Firewall-Regeln namensbasiert moeglich?

[whiizy]

Hallo und guten Tag,

ich weiß nicht so recht, wo ich bei der Suche anfangen soll. Vielleicht kann mich jemand wenigstens in die richtige Richtung stupsen ...

Gibt es irgendeine Möglichkeit, Firewall-Regeln nicht nur auf IP-Adressen zu beziehen, sondern irgendwie auf den DNS-name einer IP? Also sowas, wie namensbasierte Firewall-Regeln?

Die Frage ist zunächst ganz allgemein, aber der Anlass ist schon etwas konkreter. Ich habe z.B. bei einem Kabel-Provider eingeschränkt die Möglichkeit, IPv6-Adressen zu nutzen, die sich aber leider in unvorhersehbaren Abständen (in der Regel Wochen) mal ändern können. Nun gibt es auch für IPv6 gewisse DynDNS-Dienste, die für sich ändernde IP-Adressen bestimmte statische DNS-Namen im Internet aufrechterhalten.

Nun würde ich gerne permanent auf diesen, meinen Hostname aus dem Internet zugreifen können, bspw. per HTTPS, und muss dazu eine Firewall-Regel in meiner Firewall (ip6tables) öffnen. Damit diese Regel auch permanent treffend wäre, müsste sie eigentlich auf den statischen DNS-Name dieses Servers ausgerichtet sein (und nicht auf dessen dynamisch-wechselnde IP-Adresse).

Gibt es da irgendwelche Möglichkeiten? Nach welchem Stichwort könnte ich da suchen?

Gruss

[MSfree]

Gibt es irgendeine Möglichkeit, Firewall-Regeln nicht nur auf IP-Adressen zu beziehen, sondern irgendwie auf den DNS-name einer IP? Also sowas, wie namensbasierte Firewall-Regeln?

Grundsätzlich läßt sich iptables auch mit Hostnamen aufrufen:

iptables -A INPUT -s host.name.tld -dport 22 -j ACCEPT

Ist im Prinzip ein gütliger Aufruf. Das funktioniert aber nur, wenn sich die IP-Adresse, die host.name.tld zugewiesen ist, nicht ändert. Für Hosts, die per dyndns den Hostnamen mit wechselnden IP-Adressen im DNS eintragen, funktioniert so eine Regel also nur bis zum nächsten Adresswechsel.

Das Problem hatte ich auch, ich habe mir im Internet einen Wolf gesucht, und es gibt dazu keine fertige Lösung. Meine persönliche Lösung ist ein selbstgeschriebenes Programm. Zugang kann man sich damit entweder per erlaubter Hostnamenliste oder per Pingknocking verschaffen. Ich bevorzuge inzwischen Pingknocking, weil der Quellhost dann keine dyndns-Eintrag benötigt, was die Sache unterwegs via Mobilfunk deutlich vereinfacht.

[whiizy]

Gibt es irgendeine Möglichkeit, Firewall-Regeln nicht nur auf IP-Adressen zu beziehen, sondern irgendwie auf den DNS-name einer IP? Also sowas, wie namensbasierte Firewall-Regeln?

Grundsätzlich läßt sich iptables auch mit Hostnamen aufrufen:

iptables -A INPUT -s host.name.tld -dport 22 -j ACCEPT

Ah, das ist doch schonmal ganz gut, danke MSfree! Dann könnte ich so zumindest meinen Dynamic DNS name verwenden.

Ist im Prinzip ein gütliger Aufruf. Das funktioniert aber nur, wenn sich die IP-Adresse, die host.name.tld zugewiesen ist, nicht ändert. Für Hosts, die per dyndns den Hostnamen mit wechselnden IP-Adressen im DNS eintragen, funktioniert so eine Regel also nur bis zum nächsten Adresswechsel.

.Ja, dann wird wohl ein cronjob alle 5 min oder so kontrollieren müssen, ob sich die Namensauflösung geändert hat. Falls ja, müsste der job dann nur die ip6tables neu laden. Sehr günstig wäre, wenn man diesen job gleich in inadyn-mt integrieren könnte. Das ist das Paket, welches sowieso schon periodisch prüft, ob sich auf dem client die IP geändert hat, und dann den DNS-Server im Internet entsprechend impft. Vielleicht kann man inadyn-mt noch dazu bringen, dann gleichzeitig auch die Firewall zu reloaden.

