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.

@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 ...

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.

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.

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.

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.

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

Okay...ich glaube ich habe es. Wenn ich die Regel direkt in "FORWARD" anlege, dann wird geblockt. Das ist zwar etwas "Holzhammer" weil ich dann auch andere Docker Container blocke, aber was soll's... Die bösen Seiten aus Osteuropa haben dann auf den anderen Diensten auch nichts zu suchen 😄 Von daher: erstmal CASE CLOSED

@mgutt Alles gut, wenn ich stundenlang erfolglos an irgendwelchen Problemen bastele, dann ist mein Nervenkostüm immer leicht angegriffen. Aber zum Thema: Ja, du hast Recht. Genau das will ich machen. An die Berechtigungen des Containers hatte ich auch schon gedacht. Aber ich vermute die Problematik liegt er in den iptables Chains. Lassen wir mal den fail2ban Container links liegen. Ich will jetzt einfach mal in UNRAID händisch eine IP Adresse in der iptables blockieren bevor ich mit dem Container weiter mache, denn da liegt sicherlich der Hund begraben. Mein Emby Docker läuft über Netzwerktyp br0. Wenn ich testweise einfach mal in der INPUT Chain eine IP Adresse blocke, dann kann Ich damit nicht mehr auf UNRAID zugreifen. Check! Auf Emby (der durch br0 natürlich eine andere Adresse im LAN hat) kann ich aber zugreifen. Ich muss glaube ich nur die richtige Chain finden, aber bis jetzt war ich nicht erfolgreich. Das ist die Ausgabe von 'iptables -L". Chain INPUT (policy ACCEPT) target prot opt source destination LIBVIRT_INP all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination DOCKER-USER all -- anywhere anywhere DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED DOCKER all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere LIBVIRT_FWX all -- anywhere anywhere LIBVIRT_FWI all -- anywhere anywhere LIBVIRT_FWO all -- anywhere anywhere WIREGUARD all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination LIBVIRT_OUT all -- anywhere anywhere Chain DOCKER (1 references) target prot opt source destination ACCEPT tcp -- anywhere 172.17.0.2 tcp dpt:4848 Chain DOCKER-ISOLATION-STAGE-1 (1 references) target prot opt source destination DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere RETURN all -- anywhere anywhere Chain DOCKER-ISOLATION-STAGE-2 (1 references) target prot opt source destination DROP all -- anywhere anywhere RETURN all -- anywhere anywhere Chain DOCKER-USER (1 references) target prot opt source destination f2b-emby tcp -- anywhere anywhere multiport dports http,https,8096,8920 RETURN all -- anywhere anywhere Chain LIBVIRT_FWI (1 references) target prot opt source destination Chain LIBVIRT_FWO (1 references) target prot opt source destination Chain LIBVIRT_FWX (1 references) target prot opt source destination Chain LIBVIRT_INP (1 references) target prot opt source destination Chain LIBVIRT_OUT (1 references) target prot opt source destination Chain WIREGUARD (1 references) target prot opt source destination Chain f2b-emby (1 references) target prot opt source destination RETURN all -- anywhere anywhere f2b-emby referenziert auf DOCKER-USER welche auf die FORWARD Chain referenziert. Mit INPUT habe ich es wie gesagt auch schon probiert. Aber das juckt den Emby Container nicht. Wo würdest Du die Regel setzen? Danke schon mal

Vielen Dank für Eure Antworten, wobei @mgutt Lies Dir bitte noch einmal genau meinen Post durch. 1. Wo um alles in der Welt habe ich da etwas von ssh gesagt? 2. wie @Archonw es bereits richtigerweise sagte, kann man SSH ohne Probleme auch im Internet bereitstellen. Zertifikat - sshkey - komplexes Passwort - Port ändern - Fail2ban und fertig ist die Laube. Ich betreibe und betreue seit vielen Jahren Server und bin alles andere als ein Anfänger. Sorry... nichts für Ungut, aber solche belehrenden Posts, die mit dem eigentlichen Thema wirklich nichts zu tun haben, bringen mich regelmäßig auf die Palme. @RiDDiX Vielleicht habe ich mich da nicht genau ausgedrückt. Sorry. Natürlich habe ich das iptables nicht im Docker Container laufen. Das würde ja, wie Du es richtig bemerkt hast, nichts bringen. Der Weg ist eigentlich der, dass fail2ban die durchgereichten Logs der Dienste monitored und die Bans setzt. Die setzt er natürlich dann direkt im UNRAID OS. Dort kommen sie ja auch an. Ich kann es mir im Moment nur so erklären, dass ich im falschen Chain (INPUT) unterwegs bin. Ich habe es aber auch schon im DOCKER-USER Chain probiert, was aber auch zu keinem Ergebnis geführt hat. Selbst wenn ich die Regel im INPUT Chain händisch setze, wird die IP Adresse nicht geblockt. Weder bei einer LAN, noch bei einer WAN IP Adresse. Irgendwas ist da doch faul...

Hallo zusammen, wie es sich für einen ordentlichen Server gehört, möchte ich meine neue Unraid Installation gegen Brute-Force aus dem Internet schützen. Dazu habe ich mir die Docker Version von fail2ban heruntergeladen und installiert. Ich habe mir meine erste Jail und meinen ersten Filter gebaut. Davon abgesehen kann man aber bevor man sich an die recht komplexe Regex begibt seine Installation testen. Und jetzt beginnt das Dilemma: Im Docker Container sage ich: fail2ban-client set emby banip xxx.xxx.xxx.xxx (das 'xxx' steht natürlich für eine konkrete IP Adresse) Ich checke, ob er den Befehl ausgeführt hat mit: fail2ban-client status emby und bekomme die korrekte Antwort: Status for the jail: emby |- Filter | |- Currently failed: 0 | |- Total failed: 0 | `- File list: /var/log/emby/embyserver.txt `- Actions |- Currently banned: 1 |- Total banned: 1 `- Banned IP list: xxx.xxx.xxx.xxx bash-5.1# Okay. Die IP Adresse sollte jetzt gebant sein. Das checke ich im iptables von Unraid mit: iptables -L INPUT und bekomme die Antwort: Chain INPUT (policy ACCEPT) target prot opt source destination f2b-emby tcp -- anywhere anywhere multiport dports http,https,8096,8920 LIBVIRT_INP all -- anywhere anywhere Okay. Der Docker Container hat also in der INPUT Chain die f2b-emby Rege,l die ich in der jail.local definiert habe korrekt angelegt. Das schaue ich mir genauer an mit: iptables -L f2b-emby und bekomme tatsächlich: Chain f2b-emby (1 references) target prot opt source destination REJECT all -- xxx.xxx.xxx.xxx anywhere reject-with icmp-port-unreachable RETURN all -- anywhere anywhere Bingo. Es sollten also jetzt alle einkommenden Pakete von xxx.xxx.xxx.xxx rejected werden. Tun sie aber nicht!!! Ich kann mit der IP auf den Service genau so zugreifen wie vorher auch. Ich werde noch wahnsinnig. Sieht einer den Fehler? Verstehe ich da etwas nicht richtig, oder sehe ich den Wald vor lauter Bäumen nicht? Es sollte doch so alles stimmen.