Bents Blog

Bei einem Kunden hatte ich letztens ein etwas eigenwilliges Problem:

Auf einem Server gab es in unregelmäßigen Abständen diverse Fehlererscheinungen (wie z.B. abstürzende Dienste), die sich jedoch recht schnell auf einen Engpass im RAM des Systems zurückverfolgen ließen.
Jeweils kurz vorher tauchte folgender Eintrag im Systemereignisprotokoll auf:

Der hohe Verbrauch von Java ist (leider) nicht weiter ungewöhnlich, da es sich um einen vCenter-Server handelt während der svchost-Prozess schon eher einem Problem vermuten lässt.

Nach einer kurzen Recherche mittels des Process Explorers behandelte die betreffende svchost-Instanz folgende Dienste:

Der DHCP-Client lässt sich ausschließen, da das System keine IP-Adressen per DHCP bezieht. Den NetBIOS-Hilfsdienst halte ich für einen eher unwahrscheinlichen Auslöser, zumal LMHOSTS-Abfragen ebenfalls deaktiviert sind.
Somit ist der Ereignisdienst selbst der verdächtigste Auslöser, bestärkt wird dies auch durch folgende Einträge, die nach der anfänglichen Ressourcenwarnung in sehr kurzen Abständen in hoher Anzahl erfolgen:

Offensichtlich werden also eine große Menge Events generiert und können nicht verarbeitet werden. Bei der genaueren Analyse der Protokolle sind mir schließlich eine Menge von Einträgen verweigerter Verbindungen im Sicherheitsprotokoll aufgefallen:

An dieser Stelle wurde es recht interessant, da die entsprechenden Quell-IPs für die verweigerten Verbindungen in keiner IP-Liste auftauchten, aber andererseits auch nicht im DHCP-Bereich lagen. Nach Rücksprache mit dem Kunden und etwas Nachforschung war die Situation klar: Zwei einfache USB-Device Server senden im Sekundentakt auf div. Ports Broadcastanfragen. Auch mittels Firmware-Upgrade oder rigider Beschränkung der unterstützten Protokolle ließen sich diese Geräte nicht beruhigen.
Warum es jetzt gerade auf diesem einen Server zu derartigen Folgeerscheinungen kam, kann ich mir nur damit erklären, dass dieser bereits ohne das Problem nahe seines RAM-Kapazitätslimits fuhr.

Das Problem ist nun: Wenn sich die Quelle nicht abstellen lässt (unter der Kunde den Betrieb der Geräte weiterhin wünscht), bleibt hier nur die Variante, das Logging zu entsprechend zu deaktivieren. Eine weitere Alternative wäre, die entsprechenden Geräte in ein separates Netzwerksegment auszulagern (z.B. per VLAN) und nur den Endgeräten Zugriff zu ermöglichen, die diesen auch benötigen. Dazu benötigt es aber entsprechendes Netzwerkquipment und entsprechenden Konfigurationsaufwand. Deshalb war hier die eher einfachere Lösung gefragt.

Diese lässt sich u.a. über das Kommandozeilentool auditpol umsetzen.
Mittels auditpol /get /category:* lassen sich die aktuellen Einstellungen auslesen.

Alternativ kann man die Einstellungen mittels auditpol /backup /file:c:\temp\dateiname.csv auch in eine csv-Datei exportieren und dort ein Einstellungen ablesen.

Aus dem Ereignisprotokolleintrag lässt sich schnell herleiten, dass der anzupassende Filter der vom Typ Verworfene Pakete ist.
Um die Einstellungen anzupassen (in diesem Fall: um den entsprechenden Filter zu deaktivieren) ruft man schließlich
auditpol /set /subcategory:“Filterplattform: Verworfene Pakete“ /success:disable /failure:disable auf. Anschließend kann man die Einstellungen direkt kontrollieren und ich stellte auch fest, dass die ständigen Sicherheitsmeldungen sofort aufhörten.

Problem gelöst ?

Nicht ganz, denn das Problem trat nach einiger Zeit wieder auf.
Beim ersten Vorkommen glaubte ich noch an einen Bedienfehler meinerseits, beim zweiten Mal konnte ich das jedoch ausschließen und forschte nochmals genauer nach.

Zunächst glaube ich an eine GPO, die die Einstellungen überschreibt, aber ich konnte keine finden.
Allerdings wurde nach jeder Anwendung der GPOs mittels gpupdate /force die Einstellungen zurückgesetzt, also schaute ich nochmals nach und beim zweiten Blick konnte ich das Problem schließlich eingrenzen:

Es gibt zwei unabhängig voneinander existierende Überwachungsrichtlinien, die sich nicht zwangsläufig so verhalten, wie man es erwartet: Genaueres beschreibt folgender Artikel: Technet: Getting the Effective Audit Policy in Windows 7 and 2008 R2 .

In unserem Fall existierte eine alte Überwachungsrichtlinie, die alle Filter auf Fehlerüberwachung setzt. Da diese sich woanders befindet als die, ab Windows Server 2008 bzw. Vista vorhandene, erweiterte Überwachungsrichtlinie (die in diesem Fall auf nicht konfiguriert stand, ließ ich mich täuschen.

Ich entschied mich dafür, in der GPO die Objektverwaltung auf nicht konfiguriert zu setzen und anschließend auf dem System mit dem Speicherproblem den Filter mittels auditpol zu deaktivieren. Da sich noch einige Altsysteme (Prä-2008) in der Umgebung befinden und keine externe Monitoringlösung im Einsatz ist, mittels der die Protokolle ausgewertet werden, halte ich das für die einfachste Lösung. Damit ist bleibt die Überwachung auch bei bereits vorhandenen Servern aktiv.

Einen Blog am Leben zu erhalten kostet Zeit und Geld. Da ich auf meiner Seite weder Werbung einbinde, noch andersweitige Zuwendungen erhalte, freue ich mich über jede kleine Spende. Einfach und unkompliziert geht das über PayPalMe. Du unterstützt damit diesen Blog. Vielen Dank.