Harte Zeiten! (1) - Linux härten

von Jörg Frühbrodt, IT-Consultant

erschienen in LinuxEnterprise 7/2001, Software & Support Verlag, Frankfurt a.M.

Linux genießt zu Recht einen guten Ruf als sicheres Betriebssystem. Auf diesen Lorbeeren können sich Netzwerkadministratoren allerdings nicht ausruhen. Konfigurations- und Softwarefehler werden schnell zum Einfallstor für ungebetenen Besuch. Dies gilt natürlich besonders für Internet-Server und Unternehmensnetze. Aber auch kleine und mittlere Unternehmen werden immer öfter zum Ziel, seit eine DSL-Standleitung erschwinglich geworden ist. Diese Serie zeigt, wie sich jeder wirksamer vor Schäden durch Hacker und Script Kiddies schützen kann.

Natürlich denkt jeder beim Thema Sicherheit sofort an Firewalls und Intrusion Detection. Aber schon durch die geschickte Linux-Konfiguration wird das Risiko, zum Opfer zu werden, deutlich vermindert. Dieser erste Teil behandelt deshalb bewährte, wirksame Sicherheitsmaßnahmen mit geringem Aufwand, die nicht nur auf Firewalls und Internetservern genutzt werden können. Der zweite Teil der Serie beschreibt tiefere Eingriffe in das System, während im letzten Teil die Erkennung von Angriffen und Abwehrmaßnahmen im Vordergrund stehen. Setzt man alle Maßnahmen konsequent um, erhält man ein "hartes" Linux als sichere Basis für eine Firewall oder einen Internet-Server.

Stabiles Fundament

Die einfache Linux-Standardinstallation macht Umsteigern den Einstieg in dieses komplexe Betriebssystem sehr leicht, indem es grafische Benutzeroberflächen, Anwendungssoftware und Tools im Umfang mehrerer hundert Megabytes installiert und alle möglichen Netzwerkdienste startet. Auf einem alleinstehenden PC ist dies durchaus tolerierbar. Ein Unternehmen sollte dagegen den minimalistischen Ansatz wählen: Es wird nur installiert, was unbedingt für die Geschäftsprozesse benötigt wird: "Was nicht vorhanden ist, kann auch nicht zum Sicherheitsproblem werden oder Administrationskosten verursachen."

Eine gut geplante Installation ist die Voraussetzung für ein sicheres, stabiles System. Für eine Firewall oder einen Internet-Server wählt man die Minimalkonfiguration. Die SuSE-Distribution enthält bereits eine vordefinierte Konfiguration für Demilitarisierte Zonen (DMZ). Um jedes Risiko sicher auszuschließen, darf der betreffende Rechner während der Installation nicht mit dem internen Netzwerk und schon gar nicht mit dem Internet verbunden werden. Die während der Installation bei einigen Distributionen angebotene MD5-Verschlüsselung und Shadow-Passworte nehmen wir gerne an.

Für Serverdienste empfiehlt es sich, die Source-RPMs anstatt der Binary-RPMs zu installieren. Üblicherweise sind bei letzteren während der Kompilierung alle möglichen Optionen mit übersetzt worden, um die Installation und Anwendung der Software zu vereinfachen. Die wenigsten Möglichkeiten einer Software werden später auch wirklich genutzt. Deshalb gilt auch hier der bereits erwähnte minimalistische Grundsatz. So bleibt das System und seine Funktionen übersichtlich, die Zahl der möglichen Angriffspunkte verringert sich ebenso wie die Anzahl der Logbucheinträge. Unregelmäßigkeiten, die auf einen Eindringling hinweisen können, fallen schneller auf.

Scheibchenweise

Der sicherste Aufbewahrungsort für ein Betriebssystem -insbesondere auf Firewalls- ist natürlich ein Read-Only-Medium wie die CD-ROM. Die individuelle Konfiguration würde dann auf einer Diskette platziert und kann dort durch den Schreibschutz gesichert werden. Bliebe noch das Problem der Hauptspeicherauslagerung (SWAPing), das sich durch eine RAM-Disk lösen lässt. Vom Standpunkt der Sicherheit ist dies eine unglückliche Lösung, da sich in den ausgelagerten Daten für Angreifer wertvolle Informationen verbergen können. Zwar gibt es den International Kernel Crypto Patch, den Gerätetreiber PPDD und das Crypto File System CFS, die aber bisher keinen Eingang in den offiziellen Kernel gefunden haben.

