Mai 31

ipv6 ist nett. Aber der User bekommt halt jedes mal idR ein /64 Subnet. Für so Tools wie fail2ban, die einzelne IPs blocken, wenn irgendetwas komisches auftaucht irgendwie schlecht. Der Angreifer schnappt sich halt irgendeine neue IP, denn die unteren 64bit stehen ja voll zu seiner Verfügung.

Jetzt verhält es sich mit dem originalen fail2ban so, dass das nicht mal ipv6 kann. Zeit sich auf die Suche zu machen. In einem github-Repo bin ich fündig geworden. Der gute Mensch hat fail2ban so erweitert, dass es v6-fähig wird. Also flugs mal installiert, um direkt die Ernüchterung zu spüren: Es blockt mit /128 🙁

Also erweitern:

Die /etc/fail2ban/action.d/iptables-46-multiport-log.conf passen wir wie hier in diesem gist sichtbar an. Hinzugekommen ist lediglich <mask> bei der ban und unban-Regel sowie unter init. Das bedeutet, dass – sofern nicht anders angegeben – immer eine /32er CIDR-Mask gelegt wird, also die gesamte v4-IP (bei v6 halt ebenfalls /32 – aber dazu später mehr) geblockt wird.

Da die fail2ban-Variante von “usrweiss” im Wrapperscript nicht so granular zwischen v4 und v6 differenzieren kann, als dass wir da andere cidr-Masken drauflegen könnten, legen wir einfach in der /etc/fail2ban/jail.conf ZWEI Jails an:

[web_v4]
enabled = true
filter  = web_v4
action = ip64tables-multiport-log[name=web_v4, protocol="tcp", port="80,443", mask=32]
logpath = /var/log/apache2/web_f2b/fails.log
maxretry= 5
bantime = 60
findtime= 60

[web_v6]
enabled = true
filter  = web_v6
action = ip64tables-multiport-log[name=web_v6, protocol="tcp", port="80,443", mask=64]
logpath = /var/log/apache2/web_f2b/fails.log
maxretry= 5
bantime = 60
findtime= 60

									

Die benötigen wiederrum auch 2 Configs in der /etc/fail2ban/filter.d:

/etc/fail2ban/filter.d/web_v4.conf:

# Fail2Ban configuration file
#
#
# $Revision: 250 $
#

[INCLUDES]

[Definition]

failregex = Applikation: v4 (<HOST>) Detaillierte Fehlermeldung .*

									

/etc/fail2ban/filter.d/web_v6.conf:

# Fail2Ban configuration file
#
#
# $Revision: 250 $
#

[INCLUDES]

[Definition]

failregex = Applikation: v6 (<HOST>) Detaillierte Fehlermeldung .*

									

Der Haken ist, dass unsere Applikation, die die Events auslöst (hier eine Loginseite, die die Fehlversuche nach /var/log/apache2/web_f2b/fail.log wegschreibt) an die Zeile dranschreiben muss, ob es sich um v4 oder v6 handelt. Bezogen auf die o.g. Configs sieht das in dem fail.log der App so aus (Von der Applikation generierte Einträge. Erster: v6, zweiter v4)

[May 31 10:08:12] Applikation: v6 (2a03:2880:2130:cf05:face:b00c:0:1) fehlerhafter Loginversuch blabla
[May 31 10:09:12] Applikation: v4 (173.252.120.6) fehlerhafter Loginversuch blabla
									

Von nun an blockt fail2ban die Ports 80 und 443 sobald in der Logdatei der Applikation (/var/log/apache2/web_f2b/fail.log) 5 mal innerhalb von 60 Sekunden die selbe IP mit einem Fehler aufschlägt für 60 Sekunden. Und zwar bei einer v4 halt die v4, bei einer v6 das /64er Subnet der v6. Die gerade greifende Netzmaske wird in der/etc/fail2ban/jail.conf als Variable “mask” in der action mit angegeben – sollte dort nichts stehen, gilt der Defaultwert von /32 aus der iptables-46-multiport-log.conf

 

Wie üblich, geht das sicherlich noch eleganter. Bin gespannt, wann fail2ban endlich eine v6-Variante releast.

Tagged with:
Jun 17

So, es ist vollbracht. Die ganzen Consumer-Provider in good ‘ol Germany wollen ja irgendwie nicht so richtig mit ipv6 an den Start kommen. Also habe ich mal selbst Hand angelegt. Einen Provider hat man schnell gefunden. Ich habe mich für sixxs.net entschieden.

Bei sixxs.net bekommt man zunächst einen /64er Block für lau zugewiesen, den man hinterher auf /48 upgraden kann (Vorraussetzung: der 64er Tunnel läuft eine Woche durch / Downtimes, bspw. zum basteln, sind nicht tragisch). Einfach anmelden, “aiccu” herunterladen, konfigurieren, starten und glücklich sein. Achtung: Aiccu / sixxs.net prüft die Systemzeit – Ein NTP-Client auf dem lokalen Endpunkt hilft da ungemein !

