Workshop: Sichere Linux-Workstation

Im Internetzeitalter ist Rechnersicherheit nicht länger nur ein Thema für Server- und Netzwerkadministratoren. Flatrates und DSL-Anbindungen führen dazu, dass nicht nur klassische Webserver, sondern auch immer mehr Workstations mit semipermanenter oder fester IP-Adresse im Netz der Netze erreichbar sind. Den aus dieser Situation erwachsenden Sicherheitsproblemen sind die wenigsten Client-Betriebssysteme gewachsen.

In dramatischer Weise führt das der Zwischenfall mit dem Code-Red-Wurm vor Augen. Am 19. Juli 2001 um etwa 10 Uhr UTC tauchte im Netz die Random-Seed-Variante (CRv2) von Code Red auf. Anders als ihr zwei Tage vorher aufgetretener Vorgänger CRv1 griff sie nicht nur eine begrenzte Anzahl vorgegebener IP-Adressen an. Statt dessen versuchte CRv2 von den befallenen Rechnern aus über massive Scans alle erreichbaren Systeme zu infizieren.

Innerhalb von 24 Stunden fielen dem Wurm knapp 360.000 Rechner zum Opfer, die Infektionsrate erreichte in Spitzen bis zu 2000 Hosts pro Minute. Von diesen Rechnern befanden sich rund zwei Drittel in Providernetzen, waren also zum Großteil private Clients. Von den in Deutschland betroffenen 11.700 Maschinen stammten 5.500 aus t-dialin.net - also dem Einwahlnetz der Telekom!

Diese von der CAIDA-Studiengruppe am Supercomputer Center der UCSD erhobenen Daten führen zu klaren Schlussfolgerungen: "Der Angriff zeigt, dass auch die Rechner von Privatleuten und kleinen Gewerbetreibenden das Funktionieren des Internet erheblich beeinflussen.", warnen die Autoren einer ausführlichen Code-Red-Studie. Und weiter: "Wer seinen Rechner nicht vernünftig absichert, bringt das gesamte Netz in Gefahr."

Linux vs. Windows

Code Red war ein Windows-Wurm, der ein Sicherheitsloch des Microsoft IIS (die .ida Vulnerability) ausnutzte. Das bedeutet jedoch keineswegs, dass Linux-Rechner quasi "by design" gegen solche Gefahren gefeit wären. Ebenso gut hätten die Autoren von Code Red Linux-spezifische Schwächen als Basis ihres Schädlings verwenden können, wie die in etwa parallel zur MS-.ida-Lücke entdeckte Telnet Daemon Vulnerability .

Der große "Erfolg" von Code Red und ähnlicher Windows-Schadprogramme ist eher symptomatisch dafür, dass Microsoft-Produkte ihren Benutzer nicht gerade in idealer Weise bei der Abwehr von Bedrohungen unterstützen. Dies beweist nicht zuletzt die Tatsache, dass selbst windowsupdate.microsoft.com zu den Code-Red-infizierten Systemen zählte.

Das in bester Unix-Manier von vornherein als Netzwerk- und Multi-User-Betriebssystem konzipierte Linux glänzt mit einer ganzen Reihe eingebauter Sicherheitsmechanismen. Wir zeigen auf den folgenden Seiten, wie sich in Netzwerken - ob LANs oder dem Web - eingesetzte Rechner mit einfachen Bordmitteln gegen unberechtigte Nutzung abschotten lassen.

Sichern des Bootvorgangs

Unabhängig vom Betriebssystem beginnt der Datenschutz bei jedem Rechner schon in den BIOS-Settings: Es gilt, die Maschine gegen das Booten durch Unbefugte abzusichern. Anderenfalls besteht Gefahr, dass ein Angreifer mit physischem Zugang zum Computer sich Daten aus dem Filesystem abgreift - oder auch welche einschmuggelt, wie etwa Trojaner. Die Tatsache, dass ein bootfähiges System samt aller Werkzeuge bequem auf eine Diskette passt, verschärft diese Gefahrenmomente im Fall von Linux zusätzlich.

Daher schalten Sie am besten im BIOS ihres Rechners die Möglichkeit zum Booten von Disketten- und CD-ROM-Laufwerk aus. Zusätzlich schützen Sie das BIOS durch Vergabe eines Passworts vor der Manipulation durch Unbefugte. In vielen BIOS-Varianten lässt sich zusätzlich auch ein User-Password vergeben, ohne dessen Eingabe ein Starten des Rechners von jeglichem Bootmedium unterbunden wird.

Hundertprozentige Sicherheit erreichen Sie damit allerdings nicht. Einem potentiellen Datendieb verbleibt immer noch die Möglichkeit, den Rechner zu öffnen und das BIOS via Jumper oder schlicht durch Entnahme der Pufferbatterie zu resetten. Dagegen schützen nur Maßnahmen wie abschließbare Gehäuse. Viele BIOS-Hersteller haben zudem Master-Passworte eingebaut, die auf einschlägigen Websites zur allgemeinen Verwendung bereitliegen.

