Zurück

1.114.2

Einrichten von Host-Security

Beschreibung: Prüfungskandidaten sollten über das Einrichten einer grundlegenden Host-Security Bescheid wissen. Diese Tätigkeiten enthalten die Konfiguration von syslog, Shadow-Paßwörter, das Einrichten eines Mail-Alias für die Mails von root und das Abdrehen der nicht verwendeten Netzwerkdienste.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

Auch für dieses Kapitel gilt, daß die meisten der hier geforderten Techniken bereits an anderer Stelle beschrieben wurden. Aus diesem Grund werden neben den Verweisen auf die bereits besprochenen Techniken nur noch einige Details geklärt.

Syslog Konfigurieren

Die Konfiguration des Syslog-Daemons wurde im Abschnitt 1.111.3 bereits ausführlich beschrieben. Sicherheitsrelevante Systemmeldungen können mit Hilfe dieser Technik in eine spezielle Datei geschrieben werden, die dann entsprechend beobachtet werden muß.

Typische Herkünfte von sicherheitsrelevanten Meldungen sind:

kern
Meldungen der Firewalls
auth und authpriv
Meldungen und vertrauliche Meldungen des Sicherheitsdienstes. Hier sind die logins verzeichnet.

Neben der Ausgabe in Dateien sei hier auch nochmal an die Möglichkeit erinnert, die Meldungen auch auf das Terminal bestimmter User (vorzugsweise des root-Users) zu schreiben.

Shadow-Passwörter

Alle modernen Linux-Distributionen arbeiten heute standardmäßig mit den Shadow-Passwörtern. Die genauen Beschreibungen der Formate der Shadow-Dateien sind in Abschnitt 1.111.1 nachlesbar.

Um ein System mit dem alten Passwortsystem in ein Shadow-Passwort-System zu konvertieren, existieren die Programme pwconv und grpconv. Umgekehrt können moderne Shadow-Systeme mit pwunconv und grpunconv wieder zurück in das alte Format verwandelt werden.

Logins zeitweise verbieten

Wenn der Systemverwalter für eine bestimmte Zeit verbieten will, daß sich User auf dem Rechner einloggen, so kann er einfach eine Datei /etc/nologin anlegen. Diese Datei kann einen kurzen Text enthalten, der erklärt, warum gerade kein Login möglich ist.

Sowohl das Programm login, als auch Netzwerkdienste wie ssh, telnet, rlogin oder rsh verweigern den Login, wenn diese Datei existiert. Statt dessen zeigen sie dem User den Inhalt der Datei /etc/nologin an.

Diese Beschränkung gilt nicht für den root-User.

Mail Alias von root

Normalerweise sollte der Systemverwalter nicht immer unter seinem root-login arbeiten, außer er arbeitet tatsächlich an der Verwaltung. Wenn er jedoch normale Arbeiten am Computer erledigt, sollte er mit einem Normallogin arbeiten, wie alle anderen auch. Das hat mehrere Gründe. Zum einen können fatale Fehler im Normalbetrieb nicht stattfinden, weil ein Normaluser diese Fehler nicht machen kann. Will ein User etwa ein Verzeichnis löschen und vertippt sich, so daß ein Leerzeichen in die Befehlszeile rutscht: 
  rm -r / foo
         ^
        /|\
         |
     unbeabsichtigtes Leerzeichen
so wäre das der Befehl, das Wurzelverzeichnis und alle darunterliegenden Verzeichnisse zu löschen. Das kann aber nur der Systemverwalter (root). Arbeitet root ständig mit seinem Systemverwalter-Account, so gibt es keine Instanz, die ihn hindern würde, solche Fehler zu machen. Arbeitet er als Normaluser, so werden solche Fehler mangels Berechtigung nicht ausgeführt.

Damit aber root trotzdem seine Mails bekommt, die an root@localhost gesendet wurden, kann er einen Mailalias einrichten. Diese Technik wurde bereits im Abschnitt 1.113.2 besprochen. Der Eintrag in /etc/aliases müsste z.B. lauten: 

  root:  hans
Nach dieser Veränderung müßte der Befehl 
  newaliases
ausgeführt werden, damit sendmail den Alias benutzen kann.

Eine andere Möglichkeit wäre die Weiterleitung der Mails von root an einen anderen User über die Benutzung der Datei ~/.forward im Heimatverzeichnis von root

Nicht benötigte Netzwerkdienste abschalten

Netzwerkdienste können unter Linux grundsätzlich auf zwei verschiedene Arten gestartet werden. Entweder sie sind grundsätzlich schon im Arbeitsspeicher geladen und warten auf Aufträge, die sie abarbeiten sollen, oder sie werden - jeweils wenn sie gebraucht werden - vom inetd aufgerufen. Beide Techniken haben ihre Vor- und Nachteile die Fall für Fall abgewogen werden sollten, um zu entscheiden, auf welche Weise ein bestimmter Dienst gestartet werden soll. Meist ist die Voreinstellung der Distributionen ein guter Anhaltspunkt, um zu entscheiden, ob ein Dienst als Stand-Alone oder inetdbasierter Dienst laufen soll.

