iptables - Ich werde noch wahnsinnig!!

[el_don]

Hallo zusammen,
ich hatte ein ähnliches Thema schon einmal hier im Forum, welches ich als gelöst empfunden hatte, was aber wohl ein Trugschluss war.
Es geht darum, dass ich mit zwei Docker Containern (fail2ban und emby) meinen Zugriff auf das Mediacenter von außen sichern möchte.
Der Zugriff aus dem Internet erfolgt über einen Reverse Proxy Docker Container.

Kurz zur allgemeinen Info:
fail2ban untersucht die embyserver.txt nach fehlgeschlagenen Logins und setzt in der Unraid iptables eine Regel, welche dann die IP Adresse auf definierte Zeit sperrt. Fail2ban findet die logdatei und erstellt den Eintrag, den ich auch in der chain "f2b-emby" über

iptables -L

wiederfinde...So weit, so gut...oder auch nicht, denn trotz Eintrag in den Chains, kann ich munter auf Emby zugreifen. 

Okay, dann halt mal iptables loggen und schauen was die Pakete überhaupt machen.

In der Input Chain, also dort wo eigentlich der gesamte Traffic reinkommt, eine Regel angelegt.

iptables -I INPUT -s 91.136.xx.xx/24 -j LOG

(xx.xx/24 steht  natürlich für eine konkrete Netzmaske aus der IP Adresse mit der ich zugreife). Dann ein

tail -f /var/log/syslog

und abgefeuert. Kein logging...das ist schon mal SEHR seltsam. Wenn ich es richtig verstanden habe, sollte ja sämtlicher Traffic zunächst über die INPUT chain kommen, bevor er weiterverarbeitet wird.

 

Okay, dann halt mal ein Logging auf die DOCKER-USER chain (ist Bestandteil der FORWARD chain), in der die f2b-emby einbaut ist gesetzt:

iptables -A DOCKER-USER -s 91.136.xx.xx/24 -j LOG

Kurz wieder in die syslog geschaut und bingo... ich kann sehen wie die Pakete durchrauschen.
Hier eine Zeile des Log-Eintrags:

Aug 23 10:24:24 unraid kernel: IN=br0 OUT=br0 PHYSIN=bond0 PHYSOUT=vnet24 MAC:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=91.136.xx.xx DST=10.36.xx.xx LEN=76 TOS=0x00 PREC=0x00 TTL=49 ID=0 DF PROTO=TCP SPT=50214 DPT=4443 WINDOW=4194 RES=0x00 ACK PSH FIN URGP=0

Dann also jetzt eine Regel an den Anfang der Chain setzen:

iptables -I DOCKER-USER -s 91.136.XX.XX -j DROP

Das Logging zeigt beim Zugriff nichts mehr an, also gehe ich davon aus, dass die ankommenden Pakete tatsächlich verworfen werden.

Aber jetzt kommt der Clou: Ich kann TROTZDEM auf emby zugreifen und meine Filme schauen.

Was ist denn da los? Kann das ggf. am Bonding liegen? Ansonsten hätte ich keinerlei Erklärungen. Ich werde noch wahnsinnig!!!
Habt Ihr eine Idee? Falls Ihr noch weitere Infos benötigt einfach nachfragen.

Vielen Dank
 

Edited August 23, 2022 by el_don

[el_don]

So, ich habe ich das Konstrukt fail2ban, emby und iptables mal auf einer schnell hochgezogenen Linux VM ausprobiert und es funktioniert nach Anpassen der Configs quasi "out of the box", so wie man es erwartet. Zusätzlich habe ich mal hier im Forum etwas recherchiert. Angesichts der zahlreichen zumeist gänzlich unbeantworteten Posts zum Thema IPtables, komme ich langsam zu dem Verdacht, dass Unraid netfilter bzw. iptables gar nicht wirklich korrekt implementiert hat.  Oder es ist so dermaßen verquarzt programmiert, dass da wirklich niemand mehr durchblickt. Etwas enttäuschend für ein Payware Produkt, aber vielleicht bin ich ja auch zu blöd und jemand Anderes hat da den Durchblick und kann mir erklären was ich da falsch mache.

