2.2. Server-Sicherheit
Wenn ein System als Server in einem öffentlichen Netzwerk verwendet wird, stellt es ein Ziel für Angreifer dar. 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 nach Möglichkeit sichere Protokolle.
- Wenn möglich, sollte immer nur eine Maschine eine Art von Netzwerkdienst bereitstellen.
- Überwachen Sie alle Server sorgfältig auf verdächtige Aktivitäten.
2.2.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 verwendet werden, einem Super-Serverdienst, der zusätzliche Zugriffs-, Protokollierungs-, Binding-, Umleitungs- und Ressourcenkontrolle bietet.
Anmerkung
Es ist von Vorteil, die IPTables-Firewall-Regeln zusammen mit TCP-Wrappern und
xinetd zu verwenden, um eine Redundanz innerhalb der Dienst-Zugangskontrollen zu erreichen. Für mehr Information über das Einrichten von Firewalls mit IPTables-Befehlen siehe Abschnitt 2.5, »Firewalls«.
Die folgenden Abschnitte setzen ein grundlegendes Wissen über das jeweilige Thema voraus und konzentrieren sich daher auf spezielle Sicherheitsoptionen.
2.2.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 Protokollierungsfunktionalität eingesetzt werden können. Mehr Informationen über die Funktionalität und Kontrollsprache der TCP-Wrapper finden Sie auf der
hosts_options-Handbuchseite. Werfen Sie zudem einen Blick auf die xinetd.conf-Handbuchseite, erhältlich online unter http://linux.die.net/man/5/xinetd.conf, für Informationen über verfügbare Flags, die Sie als Optionen auf einen Dienst anwenden können.
2.2.1.1.1. TCP-Wrapper und Verbindungsbanner
Benutzern beim Verbinden mit einem Dienst ein einschüchterndes Banner anzuzeigen, ist eine gute Methode, um potenzielle Angreifer wissen zu lassen, dass sie es mit einem aufmerksamen Systemadministrator zu tun haben. Zugleich können Sie auf diese Weise steuern, welche Informationen über das System den Benutzern gezeigt werden. 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. Erstellen Sie zunächst einmal eine Bannerdatei. Es ist unerheblich, wo diese sich auf dem System befindet, muss aber den gleichen Namen wie der Daemon tragen. In diesem Beispiel heißt die Datei /etc/banners/vsftpd und enthält die folgende Zeile:
220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Inappropriate use will result in your access privileges being removed.
Der
%c-Token liefert eine Reihe von Client-Informationen wie den Benutzernamen und Hostnamen, oder den Benutzernamen und die IP-Adresse, um die Verbindung noch abschreckender zu machen.
Damit dieses Banner bei eingehenden Verbindungen angezeigt wird, fügen Sie die folgende Zeile in die Datei
/etc/hosts.allow ein:
vsftpd : ALL : banners /etc/banners/ 2.2.1.1.2. TCP-Wrapper und Warnung vor Angriffen
Wenn ein bestimmter Host oder ein Netzwerk bei einem Angriff auf den Server erwischt 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 speziellen Datei aufgezeichnet:
ALL : 206.182.68.0 : spawn /bin/echo `date` %c %d >> /var/log/intruder_alert
Der
%d-Token gibt den Namen des Dienstes an, 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.
Anmerkung
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.
2.2.1.1.3. TCP-Wrapper und erweiterte Protokollierung
Falls bestimmte Verbindungstypen Anlass zu größerer Sorge geben als andere, kann die Protokollierungsebene für den jeweiligen Dienst über die Option
severity angehoben werden.
Lassen Sie uns für dieses Beispiel annehmen, 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 ein
emerg-Flag anstelle des Standard-Flags info in die Protokolldatei ein und verweigern Sie die Verbindung.
Fügen Sie dazu die folgende Zeile in die Datei
/etc/hosts.deny ein:
in.telnetd : ALL : severity emerg
Dadurch wird die standardmäßige
authpriv-Protokollierungs-Facility verwendet, jedoch wird die Priorität vom Standardwert info auf emerg angehoben, wodurch Protokollnachrichten direkt auf der Konsole ausgegeben werden.
2.2.1.2. Erhöhen der Sicherheit mit xinetd
In diesem Abschnitt wird erläutert, wie
xinetd dazu eingesetzt werden kann, einen so genannten Trap-Dienst einzurichten sowie die verfügbaren Ressourcen für jeden xinetd-Dienst zu kontrollieren. Das Setzen von Ressourcengrenzen kann dabei helfen, Denial of Service (DoS)-Angriffe zu unterbinden. Eine Liste der verfügbaren Optionen finden Sie auf den Handbuchseiten zu xinetd und xinetd.conf.
2.2.1.2.1. Aufstellen einer Falle
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 den SENSOR-Parameter erreicht. Mithilfe dieses einfachen Verfahrens können Sie Hosts blockieren, die den Server auf offene Ports absuchen.
Der erste Schritt für das Einrichten von
SENSOR ist die Auswahl eines Dienstes, den Sie voraussichtlich nicht anderweitig brauchen werden. In diesem Beispiel wird Telnet ausgewählt.
Bearbeiten Sie die Datei
/etc/xinetd.d/telnet und ändern Sie die Zeile flags folgendermaßen um:
flags = SENSOR
Fügen Sie folgende Zeile hinzu:
deny_time = 30
Dadurch werden einem Host alle weitere Verbindungsversuche auf diesem Port für 30 Minuten verweigert. Andere gültige Werte für das
deny_time-Attribut sind FOREVER, wodurch eine Verbindung solange verweigert wird, bis xinetd neu gestartet wird, und NEVER, wodurch die Verbindung zugelassen und protokolliert wird.
Die letzte Zeile sollte Folgendes enthalten:
disable = no
Dadurch wird die Falle selbst aktiviert.
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
SENSORaktiviert ist, kann eine DoS-Attacke gegen bestimmte Hosts ausführen, indem er ihre IP-Adressen fälscht und sich mit dem verbotenen Port verbindet.
2.2.1.2.2. Kontrollieren von Server-Ressourcen
Ein weiteres, wichtiges Feature von
xinetd ist die Fähigkeit, für die von ihm kontrollierten Dienste Ressourcengrenzen festzulegen.
Dies wird durch die folgenden Direktiven erreicht:
cps = <number_of_connections> <wait_period>— Begrenzt die Frequenz der eingehenden Verbindungen. Diese Direktive akzeptiert zwei Parameter:<number_of_connections>— Die Anzahl der zu verarbeitenden Verbindungen pro Sekunde. Falls die Frequenz der eingehenden Verbindungen diesen Wert überschreitet, wird der Dienst zeitweise deaktiviert. Der Standardwert ist fünfzig (50).<wait_period>— Gibt die Anzahl der Sekunden an, die gewartet werden soll, bevor der Dienst nach dessen Deaktivierung neu gestartet werden soll. Die Standardzeitspanne beträgt zehn (10) Sekunden.
instances = <number_of_connections>— Gibt die Gesamtzahl aller erlaubten Verbindungen zu einem Dienst an. Diese Direktive akzeptiert entweder einen ganzzahligen Wert oderUNLIMITED.per_source = <number_of_connections>— Gibt die Anzahl der Verbindungen an, die pro Host zu einem Dienst erlaubt sind. Diese Direktive akzeptiert entweder einen ganzzahligen Wert oderUNLIMITED.rlimit_as = <number[K|M]>— Gibt die Größe des Speicheradressraums in Kilobyte oder Megabyte an, die der Dienst in Anspruch nehmen kann kann. Diese Direktive akzeptiert entweder einen ganzzahligen Wert oderUNLIMITED.rlimit_cpu = <number_of_seconds>— Gibt die Zeit in Sekunden an, die ein Dienst die CPU beanspruchen kann. Diese Direktive akzeptiert entweder einen ganzzahligen Wert oderUNLIMITED.
Mithilfe dieser Direktiven kann verhindert werden, dass ein einziger
xinetd-Dienst das gesamte System überschwemmt und einen Denial-of-Service verursacht.
