Нет доступа к 445 порту CIFS из вне по реальному IP / No access to 445 port CIFS to real IP address

[alexpebody]

Добрый день. Я имею роутер Keenetic Ultra 2. С каких то версий прошивок (установлено FW официальное, последней версии), я потерял доступы к шарной папке, подключенного USB 3.0 диска. Ничего не менялось, не могу получить доступ более года. Писал в ТП несколько раз - не помогли. По факту какая архитектура сети и настроек у меня создана: Есть 2 реальных - белых IP, есть правила Firewall на стороне Keenetic Ultra 2, которые стоят первыми по приоритету и разрешают с удаленного, также реального - белого IP адреса. Также разумеется на самом Keenetic Ultra 2 установлена роль Wnidows CIFS и доступы определены для admin. Сайты по проверке портов, показывают что 445 и 139 закрыты, при том, что для теста были созданы 2 правила Firewall, открывающие TCP и UDP для всех IP ото всех IP. При том, 80й порт показал что открыт, тк служба Web управление роутером включена и удаленное управление разрешено, при этом отдельного проброса 80 порта на сам Keenetic Ultra 2 не создано, тк всегда Keenetic OS была построена насколько я помню так, что если служба поднята и роль включена, то необходимые порты открываются по SNAT самостоятельно, аля NAT UPnP. Разумеется я проверял доступ по шаре изнутри домашней сети, доступ к папке есть, папка видна и с ней все хорошо. Вопрос: Кто то знает, действительно роутеры Keenetic перестали разрешать доступ к портам 445 и 139 извне настолько жестко, что даже с реального на реальный IP адреса попасть нельзя? Спасибо!

---

Good afternoon. I have a Keenetic Ultra 2 router. With some firmware versions (installed FW official, latest version), I lost access to the shared folder of the connected USB 3.0 drive. Nothing has changed, I can’t access for more than a year. He wrote in TP several times - they did not help. In fact, what network architecture and settings I created: There are 2 real - white IPs, there are Firewall rules on the Keenetic Ultra 2 side, which are first in priority and allow from a remote, also real - white IP address. Also, of course, on the Keenetic Ultra 2 itself, the Wnidows CIFS role is installed and accesses are defined for admin. Port inspection sites show that 445 and 139 are closed, although 2 Firewall rules were created for the test, opening TCP and UDP for all IPs from all IPs. Moreover, the 80th port showed that it was open, because the Web service control of the router is turned on and remote control is allowed, while a separate port 80 port forwarding to Keenetic Ultra 2 itself was not created, since Keenetic OS was always built as far as I remember, if the service is up and Since the role is enabled, the necessary ports are opened by SNAT independently, ala NAT UPnP. Of course, I checked access over the ball from inside the home network, there is access to the folder, the folder is visible and everything is fine with it. Question: Does anyone know that really Keenetic routers have stopped allowing access to ports 445 and 139 from the outside so hard that you can’t even get from a real to a real IP address? Thanks!

[r13]

Ответ тут

 

[alexpebody]

3 minutes ago, r13 said:

Ответ тут

 

Спасибо, посмотрел, но там человек прокидывает порт, у меня прокинуты порты 139 и 445, толку это не дало. Кроме того, я уже говорил, что обычно службы при поднятии роли к примеру той же Windows CIFS должны прокидывать порты самостоятельно, разве это изменилось? Пусть даже так, но при пробросе 445 и 139 как и говорил, ничего не меняется, порт на telnet с разрешенного IP не отвечает, также когда firewall открыт для всех, сайты показывают что 445й все равно закрыт. Как решить?

Edited March 25, 2020 by alexpebody

[r13]

В пробросе пропишите не "этот интернет центр" а выберите другое устройство и пропишите адрес роутера в home  сегменте. 

Этот интернет центр - это localhost адрес, smb на нем не слушает. 

[alexpebody]

1 hour ago, r13 said:

В пробросе пропишите не "этот интернет центр" а выберите другое устройство и пропишите адрес роутера в home  сегменте. 

Этот интернет центр - это localhost адрес, smb на нем не слушает. 

Эм... как это не слушает? Служба висит на 127.0.0.1, по какой причине не слушает на самом Keenetic Ultra 2, всегда ведь слушал?

А что значит: выберите другое устройство и пропишите адрес роутера в home  сегменте? У меня 1 роутер -  Keenettc Ultra 2, мне пробросить на его внутренний IP?

Ну ок, это не проблема, смотрите, пробрасываю на домашнюю сеть - результат тот же. Сейчас попробуем кинуть на сам LAN интерфейс роутера: 100.0.0.1