Schwachstelle LILO

Die Beschränkung der Boot-Devices und die dazugehörigen Schutzmaßnahmen am BIOS bieten allerdings unter Linux noch keinen ausreichenden Schutz gegen das Hochfahren des Rechners durch Unbefugte. Das gilt auch, wenn der Angreifer tatsächlich nur von der Festplatte booten kann. Der Grund dafür liegt in der Fähigkeit des LILO, beim Booten Systemparameter zu übergeben.

Die simpelste Möglichkeit, innerhalb weniger Sekunden vollen Zugriff auf einen Linux-Rechner zu erlangen, besteht in der Übergabe des Bootparameters init. Das am LILO-Bootprompt eingegebene Kommando

Linux boot: linux init=/bin/sh

verschafft dem Angreifer eine Shell mit kompletten root-Rechten.

Dieser Gefahr lässt sich auf zweierlei Arten begegnen: Zum einen gilt es zu verhindern, dass der Angreifer per Ctrl-Alt-Del an den Bootprompt herankommt. So können nur noch angemeldete Benutzer über init, shutdown oder reboot den Rechner neu starten. Zum anderen muss die unauthentifizierte Eingabe von Bootparametern unterbunden werden.

Ctrl-Alt-Del abschalten

Auf die finale Geierkralle Ctrl-Alt-Del lässt sich unter Linux gut verzichten. Zur Beendigung von Prozessen oder des Betriebssystems bietet sich eine Vielzahl von Möglichkeiten an, wie etwa kill, top, init oder shutdown. Diese Konsolenbefehle bieten gegenüber der aus der Microsoft-Welt gewohnten Tastenkombination einen entscheidenden Vorteil: Sie lassen sich nur von dazu autorisierten Benutzern anwenden.

Praktischerweise stellt das Abschalten des Tastenkombis den Anwender vor keinerlei größere Herausforderungen. In der Datei /etc/inittab findet sich eine Zeile etwa des Inhalts (je nach Distribution):

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

Hier gibt der letzte Part an, was das Betriebssystem beim Drücken der Tastenkombination veranlassen soll.

Anstatt des per Default vorgesehenen Shutdown kann der Anwender hier auch jedes andere Kommando eintragen. Im einfachsten Fall quittiert man Ctrl-Alt-Del mit einer Konsolenmeldung:

ca::ctrlaltdel:/bin/echo -e '\\n\\nNix da!\\n'

Alternativ lässt sich etwa ein vorbereitetes Skript aufrufen, das eine E-Mail an root absetzt und den Reboot-Versuch in einer Logdatei protokolliert.

LILO absichern

Gelangt ein Angreifer trotz aller Vorsichtsmaßnahmen bis an den Bootprompt, kann man ihm auch hier noch das Handwerk legen. Dazu gilt es, die LILO-Konfigurationsdatei zu modifizieren. Sie findet sich im Verzeichnis /etc unter dem Namen lilo.conf.

Für die Authentifizierung beim Hochfahren des Rechners stellt LILO die beiden Schlüsselworte password und restricted bereit:

password=mein_boot_passwort
restricted

Für password lässt sich ein beliebiges Kennwort vergeben, das der Bootloader vor dem Laden des Kernel-Image abfragt. Mit restricted schränkt man diesen Schutz dahingehend ein, dass LILO das Passwort nur bei der Angabe zusätzlicher Bootparameter einfordert.

Um generell jeden Bootvorgang mit einem Passwortschutz zu bewehren, tragen Sie die beiden Parameter vor der Auflistung der Kernel-Images in lilo.conf ein:

(...)
password=rootboot
restricted
#
image=/vmlinuz
(...)
#
image=/boot/vmlinuz-2.2.19
(...)

Kernel-Image und lilo.conf schützen

Alternativ können Sie jedes Image auch einzeln absichern. Im folgenden Beispiel erfordert das Laden des Default-Kernel in jedem Fall eine Authentifizierung. Beim Booten des speziell erstellten Maintenance-Kernel verzichtet LILO dagegen auf die Kennworteingabe - es sei denn, Sie geben zusätzliche Parameter an.

(...)
image=/vmlinuz
password=aktuell
(...)
image=/boot/vmlinuz-2.2.19
password=wartung
restricted
(...)

Vergessen Sie nach der Änderung der lilo.conf nicht, zur Übernahme der Einstellungen LILO aufzurufen. Um die im Klartext sichtbaren LILO-Passworte zu schützen, beschränken Sie alle Zugriffsrechte für die LILO-Konfigurationsdatei auf root. Da lilo.conf per Default ohnehin root als Owner und Group hat, genügt dazu in der Regel ein schlichtes chmod 600 /etc/lilo.conf.

