Inhalt:

Um in ein fremdes System einzudringen gibt es (fast) undendlich viele Möglichkeiten:

• man kann Systemdienste nutzen. Z.B. mounten eines Homeverzeichnisses eines regulären Benutzers auf dem Zielsystem (rpc), über NFS (ein bereits gehackter Rechner hat das Homeverzeichnis eines andereren Rechners (=neues Ziel) gemounted), usw.
  Gegenmittel: Keine Dienste verwenden, die nicht unbedingt zum Serverbetrieb gebraucht werden. Alle Dienste entsprechend konfigurieren.
• man errät einfach Benutzer und Passwort. In Unternehmen gibt es in der Regel Konventionen fuer login-Namen, diesen kann man also leicht erraten wenn man den Namen eines Mitarbeiters kennt. Wenn der Mitarbeiter dann noch ein unsicheres Passwort verwendet...
  Es ist erschreckend wie oft man auf default oder mit der Login-Kennung identische Passwörter vorfindet. Ebenfalls erschreckend erfolgreich ist sog. "social engineering".
• man kann ein beliebtes Programm auf irgendeiner (möglicherweise ebenfalls gehackten) Seite zum download anbieten, natürlich nachdem man es mit einem Trojaner versehen hat, und darauf hoffen das es jemand mit root-Rechten ausführt.
• man nutzt Schwächen einzelner Dienste aus (exploits), entweder um direkt eine shell (z.B. sshd) zu bekommen oder indirekt durch erlangen von /etc/passwd und /etc/shadow (ftpd, httpd) in Verbindung mit einem Passwort- cracker usw.
  Gegenmittel: faktisch keine. Einzige (unsichere) Methode: updaten bis der Arzt kommt.

Ziel ist es in jedem Falle, root-Rechte auf dem Zielrechner zu erlangen. Sobald man root-Rechte hat erfolgt der zweite Teil der Attacke: Die Verschleierung der eigenen Anwesenheit. Dazu werden alle Logfileeinträge, die auf das Eindringen hinweisen, entfernt. Weiterhin werden Systemprogramme (oder sogar der Kernel selbst) manipuliert, um eigene Aktivitäten zu verstecken.

Der nächste Schritt hängt von der Motivation des Hackers ab. Spätestens an dieser Stelle muß man sich also fragen, warum ein Hacker überhaupt versucht in ein fremdes System einzudringen. Hauptsächlich dürften dafür folgende Gründe in Frage kommen:

• Aufsetzen eigener Dienste, z.B. zum verteilen illegaler Software o.ä.
• Beschaffung von Informationen, (Industrie-) Spionage. (eher selten)

• ls, find, du : zeigen/zählen nicht die Dateien des Angreifers
• ps, top, pidof: zeigen nicht die Prozesse des Angreifers
• netstat : zeigt nicht den Netzwerkverkehr des Angreifers
• killall : beendet nicht die Prozesse des Angreifers
• ifconfig : wird nicht das PROMISC-flag anzeigen, wenn ein sniffer läuft
• crontab : wird den Eintrag des Angreifers verstecken. Viele rootkits verstecken die Crontab (und andere Dateien!) unterhalb von /dev
• tcpd : wird nicht konfigurierte Verbindungen mitloggen.
• syslogd : s. tcpd

Der Tausch dient der Verschleierung der eigenen Anwesenheit, der Installation zusaetzlicher Hintertüren ins System und i.d.R. der Installation eines Netzwerksniffers um weitere Zugangsdaten zu anderen Rechner zu erlangen. Man kann also i.A. den Einbruch gar nicht feststellen, da alle Hilfsmittel, mit denen man einen erfolgreichen Einbruch entdecken könnte, ausgetauscht wurden.

In der Regel wird man Unstimmigkeiten entdecken. Z.B. große Lücken in Logfiles, nicht erklärbarer Platzverbrauch auf den Festplatten, der Rechner lauscht auf ungewöhnlichen Ports usw.

  int init_new_sys_ls ()
  {
  	old_sys_ls = kernel_sprung_tab [sys_ls];
	kernel_sprung_tab [sys_ls] = new_sys_ls;
  }

  int new_sys_ls ()
  {
	if (VerzeichnisEintrag == "GeheimesHackerProg")
		return;
	return (old_sys_ls);
  }

An dieser Stelle möge der Leser sich gewiss werden, das wirklich alle Vorgänge auf einem Computer über den Kernel abgewickelt werden. Ein Modul soll geladen werden? sys_load_module. Alle geladenen Module sollen aufgelistet werden? sys_list_modules. Alle Prozesse sollen angezeigt werden? sys_list_procs.
Der Hacker kann sogar Teile einer (Konfigurations-) Datei vertecken. Der Hacker muss dafür sorgen, das sein Modul auch nach einem Neustart wieder geladen wird. Deshalb wird er, unter Unix-Systemen, in einem der zahlreichen Initskripte (rc-Dateien) eine entsprechende Anweisung eintragen. Durch Ausblenden von Dateiinhalten kann der Administrator diesen Eintrag jedoch nicht sehen.

An dieser Stelle wird deutlich, wie weitreichend die Manipulationsmöglichkeiten der Hacker mit Kernelmodulen sind. Selbst Intrusion Detection Systeme (IDS) versagen wenn Kernelmodule im Spiel sind. Natürlich muss der Hacker root-Rechte auf dem gehackten Rechner besitzen und dabei noch berücksichtigen, daß er ja selbst auf seine Dateien zugreifen möchte und muss deshalb noch Hintertüren einbauen um die Tarnung umgehen zu können. Das soll uns an dieser Stelle aber nicht weiter interressieren, Möglichkeiten dafür gibt es sprichwörtlich wie Sand am Meer.
Von derartigen Kernelmodulen findet man jede Menge anwedungsfertig im Internet für alle gängigen Betriebssysteme, wie z.B. BSD, Linux, Solaris aber auch für alle Windows Varianten.
Wenn ein wirklich gut geschriebenes (und gut konfiguriertes) Kernelmodul dieser Art installiert wurde, hat der Administrator praktisch keine Möglichkeit mehr den Hacker überhaupt zu bemerken. Allenfalls an sekundären Merkmalen, wie ungewönlichen Netzverkehr.

Nein, ist es nicht. In aller Regel befinden sich im selben Netzsegment mehrere Rechner und der Angreifer kann alle Verbindungen mit diesen mitlauschen. Sie verwenden ssh? Kann man z.B. mit einer "man in the middle attack" (MITM) und DSniff mitlauschen. Sie verwenden Switches und dehalb kann ein anderer (gehackter) Rechner andere Verbindungen nicht "sehen"? Irrtum, Switche lassen sich z.B. mit ettercap austricksen.
Durch das mitlauschen der ssh-Verbindungen muss der Hacker noch nicht einmal die anderen Rechner angreifen. Es reicht eine Weile zuzuhören, denn es werden alle Logins mit ihren Passwörtern mitprotokolliert (DSniff). Solange also noch ein gehackter Rechner in diesem Netzsegment vorhanden ist, muss man davon ausgehen dass auch alle anderen gehackt sind, auch wenn dort keine Anzeichen zu finden sind. Der Hacker hat ja einen regulären Zugang auf diese.