Das 48er-Subnet benötigt man aber nicht wirklich für den Heimgebrauch. Mit dem 64er kann man die restlichen 2^64 Adressen munter im Netz verteilen. Genau da war Anfangs auch mein Denkfehler. Mir war nicht aufgefallen, dass sixxs.net ein Transfernetz zur Vefügung stellt, durch das dass /64er gerouted werden kann. Konkret sieht das ganze nach dem ersten Start wie folgt aus:

  • PtP-Adresse (Da gehts also zu sixxs): 2001:6f8:100:fea::1/128 (Die beiden :: sind die Platzhalter für gaaanz viele Nullen – ausgeschrieben sähe das ganze so aus: 2001:6f8:100:fea:0000:0000:0000:1/128)
  • Lokale Adresse des ersten “ipv6”-Interfaces: 2001:6f8:100:fea::2/64
  • Und jetzt wird’s spannend. Im Webinterface bei sixxs.net kann man sehen, dass das zur Verfügung stehende Netz 2001:6f8:100:dfea::/64 lautet (Man beachte das “d” bei Octet 7)

Mit dem dfea-Netz (die Adressen sind für den Blogeintrag gefaked) können wir nun intern loslurchen und die Rechner ausstatten. Im simpelsten Falle installiert man sich den radvd (Router Advertising Daemon) und konfiguriert sowie startet ihn. Der verteilt die Dinger dann im LAN. Achtung: Dem LAN-Interface muss man selbst eine (v6-)IP aus dem dfea-Netz verpassen (/etc/network/interfaces) – das macht der radvd nicht. Jetzt noch das ipv6-Fowarding enablen (echo 1 >/proc/sys/net/ipv6/conf/all/forwarding) und schon können alle anderen Rechner per ipv6 mit der Welt in Verbindung treten (oder auch angesprochen werden !!)

Was uns zu einem kleinen Schönheitsfehler bringt. Ich will ipv6, weil ich das genNATte und diese ewige dynamische IP-Vergabe leid bin. Dummerweise vergibt der radvd die IP’s aber höchstdynamisch. Statisch verfügbar wäre in diesem Szenario also allenfalls der Router. Schuld (- Die Diskussion will ich hier nicht führen -) sind die sog. “privacy extensions” die irgendwelche paranoiden Mitmenschen entworfen haben. Ich war schon bei v4 kein Freund von “Würfel”-DHCP. Ganz abgesehen davon möchte ICH, und nicht irgendein Billo-Router regeln, wer wann wie worüber ins Netz geht. Bei IP’s die man nicht kennt, ist das ein grausames Unterfangen.

Jetzt gibt es zwei Möglichkeiten aus dem Dilemma herauszukommen.

  1. DHCP-V6 aufsetzen (hab ich noch nicht ausprobiert) und die IP’s statisch den Mac-Adressen im LAN zuordnen.
  2. Den Servern händisch statische IP’s verpassen.
  3. Mischbetrieb aus 2 und radvd

Habe mich erstmal für Variante 3 entschieden. Also jeden Server abgrasen und eine IP aus dem dfea-Netz eintragen, Default(-v6-)Route setzen und testen. Die Arbeitsplatzrechner bekommen die IP’s per radvd, die Server sind statisch verdrahtet. Fein, funktioniert.

Jetzt kommt der fieseste Teil, an dem ich zwei Stunden versenkt habe:

Das ganze ist bei Debian nämlich leider nicht Bootfest, da Linux ganz jeck auf Route-Advertisments ist, und sich dort auch eine IP “ziehen”, wenn sie schon statisch eine abbekommen haben. Hier helft eine Kernel-Einstellung in /etc/sysctl.conf:

net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.autoconf=0

Die alleine macht aber auch noch nicht glücklich, da die sysctls beim booten eingelesen werden sollen. Zu diesem Zwecke linkt man sich die /etc/init.d/procps in die runtimelevel-Dirs (/etc/rcX.d/). Hilft auch noch nicht, weil: Die Einstellungen greifen nur, wenn auch das ipv6-Kernel Modul schon geladen ist – sonst laufen die ins leere 🙁 Hierzu ipv6 in die /etc/modules eintragen. Anschliessend booten – et voila: Es läuft !

Jetzt fehlt eigentlich nur noch eins: Eine ordentliche Firewall mit Connection-Tracking. Gibts wohl demnächst mal einen Blogeintrag drüber. Soviel sei gesagt: Connectiontracking geht erst ab Kernel 2.6.26, redirect (bspw. für transparente Proxies) erst ab 2.6.36…

Somit wäre dieses Blog nun auch via ipv6 erreichbar !

Tagged with:
preload preload preload