Workshop: Linux-Hardening

Hardening: tcpwrapper, xinetd & udev

Bei Netzwerkdiensten, die nicht über den inetd beziehungsweise xinetd gestartet werden und sich somit der einfachen Zugriffskontrolle und -überwachung dort entziehen, lässt sich die Konfiguration meist über tcpwrapper aktivieren. Ob ein Prozess diese Methoden nutzen kann, verrät ein Blick in die Manualseite; man kann aber auch nachsehen, ob die notwendige Shared-Library - sinngemäß "libwrap"-- eingebunden ist.

# ldd /usr/sbin/snmpd | grep --color libwrap

libwrap.so.0 => /lib64/libwrap.so.0

Die Zugriffssteuerung erfolgt hierbei im Wesentlichen über zwei Konfigurationsdateien im /etc-Verzeichnis:

• /etc/hosts.allow

• /etc/hosts.deny

Deren Aufbau ist durch folgende Zeile charakterisiert:

Prozessnamen : System [ : shell_command]

xinetd

Über die Konfigurationen des neuen Superdaemons xinetd kann der Zugriff auf einen Netzwerkservice vielfältig beschränkt und überwacht werden. Eine White- oder Blacklist (only_from, no_access) für IP-Adressen, Host-Namen und Netzwerknamen, ein Zeitfenster (access_times) oder eine Zugriffsperre bei hoher Systemlast (max_load) sind nur einige davon. Ein erfolgreicher oder misslungener Zugriff kann ebenso geloggt werden. Die Möglichkeit, den neuen Prozess mit anderer User- und Gruppen-ID auszuführen, sollte man nutzen. Mit der "bind/ interface"-Option kann der Service auf ein definiertes Netzwerk-Interface fixiert und so beispielsweise der Zugriff über telnet nur aus dem LAN heraus aktiviert werden.

Bei einem Stand-alone-Daemon, der seinen I/O-Verkehr nicht über die Dateihandle stdin und stdout abwickelt, bleibt nur die Möglichkeit, über den tcpwrapper oder letztendlich über die Firewall eine Zugriffskontrolle zu implementieren. Die Möglichkeit, über openSSH einen Tunnel aufzubauen, erschwert die Kontrolle der Zugriffe.

Wenn möglich, sollte ein Netzwerkservice immer auf den Host-Namen "localhost" beziehungsweise die IP 127.0.0.1 oder das Interface "lo" gebunden werden. Denn nur so ist ein Zugriff darauf ausschließlich vom gleichen System möglich, und es können auch Firewall-Regeln mit dem Interface "lo" definiert werden.

udev

Wurden die sogenannten Device-Knoten im Verzeichnis "/dev" vor einiger Zeit noch statisch per "mknod" angelegt, übernimmt dies heute der "udev"-Daemon. Dieser ist in der Lage, anhand von speziellen Merkmalen der Hardware, wie Hersteller, Seriennummer oder Typ, den Device-Knoten immer mit dem gleichen Namen und der gleichen Major- und Minor-Nummer anzulegen, auch wenn Letztere in neueren Kernels keine große Rolle mehr spielen.

Die Systemregeln unter /lib/udev/rules.d können durch eigene Regeln unter /etc/udev/rules.d ersetzt und somit auch deaktiviert werden.