Die Voreinstellungen der verschiedenen Distributionen ermöglichen oft Zugriffe, die in der Praxis nicht gewünscht sind. Um solche Dienste abzuschalten, muß entsprechend erstmal klar sein, wie er gestartet wird. Die beiden folgenden Abschnitte gehen die beiden möglichen Methoden durch und zeigen Möglichkeiten der Abschaltung.

Inetd-basierte Dienste abschalten

Wenn ein Dienst über den inetd (siehe auch Abschnitt 1.113.1) gestartet wird, so ist er in der Datei /etc/inetd.conf eingetragen. Wurde stattdessen der xinetd benutzt, liegen die Einstellungen in /etc/xinetd.conf. Einträge in diesen Dateien können einfach auskommentiert werden, indem ihnen ein Kommentarzeichen am Zeilenanfang vorangestellt wird.

Das alleinige Auskommentieren dieser Zeile reicht aber nicht aus, denn der inetd ließt diese Datei nur beim Start. Um einem laufenden inetd diese Veränderungen bekannt zu geben, wird ihm ein HUP-Signal geschickt.

In vielen Fällen ist es überhaupt nicht erwünscht, daß der inetd läuft. Sollte das der Fall sein, so kann dafür gesorgt werden, daß dieser Dienst selbst gar nicht gestartet wird. Der inetd selbst ist ein Stand-Alone-Dienst, dessen Abschaltung im nächsten Abschnitt beschrieben wird.

Stand-Alone Dienste abschalten

Stand-Alone Dienste werden in den modernen Linux-Distributionen alle auf eine gemeinsame Art und Weise gestartet. Im Verzeichnis /etc/init.d liegen Shellscripts, die die einzelnen Dienste starten und stoppen. Diese sogenannten Init-Scripts verstehen jeweils mindestens die Parameter start und stop. Häufig gibt es noch weitere Parameter wie status (gibt eine Ausgabe aus, ob der entsprechende Dienst läuft oder nicht), reload (zwingt den Dienst seine Konfigurationsdatei neu einzulesen) oder restart (Kombination aus stop und anschließendem start).

Jedesmal, wenn ein neuer Dienst installiert wird, installiert er ein entsprechendes Init-Script in das Verzeichnis /etc/init.d. Jeder Dienst kann jetzt mit Hilfe dieser Scripts gestartet werden. Installieren wir den Dienst foo, dann existiert also in diesem Verzeichnis ein Script, wahrscheinlich ebenfalls mit dem Namen /etc/init.d/foo. Um den Dienst von Hand zu starten, wird dieses Script mit dem Parameter start aufgerufen: 

  /etc/init.d/foo start
entsprechend kann ein laufender Dienst mit dem Script wieder heruntergefahren werden: 
  /etc/init.d/foo stop
Die alleinige Existenz dieser Scripte legt aber noch nicht fest, daß diese Dienste auch automatisch gestartet werden. Für diese Einstellungen sind die sogenannten Runlevel-Verzeichnisse gedacht.

Im Verzeichnis /etc (manchmal auch in /etc/init.d liegen für jeden Runlevel ein weiteres Verzeichnis. Diese Runlevelverzeichnisse haben immer die Namen

also etwa rc0.d, rc1.d, rc2.d oder rcS.d (Single User Mode). Innerhalb dieser Verzeichnisse finden sich symbolische Links auf die Init-Scripts, die in dem jeweiligen Runlevel ausgeführt werden sollen. Der Namen dieser Links beginnt entweder mit einem S (Start) oder mit einem K (Kill). Dem folgt eine zweistellige Nummer, die angibt, in welcher Reihenfolge die Scripts ausgeführt werden sollen. Anschließend folgt der Name des Scripts. Die Nummer ist kein absoluter Wert, sondern nur eine Hilfe für die alphabetische Sortierung der Scriptnamen für die Ausführung.

Um unser foo-Script in /etc/init.d automatisch im Runlevel 5 zu starten, genügt also die Erstellung eines symbolischen Links im Verzeichnis /etc/rc5.d in der Form: 

  lrwxrwxrwx 1 root root   13  5. Sep 17:22 S20foo -> ../init.d/foo
Die 20 bedeutet nicht, daß dieser Dienst an 20. Stelle gestartet wird. Alle Links in diesem Verzeichnis, die mit einem S beginnen, werden beim Eintritt in diesen Runlevel alphabetisch sortiert ausgeführt. Die Nummer dient also dazu, die Reihenfolge anzugeben, nicht die absolute Position. Es ist ohne Problem möglich, daß mehrere Links mit der selben Nummer arbeiten, sie werden dann hintereinander (S20bar vor S20foo) aufgerufen. Wird ein Script durch einen Link aufgerufen, dessen Namen mit einem S beginnt, so wird das entsprechende Script mit dem Parameter start aufgerufen

Analog dazu werden die Scripts, deren Namen mit K beginnen, beim Verlassen des Runlevels ausgeführt, wieder in alphabetischer Reihenfolge. Nur diesmal wird das Script, auf das sie verweisen mit dem Parameter stop aufgerufen.

Um also Dienste grundsätzlich abzuschalten und zu verhindern, daß diese Dienste bei einem Neustart wieder automatisch geladen werden, muß im entsprechenden Runlevelverzeichnis der entsprechende Link einfach gelöscht werden.