Проверил - результат тот же, не открывается папка и шара SeagateEx, порт 445 при проверке telnet теперь отвечает! 8-( Скрины. Что еще сделать?

 

Spoiler

 

 

Spoiler

 

 

Spoiler

 

Edited March 25, 2020 by alexpebody

[alexpebody]

Все разобрался наконец то. По какой то причине 445й стал слушаться не на 127.0.0.1 как было всегда, а после какой то из прошивок он теперь слушается на внутреннем LAN хосте, те для меня это 100.0.0.1 Всем спасибо. ТП к сожалению несет чушь и советует прокинуть порты 445 и 139 на ДОМАШНЮЮ СЕТЬ! А также обвиняет ISP в блокировке портов. 😄

[sergeyk]

@alexpebody чем "внутренний LAN-хост" отличается от "домашней сети"?

[alexpebody]

4 minutes ago, sergeyk said:

@alexpebody чем "внутренний LAN-хост" отличается от "домашней сети"?

В моем случае домашняя сеть - это 100.0.0.0/24, а конкретный внутренний LAN хост это 100.0.0.1/32 вот этим отличается.

[sergeyk]

21 минуту назад, alexpebody сказал:

Сейчас попробуем кинуть на сам LAN интерфейс роутера: 100.0.0.1

Проверил - результат тот же, не открывается папка и шара SeagateEx, порт 445 при проверке telnet теперь отвечает!

Как же так?

[alexpebody]

Just now, sergeyk said:

Как же так?

Насколько я понял в какой из прошивок SMB/CIFS роль перевели на внешку, а именно на Listen 127.0.0.1 (как было ранее) -> на 0.0.0.0 не слушается, когда мы добавляем Listen 127.0.0.1, прослушивание не приводит к результату, тк запрещено слушать на localhost (видимо по соображениям безопасности, хотя ранее просто поднимая роль CIFS прослушивание и SNAT запускалось само, вместе с ролью), Жаль что ТП не сказало очень простую вещь: вам надо прокинуть порт TCP SMB 445 на внутренний интерфейс вашего LAN, вот и все. Мне сообщили что теперь это невозможно и еще прикол в Windows 10, вот в этом: https://answers.microsoft.com/ru-ru/windows/forum/all/в-windows-10/0f4b028c-ed99-443b-bfb1-68df58fc2a03 отсюда еще небольшая путанница, тк я кидал 445й на 100.0.0.1 но Windows 10 показал - нет доступа и я поверил... Такие дела.

[vasek00]

14 минуты назад, alexpebody сказал:

Все разобрался наконец то. По какой то причине 445й стал слушаться не на 127.0.0.1 как было всегда, а после какой то из прошивок он теперь слушается на внутреннем LAN хосте, те для меня это 100.0.0.1

Где что слушается и слушалось ранее на текущем 3.4

/ # netstat -ntulp | grep :445
tcp        0      0 192.168.1.1:445     0.0.0.0:*               LISTEN      -
tcp        0      0 :::445                  :::*                    LISTEN      -
/ # netstat -ntulp | grep :139
tcp        0      0 192.168.1.1:139     0.0.0.0:*               LISTEN      -
tcp        0      0 :::139                  :::*                    LISTEN      -
/ # 

Аналогичный расклад на релизах 33A3, 33B2, 301A, 215C1, 215A4

Релиз 214А2

tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      542/nqcs
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      542/nqcs

 

[alexpebody]

Just now, vasek00 said:

Где что слушается и слушалось ранее на текущем 3.4

/ # netstat -ntulp | grep :445
tcp        0      0 192.168.1.1:445     0.0.0.0:*               LISTEN      -
tcp        0      0 :::445                  :::*                    LISTEN      -
/ # netstat -ntulp | grep :139
tcp        0      0 192.168.1.1:139     0.0.0.0:*               LISTEN      -
tcp        0      0 :::139                  :::*                    LISTEN      -
/ # 

Аналогичный расклад на релизах 33A3, 33B2, 301A, 215C1, 215A4

Релиз 214А2

tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      542/nqcs
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      542/nqcs

 

Спасибо. Об этом я и говорю. Нет сейчас установленного шела SSH, поэтому не копал.

Edited March 25, 2020 by alexpebody

[sergeyk]

5 минут назад, alexpebody сказал:

Мне сообщили что теперь это невозможно и еще прикол в Windows 10, вот в этом: https://answers.microsoft.com/ru-ru/windows/forum/all/в-windows-10/0f4b028c-ed99-443b-bfb1-68df58fc2a03

Вы уверены, что вам нужен SMB 1.0 да еще и на WAN? Это же гарантированный разносчик вирусов.

[alexpebody]

8 minutes ago, sergeyk said:

Вы уверены, что вам нужен SMB 1.0 да еще и на WAN? Это же гарантированный разносчик вирусов.

Спасибо за заботу честно, но у меня зажатый через Firewall коридор, с одного конкретного реального - белого IP, на другой, так что если сомневаться в надежности Firewall, смысл вообще использовать Keenetic OS? По SMB 1.0 знаю..., но к сожалению это вина разрабов, что не обновили протокол. А так, я ничем не рискую. 55555 - это bittorrent public port по P2P, так что все ок.

 

Spoiler

 

Edited March 25, 2020 by alexpebody

[vasek00]

2 часа назад, alexpebody сказал:

По SMB 1.0 знаю..., но к сожалению это вина разрабов, что не обновили протокол.

О каком обновлении протокола идет речь если конф TSMB релиз 3.4

[global]
...
	dialect_max = SMB3.1.1
...
[/global]

 

[bigpu]

7 часов назад, r13 сказал:

В пробросе пропишите не "этот интернет центр" а выберите другое устройство и пропишите адрес роутера в home  сегменте. 

Этот интернет центр - это localhost адрес, smb на нем не слушает. 

за фичу в курсе, но почему тогда не убрать "этот интернет центр" ?

[bigpu]

Более того, раз есть такая фича, весьма не очевидная, почему бы ее не отразить в Базе...

[Le ecureuil]

Не рекомендуется SMB в WAN без VPN (и FTP тоже). Потому так и сделано.

[hellonow]

@alexpebody ТП как раз Вам и предложила правильный (а не чушь) вариант форвардинга TCP\445 (в рамках вашего кейса) на br0 и всячески указывала на небезопасный вариант использования подобного сетапа, делая акцент \ рекомендацию на использование VPN-туннелей.

interface Bridge0
    rename Home
    description "Home network"
    inherit GigabitEthernet0/Vlan1
    include AccessPoint
    include AccessPoint_5G
    mac access-list type none
    security-level private
    ip address 100.0.0.1 255.255.255.0
    ip dhcp client dns-routes
    ip dhcp client name-servers
    ip access-group _WEBADMIN_Bridge0 in
    igmp downstream
    up

@bigpu ранее мы держали статью о доступе по протоколу SMB из вне, но из-за известных всем проблем с безопасностью SMBv1 было решено убрать из доступа.

[alexpebody]

15 hours ago, vasek00 said:

О каком обновлении протокола идет речь если конф TSMB релиз 3.4

[global]
...
	dialect_max = SMB3.1.1
...
[/global]

 

Смотрите скриншот. Ответ ТП, а также:

Spoiler

10 hours ago, enpa said:

@bigpu ранее мы держали статью о доступе по протоколу SMB из вне, но из-за известных всем проблем с безопасностью SMBv1 было решено убрать из доступа.

------------------------------------------------------------------------------------------------------------------------------------

10 hours ago, enpa said:

@alexpebody ТП как раз Вам и предложила правильный (а не чушь) вариант форвардинга TCP\445 (в рамках вашего кейса) на br0 и всячески указывала на небезопасный вариант использования подобного сетапа, делая акцент \ рекомендацию на использование VPN-туннелей.

interface Bridge0
    rename Home
    description "Home network"
    inherit GigabitEthernet0/Vlan1
    include AccessPoint
    include AccessPoint_5G
    mac access-list type none
    security-level private
    ip address 100.0.0.1 255.255.255.0
    ip dhcp client dns-routes
    ip dhcp client name-servers
    ip access-group _WEBADMIN_Bridge0 in
    igmp downstream
    up

@bigpu ранее мы держали статью о доступе по протоколу SMB из вне, но из-за известных всем проблем с безопасностью SMBv1 было решено убрать из доступа.

 

Spoiler

Эта команда дает правило:

При этом Домашняя сеть - 100.0.0.0/24

Я это объяснил вот в этом посте:

Spoiler

 

Это не помогло это решение и не могло помочь, предлагая бросить порт на всю домашнюю сеть 100.0.0.0/24 (куда входят как минимум не один ПК и несколько разных устройств, которые так или иначе слушают 445й порт и какой в этом NAT смысл, куда придет пакет, на первый попавшийся IP? Такого не бывает и не будет работать).

------------------------------------------------------------------------------------------------------------------------------------

Кроме того, было еще много предложений плана (для кого обидно слово чушь, я заменю на ОШИБКА, ИМХО для меня не обидно 😉) :
1. Работать только по VPN, тк у меня ISP блокирует - фильтрует пакеты именно 139 и 445 портов - ошибка №1, за свои многие годы работы, ни разу не видел и не слышал, чтобы ISP намеренно блокировал порты, тем более на выделенном, маршрутизируемом, белом IP. Дополнительно узнал у администрации НТК. Их ответ: такого не может быть и мы никогда не блокируем порты на договорах пользователей.

2. Вывод по поводу self-test.log файлу, относительно: deny tcp 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 port eq 445, хотя выше стоят приоритетные правила (смотрите скриншоты, приложил) и я объяснил это и показал на скриншотах, отсюда ошибка ТП №2

Spoiler

3. TCP/139 - Сеть MS Windows (SMB) - ошибка № 3, поскольку 139 порт не является портом SMB (https://support.microsoft.com/ru-ru/help/832017/service-overview-and-network-port-requirements-for-windows и https://www.osp.ru/winitpro/2005/07/380116/ и еще масса источников) как минимум. Тк 139 это - Служба сеансов NetBIOS TCP 139, которое участвует, но не является SMB службой.

Было еще несколько ошибочных предложений и видений моей ситуации, я не буду приводить примеры, это ничего не даст, вопрос про это (как же я тогда получаю доступ ИЗ ВНЕ?):

Spoiler

МОЯ ПОЗИЦИЯ:

а) если вы открываете что то для public интернет сети, к примеру порт 445 - это большая дырка, но если вы задаете коридор в firewall, который ограничивает подключение только с одного реального IP на другой, то ЧТОБЫ ВЫ НЕ ДЕЛАЛИ, КАКИЕ БЫ ПРОТОКОЛЫ НЕ ИСПОЛЬЗОВАЛИ, ЭТО НЕ ДЫРКА И ЕЮ БЫТЬ НЕ МОЖЕТ, пусть даже там 100500 в степени бесконечность дыр в протоколах, тут все будет решать FIREWALL.

б) Я никоим образом не хочу и не хотел обидеть ТП - это их работа и за это БОЛЬШОЕ СПАСИБО, но исходя из порядка 10 лет обращений, я убедился, что ДАЛЕКО НЕ ВСЕГДА отвечают компетентно и часто ищут проблемы там, где их нет и помощь, может быть лично мне так совпадает, приходится искать где то еще, на форумах например, либо разгребать самому.

