7
SBS 2003 Nicht nachvollziehbare Fehler im Sicherheitsprotokoll Security Event-ID 529
Liebe Administratoren,
auf einem Kundeserver beobachte ich bereits seit ca. einem Monat den folgenden Fehler im Sicherheitsprotokoll (wird täglich per Serverleistungsbericht zugesendet).
Quelle: Security
Ereignis-ID: 529
Letztes Vorkommen: 13.08.2012 17:55
Vorkommnisse insgesamt: 24.151*
Fehlgeschlagene Anmeldung:
Grund: Unbekannter Benutzername oder falsches Kennwort
Benutzername: `‚
J + ‚
Anmeldetyp: 3
Anmeldevorgang: Advapi
Authentifizierungspaket: Negotiate
Name der Arbeitsstation: <meinServer>
Aufruferbenutzername: NETZWERKDIENST
Aufruferdomäne: NT-AUTORITÄT
Aufruferanmeldekennung: (0x0,0x3E4)
Aufruferprozesskennung: 3616
Übertragene Dienste: -
Quellnetzwerkadresse: -
Quellport: -
In älteren Serverleistungsberichten tauchte dieser Fehler pro Tag ca. 5-10 mal auf.
Was mich hier irritiert ist das extrem häufige Vorkommen: 24.151.
Der Benutzername ist mir absolut fremd.
Unter den angegebenen Aufrufermeldekennung und Aufruferprozesskennung finde ich leider keine Hinweise.
Da ein Abgleich mit dem ISA-Server-Log ebenfalls keine Hinweise auf einen Zugriff von Extern schließen lässt, kann es ja nur ein Dienst/Programm auf dem SBS oder einer der internen XP-Clients sein.
Da die Quellnetzwerkadresse und der Quellport aber nicht angegeben sind, komme ich an dieser Stelle auch nicht weiter.
Auffalden ist zudem, dass das jeweils letzte Vormommen immer in den Betriebszeiten der Firma liegt.
Allerdings kann ich kein Muster der zwischen dem letzten Vorkommens des Fehlers und der Abmeldung eines PC im Netzwerk erkennen.
Der Server ist folgendermaßen konfiguriert:
- MAXDATA Platinum Server
- 1 x XEON E5405
- 4 GB RAM
- SBS 2003 SP2 Premium mit 35 Usern
- ISA 2004
- Trend Micro WFBS Advanced 7.0 SP1
- Backup Exec 12
Im Netzwerk befinden sich 33 XP SP3-PCs, sowie ein Server 2008 als Terminalserver und ein Server 2008 als SQL-Server (SQL-Server 2008).
Ich stehe leider total auf dem Schlauch, zudem im letzten halben Jahr - mal abgesehen von den Windows Updates - keine Änderungen an der Serverkonfiguration vorgenommen wurden.
Hat vielleicht jemand noch einen Ansatz, wie ich hier weiter auf die Suche/Fehlerbehebung gehen kann?
Vielen Dank im Vorraus.
Chris
auf einem Kundeserver beobachte ich bereits seit ca. einem Monat den folgenden Fehler im Sicherheitsprotokoll (wird täglich per Serverleistungsbericht zugesendet).
Quelle: Security
Ereignis-ID: 529
Letztes Vorkommen: 13.08.2012 17:55
Vorkommnisse insgesamt: 24.151*
Fehlgeschlagene Anmeldung:
Grund: Unbekannter Benutzername oder falsches Kennwort
Benutzername: `‚
J + ‚
0‚
Domäne: <meineDomain>.localAnmeldetyp: 3
Anmeldevorgang: Advapi
Authentifizierungspaket: Negotiate
Name der Arbeitsstation: <meinServer>
Aufruferbenutzername: NETZWERKDIENST
Aufruferdomäne: NT-AUTORITÄT
Aufruferanmeldekennung: (0x0,0x3E4)
Aufruferprozesskennung: 3616
Übertragene Dienste: -
Quellnetzwerkadresse: -
Quellport: -
In älteren Serverleistungsberichten tauchte dieser Fehler pro Tag ca. 5-10 mal auf.
Was mich hier irritiert ist das extrem häufige Vorkommen: 24.151.
Der Benutzername ist mir absolut fremd.
Unter den angegebenen Aufrufermeldekennung und Aufruferprozesskennung finde ich leider keine Hinweise.
Da ein Abgleich mit dem ISA-Server-Log ebenfalls keine Hinweise auf einen Zugriff von Extern schließen lässt, kann es ja nur ein Dienst/Programm auf dem SBS oder einer der internen XP-Clients sein.
Da die Quellnetzwerkadresse und der Quellport aber nicht angegeben sind, komme ich an dieser Stelle auch nicht weiter.
Auffalden ist zudem, dass das jeweils letzte Vormommen immer in den Betriebszeiten der Firma liegt.
Allerdings kann ich kein Muster der zwischen dem letzten Vorkommens des Fehlers und der Abmeldung eines PC im Netzwerk erkennen.
Der Server ist folgendermaßen konfiguriert:
- MAXDATA Platinum Server
- 1 x XEON E5405
- 4 GB RAM
- SBS 2003 SP2 Premium mit 35 Usern
- ISA 2004
- Trend Micro WFBS Advanced 7.0 SP1
- Backup Exec 12
Im Netzwerk befinden sich 33 XP SP3-PCs, sowie ein Server 2008 als Terminalserver und ein Server 2008 als SQL-Server (SQL-Server 2008).
Ich stehe leider total auf dem Schlauch, zudem im letzten halben Jahr - mal abgesehen von den Windows Updates - keine Änderungen an der Serverkonfiguration vorgenommen wurden.
Hat vielleicht jemand noch einen Ansatz, wie ich hier weiter auf die Suche/Fehlerbehebung gehen kann?
Vielen Dank im Vorraus.
Chris
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 189575
Url: https://administrator.de/contentid/189575
Ausgedruckt am: 18.11.2024 um 09:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
da versucht vermutlich jemand ne Brutforceatakce über SMTP zu fahren.
Aus dem internen Netz würde IP und Rechnername aufgelöst werden.
Wenn Du ne Firewall hast, dann schau in den Logs nach, ob Du die IP von ders kommt blocken kannst.
Ich hoffe Du hast eine Sperrung der Benutzerkonten bei zu oft falscher Passworteingabe aktiv, für den Fall, das der Angriefer mit echten Benutzernamen kommt oder zufällig trifft.
Sind die SQL-Server aus dem Internet erreichbar, bzw. eine Webseite über die Daten von dort ausgelesen werden?
Gruß
Chonta
da versucht vermutlich jemand ne Brutforceatakce über SMTP zu fahren.
Aus dem internen Netz würde IP und Rechnername aufgelöst werden.
Wenn Du ne Firewall hast, dann schau in den Logs nach, ob Du die IP von ders kommt blocken kannst.
Ich hoffe Du hast eine Sperrung der Benutzerkonten bei zu oft falscher Passworteingabe aktiv, für den Fall, das der Angriefer mit echten Benutzernamen kommt oder zufällig trifft.
Sind die SQL-Server aus dem Internet erreichbar, bzw. eine Webseite über die Daten von dort ausgelesen werden?
Gruß
Chonta
Bruteforce mit immer denselben Benutzereinstellungen? Wenn das immer so nett läuft, könnte man sich die firewall sparen ...
LG, Thomas
LG, Thomas
Hallo,
die 24K versuche sind 100% nicht immer der selbe Benutzername und auf jedenfall immer mit anderen Passwort. Aber wer will jetzt jeden einzelnen Eintrag durchgehen?
Auf jedenfall hat da einer die IP über den MX Eintrag rausbekommenund und versucht nun auf den Ports die der Server als Mailserver zur Verfügung stellt zugriff zu bekommen.
Es werden Benutzernamen wie test, Administrator, admin, webmaster, test, root und Allerweltsnamen auftauchen.
Jehnachdem ob es in echt Benutzerkonten mit Mailadresse gibt die abgefragt werden und anhängig der Passwortlänge, kann es Probleme geben.
Aber höchstwarscheinlich passiert da nix.
Dennoch über die Firewall die IP ausfindig machen und blocken, und ggf über einen Logserver nachdenken, wenn der Router nicht soviel loggen kann und an einen Linuxserver Syslog senden kann.
Gruß
Chonta
die 24K versuche sind 100% nicht immer der selbe Benutzername und auf jedenfall immer mit anderen Passwort. Aber wer will jetzt jeden einzelnen Eintrag durchgehen?
Auf jedenfall hat da einer die IP über den MX Eintrag rausbekommenund und versucht nun auf den Ports die der Server als Mailserver zur Verfügung stellt zugriff zu bekommen.
Es werden Benutzernamen wie test, Administrator, admin, webmaster, test, root und Allerweltsnamen auftauchen.
Jehnachdem ob es in echt Benutzerkonten mit Mailadresse gibt die abgefragt werden und anhängig der Passwortlänge, kann es Probleme geben.
Aber höchstwarscheinlich passiert da nix.
Dennoch über die Firewall die IP ausfindig machen und blocken, und ggf über einen Logserver nachdenken, wenn der Router nicht soviel loggen kann und an einen Linuxserver Syslog senden kann.
Gruß
Chonta
Hallo Chonta,
danke für Deine Ansätze.
Ich habe vom ISA alle eingehenden Verbindungen über zwei Tage protokollieren lassen und mit dem Sicherheitsprotokoll abgeglichen.
Es finden sich hier von zwei IP-Adressen (212.227.15.146 und 212.227.15.130) einige von der ISA verweigerte Verbindungen.
Der Quellport ist immer 25, die Zielports zwischen 1356 und 65405. Allerdings passen die letzten Protokolleinträge für die jeweiligen Tage nicht zusammen mit dem Zeitstempel des letzten Vorkommens im Sicherheitsprotokoll.
Was mich an dieser Stelle aber wundert ist die Tatsache, dass vor dem SBS noch eine Fritz!Box 7170 vorgeschaltet ist, auf der nur ein Portforwarding für die Ports 80, 443 und 1723 eingerichtet ist. Wie kann es denn sein, dass diese - zwar von der ISA geblockten - Zugriffe überhaupt hier ankommen?
Die Sperrung der Nutzerkonten ist selbstverständlich aktiv, doch der Benutzername aus dem Protokoll (`‚J + ‚>0‚) existiert in der Domäne nicht. Hier finde ich nur ansonsten nur Benutzernamen mit Ihren passenden Arbeitsstationen, die auch tatsächlich existieren.
Werde im nächsten Schritt mal schauen, ob und wie ich die Fritz!Box Firewall dazu bringen kann, mir etwas mehr Daten zu liefern.
Viele Grüße
Christopher
EDIT:
Zum Thema MX-Eintrag: den gibt es nicht.
Der Router verfügt zwar über eine statische IP, die E-Mails werden mit PopCon von 1und1 abgeholt (Sammelpostfach) und via Exchange SMTP-Connector auch über 1und1 versendet.
EDIT_2:
Die beiden oben genannten IP-Adressen sind von 1und1 - auth.smtp.kundenserver.de. Also Entwarnung an dieser Stelle.
danke für Deine Ansätze.
Ich habe vom ISA alle eingehenden Verbindungen über zwei Tage protokollieren lassen und mit dem Sicherheitsprotokoll abgeglichen.
Es finden sich hier von zwei IP-Adressen (212.227.15.146 und 212.227.15.130) einige von der ISA verweigerte Verbindungen.
Der Quellport ist immer 25, die Zielports zwischen 1356 und 65405. Allerdings passen die letzten Protokolleinträge für die jeweiligen Tage nicht zusammen mit dem Zeitstempel des letzten Vorkommens im Sicherheitsprotokoll.
Was mich an dieser Stelle aber wundert ist die Tatsache, dass vor dem SBS noch eine Fritz!Box 7170 vorgeschaltet ist, auf der nur ein Portforwarding für die Ports 80, 443 und 1723 eingerichtet ist. Wie kann es denn sein, dass diese - zwar von der ISA geblockten - Zugriffe überhaupt hier ankommen?
Die Sperrung der Nutzerkonten ist selbstverständlich aktiv, doch der Benutzername aus dem Protokoll (`‚J + ‚>0‚) existiert in der Domäne nicht. Hier finde ich nur ansonsten nur Benutzernamen mit Ihren passenden Arbeitsstationen, die auch tatsächlich existieren.
Werde im nächsten Schritt mal schauen, ob und wie ich die Fritz!Box Firewall dazu bringen kann, mir etwas mehr Daten zu liefern.
Viele Grüße
Christopher
EDIT:
Zum Thema MX-Eintrag: den gibt es nicht.
Der Router verfügt zwar über eine statische IP, die E-Mails werden mit PopCon von 1und1 abgeholt (Sammelpostfach) und via Exchange SMTP-Connector auch über 1und1 versendet.
EDIT_2:
Die beiden oben genannten IP-Adressen sind von 1und1 - auth.smtp.kundenserver.de. Also Entwarnung an dieser Stelle.
Hallo,
es gibt immer einen Zeitversatz von einigen Sekunden zwischen dem ISA Log und dem Logeintrag auf dem Server bzw. zwischen Firewall Logeintrag und Serverlogeintrag.
Mal so gefragt, wird OWA verwendet? und gibt es dafür auch einen öffentlichen DNS-Namen?
Schonmal versucht dich über port 25 mit eurer Festen IP zu verbinden?
Es könnte auch was mit SQL zu tun haben, verzeichnen die SQL-Server irgendetwas komisches?
Denn wenn die 24k Versuche immer nur `‚J + ‚>0‚ ...
Gruß
Chonta
es gibt immer einen Zeitversatz von einigen Sekunden zwischen dem ISA Log und dem Logeintrag auf dem Server bzw. zwischen Firewall Logeintrag und Serverlogeintrag.
Mal so gefragt, wird OWA verwendet? und gibt es dafür auch einen öffentlichen DNS-Namen?
Schonmal versucht dich über port 25 mit eurer Festen IP zu verbinden?
Es könnte auch was mit SQL zu tun haben, verzeichnen die SQL-Server irgendetwas komisches?
Denn wenn die 24k Versuche immer nur `‚J + ‚>0‚ ...
Gruß
Chonta
Hallo,
ich werde heute Abend nochmal das ISA-Log anstoßen und das neue Protokoll dem aktuellen Sicherheitslog gegenüberstellen.
Ja, OWA wird leider verwendet. Der Kunde ist darauf angewiesen, da er nicht von überall eine VPN-Verbindung zum Terminalserver aufbauen kann. Auf einen öffentlichen DNS-Namen haben wir aber verzichtet. der Login erfolgt direkt über die IP-Adresse/Exchange.
Ein telnet auf die IP-Adresse des Kunden mit Port 25 liefert einen Verbindungsfehler. Im ISA-Log wird dieser Zugriff auch gar nicht protokolliert. Da scheint die Fritz!Box wohl vorher schon zuzumachen.
Die SQL-Server-Logs werde ich mir erst Ende der Woche zusammen mit dem eigenen SQL-Admin anschauen können.
Die Suche geht also weiter...
Viele Grüße
Christopher
ich werde heute Abend nochmal das ISA-Log anstoßen und das neue Protokoll dem aktuellen Sicherheitslog gegenüberstellen.
Ja, OWA wird leider verwendet. Der Kunde ist darauf angewiesen, da er nicht von überall eine VPN-Verbindung zum Terminalserver aufbauen kann. Auf einen öffentlichen DNS-Namen haben wir aber verzichtet. der Login erfolgt direkt über die IP-Adresse/Exchange.
Ein telnet auf die IP-Adresse des Kunden mit Port 25 liefert einen Verbindungsfehler. Im ISA-Log wird dieser Zugriff auch gar nicht protokolliert. Da scheint die Fritz!Box wohl vorher schon zuzumachen.
Die SQL-Server-Logs werde ich mir erst Ende der Woche zusammen mit dem eigenen SQL-Admin anschauen können.
Die Suche geht also weiter...
Viele Grüße
Christopher
