Der zweite Teil der Artikelserie „Systemsicherheit unter Debian GNU/Linux“ informiert, an welchen Stellen ein Debian-System noch sicherer gemacht werden kann. Dabei behandelt der Artikel insbesondere die Maßnahmen nach der Installation des Betriebssystems. Die Themengebiete reichen von der Absicherung des Bootloaders über die Modifikation der Pluggable Authentication Modules (PAM) bis hin zur Anpassung verschiedener Systemdienste.
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 |
Erhöhung der Systemsicherheit nach der Installation |
|
Teil 3 |
Weitere Details zur Maximierung der Systemsicherheit im Betrieb |
|
Teil 4 |
Debian Sicherheitsupdates
Sobald eine neue Sicherheitslücke in einem Debian-Paket oder einer Software dieses Pakets bekannt wird, wird von den Paket-Maintainern innerhalb weniger Stunden oder Tage ein Update der betroffenen Pakete bereitgestellt. Das aktualisierte Paket wird unter http://www.debian.org/security/ zur Verfügung gestellt.
Um auch die Sicherheitsupdates bei jeder Aktualisierung des Systems automatisch durchzuführen, muss 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 kryptographischer 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.
Pluggable Authentication Modules (PAM)
PAM erlauben es dem Systemadministrator auszuwählen, auf welche Weise die verschiedenen Programme eine Authentifizierung durchführen sollen. Hierzu muss jedes Programm an 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 jedes Programm 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. Wenn Sie Einstellungen von PAM verändern, sollten Sie also größte Vorsicht walten lassen. Eine typische Konfigurationszeile enthält in der zweiten Spalte ein Kontrollfeld. Dieses sollte auf den Wert „required“ gesetzt werden, so dass bei einem Fehler in einem Modul ein Login verhindert wird.
Password Required
Zuerst sollte die Unterstützung für MD5-verschlüsselte Passwörter aktiviert werden, um zu verhindern, dass 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, das 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 drei 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.
Anmeldung an Terminals
Um den Zugriff so zu beschränken, dass der Benutzer root sich lediglich an einem lokalen Terminal anmelden kann, muss die folgende Zeile in der Datei /etc/pam.d/login aktiviert werden:
auth requisite pam_securetty.so
Weiterhin müssen die Terminals, 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, muss 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 muss 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. Schlussendlich sollte die Zeile in etwa wie folgt aussehen:
password required pam_unix.so nullok obscure min=6 max=11 md5
PAM-Kommandos
Wenn das Kommando su so geschützt werden soll, dass es nur von bestimmten Benutzern ausgeführt werden kann, muss zunächst eine neue Gruppe dem System hinzugefügt werden. Üblich ist es, hierzu die Gruppe „wheel“ zu verwenden, da diese üblicherweise noch nicht existiert und es somit unwahrscheinlich ist, dass bereits Dateien zu dieser Gruppe gehören. Dieser Gruppe fügen Sie das Benutzerkonto root sowie alle Benutzerkonten hinzu, die das Kommando su ausführen können sollen. In der Datei /etc/pam/su ist dann folgender Eintrag zu ergänzen:
auth requisite pam_wheel.so group=wheel debug
Somit wird sichergestellt, dass 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, dieses 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 muss dieser in die Datei /etc/sshusers-allowed eingetragen werden, und folgender Eintrag muss 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äe der Datei /etc/pam.d/other hinzuzufügen:
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, denn es werden grundsätzlich erstmal alle PAM-Zugriffe verweigert.
Sie sollten auch einen aufmerksamen Blick in die Datei /etc/security/limits.conf werfen. Hier werden Ressourcen für die Benutzer des Systems festgelegt.
Anpassungen der Datei /etc/inetd.conf
Generell sollten alle nicht benötigten Dienste auf einem System deaktiviert werden. Jeder laufende, nicht unbedingt benötigte Dienst stellt ein potenzielles Risiko dar. Dies betrifft beispielsweise die Dienste echo, charges, discard, daytime, time, talk, ntalk sowie die extrem unsicheren „r“-Kommandos wie rsh, rlogin und rcp. Für letztere ist es in jedem Fall besser, die Kommandos ssh und scp zu benutzen.
Nachdem die nicht benötigten Dienste deaktiviert sind, sollte geprüft werden, ob der Dienst inetd überhaupt noch benötigt wird. Dienste können natürlich auch als Daemon gestartet werden, statt inetd zu benutzen. „Denial of Service«-(DoS-)Angriffe können auch auf den inetd als Ziel ausgeführt werden und so beispielsweise die Systemlast eines Rechners in die Höhe treiben. Wenn Sie trotzdem nicht auf den Einsatz eines solchen Dienstes verzichten können, so sollten Sie unter Umständen eine Alternative zu inetd einsetzen, die vielfältiger konfiguriert werden kann, beispielsweise den xinetd oder den rlinetd.
Veränderungen an der Datei /etec/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.
Beispiel:
/usr/sbin/update-inetd --disable telnet
/etc/init.d/inetd restart
Nach jeder Änderung ist der inetd noch neu zu starten.
Das Kommando update-ineted
Das Kommando update-inetd kennt noch viele andere Optionen, beispielsweise auch, um Einträge zu löschen:
sushi:/home/fr# update-inetd
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).
Die Datei /etc/login.defs
Hier 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, muss der Benutzer 10 Sekunden warten, bis ein neuer Login-Versuch gestartet werden kann. Dies frisst 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 auch diese Variable auf yes gesetzt werden. Diese Einstellung schreibt auch unbekannte Benutzernamen bei einem Login-Versuch ins Logfile. Es ist darauf zu achten, dass die entsprechende Logdatei nicht von allen Benutzern gelesen werden kann, da Benutzer häufig anstelle des Benutzernamens das Passwort eingeben. Damit andere Benutzer die Logdatei 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 (Ausführen eines Kommandos mit der ID einer anderen Benutzergruppe).
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, sollten Sie vor dem Aktivieren dieser Option einen Blick in die Dokumentation 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.
Die Datei /etc/ftpusers
Diese Datei enthält eine Liste der Benutzer, die sich nicht per FTP-Protokoll einloggen dürfen. Benutzen Sie diese Datei nur, wenn Sie wirklich sicher sind, dass auf dem System auch 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 wurden entwickelt, als noch keine echten Paketfilter verfügbar waren, aber trotzdem eine Kontrolle notwendig wurde. Ein TCP-Wrapper erlaubt oder verbietet einem Rechner oder einer Domäne das Nutzen eines Dienstes. Nähere Informationen finden Sie in der Manpage hosts_access(5).
Im Folgenden sehen Sie vielleicht das kleinste System, um Einbruchsversuche zu registrieren. Auf alle Fälle sollte auf jedem System eine Firewall installiert sein, zusätzlich zu diesem TCP-Wrapper. Dieser kleine Eintrag in die Datei /etc/hosts.deny schickt bei jedem verweigerten Zugriff auf einen Service eine Mail an den Administrator.
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 wiederum einem DoS-Angriff gleichkommt.
Ausblick
Im dritten Teil der Artikelserie wird die Abwandlung von Diensten zur Maximierung der Systemsicherheit fortgeführt. Neben Dateien erläutert dieser Teil auch den Einsatz von entsprechenden Kommandos sowie die Benutzung von Quota und die Prüfung der Integrität des Dateisystems.
Der vierte und letzte Teil erklärt, wie Sie spezielle Dienste in einer entsprechenden Umgebung sicher Einsetzen können. Neben der Secure Shell (SSH) werd 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. (hal)