oidentd

Das Ident-System ist ein Benutzer-Identifikationssystem zur usergenauen Zuordnung einer Verbindung von einem Client zu einem Server. oidentd ist einer von vielen Ident-Servern. Dessen Installation und sichere Konfiguration wird in diesem Wiki-Artikel beschrieben.

Vorüberlegung

Computer können anhand ihrer IP eindeutig zugeordnet werden und Prozesse können anhand des verwendeten Ports eindeutig zugeordnet werden (sofern man den Standardport nicht geändert hat). Will man aber noch einen Schritt weitergehen, und auch den Useraccount identifizieren, mit dem ein Zugriff auf einen Server erfolgt, bedarf es eines Ident-Servers.

Dies kann zum Beispiel als zusätzliches Identifikationsmerkmal verwendet werden, wenn das System so konfiguriert wurde, dass das Antworten auf Ident-Anfragen mit falschen Daten (Spoofen) deaktiviert wurde. Beim Abrufen von E-Mails kann man zum Beispiel die Ident-Antwort als X-Header mit aufnehmen, und so dem Mail-Administrator ermöglichen, eine gesendete Mail einem Benutzer zuzuordnen, obwohl dieser falsche FROM- und REPLY-TO-Angaben gemacht hat.

Kritik

Das Ident-System geht von drei Dingen aus:

Der Client ist ein Mehrbenutzersystem, auf dem mehrere Useraccounts eingerichtet sind. Jeder Benutzer nutzt alleine einen Useraccount, und das Spoofen von Ident-Antworten ist unterbunden, oder es wurde anderweitig dafür Sorge getragen, dass die Ident-Antwort einem Useraccount einwandfrei zuordenbar ist
Die Benutzer und der Administrator des System sind unterschiedliche Personen, und die Benutzer haben keine Möglichkeit, Systemeinstellungen zu verändern
Der Administrator des Systems ist zuverlässig und vertrauenswürdig

Im täglichem Umfeld ist es allerdings meist so, dass ein Computer gemeinhin nur von einer Person verwendet wird, die zudem auch noch der Administrator des Systems ist. Häufig ist es auch so, dass diese Person nur gerade eben so ausreichende Kenntnisse der Administration besitzt.

Ident-Antworten sind aufgrund der Tatsache, dass das Spoofen sogar vorgesehen ist, und der Tatsache dass eben meist kein „Optimales System“ (siehe Liste) vorhanden ist, als unverifiziert einzustufen. Analogie: Jemand klopft an die Haustür. Man Fragt: „Wer ist da?“ und das gegenüber antwortet: „Hier ist Manfred Mustermann!“

Vorteile

Wie bereits geschrieben kann die Ident-Antwort von einem Server dazu verwendet werden, einen Zugriff einem Nutzer zuzuordnen. Dies kann in Rechnerpools oder auf einem Mehrbenutzersystem dazu verwendet werden, herauszufinden, welcher Nutzer zum Beispiel Spam-Mails versendet.

Wenn man ein Bouncernetzwerk betreibt, kann man den Benutzern eine bestimmte Kennung geben, anhand derer dann eine weitere Abfrage (Passwort) zur Identifizierung vorgenommen werden kann. Zudem kann man dann anhand dieser Kennung Bouncer gezielt von der Nutzung des Netzwerks ausschließen, ohne gleich das gesamte Bouncernetzwerk vom IRC-Netzwerk zu sperren.

Zudem wird das Ident-System häufig von IRC-Servern verwendet, und ist in einigen Netzwerken sogar verbindlich. Mitunter können erst mit einer entsprechenden Ident-Antwort spezielle Dienste des IRC-Servers genutzt werden.

Installation

oidentd ist als oidentd in community verfügbar, und kann von dort mittels Pacman installiert werden.

pacman -S oidentd

Konfiguration

Die Konfiguration von oidentd wird an drei Stellen vorgenommen, zum Einem in der Datei /etc/oidentd.conf und zum Anderem in der Datei /etc/default/oidentd. Zusätzlich kann im home-Verzeichnis der jeweiligen Useraccounts in der Datei .oident.conf eine Userbezogene Konfiguration vorgenommen werden.

