Jimini
PCGH-Community-Veteran(in)
Aloha,
da das Interesse an Servern immer mehr zunimmt, steigt natürlich auch der Anteil derer, die neu in diesem Umfeld sind. Zusammen mit dem Umstand, dass virtuelle Server mittlerweile a) recht potent und b) ziemlich bezahlbar sind, ergibt das natürlich eine steigende Anzahl von Systemen, die an einer fetten Anbindung im Netz hängen, aber ziemlich ungeschützt sind. Das Ergebnis ist quasi der Traum eines Crackers / Spam-Versenders etc.
Da das Absichern eines Linux-Systems zwar komplex, aber keineswegs ein Buch mit sieben Siegeln ist, habe ich hier einen Guide mit den wichtigsten Schritten erstellt. Die meisten dieser Schritte lassen sich natürlich auch auf einen Homeserver übertragen - ein solcher sollte ebenso wie ein "öffentlicher" vServer anständig konfiguriert und abgesichert sein. Als Betriebssystem verwende ich Debian 7.6 (Wheezy), die Schritte lassen sich aber größtenteils auf jede andere gängige Linux-Distribution übertragen.
Dieser Guide setzt grundlegende Linux- und Netzwerk-Kenntnisse voraus - ihr solltet also etwa wissen, wie man eine Shell bedient und wie man eine Konfigurationsdatei editiert.
1 - Konzept und Vorbereitungen
In diesem Teil gehe ich auf die Vorbereitung und die Planung eines entsprechenden Systems ein.
2 - Konfiguration
Der mit Abstand umfangreichste Teil. Hier richten wir alle Dienste so ein, dass sie dauerhaft lauffähig sind.
3 - Routineaufgaben
Mit der Installation und Einrichtung verschiedener Daemons ist es nicht getan - die "echte" Administration geht jetzt erst los.
Die für mich fast wichtigsten Utensilien beim Aufsetzen eines Serversystems sind Papier und Stift. In seltenen Fällen läuft alles auf Anhieb und da man ebenso selten alles in einem Rutsch erledigt, sind Notizen verdammt nützlich und sinnvoll.
Ich lege mir für solche Situationen immer eine Liste der zu installierenden Software an, welche ich dann nach und nach abarbeite.
Ich gehe an dieser Stelle davon aus, dass ein entsprechendes System bereits beschafft bzw. zur Verfügung gestellt wurde. Im Falle eines Homeservers ist die Linux-Distribution der Wahl installiert, haben wir einen vServer gemietet, so wurden uns die Zugangsdaten zur Verfügung gestellt und wir können uns als root auf dem System einloggen.
Wir haben uns also auf dem neuen System eingeloggt und verfügen über alle Rechte, die wir brauchen.
2.1 - Nutzerkonten
Handelt es sich um einen gemieteten Server, ändern wir als allererstes das root-Passwort durch das Ausführen von passwd. Danach legen wir mittels adduser benutzername einen unprivilegierten Benutzer an. Möchten wir (weiterhin) sudo nutzen, fügen wir den soeben neu angelegten Nutzer mit addgroup benutzername sudo zur Gruppe "sudo" hinzu.
Es folgt ein Test dahingehend, ob sich der neu angelegte Nutzer via SSH auf dem System einloggen und mittels sudo root-Rechte erlangen kann.
2.2 - Netzwerkkonfiguration bearbeiten (gilt nur für Homeserver)
Wenn der Server zuhause steht, ist es sinnvoll, ihm eine feste IP-Adresse zuzuweisen. Je nach verwendeter Linux-Distribution unterscheiden sich die Config-Files sehr stark.
Erstes Beispiel für Debian / Ubuntu: /etc/network/interfaces
Hier wird nur ein Netzwerkinterface (10.0.0.10) genutzt. Dieses stellt über einen Router (10.0.0.1) eine Internetverbindung her.
Zweites Beispiel für Debian / Ubuntu: /etc/network/interfaces
eth0 stellt hierbei die Internetverbindung her (bei einer Kabel-Anbindung geschieht das einfach über DHCP) und eth1 (10.0.0.1) bindet das System an das interne Netzwerk an.
Die Änderungen werden anschließend mit /etc/init.d/networking restart übernommen und - oh Wunder - auch hier folgt wieder ein Test (beispielsweise durch das Pingen einer Domain).
2.3 - SSHd absichern #1: root-Zugang deaktivieren
Als nächstes konfigurieren wir den SSHd so, dass ein SSH-Login auf root nicht mehr möglich ist. Dazu öffnen wir /etc/ssh/sshd_config und ändern die Zeile PermitRootLogin yes auf PermitRootLogin no. Durch das Neustarten des SSHd (/etc/init.d/ssh restart) werden die Änderungen übernommen.
Auch hier testen wir, ob ein root-Zugang via SSH noch möglich ist und - ganz wichtig - ob der soeben neu angelegte Nutzer nach wie vor auf das System kommt.
2.4 - SSHd absichern #2: Port ändern
Es empfiehlt sich zudem, den SSHd nicht auf dem Standardport 22 laufen zu lassen. Natürlich bringt eine solche Maßnahme keine absolute Sicherheit mit sich - man erspart sich aber Tausende von Logeinträgen durch Bots, welche a) nach Systemen mit offenem Port 22 suchen und b) dort dann versuchen, Zugang zu erlangen. Um den verwendeten Port zu ändern, bearbeiten wir einfach wieder /etc/ssh/sshd_config und wählen einen anderen Port.
Auch hier empfiehlt sich nach einem Neustart des SSHd ein Test.
2.5 - SSHd absichern #3: Public-Key-Auth
Noch sicherer wird es, wenn man sich nicht mehr mit einem Passwort, sondern nur noch mit einem Keyfile einloggen kann. Eigentlich sind es genau genommen zwei Keys - ein privater und ein öffentlicher. Der private Key liegt lokal auf dem Rechner, von dem aus wir uns auf dem Server einloggen wollen. Der öffentliche wurde auf dem Server hinterlegt. Wollen wir nun eine Verbindung herstellen, müssen wir uns mit einem Passwort gegenüber dem private Key authentifizieren. Daraufhin wird der private Key mit der Liste der erlaubten Keys auf dem Server verglichen und eine Verbindung gestattet oder abgelehnt.
Hierzu generieren wir mittels ssh-keygen einen Key. Möchte man kein Passwort eingeben - was nicht empfehlenswert ist - so lässt man dieses leer. Als nächstes muss der Public Key (in der Regel im jeweiligen Homeverzeichnis unter ~/.ssh/id-rsa.pub) auf dem Zielsystem in ~./ssh/authorized_keys des vorhin eingerichteten Benutzers kopiert werden.
Natürlich testen wir hier auch wieder, ob ein Login unter Verwendung des Keys sauber funktioniert.
Danach konfigurieren wir den SSHd so, dass ein Login unter Verwendung eines Passworts nicht mehr möglich ist, sondern nur noch das Pubkey-Verfahren akzeptiert wird. Hierzu muss die Option "PubkeyAuthentication" auf "yes" gesetzt sein sowie "PasswordAuthentication" auf "no".
Auch hier empfehle ich dringend einen Test - am besten einmal als Nutzer, welcher im Besitz des Keys ist und einmal als anderer Nutzer. Dieser sollte dann die Fehlermeldung "Permission denied (publickey)." erhalten, während sich der Nutzer mit dem gültigen Key einloggen kann.
2.6 - Updates installieren
Als nächstes sollte die installierte Software auf den neusten Stand gebracht werden. Bei einem Homeserver sollte diese schon größtenteils aktuell sein, bei vServern hingegen sind die installierten Pakete erschreckend oft (sehr) veraltet. Dies kann man mit apt-get update und anschließendem apt-get dist-upgrade beheben. Sollte dabei der Kernel aktualisiert werden, sollten wir das System sicherheitshalber rebooten.
2.7 - Firewall mit iptables
Meiner Meinung nach sollte jedes Linux-System, welches direkt am Netz hängt und / oder sensible Daten beherbergt, mit iptables abgesichert werden. Die iptables stellen ein Frontend zu den netfilter-Modulen im Linux-Kernel dar. Die im nächsten Schritt zu schreibenden Firewall-Regeln haben das Ziel, nur als erlaubt definierten Traffic durchzulassen. Alles andere wird geblockt / verworfen. Auf den meisten Systemen ist iptables bereits installiert.
Als Grundlage für die Firewall auf einem routenden Homeserver kann folgendes Skript dienen:
Für einen vServer wird das Skript etwas abgeändert:
Egal für welche der beiden Versionen wir uns entscheiden - wir packen sie in eine Datei (beispielsweise /usr/bin/firewall_active) und machen diese mit chmod +x /usr/bin/firewall_active ausführbar. Bitte die Datei an dieser Stelle noch nicht ausführen!
Dazu erstellen wir noch ein Skript, welches die Firewall deaktiviert (konsequenterweise /usr/bin/firewall_inactive):
Auch diese Datei machen wir ausführbar und führen sie testweise aus. Danach fügen wir in /etc/crontab folgenden Eintrag ein:
"15" und "10" bewirken, dass um 10:15 die Firewall aktiviert wird. Ändert diese Werte so ab, dass das Skript stattdessen in 5 Minuten aufgerufen wird. Solltet ihr euch nämlich durch einen Fehler im Firewallskript aus dem System aussperren, so kommt ihr in 5 Minuten wieder rein.
Danach aktiviert ihr die Firewall und schaut, ob ihr nach wie vor auf das System zugreifen könnt.
Es ist natürlich sinnvoll, die Firewall direkt beim Systemstart zu aktivieren. Es gibt zwei Möglichkeiten:
1) das Aufrufen des Firewallskripts nach dem Bootvorgang durch einen entsprechenden Eintrag in /etc/rc.local
2) das Koppeln des Starts des Netztwerks mit der Aktivierung der Firewall (Anleitungen für Debian / Ubuntu / Gentoo)
Wenn ihr sichergehen wollt, dass das alles funktioniert, könnt ihr die Kiste an dieser Stelle rebooten.
2.8 - Logging
Das Logging wird gerne unterschätzt, ist aber ein sehr wichtiger Aspekt bei der Administration eines Serversystems. Für gewöhnlich ist schon ein Loggingdienst installiert, welcher seinen Ouput unter /var/log speichert. Wenn ihr das Syslog (meistens liegt das in /var/log/syslog oder /var/log/messages) während eurer Arbeit am System beobachtet, lassen sich frühzeitig Probleme erkennen. Ideal ist es, dazu eine weitere Shell zu öffnen und das Log mittels tail -f /var/log/syslog kontinuierlich im Blick zu haben.
Das Firewallskript weist iptables an, nicht erfasste Pakete nicht still und leise zu verwerfen, sondern dies zusätzlich im Log zu vermerken. Dies ist beispielsweise dann extrem nützlich, wenn ein frisch installierter Dienst nicht erreichbar ist oder sonstige Verbindungsversuche - etwa beim Download von Updates - fehlschlagen.
Insbesondere in den ersten "Lebenstagen" des Systems ist eine regelmäßige Analyse der Logs also nicht nur hilfreich, sondern dringend anzuraten.
2.9 - restliche Software
Nachdem ihr für ein sauberes und sicheres Grundsystem gesorgt habt, könnt ihr auch daran machen, weitere benötigte Software zu installieren und zu konfigurieren.
Quellen und weitere Infos:
- Ubuntu: Benutzer und Gruppen
- Debian-Benutzerverwaltung
- Nutzer hinzufügen unter Gentoo
- SSH-Public-Key-Authentifizierung
- Wikipedia-Artikel zur Public-Key-Authentifizierung
- Konfiguration des Netzwerks unter Debian / Ubuntu / Gentoo
- iptables-Artikel im Ubuntu-Wiki
- Logging-Artikel im Ubuntu-Wiki
Nachdem euer Server eingerichtet ist und zuverlässig seinen Dienst verrichtet, könnt ihr euch nun zurücklehnen - die Arbeit ist erledigt und ihr müsst euch von nun an um nichts mehr kümmern. Richtig? Falsch!
Die Administration eines Servers ist ein kontinuierlicher Prozess. Selbst wenn es keine Probleme gibt, müsst ihr damit rechnen, euch regelmäßig dem System widmen zu müssen, denn es gilt, immer wieder Routinearbeiten durchzuführen.
3.1 - Software aktuell halten
Die Sicherheit eures Systems steht und fällt mit der eingesetzten Software. Dies gilt inbesondere für Sicherheitslücken, welche immer wieder entdeckt werden und eine schnelle Reaktion des Admins erfordern. Gewöhnt euch daher an, regelmäßig zumindest die Sicherheitsupdates zu installieren.
3.2 - Backups
Sei es ein Festplattenausfall, ein Anwenderfehler oder gar ein erfolgreicher Angriff auf euer System - ein möglichst aktuelles Backup kann extrem viel Stress und Arbeit ersparen. Dies gilt nicht nur für einen Homeserver; Hoster bieten in der Regel Slots für Image-Backups an, dennoch ist es sinnvoll, sich unabhängig davon selbst um die Backups zu kümmern.
Legt daher nicht nur vor Arbeiten an wichtigen Konfigurationsdateien eine Sicherung selbiger an, sondern sichert die wichtigsten Daten regelmäßig auf ein zusätzliches System.
3.3 - Monitoring
Darüber hinaus ist es sehr empfehlenswert, regelmäßig den Zustand des Systems zu checken. Ist genügend Speicherplatz verfügbar (df -h)? Ist genügend freier Arbeitsspeicher vorhanden (free)? Läuft vielleicht ein Prozess Amok und lastet das System aus (top)? Ist die Temperatur der Festplatten in Ordnung (hddtemp)? Zudem sollte ein Blick in die Logs zur Gewohnheit werden.
3.4 - Informationen beschaffen
News zu Sicherheitslücken und andere wichtige Informationen erscheinen in der Regel sehr zeitnah. Schaut daher regelmäßig auf entsprechende News-Seiten oder abonniert die entsprechenden Mailinglisten eurer Distribution, um auf dem Laufenden zu bleiben.
In dieser Anleitung habe ich dargestellt, welche grundsätzlichen Schritte empfehlenswert zur Einrichtung und Absicherung eines Linux-Serversystems sind. Ich habe mich hierbei auf Debian bezogen, das Konzept ist aber auf jedes Linux-System übertragbar. Ich werde diesen Thread dazu nutzen, in Kürze weitere Anleitungen zu posten - etwa zu empfehlenswerter Software, der Implementierung einer sinnvollen Backup-Strategie oder zur Möglichkeiten der Log-Analyse.
Auch wenn ich den Guide an einem frischen System auf seine Tauglichkeit hin überprüft habe, kann ich natürlich nicht ausschließen, dass mir ein Fehler unterlaufen ist. Tippt daher die hier vorgestellten Befehle und Skripts nicht blind ab, sondern denkt mit
Bei Fragen und Antworten stehe ich selbstverständlich gerne hier im Thread zur Verfügung.
MfG Jimini
da das Interesse an Servern immer mehr zunimmt, steigt natürlich auch der Anteil derer, die neu in diesem Umfeld sind. Zusammen mit dem Umstand, dass virtuelle Server mittlerweile a) recht potent und b) ziemlich bezahlbar sind, ergibt das natürlich eine steigende Anzahl von Systemen, die an einer fetten Anbindung im Netz hängen, aber ziemlich ungeschützt sind. Das Ergebnis ist quasi der Traum eines Crackers / Spam-Versenders etc.
Da das Absichern eines Linux-Systems zwar komplex, aber keineswegs ein Buch mit sieben Siegeln ist, habe ich hier einen Guide mit den wichtigsten Schritten erstellt. Die meisten dieser Schritte lassen sich natürlich auch auf einen Homeserver übertragen - ein solcher sollte ebenso wie ein "öffentlicher" vServer anständig konfiguriert und abgesichert sein. Als Betriebssystem verwende ich Debian 7.6 (Wheezy), die Schritte lassen sich aber größtenteils auf jede andere gängige Linux-Distribution übertragen.
Dieser Guide setzt grundlegende Linux- und Netzwerk-Kenntnisse voraus - ihr solltet also etwa wissen, wie man eine Shell bedient und wie man eine Konfigurationsdatei editiert.
1 - Konzept und Vorbereitungen
In diesem Teil gehe ich auf die Vorbereitung und die Planung eines entsprechenden Systems ein.
2 - Konfiguration
Der mit Abstand umfangreichste Teil. Hier richten wir alle Dienste so ein, dass sie dauerhaft lauffähig sind.
3 - Routineaufgaben
Mit der Installation und Einrichtung verschiedener Daemons ist es nicht getan - die "echte" Administration geht jetzt erst los.
1 - Konzept und Vorbereitungen
Die für mich fast wichtigsten Utensilien beim Aufsetzen eines Serversystems sind Papier und Stift. In seltenen Fällen läuft alles auf Anhieb und da man ebenso selten alles in einem Rutsch erledigt, sind Notizen verdammt nützlich und sinnvoll.
Ich lege mir für solche Situationen immer eine Liste der zu installierenden Software an, welche ich dann nach und nach abarbeite.
Ich gehe an dieser Stelle davon aus, dass ein entsprechendes System bereits beschafft bzw. zur Verfügung gestellt wurde. Im Falle eines Homeservers ist die Linux-Distribution der Wahl installiert, haben wir einen vServer gemietet, so wurden uns die Zugangsdaten zur Verfügung gestellt und wir können uns als root auf dem System einloggen.
2 - Konfiguration
Wir haben uns also auf dem neuen System eingeloggt und verfügen über alle Rechte, die wir brauchen.
2.1 - Nutzerkonten
Handelt es sich um einen gemieteten Server, ändern wir als allererstes das root-Passwort durch das Ausführen von passwd. Danach legen wir mittels adduser benutzername einen unprivilegierten Benutzer an. Möchten wir (weiterhin) sudo nutzen, fügen wir den soeben neu angelegten Nutzer mit addgroup benutzername sudo zur Gruppe "sudo" hinzu.
Es folgt ein Test dahingehend, ob sich der neu angelegte Nutzer via SSH auf dem System einloggen und mittels sudo root-Rechte erlangen kann.
2.2 - Netzwerkkonfiguration bearbeiten (gilt nur für Homeserver)
Wenn der Server zuhause steht, ist es sinnvoll, ihm eine feste IP-Adresse zuzuweisen. Je nach verwendeter Linux-Distribution unterscheiden sich die Config-Files sehr stark.
Erstes Beispiel für Debian / Ubuntu: /etc/network/interfaces
Code:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.0.0.10
netmask 255.255.255.0
gateway 10.0.0.1
Zweites Beispiel für Debian / Ubuntu: /etc/network/interfaces
Code:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet static
address 10.0.0.1
netmask 255.255.255.0
Die Änderungen werden anschließend mit /etc/init.d/networking restart übernommen und - oh Wunder - auch hier folgt wieder ein Test (beispielsweise durch das Pingen einer Domain).
2.3 - SSHd absichern #1: root-Zugang deaktivieren
Als nächstes konfigurieren wir den SSHd so, dass ein SSH-Login auf root nicht mehr möglich ist. Dazu öffnen wir /etc/ssh/sshd_config und ändern die Zeile PermitRootLogin yes auf PermitRootLogin no. Durch das Neustarten des SSHd (/etc/init.d/ssh restart) werden die Änderungen übernommen.
Auch hier testen wir, ob ein root-Zugang via SSH noch möglich ist und - ganz wichtig - ob der soeben neu angelegte Nutzer nach wie vor auf das System kommt.
2.4 - SSHd absichern #2: Port ändern
Es empfiehlt sich zudem, den SSHd nicht auf dem Standardport 22 laufen zu lassen. Natürlich bringt eine solche Maßnahme keine absolute Sicherheit mit sich - man erspart sich aber Tausende von Logeinträgen durch Bots, welche a) nach Systemen mit offenem Port 22 suchen und b) dort dann versuchen, Zugang zu erlangen. Um den verwendeten Port zu ändern, bearbeiten wir einfach wieder /etc/ssh/sshd_config und wählen einen anderen Port.
Auch hier empfiehlt sich nach einem Neustart des SSHd ein Test.
2.5 - SSHd absichern #3: Public-Key-Auth
Noch sicherer wird es, wenn man sich nicht mehr mit einem Passwort, sondern nur noch mit einem Keyfile einloggen kann. Eigentlich sind es genau genommen zwei Keys - ein privater und ein öffentlicher. Der private Key liegt lokal auf dem Rechner, von dem aus wir uns auf dem Server einloggen wollen. Der öffentliche wurde auf dem Server hinterlegt. Wollen wir nun eine Verbindung herstellen, müssen wir uns mit einem Passwort gegenüber dem private Key authentifizieren. Daraufhin wird der private Key mit der Liste der erlaubten Keys auf dem Server verglichen und eine Verbindung gestattet oder abgelehnt.
Hierzu generieren wir mittels ssh-keygen einen Key. Möchte man kein Passwort eingeben - was nicht empfehlenswert ist - so lässt man dieses leer. Als nächstes muss der Public Key (in der Regel im jeweiligen Homeverzeichnis unter ~/.ssh/id-rsa.pub) auf dem Zielsystem in ~./ssh/authorized_keys des vorhin eingerichteten Benutzers kopiert werden.
Natürlich testen wir hier auch wieder, ob ein Login unter Verwendung des Keys sauber funktioniert.
Danach konfigurieren wir den SSHd so, dass ein Login unter Verwendung eines Passworts nicht mehr möglich ist, sondern nur noch das Pubkey-Verfahren akzeptiert wird. Hierzu muss die Option "PubkeyAuthentication" auf "yes" gesetzt sein sowie "PasswordAuthentication" auf "no".
Auch hier empfehle ich dringend einen Test - am besten einmal als Nutzer, welcher im Besitz des Keys ist und einmal als anderer Nutzer. Dieser sollte dann die Fehlermeldung "Permission denied (publickey)." erhalten, während sich der Nutzer mit dem gültigen Key einloggen kann.
2.6 - Updates installieren
Als nächstes sollte die installierte Software auf den neusten Stand gebracht werden. Bei einem Homeserver sollte diese schon größtenteils aktuell sein, bei vServern hingegen sind die installierten Pakete erschreckend oft (sehr) veraltet. Dies kann man mit apt-get update und anschließendem apt-get dist-upgrade beheben. Sollte dabei der Kernel aktualisiert werden, sollten wir das System sicherheitshalber rebooten.
2.7 - Firewall mit iptables
Meiner Meinung nach sollte jedes Linux-System, welches direkt am Netz hängt und / oder sensible Daten beherbergt, mit iptables abgesichert werden. Die iptables stellen ein Frontend zu den netfilter-Modulen im Linux-Kernel dar. Die im nächsten Schritt zu schreibenden Firewall-Regeln haben das Ziel, nur als erlaubt definierten Traffic durchzulassen. Alles andere wird geblockt / verworfen. Auf den meisten Systemen ist iptables bereits installiert.
Als Grundlage für die Firewall auf einem routenden Homeserver kann folgendes Skript dienen:
Code:
#!/bin/bash
### KERNEL-OPTIONEN
# Antispoofing
echo "1" > /proc/sys/net/ipv4/conf/all/arp_filter
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
# martian packets loggen?
echo "0" > /proc/sys/net/ipv4/conf/all/log_martians
# ICMP Redirects verweigern
echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects
# Source Routing deaktivieren
echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
# ICMP Broadcast Echos ignorieren
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Bogus ICMP-Errors ignorieren
echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# Forwarding aktivieren (wird nur benötigt, wenn das System routet)
echo "1" > /proc/sys/net/ipv4/ip_forward
### GENERELLE EINSTELLUNGEN
lan="eth1"
wan="eth0"
intern=10.0.0.0/24
### FILTERREGELN
# Vorhandene Tabellen löschen (die nat-Zeile wird nur benötigt, wenn das System routet)
iptables -F
iptables -t nat -F
iptables -t mangle -F
# Default-Policy: alles droppen
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# Default-Policy: alles natten, erst beim Filtern verwerfen (wird nur benötigt, wenn das System routet)
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
# Akzeptiere Verbindungsaufbauten aus dem LAN (wird nur benötigt, wenn das System routet)
iptables -A FORWARD -s $intern -i $lan -o $wan -j ACCEPT
# Akzeptiere alle Pakete, die zu einer aufgebauten Verbindung gehören
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Akzeptiere lokalen Traffic
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Alle Pakete bei der Weiterleitung nach aussen maskieren (wird nur benötigt, wenn das System routet)
iptables -t nat -A POSTROUTING -o $wan -j MASQUERADE
# DNS (das System darf DNS-Verbindungen zu zwei Systemen aufbauen)
iptables -A OUTPUT -d 1.2.3.4,5.6.7.8 -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -d 1.2.3.4,5.6.7.8 -p udp --dport 53 -j ACCEPT
# FTP (das System darf FTP-Verbindungen zu zwei Systemen aufbauen)
iptables -A OUTPUT -p tcp -d 1.2.3.4 --dport 21 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp -d 5.6.7.8 --dport 21 -m state --state NEW -j ACCEPT
# HTTP
iptables -A INPUT -p tcp --sport 80 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
# HTTPS
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 443 -j ACCEPT
# NTP
iptables -A OUTPUT -p udp -d 1.2.3.4 --dport 123 -j ACCEPT
# SSH (läuft auf 10.0.0.1 auf Port 12345, Anfragen von 1.2.3.4 werden zugelassen und direkt auf den richtigen Port weitergeleitet)
iptables -A INPUT -p tcp -s 1.2.3.4 --dport 22 -j ACCEPT
iptables -t nat -A PREROUTING -s 1.2.3.4 -p tcp --dport 22 -j DNAT --to 10.0.0.1:12345
iptables -A INPUT -p tcp --dport 12345 -m conntrack --ctstate NEW -j ACCEPT
### LOGGING
# alles, was durch die vorherigen Regeln nicht erfasst wurde, wird abgewiesen (rejected) und geloggt (sehr nützlich für die anfängliche Fehlersuche)
iptables -A INPUT -j LOG --log-prefix "DROPPED_INPUT: " --log-level=5
iptables -A INPUT -j REJECT
iptables -A OUTPUT -j LOG --log-prefix "DROPPED_OUTPUT: " --log-level=5
iptables -A OUTPUT -j REJECT
iptables -A FORWARD -j LOG --log-prefix "DROPPED_FORWARD: " --log-level=5
iptables -A FORWARD -j REJECT
### Speichern der Regeln
iptables-save > /etc/iptables.conf
Für einen vServer wird das Skript etwas abgeändert:
Code:
#!/bin/bash
### KERNEL-OPTIONEN
# Antispoofing
echo "1" > /proc/sys/net/ipv4/conf/all/arp_filter
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
# martian packets loggen?
echo "0" > /proc/sys/net/ipv4/conf/all/log_martians
# ICMP Redirects verweigern
echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects
# Source Routing deaktivieren
echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
# ICMP Broadcast Echos ignorieren
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Bogus ICMP-Errors ignorieren
echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
### FILTERREGELN
# Vorhandene Tabellen löschen
iptables -F
iptables -t mangle -F
# Default-Policy: alles droppen
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# Akzeptiere alle Pakete, die zu einer aufgebauten Verbindung gehören
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Akzeptiere lokalen Traffic
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# DNS (das System darf DNS-Verbindungen zu zwei Systemen aufbauen)
iptables -A OUTPUT -d 1.2.3.4,5.6.7.8 -p tcp --dport 53 -j ACCEPT
iptables -A OUTPUT -d 1.2.3.4,5.6.7.8 -p udp --dport 53 -j ACCEPT
# FTP (das System darf FTP-Verbindungen zu zwei Systemen aufbauen)
iptables -A OUTPUT -p tcp -d 1.2.3.4 --dport 21 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp -d 5.6.7.8 --dport 21 -m state --state NEW -j ACCEPT
# HTTP
iptables -A INPUT -p tcp --sport 80 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
# HTTPS
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 443 -j ACCEPT
# NTP
iptables -A OUTPUT -p udp -d 1.2.3.4 --dport 123 -j ACCEPT
# SSH (läuft auf 10.0.0.1 auf Port 12345, Anfragen von 1.2.3.4 werden zugelassen und direkt auf den richtigen Port weitergeleitet)
iptables -A INPUT -p tcp -s 1.2.3.4 --dport 22 -j ACCEPT
iptables -t nat -A PREROUTING -s 1.2.3.4 -p tcp --dport 22 -j DNAT --to 10.0.0.1:12345
iptables -A INPUT -p tcp --dport 12345 -m conntrack --ctstate NEW -j ACCEPT
### LOGGING
# alles, was durch die vorherigen Regeln nicht erfasst wurde, wird abgewiesen (rejected) und geloggt (sehr nützlich für die anfängliche Fehlersuche)
iptables -A INPUT -j LOG --log-prefix "DROPPED_INPUT: " --log-level=5
iptables -A INPUT -j REJECT
iptables -A OUTPUT -j LOG --log-prefix "DROPPED_OUTPUT: " --log-level=5
iptables -A OUTPUT -j REJECT
iptables -A FORWARD -j LOG --log-prefix "DROPPED_FORWARD: " --log-level=5
iptables -A FORWARD -j REJECT
### Speichern der Regeln
iptables-save > /etc/iptables.conf
Egal für welche der beiden Versionen wir uns entscheiden - wir packen sie in eine Datei (beispielsweise /usr/bin/firewall_active) und machen diese mit chmod +x /usr/bin/firewall_active ausführbar. Bitte die Datei an dieser Stelle noch nicht ausführen!
Dazu erstellen wir noch ein Skript, welches die Firewall deaktiviert (konsequenterweise /usr/bin/firewall_inactive):
Code:
#!/bin/bash
# alle vorhandenen Regeln löschen
iptables -F
iptables -t nat -F
iptables -t mangle -F
# Default-Policies wiederherstellen
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
Code:
15 10 * * * root /usr/bin/firewall_inactive
Danach aktiviert ihr die Firewall und schaut, ob ihr nach wie vor auf das System zugreifen könnt.
Es ist natürlich sinnvoll, die Firewall direkt beim Systemstart zu aktivieren. Es gibt zwei Möglichkeiten:
1) das Aufrufen des Firewallskripts nach dem Bootvorgang durch einen entsprechenden Eintrag in /etc/rc.local
2) das Koppeln des Starts des Netztwerks mit der Aktivierung der Firewall (Anleitungen für Debian / Ubuntu / Gentoo)
Wenn ihr sichergehen wollt, dass das alles funktioniert, könnt ihr die Kiste an dieser Stelle rebooten.
2.8 - Logging
Das Logging wird gerne unterschätzt, ist aber ein sehr wichtiger Aspekt bei der Administration eines Serversystems. Für gewöhnlich ist schon ein Loggingdienst installiert, welcher seinen Ouput unter /var/log speichert. Wenn ihr das Syslog (meistens liegt das in /var/log/syslog oder /var/log/messages) während eurer Arbeit am System beobachtet, lassen sich frühzeitig Probleme erkennen. Ideal ist es, dazu eine weitere Shell zu öffnen und das Log mittels tail -f /var/log/syslog kontinuierlich im Blick zu haben.
Das Firewallskript weist iptables an, nicht erfasste Pakete nicht still und leise zu verwerfen, sondern dies zusätzlich im Log zu vermerken. Dies ist beispielsweise dann extrem nützlich, wenn ein frisch installierter Dienst nicht erreichbar ist oder sonstige Verbindungsversuche - etwa beim Download von Updates - fehlschlagen.
Insbesondere in den ersten "Lebenstagen" des Systems ist eine regelmäßige Analyse der Logs also nicht nur hilfreich, sondern dringend anzuraten.
2.9 - restliche Software
Nachdem ihr für ein sauberes und sicheres Grundsystem gesorgt habt, könnt ihr auch daran machen, weitere benötigte Software zu installieren und zu konfigurieren.
Quellen und weitere Infos:
- Ubuntu: Benutzer und Gruppen
- Debian-Benutzerverwaltung
- Nutzer hinzufügen unter Gentoo
- SSH-Public-Key-Authentifizierung
- Wikipedia-Artikel zur Public-Key-Authentifizierung
- Konfiguration des Netzwerks unter Debian / Ubuntu / Gentoo
- iptables-Artikel im Ubuntu-Wiki
- Logging-Artikel im Ubuntu-Wiki
3 - Routineaufgaben
Nachdem euer Server eingerichtet ist und zuverlässig seinen Dienst verrichtet, könnt ihr euch nun zurücklehnen - die Arbeit ist erledigt und ihr müsst euch von nun an um nichts mehr kümmern. Richtig? Falsch!
Die Administration eines Servers ist ein kontinuierlicher Prozess. Selbst wenn es keine Probleme gibt, müsst ihr damit rechnen, euch regelmäßig dem System widmen zu müssen, denn es gilt, immer wieder Routinearbeiten durchzuführen.
3.1 - Software aktuell halten
Die Sicherheit eures Systems steht und fällt mit der eingesetzten Software. Dies gilt inbesondere für Sicherheitslücken, welche immer wieder entdeckt werden und eine schnelle Reaktion des Admins erfordern. Gewöhnt euch daher an, regelmäßig zumindest die Sicherheitsupdates zu installieren.
3.2 - Backups
Sei es ein Festplattenausfall, ein Anwenderfehler oder gar ein erfolgreicher Angriff auf euer System - ein möglichst aktuelles Backup kann extrem viel Stress und Arbeit ersparen. Dies gilt nicht nur für einen Homeserver; Hoster bieten in der Regel Slots für Image-Backups an, dennoch ist es sinnvoll, sich unabhängig davon selbst um die Backups zu kümmern.
Legt daher nicht nur vor Arbeiten an wichtigen Konfigurationsdateien eine Sicherung selbiger an, sondern sichert die wichtigsten Daten regelmäßig auf ein zusätzliches System.
3.3 - Monitoring
Darüber hinaus ist es sehr empfehlenswert, regelmäßig den Zustand des Systems zu checken. Ist genügend Speicherplatz verfügbar (df -h)? Ist genügend freier Arbeitsspeicher vorhanden (free)? Läuft vielleicht ein Prozess Amok und lastet das System aus (top)? Ist die Temperatur der Festplatten in Ordnung (hddtemp)? Zudem sollte ein Blick in die Logs zur Gewohnheit werden.
3.4 - Informationen beschaffen
News zu Sicherheitslücken und andere wichtige Informationen erscheinen in der Regel sehr zeitnah. Schaut daher regelmäßig auf entsprechende News-Seiten oder abonniert die entsprechenden Mailinglisten eurer Distribution, um auf dem Laufenden zu bleiben.
Fazit
In dieser Anleitung habe ich dargestellt, welche grundsätzlichen Schritte empfehlenswert zur Einrichtung und Absicherung eines Linux-Serversystems sind. Ich habe mich hierbei auf Debian bezogen, das Konzept ist aber auf jedes Linux-System übertragbar. Ich werde diesen Thread dazu nutzen, in Kürze weitere Anleitungen zu posten - etwa zu empfehlenswerter Software, der Implementierung einer sinnvollen Backup-Strategie oder zur Möglichkeiten der Log-Analyse.
Auch wenn ich den Guide an einem frischen System auf seine Tauglichkeit hin überprüft habe, kann ich natürlich nicht ausschließen, dass mir ein Fehler unterlaufen ist. Tippt daher die hier vorgestellten Befehle und Skripts nicht blind ab, sondern denkt mit
Bei Fragen und Antworten stehe ich selbstverständlich gerne hier im Thread zur Verfügung.
MfG Jimini
Zuletzt bearbeitet: