Securing Debian HOWTO

BIOS Einstellungen

Bevor ein Betriebsystem auf einem neuen Computer installiert wird, sollte ein BIOS Passwort gesetzt werden und die Booteinstellungen sollten so gewählt werden das ein Systemstart von Diskette nicht möglich ist. Nach der Installation sollte darauf geachtet werden das so schnell wie möglich auch der Start von CD-ROM abgeschaltet wird.

Ein weitere Vorteil dieser Einstellungen zeigt sich wenn das System als Server betrieben wird. Es wäre nicht das erste mal das eine vergessene Diskette im Laufwerk einen erfolgreichen Reboot eines Systems verhindert, sehr ärgerlich wenn ein direkter Zugriff auf das System nur mit einer längeren Anfahrt möglich ist.

Plattenpartitionen

Die Einteilung des verfügbaren Plattenplatzes hängt von der Verwendung des Systems ab. Hierzu sollte einige Dinge beachtet werden:

• Jede Partition auf die Schreibzugriff von den Benutzern des Systems besteht, sollte auf einer eigenen Partition liegen, beispielsweise die Bereiche /home und /tmp. Dies verhindert das ein Benutzer das /-Dateisystem unbenutzbar macht und das gesamte System in einen instabilen Zustand bringt. Es bleibt natürlich ein gewisser Platz (meist 5%, dieser Wert kann mit tunefs angepasst werden) für den Superuser reserviert, doch kann so anderen Benutzern das Arbeit mit dem System unmöglich gemacht werden.

• Es sollte für jeden Bereich der automatisch mit Daten gefüllt wird, beispielsweise /var und hier insbesondere /var/log eine eigene Partition vorgesehen werden. Auf Debian Systemen sollte /var großzügiger bemessen werden, da unter /var/cache/apt/archives Pakete temporär abgelegt werden wenn die Installation übers Netz erfolgt. Weiterhin finden sich unter /var/lib/dpkg viele Dateien die für das Paketmanagement benötigt werden.

• Wenn Software installiert werden soll, die nicht in der Debian Distribution enthalten ist, sollten auch diese Bereich auf eigenen Partitionen liegen, diese werden dann bei einer Neuinstallation des nicht überschrieben. Nach dem File Hierarchy Standard (FHS) sind dies /opt oder /usr/local.

Superuser Passwort

Während der Installation wird nach einem Passwort für den Superuser (root) gefragt. Zusätzlich kann ein Benutzer dem System hinzugefügt, auch für diesen ist dann ein Passwort einzugeben. Auch wenn es möglich ist hier ein sehr einfaches Passwort zu verwenden, so ist dies natürlich nicht empfehlenswert. Die Auswahl eines guten Passwortes ist auf vielen Webseiten im Netz beschrieben, es sind dabei nur einige einfache Regeln zu beachten. Eine Suche nach „auswahl gutes passwort“ mittels Google führt schnell zum Erfolg.

Grundsätzlich sollte auf jedem System neben dem Account für den Superuser auch ein Account für einen Benutzer angelegt werden der nicht alle Rechte hat. Dieser Benutzeraccount sollte für alle Logins auf dem System verwendet werden und nur wenn für eine bestimmte Aufgabe die Zugriffsrechte nicht ausreichend sind sollte mittels des Kommandos su die Identität gewechselt werden. Nach Beendigung der Arbeiten als Superuser sollte man sich umgehend wieder als normaler Benutzer im System bewegen.

Shadow- und MD5 Passwörter

Während der Installation erfolgt eine Abfrage ob „Shadow Passwords“ aktiviert werden sollen. Wenn die Frage positiv beantwortet wird, werden die Passwörter in der Datei /etc/shadow verschlüsselt gespeichert. Diese Datei kann nur vom Superuser und der Gruppe „shadow“ gelesen werden, somit kann kein Benutzer des Systems die verschlüsselten Passwörter lesen und versuchen diese mit Hilfe einer Software zu entschlüsseln. Diese Einstellung kann später mit dem Programm shadowconfig rückgängig gemacht werden. Weiterhin besteht die Möglichkeit die Passwörter mit einer MD5 Verschlüsselung zu speichern, dies ist generell eine gute Idee, da so ein Angriff weiterhin erschwert wird und längere Passwörter möglich sind.

Aktivierte Dienste

Wie bereits beschrieben sollten nur die absolut notwendigen Dienste auf einem System aktiviert werden. Jeder neue Dienst schafft möglicherweise ein neues Sicherheitsloch, welches vielleicht erst später zu einem Problem wird. Werden bestimmte Dienste nur selten benötigt, so können diese über die update-Kommandos (beispielsweise update-inetd) gezielt aktiviert und deaktiviert werden.

Mailinglisten

Lesen Sie die Debian Security Mailinglisten. Relevant sind in diesem Zusammenhang debian-security-announce, dort werden Sicherheitslücken bekanntgegeben und es wird über Bugfixes dagegen informiert, sowie debian-security@lists.debian.org, dort werden alle Sicherheitstemen rund um Debian behandelt.

Wenn Sie Meldungen über Sicherheitsupdates per E-Mail bekommen wollen, so senden Sie eine Mail an: debian-security-announce-request@lists.debian.org mit dem Wort „subscribe“ im Betreff der Mail. Die Anmeldung zu dieser Mailingliste ist auch über die Webseite http://www.debian.org/MailingLists/subscribe möglich.

Auf dieser Mailingliste kommen nur sehr wenige Mails, man erfährt dort aber sehr schnell über Probleme mit Paketen informiert und erfahren eine Adresse an der eine fehlerbereinigte Version zur Verfügung steht.

