© Yanik Chauvin, Fotolia

Fühlt sich ein Intrusion-Prevention-System attackiert, dann erteilt es dem Störer striktes Lokalverbot und lässt ihn an keinen Dienst mehr ran. Alle anderen Benutzer bleiben von der Blockade verschont. Mit dem Recent-Modul von Netfilter ist dieses Verhalten bestens steuerbar.

Firewalls sind weit mehr als reine Filterlisten-Verwalter. Stateful Inspection gehört längst zur Pflicht. In der Kür passen sie dynamisch ihre Regelsätze an, um enttarnte Angreifer von allen Zugängen fernzuhalten. Das gelingt zum Beispiel mit einer Kombination aus dem Intrusion-Detection-System Snort [3] und dem Recent-Modul [1] für Netfilter [2]. Snort bemerkt Angriffe und Recent verwaltet dynamisch eine Liste mit deren IP-Adressen. Der Clou: Die Liste darf in Firewallregeln vorkommen.

Oft ist Snort gar nicht nötig. Wenn bereits eine Firewallregel Angriffe detektiert, kann sie auch selber Einträge in der Recent-Liste ergänzen. Die Option »–set« des Recent-Moduls trägt die Source-Adresse des aktuell untersuchten Pakets in die Liste ein. Mit »–rcheck« prüft Netfilter, ob die Absenderadresse des untersuchten Pakets bereits in der Liste steht. Zusätzlich kann der Admin mit »–seconds« angeben, wie lange zurück der letzte Eintrag in der Liste liegen darf. Eine Prüfung mit der Option »–update« funktioniert so wie »–rcheck«, setzt aber den Zeitstempel neu.

Das Beispiel in Listing 1 zeigt das Recent-Modul im Einsatz. Zeile 1 sorgt dafür, dass Pakete einer bestehenden Verbindung weiterhin durchkommen (Stateful Inspection). Zeile 2 prüft, ob das Recent-Modul den Absender schon kennt, und blockiert ihn in diesem Fall. Danach folgen in einem vollständigen Skript alle Regeln für die erlaubte Kommunikation.

01 iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
02 iptables -A FORWARD -m recent --update -j DROP
03 [andere Regeln]
04 iptables -A FORWARD -i Extern-Interface -p tcp --dport 135 -m recent --set -j DROP
05 iptables -A FORWARD -j DROP

Blockadehaltung

Das Kommando in Zeile 4 füllt die Recent-Liste mit den IP-Adressen aller Angreifer, die sich von außen (externes Interface) an Port 135/TCP versuchen. Den Port verwenden Würmer, um dank einer DCOM-RPC-Schwachstelle in Windows-Systeme einzudringen. Die letzte Zeile bestimmt als Default-Policy »DROP«.

Sollte sich derselbe Rechner innerhalb des Standard-Timeout von 60 Sekunden noch einmal melden, blockt ihn die Firewall, egal auf welchen Port und Zielrechner er diesmal zugreift (Zeile 2). Zugleich setzt das Recent-Modul den Zeitstempel neu (wegen der Option »–update«) und die 60 Sekunden beginnen von vorn. Das Ablaufdiagramm in Abbildung 1 zeigt die Schritte der Pakete durch das Firewallskript.

Abbildung 1: Bei neuen Paketen prüft das Recent-Modul, ob es den Absender kennt. Wenn ja, verwirft es das Paket sofort. Wenn nein, folgen die restlichen Regeln. Erkennt das Skript am Ende eine verbotene Kommunikation, sperrt es künftig den Täter.

Tiefer im Modul

Das Modul kann auch mehrere dynamische Listen verwalten, zum Beispiel eine für den Mailserver und eine für die restlichen Systeme. Den Namen der jeweiligen Liste gibt das Firewallskript über die Option »–name Bezeichnung« an. Ohne diesen Parameter verwendet das Modul die Liste »DEFAULT«.

Userspace-Tools erreichen IP-Listen über das Proc-Verzeichnis »/proc/net/ipt_recent/Liste«. Das Recent-Modul hinterlegt hier die Adresse und die Zeitstempel der erkannten Pakete. Neue Einträge darf auch ein Userspace-Skript besorgen:

echo Adresse > /proc/net/ipt_recent/DEFAULT

