NetBIOS Session service

[Ap0ll0-13]

Erstmal hallo :new

Ich bin heute beim Firewall einstellen auf etwas gestoßen, das ich mir nicht wirklich erklären kann. Die Windows Dateifreigabe setzt ja auf NetBIOS über TCP/IP auf, und überträgt Daten über Port TCP139 (NetBIOS Session). Beim mitloggen von einem kleinen Transfer via Wireshark bin ich dann auf ganz seltsame Pakete gestoßen, und zwar stimmt bei diesen Paketen die Source IP nicht (siehe Bild im Anhang).

Die Pakete kommen von meinem PC (sieht man an der MAC-Adresse), aber von ganz anderen IP-Adressen, z.B. 5.85.13.73 oder 192.168.31.1 (was ja noch nicht mal in meinem Subnetz ist).

Hat schonmal jemand so ein Verhalten gesehen oder kann mir das erklären? Ist jetzt nicht soo wichtig, aber aus reiner Neugierde wüsste ich halt schon gerne wie das zustande kommt.

[volker81]

Das ganze läuft über Port 7881.

Das ist der Standard-Port von neuren Azureus-Versionen.

[Ap0ll0-13]

Tja nur Azureus hab ich nicht drauf (hab außerdem drauf geachtet dass keine Programme im Hintergrund laufen), und außerdem sind die Ports 7878 und 7879 auch im Spiel, nicht nur 7881.

/edit: Und wenn ich recht informiert bin sind solche Ports in Filesharing Programmen ja immer destination ports für eingehende Verbindungen und nicht source ports wie in diesem fall oder?

Bearbeitet 12. November 2008 von Ap0ll0-13

[RipperFox]

Lass mich auch mal raten:

Du hast Hamachi drauf und Irgendeiner Routet Traffic für 192.168.0.?/? über dich.

Dein Rechner (hat Routing aktiv) weiß damit wiederum nix anzufangen und schickt es an deinen Router.

Treffer?

Grüße

Ripper

@Volker: Sourceports sind beliebig..

Bearbeitet 12. November 2008 von RipperFox
Seitenhieb at Volker

[RipperFox]

Nochwas: Vllt. macht das sogar ein Fiesling absichtlich. In den RPC-Schnittstellen, welche auf Port 137-139 & 445 laufen gabs grade eben mal wieder schöne Bugs, welche sich exploiten ließen.

Immer schön Updaten also..

[Ap0ll0-13]

Ja das ist wohl ein Treffer, ich hab Hamachi drauf (aber deaktiviert) und die IP (5.85...) stimmt überein, die anderen beiden IPs kommen von VMware Netzwerkadaptern.

Ja da hätte ich vielleicht früher nachschauen sollen.

Trotzdem frage ich mich, warum die Pakete, die ja anscheinend für die anderen Netzweradapter gedacht sind, an meiner normalen LAN Schnittstelle rauskommen. Leiten die VMWare und Hamachi Netzwerkadapter automatisch den ganzen Traffic weiter? Weil die Services von den beiden Programmen hatte ich zum Testzeitpunkt aus.

PS: Ich habe Routing deaktiviert und das Ziel war nicht der Router sondern ein normaler PC. Aber trotzdem, danke für den richtigen Tipp

[RipperFox]

Ja das ist wohl ein Treffer, ich hab Hamachi drauf (aber deaktiviert) und die IP (5.85...) stimmt überein, die anderen beiden IPs kommen von VMware Netzwerkadaptern.

Wenn das deine Hamachi-IP war:

Dein Rechner hat ja die IP trozdem aktiv, obwohl Hamachi nicht verbunden ist - Soweit normal.

Dein Rechner sucht dann wohl nach anderen Rechnern (NetBIOS-Broadcast und Käse).

Kann sein, daß dein Windows die abgehenden Adressen bissl durcheinanderbringt. Oft wird die niedrigste IP (=5.x.x.x) als Quell-IP genommen - dieses Verhalten hat z.B. auch Linux ohne extra Routing-Tabellen.

(Multihomed NetBIOS Discovery ****t sowieso gewaltig - man WINS..)

Trotzdem frage ich mich, warum die Pakete, die ja anscheinend für die anderen Netzweradapter gedacht sind, an meiner normalen LAN Schnittstelle rauskommen.

Warum das über deine LAN-Schnittstelle geht, sollte klar sein: Die VMWare-Netzwerkadapter sind auf deine LAN-Schnittstelle des Hosts gebrückt..

(VMNET-sonstwas.. kann mir die Nummer welches VMNet denn nun NAT, Host-only und Bridged per default hat nich merken)

Leiten die VMWare und Hamachi Netzwerkadapter automatisch den ganzen Traffic weiter? Weil die Services von den beiden Programmen hatte ich zum Testzeitpunkt aus.

S.o. sieht nach relativ normalen Verhalten aus - hättest du gleich alles angegeben (Hamachi, Vmware mit den 192.168.0.x/x IPs) wäre es schneller gegangen (vllt. hättest du es ja auch selbst gemerkt

Grüße

Ripper