Einen zusätzlichen Schutz der Konfigurationsdatei erreichen Sie durch den Befehl

chattr +i /etc/lilo.conf

Das File kann anschließend durch niemanden mehr verändert, umbenannt, gelöscht oder verlinkt werden. Lediglich root ist in der Lage, diesen Zustand bei Bedarf per

chattr -i /etc/lilo.conf

wieder aufzuheben.

Passwortschutz

Die besten Schutzmaßnahmen gegen das Booten durch nicht autorisierte Benutzer helfen allerdings nicht, wenn Sie für root- und Benutzeraccounts zu schwache Passworte vergeben. Vermutlich kennen Sie die alte Faustregel: Passworte müssen mindestens acht Zeichen lang sein, wobei sie in guter Mischung Klein- und Großbuchstaben sowie Ziffern und Sonderzeichen enthalten sollten. Und vermutlich beherzigen Sie sie nicht.

Zugegeben, wüste Ziffern-/Zeichenkombinationen sind schwer zu merken. Dennoch taugen der Vorname der Frau, die private Telefonnummer oder das Geburtsdatum nicht als Passwort. Zu leicht lassen sich derartige Merkmale schon von Fremden über Telefonbücher, Firmenunterlagen, die eigene Website oder Social Engineering herausfinden. Ihre Kollegen dagegen brauchen vermutlich nur ins firmeneigene Intranet zu schauen, um solche Informationen zu eruieren. Der Rest ist dann nur noch eine Frage der Zeit.

Einen möglichen Ausweg aus dem Dilemma zwischen gut zu merkendem und schwer zu knackendem Passwort bieten "semiprivate" Daten. Solche also, die Sie zwar im Kopf haben, die aber für andere schwer herauszubekommen sind. Der Autor etwa verwendet eine deutlich mehr als zehnstellige, des Öfteren wechselnde Variation seiner ehemaligen Bundeswehr-Personalkennziffer, gewürzt mit Sonderzeichen.

Weniger militante Zeitgenossen können als Basis des Passworts beispielsweise auf das Datum der französischen Revolution, die Telefonnummer der Schwiegermutter oder einen beliebigen Merksatz (Strickmuster: b00t?->0n1y_R00t!) ausweichen.

MD5 und Shadow

Ursprünglich benutzte Linux das Standard-Unix-Authentifizierungsverfahren, bei dem simple Hashes der Passworte direkt in /etc/passwd gespeichert und beim Login mit der Benutzereingabe verglichen wurden. Die steigende Rechenleistung moderner Computer machte dieses Verfahren jedoch mit der Zeit allzu anfällig gegen Brute-Force-Attacken. Deswegen setzen moderne Linux-Distributionen zum Schutz der Passworte MD5-Verschlüsselung und ein Shadow-File ein.

MD5 bietet nicht nur einen relativ sicheren Hashing-Algorithmus mit 128-Bit-Hashwert, sondern erlaubt auch Passworte mit mehr als acht Zeichen Länge. Shadow verlagert die Speicherung der Passworte aus der Datei /etc/passwd nach /etc/shadow, das nur für root zugänglich ist. In /etc/passwd findet sich dann statt des Passwort-Hashes lediglich ein x:

user:x:Default User,,,,:/home/user:/bin/bash

Es verweist darauf, dass das eigentliche Passwort in /etc/shadow lagert.

Die durch MD5-Hashing und das Shadow-File gesteigerte Passwortsicherheit lässt sich durch PAM noch weiter steigern.

PAM

Das Akronym PAM steht für Pluggable Authentication Modules. Diese Libraries dienen als Wrapper für Sicherheitsfunktionen, die sie allen PAM-fähigen Programmen zur Verfügung stellen. Die entsprechenden Shared-Object-Files finden sich in /lib/security. Der Hauptvorteil des PAM-Mechanismus: Um einen geänderten oder neu entwickelten Authentifizierungsmechanismus zu implementieren, genügt es, ein entsprechendes PAM bereitzustellen. Das früher notwendige Rekompilieren aller betroffenen Programme erübrigt sich damit.

PAMs gliedern sich in die vier Typen auth, account, session und password. Für die eigentliche Authentifizierung zeichnen die PAMs der Kategorie auth verantwortlich. Sie stellen (in der Regel per Passwortabfrage) sicher, dass der Benutzer auch der ist, für den er sich ausgibt. Die account-PAMs erweitern auf Basis der Benutzerkonten die Fähigkeiten der auth-Module. So lässt sich etwa der Benutzerzugriff je nach Tageszeit, Systemressourcen oder Standort des Benutzers (Konsole, IP-Adresse des Rechners) beschränken.