Leider wird immer häufiger selbst auf Servern nur noch eine Partition angelegt. Da das Dateisystem eine baumartige Struktur hat, kann ein schwerwiegender Fehler im Dateisystem große Abschnitte beeinträchtigen. In diesem Fall ist fast immer eine zeitaufwändige Neuinstallation nötig. Unterteilt man das Dateisystem aber in mehrere Teile, bleiben Datenverluste lokal begrenzt. Das Zurückspielen einer hoffentlich vorhandenen Sicherheitskopie einer einzelnen Partition geht wesentlich schneller von der Hand als eine Neuinstallation.

Über die notwendige Größe der einzelnen Partitionen gibt es eine Vielzahl von Meinungen. Sie hängt natürlich immer auch von der späteren Anwendung des Rechners ab. Eine Firewall benötigt beispielsweise keine eigene Home-Partition, während ein Proxy-Server eine eigene Cache-Partition haben sollte. In der Praxis haben sich diese Werte für eine Firewall mit Linux-Minimalkonfiguration bewährt:

/               256MB
/boot           10MB
/usr            512MB
/tmp            256MB
/var            256MB
<swap>          (mindestens Hauptspeichergröße)

Daneben machen mehrere Partitionen mit selbstständigen Dateisystemen das System sicherer. Durch Editieren der Datei/etc/fstab werden je nach Aufgabe der Partition die Rechte vergeben:

/dev/sda3       /usr    ext2    defaults,ro,nodev 1     1
/dev/sda7       /tmp    ext2    defaults,noexec,nosuid,nodev 1  2
/dev/sda8       /home    ext2   defaults,noexec,nosuid,nodev 1  2

Damit sich nicht ohne Hindernisse neue oder manipulierte Programme in/usr ablegen lassen, wird mit dem Parameterro nur lesender Zugriff erlaubt und das Erzeugen von Gerätedateien mit nodevunterbunden. Das Schreiben auf die Partition /tmp darf nicht verhindert werden, weil viele Programme hier ihre temporären Daten zwischenlagern. Dafür verbieten wir dort das Ausführen von Programmen mitnoexec. Keinesfalls darf das Paket suidperlinstalliert sein, mit dessen Hilfe sich dieses Hindernis nehmen lässt. Für ein /home-Verzeichnis auf einem Server sind die gleichen Einstellungen wie für /tmpempfehlenswert.

Häufig wird für FTP- und DNS-Server eine weitere Partition eingerichtet, in der mit Hilfe deschroot-Mechanismus die Serversoftware abläuft. Die Partition wird zum Wurzelverzeichnis des Server-Prozess und auf alle übrigen Dateisysteme kann er nicht mehr zugreifen. Da er nun quasi eingesperrt ist, wird diese Technik auch als chroot jail bezeichnet.

Flickwerk

Im Anschluss an die Basisinstallation werden notwendige Patches und Updates eingespielt. Die nötigen Dateien und Informationen lädt man über einen weiteren Rechner von den FTP-Servern der Distribution oder deren offiziellen Mirrors -und nur von dort. Am besten brennt man sie gleich auf eine CD, nachdem man die md5-Checksummen mit

md5sum <name-der-datei.rpm>

überprüft hat. Diese Checksumme erhält der eifrige Systemadministrator über die Update- und Security-Mailinglisten mitgeteilt, die er natürlich nicht nur abonniert hat, sondern auch regelmäßig liest. Diese Emails sind ihrerseits signiert, um die Authentizität sicherzustellen. Die absolute Gewissheit einer unmanipulierten Datei ergibt sich also erst, wenn auch diese Signatur überprüft wurde. Noch nicht installierte RPM-Pakete lassen sich außerdem mit

rpm -v --checksig --nogpg <name-der-datei.rpm>

testen. Wem dies nicht ausreicht, kann das in den SuSE-Announcements beschriebene Verfahren anwenden.

Aufräumarbeiten

Ein besonderes Sicherheitsrisiko stellen Programmdateien mit gesetzem S-Bit dar. Sie sind mit

find / -type f \( -perm -04000 -o -perm -02000 \)  -exec ls -lg {} \;

leicht zu finden. Diesen Dateien des Minimalsystems wird das S-Bit entzogen:

-rwsr-xr-x    1 root     shadow      34460 Jan 19 09:50 /usr/bin/chage
-rwsr-xr-x    1 root     shadow      28184 Jan 19 09:50 /usr/bin/chfn
-rwsr-xr-x    1 root     shadow      26000 Jan 19 09:50 /usr/bin/chsh
-rwsr-x---    1 root     trusted     37076 Jan 19 09:50 /usr/bin/gpasswd
-rwsr-xr-x    1 root     root        21432 Jan 19 09:50 /usr/bin/newgrp
-rwsr-xr-x    1 root     shadow      26780 Jan 19 09:50 /usr/bin/passwd
-rwsr-xr-x    1 root     root        67236 Jan 25 15:20 /bin/mount
-rwsr-xr-x    1 root     root        34568 Jan 25 15:20 /bin/umount

user@myhost $ ls -l /etc/shadow /etc/passwd /usr/bin/passwd
-r--------   1 root     root          659 Jun 25 19:43 /etc/shadow
-rw-r--r--   1 root     root          711 Jun 25 19:42 /etc/passwd
-r-s--x--x   1 root     root         15613 May 27 12:09 /usr/bin/passwd

user@myhost$ ls -l /usr/bin/wall
-r-xr-sr-x   1 root     tty          6524 May  9 10:12 /usr/bin/wall 

In den Dateien /etc/passwd und /etc/groupfinden sich insbesondere bei der SuSE-Distribution zahlreiche Benutzeraccounts bzw. Gruppen, die für mitgelieferte Anwendersoftware benötigt werden. Sie verbleiben dort, auch wenn die Software nicht installiert oder gelöscht wurde. Hier nur einige Beispiele aus /etc/passwd:

informix:x:43:34:Informix Database Admin:/usr/lib/informix:/bin/bash
fixlohn:x:58:53:Linux Fincancial Suite fixlohn:/opt/fsuite/home/fixlohn:/bin/ksh
adabas:x:36:100:Adabas-D Database Admin:/usr/lib/adabas:/bin/bash

Wenn Sie sich sicher sind, können diese Accounts und Gruppen mit demuserdel- bzw. groupdel Kommando entfernt werden. Die Benutzergruppewheeldarf nicht gelöscht werden. Sie wird später noch benötigt, um die Anwendung des Befehls su zu verhindern.

Die Standardeinstellung für vom Anwender erzeugte Dateien ist die umask 022. In Folge hat seine Benutzergruppe und der Rest der Welt Leserechte auf alle neuen Dateien! Wünscht man eine globale Änderung dieses Problems, kann man in der Datei /etc/profile den Befehl umask auf den Wert 027 oder besser 077 ändern.

Je weniger Informationen der potenzielle Angreifer über das Netzwerk erhält, umso geringer sind seine Erfolgsaussichten. Die Dateien /etc/issue oder /etc/issue.netlöschen wir, da sie mitunter schon vor einem Login Informationen über das verwendete Betriebssystem und den Patchlevel geben.

SU verhindern

Mit dem Programm su (substitute user) kann ein Benutzer mit Kenntnis des entsprechenden Passworts aus der Sicht des Systems seine Identität wechseln und Rechte als Superuser erhalten. Das kann verhindert werden: In der Datei /etc/pam.d/suwird diese Zeile auskommentiert:

#auth   required        /lib/security/pam_unix.so       nullok #set_secrpc

und durch

auth    required        /lib/security/pam_wheel.so group=wheel

