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

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

Die Einteilung des verfügbaren Festplattenplatzes hängt von der Verwendung des Systems ab. Hierzu sollten Sie einige Dinge beachten:

Während der Installation wird nach einem Passwort für den Administrator (root) gefragt. Zusätzlich kann ein Konto für einen „normalen“ Benutzer dem System hinzugefügt werden; für diesen ist dann ebenfalls 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 Passworts 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 Zugangskonto für den Administrator auch mindestens ein solches Konto für einen Benutzer angelegt werden, das nicht über alle Rechte verfügt. Dieses Benutzerkonto sollte für grundsätzlich alle Logins bzw. Arbeiten auf dem System verwendet werden. Nur wenn für eine bestimmte Aufgabe die Zugriffsrechte nicht ausreichend sind, sollten Sie mit dem Kommando su die Identität wechseln. Nach Beendigung der Arbeiten als Administrator sollten Sie sich umgehend wieder als „normaler“ Benutzer im System bewegen.

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 Administrator 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.

Wie bereits beschrieben, sollten nur die absolut notwendigen Dienste auf einem System aktiviert werden. Jeder neue Dienst schafft möglicherweise ein neues Sicherheitsloch, das 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.

Lesen Sie die Debian Security-Mailinglisten. Informationen zu den verfügbaren Listen finden Sie unter http://lists.debian.org/debian-security-announce/. Dort ist auch beschrieben, wie Sie sich an einer solchen Liste an- und abmelden. Relevant sind in diesem Zusammenhang debian-security-announce, dort werden Sicherheitslücken bekannt gegeben, und Sie werden über Bugfixes dagegen informiert. Eine weitere Mailingliste zum Thema ist debian-security@lists.debian.org, dort werden alle Sicherheitsthemen 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 an dieser Mailingliste ist auch über die Webseite http://www.debian.org/MailingLists/subscribe möglich.

Auf dieser Mailingliste erhalten Sie nur sehr wenige Mails, Sie werden dort aber sehr schnell über Probleme mit Paketen informiert und erfahren eine Internet-Adresse, unter der eine fehlerbereinigte Version des Pakets zur Verfügung steht.

Jede Person, die Zugang zur Tastatur des Systems hat, kann eine Administrator-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 Bootloader gesetzt werden. Dies kann global für alle Boot-Images geschehen oder individuell für jedes einzelne.

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

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

Danach muss lilo noch einmal aufgerufen werden. Sorgen Sie dafür, dass die Datei /etc/lilo.conf nur vom Administrator gelesen werden kann, da das Passwort unverschlüsselt in der Konfigurationsdatei steht; dies erreichen Sie mit dem Kommando chmod 600 /etc/lilo.conf. Die Option restricted bewirkt, dass 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 allgemein gültig für alle Kernel in der Konfiguration angegeben werden oder aber innerhalb eines Abschnitts der Konfigurationsdatei nur für bestimmte Kernel.

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

timeout 3
password hackme

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

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 auf einem alten System heute noch installiert ist, lässt sich wie folgt prüfen:

Dieses Verhalten kann wie folgt verändert werden:

lilo -b /dev/hda

(wobei hda dem entsprechenden Devicenamen Ihres Systems angepasst werden muss).

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

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, dass auf dieser Partition befindliche Programme ausgeführt werden können, und nodev ignoriert Device-Dateien. Dabei ist zu beachten:

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

Ab der Kernelversion 2.6 ist die oben beschriebene Angriffsmöglichkeit nicht mehr gegeben.

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

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://security.debian.org 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 zusätzlich 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 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.

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. Auf Systemen vor der Debian Release „Sarge“ müssen die folgenden Zeilen in allen Dateien in /etc/pam.d/ hinzugefügt werden, die Zugang zu dem System erlauben. Ab der Debian Version „Sarge“ existiert die Datei /etc/pam.d/common-password, in der bereits die notwendigen Zeilen vorhanden sind, bei diesen Zeilen muss lediglich das Kommentarzeichen entfernt werden.

Auf älteren Systemen sind beispielsweise die Dateien login und ssh anzupassen.

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.

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

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äge 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 zunächst 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.

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 Dämon 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 /etc/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-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).

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.

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-Dämon PAM unterstützt, so können auch dort die Benutzer zugelassen oder ausgeschlossen werden.

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.

Sollte es einmal notwendig sein, Arbeiten am System als Administrator durchzuführen, so kann das Kommando su benutzt werden, um die benötigten Rechte zu erlangen. Versuchen Sie, allen Benutzern klarzumachen, dass Arbeiten als Administrator 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, das eine ganze Reihe weiterer Funktionen bietet. Der Befehl su ist aber weithin bekannt, da er auch auf vielen anderen Unix-Systemen eingesetzt wird.

sudo erlaubt einem Benutzer, Kommandos unter der ID eines anderen Benutzers auszuführen, gegebenenfalls auch als Administrator. 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 Programms, werden aufgezeichnet und per E-Mail an den Administrator (root) geschickt.

Der Befehl chroot ist eine leistungsfähige Möglichkeit, um ein Programm, einen Dämon oder einen 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 Festplattenplatz beanspruchen, wenn alle benötigten Binaries und Bibliotheken in diese Umgebung kopiert werden müssen. Aber wenn es dem Benutzer gelingt, Schaden anzurichten, so bleibt dieser auf die durch das Kommando chroot definierte 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-Dämon benötigt das Binary und ein paar Bibliotheken. Hier bildet eine chroot-Umgebung eine exzellente Verbesserung der Sicherheit, falls eine Sicherheitslücke in diesem FTP-Dämon auftaucht. In diesem Fall ist lediglich die Benutzer-ID des FTP-Dämons betroffen und keine anderen Benutzer des Systems. Natürlich können auch viele andere Dienste von solch einer Umgebung profitieren.

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