[mgutt]

Hast du in den Docker Einstellungen den Host to Custom Access aktiviert?

 

Tatsächlich war ich bei meinen letzten Versuchen mit iptables auch verwrirrt was die Ergebnisse anbelangte und dachte auch schon ich wäre zu blöd dafür.

[el_don]

Hallo Marc,

danke für Deine Antwort und Deinen Tipp. Kannst Du mir kurz aufs Pferd helfen wo/wie ich diese Einstellung aktiviere?
Vielen Dank. 

[cz13]

Settings-Docker dann Advanced View aktivieren dort hast du dann

Host access to custom networks:
um die Einstellung zu ändern musst du den Docker Dienst vorher beenden 

[el_don]

Prima. Probiere ich aus. Allerdings greife ich gerade Remote auf das System zu, da sollte ich den Docker Dienst lieber nicht beenden.
Aber ich werde berichten. Danke erstmal.

 

[el_don]

Tja. War eigentlich eine gute Idee, aber leider hat es nichts geändert.

Es ist wirklich äußerst seltsam.

 

Was mir aber noch aufgefallen ist:
Docker arbeitet da scheinbar mit internen VLANS. Wenn das ein IP oder MAC basiertes VLAN ist (kann man ja in den Einstellungen scheinbar auch parametrieren), dann ist es ja quasi "richtig", dass iptables die Pakete nicht sieht. Vielleicht ist das ein Ansatz.

 

Edited August 26, 2022 by el_don

[mgutt]

Ich meinte nicht, dass du es aktivieren sollst, sondern wollte nur fragen, ob es aktiv ist. Ich dachte dadurch könnten die Regeln ausgehebelt werden.

[Ford Prefect]

...ich würde nicht in den iptabvles des unraid host rumfummeln. Sowas gehört in eine dedizierte Firewall, durch die dann die VLANs geroutet/gefiltert werden.

Hilfsweise geht das mit eine VM auf unraid, der man am besten auch dedizierte Netzwerk-Karten zuordnet.

[el_don]

@mgutt Berechtigter Ansatz. Ich habe beides ausprobiert, aber leider war das Ergebnis identisch. Es gibt in den Docker Manuals auch eine Rubrik iptables https://docs.docker.com/network/iptables/ Da werde ich mal etwas stöbern, wobei es auf den ersten Blick genau das ist wie ich es gemacht und auch so verstanden habe.

Ich werde weiter berichten falls es neue Erkenntnisse dazu gibt.

 

@Ford Prefect Danke für Deinen Hinweis, aber ich möchte hier keine Philosophien diskutieren. Ich habe meine Gründe warum ich es genau so lösen möchte. Ich habe zuhause nicht wie auf der Arbeit einen Serverpark zur Verfügung und warum soll ich es mit einer zusätzlichen VM komplizieren, wenn es mit Unraid a.k.a. Linux mit Bordmitteln zu lösen ist oder zumindest sein sollte?

... to be continued ...

 

[el_don]

Ich denke, dass ich nach etwas Literatur zum Thema jetzt genug Info habe um die Sache zu lösen.

 

Also... mein "Fehler" war, dass ich für meine Container das macvlan Dockernetz benutzt habe. Dieses Dockernetz benutzt einen eigenen Treiber,
der quasi unterm Radar von iptables funktioniert.

Ich habe also für die besagten Container (reverse proxy, emby und fail2ban) einfach die Bridge benutzt und die Ports weitergeleitet und siehe da.... iptables funktioniert jetzt genau so wie ich es erwarte.

Wie ich das im macvlan Netz realisieren kann, was ich nebenbei gesagt etwas eleganter gefunden hätte, weiß ich zwar immer noch nicht, aber die Lösung wie ich sie jetzt implentiert habe funktioniert, zumindest was iptables angeht, so wie erwartet.

Edited August 29, 2022 by el_don