Oidentd: Unterschied zwischen den Versionen
veraltet (DAEMONS array in der rc.conf wurde durch systemd ersetzt) |
Dirk (Diskussion | Beiträge) K für systemd |
||
Zeile 1: | Zeile 1: | ||
{{SEITENTITEL:oidentd}}{{righttoc}} | {{SEITENTITEL:oidentd}}{{righttoc}} | ||
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. | 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. | ||
Zeile 32: | Zeile 31: | ||
pacman -S oidentd | pacman -S oidentd | ||
Nach der Installation muss oidentd | Nach der Installation muss oidentd mittels {{ic|systemctl enable oidentd}} für das automatische Starten markiert werden. Vor dem ersten Starten sollte man oidentd noch konfigurieren. Damit Ident-Anfragen den Computer auch erreichen, muss in der Firewall der Port 113 entsprechend weitergeleitet werden. Nach der Konfiguration wird oidentd mittels {{ic|systemctl start oidentd}} gestartet. | ||
== Konfiguration== | == Konfiguration== |
Version vom 18. April 2013, 15:44 Uhr
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 im Community-Repository vorhanden, und kann aus diesem mittels Pacman installiert werden
pacman -S oidentd
Nach der Installation muss oidentd mittels systemctl enable oidentd
für das automatische Starten markiert werden. Vor dem ersten Starten sollte man oidentd noch konfigurieren. Damit Ident-Anfragen den Computer auch erreichen, muss in der Firewall der Port 113 entsprechend weitergeleitet werden. Nach der Konfiguration wird oidentd mittels systemctl start oidentd
gestartet.
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, dielocalhost:N localhost:ssh
enthält,N
ist dabei eine Portnummer - Nun führt man
telnet 113
aus, und gibtN,22
ein, wobei manN
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.