Der vierte und letzte Teil erklärt, wie Sie spezielle Dienste in einer entsprechenden Umgebung sicher einsetzen können. Neben der Secure Shell (SSH) werden auch Anwendungen wie Dispaly-Manager, E-Mail, Nameserver-BIND und X-Anwendungen auf Sicherheitsaspekte durchleuchtet. Zusätzlich zeigt der Artikel, wie Sie ein System vor einem möglichen Einbruch schützen können und wie Sie sich nach einem Einbruch ins System verhalten sollten. Letzteres beinhaltet auch das Erkennen von so genannten Rootkits.
Die Artikelserie basiert auf dem Kapitel 14 des Standardwerks „Debian GNU/Linux Anwenderhandbuch für Einsteiger, Umsteiger und Fortgeschrittene“ von Frank Ronneburg aus dem Verlag Addison-Wesley. Sie können dieses über 750 Seiten starke Buch auch in unserem Buchshop bestellen oder als eBook herunterladen.
|
Teil 1 |
|
|
Teil 2 |
|
|
Teil 3 |
Weitere Details zur Maximierung der Systemsicherheit im Betrieb |
|
Teil 4 |
Sichere Dienste und weiterführende Sicherheitsmaßnahmen |
Secure Shell (SSH)
SSH sollte generell für alle Remote-Logins auf einem System eingesetzt werden. Wenn Sie noch telnetd einsetzen, so ändern Sie dies jetzt sofort. Heutzutage ist es sehr einfach, den Netzwerkverkehr mitzuschneiden und so an unverschlüsselte Benutzernamen und Passwörter zu gelangen. Die Verwendung von Programmen, die keine verschlüsselte Kommunikation erlauben, verbietet sich somit von selbst. Auch der Einsatz von hochwertigen Netzwerkkomponenten wie Switches erlaubt Angreifern das „Mitlauschen“ auf den angeschlossenen Ports! Die meisten Switches schalten bei zu hoher Last einfach das „Switching“ ab und arbeiten wie ein normaler Hub! Verlassen Sie sich nie auf diese Komponenten, sondern sorgen Sie selbst für Sicherheit! Das Paket ssh kann mit dem Kommando apt-get install ssh schnell und einfach installiert werden.
Nun sollten alle Benutzer angewiesen werden, ausschließlich ssh und keinesfalls telnet zu benutzen. Deinstallieren Sie telnet nach Möglichkeit. Auch sollte ein Login als Administrator unmöglich gemacht werden. Um Administrator-Rechte zu erlangen, können die Kommandos su oder besser sudo benutzt werden.
Der ssh-Daemon
Auch die Konfiguration des ssh-Daemons kann zur Erhöhung der Sicherheit noch verbessert werden. In der Datei /etc/ssh/sshd_config verbietet folgende Zeile einen Login via ssh als Administrator:
PermitRootLogin No
Dies verhindert, dass per Brute-Force-Angriff ein Login als Administrator möglich ist, da kein Login als Administrator erlaubt wird. Es sind nun zwei Login-Vorgänge notwendig (zunächst als Benutzer, dieser muss dann noch Administrator werden):
Listen 666
Wenn der Port, auf dem der ssh-Daemon läuft, verändert wird, so kann dieser einen potenziellen Angreifer auch etwas beschäftigen. Es stehen aber verschiedene Netzwerktools zur Verfügung, mit deren Hilfe schnell und einfach ermittelt werden kann, auf welchem Port ein Dienst läuft. Verwenden Sie hier nicht zu viel Ehrgeiz ...
PermitEmptyPasswords no
Leere Passwörter sollten ebenfalls verhindert werden.
AllowUsers alex bea fr
Mit dieser Option wird nur bestimmten Benutzern der Login via ssh erlaubt.
AllowGroups wheel admin
Gleichermaßen wird mit dieser Direktive nur bestimmten Gruppen der Zugriff per ssh erlaubt.
Benutzer- oder Gruppenzugriff
Um Benutzern oder Gruppen explizit den Zugriff zu verbieten, stehen die Optionen DenyUsers und DenyGroups zur Verfügung.
PasswordAuthentication no
Wird diese Option auf „no“ gesetzt, so ist der Login nur Benutzern gestattet, deren ssh-Key der Datei ~/.ssh/authorized_keys hinzugefügt wurde. Diese Einstellung ist sehr empfehlenswert! Bei Verwendung eines Keys wird das Passwort nicht mehr vom Client zum Server übermittelt. Die Autorisierung wird anhand eines Hash-Wertes geprüft, und der Client erhält lediglich die Freigabe für den Server – oder auch nicht.
Weiterhin ist der ssh-Daemon so einzustellen, dass ausschließlich das Protokoll der Version 2 verwendet wird. Die Protokollversion 1 ist nach aktuellem Kenntnisstand als angreifbar anzusehen und sollte nicht mehr verwendet werden.
Alle diese Optionen beziehen sich auf die Konfigurationsdateien von OpenSSH. Momentan sind drei ssh-Pakete im Umlauf: ssh1, ssh2 und OpenSSH, das vom OpenBSD-Team entwickelt wurde. OpenSSH ist eine komplett freie Implementation eines ssh-Daemons, die sowohl ssh1 als auch ssh2 unterstützt. Wenn das Paket „ssh“ installiert wird, so wird das Paket OpenSSH gewählt.
FTP_Server
Wenn auf dem System tatsächlich ein FTP-Server installiert werden muss, so ist sicherzustellen, dass die Benutzer sich in einer „chroot“-Umgebung bewegen. Diese holt den Benutzer in seinem Home-Verzeichnis gefangen; ansonsten könnte er sich frei im Dateisystem bewegen.
Mit der Option
DefaultRoot ~
im globalen Abschnitt der Datei /etc/proftpd.conf kann dies sichergestellt werden. Danach ist der Server mit /etc/init.d/proftpd restart von der Veränderung der Konfiguration zu unterrichten.
X-Anwendungen im Netz
Um X-Anwendungen von einem Server aus auf einem Client darzustellen, ist zunächst auf dem Client das Öffnen der Anwendung durch den Server zu erlauben. Vielfach ist zu lesen, dass dies durch das Kommando „xhost +“ geschieht. Dies ist auch prinzipiell nicht falsch, erlaubt jedoch jedem System den Zugriff auf das X-Display. Besser ist es, den Zugriff nur von den gewünschten Systemen aus zu erlauben, indem der entsprechende Rechnername dem Kommando als Option mitgegeben wird, also beispielsweise xhost +sushi.
Eine deutlich sicherere Lösung ist es allerdings, die komplette Sitzung über ssh – und damit verschlüsselt – zu tunneln. Dies erfolgt automatisch, wenn eine ssh-Verbindung zu einem System aufgebaut wird. Soll diese Funktion abgeschaltet werden, so ist die Option X11Forwarding in der ssh-Konfiguration anzupassen. In Zeiten von ssh sollte auf die Verwendung von xhost komplett verzichtet werden.
Wenn keinerlei Zugriff auf den X-Server von anderen Systemen im Netz erlaubt werden soll, so ist es das Sicherste, dies bereits beim Start von X zu verhindern, indem der TCP-Port 6000 deaktiviert wird. Wenn X über das Kommando startx gestartet wird, so kann dies mit startx -- -nolisten tcp geschehen.
Display-Manager
Wenn der Display-Manager (das Programm, das einen grafischen Login bereitstellt, beispielsweise XDM, KDM oder GDM) nur auf dem lokalen System benötigt wird, so ist sicherzustellen, dass XDMCP (X Display Manager Control Protocol) deaktiviert ist.
Wenn das Programm xdm benutzt wird, kann dies durch die Zeile DisplayManager.requestPort: 0
in der Datei /etc/X11/xdm/xdm-config geschehen.
Die XDMCP-Unterstützung ist bei der Grundinstallation aller Display Manager unter Debian deaktiviert.
Das Lesen beziehungsweise Empfangen von E-Mail mittels POP3 ist das am häufigsten eingesetzte Protokoll ohne Verschlüsselung. Unabhängig davon, ob POP3 oder IMAP als Protokoll verwendet wird – beide benutzen Benutzernamen und Passwörter im Klartext, und auch die Daten werden unverschlüsselt übertragen. Als Alternative kann auch hier ssh verwendet werden, falls ein Shell-Account auf dem Mail-Server vorhanden ist.
Mittels fetchmail kann über ssh eine verschlüsselte Verbindung aufgebaut werden; hierzu eine entsprechende ~/.fetchmailrc:
poll my-imap-mailserver.org via "localhost"
with proto IMAP port 1236
user "ref" there with password "hackme" is alex here warnings 3600
folders
.Mail/debian
preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref
my-imap-mailserver.org sleep 15 < /dev/null > /dev/null'
Die wichtigste Zeile ist der “preconnect“-Eintrag. Dieser startet eine ssh-Session und installiert einen Tunnel, der automatisch die Verbindungen zum IMAP-Server auf Port 1236 weiterreicht, verschlüsselt. Dies nur als ein Beispiel, normalerweise sind einfachere Konfigurationen ausreichend. Alternativ kann fetchmail auch mit SSL benutzt werden.
Wenn verschlüsselte IMAP- und POP3-Server zur Verfügung gestellt werden sollen, so ist das Paket stunnel zu installieren. Die Daemons müssen dann über stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd gestartet werden, wobei -l den gewünschten Daemon und -d den Port beschreibt. Die Option -p setzt das SSLZertifikat.
Mittlerweile sind auch POP- und IMAP-Server verfügbar, die über Verschlüsselungsfunktionen mittels SSL verfügen. Als Server-Programm für das POP-Protokoll wäre hier apop zu nennen.
Loghost – ein Server für Logdateien
Ein „Loghost“ ist ein zentraler Rechner, auf dem Daten aus dem Syslog-Daemon verschiedener Rechner gespeichert werden. Wenn ein Eindringling ein System geknackt hat, so ist es ihm unmöglich, die Spuren aus den Logdateien zu entfernen, außer er knackt auch noch den Loghost. Somit sollte speziell ein solcher Loghost gut abgesichert sein. Um ein System in einen Loghost umzuwandeln, muss lediglich der syslog-Daemon mit der Option -r gestartet werden. Natürlich muss aber auch auf allen Rechnern, die nun die Daten auf diesem Loghost abliefern sollen, eine Anpassung erfolgen. Auf diesen Systemen sind in der Datei /etc/syslog.conf Einträge in der folgenden Form hinzuzufügen:
<facility>.<level> @<loghost>
Das Feld <facility> kann dabei einen Werte authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp oder local1 bis local7 annehmen. Als <level> kann alert, crit, err, warning, notice oder info angegeben werden. Hinter dem Zeichen „@“ ist der Hostname des Loghosts anzugeben.
Wenn generell alle Einträge auf dem entfernten System protokolliert werden sollen, so führt folgende Zeile zum Erfolg:
*.* @loghost
Im Idealfall wird man die Logdateien sowohl auf dem lokalen System als auch auf dem Loghost speichern, um durch Vergleichen der Dateien schneller zu einem Ergebnis zu kommen. Weitere Informationen finden Sie in den Manpages zu syslog(3), syslogd(8) und syslog.conf(5).
BIND und Snort
Auf einem unveränderten System läuft der Nameserver BIND nach der Installation mit den Rechten des Benutzers und der Gruppe „root“. BIND kann sehr leicht umkonfiguriert werden, so dass der Dienst unter einem anderen Benutzerkonto läuft. Leider kann er dann nicht mehr automatisch neue Netzwerkgeräte erkennen, die während des laufenden Betriebs hinzugefügt wurden, beispielsweise eine PCMCIA-Netzwerkkarte in einem Notebook oder auch virtuelle Netzwerk-Devices.
In der Datei README.Debian des Nameservers finden Sie weitere Informationen darüber, wie Sie BIND unter einem anderen Benutzerkonto zum Laufen bringen können. Wenn möglich, sollten Sie darauf verzichten, BIND mit Administratorrechten zu benutzen.
Um BIND mit einer anderen Benutzer-ID zu starten, muss zunächst ein neuer Benutzer und eine entsprechende Gruppe angelegt werden. Es kann beispielsweise als Benutzername und Gruppe der Name „named“ benutzt werden.
Hierzu sind folgende Kommandos notwendig:
addgroup named
adduser --system --ingroup named named
Nun muss in der Datei /etc/init.d/bind der Eintrag
start-stop-daemon --start
in
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named
geändert werden.
Natürlich ist BIND nun noch mit /etc/init.d/bind stop und /etc/init.d/bind start neu zu starten. Dabei sollten im Syslog (/var/log/syslog) in etwa folgende Einträge auftauchen:
Jul 8 23:21:01 sushi named[12432]: group = named
Jul 8 23:21:01 sushi named[12432]: user = named
Damit ist die Umstellung abgeschlossen. Idealerweise kann BIND nun noch in einer „chroot“-Umgebung betrieben werden.
Snort
Snort ist ein flexibler Packet-Sniffer, der verschiedenste Angriffe ermitteln kann. Hierzu gehören Buffer-Overflows, CGI-Angriffe, SMB-Angriffe und vieles mehr. Snort kann Alarmierungen in Echtzeit durchführen. Dieses Programm sollte auf jedem Router installiert sein, um jederzeit das Netzwerk zu überwachen. Die Installation erfolgt mit einem apt-get install snort; beantworten Sie die Fragen, und werfen Sie dann einen Blick auf die Logdateien.
Debian-Sicherheits-Updates
Unmittelbar nach jeder neuen Debian-GNU-Installation, beispielsweise von CD, sollten die neuesten verfügbaren Security-Updates installiert werden. Durch die notwendigen Vorlaufzeiten bei der Produktion von CDs sind diese natürlich nicht immer auf dem neuesten Stand.
Natürlich ist es nicht ausreichend, ein solches Update einmalig auszuführen, vielmehr müssen diese Updates in regelmäßigen Abständen durchgeführt werden. Dies verhindert, dass Software mit bekannten Sicherheitslücken über längere Zeit im laufenden Betrieb verwendet wird.
Austausch von Software
Zunächst sollten alle Netzwerkdienste, deren Passwörter im Klartext übertragen werden, deaktiviert beziehungsweise gegen Versionen mit verschlüsselter Kommunikation ausgetauscht werden. Dies betrifft Dienste wie FTP, Telnet, NIS, RPC und so weiter.
Auch sollten Sie auf die Verwendung von NIS (Network Information Service) verzichten. Bei einer fehlerhaften Konfiguration kann es leicht zu Sicherheitslücken kommen.
Zusätzlich sollten Sie RPC deaktivieren, sofern es möglich ist. Für diesen Dienst sind eine ganze Reihe von Sicherheitslücken bekannt. Natürlich wird gerade NFS häufig verwendet und stellt in vielen Netzen einen wichtigen Basisdienst dar. Hier gilt es, einen Kompromiss zwischen Sicherheit und Benutzbarkeit der Netzwerkdienste zu finden. Viele DDoS-(Distributed Denial of Service-)Angriffe benutzen RPC-Sicherheitslücken, um Systeme in so genannte „Agents“ oder „Handler“ umzuwandeln.
Das Deaktivieren des Portmappers ist relativ einfach. Wie für jede Lösung gibt es auch hier verschiedene Wege. Auf einem Debian-System ist der einfachste Weg sicherlich ein update-rc.d portmap remove. Dieses Kommando löscht jeden symbolischen Link auf den Portmapper in /etc/rc${runlevel}.d/. Dies kann natürlich auch auf herkömmlichem Wege von Hand erledigt werden. Eine weitere, nicht ganz elegante Möglichkeit ist es, die Zugriffsrechte so zu ändern, dass das Script nicht mehr ausführbar ist. Dazu verwenden Sie chmod 644 /etc/init.d/portmap. Dies würde jedoch zu einer Fehlermeldung beim Start des Systems führen.
Natürlich ergibt es nur wenig Sinn, lediglich einen Teil der Dienste von unverschlüsselter auf verschlüsselte Kommunikation umzustellen; hier sollte der Systemadministrator konsequent durchgreifen. Generell sollten die Dienste ftp, telnet, pop, imap und http entfernt und durch die entsprechenden Dienste mit verschlüsselter Kommunikation (ftp-ssl, telnet-ssl, pop-ssl, https) ersetzt werden.
Kernel-Patches
Im Netz sind einige Kernel-Patches verfügbar, die nicht Bestandteil des Standard-Linux-Kernels sind, dessen Sicherheit aber verbessern. Vor dem Einsatz ist im Einzelfall zu prüfen, ob der gewünschte Patch nicht schon in den benutzten Kernel eingeflossen ist. Auch erhebt die folgende Auflistung natürlich keinerlei Anspruch auf Vollständigkeit.
OpenWall Patch von „Solar Designer“. Eine Sammlung von Patches, die beispielsweise Links beschränken, FIFOs in /tmp/ unterbinden, das /proc-Dateisystem schützen, die Behandlung von Datei-Deskriptoren ändern und einiges andere verändern. Momentan werden Kernel der Serien 2.0, 2.2 und 2.4 unterstützt. Detaillierte Informationen finden Sie auf der Homepage http://www.openwall.com/linux.
LIDS - Linux intrusion detection system von Huagang Xie und Philippe Biondi. Dieser Patch vereinfacht die Sicherung eines Linux-Systems. Jeder Prozess kann beschränkt werden, indem Lese- und Schreibberechtigungen auf Dateien vergeben werden können. Weiterhin können je Prozess „Capabilities“ gesetzt werden. Dieser Patch findet sich auf der Homepage des Projekts unter http://www.lids.org.
POSIX Access Control Lists (ACLs) für Linux. Dieser Patch erweitert den Kernel um Access Control Lists (ACLs), eine Methode, die es gestattet, den Zugriff auf Dateien detaillierter zu beschränken, als es mit den üblichen Schemata möglich ist. http://acl.bestbits.at.
Linux trustees. Mit diesem Patch wird ein erweitertes System mit Zugriffsrechten zum Kernel hinzugefügt. Alle Objekte werden im Kernel-Speicher gehalten, so dass ein schneller Zugriff möglich ist. Homepage: http://www.braysystems.com/linux/trustees.html.
International kernel patch. Dieser Patch implementiert kryptographische Dateisysteme im Kernel. Es sind in einigen Ländern die entsprechenden Gesetze zu beachten. Homepage: http://www.kerneli.org.
SubDomain. Mit diesem Patch kann eine noch sicherere chroot-Umgebung aufgesetzt werden. Die für die Umgebung benötigten Dateien können einzeln angegeben werden und müssen nicht mit einkompiliert werden. Homepage: http://www.seifried.org/security/products.
UserIPAcct. Dieser Patch bezieht sich nicht direkt auf die Sicherheit eines Systems, erhöht aber die Kontrolle über die unberechenbaren Benutzer. Hiermit können Quota, bezogen auf den Benutzer, für den Netzwerkverkehr vergeben werden. Statistiken sind ebenfalls verfügbar. Homepage: http://ramses.smeyers.be/homepage/useripacct.
FreeS/WAN. Um IPSec zusammen mit dem Linux-Kernel verwenden zu können, wird dieser Patch benötigt. Hiermit können VPNs (Virtual Private Networks) sehr leicht aufgesetzt werden, zur Not auch mit Windows-Rechnern auf der Gegenseite. IPSec ist der für VPNs eingebürgerte Standard. Homepage: http://www.freeswan.org.
Cruft
Eine wichtige Aufgabe des Systemadministrators ist die regelmäßige Überwachung aller Dateien im System. Ein Eindringling kann es nicht nur auf den Diebstahl von Daten abgesehen haben, auch das Verändern von Systemdateien (beispielsweise um neue Benutzer anzulegen) oder von Programmdateien (Austausch von Binaries durch veränderte Versionen) kann ein Ziel sein. Das Auffinden dieser Veränderungen ist nur möglich, wenn der Stand vor der Veränderung bekannt ist.
Debian unterstützt durch das ausgefeilte Paketsystem die Überprüfung der installierten Dateien. Als erster Einstieg kann das Programm cruft dienen.
cruft untersucht das komplette Dateisystem nach Dateien, die eigentlich nicht vorhanden sein sollten, beziehungsweise nach Dateien, die sich nicht mehr im Dateisystem finden lassen. Hierzu wird im Wesentlichen auf die Informationen aus den Dateien im Verzeichnis /var/lib/dpkg/info/ zugegriffen. cruft überwacht aber auch darüber hinausgehende Informationen wie beispielsweise die „alternatives“-Informationen, die lost+found-Verzeichnisse in einem ext2-Dateisystem und auch die Heimatverzeichnisse der Benutzer.
Weitere Möglichkeiten
Im Folgenden finden Sie einige Gedanken dazu, wie das bisher Gesagte weiterhin umgesetzt werden kann.
Das PAM-System ist durch den modularen Aufbau in der Lage, die verschiedensten Medien zur Authentifizierung zu nutzen. Wie wäre es mit einem Scanner für Fingerabdrücke oder einem Iris-Scanner?
Alle bisherigen Logdaten wurden auch in Dateien geschrieben. Diese können von einem Angreifer natürlich verändert oder gelöscht werden, auch wenn diese auf anderen Rechnern gespeichert werden. Logfiles, die auf einem Drucker mit Endlospapier ausgegeben werden, können nicht gelöscht werden!
Um das Löschen oder das Verändern von Dateien zu verhindern, kann ein komplettes System einmalig konfiguriert werden und dann auf eine bootfähige CD-ROM geschrieben werden. Natürlich sind so noch Angriffe auf das System möglich; es können aber keine Daten verändert oder zusätzliche Programme installiert werden. Für ein Firewall-System ist dies beispielsweise eine sinnvolle Möglichkeit, das System zu schützen.
Wenn möglich sollten alle Kernel-Treiber nicht als Module übersetzt werden. Dann kann die Möglichkeit, Kernel-Module zu laden, komplett deaktiviert werden. So können viele Angriffe abgewehrt werden. Auch hier gilt: Nicht benutzte Funktionen sind abzuschalten.
Maßnahmen nach einem Einbruch ...
Nach einem Einbruch gibt es nicht viel zu tun. Das System ist sofort vom Netz zu nehmen und komplett neu zu installieren. Einfach, nicht wahr? Natürlich gilt es herauszufinden, wie der Eindringling in das System eingedrungen ist. Dies geschieht in einer abgeschotteten Umgebung, also ohne Netzzugang für das betroffene System. Es sind zur späteren weiteren Analyse alle Daten auf einem geeigneten Medium zu sichern.
Gegebenenfalls ist eine Meldung an ein CERT (Computer Emergency Response Team, in Deutschland beispielsweise das DFN-CERT http://www.cert.dfn.de/) zu erstellen und dort der Einbruch zu melden. Ist eine Strafverfolgung des Einbruchs vorgesehen oder geplant, so sollten Sie gegebenenfalls auf professionelle Unterstützung zurückgreifen.
Weiterhin sind auf dem neuen System alle notwendigen, vorab beschriebenen Sicherheitsvorkehrungen zu treffen.
Erkennen von Rootkits
Nach einem Einbruch auf einem System, beispielsweise durch ein über das Netzwerk gesnifftes Passwort, werden häufig so genannte „Rootkits“ installiert, die dem Angreifer einen Zugang mit Rechten des Administrators (root) erlauben. Es ist dabei über eine Sicherheitslücke, die dem Angreifer zunächst lediglich normale Benutzerrechte erlaubt, möglich, mittels bekannter Lücken weitere Zugriffsrechte zu erlangen.
Ein Rootkit wird dabei, wie der Name schon sagt, als „Bausatz“ in Form von Scripts geliefert. Rootkits sind in den verschiedensten Varianten im Internet verfügbar. Der Angreifer muss nicht zwingend über weit reichende Systemkenntnisse verfügen, ein erschlichener Benutzer-Account ist oft ausreichend, um ein Rootkit zu installieren. Angreifer, die solche Rootkits einsetzen, werden daher aufgrund des fehlenden Know-hows auch als „Script-Kiddies“ bezeichnet.
Rootkits haben dabei die (unangenehme) Eigenschaft, viele Arbeitsschritte bei einem Einbruch in ein System zu automatisieren. Es werden dabei zunächst Programme installiert und ausgetauscht, um Aktivitäten auf dem System zu verbergen. Dabei ist es beispielsweise üblich, zunächst /bin/login gegen eine modifizierte Variante auszutauschen. Die neue Version erlaubt Logins eines bestimmten Benutzers ohne oder mit einem bekannten Passwort. Natürlich erscheinen diese Logins in keinem Logfile. Weiterhin werden Programme, die Aufschlüsse über die Aktivität von Benutzern erlauben, durch veränderte Versionen ersetzt. Dies betrifft meist Programme wie ls (Anzeigen von Dateien und Zugriffsrechten) oder auch ps (Anzeigen von Prozessen eines Benutzers). Mit diesen neuen Programmen werden Aktivitäten des Angreifers verschleiert oder komplett verborgen.
Rootkit-Tools
Um ein Rootkit zu erkennen, können Sie das Paket chkrootkit (Check Rootkit) verwenden. Dieses kann ab der Debian-Version 3.1 direkt via APT installiert werden.
Der Aufruf dieses Programms erfolgt wie üblich auf der Kommandozeile, es kann dabei die Option -q angegeben werden, um die Informationen über die durchgeführten Tests zu unterdrücken. Leider neigt chkrootkit dazu, mitunter Alarm zu schlagen, auch wenn kein Rootkit installiert ist. Bekannt ist dies bei Netzwerkinterfaces, die im Promiscous-Modus laufen (wenn beispielsweise tcpdump eingesetzt wird). Bekannt ist dieses Fehlverhalten auch bei Kerneln mit NPTL-Patch (ab Kernel 2.6 immer enthalten); dabei wird ein „LKM-Trojaner“ gemeldet. Weiterhin werden solche falsch-positiven Ergebnisse auch auf sehr langsamen Rechnern gemeldet.
Suckit Detection Tool
Das Paket skdetect ist ein auf das „Suckit“-Rootkit spezialisiertes Programm. Einige Tests wurden hier genauer implementiert, die Erkennung ist aber nicht so umfassend.
Fazit
Grundsätzlich enthält jedes System nach der Neuinstallation Sicherheitslücken. Je nach Einsatzgebiet des Rechners müssen diese Schwachstellen erst beseitigt werden. Debian GNU/Linux bietet umfangreiche Möglichkeiten, das System vor unbefugten Zugriffen abzuschotten. Allerdings reicht es nicht aus nur Sicherheits-Updates aufzuspielen. Der Anwender selbst kann und muss aktiv sein System „härten“.
Über Sicherheitsrisiken unter Debian GNU/Linux kann sich der Anwender im „Securing Debian HOWTO“ bereits im Vorfeld informieren. Auch vor, während und nach der Installation des Debian-Betriebssystems muss der User auf einige Grundlegende Dinge achten. Das beginnt bei den BIOS-Einstellungen geht über Absicherung des Bootloaders und Aufspielen von Sicherheits-Patches bis hin zu Anpassungen von Diensten und sicherheitsrelevanten Dateien. (hal)