Spurensuche in Logfiles

"Gute Idee", stimmte Hubert zu. Firebox geroutet ist, kann jemand von innen immer noch Zugriff auf die Server nehmen."

"Hubert", sagte er,

Hubert lachte. "Gut, es ist vermutlich niemand von uns. Andererseits sind Dieter und seine Leute intelligent genug, um so etwas zu bewerkstelligen."

"Die habe ich ganz vergessen", gab Andi zu. "Aber wenn wir den externen Zugang sperren und dann immer noch Probleme haben, wissen wir mit Sicherheit, dass das Problem im Haus liegt."

"Einverstanden""Nehmen wir uns also zuerst die FirewallWatchGuard Management-Station nutzte. Er gab Policy ManagerHTTP-ServiceHTTP-DienstSSL-Verbindung

"Cool", meinte Hubert. "Nun haben wir zwar den Webserver isoliert, aber er befindet sich noch immer in dem Zustand, in dem er beim Hackerangriff war. Sehen wir uns mal die SQL-Server-Protokolle an."Putty, seinen frei nutzbaren SSH Client, und gab die IP-Adresse des MySQL-Servers ein. Nachdem er seine Zugangsdaten eingegeben hatte, verband ihn Putty mit seinem SQL-Server. In einem kleinen Fenster erschien eine Linux-Eingabeaufforderung. Da er wusste, wo sich die SQL-Fehlerprotokolldatei befand, gab er den Pfad ein:

vi /var/log/mysql/mysql.err

"Wann war der Angriff?", wollte Andi wissen.

Die Protokolldatei begann:

040524 23:58:43 mysqld started
040524 23:58:43 InnoDB started
/usr/sbin/mysqld: ready for connection

"Hmm", machte er.