Im vergangenen Monat stellte der Admin-Workshop Werkzeuge vor, mit denen Administratoren Serverdienste in ihr System einbinden. Dieses Mal erfahren Sie alles über das Ident-Protokoll und dessen Aufgaben sowie die Fallen, die entstehen, wenn ein Rechner als Server dient.

Nachdem die vorige Ausgabe des Admin-Workshops erläutert hat, wie Admins Serverprozesse per Inetd aufsetzen[1], dient diesmal das Identification-Protokoll als Beispiel für die Möglichkeiten und Gefahren eines Unix-Servers. Ident ist sehr simpel und dient dazu, einer TCP-Verbindung den Benutzernamen auf dem Client-Rechner zuzuordnen. Vor allem FTP-, IRC- und SMTP-Daemons nutzen Ident häufig. Sobald jemand beispielsweise eine Verbindung startet, fragen manche Server beim Client an, welcher lokale Benutzer die Verbindung geöffnet hat. Abbildung 1 illustriert dieses Vorgehen.

Der FTP-Server von Abbildung 1 wird innerhalb des Ident-Protokolls seinerseits zum Client. Er baut eine Verbindung zurück zum anfragenden Rechner auf dem Standardport 113 auf. Weil sich nur ein Root-Prozess an diesen Port binden darf (da er sich im privilegierten Bereich unterhalb von 1024 befindet), ist auf fremdadministrierten Systemen einigermaßen sichergestellt, dass die Antwort der Wahrheit entspricht.

Das Protokoll selbst ist extrem simpel: Der Ident-Client-Code schickt die beiden Portnummern der betreffenden FTP-Verbindung an den Ident-Server (in Abbildung 1 sind das 33812 und 21). Der Ident-Daemon schaut dann im System nach, welchem Benutzer der entsprechende Prozess gehört, der sich an Port 33812 gebunden hat, und schickt dessen Kennung an den Client.

Sicherheit von Ident

Ident stammt aus einer Zeit, in der die meisten Unix-Computer noch Multiuser-Systeme waren, die von einem oder mehreren Admins verwaltet wurden. Trieb ein Benutzer Missbrauch mit diesen Rechnern und startete Angriffe auf Internetserver, hatten die Admins keine Möglichkeit herauszufinden, wer sich hinter diesen Angriffen verbarg.

Mit einem Ident-Daemon auf allen Benutzerrechnern gelingt es, die Verbindung zurückzuverfolgen. Der Betreiber des angegriffenen Servers meldet den Admins des Rechenzentrums, aus dem die Angriffe kommen, welche Benutzerkennung er geloggt hat. So finden die Admins schnell den Missetäter.

Gängige Probleme

Der Ident-Dienst hilft heute aber nur in offensichtlichen Fällen. Halbwegs geschickte Angreifer umgehen diese Sicherung spielend und den Server schützt Ident überhaupt nicht. Insbesondere enthält das Protokoll keinerlei Authentifizierung oder Autorisierung.

Für die Clients ist Ident sogar ein Sicherheitsrisiko: Verbindet sich ein User mit einem nicht vertrauenswürdigen Server, offenbart er ihm zusätzliche Informationen über seine Maschine. Diese Infos kann ein Angreifer ausnutzen. Daher gibt es Implementationen, die statt der Kennung einen Hash senden (etwa den verschlüsselten Benutzernamen inklusive Zeitstempel) und sich den tatsächlichen Accountnamen in Logfiles merken. So erfährt der entfernte Server keine vertrauliche Informationen.

Da Ident aus einer Zeit zentral administrierter Maschinen stammt, ist es heute nur noch bedingt einsetzbar. Denn fast jeder Internetnutzer besitzt einen Computer, den er selbst verwaltet. Er ist in der Lage, den Ident-Daemon antworten zu lassen, was er will. Daher sollten Serverbetreiber den Antworten eines Ident-Daemon niemals vertrauen.

Kein Security-Tool

Ident ist kein Werkzeug zur Absicherung einer Maschine, sondern ein forensisches Hilfsmittel. Viele Internetserver setzen voraus, dass Ident auf dem Client läuft. Hat ein Benutzer auf seinem Rechner den Dienst nicht gestartet, kommt es zu Verzögerungen beim Verbindungsaufbau mit diesen Servern. Denn der Client verwirft die ankommenden Ident-Requests einfach und der Server wartet bis zum Timeout auf eine Antwort.

