NetBIOS-Paketprüfung (Port 137). Kommt es vom Router?

1004
mbax

Seit einiger Zeit entdeckt die Firewall meines Computers seltsame Pakete, die scheinbar von meinem Router stammen. Ich kann dieses Verhalten nicht erklären. Ich vermute, dass ein Angreifer von außen diese Pakete schmuggeln kann, indem er entweder die Quell-IP-Adresse spoofet oder meinen Router gehackt hat, aber ich muss es bestätigen. Oder vielleicht ist der Router vom Hersteller dafür vorkonfiguriert?

Wenn jemand eine Idee hat, woran es liegen könnte, wäre ich sehr dankbar.

Config: Router / RR.RR.RR.RR - Arris WTM652B (Ich denke, es ist Touchstone unter der Haube), Firewall aktiviert.

Mein Host / MM.MM.MM.MM mit iptables

Ich bekomme zwei Arten unerwarteter Pakete:

  • DST-Port 137 (NetBIOS) -Pakete, die von der IP des Routers stammen. Hat der Router einige komische "Extras" mit NetBIOS oder ist er ein Außenseiter?
  • Ungültige unerwünschte Pakete mit !! ?? !! SRC-Port = 443, der von verschiedenen IP-Adressen stammt und der Google Inc. zugewiesen wurde. Kann dies ein Hacking-Versuch sein? Jemand (möglicherweise Google?), Der versucht, über dynamische Regeln in meiner Firewall durch meine Firewall zu gelangen (wenn ich Google durchsuche, schlagen diese Regeln ein Loch und jemand versucht, sich durch dieses Loch hindurchzuschleichen)?

Hier ist ein Beispiel:

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

Irgendeine Idee, was hier los ist?

Besten Dank, mbax

0
Ich denke, es wäre hilfreich, wenn Sie uns mehr über die Konfiguration Ihres Routers erzählen würden, da die Weiterleitung von NetBIOS aus dem WAN dort normalerweise nicht stattfinden würde. Was "https" angeht, öffnet ein Router seine Firewall normalerweise nicht für den von einem bestimmten entfernten _source_port initiierten Verkehr, und dagegen kann niemand etwas dagegen unternehmen. Eine Frage ist, gibt es andere LAN-Clients, und die andere ist, könnten Sie ein Werkzeug wie "Wireshark" verwenden, um besser zu verstehen, was los ist. Run CMD vor 8 Jahren 0
Vielen Dank für das Beantworten von Class Stacker. Die Konfiguration des Routers ist in der Benutzeroberfläche leider ziemlich einfach. Es gibt ein einfaches Optionsfeld, das "Firewall ein" und "Firewall aus" sagt. Mein ist "auf". Ich habe keine offenen Dienste oder Portweiterleitung. Ich habe auch extern geprüft und keine TCP-Ports sind geöffnet. Zum zweiten Problem: Nein, mein Rechner ist alleine im LAN. Ich habe versucht, tcpdump zu verwenden, aber es sagte mir nicht viel mehr als das Firewall-Protokoll. Ich werde es mit Wireshark versuchen. mbax vor 8 Jahren 0
Der erste Pakettyp (http://pastebin.com/UeH12zMq) - es handelt sich um eine NetBIOS-Namensabfrage. Der "Router" (oder eine andere Person) stellt fest, wer sich im Netzwerk befindet. Ist das normal? In Bezug auf den zweiten Typ scheint ein Reset der TCP-Verbindung von Google zu erfolgen (http://pastebin.com/GQW9YeiX). Kann es sein, dass dies an meinen HTTPS-Sitzungen im Browser liegt? Warum RST, sollten diese Verbindungen mit einem normalen FIN enden, imo. mbax vor 8 Jahren 0
Ich habe einen ähnlichen Thread gefunden, der solche Pakete mit AJAX-Antworten von der Website (in ihrem Fall Facebook) in Beziehung setzt: http://security.stackexchange.com/questions/73344/is-it-safe-to-ignore-dos-attacks-on -my-router Sie scheinen jedoch nicht sehr sicher zu sein. mbax vor 8 Jahren 0

2 Antworten auf die Frage

0
Mokubai

I would not be worried about a NetBIOS name query coming from my router.

I've seen many routers that when you go into their MAC filtering options (or any option that works using MAC addresses) will also show the NetBIOS name that has been set on that PC. This makes it easier to work out what machines are yours on the network and restrict them as necessary.

If you are still uncertain then what I would do is go to grc.com and use their Shields Up! tools to scan your ports and make sure that port 137 is closed on the internet side of your router. This way you can be sure that the name probe packets are coming from your router itself and not the internet at large.

Ja, daran habe ich nicht gedacht. Der Router scheint tatsächlich symbolische Namen zu finden (zumindest wenn die Firewall das Zeug nicht blockiert - z. B. für Pads, Telefone oder Windows-Geräte). Dies macht Sinn. mbax vor 8 Jahren 0
0
mbax

I found a very similar thread with a very understandable answer:

As a side note, I am seeing such behaviour too on some of my servers with certain ip ranges. They are all RST packets that are sent because the DNS rotation of some commonly used webservice is containing ip addresses that do not actually have a service running.

To recap, what probably happens is due to Google's clusters and changing IP addresses, also multiple javascript requests via AJAX. Some of those Google servers probably are down and send a RST (after having switched the IP?)

Other possibility is a misconfiguration in the firewall rules or a firewall bug. I used the official iptables configuration guide and used the rules almost 1:1 so this should not be the case, but who knows?

And third - it can be an unsolicited packet, sent directly to my router with SRC IP=router ip and DST IP=my ip. The router might be so dumb to not drop those invalid packets. I would be surprized if it was like this.

If someone has a better explanation, please help.

Verwandte Probleme