Unitymedia dynamischer IPv6-Präfix und Linux-Firewall

[GoaSkin]

Hallo,

man kann zwar bei Verwendung einer Fritzbox einzelne Ports für Systeme im Haus freigeben, jedoch hat die per Web konfigurierbare Firewall in der FB ihre Grenzen. Zu dem kann man bei Verwendung des TC7200 sowieso nur entweder alles sperren oder alles freigeben.

So gibt Fälle, in denen es ratsam ist, eine nachgelagerte Firewall selbst aufzusetzen. Die Tatsache, dass man jedoch einen dynamischen IPv6-Präfix vom Provider erhält (auch wenn sich der Präfix selten ändert) macht es jedoch schwierig, per ip6tables Regeln zu definieren, die für bestimmte Hosts immernoch gleichermaßen gültig bleiben, wenn sich der Präfix ändert.

Weiss jemand, ob es möglich ist, Firewall-Regeln so zu definieren, dass sie sich auf den Suffix statt dem Präfix einer IP-Adresse beziehen?

Man könnte zwar ein Skript erstellen, was den Präfix herausfindet und ip6tables bei Verwendung von Variabeln aufruft, jedoch würden die Regeln bei einem Präfix-Wechsel ihre Gültigkeit verlieren.

 

[tq1199]

... (auch wenn sich der Präfix selten ändert) ..., jedoch würden die Regeln bei einem Präfix-Wechsel ihre Gültigkeit verlieren.

Man könnte das "seltene Ändern" des Präfixes, mit z. B. einem watchdog (oder gleichwertig) überwachen und wenn der Fall der Änderung eingetreten ist, eine neue gültige ip6tables-Regel generieren und die alte nicht mehr gültige ip6tables-Regel löschen.

 

[NEXO]

Weiss jemand, ob es möglich ist, Firewall-Regeln so zu definieren, dass sie sich auf den Suffix statt dem Präfix einer IP-Adresse beziehen?

Mit mehr Schreibarbeit... aber nicht besonders sinnvoll. Suffixe sind nicht eindeutig und eröffnen jedem potentiellen Eindringling mit mehr oder weniger großem Subnetz entsprechend alle Türen.

tq1199's Vorschlag wäre auch meine erste Wahl. Natürlich nur ein Workaround, aber zumindest ein sinnvolles.
Man könnte man das ggf. auch über einen (zweckentfremdeten) DynDNS-Dienste auf dem Router lösen (Server auf dem Firewall-System, der entsprechend auf die Änderung reagiert). Oder halt klassisches Watchdog-Skript, das zyklisch auf Adressänderung prüft.

 

[SpaceRat]

Mit mehr Schreibarbeit... aber nicht besonders sinnvoll. Suffixe sind nicht eindeutig und eröffnen jedem potentiellen Eindringling mit mehr oder weniger großem Subnetz entsprechend alle Türen.

Es geht wohl eher um die Zielrechner ...

Jede gute IPv6-Firewall wird entweder über die "Suffixe" (Also den geräteabhängigen Teil der IPv6-Adresse) oder die DUID konfiguriert, nur ip6tables nicht.

Wir haben's hier mit der klassischen Mentalität des typischen Linux-Entwicklers zu tun, daß nicht sein kann (dynamische Präfixe), was nicht sein darf (Eigentlich sind sie wirklich Blödsinn).
Tatsache ist, wir haben in Deutschland quer durch die Bank weg bei fast allen Providern dynamische IPv6-Präfixe und ip6tables kann sie nicht wirklich handhaben.

Solange sich Linux-Entwickler lieber in ihrer eigenen Wahnwelt (Haloperidol würde helfen) statt in der Realität bewegen, wird sich da so schnell auch nix dran ändern.

 

[umuserhe]

Man kann schon das Suffix verwenden.

 

[sparkie]

Oder halt klassisches Watchdog-Skript, das zyklisch auf Adressänderung prüft.

