Besonders in kleineren Firmen ohne eigenes IT-Sicherheitsteam fällt es Administratoren schwer, mit zunehmend gehäuften und raffinierten Angriffen umzugehen. ... (mehr)

Inetd wacht über Serverdienste

Ein Internet-Superserver verwaltet die Netzwerkverbindungen verschiedener Dienste auf einem Rechner. Je nach Konfiguration öffnet Inetd verschiedene Ports und wartet auf Verbindungsanfragen. Erst dann wird der betreffende Serverprozess gestartet. Das hat den Vorteil, dass nur ein Server ständig im Hintergrund läuft. In einer neuen Debian-Installation ist Inetd allerdings nicht enthalten, denn er bringt auch einige Nachteile mit: So wird bei jeder neuen Verbindung der Serverdienst neu gestartet und das kostet Ressourcen; außerdem lässt sich nicht jeder beliebige Serverdienst über Inetd betreiben, da manche Dienste eigene Netzwerk-Sockets öffnen. Inetd eignet sich daher mehr für einfachere und selten benutzte Dienste. Für Web- oder Mailserver ist er eher ungeeignet, da diese meist entweder für den Solobetrieb oder für den Betrieb mit Inetd ausgelegt sind.

Setzen Sie jedoch Inetd ein, sollten Sie nicht benötigte Dienste abschalten, etwa die unsicheren r-Kommandos wie »rsh« , »rlogin« und »rcp« . Stattdessen können Sie die sicheren Varianten »ssh« und »scp« verwenden. Da etwa für SSH-Server oder Apache-Webserver kein Inetd erforderlich ist, prüfen Sie zudem, ob Sie Inetd nicht komplett abschalten können. Dienste können Sie nämlich auch als Daemon starten, anstatt Inetd zu verwenden. Wenn Sie jedoch nicht auf den Einsatz eines Inetd verzichten können, sollten Sie unter Umständen nicht den aus dem Paket "inetutils-inetd" nutzen, sondern eine Alternative. Xinetd etwa bietet viele Erweiterungen und ist vielfältiger konfigurierbar.

Zugriff einschränken mit PAM

In neueren Debian-Systemen sollten Sie in die Verzeichnisse "/etc/security" und "/etc/pam.d" blicken. Hier können Sie den Zugriff auf das System sehr genau regeln und Dinge wie Root-Zugang oder erlaubte CPU-Zeit pro Benutzer einstellen. Das geschieht mithilfe von PAM. PAM steht für "Pluggable Authentication Modules". Dieses von Sun Microsystems in den 1990er-Jahren entwickelte Framework ist unabhängig von einem Authentifikationsschema und wird inzwischen in vielen unixoiden Betriebssystemen eingesetzt – in Debian ist es elementar. In einer oder mehreren Konfigurationsdateien ordnen Sie die Module einzelnen Systemdiensten wie SSH und FTP zu. Dank PAM können die Anmeldedaten dieser Dienste zentral gespeichert werden und getrennte Passwortdatenbanken für einzelne Dienste sind nicht notwendig.

Ursprünglich standen die PAM-Regeln in der Datei "/etc/pam.conf". Aber Debian-getreu steht nun alles im Verzeichnis "/etc/pam.d". Werden neue Dienste wie SSH und andere per Debian-Paketmanagement installiert, wird auch gleich die entsprechende PAM-Konfigurationsdatei mit eingerichtet. Welches Modul an welchen Service gekoppelt wird, hängt daher vom jeweiligen Setup ab. Jedes PAM-Modul unterstützt bis zu vier Services: Authentication (auth), Benutzerzugriff (account), Passwörter (password) und Sitzungsmanagement (session). Debian nutzt für jeden dieser Modultypen eine eigene Datei, seit Debian Squeeze fürs Sitzungsmanagement sogar zwei:

- "/etc/pam.d/common-account": allgemeine Authorisierungseinstellungen für alle Services

- "/etc/pam.d/common-auth": allgemeine Authentication-Einstellungen für alle Services

- "/etc/pam.d/common-password": allgemeine passwortbezogene Module für alle Services

- "/etc/pam.d/common-session": allgemeine Sitzungsmodule für alle Services

- "/etc/pam.d/common-session-noninteractive": allgemeine Sitzungsmodule für alle nicht-interaktiven Services wie cron, cups, ppp

Zu den common-Konfigurationsdateien gibt es weitere etwa für »su« , »login« und andere wichtige Befehle. In diesen kommen die Modultypen nach Bedarf vor. Die Konfigurationsdaten verwenden alle dieselbe Syntax; erklärt wird diese sehr ausführlich im Paket "libpam-doc". Das enthält unter anderem den "Linux-PAM System Administrator's Guide" [4], der erklärt, wie PAM konfiguriert wird. Nach dem Modultyp stehen die Control-Flags. Derer gibt es vier:

- requisite: Ein Fehler gibt die Kontrolle gleich an die Anwendung zurück.

- required: Erforderlich, damit libpam der Anwendung einen Erfolg zurückmelden kann.

- sufficient: Falls alle vorhergehenden Module erfolgreich abgearbeitet wurden, wird hier erfolgreich zur Anwendung zurückgewechselt.

- optional: Erfolg oder Misserfolg dieses Moduls wird nicht aufgezeichnet.

Hinzu kommen die Schlüsselwörter "include" und "substack", die alle Zeilen weiterer Dateien als Argumente einlesen. Die Control-Flags können auch mit einer komplexeren Syntax kombiniert werden in der Art

[value1=action1 value2=action2 ...]

 

Nach den Control-Flags wird das jeweilige PAM-Modul genannt. Die Module stehen im Verzeichnis "/lib/ »architektur« -linux-gnu/security/". In den PAM-Konfigurationsdateien muss der qualifizierte Name nicht angegeben werden, es genügt der jeweilige Modulname, also etwa "pam_ »name« .so".

Als Letztes folgen kommasepariert die Argumente, die dem Modul übergeben werden. Allerdings ist das nicht immer notwendig. Welche Argumente möglich sind, erfahren Sie üblicherweise in den entsprechenden man-Seiten der Module, also etwa »man pam_unix« .

Bild 2: Im Verzeichnis "/etc/security" finden Sie die PAM-Konfigurationsdateien, die Sie anpassen können.
comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023