Schlagwort-Archive: iptables

Tunnelbau

Die OMD steht in der Schule hinter der Dom0, die für diesen Rechner gleichzeitig das Gateway ins Netz ist:

cat /proc/sys/net/ipv4/conf/eth0/forwarding 
cat /proc/sys/net/ipv4/conf/eth0/forwarding

Die Ausgabe muss jeweils 1 lauten.

Zwei iptables Regeln sorgen dafür, dass die Ports und der Traffic zur OMD durchgereicht werden:

iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 9393 -j DNAT --to-destination 192.168.0.2:443
iptables -A FORWARD -p tcp -d 192.168.0.2 --dport 9393 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Ein Aufruf von https://domnullundgateway.tld:9393/checkmk/ sorgt so dafür, dass Anfragen an die OMD, die intern unter https://192.168.0.2 zu erreichen ist, weiter geleitet werden.

Damit man diese Regeln nicht immer wieder neu setzen muss, stehen sie in /etc/network/interfaces am Ende der Konfiguration der Netzwerkkarte eth0 jeweils nach einem up.

Routerbau

netzwerk

Als nächsten Schritt für das iptables Projekt mit meiner AG dachte ich an einen kleinen dreckigen Router, der den „Charme“ hat, dass er die zentrale IP Adressvergabe der Schule für Fremdrechner umgeht. So etwas motiviert Schüler immer 🙂

Wir nutzen dazu am einfachsten ein paar Rechner in der Bibliothek und aktivieren deren zweite Netzwerkkarte, die bisher auf Grund ihrer PXE-Unfähigkeit brach lag. Die schon vorhandene Hardware „kennt“ das Schulnetz – das wird dann eth0.

Ein

echo 1 > /proc/sys/net/ipv4/ip_forward

schaltet auf dem Rechner zwischen Schulnetz und Clients die Routerfunktionalität ein. Dabei zeigt dessen eth0 wie gesagt zur Schule und würde vom schulischen DHCP Server mit einer Adresse versorgt. Da ich das für router-unpassend halte, wird die per DHCP zugewiesene IP Adresse ermittelt und dann mit ipconfig statisch auf eth0 gesetzt. Die eth1 (und damit die bisher brach liegende Karte) des Routers zeigt zu einem kleinen Switch, an dem die Clients hängen. Hier wird per ipfonfig eine 192er Adresse gesetzt und die Clients erhalten ebenfalls statische Adressen. Die Bearbeitung von

/etc/udev/rules.d/70-persistent-net.rules

kann die Zuordnung der MAC-Adressen zu Interface-Namen auf dem Router erzwingen. Mehr muss für dieses Experiment nicht sein.

Ein

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

stellt den Router auf NAT um.

Damit Clients hinter diesem Router weiterhin über SSH zu erreichen sind, wird Port 22 ge-forward-ed

iptables -t nat -A PREROUTING -p tcp -i eth0 –dport 22 -j DNAT –to-destination ip.adresse.des.clients

Das sollte es dann gewesen sein: Der Router selbst ist von Außen nicht mehr über SSH auf Port 22 zu erreichen, da er diesen ja nach Innen zum Client weiter reicht. Weitere Ports können für einen Webserver auf einem weiteren Client auch noch dazu kommen … mal sehen, wie viel Zeit überhaupt noch bleibt. Ein kurzer Exkurs für den Schluss wäre: Wir schreiben die ganzen Befehle in ein Skript und tragen dieses in /etc/rc.local ein, damit sie einen Reboot überleben.

REJECT und DROP

Für meine Linux AG habe ich nach einer einfachen Möglichkeit gesucht, wie man den Unterschied zwischen REJECT und DROP bei der Nutzung von iptables zeigen könnte. Ich denke, mit ICMP Paketen zeigt sich das deutlich genug:

iptables DROP

Ich nutze hierzu eine VM unter Debian, die über eine Schnittstelle (eth1 – in VBOX dann bridge) direkt mit dem Schulnetz verbunden ist – mit der anderen (eth0 – in VBOX dann nat oder intern) hängt sie am Wirtsrechner selbst. Ein

iptables -t filter -A INPUT -j DROP -i eth1 -s ip.des.anfragenden.rechners

schaltet die Anworten auf ping ip.der.vbox.unter.debian sichtbar komplett ab: ping erhält überhaupt keine Antworten mehr.

iptables REJECT

Nach einem iptables -F zum Putzen der Chains kann man dann weiter spielen und ein REJECT ausprobieren:

iptables -t filter -A INPUT -j REJECT -i eth1 -s ip.des.anfragenden.rechners

Es wird sichtbar, dass nun ping mit „Destination Port Unreachable“ reagiert.

Welches der beiden Verfahren nun sicherer ist, wenn man iptables basierte Firewalls aufbaut, können wir im Anschluss ja endlos diskutieren.

Manchmal hat man schon einen Knoten im Kopf: Zuerst setzte ich auf einen Apache in der VM, den man mit Hilfe von

iptables -t filter -A INPUT -j DROP -i eth1 -s ip.des.anfragenden.rechners -p tcp –dport 80

gegenüber Anfragen von Außen an Port 80 absichern kann.

Aber das ist für den Einstieg a) zu komplex und b) zu langweilig, weil am anfragenden Firefox nicht zu sehen ist, ob nun DROP oder REJECT in der Chain steht: Er meckert halt rum, dass die Verbindung nicht zustande kommt.

Lieber also den brutalen, weil auf alle Ports und alle Protokolle wirkenden Befehl oben zuerst verwenden und dann mit

iptables -t filter -A INPUT -j DROP -i eth1 -s ip.des.anfragende.rechners -p icmp

einschränken, dabei zeigen, dass man dann noch per ssh auf die VM kommt, und dann weiter machen. Außerdem ist der allgemein gegen eine einzelne IP gerichtete Eintrag in iptables sicherlich der Befehl, den man im Alltag häufiger benötigt: Wenn eine IP schon geblockt werden muss, dann ja meist komplett.