wieso so kompliziert?

Dafuer gibt es extra die Moeglichkeit eigene Scripten in die DHCP Mimik einzubauen.

<i>
</i>/etc/dhcp/dhclient-exit-hooks.d/my_actions

bekommt im Environment alle relevanten Daten z.B.

<i>
</i>new_dhcp6_client_id=
new_dhcp6_domain_search=
new_dhcp6_name_servers=
new_dhcp6_server_id=
new_iaid=
new_ip6_prefix=
new_life_starts=
new_max_life=
new_preferred_life=
new_rebind=
new_renew=
new_starts=

mit. Z.B. wenn ein BOUND6, RENEW6 etc. ablaeuft. Damit kann man alle dynamischen Parameter / ip6tables-rules bei Bedarf in Echtzeit anpassen.

Solange sich Linux-Entwickler lieber in ihrer eigenen Wahnwelt (Haloperidol würde helfen) statt in der Realität bewegen, wird sich da so schnell auch nix dran ändern.

Keine Ahnung was jetzt eigentlich das Problem sein soll?

Geht doch alles bereits jetzt und hier.

 

[umuserhe]

Sparkie, wo hast du die Umgebungsvariablen gefunden? In der ISC-DHCP Doku?

Muss man außer dem iptables Script noch etwas von Hand anpassen? Routing Tabelle geht wahrscheinlich automatisch.

Welchen Server verwendest du für RA? An RA wird man ja nicht vorbei kommen, weil Android kein DHCPv6 kann.

Wie konfigurierst du Clients, die von außen erreichbar sein sollen? Eine iptables Regel mit SLAAC-Adresse oder weist du ihnen eine zusätzliche statische über DHCP zu?

 

[sparkie]

Sparkie, wo hast du die Umgebungsvariablen gefunden? In der ISC-DHCP Doku?

ja. Z.B. hier (unter enter/exit hooks) dhclient-script
am einfachsten du beginnst mit dem Kommando 'env' im Hook-Script. Dann siehst du ja sofort was alles im Environment steht.
Hier sind abhaengig von der verwendeten Distribution sicher auch Unterschiede. Ich nutze Debian 9.

Muss man außer dem iptables Script noch etwas von Hand anpassen? Routing Tabelle geht wahrscheinlich automatisch.

default route fuer ip6 passe ich auch an. Evtl. machen das schon irgendwelche fertigen Packages automatisch (die ich aber nicht installiert habe).

Kommt ausserdem drauf an was bei dir sonst noch alles so laeuft. Ich pruefe z.B. ebenfalls ob sich fuer den 'radvd' noch was Relevantes aendert. Und restarte bei Bedarf mit neuen Parametern.

Welchen Server verwendest du für RA? An RA wird man ja nicht vorbei kommen, weil Android kein DHCPv6 kann.

den 'radvd'

Wie konfigurierst du Clients, die von außen erreichbar sein sollen? Eine iptables Regel mit SLAAC-Adresse oder weist du ihnen eine zusätzliche statische über DHCP zu?

ich hab' noch native dual Stack hier am laufen. Externe Erreichbarkeit laeuft bei mir grundsaetzlich immer ueber IP4-Reverse-Proxy Verbindungen zu einem meiner dedicated Server im Internet.

 

[Ool3eiV3aetooChu]

Falls es jemandem hilft, ich mach's mir "einfach" (RHEL7):
/etc/sysconfig/ifcfg-eth0:

<i>
</i>DHCPV6C="yes"
DHCPV6C_OPTIONS="-P -N -nc"

hier holt der dhclient sich die Adressen über prefix delegation.

/etc/radvd.conf:

<i>
</i>interface br0 {	AdvSendAdvert on;	MinRtrAdvInterval 30;	MaxRtrAdvInterval 100;	prefix ::/64 {	AdvOnLink on;	AdvAutonomous on;	AdvRouterAddr on;	};
};

