6
IPBan in OpnSense mit CrowdSec einrichten?
Hallo! Ich bins mal wieder mit einer kleinen frage.
Ich bin aktuell dabei unseren Projektserver neu aufzusetzen.
Ich nutze als firewall eine OpnSense. Ich möchte gern das die config seite auf WAN erreichbar ist (Ich weiß, nicht die best practice), das geht auch soweit. Jetzt kommt der Punkt: Die oberfläche sitzt hinter einem reverse proxy (damit dies an eine subdomain kann und aus cert. gründen) Das klappt auch.
Aber dadurch klappt kein CroudSec oder andere fail2bans, da er nur die IP vom Reverseproxy bekommt. Header wird mitgeschickt (X-Forwarded-For) aber juckt die oberfläche nicht.
hat jemand damit erfahrung in die richtung?
Danke im vorraus
Ich bin aktuell dabei unseren Projektserver neu aufzusetzen.
Ich nutze als firewall eine OpnSense. Ich möchte gern das die config seite auf WAN erreichbar ist (Ich weiß, nicht die best practice), das geht auch soweit. Jetzt kommt der Punkt: Die oberfläche sitzt hinter einem reverse proxy (damit dies an eine subdomain kann und aus cert. gründen) Das klappt auch.
Aber dadurch klappt kein CroudSec oder andere fail2bans, da er nur die IP vom Reverseproxy bekommt. Header wird mitgeschickt (X-Forwarded-For) aber juckt die oberfläche nicht.
hat jemand damit erfahrung in die richtung?
Danke im vorraus
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: 82087576281
Url: https://administrator.de/contentid/82087576281
Printed on: December 1, 2023 at 07:12 o'clock
6 Comments
Latest comment
Moin,
Gruß,
Dani
Aber dadurch klappt kein CroudSec oder andere fail2bans, da er nur die IP vom Reverseproxy bekommt. Header wird mitgeschickt (X-Forwarded-For) aber juckt die oberfläche nicht.
es gibt für die Thematik einen weiteren Paramter für die Crowdsec Lösung: use_forwarded_for_headers (https://docs.crowdsec.net/docs/configuration/crowdsec_configuration/#use ..). Damit sollte diese die richtige IP-Adresse aus den Logfiles auslesen und verwerten.Gruß,
Dani
Zitat von @Dani:
Moin,
Gruß,
Dani
Moin,
Aber dadurch klappt kein CroudSec oder andere fail2bans, da er nur die IP vom Reverseproxy bekommt. Header wird mitgeschickt (X-Forwarded-For) aber juckt die oberfläche nicht.
es gibt für die Thematik einen weiteren Paramter für die Crowdsec Lösung: use_forwarded_for_headers (https://docs.crowdsec.net/docs/configuration/crowdsec_configuration/#use ..). Damit sollte diese die richtige IP-Adresse aus den Logfiles auslesen und verwerten.Gruß,
Dani
Der Parameter ist doch nur für die API soweit ich gesehen habe, oder nicht?
In den logfiles steht nicht Mal die IP aus dem Header, sondern nur die vom Reverse-Proxy. Den Login Audit interessiert scheinbar nur die Connect IP
Moin,
Gruß,
Dani
In den logfiles steht nicht Mal die IP aus dem Header, sondern nur die vom Reverse-Proxy.
von welchen Logfiles sprichst du?Aber dadurch klappt kein CroudSec oder andere fail2bans
Läuft auf der OpnSense, richtig?Gruß,
Dani
Zitat von @Dani:
Moin,
Gruß,
Dani
Moin,
In den logfiles steht nicht Mal die IP aus dem Header, sondern nur die vom Reverse-Proxy.
von welchen Logfiles sprichst du?Aber dadurch klappt kein CroudSec oder andere fail2bans
Läuft auf der OpnSense, richtig?Gruß,
Dani
Hat sich erübrigt. Ich mach das anders, ich mach's ohne Reverse Proxy auf nem high Port.
Aber stehe nun vor einem anderen Problem
Ich hab ja hn0 als WAN und hn1 als LAN Interface
Zusätzlich hab ich für einem Mail Server eine weitere Public IP, an hn2. Der Mailserver sitzt dann mit an hn3
Problem ist, sobald ich hn1 und hn2 anbinde, geht kein DNS resolving mehr und alles steht. Ich binde mal ein Bild vom Setup ein
Moin,
Gruß,
Dani
Hat sich erübrigt. Ich mach das anders, ich mach's ohne Reverse Proxy auf nem high Port.
Alles klar.Aber stehe nun vor einem anderen Problem
neues Problem, neue Frage.Gruß,
Dani