Das ist nützlich, um die Kommunikationen mit einer bestimmten IP-Adresse schnell zu unterbinden. Ebenso gelingt es, Nummern aus der Liste zu löschen:

echo -Adresse > /proc/net/ipt_recent/DEFAULT

Üblicherweise verwaltet Recent nur 100 Einträge pro Liste. Kommen neue hinzu, verdrängen sie ältere Felder, auch wenn die Zeitspanne noch gar nicht abgelaufen ist. Das gerät bei schnellen Internetanbindungen zum Problem, lässt sich aber leicht umgehen: »modprobe ipt_recent ip_list_tot=1000« erhöht beim Initialisieren des Moduls sein Fassungsvermögen auf 1000 Adressen.

Portscan-Gegenwehr

Zu den praktischen Anwendungen des Moduls gehört es, die Suche nach offenen Ports und Anwendungen (Portscan) aus dem Internet wesentlich zu erschweren. Wer einen ganzen Adressenbereich besitzt, reserviert dazu die erste und letzte IP des Adressenblocks, statt sie einem Rechner im LAN zuzuweisen. Es gibt keine legitime Kommunikationen mit diesen IPs. Alles, was mit diesen Zieladressen an der Firewall aufschlägt, darf sie guten Gewissens als potenziellen Angriff werten und den Absender in die schwarze Liste aufnehmen.

Falls der Angreifer jetzt weiterscannt, erhält er nie eine Antwort, auch wenn er einen Rechnerport in der Mitte des Adressenbereichs prüft, der normalerweise erlaubt ist. Gegenüber anderen Portscan-Blockaden hat diese den Vorteil, dass sie schon beim ersten Paket einsetzt und nicht erst nach einer gewissen Zeit und Paketanzahl, wenn eine Firewall gewöhnlich Portscans von legitimer Kommunikation unterscheidet.

Weil es keine legitime Kommunikation mit den Adressenfallen gibt, ist die Methode recht sicher. Gegen IP-Spoofing ist sie allerdings nicht gefeit (siehe Kasten “DoS-Attacken”) und sie erkennt auch keine Portscans, die in der Mitte des Adressenblocks beginnen.

Erfahrungswerte

Ein Beispiel aus der Praxis: Für Fernwartung nutzt der Autor gerne SSH. Da er vorab nicht wissen kann, von welcher Adresse aus er auf die Firewall zugreift (Urlaub in Griechenland), erlaubt er alle Adressen. Die Auswertung der Logfile zeigt: Auf den SSH-Port hat die Firewall im Laufe eines Monats 207 unerlaubte Zugriffe verzeichnet (etwa Portscans oder Rumpelstilzchen-Attacken). 187 Mal schlug das Recent-Modul zu und ließ die Verbindung gar nicht erst zu. Nur zehnmal kamen Verbindungen zustande, die an der SSH-Authentifizierung scheiterten. Weitere zehnmal schlug das Limit-Modul von IPtables zu, das die Rate der Verbindungen auf ein vernünftiges Maß begrenzt. Somit fand der Angreifer in 95 Prozent aller Fälle den eigentlich offen Port nicht.

Der Autor des Recent-Moduls schlägt sogar vor, die Default-Policy der Firewall durch ein »-m recent –set« zu ergänzen. Jedes nicht näher erkannte Paket führt damit zu einem Blacklist-Eintrag. Solch drastische Maßnahmen sind in den meisten Fällen aber eher schädlich. Es empfiehlt sich viel mehr, vorsichtig zu sein und nur garantiert böswillige Kommunikation zu unterbinden. Siehe dazu auch den Kasten “DoS-Attacken”.

Bequemer mit FW-Builder

Zu den besten grafischen Oberflächen für Linux-Firewalls gehört mit Sicherheit der FW-Builder ([4], [5]). Mit ihm ist es möglich, intuitiv Regeln für eine Firewall zusammenzustellen, sie zu einem Firewallskript zu kompilieren und anschließend zu installieren. Mit ein paar Tricks gelingt es auch, Regeln für das Recent-Modul einzubauen. Als erster Schritt sind neue Services erforderlich – im GUI zu erreichen über »User | Services | Custom« (siehe Abbildung 2). Auf dem gleichen Weg ist ein eigener »recent_update«-Service zu definieren, der »-m recent –update« entspricht. Vorsichtige Naturen ergänzen noch »-i Externes-Interface« in der Definition.

