Zunächst müssen Sie sich darüber im klaren sein das ein System nur dann
100%tig sicher ist wenn keinerlei Dienste auf diesem nach aussen hin über das
Netzwerk angeboten werden oder sogar garkeine Verbindung zu einem Netzwerk
besteht. Dies ist in der
Realität natürlich unsinnig und nicht durchsetzbar, das System würde so nicht
sinnvoll benutzbar sein.
Man sollte sich auch darüber im klaren sein das die Anforderungen an die
Sicherheit stark vom Einsatz des Systems abhängig sind. Ein Privatnutzer wird
deutlich andere Anforderungen stellen wie der Administrator eines Firewall
Systems. Viele Einstellungen die die Sicherheit eines Systems erhöhen
vereinfachen die Bedienung nicht unbedingt, auch hier ist zwischen
Benutzbarkeit und Paranoia abzuwägen.
Die Softwareseitigen Einstellungen an einem Debian System die zur Verbesserung
der Sicherheit dienen, können nicht den physikalischen Zugriff auf das System
verhindern. Wenn von Systemsicherheit die Rede ist muß auch bedacht werden das
zu einem völlig sicheren System auch gehört das der Zugriff auf die Hardware
unterbunden wird. Ein Angreifer der Zugriff auf die Hardware hat kann
beispielsweise über eine Boot-CD oder Diskette Zugriff auf das System erlangen.
Auch ein BIOS- oder Lilo-Passwort kann den Diebstahl der Festplatte nicht verhindern. Ein
völlig sicheres System gehört also hinter gut verschlossene Türen. Doch
Betrachtungen zur Hardwaresicherung sollen an dieser Stelle nicht weiter
verfolgt werden.
Nachdem das System mit allen benötigten Programmen eingerichtet ist, kann mit
einigen weiteren Aktionen die Sicherheit des Systems weiter erhöht werden.
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.
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).
|
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.
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.