ersetzt. Ein Versuch, mit su - Superuser-Rechte zu bekommen, wird nach einigen Sekunden Wartezeit mit einer Fehlermeldung abgewiesen.

Unnötiger Ballast

Es gibt Software für Linux, die aufgrund systembedingter Mängel oder ihrer Funktion nicht für sensible Bereiche geeignet ist. Mit ihrer Hilfe könnte ein Eindringling das Netzwerk leicht auskundschaften und weiter vordringen. Auf keinen Fall sollte in der SuSE-Distribution das Paket nkitbinstalliert sein, das die berüchtigten R-Befehle und Telnet enthält. Auch grafische Benutzeroberflächen oder FTP-Clients werden besser erst gar nicht installiert. Im grauen Kasten ist ein Vorschlag für eine Minimalkonfiguration abgedruckt. Einige Dateien müssen nun noch von Hand entfernt werden:

/usr/sbin/nscd 
/usr/sbin/clnt.pcnfsd
/usr/sbin/rcpcnfsd
/usr/sbin/rpc.pcnfsd
/usr/sbin/rcrouted
/usr/sbin/rcxdm

Der Name Service Cache Daemon nscd ist überflüssig, da in Grenznetzen häufig der DNS-Server BIND8 als DNS-Proxy eingesetzt wird. Auch pcnfsd, rcroutedund rcxdm werden in einem Grenznetz nicht gebraucht.

Init-Skripte

Im Verzeichnis /etc/init.d finden sich die Shell-Skripte, die während des Bootvorgangs u.a. Netzwerkdienste starten. Die bereits genannten Programme sind zwar schon gelöscht, die dazugehörigen Skripte entfernen wir sicherheitshalber auch:

nfs
nscd
pcnfsd
routed (nicht zu verwechseln mit route!)
xdm

Alle übrigen Skripte haben merkwürdigerweise Leserechte für Jedermann, die wir mit

chmod 700 <init-skript> 

korrigieren.

inetd

Der inetd ist für den Start von Netzwerk-Diensten verantwortlich, die er als Antwort auf eine Anfrage aus dem Netzwerk startet und dann wieder beendet. Diese Strategie führt auf frequentierten Servern natürlich zu Leistungseinbußen. Im nächsten Teil dieser Serie werden deshalb Alternativen zu inetd vorgestellt, die professionellen Ansprüchen hinsichtlich Leistung und Sicherheit genügen. Da er trotz dieser Nachteile häufig verwendet wird, beschränken wir uns vorläufig auf eine verbesserte Konfiguration, die für einen einzelnen, über eine Wählleitung mit dem Internet verbundenen PC oder kleinen Kommunikationsserver ausreicht. Sie findet sich in der Datei/etc/inetd.conf und hat häufig Leserechte für Jedermann, was wir sofort ändern:

chmod 600 /etc/inetd.conf

Dann kommentieren wir diese Dienste aus:

#time    stream  tcp     nowait  root    internal
#time    dgram   udp     wait    root    internal
#ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd
#telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd
#shell   stream  tcp     nowait  root    /usr/sbin/tcpd  in.rshd -L
#login   stream  tcp     nowait  root    /usr/sbin/tcpd  in.rlogind
#talk    dgram   udp     wait    root    /usr/sbin/tcpd  in.talkd
#ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  in.talkd
#finger  stream  tcp     nowait  nobody  /usr/sbin/tcpd  in.fingerd -w
#swat    stream  tcp     nowait.400      root    /usr/sbin/swat  swat

Damit der inetd die neuen Einstellungen übernimmt, geben wir ihm abschließend das Signal zum Lesen seiner Konfigurationsdatei:

killall -HUP inetd

TCP-Wrappers

Sowohl SuSE 7.1 als auch Redhat 7.0 verwenden den von Wietse Venema entwickelten TCP-Wrapper tcpd. Anstatt einen Verbindungswunsch direkt an den Dienst zu übergeben, reichtinetd diesen zunächst an dentcpd weiter. Dieser prüft, ob die Verbindung von einem vertrauenswürdigen Rechner stammt. Trifft diese Bedingung zu, gibt der tcpd die Verbindung an den Netzwerkdienst weiter. Der TCP-Wrapper wird durch diese zwei Dateien kontrolliert. In/etc/hosts.deny wird mit der Zeile