Die radvd.conf enthält keine Adressen oder Netze, sie werden beim startup automatisch ermittelt.

/etc/dhcp/dhclient.d/ipv6-router.sh:

<i>
</i>#!/bin/bash
public_if=eth0
internal_if=br0
[[ "${interface}" == "${public_if}" ]] || exit 0
ipv6-router_config() { [[ -n "${new_iaid}" ]] || return prefix=$( sed -n -r -e "/ia-pd ${new_iaid} [{]/,/[}]/{/iaprefix/s/.*iaprefix (.*) [{]/\1/p}" \ /var/lib/dhclient/dhclient6--${interface}.lease | \ tail -n1 ) [[ -n "${prefix}" ]] || return prefix=${prefix/\/*}/64 prev_net=( $(ip -6 --brief addr show dev ${internal_if} scope global) ) prev_net=${prev_net[@]:2} for p in ${prev_net}; do [[ "${prev_net}" == "${prefix}" ]] && return done ip -6 addr flush dev ${internal_if} scope global ip -6 addr add ${prefix} dev ${internal_if} systemctl restart radvd
}
ipv6-router_restore() { systemctl stop radvd ip -6 addr flush dev ${internal_if} scope global
}

Hier wird auf das interne Interface bei Bedarf eine neue Adresse gelegt, die das script aus den leases zieht. Hat sich was geändert – radvd neu starten.
Bei Bedarf die Interfacenamen anpassen; ich habe wegen der Virtualisierung als internes Interface eine bridge. Je nach Distribution sind vielleicht noch andere Änderungen nötig, etwa in den Pfaden oder der PATH-Umgebung (auch: Devuan hat z.B. kein systemctl).
Die Firewall (ip6tables) ist klassisch über in/out interfaces geregelt, einzelne Adressen sind prefixunabhängig gehalten, nach dem hier bereits genannten Schema mit /::ffff:ffff:ffff:ffff

 

[umuserhe]

Ool3eiV3aetooChu: Danke für das Script! Vielleicht kann ich es für Debian anpassen. Wie aktualisierst du die DNS Einträge?

 

[MartinDJR]

Solange sich Linux-Entwickler lieber in ihrer eigenen Wahnwelt (Haloperidol würde helfen) statt in der Realität bewegen, wird sich da so schnell auch nix dran ändern.

Freeware-Entwickler machen in der Regel das, was sie selbst brauchen:

Sie arbeiten an einer Universität, die das feste Präfix 2001:db8:2345::/48 hat - also schreiben sie an einer Firewall, die mit festen Präfixen arbeitet.

Wenn du selbst ein Feature haben willst, sollst/musst du dich selbst einbringen - z.B. indem du selbst mitentwickelst.

Das ist der Unterschied zu gekaufter Software, die von den Entwicklern für die Bedürfnisse der Leute entwickelt wird, die dafür bezahlen.

 

[hajodele]

ich glaube aber kaum, dass diese Entwickler eine Firewall für die Uni schreiben

 

[sch4kal]

Solange sich Linux-Entwickler lieber in ihrer eigenen Wahnwelt (Haloperidol würde helfen) statt in der Realität bewegen, wird sich da so schnell auch nix dran ändern.

Freeware-Entwickler machen in der Regel das, was sie selbst brauchen:

Sie arbeiten an einer Universität, die das feste Präfix 2001:db8:2345::/48 hat - also schreiben sie an einer Firewall, die mit festen Präfixen arbeitet.

Wenn du selbst ein Feature haben willst, sollst/musst du dich selbst einbringen - z.B. indem du selbst mitentwickelst.

Das ist der Unterschied zu gekaufter Software, die von den Entwicklern für die Bedürfnisse der Leute entwickelt wird, die dafür bezahlen.

OT:
ua. https://de.m.wikipedia.org/wiki/Rusty_Russell
Linux Kernel Dev, arbeitet für IBM.

 

[SpaceRat]

Das ist auch eine etwas verherrlichende Sicht der Dinge.
Es interessiert sich schlichtweg keiner der Restentwickler dafür, daß Linux jemals für Normalnutzer brauchbar wird. Wenn's rudimentär funktioniert, also mit Script-Gewurschtel ans Laufen zu kriegen ist, reicht das den Linux-Devs völlig.

Mir ist das auch völlig wumpe, ich habe schon vor Jahren die Hoffnung aufgegeben, daß Linux noch weiterentwickelt würde, und mich mit Windows arrangiert.

Es erheitert mich halt nur immer wieder, wenn Linux-Pinguine in diversen Foren und Blogs gegen Microsoft hetzen und Linux schönreden:
Schönreden hilft da nix, es müßte sich schon wirklich weiterentwickeln.

 

[sparkie]

Mir ist das auch völlig wumpe, ich habe schon vor Jahren die Hoffnung aufgegeben, daß Linux noch weiterentwickelt würde, und mich mit Windows arrangiert.

Hae?

Linux wird, wie man sieht, staendig weiterentwickelt. Dieser Thread ist das beste Beispiel: Beitrag

Was es nicht gibt schreibt man eben selbst und veroeffentlicht es.

Windows ist fuer diejenigen denen man alles vorkauen muss. Naja, und wem vor dem vorverdauten Kotzbrei aus Redmond nicht eckelt - Jedem das Seine :brüll:

 

[sch4kal]

Das ist auch eine etwas verherrlichende Sicht der Dinge.
Es interessiert sich schlichtweg keiner der Restentwickler dafür, daß Linux jemals für Normalnutzer brauchbar wird. Wenn's rudimentär funktioniert, also mit Script-Gewurschtel ans Laufen zu kriegen ist, reicht das den Linux-Devs völlig.

Mir ist das auch völlig wumpe, ich habe schon vor Jahren die Hoffnung aufgegeben, daß Linux noch weiterentwickelt würde, und mich mit Windows arrangiert.

Es erheitert mich halt nur immer wieder, wenn Linux-Pinguine in diversen Foren und Blogs gegen Microsoft hetzen und Linux schönreden:
Schönreden hilft da nix, es müßte sich schon wirklich weiterentwickeln.

Wenn die Tools nicht in die Oberfläche (z.b. in den NetworkManager) integriert werden ist das doch nicht die Schuld der Entwickler der Tools stell n Feature Request, dann wirds eventuell implementiert oder schreib selber ein Patch und erstell ein Merge Request. Natürlich sollte man dann etwas von Softwareentwicklung verstehen und sich die Coding und Design Principles vorher anschauen. Dafür weiß man wenigstens was der Code macht. Die MCTs bei uns in der Firma haben öfters keine Ahnung warum etwas in Windows nicht funktioniert und sind dann auf die Hilfe von MS angewiesen, da könnte ich in Linux den fehlerhaften Teil selber debuggen und im Code nachschauen was falsch läuft.

 

[umuserhe]

Der Windows Linux Flamewar würde besser in ein neues Thema passen.

 

[Ool3eiV3aetooChu]

Wie aktualisierst du die DNS Einträge?

Mithilfe von nsupdate, ebenfalls über dhclient.d; ich habe eigene DNS-Server für meine Domains. Aber ob da nun ein nsupdate oder für dyndns ein curl abgesetzt wird, ist ja egal. Das Prinzip ist dasselbe.
Beim Schreiben von solchen scripten (ip-up, dhclient, ...) ist es imho sinnvoll, zu Beginn des scripts ein paar Debugzeilen reinzupacken:

<i>
</i>#!/bin/bash
tmp=$(mktemp -d)
env > ${tmp}/env
echo $@ > ${tmp}/argv
exec 2> ${tmp}/stderr > ${tmp}/stdout
set -x

Dann siehst Du gleich, was dem script an Parametern oder Umgebungsvariablen übergeben werden, und suchst Dir das Passende raus.