Daher ist es durchaus sinnvoll, auf seinem Rechner Ident zu installieren. Die Einrichtung eines passenden Daemon offenbart dabei gängige Fallen, die beim Konfigurieren eines Servers auftreten. Fast alle Linux-Distributionen enthalten mindestens eine Ident-Implementation. Da der Dienst typischerweise nur selten zum Einsatz kommt, bietet sich der Aufruf über die Superserver Inetd oder Xinetd[1] an. Bei der Variante mit dem klassischen Inetd ist folgende Zeile in die Datei »/etc/inetd.conf« einzutragen:

ident stream tcp nowait nobody 
/usr/sbin/in.identd

Bei Distributionen mit Xinetd erstellt der Admin die Datei »/etc/xinetd.d/identd« und füllt sie mit den Zeilen aus Listing 1. Einige Distributionen haben Beispielkonfigurationen mitgeliefert, die es nur noch zu aktivieren gilt. Im Inetd durch das Entfernen des »#«-Symbols am Anfang der Zeile; in Xinetd ist für das Aktivieren des Dienstes die Zeile »disable = yes« in »disable = no« zu ändern. Abschließend informiert der Admin den Superserver mit dem Kommando »killall -HUP inetd« oder »killall -HUP xinetd« über die neue Konfiguration.

Paketfilter anpassen

Mit dem Einrichten und Starten des passenden Daemon ist die Arbeit meist noch nicht getan. Denn viele Arbeitsplatzrechner sind durch eine Firewall geschützt, die entweder vorgeschaltet ist oder auf dem Rechner selbst läuft. Ein Paketfilter blockt meist alle Ident-Pakete. Das ist auch der Grund, warum einige Verbindungen zu Internetservern verzögert ablaufen: Der Paketfilter löscht stillschweigend die ankommenden Pakete an Port 113. Die meisten Server warten zwar nur über einen sehr kurzen Zeitraum auf die Antwortpakete, doch einige Sekunden dauert die Verzögerung auf jeden Fall.

Einzige Abhilfe: Ein Loch in die Firewall bohren. Unter Linux ist dazu mit Hilfe von IPtables eine Regel anzulegen, die ankommende Pakete zum Ident-Server akzeptiert und die Antworten passieren lässt. Zwei kurze Aufrufe als Root sorgen für die nötigen Löcher im Paketfilter:

iptables -I INPUT  -p tcp --dport 
ident -j ACCEPT
iptables -I OUTPUT -p tcp --sport 
ident -j ACCEPT

Die bisherige Konfiguration funktioniert wunderbar, sofern der Computer die Internetverbindung selbst herstellt. Oftmals sorgt jedoch ein Router für die Verbindung. Er leitet alle Pakete vom LAN ins Internet und umgekehrt. Die darauf installierte Firewall ist also für Ident fit zu machen. Das hängt stark vom verwendeten Router ab.

Sonderfall NAT

Doch was tun, wenn sich mehrere Computer mittels Network Address Translation (NAT) eine IP-Adresse teilen? Ein einfacher Paketfilter hat hier keine Chance mehr. Denn eingehende Ident-Anfragen richten sich immer ausschließlich an den dafür reservierten Port 113. Nur eine intelligente Firewall, die sich merkt, welcher Computer aktuell zu welcher fremden IP-Adresse Verbindungen unterhält, könnte die ankommenden Ident-Pakete korrekt zuordnen.

Abbildung 1: Beim Verbindungsaufbau mit einem Client fragt der FTP-Server diesen über das Ident-Protokoll nach der Benutzerkennung des Benutzers, der die Verbindung aufbaut.

Einfache Variante

Auch wer sich dieses Durcheinander nicht antun möchte, kann im Linux-Alltag die angesprochene Pause beim Verbindungsaufbau vermeiden: Indem er Ident-Anfragen vom Paketfilter nicht verwerfen lässt, sondern sie sauber zurückweist. Das erledigt eine schlichte IP-Filter-Regel:

iptables -I INPUT -p tcp --dport ident 
-j REJECT --reject-with tcp-reset

Damit erhält der anfragende Rechner sofort die Meldung, dass der Dienst nicht verfügbar ist. Statt auf den Timeout zu warten, bricht der Rechner dann den Verbindungsaufbau ab und es kommt zu keiner Verzögerung. (mwe)

01 # Datei /etc/xinetd.d/identd
02 service ident
03 {
04         socket_type     = stream
05         protocol        = tcp
06         wait            = no
07         user            = nobody
08         server          = /usr/sbin/in.identd
09         disable         = no
10 }