7. Januar 2017 , 09:30 Uhr
von Marc Eggert

Linux Firewall / iptables

In diesem Beitrag erkläre ich anhand einiger Beispiele, wie eine mögliche Absicherung eines Linux-Servers (im beschriebenen Fall Debian-/Ubuntu-Server) grundsätzlich aussehen könnte. Dabei sollte „iptables“ an sich schon ein Begriff sein und man sollte sich seine eigenen Filter-Regeln bereits via iptables angelegt haben. Im Normal-Fall richtet man sich seine Firewall grundsätzlich so ein, dass sämtlicher eingehender Datenverkehr blockiert wird, außer es trifft eine Filter-Regel zu. Aber auch diese durchgelassenen Pakete können weiter gefiltert werden oder IP-Adressen bereits im Vorfeld aussortiert werden.

Ich habe es mir angewöhnt, meine Firewall- und Sicherheits-Scripts in einem eigenen Verzeichnis zu pflegen – beispielsweise unter /opt/myfirewall.

iptables-save

Für meine Zwecke und nach dem Anlegen der für mich sinnvollen Filter-Regeln, nutze ich einmalig den Befehl iptables-save, um die bestehenden Einstellungen zu sichern, sobald die iptables-Regeln einmal sauber konfiguriert sind (noch VOR der Einrichtung von fail2ban und ipset! <- diese Regeln sollten jeweils dynamisch von den Programmen gesetzt werden!). Die aktuellen iptables-Regeln können mit „iptables -L“ ausgegeben werden. Über den folgenden Befehl kann also zunächst das eigene iptables-Set abgespeichert werden:

Hierbei wird eine Text-Datei angelegt, welche auch weiter modifiziert werden kann – beispielsweise, um weitere Ports freizugeben. iptables an sich dient zunächst auch nur dazu, bestimmte Ports freizugeben. Ein Dienst wird also nicht sicherer, nur weil er durch eine bestimmte Firewall-Regel freigegeben wird – logisch. 😉

fail2ban

In den meisten Distributionen findet man fail2ban bereits in den Repositories. Dieses Programm funktioniert so, dass Log-Dateien auf das Vorkommen bestimmter Einträge geprüft werden und daraus dynamisch Firewall(iptables-)-Regeln erstellt werden. Unter Ubuntu/Debian werden die aktivierten fail2ban-Regeln in der Datei „/etc/fail2ban/jail.local“ eingestellt und definiert. Sollte diese Datei noch nicht vorhanden sein, kopiert man den Inhalt von /etc/fail2ban/jail.conf nach /etc/fail2ban/jail.local – diese eigene Datei bleibt dann auch bei Software-Updates erhalten und wird vom System als Standard genutzt.

Beispiel sshd

fail2ban kommt bereits mit einer Reihe von Regeln und Filtern, die nur noch aktiviert werden müssen. Sucht man in der Einstellungsdatei nach „[sshd]“, so findet man folgende Zeilen hierzu (die Kommentare sind von mir und nicht in der Datei zu finden):

Aktiviert man also diesen Regelsatz durch setzen des „enabled“-Wertes auf „true“, wird die auth.log-Datei nach Vorkommen von regulären Ausdrücken aus der Filter-Datei untersucht. Standardmässig erfolgt eine Sperre der entsprechenden IP-Adresse nach dreimaligem Zutreffen der Filter-Regel für fünf Minuten. Auch diese Parameter können in der Datei jail.local angepasst werden – entweder generell oder für das entsprechende Jail individuell. Sieht man sich die Filter-Regeln für den SSH-Dienst an, so stellt man fest, dass auf entsprechende Login-Versuche auf den SSH-Dienst reagiert werden soll.

Über fail2ban lassen sich sämtliche Dienste überwachen (Web-Server/logins, PHPMyAdmin, Mailserver, etc.) – Voraussetzung hierfür ist lediglich, dass unerlaubte oder fehlgeschlagene Zugriffe protokolliert werden und das Protokoll von fail2ban überwacht wird. Standardmässig sind schon eine Reihe von Filtern in der Grund-Installation vorhanden, welche nur noch aktiviert werden müssen.

Der Dienst fail2ban wird unter Debian/Ubuntu via

verwaltet.

Beispiel WordPress

Als weiteres Beispiel sei das Plugin „WP fail2ban“ genannt – einmal in WordPress installiert, werden sämtliche fehlgeschlagenen Logins oder Zugriffe auf das XML-RPC-Modul inkl. IP-Adresse in die syslog, bzw. auth.log-Datei geschrieben. Eine entsprechende Filter-Regel wird mitgeliefert. In der jail.local-Datei sieht die Konfiguration so aus:

Die Filter-Regeln dazu sehen so aus:

Einträge in der auth.log sehen dann beispielsweise so aus:

ipset

Es gibt eine ordentliche Anzahl von IP-Adressen, die als „bad“ bekannt sind, bzw. von welchen sehr oft Angriffs-Versuche ausgehen. Teilweise werden hier auch Methoden benutzt, die eben gerade solche Erkennungen von fail2ban umgehen wollen. Login-Versuche werden dann nicht direkt hintereinander, sondern in Abständen von ca. 7 Minuten gestartet. So wird eine fail2ban-Filter-Regel wohl nie zum Einsatz kommen. Solche IP-Adressen (natürlich nicht alle), lassen sich gezielt bannen. Hierzu kommt das Programm „ipset“ zum Einsatz.

Über ipset lassen sich ganze Sammlungen von IP-Adressen über eine einzige iptables-Regel verwalten. Auf Github findet sich das Projekt „ipset-blacklist„, über welches sich eine Sammlung solcher IP-Adressen in die eigene Firewall integrieren lässt. In der Konfigurations-Datei lässt sich einstellen, welche Blocklisten von welchen Anbietern benutzt werden sollen (openbl.org, etc.). Das Vorgehen ist im Grunde folgendes:

  1. ipset mit der IP-Adressen-Liste erstellen
  2. Filter-Regel für dieses ipset zur iptables-Konfiguration hinzufügen

Sollte im weiteren Verlauf festzustellen sein, dass eine weitere IP-Adresse in den Logs mit Login-Versuchen nervt, so kann auch diese einzelne IP-Adresse zum bestehenden ipset hinzugefügt und blockiert werden:

Über ipset-blacklist können auch ganze Länder blockiert werden, sofern dies gewünscht ist. Entsprechende Anbieter liefern hierzu tagesaktuelle IP-Listen nach Ländern sortiert, welche so eingebunden werden können.

Zusammenfassung & Start-Script

Mit den vorgestellten Programmen kann man schonmal einen Großteil der üblichen Script-Angriffe abwehren. Es ist natürlich auch weiterhin erforderlich, die eigenen Systemlogs aufmerksam zu beobachten und Auffälligkeiten zu erkennen. Programme wie „logwatch“ helfen dabei, eine grobe Übersicht über die Logs zu erhalten. Das Durchsehen von syslogs und auth.logs bleibt aber weiterhin im Auge zu behalten!

Für meine Zwecke habe ich eine kleine Start-Datei der obigen Konfigurationen angelegt, die wie folgt aussieht:

Das Clean-Set sieht so aus:

Eine Einsicht, wieviele Pakete über die bestehenden iptables-Regeln „gedroppt“ wurden, erhält man so:

 

    Zu diesem Beitrag gibt es noch keine Kommentare...

Kommentar verfassen