• vollständiger Portscan So kann man offene Ports finden, die eigentlich nicht auf sein sollten
• durchstöbern aller Logfiles Sind ungewöhnliche Einträge oder große Lücken vorhanden?
• Man sollte immer für das jeweilige Betriebssystem (statisch gelinkte!) Kopien aller wichtigen Kommandos haben, diese auf den verdächtigen Rechner kopieren und mit der Ausgabe der installierten Versionen vergleichen. Statisch gelinkt sollten sie sein, weil geschickte Hacker selbst die system libraries austauschen. Das scheinbar sichere Programm arbeitet dann mit korrumpierten Routinen und macht ebenfalls gefälschte Ausgaben.
• genaues anschauen der /etc/inetd.conf. Der sollte eigentlich deaktiviert sein aber ein rootkit kann den reaktivieren. Ein möglicherweise getauschtes ps verschleiert daß der läuft. In der Konfiguration kann man evtl. einen zusätzlich geöffneten Port sehen.
• Mit geeigneten Programmen überprüfen, auf welchen Ports der Rechner lauscht.
• läuft ein sniffer? 'ifconfig -a' aufrufen. Wird ein Interface mit dem PROMISC flag angezeigt, läuft ein sniffer. Wenn kein Interface mit diesem Flag angezeigt wird: tcpdump aufrufen (ein Interface auf PROMISC setzten) und nochmal 'ifconfig -a' aufrufen. Wird PROMISC angezeigt?
• sehr nützlich: die Ausgabe von lsof (list open files)
• aufspüren aller laufenden Prozesse durch das /proc Verzeichnis. Stimmen die Anzahl der dort gezeigten Prozesse mit der Ausgabe von 'ps' überein?
• Vergleich der Ausgabe von 'ls' mit der Ausgabe vn 'echo *'. Falls nur ls ausgetauscht wurde kann man so versteckte Dateien/Verzeichnisse sehen
• Aufspüren von LKMs: (funktioniert nur bei Linux, weil andere Unixe kein so auskunftfreudiges /proc Verzeichnis haben) manchmal (selten) tauchen die LKMs bei der Ausgabe von lsmod auf. Viel warscheinlicher sieht man die LKMs beim betrachten von /proc/ksyms. Tauchen dort unbekannte Symbolnamen auf? Durchstöbern der Initscripte. Werden dort unbekannte Module geladen? Manchmal hilft ein neustart, um die LKMs loszuwerden. Sollte das nicht helfen, müßen die LKMs in einen Initskript gestartet werden -> also danach suchen.

• Man sollte den Rechner sofort vom Netz nehmen, wenn möglich auch das ganze Netzsegment.
• Man sollte keinem system-utillity vertrauen, bis sie wieder neu installiert wurden!
• Da man nicht sicher sein kann wirklich alle Teile des rootkits erkannt zu haben, und der Eindringling möglicherweise zusätzliche Trojaner installiert hat, steht eine komplette Neuinstallation an.
• vor der Neuinstallation alle Logfiles sichern und analysieren.
• falls der Rechner auf einen unerwünschten Port lauscht -> einsetzen eines Portloggers. Vielleicht meldet sich der Hacker dort nochmal.
• im Falle gefundener (IRC-) bots/bouncern: analysieren der config files und evtl. Hacker im IRC aufspüren
• Wiederstehe der Versuchung von einem Backup zu (re-) installieren, der Angriff könnte schon vor der Erstellung desselben erfolgt sein.
• Wenn man weiß wann der Rechner gehackt wurde, eine Liste aller seit dem Stichtag neuerer Dateien erstellen.
• Man muß davon ausgehen, das der Eindringling den gesamten Netzwerkverkehr mitgelauscht hat. Also auch möglicherweise alle Benutzernamen/Passwörter die in diesem Netzbereich verwendet wurden (z.B. ftp). Also alle Passwörter auf allen Rechnern (die von diesem Rechner erreichbar sind) änderen und diese Rechner ebenfalls nach Spuren eines Hacks überprüfen.

• keinen C-Compiler installieren. Auch wenn das nur eine recht kurzsichtige Massnahme ist, erschwert sie die Installation eines rootkits und lokaler Exploits ungemein.
• Installation eines IDS, wie tripwire oder AIDE (Checksummen über Systemdateien) Aber nicht darauf vertrauen, auch dagegen kann ein Hacker erfolgreich vorgehen, z.B. über LKMs.
• wenn möglich keinen Prozess als root laufen lassen. Auf so viele Prozesse verzichten wie möglich.
• remote Zugriff (z.B. über ssh) nur von bekannten Netzen zulassen (firewall)
• syslogd konfigurieren, damit auf einen remote-Rechner geloggt wird
• Mitloggen des Netzwerkverkehrs (evtl. auch auf nicht geöffneten Ports)