в) Есть предложение закрыть тему и не развивать холивар, меряясь причинными местами и некоторыми знаниями, я изначально никого ни в чем не обвинял и не старался обидеть, БОЛЬШОЕ СПАСИБО, что помогли решить проблему, тк я ходил кругами доверяя ответу Windows браузера и telnet, а в итоге тем временем, не зная изменений в LISTEN 0.0.0.0 445 -> 100.0.0.1 445 я бы еще долго парился и ходил по кругу.

Исходя из выше сказанного, я никого ни в чем не обвиняю, у каждого своя голова на плечах, у каждого свой багаж знаний, я себя супер специалистом и не выставляю, говоря лишь о том, что да, у меня есть опыт. Я констатирую факты, что какие то решения - это глупость, чушь (к примеру "ходить" по VPN, если доступ нужен конкретно с одного реального IP и он задан в firewall политике), а какие то решения, просто не работают, ошибка ТП. Всем хорошего дня.

 

Edited March 26, 2020 by alexpebody

[Ranger]

IP Spoofing? Нет, не слышали...

[alexpebody]

58 minutes ago, Ranger said:

IP Spoofing? Нет, не слышали...

Разумеется слышали, как и о: Check TTL, DHCP Snooping, ARP Inspection, Check MAC и т.д.

