Проверка пакетов NetBIOS (порт 137). Это приходит от роутера?

948
mbax

В течение довольно долгого времени брандмауэр моей машины обнаруживал странные пакеты, по-видимому, исходящие от моего маршрутизатора. Я не могу объяснить это поведение. Я подозреваю, что каким-то образом злоумышленник извне осуществляет контрабанду этих пакетов путем подмены исходного IP-адреса или взлома моего маршрутизатора, но мне нужно подтвердить это. Или, может быть, маршрутизатор предварительно настроен для этого производителем?

Если у кого-то есть идея, в чем может быть причина, я был бы очень благодарен.

Конфиг: Маршрутизатор / RR.RR.RR.RR - Arris WTM652B (я думаю, что это Touchstone под капотом), брандмауэр включен.

Мой хост / MM.MM.MM.MM с iptables

Я получаю два типа неожиданных пакетов:

  • DST порт 137 (NetBIOS) пакеты, поступающие с IP-адреса маршрутизатора. У маршрутизатора есть какие-то странные «дополнения» с NetBIOS, или это посторонний?
  • Неверные незапрошенные пакеты с !! ?? !! Порт SRC = 443, поступающий с разных IP-адресов, выделенных Google Inc. Может ли это быть попыткой взлома? Кто-то (возможно, Google?) Пытается пройти через мой брандмауэр с помощью динамических правил на моем брандмауэре (когда я ищу в Google, эти правила пробивают дыру, а кто-то пытается проникнуть через эту дыру)?

Вот образец:

Apr 27 10:55:38 notebook kernel: iptables REJECT input: IN=enp0s25 OUT= MAC=(my LAN MAC addr) SRC=RR.RR.RR.RR DST=MM.MM.MM.MM LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=4108 PROTO=UDP SPT=2092 DPT=137 LEN=58  Apr 27 10:55:42 notebook kernel: iptables REJECT input: IN=enp0s25 OUT= MAC=(my LAN MAC addr) SRC=RR.RR.RR.RR DST=MM.MM.MM.MM LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=4109 PROTO=UDP SPT=2092 DPT=137 LEN=58  Apr 27 10:55:49 notebook kernel: iptables DROP input/invalid: IN=enp0s25 OUT= MAC=(my LAN MAC addr) SRC=216.58.212.4 DST=MM.MM.MM.MM LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=58408 PROTO=TCP SPT=443 DPT=53474 WINDOW=0 RES=0x00 RST URGP=0  Apr 27 10:55:50 notebook kernel: iptables DROP input/invalid: IN=enp0s25 OUT= MAC=(my LAN MAC addr) SRC=216.58.201.195 DST=MM.MM.MM.MM LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=32104 PROTO=TCP SPT=443 DPT=34440 WINDOW=0 RES=0x00 RST URGP=0  Apr 27 10:58:27 notebook kernel: iptables DROP input/invalid: IN=enp0s25 OUT= MAC=(my LAN MAC addr) SRC=172.217.20.142 DST=MM.MM.MM.MM LEN=40 TOS=0x00 PREC=0x00 TTL=59 ID=16097 PROTO=TCP SPT=443 DPT=38786 WINDOW=0 RES=0x00 RST URGP=0  

Есть идеи, что здесь происходит?

Очень спасибо, mbax

0
Я чувствую, что это поможет, если вы расскажете нам больше о конфигурации вашего маршрутизатора, потому что пересылка NetBIOS из глобальной сети обычно не происходит там. Что касается `https`, то маршрутизатор обычно не открывает свой брандмауэр для трафика, инициируемого _от определенного удаленного _source_ порта, и с этим мало кто может что-либо сделать. Один вопрос заключается в том, существуют ли другие клиенты локальной сети, а другой - можете ли вы использовать такой инструмент, как «wireshark», чтобы лучше понять, что происходит. Run CMD 8 лет назад 0
Спасибо за ответ на Class Stacker. Конфигурация маршрутизатора довольно проста в пользовательском интерфейсе, к сожалению. У него есть простая кнопка с надписью «Брандмауэр включен» и «Брандмауэр выключен». Мой "включен". У меня нет открытых служб или переадресации портов. Я также проверил внешне, и порты TCP не открыты. По поводу второго вопроса: нет, моя машина одна в локальной сети. Я попытался использовать tcpdump, но он не сказал мне намного больше, чем журнал брандмауэра. Я попробую с wireshark. mbax 8 лет назад 0
Первый тип пакета (http://pastebin.com/UeH12zMq) - это запрос имени NetBIOS. «Маршрутизатор» (или кто-то еще) нюхает, чтобы увидеть, кто находится в сети. Это нормально? Похоже, что по второму типу сброс соединения TCP отправляется Google (http://pastebin.com/GQW9YeiX). Может ли это быть из-за моих сеансов HTTPS в браузере? Почему RST, эти соединения должны заканчиваться обычным FIN, IMO. mbax 8 лет назад 0
Я нашел аналогичную ветку, относящуюся к таким пакетам, к ответам AJAX на веб-сайте (в их случае Facebook): http://security.stackexchange.com/questions/73344/is-it-safe-to-ignore-dos-attacks-on -my-router Они, кажется, не очень уверены, хотя. mbax 8 лет назад 0

2 ответа на вопрос

0
Mokubai

Я не буду беспокоиться о запросе имени NetBIOS, поступающем от моего маршрутизатора.

Я видел много маршрутизаторов, которые, когда вы входите в их параметры фильтрации MAC (или любой параметр, который работает с использованием MAC-адресов), также будут показывать имя NetBIOS, установленное на этом ПК. Это облегчает определение того, какие машины принадлежат вам в сети, и ограничивает их при необходимости.

Если вы все еще не уверены, то я бы пошел на grc.com и использовал их Shields Up! инструменты для сканирования ваших портов и убедитесь, что порт 137 закрыт на интернет-стороне вашего маршрутизатора. Таким образом, вы можете быть уверены, что пакеты проверки имени приходят от самого маршрутизатора, а не от Интернета в целом.

Да, я не думал об этом. Действительно, кажется, что маршрутизатор может выбирать символические имена (по крайней мере, когда брандмауэр не блокирует содержимое - например, для планшетов, телефонов или устройств Windows). Это имеет смысл. mbax 8 лет назад 0
0
mbax

Я нашел очень похожую ветку с очень понятным ответом:

Как примечание, я вижу такое поведение на некоторых из моих серверов с определенными диапазонами IP-адресов. Все они являются пакетами RST, которые отправляются, потому что ротация DNS некоторых обычно используемых веб-сервисов содержит IP-адреса, которые на самом деле не работают.

Напомним, что, вероятно, происходит из-за кластеров Google и изменения IP-адресов, а также многочисленных запросов javascript через AJAX. Некоторые из этих серверов Google, вероятно, не работают и отправляют RST (после переключения IP?)

Другая возможность - неправильная настройка в правилах брандмауэра или ошибка брандмауэра. Я использовал официальное руководство по настройке iptables и использовал правила почти 1: 1, так что это не должно быть так, но кто знает?

И третье - это может быть незапрошенный пакет, отправленный непосредственно на мой маршрутизатор с IP-адресом SRC = IP-адрес маршрутизатора и IP-адресом DST = IP-адрес моего устройства. Маршрутизатор может быть настолько глуп, чтобы не отбрасывать эти недопустимые пакеты. Я был бы удивлен, если бы это было так.

Если у кого-то есть лучшее объяснение, пожалуйста, помогите.