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

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

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

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

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

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

• Пакеты на порт назначения 137 (NetBIOS), приходящие с IP маршрутизатора. Есть ли у маршрутизатора какие-то странные “функции” с NetBIOS, или это посторонний?
• Недействительные пакеты без запроса с !!??!! Исходный порт=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

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

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

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

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

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

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

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

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

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