• Serversicherheit

Navigation: Start -> ServerAdminTutorials -> Serversicherheit

Serversicherheit

Der Grundschutzkatalog des BSI ist mit 3.800 Seiten für IT-Profis, deren tägliche Aufgabe die Administration von Servern ist, sicher eine umfangreiche Hilfe. Für jene, die nur gelegentlich einen kleinen Server im WWW administrieren, versuchen wir hier einen kurze Hilfestellung zur Erhöhung der Sicherheit zu geben. Die Umsetzung der Beispiele wird für Debian beschrieben.

Allgemeine Grundregeln

In jeder Publication zu diesem Thema findet man die Hinweise, Updates regelmäßig zeitnah zu installieren und nur die benötigten Dienste laufen zu lassen. Nicht benötigte Dienste sollten deinstalliert werden. Werden sie nur gestoppt, kommt es in der Regel nach einem Update oder Reboot ganz unauffällig zu einem Neustart.

SSH-Konfiguration

Die Server in einem Rechenzentrum werden in der Regel via SSH administriert. Ein paar kleine Hinweise zur Konfiguration des Daemons:

• Da im WWW Botnetze automatisiert nach offenen SSH-Ports (Port 22) suchen und versuchen, mittels Wörterbuch-Attacke Zugang zu Standard-Accounts wie root, ftp.... zu erlangen, sollte man den Port verschieben, an welchem der Daemon lauscht (z.B. auf Port 55022). Das reduziert auch den sinnlosen Bot-Traffic.
• Ein Login mit Passwort sollte deaktiviert werden. Sicherer ist es, einen SSH-Key zu nutzen. Der Public Key ist auf dem Server als authorisiert an die Datei $HOME/.ssh/authorized_keys anzuhängen. Der Login mit Passwort und über verschiedene PAM-Module kann komplett deativiert werden.
• das SSH-Protokoll 1 gilt als unsicher, es sollte nur die Protokollversion 2 zulässig sein.

Einige relevante Optionen aus der Konfiguration des SSH-Daemon in /etc/ssh/sshd_config, die häufig nach der Installation des Systems anzupassen sind:

Port 55022
Protocol 2
PermitRootLogin without-password   # oder no
PasswordAuthentication no
ChallengeResponseAuthentication no
X11Forwarding no
UsePAM no

Rootkit-Scanner nutzen

Rootkit-Scanner bieten zwar keine perfekte Sicherheit, im Fall der Fälle werden viele Angriffe jedoch erkannt. Debian bietet die Scanner rkhunter und chkrootkit im Repository. Sie werden wie üblich mit aptitude installiert. Nach der Installation können die Einstellungen für den tägliche Scan um 6:00 Uhr mit dem Kommando dpkg-reconfigure angepasst werden. Warnungen bei den täglichen Scans werden per E-Mail an den user root gesendet. Eine Weiterleitung der Nachrichten an den Admin-Account sollte konfiguriert werden (z.B. in der Datei /etc/aliases).

Auf der Kommandozeile werden die Scanner folgerndermaßen aufgerufen:

• rkhunter -c
• chkrootkit -q

rkhunter liefert standardmäßig eine Reihe von Fehlermeldungen über versteckte Dateien und Verzeichnisse. Um nicht täglich mit dem gleichen Stuff belästigt zu werden und dabei die wichtigen Meldungen zu übersehen, sollten in der Datei /etc/rkhunter.conf die nötigen Anpassungen über ALLOW-Statements konfiguriert werden. Die Datei enthält bereits alles nötige als Kommentar.

Datenbereiche verschlüsseln

Neben der Software enthält der Server auch die nötigen Daten und Logfiles. Diese können teilweise vertraulich sein, beispielsweise gehören die Identifikations-Keys von Anon-Servern zu den absolut vertraulichen Daten. Um diese Daten auch bei Ausbau der Festplatte durch Service-Personal (z.B. bei technischen Problemen) zu schützen, sollten sie in einem verschlüsselten Container abgelegt werden. Eine Anleitung zur Nutzung von DM-Crypt bietet das Privacy-Handbuch.

SWAP-Partition verschlüsseln

Die swap-Partition kann sensible Daten enthalten. Es ist vor allem für Anon-Server empfehlenswert, diese Partition zu verschlüsseln. Debian GNU/Linux bringt alles nötige dafür bereits mit.

In der Datei /etc/crypttab sind die folgenden Zeilen hinzuzufügen, wobei "/dev/sda2" durch die jeweils genutzten Partition zu ersetzen ist:

cryptswp  /dev/sda2  /dev/urandom  swap

Außerdem ist die swap-Partition in der Datei /etc/fstab anzupassen, welche die beim Bootprozess zu mountenden Partitionen enthält:

/dev/mapper/cryptswp  none  swap  sw  0  0

Die swap-Partition wird mit einem zufälligem Passwort beim Booten initialisiert und verschlüsselt. Mit dem Herunterfahren des Systems ist das Passwort verloren und keiner kommt an diese Daten ran.

Firewall nutzen

Eine restriktive Firewall sollte in jedem Fall genutzt werden. Eine Möglichkeit ist es, die Firewall mit Bastille-Linux zu konfigurieren. Ein kleines übersichtliches Script ist aber auch schnell geschrieben und einfach anzupassen:

IPT=/sbin/iptables
IFACE="eth0"