Die Module der Gruppe session regeln zusätzliche Aufgaben, die rund um die eine Benutzersitzung anfallen. Dazu zählen etwa das Mounten von Laufwerken oder die Protokollierung von Dateizugriffen. Zum Ändern von Authentifizierungs-Tokens wie beispielsweise des Passworts dienen password-PAMs. Üblicherweise gehört zu jedem Challenge/Response-basierten auth-Modul auch ein entsprechendes password-PAM.

PAM-Konfiguration

Jedes PAM kann nicht nur in eine, sondern auch in mehrere der Funktionsgruppen fallen. So stellt etwa pam_unix.so, das Standard-Unix-Authentifizierungsmodul, Funktionen für alle vier Aufgabengruppen zur Verfügung.

Praktisch alle aktuellen Linux-Distributionen unterstützen PAM; Caldera, Debian, Red Hat und SuSE bereits seit einiger Zeit. Die dazugehörigen Konfigurationsdaten finden sich im Verzeichnis /etc/pam.d, gelegentlich auch in der Datei /etc/pamd.conf.

Im PAM-Verzeichnis liegt für jeden konfigurierten Dienst ein eigenes File, wie etwa passwd oder login. Die Datei other dient als Fallback für nicht speziell eingerichtete Services und greift in der Regel auf pam_unix.so zurück. Nutzt die Distribution eine /etc/pamd.conf, steht dort der Name des zu konfigurierenden Dienstes am Beginn jeder Zeile, das Schlüsselwort OTHER kennzeichnet die Defaulteinstellungen. In beiden Fällen gehorchen die einzelnen Einträge der Syntax:

Modultyp Kontrollflag Modul Parameter

Beim Modultyp handelt es sich um die bereits angesprochenen Kategorien auth, account, session und password. Für jeden dieser Typen lassen sich Prüfungen durch mehrere Module einrichten, die in der Reihenfolge ihres Auftretens abgearbeitet werden. Dabei gibt das Kontrollflag an, welche Gewichtung dem jeweiligen Modul zukommt. Hier kennzeichnen required oder requisite, dass beim Fehlschlagen der Prüfung die Authentifizierung insgesamt als gescheitert gilt. Nach der erfolgreichen Absolvierung eines mit sufficient gekennzeichneten Moduls gilt die Authentifizierung als abgeschlossen, weitere Prüfungen unterbleiben. Als optional gekennzeichnete Module dienen der Abarbeitung von Aufgaben, die für die eigentliche Authentifizierung nicht kritisch sind.

Module lassen sich wahlweise mit vollem Pfadnamen oder relativ zum Basisverzeichnis /usr/lib/security angeben. Fast alle PAM verarbeiten, meist getrennt nach Modultyp, verschiedene Parameter. Eine ausführliche Beschreibung aller Werte finden Sie im Linux-PAM System Administrators Guide.

pam_cracklib

In Sachen Passwortsicherheit interessieren uns vor allen Dingen die Einträge in den Dateien /etc/pam.d/passwd und /etc/pam.d/login. Die erste steuert das Verhalten beim Ändern von Passworten, die zweite zeichnet für die Vorgänge beim Login verantwortlich. Sowohl passwd als auch login sollten folgende zwei Zeilen (in dieser Reihenfolge) enthalten:

# Zeile 1
password required /lib/security/pam_cracklib.so retry=3 minlen=8 difok=3
# Zeile 2
password required /lib/security/pam_unix.so nullok use_authtok md5 shadow

Damit erzwingen Sie über pam_cracklib.so bei allen Accounts die Verwendung ausreichend starker Passworte.

Die Bibliothek überprüft alle neuen Passworte zunächst anhand eines Dictionary auf gängige und somit leicht zu erratende Passworte. Fällt das Passwort nicht in diese Rubrik, testet pam_cracklib zusätzlich folgende Ausschlusspunkte:

• Hat das Passwort die notwendige Mindestlänge (minlen)?

• Wurden wenigstens difok oder ersatzweise mindestens 50 Prozent der Zeichen im Passwort geändert?

• Wurde das Passwort schon einmal benutzt?

• Ist das Passwort ein Palindrom eines schon vorhandenen Passworts (beispielsweise regen_nie? statt ?ein_neger)

• Handelt es sich um ein Passwort, bei dem lediglich die Groß/Kleinschreibung gewechselt wurde?

• Handelt es sich um die Rotation eines alten Passworts (etwa bcdef statt abcde)?

Nur wenn das neue Passwort alle Hürden nimmt, reicht pam_cracklib es an pam_unix weiter. Dabei erzwingt use_authtok die Verwendung des von pam_cracklib getesteten Tokens. Anderenfalls fordert pam_cracklib den Benutzer bis zu drei Mal (retry=3) zur Eingabe eines stärkeren Passworts auf.