Absicherung des Bootloaders

Jede Person die Zugang zur Tastatur des Systems hat kann eine Superuser-Shell bekommen und beispielsweise alle Passwörter ändern, indem am Bootprompt dateiname-des-bootkernels init=/bin/sh eingegeben wird. Um dies zu verhindern kann ein Passwort für den Boot-Loader gesetzt werden. Dies kann global für alle Boot-Images geschehen oder individuell für jedes einzelne.

Wenn Lilo als Bootloader verwendet wird, muß die Datei /etc/lilo.conf um die Einträge password und restricted erweitert werden.

image=/boot/2.2.14-vmlinuz label=Linux read-only password=hackme restricted

Danach muß lilo nochmal aufgerufen werden. Sorgen Sie dafür das die Datei /etc/lilo.conf nur vom Superuser gelesen werden kann, da das Passwort unverschlüsselt in der Konfigurationsdatei steht, dies ist mit dem Kommando chmod 600 /etc/lilo.conf zu erreichen. Die Option restricted bewirkt das nur nach einem Passwort gefragt wird wenn der Benutzer versucht zusätzliche Parameter am Bootprompt anzugeben. Die Auswahl verschiedener, bereits in der Konfiguration eingetragener Kernel ist weiterhin möglich. Wird der Eintrag restricted weggelassen, fragt Lilo in jedem Fall nach einem Passwort.

Die genannten Einträge können am Anfang der Konfigurationsdatei allgemeingültig für alle Kernel in der Konfiguration angegeben werden, oder aber innerhalb eines Abschnittes der Konfigurationsdatei nur für bestimmte Kernel.

Wird auf dem System GRUB verwendet, so müssen folgende Zeile der Datei /boot/grub/menu.lst hinzugefügt werden:

timeout 3 password hackme

Die Option timeout sorgt nach der angegebenen Zeit dafür das der Standardeintrag gebootet wird.

Starten von Diskette

Der von Debian Versionen vor 2.2 installierte MBR (Master Boot Record) wurde mit einer Option installiert die es erlaubte von Diskette zu booten auch wenn dies sonst abgeschaltet war. Ob ein solcher MBR installiert ist läßt sich wie folgt prüfen:

• Drücken Sie während des Startvorganges die Shift Taste, der MBR Prompt sollte erscheinen.

• Drücken Sie nun „F“ und das System startet von Diskette. Mit dieser kann ein Superuserzugang zum System erreicht werden.

Dieses Verhalten kann wie folgt verändert werden:

lilo -b /dev/hda

Wobei hda dem entsprechenden Devicenamen Ihres Systems angepasst werden muß.

Die Bootdisketten ab Debian Version 2.2 installieren lilo direkt in den MBR, hier tritt diese Lücke nicht auf.

Mounten von Dateisystemen

Beim mounten (einhängen in das Dateisystem) von ext2-Partitionen gibt es diverse Optionen die dem Kommando mount übergeben werden oder die direkt in die Datei /etc/fstab eingetragen werden können. Ein solcher Eintrag könnte beispielsweise wie folgt aussehen:

/dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2

Die Optionen finden sich in der vierten Spalte. Die Option nosuid ignoriert gesetzte SUID und GUID Bits auf dieser Partition. Eine gesetzte Option noexec verhindert das auf dieser Partition befindliche Programme ausgeführt werden können und nodev ignoriert Device Dateien. Dabei ist zu beachten:

• Dies bezieht sich nur auf ext2 Dateisysteme.

• Auch solche Optionen können relativ leicht umgangen werden.

Hierzu ein Beispiel:

fr@sushi:/tmp# mount | grep tmp /dev/hda3 on /tmp type ext2 (rw,noexec,nosuid,nodev) fr@sushi:/tmp# ./date bash: ./date: Keine Berechtigung fr@sushi:/tmp# /lib/ld-linux.so.2 ./date Sun Jul 29 14:40:32 CEST 2001

Viele Tools die von Hackern benutzt werden, versuchen im Verzeichnis /tmp Dateien anzulegen und diese auszuführen. Mit der Option noexec kann man dem Einbrecher zumindest das Leben etwas schwerer machen.

Debian Sicherheitsupdates

Sobald eine neue Sicherheitslücke in einem Debian Paket oder einer Software dieses Paketes bekannt wird, wird von den Paket-Maintainern innerhalb weniger Stunden oder Tage ein Update der betroffenen Pakete bereitgestellt. Das aktualisierte Paket wird unter http://security.debian.org zur Verfügung gestellt.

Um auch die Sicherheitsupdates bei jeder Aktualisierung des Systems automatisch durchzuführen, muß folgende Zeile in die Datei /etc/apt/sources.list eingefügt werden:

deb http://security.debian.org/debian-security stable/updates main contrib non-free

In Ländern die den Import von Kryptografischer Software nicht verbieten kann zusätzlich folgende Zeile hinzugefügt werden.

deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free

Natürlich können auch die entsprechenden deb-src Zeilen hinzugefügt werden wenn auch der Zugriff auf die Sourcen gewährleistet sein soll. Danach ist nur noch ein apt-get update gefolgt von einem apt-get upgrade nötig um das System auf den neuesten Stand zu bringen.

PAM - Pluggable Authentication Modules