Viele Funktionen des Kernels können während der Laufzeit verändert werden, beispielsweise indem mit dem Kommando echo ein Wert in die entsprechende 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 muss 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 außen wie ein Windows-System, wenn ein Broadcast-ping-Kommando das System erreicht.

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

Wenn ICMP-Pakete auf der vorgeschalteten Firewall nicht geblockt werden sollen, so ist diese Variable auf den Wert 0 zu setzen.

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

Diese Option ist ein zweischneidiges Schwert: Einerseits schützt sie gegen „Syn-Flooding“-Attacken, andererseits entspricht dies nicht den RFCs. Diese Option beschäftigt die angreifende Seite ebenso mit „Syn-Floods“, so dass diese gleichermaßen 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 Adressen, beispielsweise wegen eines fehlerhaften Routings, im Netzwerk protokolliert.

SVGAlib ist eine schöne Einrichtung für Liebhaber der Konsole. In der Vergangenheit sind jedoch immer wieder Sicherheitslücken bekannt geworden. So wurden Sicherheitslücken in zgv bekannt, mit denen Administratorrechte erlangt werden konnten. Wenn möglich, sollten Sie auf die Verwendung der SVGAlib verzichten.

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 das Programm scp zur Verfügung, das im Paket ssh enthalten ist. Hier werden sowohl der Benutzername als auch das Passwort und auch die Daten selbst in verschlüsselter Form übertragen.

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

Es können grundsätzlich zwei verschiedene Quota-Systeme eingesetzt werden: benutzer- oder gruppenorientierte Quota. Dies ist bei der Planung zu berücksichtigen.

Einige Punkte sind bei der Benutzung von Quota zu beachten:

Für jede Partition bzw. jedes Verzeichnis, auf die bzw. das Benutzer Schreibzugriff haben, sollten Quota 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 Quota: Zunächst müssen Sie prüfen, ob die Quota-Unterstützung im Kernel aktiviert ist. Wenn dies nicht der Fall ist, muss ein neuer Kernel erzeugt werden. Danach ist sicherzustellen, dass das Paket quota installiert ist.

Quota 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 müssen im Root-Verzeichnis des Dateisystems leere Dateien quota.user und/oder quota.group erzeugt werden.

Das Quota-System muss nun neu gestartet 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 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.

Einige Logdateien sind nach der Installation nicht perfekt. Zunächst ist es nicht notwendig, dass 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 Administrator und für die Gruppe adm oder root ausreichend.

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

Um diese Überprüfung zu aktivieren, muss die Variable CHECKSECURITY_DISABLE in der Datei /etc/checksecurity.conf auf FALSE gesetzt sein. Dies ist auch die Voreinstellung, so dass hier eigentlich keine Änderungen erforderlich sind.

Diese beiden Kommandos sind auf einem ext2-Dateisystem sehr sinnvoll. Die Attribute einer Datei können mit lsattr angezeigt und mit chattr 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 Administrator gesetzt werden.

Zunächst wäre das „a“-Flag zu nennen. Wenn dieses 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, dass einige Dateien von Zeit zu Zeit „rotiert“ werden (unter „rotieren“ versteht man das tägliche Umkopieren und Umbenennen von Logdateien. Dabei werden Dateien vom Vortag komprimiert. Nach einer bestimmten Zeit, meist eine Woche, werden ältere Dateien gelöscht).

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

Sind Sie sicher, dass die auf einem bereits seit Wochen oder Monaten ans Internet angeschlossenen System installierten Programme noch die ursprünglichen sind? Oder kann es sein, dass bereits das Programm /bin/login durch eine veränderte Variante ersetzt wurde, die einen unbemerkten Login als Administrator 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, desto weniger Zeit bleibt einem Eindringling, auf dem System zu agieren) mittels einer Checksumme zu dokumentieren 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 den Original-Checksummen der Dateien in den Ursprungspaketen der Distribution verglichen werden.

Mittels debsums -a können die Checksummen aller Pakete des Systems verglichen werden, wogegen Sie mit debsums <paketname> die Checksummen bestimmter Pakete vergleichen. Hierbei ist zu beachten, dass 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 vom Angreifer auch angepasst werden. Eine höhere Sicherheit bietet das Paket Tripwire.

Um die Sicherheit des Programms 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 werden, so dass diese nicht von locate in der Datenbank erfasst werden.

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, 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.

Auch die Konfiguration des ssh-Dämons 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-Dämon läuft, verändert wird, so kann dies 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.

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-Dämon so einzustellen, dass auschließ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-Dämons, die sowohl ssh1 als auch ssh2 unterstützt. Wenn das Paket „ssh“ installiert wird, so wird das Paket OpenSSH gewählt.

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 hält 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.

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.

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 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 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 Dämons müssen dann über stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd gestartet werden, wobei -l den gewünschten Dämon 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-Programm für das POP-Protokoll wäre hier apop zu nennen.

Ein „Loghost“ ist ein zentraler Rechner, auf dem Daten aus dem Syslog-Dämon 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-Dämon 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 Einträge in der folgenden Form hinzuzufügen:

<facility>.<level>            @<loghost>

Das Feld <facility> kann dabei der 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).

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 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.

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.

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 sollten Sie auf die Verwendung von NIS (Network Information Service) verzichten. Bei einer fehlerhaften Konfiguration kann es leicht zu Sicherheitslücken kommen.

Auch 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 Skript 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.

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:

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 Heimat-Verzeichnisse der Benutzer.