Kapitel 5. Server-Sicherheit

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 Services 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:

5.1. Sichern von Services mit TCP Wrappers und xinetd

TCP Wrappers bieten Zugriffskontrolle für eine Reihe von Services. Die meisten modernen Netzwerkservices, wie z.B. SSH, Telnet und FTP, verwenden TCP Wrappers, die als Wachposten zwischen einer eingehenden Anfrage und dem angefragten Service stehen.

Die Vorteile von TCP Wrappers werden noch erweitert, wenn diese zusammen mit xinetd, einem Super-Service, der zusätzliche Zugriffs-, Log-, Bindungs-, Umleitungs- und Ressourcenkontrolle bietet.

TippTipp
 

Es ist eine gute Idee, die IPTables-Firewall-Regeln in Zusammenhang mit TCP Wrappers 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 Wrappers und xinetd finden Sie im Kapitel TCP Wrappers 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 Wrappers

TCP Wrappers können viel mehr als nur Zugriffe auf Services verweigern. In diesem Abschnitt wird erläutert, wie TCP Wrappers 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 Wrappers finden Sie auf den man-Seiten der hosts_options.

5.1.1.1. TCP Wrappers und Verbindungs-Banner

Den mit einem Service 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 Wrappers Banner für einen Service 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 anderenverfügbaren Tokens für TCP Wrappers.

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 Wrappers und Warnung vor Angriffen

Wenn ein bestimmter Host oder ein Netzwerk bei einem Angriff auf den Server ertappt wurde, können TCP Wrappers 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:

 ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert

Das %d-Token liefert den Namen des Services, 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.

AnmerkungHinweis
 

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 Wrappers und erweitertes Logging

Wenn bestimmte Verbindungstypen eine größere Sorge darstellen als andere, kann der Log-Level für diesen Service über die Option severity angehoben werden.

In diesem Beispiel gehen wir davon aus, dass jeder, der eine Verbindung zu Port 23 (der 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 Fang-Service einzurichten und die Anzahl der Ressourcen, die zur Unterbindung von Service-Ablehnungs-Angriffen in jedem beliebigen xinetd Service 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 Services, 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 Service 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 Service-Ablehnungs-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 Services 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 von. Diese Direktive akzeptiert nur ganze Zahlen.

  • instances = <number_of_connections> — Gibt die Gesamtzahl aller erlaubten Verbindungen zu einem Service an. Diese Direktive akzeptiert entweder ganze Zahlen oder UNLIMITED.

  • per_source = <number_of_connections> — Gibt die Verbindungen zu einem Service 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 Service belegen kann. Diese Direktive akzeptiert entweder einen ganzzahligen Wert oder UNLIMITED.

  • rlimit_cpu = <number_of_seconds> — Gibt die Zeit in Sekunden an, die ein Service die CPU belegen kann. Diese Direktive akzeptiert entweder einen ganzzahligen Wert oder UNLIMITED.

Mithilfe dieser Direktiven kann verhindert werden, dass ein xinetd Service das gesamte System belegt und Denial-of-Service verursacht.