Abbildung 2: Ein eigens definierter Service in FW-Builder erlaubt es, das Recent-Modul von Netfilter via GUI zu nutzen. Hier erhält die IPtables-Option »-m recent –set« ihr GUI-Äquivalent unter dem Namen »recent_set«.

Dummy-Falle

Für die beiden Fallen am Anfang und Ende des Adressenblocks eignet sich ein flugs eingerichteter Dummy-Rechner mit interner Adresse. Zwei NAT-Regeln leiten die erste und die letzte Adresse aus dem externen Bereich auf diesen Rechner. Wie in dieser Situation die Firewallregeln aussehen, zeigt Abbildung 3.

Abbildung 3: Der FW-Builder-Regelsatz erkennt Angriffe auf einen nicht real vorhandenen Dummy-Rechner (Zeile 3) und nutzt den eigens definierten Dienst (Custom Service) »recent_set«, um Quelladressen auf die Blacklist zu setzen. In Zeile 0 sperrt »recent_update« alle bekannten Bösewichte aus.

Ein paar Fallstricke hat FW-Builder jedoch eingebaut. Bei komplexen Regeln mit mehreren Quellen und Zielen generiert das Programm eine Reihe von Regeln mit eigenen Chains, die nacheinander die Objekte abfragen. Hier kann es passieren, dass ein Aufruf des Recent-Moduls ganz am Anfang die Adresse in die Liste einträgt, sich aber später herausstellt, dass die Regel doch nicht passt. Die weitere Kommunikation ist zu diesem Zeitpunkt bereits unterbrochen. Hier hilft nur, den von FW-Builder erzeugten Regelsatz manuell zu prüfen.

Externe Applikationen

Dank der beschriebenen Möglichkeit, die Sperrliste manuell zu beeinflussen, halten auch externe Applikationen unerwünschte Gäste ab. Das ist insbesondere interessant, da viele Applikation besser als jede Firewall wissen, was erlaubte und was verbotene Kommunikation ist. Das gilt allen voran für IDS-Programme wie Snort [3].

Die Snort-Konfiguration in Listing 2a sorgt dafür, dass das IDS alle Ereignisse über einen Syslog-Alert meldet und ihnen die Facility »log_auth« mitgibt sowie die Priorität »log_alert«. Syslog-NG ([6], [7]) filtert alle Ereignisse aus, die die Strings »snort« sowie »Priority: 1« enthalten (Zeile 2, Listing 2b), und sendet diese an ein Perl-Skript (Zeile 5).

01 output alert_syslog: LOG_AUTH LOG_ALERT

01 filter f_snort  {
02   facility(auth) and match("snort") and match("Priority: 1");
03 };
04 destination snort {
05   program("/usr/local/sbin/blocker.pl");
06 };
07 log {
08   source(src);
09   filter(f_snort);
10   destination(snort);
11 };

Dieses Blocker-Skript ist in Listing 2c zu sehen. Falls es die Signatur 1810 mit der Priorität 1 in den übermittelten Log-Einträgen findet (erfolgreicher Einbruch über SSH, Zeile 4), schreibt es die IP-Adresse des Angreifers in die »BLOCK«-Liste des Recent-Moduls (Zeile 5). Das Firewallskript muss in diesem Szenario die »BLOCK«-Liste vor den Zeilen mit »ESTABLISHED,RELATED« abarbeiten, da die Verbindung zum Blockadezeitpunkt bereits besteht.

01 #!/usr/bin/perl
02 # /usr/local/sbin/blocker.pl
03 while (<>) {
04   if ( /.*[1:1810:12].* -> ((d{1,3}.){3}d{1,3})/ )/ ) {
05     system "echo $1 > /proc/net/ipt_recent/BLOCK";
06   }
07 }

Fantasie ist gefragt

Die simplen Beispiele deuten die Flexibilität beim Firewalling an, die Administratoren mit der Kombination mehrerer Werkzeuge erreichen. Falls es zum Beispiel noch kein Patch zu einem bestimmten Angriff gibt (Zero-Day-Attacken) oder ein Patch nicht einwandfrei funktioniert, realisiert die Auswertung eines IDS oder des Logfile der Applikation selbst schnell ein praktisches Intrusion-Prevention-System. Das verschafft Zeit, um auf ein Patch zu warten oder es ausführlich zu testen. (fjl)