PAM erlaubt dem Systemadministrator die Auswahl auf welche Weise die verschiedenen Anwendungen eine Authentifizierung durchführen sollen. Hierzu muß jede Anwendung auf die Verwendung von PAM angepasst sein, dies ist seit Debian 2.2 für die meisten Programme der Fall. Ältere Versionen von Debian benutzen noch keine Authentifizierung über PAM. Für jede Anwendung existiert im Verzeichnis /etc/pam.d eine eigene Konfigurationsdatei.

Mit PAM bietet sich die Möglichkeit mehrere Authentifizierungsschritte, vom Benutzer unbemerkt, durchzuführen. Beispielsweise kann eine Authentifizierung sowohl gegen eine Datenbank als auch gegen die Datei /etc/passwd erfolgen.

Über PAM können viele Restriktionen auferlegt werden, genauso gut ist es aber möglich das System weit zu öffnen und so Sicherheitslücken zu schaffen. Bei der Veränderung von Einstellungen von PAM sollte also größte Vorsicht bewahrt werden. Eine typische Konfigurationszeile enthält in der dritten Spalte ein Kontrollfeld. Dieses sollte auf den Wert „requisite“ gesetzt werden, so das bei einem Fehler in einem Modul ein Login verhindert wird.

Zuerst sollte die Unterstützung für MD5 verschlüsselte Passwörter aktiviert werden, um so zu verhindern das ein Passwort leicht von einem Programm über eine Datenbank ermittelt werden kann. Die folgenden Zeilen sollten in allen Dateien in /etc/pam.d/ hinzugefügt werden die Zugang zu dem System erlauben, beispielsweise login und ssh.

password required pam_cracklib.so retry=3 minlen=12 difok=3 password required pam_unix.so use_authtok nullok md5

Der erste Eintrag lädt das Cracklib PAM Modul, welches eine strengere Anforderungen an das verwendete Passwort stellt. Passwörter müssen mit diesem Modul mindestens 12 Zeichen haben, bei einer Passwortänderung müssen mindestens drei Zeichen verändert werden. Weiterhin werden nur 3 Login Versuche erlaubt.

Die zweite Zeile benutzt die Standard Authentifizierung des Unix Systems mit einer MD5 Verschlüsselung und erlaubt auch leere Passwörter. Die use_authtok Option wird benötigt um das Passwort vom vorhergehenden Modul zu übernehmen.

Um den Zugriff so zu beschränken das der Benutzer root sich lediglich auf den lokalen Terminal einloggen kann, muß die folgende Zeile in der Datei /etc/pam.d/login aktiviert werden:

auth requisite pam_securetty.so

Weiterhin müssen die Terminal von denen dem Benutzer root der Zugriff auf das System gewährt werden soll in die Datei /etc/security/access.conf eingetragen werden. Um auch die eigentlichen Benutzer des Systems zu beschränken, beispielsweise in der Anzahl der gleichzeitigen Logins, muß noch die folgende Zeile aktiviert werden:

session required pam_limits.so

In der Datei /etc/pam.d/passwd ist nun noch die erste Zeile zu verändern. Dort muß die Option „md5“ eingetragen werden um mit MD5 verschlüsselte Passwörter zu benutzen. Weiterhin kann die minimale Passwortlänge beispielsweise von 4 auf 6 Zeichen erhöht werden. Ebenso kann eine maximale Länge gesetzt werden falls dies gewünscht ist. Schlußendlich sollte die Zeile in etwas wie folgt aussehen:

password required pam_unix.so nullok obscure min=6 max=11 md5

Wenn das Kommando su so geschützt werden soll das es nur von bestimmten Benutzern ausgeführt werden kann, muß zunächst eine neue Gruppe dem System hinzugefügt werden. Üblich ist es hierzu die Gruppe „wheel“ zu verwenden, da diese noch nicht existiert und es somit unwahrscheinlich ist das bereits Dateien zu dieser Gruppe gehören. Dieser Gruppe ist der Benutzer root sowie alle Benutzer die das Kommando su ausführen sollen, hinzuzufügen. In der Datei /etc/pam/su ist dann folgender Eintrag zu ergänzen:

auth requisite pam_wheel.so group=wheel debug

Somit wird sichergestellt das nur Benutzer die der Gruppe „wheel“ angehören das Kommando su ausführen können. Alle anderen Benutzer bekommen eine entsprechende Meldung wenn sie versuchen das Kommando auszuführen.

Wenn nur bestimmten Benutzern eine Authentifizierung über PAM erlaubt werden soll, so ist dies relativ einfach über Dateien zu erreichen in denen die Benutzer aufgeführt sind denen der Login erlaubt oder verboten werden soll. Wenn beispielsweise nur dem Benutzer „fr“ der Login über ssh erlaubt werden soll, so muß dieser in die Datei /etc/sshusers-allowed eingetragen werden und folgender Eintrag muß der Datei /etc/pam.d/ssh hinzugefügt werden.

auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail

Zu guter letzt sind folgende Einträge der Datei /etc/pam.d/other hinzuzufügen:

Last, but not least, create /etc/pam.d/other and enter the following lines: auth required pam_securetty.so auth required pam_unix_auth.so auth required pam_warn.so auth required pam_deny.so account required pam_unix_acct.so account required pam_warn.so account required pam_deny.so password required pam_unix_passwd.so password required pam_warn.so password required pam_deny.so session required pam_unix_session.so session required pam_warn.so session required pam_deny.so

Diese Voreinstellungen sind erst einmal eine sinnvolle Vorgabe, es werden grundsätzlich erstmal alle PAM Zugriffe verweigert.

