Dynamische Firewall mit iptables

On 10. 07 2010, in Netzwerk, by Raptor 2101

Einer der Gründe warum ich meinen Netgear-Router zum Switch/AP degradiert habe war, dass ich mehr Kontrolle über meine Datenströme haben will. Meine grundlegende Anforderungen sind:

  • Aufschlüsselung der Bandbreite nach Clients
  • unterwerfen von unbekannten Clients unter eine dynamische Bandbreiten Beschränkung
  • gute Wartbarkeit
  • gute Monitoring-Möglichkeit

Die ursprüngliche Anregung habe ich diesem Artikel entnommen. Man muss das Konzept nur noch um die Dynamik ergänzen, damit auch Clients verwaltet werden können die man vorher nicht kennt.

Unter Ubuntu hat man die Wahl zwischen der “uncomplicated Firewall” (UFW) und dem direkten Zugriff mittels iptables. Ich hab mich für iptables entschieden. Zum einen bin ich unter UFW zu schnell in Bereich gestoßen, bei den ich quasi iptables-Befehle geschrieben habe (nur ohne iptables vorangestellt). Zum anderen lieferte mir UFW zu viele “default”-Regeln aus, die mit “nicht löschen” markiert sind ohne zu Begründen warum. Hat man sich einmal in iptables eingearbeitet, so hat man die volle Freiheit die man braucht.

WICHTIGER HINWEIS:Beim Ausführen der folgenden Befehle sollte man in Reichweite des Rechners sitzen oder einen alternativen Zugang zum Rechner haben, da man sich u.U aussperrt.

Es empfiehlt sich für das einstellen der Firewall-Regeln ein eigenes Set an Scripts zu erstellen, z.B. unter /etc/firewall. So kann man mit einfacher die Firewall zu und abschalten.

Als erstes sollte man die default-Policy der Haupt-Regel-Ketten auf DROP setzen. Das ist zwar ein wenig Paranoid hilft aber ungemein, da man jedes Loch bewusst aufmachen muss.

Diese Kommandos verhindern das jegliches einloggen via Remote-Access-Tools. Es wird jeder Traffic gedropt.
iptables -L INPUT -p DROP
iptables -L FORWARD -p DROP
iptables -L OUTPUT -p DROP

Bei aller Regelwut sollte man eines bedenken, das Durchlaufen der Filterregeln kostet zeit. Je nachdem auf welchem Layer man die Entscheidung zum DROP/ACCEPT trifft, müssen die Pakete aufwändig entpackt werden. Einige Module beherrschen dabei die sogenannte DeepPackageInspection (DPI). Diese Filterregeln sollten jedoch nur sparsam zum Einsatz kommen da sie sonst den kompletten Netzwerktraffic drücken.

Als erstes sollte man eine Regel einrichten die jede Verbindung annimmt die schon mal geprüft wurde. Zu diesem Zweck nutzt man das “state”-Module bzw Connection-Tracking.

iptables -L INPUT -m state --state ESTABLISHED,RELEATED -j ACCEPT
iptables -L OUTPUT -m state --state ESTABLISHED,RELEATED -j ACCEPT

Nun sollte man die Input-Chain um statische Ausnahmen für die Fernwartung und eventuell benötigte Dienste erweitern. Vorzugsweise mit angaben aus welchem Netz diese Zugriffe erfolgen dürfen. Hier bietet es sich an eigene “Chains” anzulegen und so die Wartbarkeit zu erhöhen.

Beispiel: Es ist sinnvoll den “eingehenden” Traffic nach “Herkunft” zu unterscheiden. Traffic aus dem eigenen Netz unterliegt einer anderen Vertrauenswürdigkeit als externer Traffic.

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT #vom lokalen netz zum server alles zulassen
iptables -A INPUT -i ppp0 -j server_incoming_traffic
iptables -A INPUT -j LOG --log-level 4 --log-prefix "Input dropped by firewall: "

Die ersten beiden regeln erlauben jeglichen Traffic des “localhost” und “eth1″ Interfaces. Nur Traffic des ppp0 Interfaces wird einer Filter-Chain unterworfen. Führt in dieser “server_incoming_traffic”-Chain keine Regel zu einem DROP oder ACCEPT wird diese einfach verlassen und das LOG – Kommando wird ausgeführt, zum logging aber später mehr.

Die Filter-Chain kann dann so aussehen:

iptables -N server_incoming_traffic
iptables -A server_incoming_traffic -p tcp --dport 22 -j ACCEPT
iptables -A server_incoming_traffic -p tcp --dport 443 -j ACCEPT
iptables -A server_incoming_traffic -p tcp --dport 6880:6999 -j ACCEPT
iptables -A server_incoming_traffic -p udp --dport 6880:6999 -j ACCEPT