cracklib-Dictionary

Beim Ausschluss zu schwacher Passworte stützt sich pam_cracklib.so auf die Library cracklib, die ähnlich wie Brute-Force-Crackprogramme operiert: Sie stützt sich auf eine Wortliste. Diese dient hier allerdings nicht zum Abklopfen von Accounts, sondern soll allzu leicht zu erratende Passworte ausschließen. Ein vorgefertigtes Dictionary findet sich im Verzeichnis /usr/lib in drei Dateien namens cracklib_dict mit den Endungen .hwm, .pwd sowie .pwi. Diese Files lassen sich über die mit cracklib gelieferten Dienstprogramme aus ASCII-Wortlisten mit je einem Eintrag pro Zeile generieren. Als Standard-Wortliste dient dabei die Datei /usr/dict/words.

Je nach Distribution gestaltet sich die Ergänzung des Dictionary um eigene Einträge mehr oder weniger aufwendig. So erstellt Debian über ein cron-Skript das Wörterbuch täglich aus den Wortlisten in den Verzeichnissen /usr/dict und /usr/share/dict neu. Bei Red Hat Linux oder SuSE dagegen muss der Administrator diese Arbeit manuell erledigen. SuSE liefert immerhin ein Skript namens create-cracklib-dict, das die notwendigen Aufrufe für eine als Parameter anzugebende ASCII-Wortliste automatisch erledigt. Bei Red Hat lautet die entsprechende Kommandozeile:

/usr/sbin/mkdict /usr/dict/words | /usr/sbin/packer /usr/lib/cracklib_dict

Dabei entfernt mkdict Doubletten und Kontrollzeichen aus der als Parameter angegebenen Liste und schreibt das Ergebnis sortiert auf die Standardausgabe. Das Utility packer erwartet eine derart formatierte Liste an der Standardeingabe und erzeugt daraus die drei von cracklib benötigten Files mit dem als Parameter angegebenen Namen und den Endungen .hwm, .pwd sowie .pwi

pam_securetty und pam_nologin

Über PAMs können Sie nicht nur die Vergabe sicherer Passworte erzwingen, sondern auch das Login selbst zusätzlich schützen. Das gilt speziell für den kritischen root-Account. Dazu sollte /etc/pam.d/login gleich zu Anfang die folgenden zwei Zeilen enthalten:

# Zeile 1
auth required /lib/security/pam_securetty.so
# Zeile 2
auth required /lib/security/pam_nologin.so

Das Modul pam_securetty beschränkt das Login von root auf jene Konsolen, die ausdrücklich in der Datei /etc/securetty erfasst sind. Auf den meisten Workstations lässt sich der Zugang problemlos auf die lokalen Terminals tty0 bis tty12 beschränken. Serielle Terminals (ttyS) oder die devfs-Devices vc/1 bis vc/11 benötigt man nur in den wenigsten Konfigurationen.

Wollen Sie zu Wartungsarbeiten oder aus Sicherheitsgründen das Login vorübergehend auf root beschränken und andere Nutzer aussperren, bietet dazu pam_nologin eine komfortable Möglichkeit. Findet sich in /etc das File nologin, weist das System die Anmeldeversuche aller User mit Ausnahme von root zurück. Dabei gibt es den Inhalt von nologin auf dem Bildschirm aus.

pam_wheel

Nicht nur root kann Systembefehle mit weitreichenden Folgen absetzen. Dieselbe Möglichkeit steht auch allen Benutzern offen, die das Kommando su ausführen. Daher sollten Sie diesen Anwenderkreis mit Hilfe des Moduls pam_wheel begrenzen. Die Bezeichnung wheel stammt aus der BSD-Welt, wo sich nur Benutzer der gleichnamigen Gruppe per su root-Rechte aneignen können. Unter Linux beschränkt pam_wheel den Zugriff per Default auf die Gruppe wheel oder ersatzweise jene mit der Group-ID 0 (root).

Sollen nur root und die Mitglieder einer eigens eingerichteten Gruppe suser Zugriff auf su haben, müssen die ersten zwei Zeilen von /etc/pam.d/su folgendermaßen aussehen:

auth sufficient pam_rootok.so
auth required pam_wheel.so

Hier erlaubt die erste Zeile dem Benutzer root, ohne Angabe des Passworts die Identität anderer User zu übernehmen.

Soll statt wheel eine andere Benutzergruppe in den Genuss des root-Zugriffs per su kommen, ergänzen Sie die zweite Zeile um zwei Parameter:

auth required pam_wheel.so deny group=andere_gruppe

Die Parameter deny sperrt zunächst den Zugriff der Gruppe wheel. Der Ausdruck group=andere_gruppe räumt dieses Recht statt dessen der Gruppe mit dem Namen andere_gruppe ein.

SUID root beschränken

Linux kennt jedoch noch eine weitere Methode, nach der normale Benutzer Programme quasi als root ausführen können. Dies betrifft alle ausführbaren Dateien, die SUID root gesetzt sind. Der Besitzer solcher Dateien ist root, ls -l zeigt als Ausführungsrecht für den Besitzer ein s statt eines x an.

Unter Angabe des oktalen Werts finden Sie mit einem schlichten find / -perm -4000 -xdev schnell alle entsprechenden Files auf dem Rechner. Je nach Distribution handelt es sich dabei um mehrere Dutzend Dateien - speziell SuSE geht mit dem SUID-Flag recht freizügig um. Die wenigsten User allerdings benötigen jemals SUID-root-Zugriff auf alle hier angebotenen Files, andererseits lässt sich damit einiger Unsinn anstellen. Daher sollten Sie nur bei den notwendigsten Dateien das SUID-root-Flag gesetzt lassen. Dazu zählen neben passwd, ping, traceroute und su gegebenenfalls Xwrapper für X11 sowie einige Files aus der KDE-Suite.

Um Ihnen die Arbeit zu erleichtern, bieten wir Ihnen das kleine Skript findsuid zum Download. Es durchsucht das lokale Filesystem nach Dateien mit gesetztem SUID-root-Flag und schreibt eine formatierte Liste dieser Files samt Pfad, Owner, Group und Berechtigungen auf die Standardausgabe. Speichern Sie diese Liste in einer Datei ab, bevor Sie Änderungen vornehmen. Dann können Sie später bei Bedarf jederzeit wieder den Originalzustand herstellen.

Serverdienste

Der Internet-Superserver inetd regelt die Behandlung von eingehenden Netzwerkverbindungen. Trifft eine Verbindungsanfrage an einem von inetd betreuten Port ein, leitet der Daemon den Request an einen Dienst namens tcpd weiter. Dieser entscheidet anhand der Einstellungen in den Files /etc/hosts.deny sowie /etc/hosts.allow, ob es sich um einen zulässigen Zugriff handelt. Ist das der Fall, startet tcpd den zugehörigen Serverprozess, der nun die Anfrage bedienen kann. Diesen Mechanismus bezeichnet man als TCP Wrapping.

Nun benötigen typische Workstations in den seltensten Fällen einen der Serverdienste, für die inetd verantwortlich zeichnet. Daher bestünde eigentlich kein Grund, den Daemon auf Clients einzurichten. Dennoch installieren die meisten älteren Linux-Distributionen sowohl bei Default- als auch Workstation-Installationen nicht nur inetd, sondern auch Dienste wie FTP , Telnet , Finger und andere mehr.

Dies produziert unnötige Scherheitslücken: Die installierten Dienste stehen nicht nur über lokale Netzwerkverbindungen, sondern ebenso auch via Internet zur Verfügung. Für Rechner, die per konventionellem Dial-Up ans Web angebunden werden, hält sich das Risiko aufgrund der nur zeitweilig zugeteilten IP-Adresse und der relativ kurzen Verbindungszeiten in Grenzen.

Anders bei Flatrate- und DSL -Verbindungen: Hier ist der Rechner stets erreichbar, die IP bleibt zumindest über mehrere Stunden konstant. Neuere Distributionen wie Red Hat 7.1, SuSE 7.2 oder Mandrake 8.0 tragen dieser Tatsache Rechnung, indem sie bei Workstation-Installationen von vornherein auf die Einrichtung des Internet-Superservers verzichten.

inetd.conf durchforsten

Hat das Setup auf ihrem System inetd installiert, lässt sich auch dies beheben. Durch Editieren seiner Konfigurationsdatei können Sie dem Superserver auf simple Weise untersagen, unerwünschte Verbindungen nach außen zuzulassen. Die Einstellungen für inetd lagern, wie sich unschwer erraten lässt, in der Datei /etc/inetd.conf.

Für jeden Dienst findet sich dort eine Zeile, die mit dem Servicenamen beginnt. Kommentieren Sie mit einem Doppelkreuz eine Zeile aus, bleibt der entsprechende Dienst in Zukunft geschlossen. Um die Änderung sofort zu übernehmen, starten Sie anschließend inetd über /etc/init.d/inetd restart oder killall -HUP inetd neu.

Auf den meisten Linux-Workstations können Sie bedenkenlos sämtliche Einträge deaktivieren. Zu den Diensten, die Sie mit an Sicherheit grenzender Wahrscheinlichkeit nicht brauchen, zählen chargen, daytime, discard, echo, imap, ntalk, talk, tftp, time, pop und uucp. Als nachgerade gefährlich erweisen sich ident und finger, die einen Angreifer zuvorkommenderweise mit umfangreichen Informationen über die Benutzer des Rechners bedienen.