Mir fällt aber gerade noch ein, daß der inadyn-mt (dyn DNS client) auf dem Server (raspi) läuft und die ip6tables auf dem vorgelagerten, externen Router (openwrt). Demzufolge müsste mein Server dann bei der festgestellten IP-Änderung die firewall remote per ssh oder so auf dem OpenWrt restarten.

Vielleicht kann man inadyn-mt ja sogar unter OpenWrt ans Laufen kriegen, dann würde der ganze dynamische Krempel (dyndns+iptables) direkt auf dem Router abgewickelt werden und der Server bliebe universell.

Das Problem hatte ich auch, ich habe mir im Internet einen Wolf gesucht, und es gibt dazu keine fertige Lösung. Meine persönliche Lösung ist ein selbstgeschriebenes Programm. Zugang kann man sich damit entweder per erlaubter Hostnamenliste oder per Pingknocking verschaffen. Ich bevorzuge inzwischen Pingknocking, weil der Quellhost dann keine dyndns-Eintrag benötigt, was die Sache unterwegs via Mobilfunk deutlich vereinfacht.

Stimmt, Ping(port?)nocking wird dann wohl das zweite sein, wenn der obige, erste Ansatz scheitert, - hatte ich noch gar nicht dran gedacht. Was nimmt man für das vorherige Anklopfen denn so als Debian-Paket?

Gruß

[whiizy]

... ich habe da noch Denkfehler drin, wie es aussieht. Der Server bezieht seine (IPv6-)Adresse auch schon dynamisch, deshalb muss er selbst es dem Dyn DNS mitteilen, wenn sich seine IP ändert. Das kann ihm der externe OpenWrt-Router kaum abnehmen. Kurz: der Server muss dann doch wieder per ssh die namensbasierte Firewall auf dem schützenden Router restarten.

Für vollwertige Debian-Server als client mag das alles noch machbar sein, aber wenn ich da mal etwas weiter an das vielbeschworene "Internet der Dinge" denke ... da hat nicht jeder IPv6-Sensor oder -Aktor die Fähigkeit, dyndns-client zu spielen und bei IP-Änderungen eine remote firewall durchzustarten.

Nun gut, bei einem echten delegierten IPv6-Prefix von einem professionellen Provider wäre das sicherlich auch alles einfacher.

[MSfree]

.Ja, dann wird wohl ein cronjob alle 5 min oder so kontrollieren müssen, ob sich die Namensauflösung geändert hat. Falls ja, müsste der job dann nur die ip6tables neu laden.

Das ginge natürlich. Ich bin aber kein Freund von Polling, also Methoden, die mehr oder weniger auf Versuch und Irrtum beruhen. Der Nachteil so einer Lösung ist, daß man bei einem fehlgeschlagenen Verbindungsaufbau nie weiß, ob man nur gerade noch auf ein Refresh warten muß oder ob der dyndns-Update fehlgeschlagen ist.

Mir fällt aber gerade noch ein, daß der inadyn-mt (dyn DNS client) auf dem Server (raspi) läuft und die ip6tables auf dem vorgelagerten, externen Router (openwrt). Demzufolge müsste mein Server dann bei der festgestellten IP-Änderung die firewall remote per ssh oder so auf dem OpenWrt restarten.

Warum nutzt du für das dyndns-Update Polling? Es ist völlig unnötig, alle 5 Minuten zu prüfen, ob sich die IP geändert hat. Der Router kennt doch den exakten Zeitpunkt der IP-Änderung. Der PPPoE-Daemon ist von sich aus in der Lage, Skripte nach Verbindungsaufbau zu starten. In der Debianinstallation wird z.B. der ntpd neu gestartet, dort kann man auf dyndns mit updaten lassen, also in der Regel nur einmal Tag. OpenWRT soltle das eigentlich auch von Haus aus beherrschen.

Die Änderung der Client-IP-Adressen hast du damit allerdings noch nicht im Griff.

Stimmt, Ping(port?)nocking wird dann wohl das zweite sein, wenn der obige, erste Ansatz scheitert, - hatte ich noch gar nicht dran gedacht. Was nimmt man für das vorherige Anklopfen denn so als Debian-Paket?

