el_don Posted February 20, 2022 Share Posted February 20, 2022 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. Quote Link to comment
mgutt Posted February 20, 2022 Share Posted February 20, 2022 55 minutes ago, el_don said: wie es sich für einen ordentlichen Server gehört, ... sollte SSH gar nicht erst über das Internet erreichbar sein. Quote Link to comment
Archonw Posted February 20, 2022 Share Posted February 20, 2022 Warum nicht? Mit ssh-key und ed25519 chrypto, dazu weg von port 22 dann noch fail2ban. Da hatte ich in zwei Jahren kaum noch Zugriffsversuche, und bei maximal 3 Versuchen mittels fail2ban wird die Möglcihkeit schon gerade gegen Null geführt, dass da noch ein unbefugter Zugriff möglich ist. Quote Link to comment
RiDDiX Posted February 20, 2022 Share Posted February 20, 2022 26 minutes ago, mgutt said: ... sollte SSH gar nicht erst über das Internet erreichbar sein. Ansich sage ich bei sowas immer nur bedingt. Es kommt auf die Sicherung des SSH Ports an. Ich empfehle, wenn er wirklich direkt offen sein muss, dann anderen Port als 22 und vor allem mit Key-Files + PW. Am besten ist sowas per VPN zu realisieren, aber vielen ist das zu umständlich. Zurück zu Fail2Ban Problem. Ansich scheint da gar nichts geblockt zu werden. Du bannst ja nur im Docker Fail2Ban sonst nirgends. So lange dein Traffik nicht durch den Fail2Ban Docker geroutet wird bringt das alles nichts. Sonst so kann man anhand deiner gelieferten Infos nicht viel mit der Konfig anfangen. Sorry Quote Link to comment
el_don Posted February 20, 2022 Author Share Posted February 20, 2022 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... Quote Link to comment
mgutt Posted February 20, 2022 Share Posted February 20, 2022 9 minutes ago, el_don said: Wo um alles in der Welt habe ich da etwas von ssh gesagt? Sorry. Tatsächlich nur überflogen. Gut, du willst also IPs blockieren, die sich bei Emby versuchen mit dem falschen Login anzumelden. Dazu lässt du iptables Regeln auf der Host-Maschine, also unRAID durch den fail2ban Container setzen. Welche Rechte hat der Container, dass er das überhaupt darf? Also welche Config hat dein fail2ban Container? Quote Link to comment
el_don Posted February 20, 2022 Author Share Posted February 20, 2022 @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 Quote Link to comment
el_don Posted February 20, 2022 Author Share Posted February 20, 2022 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 Quote Link to comment
MattFromGer Posted April 19, 2023 Share Posted April 19, 2023 @el_don Ich habe genau das gleiche Problem mit dem Fail2ban Container von linuxserver. Hast du im letzten Jahr an deiner Config noch was verändert oder es bei FORWARD belassen? Wie kann ich meine Config so ändern, dass meine Regel in FORWARD angelegt wird? Quote Link to comment
Triceps1277 Posted September 30, 2023 Share Posted September 30, 2023 On 2/20/2022 at 6:33 PM, el_don said: 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 Kannst du deinen Weg noch mal aufzeigen? Was bedeutet Forward in Bezug auf die Fail2Ban config ? Quote Link to comment
blinddark Posted September 30, 2023 Share Posted September 30, 2023 (edited) Ich hänge an der gleichen Stelle. Edited September 30, 2023 by blinddark Quote Link to comment
Mainfrezzer Posted September 30, 2023 Share Posted September 30, 2023 (edited) Was auch immer ihr da an Container, die über die Brücke laufen, freigegeben habt und mit fail2ban sichern wollt muss in der Datei von fail2ban mit FORWARD anstelle von INPUT, wie in diesem Beispiel [sshd] # configuration inherits from jail.conf enabled = true chain = INPUT action = %(known/action)s geblockt werden. Immer wert sich die Beispiele anzugucken https://github.com/linuxserver/fail2ban-confs/tree/master#jaillocal-examples Edit: Der andere verfügbare Container hat auch sowas, nur nicht detailiert. https://github.com/FrankM77/docker-fail2ban Dort wird bei dem Vaultwarden Beispiel nur "chain=DOCKER-USER" genannt, sollte aber auch mit FORWARD gehen Edited September 30, 2023 by Mainfrezzer 1 Quote Link to comment
blinddark Posted September 30, 2023 Share Posted September 30, 2023 (edited) Hallo, ist eventuell das Problem, dass meine Container im Custom: BR0 laufen, eigene statische LAN-IPs haben und nicht im Bridge-Modus laufen? folgende Configs habe ich Angelegt und mal getestet: jail.local [DEFAULT] bantime.increment = true bantime.maxtime = 5w bantime.factor = 24 findtime = 24h bantime = 1h jail.d/nextcloud-auth.local [nextcloud-auth] enabled = true backend = AUTO protocol = tcp filter = nextcloud-auth maxretry = 3 chain = FORWARD action = %(known/action)s Melde ich mich nun 3X falsch an und führe auf der Console fail2ban-client status nextcloud-auth aus sehe ich folgendes: Status for the jail: nextcloud-auth |- Filter | |- Currently failed: 1 | |- Total failed: 5 | `- File list: /remotelogs/nextcloud/nextcloud.log `- Actions |- Currently banned: 1 |- Total banned: 1 `- Banned IP list: x.x.x.x iptables -L zeigt folgende Einträge: Chain f2b-nextcloud-auth (1 references) target prot opt source destination DROP all -- x.x.x.x anywhere RETURN all -- anywhere anywhere Die IP wird aber nicht geblockt. Muss ich alle Container auf Bridge umstellen oder hat noch jemand eine andere Idee eventuell in Kombination mit Nginx-Proxy-Manager? Bei 3 Fehlversuchen auf die Weboberfläche von Unraid selbst wird die entsprechende IP erfolgreich geblockt. Edited September 30, 2023 by blinddark Quote Link to comment
Mainfrezzer Posted September 30, 2023 Share Posted September 30, 2023 Wenn die auf BR0 laufen muss es INPUT sein und die Container selbst müssen IPTables ausführen. Das ganze ist wesentlich einfacher über nen Reverse Proxy zu regeln. Quote Link to comment
blinddark Posted September 30, 2023 Share Posted September 30, 2023 (edited) Hast du eventuell Lesestoff, wie ich das über den ReverseProxy lösen kann? Ich habe Nginx-Proxy-Manager Laufen und dieser leitet auch sämtlichen Verkehr an die definierten Ziele Weiter. Edited September 30, 2023 by blinddark Quote Link to comment
Mainfrezzer Posted October 2, 2023 Share Posted October 2, 2023 Puh also den Container von Linuxserver hab ich irgendwie nicht ans laufen bekommen auf die "Schnelle" Mit den Container von FrankM77 bzw der "Forkursprung", der funktioniert so wunderbar, das ich mich gerade von meinen Servern ausgeschlossen habe. Zum Glück nur via ipv6. War eigentlich recht schmerzfrei. Fail2ban und nginx laufen via HOST. jail.d/nginx.local [nginx] enabled = true port = 80,443 filter = nginx #banaction = %(banaction_allports)s action = iptables-allports[name=nginx, chain=INPUT] #Path to logfile......."inside the container"!!!!! logpath = /var/nginx/proxy-host-*_access.log /var/nginx/proxy-host-*_error.log maxretry = 5 bantime = 300 findtime = 300 bantime.increment = true (Die Port angabe ist anscheindend irrelevant, es bannt einfach alle ports, was man als positiv ansehen kann, war aber scheiße ssh zu verlieren xD) filter.d/nginx.local [INCLUDES] [Definition] failregex = ^.* (405|404|403|401|\-) (405|404|403|401) - .* \[Client <HOST>\] \[Length .*\] .* \[Sent-to <F-CONTAINER>.$ ignoreregex = ^.* (404|\-) (404) - .*".*(\.png|\.txt|\.jpg|\.ico|\.js|\.css|\.ttf|\.woff|\.woff2)(/)*?" \[Client <HOST>$ (genommen von diesem "Tutorial" Configuring Fail2ban with Nginx Proxy Manager (NPM) (lrvt.de)" action.d/iptables-common.local [Init] blocktype = DROP [Init?family=inet6] blocktype = DROP Damit hat das wunderbar funktioniert. Gut, bei mir ist das nen bisschen anders aufgebaut. Ich habe 2 Reverse-Proxy-Server hintereinander im Einsatz. Ich musste diese Modifikatione an dem im Internet ausführen. Damit werde ich definitiv und absolut nicht mehr durchgeleitet zu irgendwelchen Seiten die durch den Proxy bzw den ganzen Server laufen. Ich hab's nicht hinbekommen das über den Lokalen zu regeln. Ich hab aber auch noch nie mit fail2ban vorher "gearbeitet" oder crowdsec. Aber im Endeffekt sollte das reichen. So wie ich es aber gesehen habe gibts das ganze auch als Gesamtpaket mit "SWAG" aber damit hab ich auch noch nix gemacht. Quote Link to comment
blinddark Posted December 27, 2023 Share Posted December 27, 2023 (edited) Nun wollte ich mal ein Feedback da lassen. ich habe die Feiertage genutzt und meinen Nginx-Proxy-Manager sowie Fail2Ban in dem Host-Modus laufend konfiguriert. Fail2ban zusätzlich noch priviligiert. Nun funktioniert alles, wie es soll. Meine Jail.local sieht so aus: [DEFAULT] # Prevents banning LAN subnets ignoreip = 127.0.0.1/8 ::1 172.17.0.0/12 192.168.78.0/24 maxretry = 5 findtime = 24h bantime = 5y bantime.increment = true bantime.maxtime = 50y bantime.factor = 24 action = %(action_)s chain = INPUT allowipv6 = auto Meine nextcloud-auth.local ist dann nur noch so klein [nextcloud-auth] enabled = true backend = AUTO protocol = tcp filter = nextcloud-auth action = iptables-allports[name=nextcloud] die Logs vom Nginx-Proxy-Manager werden auch dank der Erklärung von @mainfrezzer ausgewertet. Vaultwarden und Unraid-sshd sowie unraid-webui sind ebenso schon abgesichert. Diverse Tests verliefen erfolgreich Jetzt stellen sich mir noch die Fragen, wie ich eine IP per ssh whitelisten kann und ob es ein Webinterface auf Docker-Basis für f2b gibt. Auch Mailbenachrichtigungen will ich gern noch konfigurieren. Edited December 27, 2023 by blinddark Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.