Ein Aufmerksamer Blick sollte auch in die Datei /etc/security/limits.conf geworfen werden. Hier werden Resourcen für die Benutzer des Systems festgelegt.

Anpassungen der /etc/inetd.conf

Generell sollten alle nicht benötigten Dienste auf einem System deaktiviert werden. Jeder laufende, nicht unbedingt benötigte Dienst stellt ein potentielles Risiko dar. Dies betrifft beispielsweise die Dienste echo, charges, discard, daytime, time, talk, ntalk sowie die extrem unsicheren „r“-Kommandos wie rsh, rlogin, rcp. Für letztere ist es in jedem Fall besser das Kommando ssh zu benutzen.

Nachdem die nicht benötigten Dienste deaktiviert sind, sollte geprüft werden ob der inetd überhaupt noch benötigt wird. Dienste können natürlich auch als Daemon gestartet werden statt den inetd zu benutzen. Denial of Service (DoS) Angriff können auch auf den inetd als Ziel ausgeführt werden und so beispielsweise die Systemlast eines Rechners in die Höhe treiben. Wenn trotzdem nicht auf den Einsatz eines inetd verzichtet werden kann, so sollte unter Umständen ein alternativer inetd eingesetzt werden der vielfältiger konfiguriert werden kann, beispielsweise der xinetd oder der rlinetd.

Veränderungen an der inetd.conf können von Hand vorgenommen werden, Debian bietet aber eine einfach zu benutzende Alternative dazu: mit dem Programm update-inetd können einzelne Dienste verändert werden.

Beipiel:

/usr/sbin/update-inetd --disable telnet /etc/init.d/inetd restart

Nach jeder Änderung ist der inetd noch neu zu starten.

Das Kommando update-inetd kennt noch viele andere Optionen, beispielsweise auch um Einträge zu löschen:

sushi:/home/fr# Usage: update-inetd [OPTION] MODE ARGUMENT Options: --version output version information and exit --help display this help and exit --verbose explain what is being done --debug enables debugging mode --multi allow multiple removes/disables --file FILENAME use FILENAME instead of /etc/inetd.conf --group GROUPNAME add entry to section GROUPNAME --comment-chars CHARACTERS use CHARACTERS as comment characters --pattern PATTERN use PATTERN to select a service Modes: --add ENTRY add ENTRY to /etc/inetd.conf --remove ENTRY remove ENTRY (regular expression) --enable SERVICE enable SERVICE in /etc/inetd.conf --disable SERVICE disable SERVICE in /etc/inetd.conf In order to prevent the shell from changing your ENTRY definition you have to quote the ENTRY using single or double quotes. You can use tabs (the tab character or \t) and spaces to separate the fields of the ENTRY. If you want to enable/disable more than one SERVICE you can use a comma separated list of services (no whitespace characters allowed).

/etc/login.defs

Nun sollten einige Einstellungen zum Benutzer Login und zur grundsätzlichen Konfiguration vorgenommen werden.

FAIL_DELAY          10

Diese Variable sollte auf einen höheren Wert gesetzt werden um „Brute-Force“ Angriffe auf einem Terminal zu erschweren. Wenn ein falsches Passwort eingegeben wird, muß der Benutzer 10 Sekunden warten bis ein neuer Login Versuch gestartet werden kann. Dies frist einiges an Zeit wenn versucht wird ein Passwort zu erraten. Diese Einstellung gilt nur wenn getty benutzt wird, bei mingetty beispielsweise ist diese Einstellung ohne Wirkung.

FAILLOG_ENAB        yes

Mit dieser Variablen werden fehlgeschlagene Logins im Logfile verzeichnet. Dies ist wichtig wenn „Brute-Force“ Angriffe aufgezeichnet werden sollen.

LOG_UNKFAIL_ENAB    yes

Wenn die Variable FAILLOG_ENAB auf yes gesetzt wird, so sollte dies Variable auf yes gesetzt werden. Diese Einstellung schreibt auch unbekannte Benutzernamen bei einem Login ins Logfile. Es ist darauf zu achten das die entsprechenden Logdateien nicht von allen Benutzern gelesen werden können, da Benutzer häufig anstelle des Benutzernamens das Passwort eingeben. Damit andere Benutzer diese Datei nicht lesen können sind die Zugriffsrechte beispielsweise auf 640 zu setzen.

SYSLOG_SU_ENAB yes

Diese Einstellung verzeichnet die Benutzung des Kommandos su im Syslog.

SYSLOG_SG_ENAB yes

Diese Einstellung erfüllt die gleiche Funktion wie die vorhergehende, jedoch für das Kommando sg.

MD5_CRYPT_ENAB yes

Wie schon beschrieben reduzieren MD5 verschlüsselte Passwörter die Gefahr des erschleichens eines Passwortes durch entsprechende Software. Wenn auf dem System noch „slink“ (Debian 2.1) eingesetzt wird so ist vor dem aktivieren dieser Option ein Blick in die Dokumentation zu werfen. Ansonsten wird diese Einstellung über PAM realisiert.

PASS_MAX_LEN 50

Wenn MD5 Passwörter in der PAM Konfiguration aktiviert sind, so sollte diese Variable auf den gleichen Wert wie dort gesetzt werden.

/etc/ftpusers

Diese Datei enthält eine Liste der Benutzer die nicht per FTP Protokoll einloggen dürfen. Benutzen Sie diese Datei nur wenn Sie wirklich sicher sind das auf dem System auf tatsächlich ein FTP-Server laufen soll, da per FTP der Benutzername und das Passwort immer im Klartext übertragen werden. Wenn der benutzte FTP-Daemon PAM unterstützt, so können auch dort die Benutzer zugelassen oder ausgeschlossen werden.

