Ein beharrlicher und blinder „Panda“

Wenn man seine Daten und seine Rechnersysteme vor Schädlingen, Schadprogrammen und hölzernen Pferden sch?tzen möchte, dann muss mindestens ein Virenschutzprogramm – ein Antivirusprogramm – auf den jeweiligen möglichen Opfern seine Arbeit verrichten.

Das ist auch bei einem speziellen Kunden der Fall – nur leider hat hat ihm das nichts gen?tzt. Nicht deswegen, weil sein Server mit Viren bombardiert wurde, sondern weil sein eingesetztes Antivirenprogramm mit dem knuddeligen Pandakopf von jetzt auf gleich erblindete und massiven destruktiven Murks baute. Der Kunde meldete sich bei uns, weil er sich nicht mehr an seinem Server (Microsoft Small Business Server 2003) anmelden konnte. Nach Eingabe des Administratorkennwortes wurde er an- und umgehend darauf wieder abgemeldet. Ebenso wurden keine Mails mehr abgerufen und die auf dem Server bereitgestellte Online-Banking Software verweigerte ihren Dienst.

Was ist passiert und wie wurde das Ganze gelöst?

Auf dem Server selbst lief der Panda AdminSecure Server. Dieser ist f?r den zentralen Download aller Updates, sowie f?r die Verwaltung und Aktualisierung der angemeldeten Arbeitsstationen und Server verantwortlich. In der Nacht zum 26.09.2008 wurden Updates sowohl von Panda, als auch die automatischen Updates von Microsoft heruntergeladen und installiert. Auf Grund einer älteren, aber bis dato funktionierenden AdminSecure Version, trat dann die beschriebene Katastrophe ein. Die durch die Microsoft-Updates geänderten Dateien nebst geänderten Dateisignaturen veranlassten den aktualisierten Panda dazu vehement und beharrlich diese Dateien zu blockieren und auf Grund eines False Positive (Fehlalarm in der Erkennung) versuchte Panda diese auch gleich zu löschen. Windows versuchte sich (gemäß Logdatei) auch mittels des Dateischutzes zu wehren, musste aber nach unzähligen Neulöschungen seiner wiederhergestellten Dateien geschlagen geben.

Panda war bei Nachfrage sich des Problems bewusst (hatten mehrere Anfragen diesbez?glich erhalten) und hatte auch die dazugehörige Datenbank und die Logdatei des betroffenen Servers von mir erhalten (?ber den Weg siehe weiterer Text). Der ganze Fall dort eskalierte bis zum First-Level-Support und man versprach (via Mail und Telefon) am 30.09. dem Problem nachzugehen und eine Lösung zu generieren.

Insgesamt wurden ?ber 100 systemrelevante Dateien von Windows als schädlingsbehaftet gedeutet und eliminiert, nebst DLL-Dateien f?r die Netzwerkverwaltung, Anmeldung (msgina.dll), POP3 Connector und viele weitere ebenso.

Das größte Problem bestand darin, das System wieder lauffähig zu machen, da der Kunde eine Neuinstallation f?r sich ausschloss (Zeitaufwand). Die Datensicherung war lediglich eine Datensicherung und konnte nicht zur Systemwiederherstellung genutzt werden. Ebenso war die letzte Sicherung schon zu teilen mit fehlenden Windows-Dateien gesegnet – sprich die letzte nutzbare Sicherung war nach dem ganzen Vorfall.

Der Zugriff lokal oder via RDP war wie bereits geschrieben nicht möglich, aber ?ber das Netzwerk konnte man noch auf die Freigaben zugreifen. Zum Gl?ck funktionierten auch die C$ und D$ Freigaben (versteckte Freigaben auf die einzelnen Volumes). Ebenso konnte man mittels der Computerverwaltung von einer Arbeitsstation aus remote auf die Computerverwaltung des Servers zugreifen. Somit war die Grundlage gegeben weiter an der Lösung des Problems arbeiten zu können.

Hierzu wurden alle Dienste (Mail, Panda usw.) remote (Computerverwaltung) deaktiviert und im ersten Schritt der Ordner von „Windows“ und „Programme“ mit Hilfe der Datensicherung wieder aufgef?llt.  Nur die fehlenden Dateien wurden geschrieben, aber keine ?berschrieben. Die restlichen fehlenden Dateien, welche nicht in der Sicherung vorhanden waren, konnten wir mit Hilfe einer bei uns vorhandenen SBS 2003 Installation (gleicher Service Pack Stand) zur?cksichern.

Das An- und sofortige Abmelden ließ sich durch das Einspielen der UserInit.exe beheben – diese war ebenso nicht mehr existent. Zusätzlich konnten damit SBS-spezifische Programme bzw. deren Dateien (POP3 Connector) ebenfalls wieder funktionst?chtig gemacht werden.

Es bestand keine Grundlage oder Sicherheit daf?r, dass dieses Lösungsverfahren funktionierte – aber es tat es dennoch. Wir konnten uns am System wieder anmelden, installierten die aktuelle Version des Panda AdminSecure und alle Windows-Updates, testeten alle SBS Funktionalitäten und konnten somit dem Kunden sein System wieder aushändigen – zur Freude des Kunden.

Ein Dank gilt an den/die Entwickler vom Total Commander, deren Synchronisierungsfunktion sehr hilfreich f?r diesen Vorgang war.

Apropos: Auf einen Lösungsvorschlag von Panda warte ich immer noch – sonst eskaliere ich.

Das könnte Dich auch interessieren...

1 Antwort

  1. Marcus sagt:

    Der TotalCommander ist ja auch DAS Tool überhaupt! Ich weiss garnicht mehr was ich ohne den machen würde. Nach Jahren als Shareware-Nutzung hab ich mir den neulich auch gekauft, der ist wirklich jeden Penny wert.
    Ich hab alle kostenlosen Derivate vom TC getestet, mit dem Original konnten alle nicht mithalten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.