# Alle Werte zurücksetzen
$IPT -t mangle -F
$IPT -t mangle -X
$IPT -t nat -F
$IPT -t nat -X
$IPT -F
$IPT -X

# forwarding deaktivieren
echo 0 > /proc/sys/net/ipv4/ip_forward

# Default-Policies setzen
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT ACCEPT

# loopback freischalten
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT

# Antworten auf bestehende Verbindungen erlauben
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# ICMP erlauben (nur für einige ISPs nötig)
# $IPT -A INPUT -m state --state NEW -p icmp -j ACCEPT


##################################################
# Einzelene Dienste freischalten
##################################################

# SSH erlauben, max. 3 Versuche in 60sec (Port anpassen!)
$IPT -A INPUT -i $IFACE -p tcp --dport 55022 -m state --state NEW -m recent --set --name SSH
$IPT -A INPUT -i $IFACE -p tcp --dport 55022 -m state --state NEW -m recent --rcheck --seconds 60 --hitcount 4 --rttl --name SSH -j REJECT --reject-with tcp-reset
$IPT -A INPUT -i $IFACE -p tcp --dport 55022 -m state --state NEW -j ACCEPT


# DNS erlauben (BIND)
$IPT -A INPUT -i $IFACE -p tcp --dport 53 -j ACCEPT
$IPT -A INPUT -i $IFACE -p udp --dport 53 -j ACCEPT


# Webserver erlauben
$IPT -A INPUT -i $IFACE -p tcp --dport 443 -j ACCEPT
$IPT -A INPUT -i $IFACE -p tcp --dport 80 -j ACCEPT

# alles weitere verwerfen
$IPT -A INPUT -j DROP

Das Beispiel zeigt ein kurzes Script für einen via SSH adminstrierten Webserver. Weitere erreichbare Dienste kann man einfach ergänzen. Das Script ist als Textdatei zu speichern und mit chmod u+x als ausführbar zu kennzeichnen. Es ist nach jedem Reboot aufzurufen.

Ein kleiner Hinweis für TOR-Admins, die keinen Webserver auf ihrem Server nutzen: Es wird gern gesehen, wenn diese Nodes ihre Dienste auf den Ports 443 (ORPort) und Port 80 (DirPort) anbieten. Um dies zu realisieren ohne tor mit der UID root laufen zu lassen, können diese Ports mit folgenden Regeln umgeleitet werden:

# Ohne Webserver können die Ports 443 und 80 für TOR genutzt werden
# $IPT -t nat -A PREROUTING -p TCP -i $IFACE --dport 443 -j REDIRECT --to-ports 9001
# $IPT -t nat -A PREROUTING -p TCP -i $IFACE --dport 80 -j REDIRECT --to-ports 9030

In der Datei /etc/torrc sind die Ports des TOR-Servers wie folgt zu konfigurieren:

ORPort 443
ORListenAddress 0.0.0.0:9001

DirPort 80
DirListenAddress 0.0.0.0:9030

Intrusion Detection Environment nutzen

Nachdem alles eingerichtet und konfiguriert ist, kann ein Tool für den Filesystem Integritäts Check initialisiert werden. Debian GNU/Linux bietet mit AIDE ein Tool für das Aufspüren von Modifikationen an Dateien. Das Tool überprüft die Attribute und verschiedene Checksummen der Dateien und meldet sich, sobald Modifikationen erkannt werden. Damit sollte man die Installation beliebiger Trojaner erkennen können. Debian-typisch ist (fast) alles sinnvoll vorbereitet. Die Installation erfolgt wie üblich mit "aptitude install aide".

Nach der Installation kann die Datei /etc/aide.conf angepasst werden. In dieser Datei ist vor allem das Verzeichnis /tmp von einer Überprüfung auszunehmen, da die häufigen Änderungen zu Fehlalarmen führen. Auch für die $HOME-Verzeichnisse sind besondere Regeln zu konfigurieren. Die Anpassung der Regeln kann ein paar Tage in Anspruch nehmen.

!/tmp$
/home$ p+u+g
!/var/lib/rkhunter/tmp$

Anschließend kann man mit dem Kommando "aideinit" die Datenbasis initialisieren. In Abweichung von der Dokumentation ist NICHT "aide --init" unter Debian aufzurufen. Damit erhält man eine leere Datenbasis. Das Debian-Team stellt Wrapper-Scripte für die Nutzung bereit.

Die Überprüfung des Systems erfolgt mit "aide.wrapper --check". Dieser Check sollte vor jedem Einspeilen von Updates durchgeführt werden!

Nach legalen Änderungen durch Updates und Anpassungen der Konfiguration des Systems ist die Datenbasis zu aktualisieren mit dem Kommando "aide.wrapper --update".

Den tagtäglichen automatisierten Check konfiguriert man in der Datei /etc/default/aide. Hier ist eine E-Mail Adresse für die Fehlermeldungen zu konfigurieren.

In der Dokumention findet man die Empfehlung, die Datenbasis auf einen schreibgeschützten Datenträger zu kopieren und diese Kopie für den Test zu nutzen. Das ist bei einem Server im Rechenzentrum schwer realisierbar. Man kann die Datei jedoch gegen Änderungen immunisieren und Modifikationen an dieser Datenbasis erschweren: "chattr +i /var/lib/aide/aide.db". Vor einem Update der Datenbasis ist diese Immunisierung rückgängig zu machen. "chattr -i /var/lib/aide/aide.db".