Portknocking hat den Vorteil, daß es dafür ein fertiges Paket gibt: knockd.
Der Nachteil ist, daß ein Client hinter einer Firmenfirewall seine Anklopfsequenz nicht zum Server raus bekommt, weil die Firewall diese Ports blockiert.

Für Pingknocking habe ich bisher nichts fertiges gefunden, also habe ich mir einen Daemon selbst geschrieben. Für das Anklopfen ist ein modifiziertes Pingprogramm nötig, das in der Lage ist, im Payload des Pingpakets ein Paßwort zu übertragen. Modifizierte Pingprogramme habe ich für Windows und Linux als Quellcode, eine Macversion ist noch in Vorbereitung.

[heisenberg]

Wusste gar nicht, dass man bei IP-Tables auch Hostnamen verwenden kann. Gut zu wissen.

Was den Port-Knocking-Kram angeht: Ich schätze das als Hipster-Methode ein(Siehe: XKCD - Real Programmers), die nur begrenzt sicher ist und schon durch mitsniffen des Traffics auszuhebeln ist. Als zusätzliche Sicherungsmassnahme kann man das bestimmt hier und da gebrauchen.

Beim normalen Sicherheitsbedürfnis wäre mir das alles egal. Da reicht ein SSH mit Key-Only-Authentifizierung schon aus - und ja auch OpenSSH-kann und wird immer mal wieder eine Sicherheitslücke enthalten. Wenn es denn mehr Sicherheit sein muss, dann kann man auch was besseres basteln.

Wenn man denn schon eine Client-Komponente(so etwas wie der Portknocker) haben muss, dann kann man das auch sicherer lösen. Z. B. über einen dedizierten SSH-Aufruf, der sich mit Key verbindet und dann eine Firewall-Rekonfiguration auslöst.

Vom Client(z. B. im post-up Script)

Code: Alles auswählen

echo $MY_IP | ssh server

Am Server($TARGET_USER/.ssh/authorized_keys)

Code: Alles auswählen

command="/usr/local/bin/allow_ip.sh",no-port-forwarding,no-x11-forwarding,no-agent-forwarding KEY_TYPE KEY COMMENT

Dazu müsste sich also jemand mit einem vorhandenen Key einloggen um die FW-Neukonfiguration auszulösen. Das einlesen der IP ist dabei natürlich sicherheitskritisch. Z. B. also so:

allow_ip.sh

Code: Alles auswählen

# Von den übergebenen Daten nur die ersten 15 Zeichen auswerten 
# und die nur akzeptieren, wenn das per grep tatsächlich eine IP ist.
IP_SAFE=$(cut -c1-15 | grep -E '^([1-9][0-9]{0,2}\.?){4}$')

# stdout/stdin jetzt schliessen, da nicht mehr gebraucht
exec <&-
exec >&-
/usr/bin/sudo /usr/local/bin/allow_ip_stage2 "$IP_SAFE"

Das umkonfigurieren kann man auch nochmal abkoppeln für zusätzliche Sicherheit. Alles eine Frage wie viel Arbeit man sich machen möchte.

[MSfree]

Beim normalen Sicherheitsbedürfnis wäre mir das alles egal. Da reicht ein SSH mit Key-Only-Authentifizierung schon aus

So habe ich auch mal gedacht. Seit ich aber einen Einbruch auf einen Server, der genau so abgesichert war, live miterlebt habe, bin ich anderer Meinung. Das ist zwar schon viele Jahre her und SSH hatte damals eine Sicherheitslücke, die ausgenutzt wurde, inzwischen ist diese Lücke gestopft, aber man wird sehr skeptisch, wenn man so etwas mal miterleben durfte. Seither halte ich alle Remotezugänge, die sich nur auf ihren Schlüssel oder ihr Zertifikat verlassen, für vollkommen unsicher, die Sicherheitslücken, die in den letzten Jahren in SSH und SSL aufgedeckt wurden, bestätigen meine Meinung immer wieder. Man muß davon ausgehen, daß in jeder Software irgendwo ein ganz dickes Ei verborgen ist, das früher oder später ausgenutzt wird.

[whiizy]

Das ginge natürlich. Ich bin aber kein Freund von Polling, also Methoden, die mehr oder weniger auf Versuch und Irrtum beruhen. Der Nachteil so einer Lösung ist, daß man bei einem fehlgeschlagenen Verbindungsaufbau nie weiß, ob man nur gerade noch auf ein Refresh warten muß oder ob der dyndns-Update fehlgeschlagen ist.