Einsatz eines TCP Wrappers

TCP Wrapper wurde entwickelt als noch keine echten Paketfilter verfügbar waren aber trotzdem eine Kontrolle notwendig wurde. Ein TCP Wrapper erlaubt oder verbietet die Nutzen eines Dienstes einem Rechner oder einer Domain. Nähere Informationen finden sich in der Manpage hosts_access(5).

Hier nun vielleicht das kleinste System um Einbruchsversuche zu registrieren. Auf alle Fälle sollte auf jedem System ein Firewall installiert sein, zusätzlich zu diesem TCP-Wrapper. Dieser kleine Trick schickt bei jedem verweigerten Zugriff auf auf einen Service eine Mail an den Superuser.

ALL: ALL: spawn ( \ echo -e "\n\ TCP Wrappers\: Connection refused\n\ By\: $(uname -n)\n\ Process\: %d (pid %p)\n\ User\: %u\n\ Host\: %c\n\ Date\: $(date)\n\ " | /bin/mail -s "Connection to %d blocked" root)

Natürlich ist dieses Beispiel nicht perfekt: Bei vielen Verbindungen innerhalb einer kurzen Zeit werden natürlich auch entsprechend viele E-Mails gesendet, was wiederrum einem DoS-Angriff gleichkommt.

Benutzung von su

Sollte es einmal notwendig sein Arbeiten am System als Superuser durchzuführen, so kann das Kommando su benutzt werden um die benötigten Rechte zu erlangen. Es sollte versucht werden allen Benutzern klarzumachen das Arbeiten als Superuser nur in Ausnahmefällen gestattet sind. In jedem Fall ist ein Login als root zu vermeiden und stattdessen das Kommando su zu benutzen. Noch besser ist es jedoch das Kommando su komplett zu entfernen und stattdessen das Kommando sudo zu benutzen, welche eine ganze Reihe weiterer Funktionen bietet. su ist aber weithin bekannt da es auch auf vielen anderen Unix Systemen eingesetzt wird.

Benutzung von sudo

sudo erlaubt einem Benutzer Kommandos unter der ID eines anderen Benutzers auszuführen, gegebenenfalls auch als Superuser. Wenn der Benutzer in der Datei /etc/sudoers aufgeführt ist und sich authentifiziert hat, können Kommandos ausgeführt werden die ebenfalls in dieser Datei aufgeführt sind. Verletzungen dieser Regel, wie beispielsweise ein falsches Passwort oder die versuchte Ausführung eines unerlaubten Programmes, werden aufgezeichnet und per E-Mail an den Superuser (root) geschickt.

Benutzung von chroot

chroot ist eine leistungsfähige Möglichkeit um ein Programm oder einen Daemon oder einem Benutzer zu beschränken. Man kann sich das wie in einem Gefängnis vorstellen aus dem ein Ausbruch unmöglich ist (normalerweise... aber einige Leute schaffen es ja doch manchmal...). Wenn einem Benutzer nicht vollkommen vertraut wird, so kann für diesen eine chroot-Umgebung eingerichtet werden. Dies kann einiges an Plattenplatz beanspruchen wenn alle benötigten Binaries und Bibliotheken in diese Umgebung kopiert werden müssen. Auch wenn es dem Benutzer gelingt Schaden anzurichten, so bleibt dieser auf die beschränkte Umgebung beschränkt.

Ein gutes Beispiel für eine solche Anwendung ist folgende: die Authentifizierung erfolgt nicht gegen die Datei /etc/passwd sondern gegen LDAP oder/und eine MySQL Datenbank. Ein verwendeter FTP-Daemon benötigt das Binary und ein paar Bibliotheken. Hier bildet eine chroot-Umgebung eine excellente Verbesserung der Sicherheit, falls eine Sicherheitslücke in diesem FTP Daemon auftaucht. In diesem Fall ist lediglich die Benutzer-ID des FTP-Daemons betroffen und keine anderen Benutzer des Systems. Natürlich können auch viele andere Dienste von solch einer Umgebung profitieren.

Als Hinweiß: Bisher wird bei keiner Debian Version eine chroot-Umgebung für die Dienste und Server verwendet.

Kernel Features

Viele Funktionen des Kernel können während der Laufzeit verändert werden, beispielsweise indem mit dem Kommando echo ein Wert in die entsprechenden Datei geschrieben wird, oder mit dem Kommando sysctl. Mit dem Kommando sysctl -A kann angezeigt werden welche Einstellungen verändert werden können und welche Optionen verfügbar sind. In seltenen Fällen muß etwas verändert werden, aber auf diesem Weg kann die Sicherheit des Systems erhöht werden.

/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts = 0

Wird diese Variable auf den Wert 1 gesetzt, so verhält sich das System nach aussen wie ein Windows System wenn ein Broadcast ping das System erreicht.

/proc/sys/net/ipv4/icmp_echo_ignore_all = 0

Wenn ICMP Pakete auf dem Firewall nicht geblockt werden sollen, so ist dieser Wert auf 1 zu setzen.

/proc/sys/net/ipv4/tcp_syncookies = 1

Diese Option ist ein zweischneidiges Schwert: Auf der einen Seite schützt es gegen „Syn-Flooding“ Atacken, auf der anderen Seite entspricht dies nicht den RFCs. Diese Option beschäftigt die angreifende Seite ebenso mit „Syn-Floods“ so das diese ebenso beschäftigt ist. Diese Option kann auch in /etc/network/options verändert werden, indem die Option syncookies auf yes gesetzt wird.