Serverdienste abschalten

Gerade unerfahrene Benutzer binden viele Daemons eher "versehentlich" ein: So etwa den DNS-Dienst named/bind, den DHCP-Server dhcpd, den News-Server innd oder den SMB-Server Samba.

Alle vier benötigen Sie nur, wenn Sie anderen Rechnern entsprechende Dienste zur Verfügung stellen wollen. Zur Nutzung von News, DNS und DHCP und Windows-Shares als Clients sind sie überflüssig. Ähnliches gilt für die NFS- und Yellow-Pages-Server nfsd und ypbind, die zudem fast ausschließlich in Unix-Netzwerken zum Einsatz kommen.

Bei FTP und SMTP handelt es sich um klassische Serverdienste, die auf Workstations nichts verloren haben. Sie bieten zudem funktionsbedingt derart viele Angriffspunkte, dass sie nur auf speziell gesicherten Maschinen - etwa in einer DMZ - laufen sollten.

Samba, Apache und Telnet

Auch auf einer Workstation möchten Sie möglicherweise gewisse Serverdienste bereitstellen. Als klassische Kandidaten fallen hier SMB- und HTTP-Services sowie Telnet für den Wartungszugriff aus der Ferne an.

Samba benötigen Sie, um anderen Maschinen im Netz SMB-File- und Printservices bereitzustellen. Die Samba-Daemons smbd und nmbd müssen Sie nicht zwangsläufig via inetd starten: Wollen sie ausschließlich CIFS-Dienste offerieren, lassen sich beide Services auch direkt als Daemons starten. Dies beschleunigt sogar den Zugriff. Im Regelfall wird zusammen mit Samba auch Swat installiert, das die Remote-Konfiguration des SMB-Servers per Web-Browser erlaubt. Diesen Dienst sollten Sie unbedingt deaktivieren, wenn Sie ihn nicht dringend benötigen.

Dem Webserver Apache lässt sich kaum etwas Schlechtes nachsagen. Im Gegensatz zu Samba läuft er nicht als root, sondern nutzt einen eigenen Account. Sollte also jemand über httpd Zugriff auf die Maschine erlangen, geschieht dies wenigstens nicht im root-Kontext. Dennoch ist Vorsicht geboten, da Angriffstools gerne den HTTP-Port 80 als mögliche Einfallspforte in den Rechner abklopfen.

Bei Telnet handelt es sich zwar um einen sehr nützlichen Dienst. Allerdings läuft die entsprechende Kommunikation völlig unverschlüsselt ab - inklusive der Authentifizierung mit Username und Passwort. Daher sollten Sie auf Telnet nach Möglichkeit verzichten oder statt dessen OpenSSH einsetzen. Mit dieser Softwaresuite erhalten Sie neben Client und Server für verschlüsselte Remote-Verbindungen mit scp und sftp auch gleich noch sichere Varianten für Remote Filecopy und FTP.

Dienstzugriff einschränken

Den Zugriff auf die in /etc/inetd.conf aufgeführten Dienste können Sie über die beiden hosts_access-Dateien /etc/hosts.allow und /etc/hosts.deny auf Basis von IP-Adressen steuern. In beiden Dateien gehorchen die Einträge der Syntax:

Liste von Daemons : Liste von Clients : optionales Shell-Kommando

Als Trennzeichen innerhalb der Listen dienen Kommas oder Blanks. Der Zugriff auf einen Dienst gilt als verboten, wenn sich ein passendes Daemon:Client-Päckchen in /etc/hosts.deny findet. Umgekehrt wird er erlaubt, falls hosts.allow eine entsprechende Regel aufweist.

Sowohl die Daemon- als auch die Clientliste erlauben die Angabe von Wildcards. ALL lässt alle Dienste und Clients zu. LOCAL steht für Clients, deren Rechnername keinen Punkt enthält. UNKNOWN betrifft alle Clients, deren IP-Adresse oder Hostname sich nicht eruieren lässt; KNOWN bedeutet genau das Gegenteil. PARANOID betrifft alle Clients mit nicht übereinstimmenden Adressen und Namen. Zudem kann der Operator EXCEPT eingesetzt werden: ALL EXCEPT 192.80.0.77, 192.80.0.207 beträfe etwa alle Clients bis auf die beiden angegebenen.

In der Clientliste dürfen sowohl IP-Adressen als auch Rechnernamen auftauchen. Einträge, die mit einem Punkt beginnen, werden als Endstück eines FQDN betrachtet. So beträfe .tecchannel.de alle Rechner der Domain tecchannel.de. Auch IP-Adressen lassen sich sinngemäß generalisieren: 192.168.80. gilt für alle Rechner des entsprechenden Subnetzes. Daneben ist auch die Angabe per Netzmaske zulässig. 192.168.80. ließe sich also auch als 192.168.80.0/255.255.255.0 schreiben.