Da stimme ich Dir zu, schön finde ich so ein Polling auch nicht.

Warum nutzt du für das dyndns-Update Polling? Es ist völlig unnötig, alle 5 Minuten zu prüfen, ob sich die IP geändert hat. Der Router kennt doch den exakten Zeitpunkt der IP-Änderung. Der PPPoE-Daemon ist von sich aus in der Lage, Skripte nach Verbindungsaufbau zu starten. In der Debianinstallation wird z.B. der ntpd neu gestartet, dort kann man auf dyndns mit updaten lassen, also in der Regel nur einmal Tag. OpenWRT soltle das eigentlich auch von Haus aus beherrschen.

... die Umstände sind leider nicht ganz einfach. Der Kabelprovider macht nur halbgares IPv6 nach DSlite mit einem vorgeschriebenen Router. Da dieser nicht unter meiner Kontrolle ist und daher als nicht vertrauenswürdig gelten kann, musste ich dahinter noch einen eigenen Router schalten, auf dem ich wenigstens die private Firewall kontrollieren kann. Da dieser Provider aber kein reguläres IPv6-Prefix-Delegation anbietet, muss mein Router den unkonventionellen "relay mode" nutzen. Unter dem Strich hat man dann ein einziges /64 welches sich aber in unbestimmten Zeiträumen immer wieder mal ändert. Was natürlich doof ist, wenn man den Vorteil einer globalen IPv6-Adresse tatsächlich auch einmal privat für sich nutzen möchte.

PPPoE, wie bei klassischem DSL, kommt dabei gar nicht zum Einsatz. Mein Server erhält von meinem privaten Router per DHCP dynamisch eine private (RFC1918) IPv4 und die "relayte" IPv6 vom DSlite. Demnach hat zwar nicht ein PPPoE-client die Chance einen Firewall-Restart auszulösen, aber analog vielleicht der DHCP-Client (isc) auf dem Server. Ich weiß gar nicht, ob der DHCP-client sowas von Hause aus könnte.

Danke für den Hinweis auf knockd und auch Pingknocking, werde ich dran denken, wenn ich es mal brauche!

[whiizy]

Wenn man denn schon eine Client-Komponente(so etwas wie der Portknocker) haben muss, dann kann man das auch sicherer lösen. Z. B. über einen dedizierten SSH-Aufruf, der sich mit Key verbindet und dann eine Firewall-Rekonfiguration auslöst.

Die Idee finde ich interessant. Die Firewall würde erst dann per SSH-Befehl für die aktuelle IP restartet, wenn man die jeweiligen Serverdienste nutzen will (oder wenn man feststellt, daß der Dienst nicht mehr erreichbar ist, weil die Firewall eine IP-Änderung noch nicht eingelesen hat). Ist aber vielleicht etwas unpraktisch, da man dann selbst immer den private SSH-key bereit haben muss. Und Dienste, wie HTTPS, möchte man ja durchaus auch mal permanent Dritten zur Verfügung stellen.

Vielen Dank für Deine code-schnipsel, die muss ich erst noch etwas sacken lassen!

[whiizy]

Ich habe noch herausgefunden, daß das aktuelle Release von OpenWrt jetzt auch Dyn DNS für IPv6-Adressen unterstützt. Es gibt für die Router-GUI (luci) die nachinstallierbare luci-app-ddns, welche scripts für diverse DynDNS-Anbieter mitbringt. Hat in meinem Fall sogar geklappt.

Ob eine registrierte IP-Änderung dann automatisch den Netzwerk-Stack samt firewall reloaded, weiß ich derzeit nicht (ist vermutlich auch eher ein Wunschgedanke). Aber zumindest besteht so schonmal die Möglichkeit, daß der Router den Anlass für einen Firewall-Reload selbst detektieren kann.

