Wenn ein System als Server in einem �ffentlichen Netzwerk verwendet wird, wird dieses zu einem Angriffsziel. Aus diesem Grund ist das Abh�rten des Systems und Sperren von Diensten von erheblicher Bedeutung f�r den Systemadministrator.
Bevor Sie die Details eines bestimmten Themas erforschen, sehen Sie sich die folgenden allgemeinen Hinweise f�r das Erh�hen der Server-Sicherheit an:
Halten Sie alle Dienste auf dem neuesten Stand, um vor den neuesten Bedrohungen gesch�tzt zu sein.
Verwenden Sie sichere Protokolle.
Wenn m�glich, sollte immer nur eine Maschine einen Netzwerkdienst bereitstellen.
�berwachen Sie alle Server sorgf�ltig auf verd�chtige Aktivit�ten.
5.1. Sichern von Diensten mit TCP Wrappern und xinetd
TCP-Wrapper bieten Zugriffskontrolle f�r eine Reihe von Diensten. Die meisten modernen Netzwerkdienste, wie z.B. SSH, Telnet und FTP, verwenden TCP-Wrapper, die als Wachposten zwischen einer eingehenden Anfrage und dem angefragten Dienst stehen.
Die Vorteile von TCP Wrappern werden noch erweitert, wenn diese zusammen mit xinetd, einem Super-Dienst, der zus�tzliche Zugriffs-, Log-, Bindungs-, Umleitungs- und Ressourcenkontrolle bietet.
Tipp
Es ist eine gute Idee, die IPTables-Firewall-Regeln in Zusammenhang mit TCP Wrappern und xinetd zu verwenden, um eine Redundanz innerhalb der Service-Zugangskontrollen zu erreichen. F�r mehr Information �ber das Errichten von Firewalls mit IPTables-Befehlen sieheKapitel 7.
Weitere Informationen zur Konfiguration von TCP Wrappern und xinetd finden Sie im Kapitel TCP Wrapper und xinetd im Red Hat Enterprise Linux Referenzhandbuch.
In den folgenden Unterkapiteln wird davon ausgegangen, dass Sie ein grundlegendes Wissen �ber jedes Thema besitzen und sich auf spezielle Sicherheitsoptionen konzentrieren.
5.1.1. Erh�hung der Sicherheit mit TCP Wrappern
TCP Wrapper k�nnen viel mehr als nur Zugriffe auf Dienste verweigern. In diesem Abschnitt wird erl�utert, wie TCP Wrapper zum Versenden von Verbindungs-Bannern, Warnen vor Angriffen von bestimmten Hosts und Erweitern der Log-Funktionalit�t eingesetzt werden k�nnen. Eine ausf�hrliche Liste der Funktionalit�t und Kontrollsprache der TCP Wrapper finden Sie auf den man-Seiten der hosts_options.
5.1.1.1. TCP Wrapper und Verbindungs-Banner
Den mit einem Dienst verbundenen Clients ein einsch�chterndes Banner zu schicken, ist eine gute Methode, um zu verschleiern, welches System der Server verwendet, und im gleichen Zug Angreifer wissen zu lassen, dass sie es mit einem wachsamen Systemadministrator zu tun haben. Um ein TCP-Wrapper Banner f�r einen Dienst zu implementieren, verwenden Sie die Option banner.
In diesem Beispiel wird ein Banner f�r vsftpd implementiert. Sie m�ssen zuerst eine Banner-Datei anlegen. Diese kann sich irgendwo auf dem System befinden, muss aber den gleichen Namen wie der Daemon haben. In diesem Beispiel nennen wir die Datei /etc/banners/vsftpd.
Der Inhalt der Datei sieht wie folgt aus:
220-Hello, %c
220-All activity on ftp.example.com is logged.
220-Act up and you will be banned.
Der %c Token liefert eine Reihe von Client-Informationen wie den Benutzernamen oder den Hostnamen, oder den Benutzernamen und die IP-Adresse, um die Verbindung einsch�chternder zu machen. In Red Hat Enterprise Linux Referenzhandbuch finden Sie eine Liste mit anderen verf�gbaren Tokens f�r TCP Wrapper.
Damit dieses Banner eingehenden Verbindungen pr�sentiert werden kann, f�gen Sie die folgende Zeile in die Datei /etc/hosts.allow ein:
vsftpd : ALL : banners /etc/banners/
5.1.1.2. TCP Wrapper und Warnung vor Angriffen
Wenn ein bestimmter Host oder ein Netzwerk bei einem Angriff auf den Server ertappt wurde, k�nnen TCP Wrapper mit der spawn-Direktive vor weiteren Angriffen von diesem Host oder Netzwerk warnen.
In diesem Beispiel gehen wir davon aus, dass ein Cracker vom 206.182.68.0/24 Netzwerk bei einem Angriffsversuch auf den Server erwischt wurde. Indem Sie die folgende Zeile in die Datei /etc/hosts.deny einf�gen, wird der Verbindungsversuch abgewiesen und in einer besonderen Datei aufgezeichnet:
Das %d-Token liefert den Namen des Dienstes, auf den der Angreifer zugreifen wollte.
Um die Verbindung zu erlauben und diese aufzuzeichnen, f�gen Sie die spawn Direktive in die Datei /etc/hosts.allow ein.
Hinweis
Da die spawn-Direktive jeden beliebigen Shell-Befehl ausf�hrt, k�nnen Sie ein spezielles Skript schreiben, das den Administrator im Falle eines Verbindungsversuchs eines bestimmten Clients mit dem Server benachrichtigt oder eine Reihe von Befehlen ausf�hrt.
5.1.1.3. TCP Wrapper und erweitertes Logging
Wenn bestimmte Verbindungstypen eine gr��ere Sorge darstellen als andere, kann der Log-Level f�r diesen Dienst �ber die Option severity angehoben werden.
In diesem Beispiel gehen wir davon aus, dass jeder, der eine Verbindung zu Port 23 (dem Telnet-Port) auf einem FTP-Server herstellen will, ein Cracker ist. Um dies zu kennzeichnen, f�gen Sie eine emerg-Flag anstelle der Standard-Flag info in die Log-Datei ein und verweigern Sie die Verbindung.
Hierf�r f�gen Sie die folgende Zeile in die Datei /etc/hosts.deny ein:
in.telnetd : ALL : severity emerg
Dies verwendet die standardm��ige authpriv Logging-Funktion, jedoch wird die Priorit�t vom Standardwert info auf emerg hinaufgesetzt, wodurch Log-Nachrichten direkt an die Konsole weitergegeben werden.
5.1.2. Erh�hen der Sicherheit mit xinetd
Der xinetd Super-Server ist ein weiteres n�tzliches Tool zur Zugriffskontrolle auf die untergeordneten Server. In diesem Abschnitt wird beschrieben, wie xinetd eingesetzt werden kann, um einen sogenannten Trap-Service einzurichten und die Anzahl der Ressourcen, die zur Unterbindung von DoS-Angriffen in jedem beliebigen xinetd-Dienst zu Verf�gung stehen, zu kontrollieren. Eine eingehendere Liste der verf�gbaren Optionen finden Sie auf den man-Seiten zu xinetd und xinetd.conf.
5.1.2.1. Eine Falle aufstellen
Ein wichtiges Feature von xinetd ist die F�higkeit, Hosts zu einer globalen no_access-Liste hinzuf�gen zu k�nnen. Den Hosts auf dieser Liste werden Verbindungen zu Diensten, die von xinetd verwaltet werden, f�r einen bestimmten Zeitraum oder bis xinetd neu gestartet wird, verweigert. Dies wird durch das SENSOR-Attribut erreicht. Durch diese Methode k�nnen Sie auf einfache Weise Hosts blockieren, die den Server auf offene Ports absuchen.
Der erste Schritt f�r das Einrichten des SENSOR ist, einen Dienst auszuw�hlen, den Sie nicht f�r eine Verwendung einplanen. In diesem Beispiel wird Telnet verwendet.
Bearbeiten Sie die Datei /etc/xinetd.d/telnet und �ndern Sie die Zeile flags in folgendes um:
flags = SENSOR
F�gen Sie die folgendes Zeile innerhalb der Klammern hinzu:
deny_time = 30
Hierdurch wird dem Host, der 30 Minuten lang versucht hat, sich mit dem Port zu verbinden, der Zugriff verweigert. Andere Werte f�r das deny_time-Attribut sind FOREVER, der solange wirksam ist, bis xinetd neu gestartet wird, und NEVER, der die Verbindung zul�sst und sie dokumentiert.
Die letzte Zeile sollte wie folgt aussehen:
disable = no
Obwohl SENSOR eine gute Methode ist, Verbindungen von b�swilligen Hosts zu erkennen und zu stoppen, hat es jedoch zwei Nachteile:
Es hilft nicht gegen heimliches Scannen (Stealth Scans).
Ein Angreifer, der wei�, dass ein SENSOR ausgef�hrt ist, kann eine DoS-Attacke gegen bestimmte Hosts ausf�hren, indem er ihre IP-Adressen f�lscht und sich mit dem verbotenen Port verbindet.
5.1.2.2. Kontrollieren von Server-Ressourcen
Ein weiteres, wichtiges Feature von xinetd ist die F�higkeit, die Anzahl der Ressourcen, die Dienste zur Verf�gung haben, zu kontrollieren.
Dies wird durch die folgenden Direktiven erreicht:
cps = <number_of_connections> <wait_period> — Gibt die Verbindungen pro Sekunde zu einem Service vor. Diese Direktive akzeptiert nur ganze Zahlen.
instances = <number_of_connections> — Gibt die Gesamtzahl aller erlaubten Verbindungen zu einem Dienst an. Diese Direktive akzeptiert entweder ganze Zahlen oder UNLIMITED.
per_source = <number_of_connections> — Gibt die Verbindungen zu einem Dienst pro Host vor. Diese Direktive akzeptiert entweder einen ganzzahligen Wert oder UNLIMITED.
rlimit_as = <number[K|M]> — Gibt die Gr��e der Speicheradresse in Kilobyte oder Megabyte an, die der Dienst in Anspruch nehmen kann kann. Diese Direktive akzeptiert entweder einen ganzzahligen Wert oder UNLIMITED.
rlimit_cpu = <number_of_seconds> — Gibt die Zeit in Sekunden an, die ein Dienst die CPU belegen kann. Diese Direktive akzeptiert entweder einen ganzzahligen Wert oder UNLIMITED.
Mithilfe dieser Direktiven kann verhindert werden, dass ein xinetd-Dienst das gesamte System belegt und Denial-of-Service verursacht.