/proc/sys/net/ipv4/conf/all/log_martians = 1

Mit dieser Option werden Pakete mit unerlaubten Adresse, beispielsweise wegen eines fehlerhaften Routings, im Netzwerk geloggt.

Benutzung der svgalib

SVGAlib ist eine schöne Einrichtung für Liebhaber der Konsole, in der Vergangenheit hat es sich jedoch gezeigt das immer wieder Sicherheitslücken bekannt geworden sind. Sicherheitslücken in zgv wurden bekannt mit denen Superuser Rechte erlangt werden konnten. Wenn möglich sollte auf die Verwendung der SVGAlib verzichtet werden.

Sichere Übertragung von Dateien

Die Übertragung zwischen zwei Rechnern sollte auf keinen Fall mit Programmen wie ftp oder rcp erfolgen, da diese den Benutzernamen und das Passwort unverschlüsselt übertragen. Als sichere Alternative steht scp zur Verfügung welches im Paket ssh enthalten ist. Hier werden sowohl Benutzername als auch Passwort und auch die Daten selber in verschlüsselter Form übertragen.

Benutzung von Quotas

Eine saubere Definition von Benutzerquotas ist wichtig um zu verhindern das Benutzer ein komplettes Dateisystem mit Daten füllen können.

Es können grundsätzlich zwei verschieden Quota Systeme eingesetzt werden - Benutzer- oder Gruppen-orientierte Quotas. Dies ist bei der Planung zu berücksichtigen.

Einige Punkte sind bei der Benutzung von Quotas zu beachten:

• Quotas sollten in Summe so klein gewählt werden das nicht der gesammte Plattenplatz belegt werden kann.

• Quotas sollten so groß gewählt werden das die Benutzer nicht in der Arbeit behindert werden, beispielsweise sollte das Spoolverzeichnis für Mail nicht zu knapp bemessen werden.

• Quotas müssen auf allen, von Benutzern beschreibbaren Bereichen eingerichtet werden, beispielsweise /home und /tmp.

Für jede Partition, bzw. jedes Verzeichnis, auf das Benutzer einen Schreibzugriff haben, sollten Quotas aktiviert werden. Für diese Bereiche ist ein sinnvoller Wert zu errechnen der eine Balance zwischen Sicherheit und Benutzbarkeit des Systems schafft.

Doch nun zur Benutzung von Quotas: Zunächst muß geprüft werden ob im Kernel die Quota Unterstützung aktiviert ist. Wenn dies nicht der Fall ist, muß ein neuer Kernel erzeugt werden. Danach ist zu prüfen ob das Paket quota installiert ist, ggf. ist dies zu installieren.

Quotas werden aktiviert indem in der Datei /etc/fstab der Eintrag für das entsprechende Dateisystem in der Spalte „Options“ um den Eintrag usrquota erweitert wird. Wenn statt Benutzer-Quota, Gruppen-Quota benutzt werden sollen, lautet der Eintrag grpquota. Natürlich können auch beide gleichzeitig verwendet werden. Nun muß im Root-Verzeichnis des Dateisystems eine leere Datei quota.user und quota.group erzeugt werden.

Das Quota System muß nun neugestartet werden, dies geschieht durch die Kommandos /etc/init.d/quota stop und /etc/init.d/quota start. Nun können die gewünschten Grenzwerte gesetzt werden.

Um die Quota für einen Benutzer (beispielsweise fr) zu setzen, wird das Kommando edquota -u fr benutzt. Gruppen-Quota werden mit dem Kommando edquota -g gruppe gesetzt. Nun können die Grenzwerte für „soft“ und „hard“ sowie für die Inodes gesetzt werden.

Zugriffsrechte von Logdateien

Einige Logdateien sind nach der Installation nicht perfekt. Zunächst ist es nicht notwendig das die Dateien /var/log/lastlog und /var/log/faillog von jedem Benutzer gelesen werden können. In der Datei lastlog sind Benutzer verzeichnet die sich in der letzten Zeit am System angemeldet haben, in der Datei faillog finden sich fehlgeschlagene Loginversuche. Bei beiden Dateien sollten die Zugriffsrechte auf 660 verändert werden. Prüfen Sie genau ob Logdateien mit unnötigen Zugriffsrechten versehen sind. Meist sind Lese- und Schreibrechte für den Superuser und für die Gruppe adm oder root ausreichend.

setuid Überprüfungen

Debian wird mit einem täglichen Cronjob installiert welcher in /etc/cron.daily/standard zu finden ist. Der Aufruf von /usr/sbin/checksecurity führt eine Überprüfung des Systems auf Änderungen des setuid Flags an allen Dateien auf dem System durch.

Um diesen Check zu aktivieren muß die Variable CHECKSECURITY_DISABLE in der Datei /etc/checksecurity.conf auf FALSE gesetzt sein. Dies ist auch die Voreinstellung, so das hier eigentlich keine Änderungen erforderlich sind.

chattr / lsattr

Diese beiden Kommandos sind, auf einem ext2-Dateisystem sehr sinnvoll. Mit lsattr können die Attribute einer Datei angezeigt werden, mit chattr können diese verändert werden. Attribute unterscheiden sich von Zugriffsrechten! Es gibt viele verschiedene Attribute, hier werden nur die Sicherheitsrelevanten aufgeführt. Zwei Attribute können nur vom Superuser gesetzt werden.

Zunächst wäre das „a“-Flag zu nennen. Wenn diese Attribut gesetzt ist können an die entsprechende Datei nur Daten angehängt (append) werden. Dieses Attribut kann auf einige Dateien in /var/log/ angewendet werden, beachten Sie jedoch das einige Dateien von Zeit zu Zeit rotiert werden.

Das zweite wichtige Flag ist „i“, welches für „immutable“ steht. Wenn diese Flag gesetzt wird kann eine Datei weder verändert, gelöscht oder umbenannt werden. Auch kann kein Link auf diese Datei erzeugt werden. Wenn Benutzern die Einsicht in Logdateien verwehrt werden soll, so kann diese Flag gesetzt werden und die Leserechte können entfernt werden. Dies bietet auch eine etwas höhere Sicherheit gegen Eindringlinge, da dieser sich sicher darüber wundert das die Datei nicht gelöscht werden kann. Trotzdem sollten Sie sich nicht darauf verlassen das ein Eindringling diese Funktion nicht kennt. In jedem Fall ist es ihm zu diesem Zeitpunkt bereits gelungen in das System einzudringen...

Integrität des Dateisystems

Sind Sie sicher das die, auf einem bereits seit Wochen oder Monaten ans Internet angeschlossenen System, installierten Programme noch die urspünglichen sind? Oder kann es sein das bereits das Programm /bin/login durch eine veränderte Variante ersetzt wurde, die einen unbemerkten Login als Superuser erlaubt...?

Die einzige Methode ein System gegen solche Veränderungen zu schützen, ist die installierten Dateien täglich, wöchentlich oder beispielsweise monatlich (je häufiger dieser Test durchgeführt wird, umso weniger Zeit bleibt einem Eindringling auf dem System zu agieren) mittels eine Checksumme zu prüfen und diese mit vorab gespeicherten Werten zu vergleichen.

Pakete die einen regelmäßigen Check der installierten Pakete ermöglichen sind: sXid, AIDE (Advanced Intrusion Detection Environment) und Tripwire (die aktuelle Version befindet sich im Bereich non-free, eine der nächsten Versionen wird unter der GPL stehen).

Mit dem Paket debsums können alle MD5-Checksummen der installierten Pakete mit der Original Checksumme der Dateien in den Ursprungspaketen verglichen werden.

Mittels debsums -a können alle Pakete des Systems oder aber mit debsums paketname bestimmte Pakete hinsichtlich der Checksummen überprüft werden. Hierbei ist zu beachten das es einem versierten Eindringling durchaus möglich ist auch diese Kontrolle der Checksummen zu beeinflussen. Die ursprünglichen Checksummen der Pakete liegen in den Dateien /var/lib/dpkg/info/paketname.md5sums und können von Angreifer auch angepasst werden. Eine höhere Sicherheit bietet wie schon erwähnt das Paket tripwire.

locate und slocate

Um die Sicherheit des Programmes locate zu erhöhen, kann alternativ das Programm slocate verwendet werden. slocate ist eine verbesserte Version von locate aus dem GNU Projekt. Wenn slocate verwendet wird, werden dem Benutzer nur Dateien angezeigt auf die dieser Benutzer auch tatsächlich Zugriff hat. Weiterhin können per Konfiguration auch Dateien und Verzeichnisse gezielt ausgeschlossen werde, so das diese nicht von locate in der Datenbank erfasst werden.

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 Netzwerkkompenenten 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, 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 ausschliesslich ssh und keinesfalls telnet zu benutzen. Wenn möglich deinstallieren Sie telnet. Auch sollte ein Login als Superuser unmöglich gemacht werden, um Superuser Rechte zu erlangen können die Kommandos su oder besser sudo benutzt werden.

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 Superuser:

PermitRootLogin No

Dies verhindert das per Brute-Force Angriff ein Login als Superuser möglich ist, da kein Login als Superuser erlaubt wird. Es sind nun zwei Login-Vorgänge (zunächst als Benutzer, dieser muss dann noch Superuser werden) notwendig.

Listen 666

Wenn der Port auf dem der ssh Daemon läuft verändert wird, so kann dies einen potentiellen 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 zuviel Ehrgeiz...

PermitEmptyPasswords no

Leere Passwörter sollte ebenfalls verhindert werden.

AllowUsers alex geka fr

Mit dieser Option wird nur bestimmten Benutzern der Login via ssh erlaubt.

AllowGroups wheel admin

Gleichermassen wird mit dieser Direktive nur bestimmten Gruppen der Zugriff per ssh erlaubt.

Um Benutzern oder Gruppen expliziert 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 Key wird das Passwort nicht mehr von Client zum Server übermittelt. Die Authorisierung wird anhand eines Hashes geprüft und der Client erhält lediglich die Freigabe für den Server, oder auch nicht.

Weiterhin ist der SSH Daemon so einzustellen das auschliesslich 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, welches vom OpenBSD Team entwickelt wurde. OpenSSH ist eine komplett freie Implementation eines SSH Daemons, welche sowohl ssh1 als auch ssh2 unterstützt. Wenn das Paket „ssh“ installiert wird, so wird das Paket OpenSSH gewählt.

FTP

Wenn auf dem System tatsächlich ein FTP Server installiert werden muß, so ist sicherzustellen das die Benutzer sich in einer „chroot“ Umgebung bewegen. Diese hält den Benutzer in seinem Homeverzeichnis 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 Anwendung 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 das 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 Session ü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 Displaymanager (das Programm welches einen grafischen Login beritstellt) nur auf dem lokalen System benötigt wird, so ist sicherzustellen das 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 alle Display Manager unter Debian deaktiviert.