so kann man eine Reihe von Port-Ranges freigeben. Man kann auf Wunsch die Regeln auch noch ins unendliche erweitern. Aber immer dran denken, dass frisst Performance.

Beim ausgehenden Traffic kann man es ähnlich händeln, mit einer Ausnahme. Bei einigen Programmen weiß man im vornherein nicht ob und welche Ports genutzt werden. Hier führen DROP-Policys normalerweise dazu, dass die Programme nicht oder nur eingeschränkt funktionieren. Entweder reißt man für solche Programme große Lücken in seine Firewall oder nutzt das “owner”-Modul. Bei ausgehenden Traffic ist es möglich zu ermitteln unter welcher UID oder GID der Socket aufgemacht wurde. Auch darauf kann man filtern. Wenn man sich an den Standard hält jedem Dienst seinen eigenen User zu verpassen, kann man so schön auf Dienstebene freigeben, wer was darf.

Folgendes Beispiel gibt für rTorrent allen ausgehenden Traffic frei.

iptables -A server_outgoing_traffic -p tcp -m owner --uid-owner rtorrent -j ACCEPT
iptables -A server_outgoing_traffic -p udp -m owner --uid-owner rtorrent -j ACCEPT

Kommen wir nun zum Forward-Traffic. Hier wird es ein wenig kniffeliger. Zum ein landet hier alles was geroutet wird, zum anderen muss man hier mit dem “in” und “out” aufpassen. Am einfachsten fällt die Unterscheidung nach Zielnetzen.

iptables -A FORWARD -o ppp0 -s 192.168.99.0/24 -j outgoing_traffic
iptables -A FORWARD -o eth1 -d 192.168.99.0/24 -j incoming_traffic
iptables -A FORWARD -j LOG --log-level 4 --log-prefix "Forward dropped by firewall: "

Die regeln sind schnell erklärrt: alles was an ppp0 gerouted wird und vom Netz 192.168.99.0/24 kommt wird der Chain ” outgoing_traffic” unterworfen. Gleichlaufend wird alles was an eth1 geroutet wird und an das gleiche Netz gesendet wird der Chain “incoming_traffic” unterworfen. Alles andere wird geloggt und gedropt.

In diesen beiden Listen passiert nun das “magic”. Clients die ins “Internet” wollen müssen durch diese Regeln durch. Hier muss also am ende jeder Client aufgeführt sein der Accepted werden soll. Deshalb sollte man erstmal jeden Port droppen den man nicht geroutet wissen will. Das dient weniger dazu, dass der User die entsprechenden Programme nicht nutzt (ein umbiegen von Ports, beherrscht wohl jeder …) sondern soll eher verhindern, dass gewisse Windows-Clients unwissend ihre Existenz in Netz hinaus posaunen…

Danach muss man nun die Clients dynamisch in der Firewall freigeben. Das geht am besten über den DHCP-Deamon. Jeder Client muss sich eine IP holen, tut er es auf korrektem weg, wird er in der Firewall freigeschaltet, ansonsten bekommt er nicht gerouted. Das einzige Einfallstor sind dann noch IP/Mac spoofing. Das kann man aber bei kommen. Der dhcpd3-Daemon bietet für diese Zwecke die Möglichkeit ein Script auszuführen. Mittels folgendem Eintrag in der dhcpd.conf kann man Scripte anstoßen wenn ein Client ein Lease bekommt oder freigibt.

on commit {
  set ClientIP = binary-to-ascii(10, 8, ".", leased-address);
  set ClientMac = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));
 
  log(concat("Commit: IP: ", ClientIP, " Mac: ", ClientMac));
 
  execute("/etc/firewall/add-client", ClientIP);
}
 
on release {
  set ClientIP = binary-to-ascii(10, 8, ".", leased-address);
  set ClientMac = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));
 
  log(concat("release: IP: ", ClientIP, " Mac: ", ClientMac));
 
  execute("/etc/firewall/del-client", ClientIP);
}
 
on expiry {
  set ClientIP = binary-to-ascii(10, 8, ".", leased-address);
  set ClientMac = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));
 
  log(concat("expire: IP: ", ClientIP, " Mac: ", ClientMac));
 
  execute("/etc/firewall/del-client", ClientIP);
}

Sobald man diesen Code in die /etc/dhcp3/dhcpd.conf einfügt, werden zwei Scripte ausgeführt. in diesem Fall del-client und add-client. Wichtig dabei ist, dass man in apparmor die Ausführung dieser Scripte von dhcpd zulässt. Entweder über das unsichere “ohne eigene Regeln ausführen” oder man legt schnell eine eigene Regel an.

In den Scripts wird einfach nur folgendes gemacht:

#!/bin/bash
RULEOCCURE=`iptables -L -n|grep -c $1`
if [ $RULEOCCURE -eq 0 ]; then
        /usr/bin/sudo /sbin/iptables -A outgoing_traffic -s $1 -j ACCEPT
        /usr/bin/sudo /sbin/iptables -A incoming_traffic -d $1 -j ACCEPT
fi
iptables -D outgoing_traffic -s $1 -j ACCEPT
iptables -D incoming_traffic -s $1 -j ACCEPT

Das $1 wird zur Laufzeit durch die gewünschte IP ersetzt.

Kommen wir nun zum Logging, Eine Firewall die nicht überwacht wird bringt recht wenig. Deswegen sollte man mitloggen was passiert. Rudimentär kann man mittels des iptables-Befehl selber auswerten.

iptables -L -v -n

Durch diesen Befehl wird für jede FilterChain aufgelistet wie oft sie angewendet wurde. (Counter und Bytes) So kann man auch raus finden welcher Client wie viel Traffic erzeugt. Geht der Counter für die Drops jedoch extrem hoch sollte man mal schauen was da eigentlich passiert. Für dieses anliegen braucht man die LOG – Rule.

iptables -A FORWARD -j LOG --log-level 4 --log-prefix "Forward dropped by firewall: "

Man braucht kein Präfix, es empfiehlt sich aber. So kann man mittels rsyslog dafür sorgen, dass alle Meldungen der Firewall in eine Datei geloggt werden. Dazu bedarf eines eines Eintrag in der rsyslog-config.

#
# FIREWALL logging
#
:msg, contains, "firewall"      /var/log/firewall
:msg, contains, "firewall"      ~

Mittels eines Scriptes kann man nun alle fünf Minuten diese Statistik und die Logs auswerten und ggf Gegenmaßnahmen einleiten. Zb “vollautomatisch” eine DROP-Regel für eine IP anlegen die eine flood-Attacke durchführt und gleichzeitig eine Warn-Mail absetzen.

Tagged with:
 

Ubuntu als Router

On 10. 07 2010, in Netzwerk, by Raptor 2101

Handelsübliche “DSL-Router”, oder die sogenannten eierlegenden Wollmilch-Säue, nehmen einem im Alltag schon sehr viel Arbeit ab. Leider legen die Hersteller wenig Wert auf  Transparenz oder Wartbarkeit.  Spätestens wenn man etwas mehr Flexibilität will, darf man gleich richtig Tief in die Tasche greifen oder sich selber was basteln bzw eine WRT-Firmware einsetzten.

Linux-Distributionen kommen schon seit Jahren mit einer Grundkonfigurationen die sie mit wenigen Handgriffen in einen vollwertigen Router verwandelt.

Einen DSL-Modem kann man mittels pppoeconf ansprechen.

sudo pppoeconf

Der Installationsmechanismus ist ein wenig krüppelig aber anschließend hat man eine Verbindung ins Internet. Standardmäßig ist sie im “persistenten” Modus, soll heißen, nach einem 24 Stunden disconnect verbindet sich das System automatisch neu. Zusätzlich wird noch die Möglichkeit geboten scriptes aufzurufen wenn die Verbindung auf oder abgebaut wurde. Das kann man dazu nutzen einen dyndns-Dienst
zu aktualisieren. Installiert man den ddclient, klinkt er sich dort eigenständig ein.

sudo aptitude install ddclient

zusätzlich zu dieser Konfiguration bedarf es noch der Verschaltung der Netzwerke. Wenn man nicht gerade ein öffentliches Netz im betrieb hat wird man NAT nutzen müssen. Dazu muss man einfach mittels iptables folgende regeln konfigurieren. Am besten sollte man das gleich in /etc/rc.local ablegen, damit das setup bei jedem reboot gesetzt wird.

sudo -s
echo "1" > /proc/sys/net/ipv4/ip_forward #alternative /etc/sysctl bearbeiten
 
iptables -A FORWARD -o <internes interface> -m state --state ESTABLISHED,RELATED -J ACCEPT #alles akzeptieren was vom Internet kommt und von lokalen Lan initialisiert wurde.
iptables -A FORWARD -o <externes interface> -J ACCEPT #alles was von Intern nach Extern will akzeptieren.
 
iptables -t nat -A POSTROUTING -o <externes interface> -j MASQUERADE #NAT aktivieren

Nach diesem Setup hat man erst mal wieder Internet von allen Clients, wenn man den default-dns-server und standart-gateway korrekt eingestellt hat.

Wenn man über längere zeit “ernsthaft” einen Rechner direkt am I-Net hängen lässt, sollte man sich jedoch über iptables genauer Informieren. Das genannte Setup ist nur ein Grundsetup und lässt den Router-Rechner ziemlich “exposed” im Netz.

Tagged with: