5
Ubuntu 18.04 fail2ban x-forwarded-for hinter HAProxy Opnsense
Hallo, bisher hatte ich eine Pfsense, da gab es die Funktion im HAProxy im Frontdend Use "forwardfor" option und im Backend die Transparent ClientIP, so konnte ich dem nachgelagerten System (Nextcloud) die wirkliche IP des Client mitgeben. Nun ist der umstieg auf Opnsense angedacht und hier sollte dann auch fail2ban sein Werk tun.
der Aufbau ist so Opnsense HAProxy --> nginx Reverse Proxy Nextcloud nach dieser Anleitung https://www.c-rieger.de/nextcloud-installationsanleitung/#c01
Mit der Pfsense hat es im gleichen Setup halt mit Transparent ClientIP wunderbar funktioniert.
Leider hat Opnsense nicht die Funktion Transparent ClientIP
daher sollte der anlog hierzu auf meinem Ubuntu Server erfolgen:
https://nerdblog.steinkopf.net/2016/12/fail2ban-schuetzt-owncloud-hinter ...
Nur leider werden die Jails erkannt aber von iptables nicht geblockt.
Danke
Die erstellte : iptables-x-forwarded-for.conf
und die meine nextclod.local dazu.
der Aufbau ist so Opnsense HAProxy --> nginx Reverse Proxy Nextcloud nach dieser Anleitung https://www.c-rieger.de/nextcloud-installationsanleitung/#c01
Mit der Pfsense hat es im gleichen Setup halt mit Transparent ClientIP wunderbar funktioniert.
Leider hat Opnsense nicht die Funktion Transparent ClientIP
daher sollte der anlog hierzu auf meinem Ubuntu Server erfolgen:
https://nerdblog.steinkopf.net/2016/12/fail2ban-schuetzt-owncloud-hinter ...
Nur leider werden die Jails erkannt aber von iptables nicht geblockt.
Danke
Die erstellte : iptables-x-forwarded-for.conf
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
#
[INCLUDES]
before = iptables-blocktype.conf
[Definition]
# Option: actionstart
# Notes.: command executed once at the start of Fail2Ban.
# Values: CMD
#
actionstart = <iptables> -N f2b-<name>
<iptables> -A f2b-<name> -j <returntype>
<iptables> -I <chain> -p <protocol> --dport <port> -j f2b-<name>
# Option: actionstop
# Notes.: command executed once at the end of Fail2Ban
# Values: CMD
#
actionstop = <iptables> -D <chain> -p <protocol> --dport <port> -j f2b-<name>
<actionflush>
<iptables> -X f2b-<name>
# Option: actioncheck
# Notes.: command executed once before each actionban command
# Values: CMD
#
actioncheck = <iptables> -n -L <chain> | grep -q 'f2b-<name>[ \t]'
# Option: actionban
# Notes.: command executed when banning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: See jail.conf(5) man page
# Values: CMD
#
#actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>
actionban = <iptables> -I f2b-<name> 1 -p tcp --dport 443 -m string --algo bm --string 'X-Forwarded-For: <ip>' -j DROP
#actionban = <iptables> -I f2b-<name> 1 -p -m string --algo bm --string 'X-Forwarded-For: <ip>' -j DROP
# Option: actionunban
# Notes.: command executed when unbanning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: See jail.conf(5) man page
# Values: CMD
#
#actionunban = <iptables> -D f2b-<name> -s <ip> -j <blocktype>
actionunban = <iptables> -D f2b-<name> -p tcp --dport 443 -m string --algo bm --string 'X-Forwarded-For: <ip>' -j DROP
#actionunban = <iptables> -D f2b-<name> -p -m string --algo bm --string 'X-Forwarded-For: <ip>' -j DROP
[Init]und die meine nextclod.local dazu.
[nextcloud]
backend = auto
enabled = true
port = 80,443
protocol = tcp
filter = nextcloud
maxretry = 3
bantime = 36000
findtime = 36000
logpath = /nextcloud/nextcloud.log
action = iptables-x-forwarded-for
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 553130
Url: https://administrator.de/contentid/553130
Printed on: April 19, 2024 at 10:04 o'clock
5 Comments
Latest comment
Ich stelle mal das ganze Konstrukt infrage, weil es einige unschöne Probleme bereiten kann.
Wäre es nicht zielführender und einfacher, die Requests auf der pfSense (per API die IP-Adressen eintragen) zu blockieren?
Das ist immerhin die Firewall...
Und dann läufst du auch nicht Gefahr, dass dir irgendwann legitime HTTP-Anfragen in Fehler 503 laufen, weil der Reverse-Proxy zu oft an der Verbindung zum Backend gescheitert ist.
Zu deinem Problem: Auf welchem Port kommen die Anfragen vom HAProxy zu dir?
Wenn 443 kannst du es eh vergessen mit iptables, denn das kann ja im verschlüsselten Datenstrom nichts erkennen
Wäre es nicht zielführender und einfacher, die Requests auf der pfSense (per API die IP-Adressen eintragen) zu blockieren?
Das ist immerhin die Firewall...
Und dann läufst du auch nicht Gefahr, dass dir irgendwann legitime HTTP-Anfragen in Fehler 503 laufen, weil der Reverse-Proxy zu oft an der Verbindung zum Backend gescheitert ist.
Zu deinem Problem: Auf welchem Port kommen die Anfragen vom HAProxy zu dir?
Wenn 443 kannst du es eh vergessen mit iptables, denn das kann ja im verschlüsselten Datenstrom nichts erkennen
Zitat von @LordGurke:
Ich stelle mal das ganze Konstrukt infrage, weil es einige unschöne Probleme bereiten kann.
Wäre es nicht zielführender und einfacher, die Requests auf der pfSense (per API die IP-Adressen eintragen) zu blockieren?
Das ist immerhin die Firewall...
Was ist das? Bzw. wie geht das? Hast Du da mal einen Link? Also sucht der Fail2ban auf meinem Server die fehlerhaften Zugriffe und gibt diese dann an die Pfsense oder Opnsense weiter?Ich stelle mal das ganze Konstrukt infrage, weil es einige unschöne Probleme bereiten kann.
Wäre es nicht zielführender und einfacher, die Requests auf der pfSense (per API die IP-Adressen eintragen) zu blockieren?
Das ist immerhin die Firewall...
Und dann läufst du auch nicht Gefahr, dass dir irgendwann legitime HTTP-Anfragen in Fehler 503 laufen, weil der Reverse-Proxy zu oft an der Verbindung zum Backend gescheitert ist.
Zu deinem Problem: Auf welchem Port kommen die Anfragen vom HAProxy zu dir?
Wenn 443 kannst du es eh vergessen mit iptables, denn das kann ja im verschlüsselten Datenstrom nichts erkennen
ja kommt über 443 zu mir, aber wenn Transparent ClientIP auf der Pfsense aktiv habe, dann geht das doch jetzt, dass Problem ist also nicht, dass ich das X-forwarded nicht "zu fassen bekomme". Der Jail wird ja von fail2ban erkannt, es geht "ja nur noch drum" das iptables das blockt, wenn Transparent ClientIP aus ist dann klappt das halt nicht. Wo ist da der Unterschied?Zu deinem Problem: Auf welchem Port kommen die Anfragen vom HAProxy zu dir?
Wenn 443 kannst du es eh vergessen mit iptables, denn das kann ja im verschlüsselten Datenstrom nichts erkennen
danke!
Zitat von @horstvogel:
Was ist das? Bzw. wie geht das? Hast Du da mal einen Link? Also sucht der Fail2ban auf meinem Server die fehlerhaften Zugriffe und gibt diese dann an die Pfsense oder Opnsense weiter?
Was ist das? Bzw. wie geht das? Hast Du da mal einen Link? Also sucht der Fail2ban auf meinem Server die fehlerhaften Zugriffe und gibt diese dann an die Pfsense oder Opnsense weiter?
Genau das wäre der Plan. Jetzt wo ich gerade danach suche, stelle ich gerade fest, dass pfSense scheinbar ohne integrierte API kommt - habe ich mit OPNsense verwechselt.
Vielleicht kann da jemand weiterhelfen, der pfSense schon länger im Einsatz hat.
ja kommt über 443 zu mir, aber wenn Transparent ClientIP auf der Pfsense aktiv habe, dann geht das doch jetzt, dass Problem ist also nicht, dass ich das X-forwarded nicht "zu fassen bekomme". Der Jail wird ja von fail2ban erkannt, es geht "ja nur noch drum" das iptables das blockt, wenn Transparent ClientIP aus ist dann klappt das halt nicht. Wo ist da der Unterschied?
Du suchst mit deiner iptables-Regel innerhalb der Netzwerkdaten nach diesem Header und der IP. Das wird bei unverschlüsselten Verbindungen tendenziell auch funktionieren.
Bei der verschlüsselten Verbindung über Port 443 kann iptables aber ja nunmal prinzipbedingt nicht in die Verbindung hineinschauen und deshalb auch nie etwas finden
(Naja, bei unverschlüsselten Verbindungen auch nur dann, wenn die Netzwerkpakete nicht an genau der Stelle fragmentiert werden und dadurch die Zeichenkette nicht mehr vollständig zu finden ist).
Hallo LordGurke,
hast Du einen Link für die integrierte API bei der OPNsense? Es soll ja in der Opnsense "später enden"
Warum geht das Transparent ClientIP? X-forwarded auf dem HAProxy sorgt doch schon dafür das die Client IP übertragen wird.
das verstehe ich nicht wirklich, warum das jetzt mit verschlüsselt oder unverschlüsselt was am Hut hat?
Danke!
hast Du einen Link für die integrierte API bei der OPNsense? Es soll ja in der Opnsense "später enden"
Du suchst mit deiner iptables-Regel innerhalb der Netzwerkdaten nach diesem Header und der IP. Das wird bei unverschlüsselten Verbindungen tendenziell auch funktionieren."
Warum geht das Transparent ClientIP? X-forwarded auf dem HAProxy sorgt doch schon dafür das die Client IP übertragen wird.
das verstehe ich nicht wirklich, warum das jetzt mit verschlüsselt oder unverschlüsselt was am Hut hat?
Danke!
Hallo LordGurke,
hast Du vielleicht einen Link für mich, die grundsätzlichen Infos zur API habe ich verstanden, aber wie das mit fail2ban funktioniert, da habe ich so nichts gefunden.
Danke!
hast Du vielleicht einen Link für mich, die grundsätzlichen Infos zur API habe ich verstanden, aber wie das mit fail2ban funktioniert, da habe ich so nichts gefunden.
Danke!