На сетевом уровне атака частично предотвращается с помощью фильтра пакетов на шлюзе.

Это даже не очень важно, для успешного начала атаки, угадайте мой IP устройства?

А если говорить о роботах, обходчиках, то о полноценной атаке и подборе нет речи.

Вот неплохая статья на этот счет: http://journalpro.ru/articles/ip-spoofing/ и эта 

https://rusvpn.com/ru/blog/chto-takoe-ip-spufing-i-kak-predotvrashhat-spufing-ataki/

Edited March 26, 2020 by alexpebody

[bigpu]

В 25.03.2020 в 18:31, enpa сказал:

@bigpu ранее мы держали статью о доступе по протоколу SMB из вне, но из-за известных всем проблем с безопасностью SMBv1 было решено убрать из доступа.

Спасибо за ответ, а разве на Кинетик Samba давно, не свежее SMBv1?

[Le ecureuil]

17 часов назад, alexpebody сказал:

а) если вы открываете что то для public интернет сети, к примеру порт 445 - это большая дырка, но если вы задаете коридор в firewall, который ограничивает подключение только с одного реального IP на другой, то ЧТОБЫ ВЫ НЕ ДЕЛАЛИ, КАКИЕ БЫ ПРОТОКОЛЫ НЕ ИСПОЛЬЗОВАЛИ, ЭТО НЕ ДЫРКА И ЕЮ БЫТЬ НЕ МОЖЕТ, пусть даже там 100500 в степени бесконечность дыр в протоколах, тут все будет решать FIREWALL.

MITM / Replay attack.

[Le ecureuil]

1 минуту назад, bigpu сказал:

Спасибо за ответ, а разве на Кинетик Samba давно, не свежее SMBv1?

Все равно это нехорошо. Плюс некоторые старые клиенты форсируют 1 версию.