hosts.allow und hosts.deny

Eine bewährte Grundregel für alle Sicherheitsmaßnahmen lautet: "Erst einmal alles verbieten". Daran sollte man sich tunlichst halten, so dass die hosts.deny genau einen Eintrag umfasst:

# /etc/hosts.deny
#
ALL : ALL
#EOF

Per Default darf also kein entfernter Rechner auf irgendeinen lokalen Dienst zugreifen.

Die /etc/hosts.allow lockert anschließend diese restriktive Politik durch die Definition dedizierter Dienst/Client-Pärchen wieder auf:

# /etc/hosts.allow
#
ALL EXCEPT in.telnetd : \\    192.168.80.0/255.255.255.0
in.telnetd : \\    192.168.80.207
#EOF

In unserem Beispiel dürfen alle Rechner im lokalen Class-C-Netz auf sämtliche Dienste mit Ausnahme von Telnet zugreifen. Letzteres bleibt ausschließlich der Maschine mit der IP-Adresse 192.168.80.207 vorbehalten.

Tragen Sie beim Editieren dafür Sorge, dass beide Dateien mit einem Zeilenumbruch enden. Anderenfalls wird die letzte Zeile des Files nicht mehr ausgewertet. Am besten schließen Sie die Datei dazu mit einer Kommentarzeile ab. Da Linux die beiden hosts_access-Dateien bei jedem Verbindungsversuch neu auswertet, werden Änderungen an den Files auch ohne Restart des inetd sofort übernommen.

Andere Dienste

Linux startet nicht alle Dienste via inetd. Etliche Daemons fährt das Betriebssystem während des Bootens direkt über die Skripts in /etc/init.d hoch. Zwei davon sollten Sie sich genauer unter die Lupe nehmen: den RPC-Portmapper portmap und den Printerdaemon lpd.

Ähnlich wie andere Serverdienste wird portmap auf den wenigsten Clients benötigt. Um den Start des Daemons komplett zu unterbinden, fügen Sie im Start-Up-Skript /etc/init.d/portmap als ersten ausführbaren Befehl ein exit ein. Da der RPC-Portmapper die Dienste des TCP-Wrappers nutzt, können Sie den Zugang alternativ auch über einen entsprechenden Eintrag in /etc/hosts.allow beschränken:

# /etc/hosts.allow
#
ALL EXCEPT in.telnetd, portmap : \\    192.168.0.0/255.255.0.0
in.telnetd : \\    192.168.80.207
portmap : \\    192.186.80.
#EOF

In der Clientliste erlaubt portmap dabei ausschließlich ALL oder die Angabe von IP-Adressen. Hostnamen werden nicht verarbeitet.

Der Druckerdaemon lpd lauscht auf Port 515 nach Connections. Per Default akzeptiert er Verbindungen zu jeder Gegenstelle, solange diese von Ports zwischen 721 und 731 stammen. Davon lässt er sich nur durch das Einrichten der Datei /etc/hosts.lpd abhalten. Den dort per Hostname oder IP-Adresse aufgeführten Maschinen gewährt der Daemon Zugriff, alle anderen lässt er abblitzen.

Fazit

Die geschilderten Maßnahmen verbessern den Schutz Ihrer Linux-Workstation deutlich - unangreifbar machen sie sie nicht. Das liegt vor allem an zwei Tatsachen.

Zum einen ist Sicherheit kein Zustand, sondern ein Prozess. Das Verhältnis zwischen Systemadministrator und Cracker erinnert stark an das Rennen zwischen Hase und Igel: Der Cracker "ist schon da". Erst wenn eine Sicherheitslücke bekannt wird, kann man sie auch stopfen. Ein Angreifer hat in der Zwischenzeit reichlich Gelegenheit, sie auszunutzen. Konsequente System-Updates senken hier allerdings das Risiko deutlich. Im Fall von Code Red beispielsweise war das Sicherheitsloch rund einen Monat vor dem Angriff bekannt, auch ein Patch lag schon vor.

Zum anderen bleiben selbst auf bestens gepflegten Systemen noch potentielle Eingangstüren offen. Dabei handelt es sich um die Ports jener Dienste, die der Rechner nach dem Willen seines Benutzers nach außen anbieten soll. Hier kann eine Firewall helfen, die Maschine vor Angriffen zu schützen oder zumindest den Benutzer frühzeitig zu warnen. Einen umfassenden Überblick über die Möglichkeiten der bis Kernel 2.2 genutzten Ipchains bietet unsere Serie zum Thema Firewall unter Linux. Einrichtung und Konfiguration der im Kernel 2.4 integrierten Iptables-Firewall werden Gegenstand eines Artikels sein, den sie demnächst auf tecChannel.de finden. (jlu)