ALL:ALL@ALL,PARANOID

jeder Zugriff auf den Rechner unterbunden, um dann das absolute Verbot in der Datei /etc/hosts.allow für bestimmte Hosts wieder zu lockern:

sshd:194.32.32.1 gw.pomme.fr

Benutzerverwaltung

Einige Leser werden sicher angesichts dieses Themas gelangweilt die Augen verdrehen. Wie notwendig gute Passworte sind, wird durch die ständig steigende Zahl von Angriffen aus den eigenen Reihen eines Unternehmens deutlich. Nur etwa 20% aller Angriffe kommen tatsächlich aus dem Internet. In der Praxis werden aber selbst auf Servern als Superuser-Passwort der Name des Unternehmens oder andere leicht zu erratende Begriffe benutzt. Als Argument wird immer wieder genannt, dass sichere Passworte schwer zu merken seien. Eine "Eselsbrücke", die durchaus einen privaten Bezug haben kann, erleichtert die Erinnerung:

Luisa isst jedenMorgen 2! gekochteEier.

Als Passwort ergibt sich LijM2!gE. , das auch einer Überprüfung durch

echo 'LijM2!gE.' | vpass -nouser

standhält. Das Programm vpass aus der SuSE-Distribution testet das Passwort mit Hilfe dercracklib. Damit testet diese Distribution sinnvollerweise auch die Passworte der Benutzer. Cracklib enthält eine Reihe von Funktionen, die zu einfache Silbenkombinationen bemängelt und das Passwort gegen ein Lexikon bekannter Worte vergleicht. Idealerweise sollte es mindestens acht Zeichen haben und nach einem bestimmten Zeitraum ersetzt werden. Erzwingen lässt sich das durch das Editieren der Datei /etc/login.defs:

PASS_MIN_LEN 8
PASS_MAX_DAYS 30

Keinesfalls benutzen wir das Passwort auf anderen als den von uns administrierten Systemen oder gar für eines der Online-Multiuser-Ballerspiele.

Gelegentlich ist es sicher jedem schon einmal passiert: Nachdem die Konfigurationsarbeit als Superuser beendet ist, entfernt man sich vom Terminal ohne sich auszuloggen. Das kann Linux für uns nachholen. In der Datei .bashrc fügen wir diese Zeile hinzu:

TMOUT=300

Nach fünf Minuten der Inaktivität beendet sich die Bash-Shell selbst. Steht auch anderen Benutzern eine Shell zu Verfügung, kann diese Änderung in /etc/profilevorgenommen werden. Bei dieser Gelegenheit wird geprüft, ob die Restricted Shell /usr/bin/rbash für den gemeinen Anwender ausreicht. Sie verhindert u.a. das Verlassen des Benutzerverzeichnis.

Vorschau

In zweiten Teil der Serie sind Sicherheitsmaßnahmen auf Kernel- und Netzwerkebene das zentrale Thema. Es werden Kernelpatches und Daemons vorgestellt, die einige Sicherheitsschwächen beheben. Der Praxisteil zeigt anhand von beispielhaften Konfigurationen die vielen neuen Möglichkeiten auf.

Weitere Artikel zu ähnlichen Themen

Harte Zeiten! (2)

Harte Zeiten! (3)

Literatur & Links

Building Internet Firewalls, 2nd Edition, O'Reilly Verlag, Practical UNIX and Internet Security, 2nd Edition, O'Reilly Verlag

File System considerations in Linux: www.securityportal.com/lskb/10000000/kben10000036.html

Internet Firewalls FAQ: http://www.interhack.net/pubs/fwfaq/

Linux Security Administrators Guide: http://nic.com/~dave/Security/

Securing and Optimizing Linux: http://www.linuxdoc.org/guides.html

International Kernel Crypto Patch: http://www.kernel.org

PPDD: http://linux01.gwdg.de/~alatham/ppdd.html