E-Mail

Das lesen bzw. 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 Rechner 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 welcher automatisch die Verbindungen zum IMAP Server auf Port 1236 weiterreicht, verschlüsselt. 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 Daemonen 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 SSL Zertifikat.

Mittlerweile sind auch POP und IMAP Server verfügbar die über Verschlüsselungsfunktionen mittels SSL verfügen. Als Server für das POP Protokoll wäre hier apop zu nennen.

loghost - ein Server für Logdateien

Ein „loghost“ ist ein Rechner auf dem Daten aus dem Syslog verschiedener Rechner remote gespeichert werden. Wenn ein Eindringling ein System geknackt hat, so ist es ihm unmöglich die Spuren aus den Logdateien zu entfernen, ausser er knackt auch noch den loghost. Somit sollte speziell ein solcher loghost gut abgesichert sein. Um ein System zu einem loghost umzuwandeln muß 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 Systemem sind in der Datei /etc/syslog.conf folgende Einträge hinzuzufügen:

facility.level @loghost

Das Feld „facility“ kann dabei den Wert authpriv, cron, 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 Name des loghosts anzugeben.

Wenn generell alle Einträge auf dem entfernten System gelogt 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 Ergebnis zu kommen. Weitere Informationen finden sich in den Manpages zu syslog(3), syslogd(8) und syslog.conf(5).

BIND

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 daß er unter einer anderen Benutzer ID läuft. Leider kann er dann nicht mehr automatisch neue Netzwerkdevices erkennen die während des laufenden Betriebes hinzugefügt wurden, beispielsweise eine PCMCIA Netzwerkkarte in einem Notebook oder auch virtuelle Netzwerkdevices.

In der Datei README.Debian des Nameservers finden sich weitere Informationen wie BIND unter einer anderen Benutzer ID zu laufen zu bringen ist. Wenn möglich sollte darauf verzichtet werden BIND mit Superuserrechten zu benutzen.

Um BIND mit einer anderen Benutzer ID zu starten muß 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 muß 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 neuzustarten. Dabei sollten im syslog (/var/log/syslog) in etwa folgender Eintrag 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 welcher verschiedenste Angriff 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 das 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, bzw. gegen Versionen mit verschlüsselter Kommunikation ausgetauscht werden. Dies betrifft Dienste wie FTP/Telnet/NIS/RPC usw..

Auch sollte auf die Verwendung von NIS (Network Information Service) verzichtet werden. Bei einer fehlerhaften Konfiguration kann es leicht zu Sicherheitslücken kommen.

Auch sollte RPC deaktiviert werden soweit es möglich ist. Für diesen Dienst sind eine ganze Reihe von Sicherheitslücken bekannt. Natürlich wird grade 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 zu sogenannten „Agents“ oder „Handlern“ umzuwandeln.

Das deaktivieren des Portmapers 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 Portmaper in /etc/rc${runlevel}.d/. Dies kann natürlich auch auf herkömlichem Wege von Hand erledigt werden. Eine weitere, nicht ganz elegante, Möglichkeit ist es die Zugriffsrechte so zu ändern das das Script nicht mehr ausführbar ist, mittels: chmod 644 /etc/init.d/portmap. Dies würde jedoch zu einer Fehlermeldung beim Start des Systems führen.

Natürlich macht 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, 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 gewünschten Kernel eingeflossen ist. Auch erhebt die 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-Descriptoren ändern und einiges andere verändern. Momentan werden Kernel der Serien 2.0, 2.2 und 2.4 unterstützt. Detailierte Informationen finden sich 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. Zum Einsatz von LIDS auf Debian GNU Systemen gibt es eine spezielle Seite im Netz unter http://netzwurm.cc/computer/lids.html. Dort findet sich neben einem vorkonfigurierten Kernel auch ein Paket mit dem Administrationstool. Dieser Patch findet sich auf der Homepage des Projektes 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 um den Zugriff auf Dateien detailierter beschränken zu können. http://acl.bestbits.at

• Linux trustees. Mit diesem Patch wird ein erweitertes System mit Zugriffsrechten dem Kernel hinzugefügt. Alle Objekte werden im Kernel Speicher gehalten, so das ein schneller Zugriff möglich ist. Homepage: http://www.braysystems.com/linux/trustees.html.

• International kernel patch. Dieser Patch implementiert cryptografische 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.immunix.org/subdomain.html.

• UserIPAcct. Dieser Patch bezieht sich nicht direkt auf die Sicherheit eines Systems, erhöht aber die Komtrolle über die unberechenbaren Benutzer. Hiermit können Quotas, bezogen auf den Benutzer, für den Netzwerktraffic vergeben werden. Statistiken sind ebenfalls verfügbar. Homepage: http://rsmeyers.3ti.org/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 Network) 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.

Weitere Möglichkeiten

Im folgenden einige Gedanken wie bisher gesagtes weiterhin umgesetzt werden kann.

PAM ist durch den modularen Aufbau in der Lage die verschiedensten Authentifizierung Medien zu nutzen. Wie wäre es mit einem Scanner für Fingerabdrücke oder einem Iris-Scanner?

Alle bisherigen Logfiles wurden auch in Files 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.

Kernel Module: wenn möglich sollten alle Kernel Treiber nicht als Module übersetzt werden. Dann kann die Möglichkeit Module zu laden komplett deaktiviert werden. So können viele Angriffe abgewehrt werden. Auch hier gilt: nicht benutzte Funktionen sind abzuschalten.