Systemweite Konfiguration

Über die systemweite Konfiguration in /etc/oidentd.conf und /etc/default/oidentd wird zum Einen die Grundkonfiguration vorgenommen, und zum Anderen Betriebs-Grundlagen für den Daemon definiert.

`/etc/default/oidentd`

In dieser Datei befinden sich drei Variablen, USER, GROUP und OPTS. Normaler Weise muss hier nichts geändert werden. Wenn man allerdings möchte, dass oidentd mit anderen Nutzerdaten läuft, oder wenn man spezielle Optionen für den oidentd-Start definieren möchte, kann man diese Datei bearbeiten.

USER=oident
GROUP=nogroup
OPTS="-oHAL9000"

Hier wird oident nicht – wie standardmäßig definiert – als nobody:nobody gestartet, sondern als oident:nogroup. Zudem wird ein zusätzliches Kommando an oident übermittelt (und zwar ohne Leerzeichen zwischen Parameter und Wert), in diesem Fall die Anweisung, statt des Betriebssystem-Namens die humoristische Bezeichnung „HAL9000“ zu verwenden, um den tatsächlichen Betriebssystem-Namen zu verschleiern, was die Sicherheit erhöht, da so nicht durch eine einfache Ident-Anfrage herausgefunden werden kann, welches Betriebssystem auf dem Client läuft (genauer genommen, welcher Betriebssystem-Familie das Betriebssystem auf dem Client entstammt).

`/etc/oidentid.conf`

Anhand dieser Datei werden die Userrechte definiert. Diese Datei muss vor dem ersten Start angelegt werden und es müssen zwei Einträge vorgenommen werden. Der erste Eintrag default definiert Regeln, die für alle User gelten, wenn nicht explizit durch userspezifische Einträge geändert. Der zweite Eintrag definiert die Antwort, die gegeben werden soll, wenn ein Prozess von root stammt.

default {
   default {
      deny spoof
      deny spoof_all
      deny spoof_privport
      deny hide
      deny random
      deny numeric
      deny random_numeric
   }
}

user root {
   default {
      force reply "UNKNOWN"
   }
}

Innerhalb der Einträge können weitere Spezifizierungen vorgenommen werden. Auch auf der zweiten Ebene ist es so, dass default alles abdeckt, was nicht explizit durch weitere Einträge konfiguriert wurde. Innerhalb dieser Ebene folgen dann die eigentlichen Regeln.

Der erste Eintrag verbietet global allen Usern bei allen Verbindungen das Senden von falschen Ident-Angaben. Hiermit wird also sichergestellt, dass immer der richtige Username des entsprechenden Accounts zurückgegeben wird.

Der zweite Eintrag bestimmt, dass für Zugriffe des Useraccounts root bei allen Verbindungen als Ident-Antwort lediglich „UNKNOWN“ zurückgegeben wird, so dass zugreifende root-Prozesse nicht sofort als solche erkannt werden können.

Diese beiden Einträge sollte man in dieser Form vornehmen, wenn nichts elementar wichtiges dagegen spricht. (Dies könnte zum Beispiel auf einem System mit mehreren Dutzend Useraccounts das generelle Erlauben des Verbergens des Usernamens sein.) Stattdessen sollte man für jeden Nutzer einzeln einen entsprechenden Regelblock verwenden.

user myaccount {
   default {
      allow spoof
      allow spoof_all
      allow random
      allow hide
   }
   from 127.0.0.1 {
      allow spoof_privport
   }
}

Hier wird der Useraccount myaccount konfiguriert. Dabei wird definiert, dass bei allen Verbindungen die Antwort verändert werden darf, dass zur Antwort ein anderer auf dem System existierender Username verwendet werden darf, dass ein Zufallswert als Antwort gesendet werden darf, und dass der Username versteckt werden darf.

Zusätzlich wird definiert, dass bei allen Zugriffen von 127.0.0.1 aus (also bei Zugriffen vom Rechner auf den Rechner selbst – in allen anderen Fällen hätte die Anfrage nicht 127.0.0.1 als Absenderadresse, sondern die externe Adresse des Interfaces oder des Einwahlknotens) die Ident-Antwort auch auf einen privilegiertem Port (alle ports kleiner als 1024) erfolgen darf.