Bis an diese Stelle war ich eigentlich erstmal ganz happy, als ich dann ein Problem an anderer Stelle feststellen musste. Ich wollte eine neue Traffic-Rule in der OpenWrt-GUI anlegen und dort den hostname des Servers anstatt seiner IPv6-Adresse eintragen. Leider ist das in der Maske nicht möglich , es werden dort nur wie gewohnt IP-Adressen akzeptiert (obwohl iptables unter der Haube hostnames durchaus erlaubt, wie ich heute gelernt habe). Damit kann ich namensbasierte Regeln bequem über die GUI wohl schon vergessen. Einen Ausweg gäbe es vielleicht noch, wenn man in OpenWrt eigene Rules in normaler iptables-Syntax ergänzen könnte. Halte ich für wahrscheinlich, daß OpenWrt diese Flexibilität irgendwo hat (nur noch nicht wo genau).

Gruß

[killerbees19]

Einen Ausweg gäbe es vielleicht noch, wenn man in OpenWrt eigene Rules in normaler iptables-Syntax ergänzen könnte. Halte ich für wahrscheinlich, daß OpenWrt diese Flexibilität irgendwo hat (nur noch nicht wo genau).

Gibt es natürlich: /etc/firewall.user (über LuCI unter Netzwerk » Firewall » Benutzerdefinierte Regeln zu finden)

Damit kannst Du beliebigen Shellcode ausführen lassen, wenn die Firewall neu gestartet wird. Beispiel:

Code: Alles auswählen

# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.

# Internal uci firewall chains are flushed and recreated on reload, so
# put custom rules into the root chains e.g. INPUT or FORWARD or into the
# special user chains, e.g. input_wan_rule or postrouting_lan_rule.

# Transparenter Tor Proxy: https://trac.torproject.org/projects/tor/wiki/doc/OpenWRT
iptables -t nat -A PREROUTING -i br-guest -p udp --dport 53 -j REDIRECT --to-ports 9053
iptables -t nat -A PREROUTING -i br-guest -p tcp --syn -j REDIRECT --to-ports 9040

# fwknop-Server neustarten
/etc/init.d/fwknopd restart

Für Dein ursprüngliches Problem habe ich gerade nichts parat, da ich den Thread nur schnell überflogen habe und mir diese Subfrage aufgefallen ist. Es ist eindeutig schon zu spät…


MfG Christian

[whiizy]

Für Dein ursprüngliches Problem habe ich gerade nichts parat, da ich den Thread nur schnell überflogen habe und mir diese Subfrage aufgefallen ist. Es ist eindeutig schon zu spät…

Danke für Deine trotzdem noch so klaren Nachtgedanken!
Über die "Custom Rules" in der GUI bzw. letzlich die /etc/firewall.user kann ich jetzt eine massgeschneiderte, namensbasierte Regel fuer einen Dienst erstellen!

Da ich mit der Syntax von ip6tables nicht ganz so vertraut bin, habe ich zunächst als Vorlage eine Traffic Rule mit der firewall GUI erstellt (welche zunächst noch eine numerische Zieladresse enthielt). Mit ip6tables -S habe ich mir das Ergebnis dann angesehen und herauskopiert. Diesen Regel musste ich dann nur noch um ip6tables -t filter ergaenzen (im table filter sind die Traffic rules angesiedelt), damit die firewall.user die vollständige netfilter-Syntax erhält. Die vorläufige IP-Adresse habe ich dann durch meinen gewünschten hostname ersetzt.

Musterhaft sieht eine funktionierende Custom Rule für einen HTTP-Webserver hinter dem OpenWrt-Router jetzt so aus:

Code: Alles auswählen

ip6tables -t filter -A zone_wan_forward -d myhost.mydomain.tld -p tcp -m tcp --dport 80 -m comment --comment Allow-HTTP-1 -j zone_lan_dest_ACCEPT

Was genau passiert, wenn sich die zugewiesenen IP-Adressen vom Provider mal wieder ändern, muß ich wohl abwarten. Da aber beide Endgeräte (der Webserver und mein OpenWrt) nun Dyn DNS mit IPv6 beherrschen und die Firewall nun namensbasierte Regeln enthält, ist die Chance für einen kontinuierlichen Server-Betrieb vielleicht gar nicht so schlecht.

Gruß

[whiizy]

PS:
Damit die Custom Rule auch bootfest ist, musste ich noch einen sleep von 30 s und einen anschließenden /etc/init.d/firewall restart in die /etc/rc.local des OpenWrt einfügen. Vermutlich ist ohne Verzögerungsfaktor die Namensauflösung oder DDNS noch nicht rechtzeitig fertig.