CheckAdBlock<\/a>. Один из первых сайтов, который мне попался много лет назад, когда возникла мысль протестировать работу блокировщиков рекламы в браузере.<\/p>\n",
"date_published": "2023-01-20T13:35:10+07:00",
"date_modified": "2025-02-28T09:01:38+07:00",
"tags": [
"dns",
"ipv6",
"jabber",
"online",
"ssl",
"web",
"веб",
"защита",
"настройка",
"порт",
"почта",
"проверка",
"сервер",
"сервис",
"тест"
],
"_date_published_rfc2822": "Fri, 20 Jan 2023 13:35:10 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "262",
"_e2_data": {
"is_favourite": true,
"links_required": [],
"og_images": []
}
},
{
"id": "259",
"url": "https:\/\/kini24.ru\/all\/probros-portov-v-openwrt\/",
"title": "Проброс портов в OpenWrt",
"content_html": "Мне никогда не нравилось, что в интерфейсе OpenWrt нельзя указать несколько портов при пробросе, можно указать только диапазон. А если мне нужно несколько, объединенных одним сервисом? Например, почта. Если указывать все порты, то получается, что на каждый из них нужно создавать свое правило. В итоге получается такая простыня правил, что ориентироваться в ней становится затруднительно.
\nПо сути, эта заметка — напоминание себе как нужно правильно прокинуть порты во внутреннюю сеть, используя iptables. И, заодно, там же сделаем так, чтобы из локальной сети можно было обращаться к своим серверам по доменному имени.
\nИдем в раздел Network<\/i> — Firewall<\/i> и открываем вкладку Custom rules<\/i>. Добавляем туда строку такого вида:<\/p>\niptables -t nat -A zone_wan_prerouting -p tcp -m multiport --dports 25,110,143,465,587,993,995,4190 -j DNAT --to-destination 192.168.1.100<\/code><\/pre>Здесь мы помещает в цепочку zone_wan_prerouting<\/i> таблицы nat<\/i> правило, указывающее, что сервисы, обращающиеся из внешней сети на перечисленные порты, должны перенаправляться на сервер с адресом 192.168.1.100. Параметр -р указывает протокол tcp, а параметр -m multiports позволяет указать не один порт, а несколько. Это правило позволит открыть порты для доступна извне, но при обращении к ним из локальной сети придется указывать «прямой» адрес 192.168.1.100. Если вписать свой внешний адрес (IP или DNS), то ничего не выйдет. Чтобы это стало возможным, нужно дописать еще две строки:<\/p>\niptables -t nat -A zone_lan_prerouting -d 95.170.188.45 -p tcp -m multiport --dports 25,110,143,465,587,993,995,4190 -j DNAT --to-destination 192.168.1.100\niptables -t nat -A zone_lan_postrouting -d 192.168.1.100 -p tcp -m multiport --dports 25,110,143,465,587,993,995,4190 -j MASQUERADE<\/code><\/pre>В первой строке мы говорим, что все обращения к внешнему адресу на указанные порты должны перенаправляться на локальный адрес 192.168.1.100. Во второй строке мы, если так можно выразиться, прячем, что обращаемся из локальной сети.
\nПосле нажатия кнопки Save<\/i> содержимое поля Custom Rules<\/i> будет сохранено на роутере в файле \/etc\/firewall.user. Для применения эти необходимо перезапустить файрволл:<\/p>\n\/etc\/init.d\/firewall restart<\/code><\/pre>После этого почта станет доступной из внешней сети и из локальной, причем по доменному имени или внешнему IP-адресу.<\/p>\n
Обновление<\/b> Если оставить последнее правило в таком виде, то исходящий IP-адрес (адрес клиента) будет отображаться как адрес самого роутера в локальной сети: 192.168.1.1. Поэтому следует немного изменить правило, чтобы оно выглядело следующим образом:<\/p>\niptables -t nat -A zone_lan_postrouting -s 192.168.1.0\/24 -d 192.168.1.100 -p tcp -m multiport --dports 25,110,143,465,587,993,995,4190 -j MASQUERADE<\/code><\/pre>В этом случае внешние адреса останутся «настоящими», а все запросы из локальной сети будут отображаться как 192.168.1.1. На мой взгляд, это приемлемо.<\/p>\n",
"date_published": "2022-12-25T12:48:29+07:00",
"date_modified": "2023-01-18T12:11:20+07:00",
"tags": [
"firewall",
"iptables",
"openwrt",
"внешний",
"доступ",
"локальная сеть",
"перенаправление",
"порт",
"проброс",
"роутер"
],
"_date_published_rfc2822": "Sun, 25 Dec 2022 12:48:29 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "259",
"_e2_data": {
"is_favourite": false,
"links_required": [
"highlight\/highlight.js",
"highlight\/highlight.css"
],
"og_images": []
}
},
{
"id": "175",
"url": "https:\/\/kini24.ru\/all\/samsung-tv\/",
"title": "Управление Samsung TV через сеть",
"content_html": "
Не оставляю попыток получить управление своим ТВ через сеть. Периодически поглядываю через wireshark на него, но информации маловато для понимания. Существует же множество утилит, которые позволяют управлять им со смартфона, значит это возможно. Для линукса существует утилита samsungctl, но мою модель она не поддерживает (???)<\/p>\n
Я вообще когда-нибудь получу контроль над ним через сеть?<\/p>\n
Ниже список доступных портов, чтобы не забыть.<\/p>\n
# nmap -v -p1-65535 -sS 192.168.1.7\n\nCompleted SYN Stealth Scan at 11:56, 3.12s elapsed (65535 total ports)\nNmap scan report for Samsung-TV.kini24.ru (192.168.1.7)\nHost is up (0.00065s latency).\nNot shown: 65517 closed ports\nPORT STATE SERVICE\n7676\/tcp open imqbrokerd\n7678\/tcp open unknown\n8001\/tcp open vcom-tunnel\n8002\/tcp open teradataordbms\n8080\/tcp open http-proxy\n8187\/tcp open unknown\n9012\/tcp open unknown\n9119\/tcp open unknown\n9197\/tcp open unknown\n9999\/tcp open abyss\n15500\/tcp open unknown\n32768\/tcp open filenet-tms\n32769\/tcp open filenet-rpc\n32770\/tcp open sometimes-rpc3\n32771\/tcp open sometimes-rpc5\n39556\/tcp open unknown\n52752\/tcp open unknown\n56295\/tcp open unknown\nMAC Address: 7C:64:56:FE:76:2A (Unknown)<\/code><\/pre>Порты Samsung AllShare: 7676, 7678, 8187, 9119, 9197<\/p>\n
Полное сканирование портов:<\/p>\n
PROTOCOL STATE SERVICE\n1 open icmp\n2 open|filtered igmp\n6 open tcp\n17 open udp\n136 open|filtered udplite\n255 open|filtered unknown\n7676\/tcp open imqbrokerd\n7678\/tcp open unknown\n8001\/tcp open vcom-tunnel\n8002\/tcp open teradataordbms\n8080\/tcp open http-proxy\n8187\/tcp open unknown\n9012\/tcp open unknown\n9119\/tcp open unknown\n9197\/tcp open unknown\n9999\/tcp open abyss\n15500\/tcp open unknown\n26101\/tcp open unknown\n32768\/tcp open filenet-tms\n32769\/tcp open filenet-rpc\n32770\/tcp open sometimes-rpc3\n32771\/tcp open sometimes-rpc5\n40046\/tcp open unknown\n57772\/tcp open unknown\n60850\/tcp open unknown\n1900\/udp open|filtered upnp\n5353\/udp open|filtered zeroconf\n8001\/udp open|filtered vcom-tunnel\n32768\/udp open|filtered omad\nMAC Address: 7C:64:56:FE:76:2A (Unknown)<\/code><\/pre>",
"date_published": "2022-12-12T14:00:40+07:00",
"date_modified": "2022-12-21T18:40:16+07:00",
"tags": [
"samsung",
"smarttv",
"доступ",
"порт",
"сеть",
"сканирование",
"удаленное управление"
],
"_date_published_rfc2822": "Mon, 12 Dec 2022 14:00:40 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "175",
"_e2_data": {
"is_favourite": false,
"links_required": [
"highlight\/highlight.js",
"highlight\/highlight.css"
],
"og_images": []
}
},
{
"id": "151",
"url": "https:\/\/kini24.ru\/all\/dostup-k-samsung-smart-tv\/",
"title": "Доступ к Samsung Smart TV",
"content_html": "Проба пера<\/h3>\n
Когда мне становится скучно, в голову приходят самые разные мысли...
\nВ этот раз в голове мелькнула мысль просканировать телевизор на открытые порты. Результат был положительным:<\/p>\n
Starting Nmap 5.51 ( http:\/\/nmap.org ) at 2018-01-21 20:41 +07\nNmap scan report for 192.168.1.7\nHost is up (0.0026s latency).\nNot shown: 991 closed ports\nPORT STATE SERVICE\n7676\/tcp open imqbrokerd\n8001\/tcp open vcom-tunnel\n8002\/tcp open teradataordbms\n8080\/tcp open http-proxy\n9999\/tcp open abyss\n32768\/tcp open filenet-tms\n32769\/tcp open filenet-rpc\n32770\/tcp open sometimes-rpc3\n32771\/tcp open sometimes-rpc5\n\nNmap done: 1 IP address (1 host up) scanned in 0.25 seconds<\/code><\/pre>Номера портов, по большей части не знакомы, но 8001, 8002, 8080 и 9999 наводят на определенные мысли. Пробуем получить информацию по ним...<\/p>\n
$ curl -v http:\/\/192.168.1.7:7676\n* Rebuilt URL to: http:\/\/192.168.1.7:7676\/\n* Trying 192.168.1.7...\n* TCP_NODELAY set\n* Connected to 192.168.1.7 (192.168.1.7) port 7676 (#0)\n> GET \/ HTTP\/1.1\n> Host: 192.168.1.7:7676\n> User-Agent: curl\/7.57.0-DEV\n> Accept: *\/*\n> \n* HTTP 1.0, assume close after body\n< HTTP\/1.0 400 Bad Request \n< CONTENT-TYPE: text\/xml; charset="utf-8" \n< SERVER: UPnP\/1.1 Samsung AllShare Server\/1.0 \n< CONTENT-LENGTH: 417 \n< \n* Closing connection 0\n<?xml version="1.0"?><s:Envelope xmlns:s="http:\/\/schemas.xmlsoap.org\/soap\/envelope\/" s:encodingStyle="http:\/\/schemas.xmlsoap.org\/soap\/encoding\/"><s:Body><s:Fault><faultcode>s:Client<\/faultcode><faultstring>UPnPError<\/faultstring><detail><UPnPError xmlns="urn:schemas-upnp-org:control-1-0"><errorCode>402<\/errorCode><errorDescription>Invalid Args<\/errorDescription><\/UPnPError><\/detail><\/s:Fault><\/s:Body><\/s:Envelope><\/code><\/pre>Пустые ответы приводить не буду, только те, по которым получен какой-либо результат. Проверяем порт 8001:<\/p>\n
$ curl -v http:\/\/192.168.1.7:8001\n* Rebuilt URL to: http:\/\/192.168.1.7:8001\/\n* Trying 192.168.1.7...\n* TCP_NODELAY set\n* Connected to 192.168.1.7 (192.168.1.7) port 8001 (#0)\n> GET \/ HTTP\/1.1\n> Host: 192.168.1.7:8001\n> User-Agent: curl\/7.57.0-DEV\n> Accept: *\/*\n> \n* HTTP 1.0, assume close after body\n< HTTP\/1.0 401 Unauthorized\n< access-control-allow-origin: *\n< content-length: 29\n< \n* Closing connection 0\n<html><body>401<\/body><\/html><\/code><\/pre>На очереди 8002:<\/p>\n
$ curl -v https:\/\/192.168.1.7:8002\n* Rebuilt URL to: https:\/\/192.168.1.7:8002\/\n* Trying 192.168.1.7...\n* TCP_NODELAY set\n* Connected to 192.168.1.7 (192.168.1.7) port 8002 (#0)\n* ALPN, offering h2\n* ALPN, offering http\/1.1\n* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH\n* successfully set certificate verify locations:\n* CAfile: \/usr\/share\/ca-certificates\/ca-bundle.crt\n CApath: none\n* TLSv1.2 (OUT), TLS header, Certificate Status (22):\n* TLSv1.2 (OUT), TLS handshake, Client hello (1):\n* TLSv1.2 (IN), TLS handshake, Server hello (2):\n* TLSv1.2 (IN), TLS handshake, Certificate (11):\n* TLSv1.2 (OUT), TLS alert, Server hello (2):\n* SSL certificate problem: self signed certificate in certificate chain\n* stopped the pause stream!\n* Closing connection 0\ncurl: (60) SSL certificate problem: self signed certificate in certificate chain\nMore details here: https:\/\/curl.haxx.se\/docs\/sslcerts.html\n\ncurl failed to verify the legitimacy of the server and therefore could not\nestablish a secure connection to it. To learn more about this situation and\nhow to fix it, please visit the web page mentioned above.<\/code><\/pre>Теперь очередь порта 8080:<\/p>\n
$ curl -v http:\/\/192.168.1.7:8080\n* Rebuilt URL to: http:\/\/192.168.1.7:8080\/\n* Trying 192.168.1.7...\n* TCP_NODELAY set\n* Connected to 192.168.1.7 (192.168.1.7) port 8080 (#0)\n> GET \/ HTTP\/1.1\n> Host: 192.168.1.7:8080\n> User-Agent: curl\/7.57.0-DEV\n> Accept: *\/*\n> \n< HTTP\/1.1 404 Not Found\n< Access-Control-Allow-Origin: *\n< Access-Control-Allow-Headers: Content-Type\n< Content-Type: text\/html\n< Content-Length: 345\n< Date: Sun, 21 Jan 2018 04:14:36 GMT\n< Server: WebServer\n< \n<?xml version="1.0" encoding="iso-8859-1"?>\n<!DOCTYPE html PUBLIC "-\/\/W3C\/\/DTD XHTML 1.0 Transitional\/\/EN"\n "http:\/\/www.w3.org\/TR\/xhtml1\/DTD\/xhtml1-transitional.dtd">\n<html xmlns="http:\/\/www.w3.org\/1999\/xhtml" xml:lang="en" lang="en">\n <head>\n <title>404 - Not Found<\/title>\n <\/head>\n <body>\n <h1>404 - Not Found<\/h1>\n <\/body>\n<\/html>\n* Connection #0 to host 192.168.1.7 left intact<\/code><\/pre>Если использовать SSL, то ответ тоже не заставит себя ждать:<\/p>\n
$ curl -v https:\/\/192.168.1.7:8080\n* Rebuilt URL to: https:\/\/192.168.1.7:8080\/\n* Trying 192.168.1.7...\n* TCP_NODELAY set\n* Connected to 192.168.1.7 (192.168.1.7) port 8080 (#0)\n* ALPN, offering h2\n* ALPN, offering http\/1.1\n* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH\n* successfully set certificate verify locations:\n* CAfile: \/usr\/share\/ca-certificates\/ca-bundle.crt\n CApath: none\n* TLSv1.2 (OUT), TLS header, Certificate Status (22):\n* TLSv1.2 (OUT), TLS handshake, Client hello (1):\n* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.1.7:8080 \n* stopped the pause stream!\n* Closing connection 0\ncurl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.1.7:8080<\/code><\/pre>И, наконец, 9999:<\/p>\n
$ curl -v https:\/\/192.168.1.7:9999\n* Rebuilt URL to: https:\/\/192.168.1.7:9999\/\n* Trying 192.168.1.7...\n* TCP_NODELAY set\n* Connected to 192.168.1.7 (192.168.1.7) port 9999 (#0)\n* ALPN, offering h2\n* ALPN, offering http\/1.1\n* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH\n* successfully set certificate verify locations:\n* CAfile: \/usr\/share\/ca-certificates\/ca-bundle.crt\n CApath: none\n* TLSv1.2 (OUT), TLS header, Certificate Status (22):\n* TLSv1.2 (OUT), TLS handshake, Client hello (1):\n\n* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.1.7:9999 \n* stopped the pause stream!\n* Closing connection 0\ncurl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.1.7:9999<\/code><\/pre>Судя по всему, на порту 7676 «висит» какой-то UPNP. Порты 8002 и 9999 обмениваются данными через SSL, 8080 похож на веб-сервер, а 8001 требует авторизацию.
\nЕсли открыть ТВ в браузере на порту 8002, то можно получить визуальные данные о сертификате. В принципе, самое интересное, что можно из него вычленить — срок действия в 20 лет и что сертификат является самоподписанным.
\nПорывшись в интернете, понял, что на эту тему достаточно мало материала. Впрочем, сначала нужно просмотреть SamsungSmartSDK, упомянутый в сертификате. Возможно, что там найдется какая-то дополнительная информация.
\nКстати, теоретически, есть возможность включить ТВ с ипользованием технологии Wake-On-LAN. Стандартный способ, видимо, не проходит — по крайне мере на «magic packet» он не отозвался. Но пример кода, реализующего эту возможность, я встретил.<\/p>\n",
"date_published": "2018-01-21T21:00:33+07:00",
"date_modified": "2018-01-21T23:39:38+07:00",
"tags": [
"порт",
"результат",
"сканирование",
"телевизор"
],
"_date_published_rfc2822": "Sun, 21 Jan 2018 21:00:33 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "151",
"_e2_data": {
"is_favourite": false,
"links_required": [
"highlight\/highlight.js",
"highlight\/highlight.css"
],
"og_images": []
}
},
{
"id": "23",
"url": "https:\/\/kini24.ru\/all\/onlayn-skaner-portov\/",
"title": "Онлайн сканер портов",
"content_html": "
Наткнулся сегодня с утра пораньше на такой вот любопытный сканер портов<\/a>. Любопытен он тем, что, несмотря на некоторые нестандартные используемые порты четко определил использующий их сервис. Я не говорю про такие обычные вещи как postfix, apache и т. д. Он, например, смог определить что один порт используется LuCI Lua, на другом «висит» Dropbear и так далее. От роботов сервис защищен стандартной капчей Google.<\/p>\n",
"date_published": "2016-12-19T07:54:29+07:00",
"date_modified": "2016-12-19T07:54:26+07:00",
"tags": [
"онлайн",
"порт",
"сервис",
"сканер"
],
"_date_published_rfc2822": "Mon, 19 Dec 2016 07:54:29 +0700",
"_rss_guid_is_permalink": "false",
"_rss_guid": "23",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
}
],
"_e2_version": 4134,
"_e2_ua_string": "Aegea 11.3 (v4134)"
}