Weitere Möglichkeiten, Regeln und Bedingungen zu definieren, werden in der Manpage von oidentd ausführlich beschrieben.

Userbezogene Konfiguration

In der Datei ${HOME}/.oidentd.conf werden userbezogene Regeln definiert, nach denen die Ident-Antwort gestaltet wird. Damit diese Datei vom oidentd verwendet werden kann, müssen das home-Verzeichnis des Users, sowie die Datei .oidentd.conf selbst, entweder für die Gruppe lesbar sein, der oidentd angehört, oder aber für alle lesbar sein. Alternativ kann man oidentd auch als root laufen lassen, wovon aus Sicherheitsgründen allerdings abzuraten ist.

In der Datei können zwei verschiedene Abschnittstypen definiert werden. Zum einen kann man dort einmalig den Abschnitt global definieren, der immer dann angewendet wird, wenn nicht explizit durch einen mehrmalig definierbaren to-Abschnitt ein spezieller Regelsatz für die entsprechende Verbindung definiert wurde.

global {
   reply "anonymous"
}

to irc.example.org {
   reply "irctestuser"
}

to mail.example.org {
   reply "mailtestuser"
}

Hier werden neben dem global-Abschnitt noch zwei to-Abschnitte definiert. Damit diese Regeln angewandt werden können, muss dem entsprechendem User in der /etc/oidentd.conf durch einen Abschnitt das Spoofen des Usernamens erlaubt worden sein. Ansonsten greifen die Regeln aus dem default-Abschnitt in der /etc/oidentd.conf.

Testen

Um oidentd auf die richtige Funktionsweise hin zu überprüfen, ohne dabei online gehen zu müssen, bedarf es lediglich der Programme telnet und netstat, sowie eines lokal laufenden SSH-Servers.

Man baut in einem Terminal-Fenster eine Verbindung zum lokalen SSH-Server auf
In einem weiteren Terminal-Fenster führt man netstat -a aus und sucht nach der Zeile, die localhost:N localhost:ssh enthält, N ist dabei eine Portnummer
Nun führt man telnet 113 aus, und gibt N,22 ein, wobei man N durch die im vorherigen Schritt ermittelte Portnummer ersetzt.

telnet localhost 113

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
56762,22
56762,22:USERID:UNIX:testuser
Connection closed by foreign host

Hier wurde durch den User testuser der Port 56762 verwendet. Die Konfiguration entspricht hier in diesem Wiki-Artikel vorgestellten Grundkonfiguration ohne Spoof-Rechte. Ein weiterer Aufruf könnte zum Beispiel so aussehen:

telnet localhost 113

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
57351,22
57351,22:USERID:HAL9000:geheim
Connection closed by foreign host.

Hier wurde dem User testuser erlaubt, die Antwort zu manipulieren, von dem auch Gebrauch gemacht wird. Statt des Usernamens wird hier lediglich geheim zurückgegeben. Zusätzlich wurde in der Daemonkonfiguration mittels OPTS="-oHAL9000" die Ausgabe des verwendeten Betriebssystems humoristisch verschleiert.

Zusätzlich zur Abfrage mittels Telnet, kann man das Vorgehen von oidentd auch in der Daemon-Logdatei unter /var/log/daemon.log nachvollziehen.

… oidentd[3147]: [localhost] Successful lookup: 56762 , 22 : testuser (geheim)

Dies ist die Ausgabe, die durch oidentd beim zweiten Beispiel produziert wurde. Es wird der Servername (in diesem Fall localhost) ausgegeben. Es folgt dann der Status, in diesem Fall eine erfolgreiche Abfrage. Danach wird der Antwortport ausgegeben, direkt gefolgt vom Anfrageport des Clients. Nach diesen Informationen folgt der tatsächliche Benutzername, und in Klammern ganz am Ende der Benutzername, der dem anfragenden Prozess übermittelt wurde.

Weblinks