Absicherung Unraid fail2ban/iptables Problem

el_don · 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.

mgutt · 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.

Archonw · 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.

RiDDiX · 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

el_don · 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...

mgutt · 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?

el_don · 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

el_don · 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

MattFromGer · 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?

Triceps1277 · 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 ?

blinddark · September 30, 2023

Ich hänge an der gleichen Stelle.

Edited September 30, 2023 by blinddark

Mainfrezzer · September 30, 2023

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

blinddark · September 30, 2023

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:

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

Mainfrezzer · 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.

blinddark · September 30, 2023

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

Mainfrezzer · 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.

blinddark · December 27, 2023

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

Absicherung Unraid fail2ban/iptables Problem

Recommended Posts

el_don

Link to comment

mgutt

Link to comment

Archonw

Link to comment

RiDDiX

Link to comment

el_don

Link to comment

mgutt

Link to comment

el_don

Link to comment

el_don

Link to comment

MattFromGer

Link to comment

Triceps1277

Link to comment

blinddark

Link to comment

Mainfrezzer

Link to comment

blinddark

Link to comment

Mainfrezzer

Link to comment

blinddark

Link to comment

Mainfrezzer

Link to comment

blinddark

Link to comment

Join the conversation