sebbre 10 Geschrieben 12. Juli 2007 Melden Teilen Geschrieben 12. Juli 2007 Hallo, seitdem letzte Woche ein neues Firewallsystem Einzug gehalten hat (Watchguard X750e) stelle ich mit den mitgebrachten Monitoring-Möglichkeiten (Host-Watch) erschreckend fest, dass einer unserer Windows Server fleißig nach draußen telefoniert und zwar über Port 137 UDP. Teilweise sind mehrere 100 Verbindungen gleichzeitig offen, was zu erheblicher Last führt. Um die Auswirkungen einzudämmen wurde die Telefonie über Port 137 UDP von dieser Maschine vorerst per FW-Policy unterbunden. Die Broadcasts gehen teilweise an komplette Adressbereiche ins öffentliche Netz, aber auch (dem angehängten Screenshot zu entnehmen) ins 169.254.x.x Netz, welches ja eigentlich von Windows für die automatische Adresszuteilung verwendet wird, wenn kein DHCP Server im Netz steht. Der Server hat 2 NICs an Bord, von denen eine deaktiviert ist. Probehalber wurde die 2. NIC in Betrieb genommen (Adressierung im selben Subnetz wie die erste NIC). Im Traffic Monitor der Firewall war dann auch sehr schön zu sehen, dass die Broadcasts über beide NICs gehen. Habe zuerst vermutet, dass sich ein Trojaner o.ä. eingenistet hat, ein FullScan mit Kaspersky (aktuelle Definitionen) ergab aber keine Treffer - ebensowenig wie der Einsatz von Ad-Aware und Spybot. Der MS Baseline Security Analyzer stellt auch keine kritischen Konfigurationsfehler fest. Steckbrief: DELL PowerEdge 850 Windows Server 2003 R2 Standard SP2 2. DC im Netz Neben DNS und IIS laufen WSUS 2.0 der Kaspersky Administration Server sowie der Watchguard Log Server auf der Maschine. Probehalber wurden die Dienste (WSUS, Kaspersky, Log Server) schon gestoppt um Veränderungen am Broadcast Verhalten festzustellen - ohne Erfolg. Adressierung im Netz erfolgt nicht per DHCP, alle Maschinen werden fest adressiert. Google wurd schon redlich bemüht, allerdings ohne erfolgsversprechende Ergebnisse. Vielleicht hat ja noch jemand eine Idee (außer Neuinstallation). Danke & Gruß Sebastian Zitieren Link zu diesem Kommentar
IThome 10 Geschrieben 12. Juli 2007 Melden Teilen Geschrieben 12. Juli 2007 Ich habe solche Meldungen auch in den Logs der Watchguards gesehen. Ich bekomme NetBIOS Namensauflösungsversuche entweder durch den Einsatz von WINS geregelt oder weg durch das Abschalten von NetBIOS über TCP/IP. Auf den Watchguards, auf denen SMB sowieso in beide Richtungen in den meisten Fällen verweigert wird, definiere ich meistens einen SMB-Filter, Deny für ANY to ANY und logge keine Deny-Logs (es sind also keine unhandled Packets mehr). Es wäre aber interessant zu wissen, warum der Server so exzessiv Namen auflösen will und das Log zu sehen wäre auch nicht das Schlechteste, das Bild ist allerdings nicht freigeschaltet ... Vielleicht mal alle Nicht-Standarddienste abschalten, beobachten und nach und nach wieder zuschalten ... Zitieren Link zu diesem Kommentar
sebbre 10 Geschrieben 13. Juli 2007 Autor Melden Teilen Geschrieben 13. Juli 2007 Das deaktivieren von netBIOS über TCP/IP bringt den Server erstmal zum schweigen (hinsichtlich der Broadcasts). Danke für den Tipp. Eine Ursache konnte bislang jedoch nicht gefunden werden - Nicht Standard-Dienste wurden testweise deaktiviert, allerdings ohne eine Veränderung an dem Verhalten festzustellen. In eine intensivere Ursachenforschung werde ich nach meinem Urlaub einsteigen und bei konkreten Hinweisen hier berichten. Gruß Sebastian Zitieren Link zu diesem Kommentar
IThome 10 Geschrieben 13. Juli 2007 Melden Teilen Geschrieben 13. Juli 2007 Das mit dem SMB-Filter auf der Firebox ist auch ne gute Sache, diese Meldungen wirst Du trotz allem immer haben. Es hält die Loganzahl in einem erträglichen Bereich, der besser durchsuchbar ist ... Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.