HA Proxy Client ID weiterreichen

[docb]

Hallo zusammen,
ich habe mittlerweile einen HAProxy zum Laufen gebracht und hätte gerne, dass er die Client-ID an das Backend weiterreicht. In einer früheren Version gab es wohl bei der Config des Frontends die Option X-Forward-for header (sh. https://wiki.opnsense.org/manual/how-tos/haproxy.html) - aber die gibt es nicht mehr.

Die IP würde ich nämlich gerne durchreichen, um dann auf dem Server mit Fail2ban entsprechende Brute-force Angriffe zu unterbinden.

Aber vielleicht hat jemand auch eine andere Idee/Hilfestellung zum Erbasteln:
Wesentlich schöner wäre natürlich eine Möglichkeit, das direkt auf der OPNSense zu tun, aber wie ich die ganzen Posts verstanden habe, gibt es kein Fail2Ban für die OPNSense. Die Authentifikation könnte man nämlich wohl auch gleich am HAProxy einstellen und quasi vorlagern. Deswegen würde ich das jetzt erstmal mit der IP Weiterleitung im Header machen, dann über fail2ban auf dem Backendserver die IP bei cloudflare sperren lassen, da gibt es eine entsprechende Action. Aber die unterbindet natürlich nicht Angriffe, wenn jemand direkt auf meine IP geht, deswegen wäre dann mein nächster Schritt zu schauen, ob ich das irgendwie über die API von OPNSense hinbekomme. Da habe ich mich aber noch zu wenig damit beschäftigt, step by step ;-)

Viele Grüße
doc

[fabian]

Hallo zusammen,
ich habe mittlerweile einen HAProxy zum Laufen gebracht und hätte gerne, dass er die Client-ID an das Backend weiterreicht. In einer früheren Version gab es wohl bei der Config des Frontends die Option X-Forward-for header (sh. https://wiki.opnsense.org/manual/how-tos/haproxy.html) - aber die gibt es nicht mehr.

Die Doku ist leicht veraltet - sollte aber immer noch stimmen. Die meisten Menüs haben nur eine andere Überschrift bekommen.
Diese Doku habe ich für die letzte 1.x-Version des HAProxy-Plugins geschrieben und kurz darauf kam Version 2.
Ansonsten am besten @freanki frangen.

Die IP würde ich nämlich gerne durchreichen, um dann auf dem Server mit Fail2ban entsprechende Brute-force Angriffe zu unterbinden.

Wird vermutlich wenig Erfolg versprechen, weil die Requests alle mit der IP des Load-Balancers ankommen. Du solltest hier eher auf die API für die Aliase warten, damit das sinnvoll geht - dann musst du allerdings immer noch drauf hoffen, dass wer ein Modul bzw. einen Wrapper dafür schreibt.

Wesentlich schöner wäre natürlich eine Möglichkeit, das direkt auf der OPNSense zu tun, aber wie ich die ganzen Posts verstanden habe, gibt es kein Fail2Ban für die OPNSense.

Das ist so. sshd und Webschnittstelle sind mit einem ähnlichen Tool geschützt.

Die Authentifikation könnte man nämlich wohl auch gleich am HAProxy einstellen und quasi vorlagern.

Kommt ganz auf die Anwendung an.

Deswegen würde ich das jetzt erstmal mit der IP Weiterleitung im Header machen, dann über fail2ban auf dem Backendserver die IP bei cloudflare sperren lassen, da gibt es eine entsprechende Action.

Siehst du in dem Fall nicht nur deren IP?

Aber die unterbindet natürlich nicht Angriffe, wenn jemand direkt auf meine IP geht, deswegen wäre dann mein nächster Schritt zu schauen, ob ich das irgendwie über die API von OPNSense hinbekomme.

Einfach nur IPs von deinem Anbieter zuzulassen ist keine Option?

[docb]

Hi,
vielen Dank für die ausführliche Antwort. Weißt du zufällig hinter welcher neuen "Überschrift" sich das X-Header-For versteckt? Ich habe mal die aktuellen Möglichkeiten beim Frontend (jetzt Virtual Services->Public Services) man angehängt.

    Die IP würde ich nämlich gerne durchreichen, um dann auf dem Server mit Fail2ban entsprechende Brute-force Angriffe zu unterbinden.

Wird vermutlich wenig Erfolg versprechen, weil die Requests alle mit der IP des Load-Balancers ankommen. Du solltest hier eher auf die API für die Aliase warten, damit das sinnvoll geht - dann musst du allerdings immer noch drauf hoffen, dass wer ein Modul bzw. einen Wrapper dafür schreibt

Doch, das geht mit ein paar kleinen Anpassungen, dazu habe ich was gefunden : https://centos.tips/fail2ban-behind-a-proxyload-balancer/
Bis es eine API für Aliase gibt, werde ich das mal so machen (und neben der Sperrung der IP  auf dem Backend auch die so ermittelte IP an Cloudflare zur Sperrung geben (das geht da über die API, da meine Domain über Cloudflare läuft und Fail2Ban eine Action dafür hat). Ist mal besser als nix und dann schauen wir mal, wie die API von OpnSense vorankommt (eine echt suuuper Möglichkeit, da freue ich mich wie ein Schnitzel).

EDIT: HA, einfach genial - guck mal: https://github.com/fvanroie/PS_OPNsense/wiki/API-Commands
Es gibt eine API für HAProxy. Also werde ich eine IP SRC = Condition mit Regel http deny machen und versuchen, die src über die API mit Fail2Ban zu füttern ;-) Ich hoffe ich finde mal demnächst die Zeit dafür. Jetzt muss aber erstmal dieser X-header-for her 

[fabian]

Hi,
vielen Dank für die ausführliche Antwort. Weißt du zufällig hinter welcher neuen "Überschrift" sich das X-Header-For versteckt? Ich habe mal die aktuellen Möglichkeiten beim Frontend (jetzt Virtual Services->Public Services) man angehängt.

Nein, hab keinen HAProxy in Verwendung.

Doch, das geht mit ein paar kleinen Anpassungen, dazu habe ich was gefunden : https://centos.tips/fail2ban-behind-a-proxyload-balancer/
Bis es eine API für Aliase gibt, werde ich das mal so machen (und neben der Sperrung der IP  auf dem Backend auch die so ermittelte IP an Cloudflare zur Sperrung geben (das geht da über die API, da meine Domain über Cloudflare läuft und Fail2Ban eine Action dafür hat). Ist mal besser als nix und dann schauen wir mal, wie die API von OpnSense vorankommt (eine echt suuuper Möglichkeit, da freue ich mich wie ein Schnitzel).

Damit könntest du dir selbst ins Knie schießen weil es störungsanfällig ist, da es auch den String im body blockieren könnte, falls die Regel überhaupt zum Zug kommt (Verbindung ist bereits "ESTABLISHED" und üblicherweise ist bei Netfilter die erste Regel erlaube ESTABLISHED,RELATED).

EDIT: HA, einfach genial - guck mal: https://github.com/fvanroie/PS_OPNsense/wiki/API-Commands
Es gibt eine API für HAProxy. Also werde ich eine IP SRC = Condition mit Regel http deny machen und versuchen, die src über die API mit Fail2Ban zu füttern ;-) Ich hoffe ich finde mal demnächst die Zeit dafür. Jetzt muss aber erstmal dieser X-header-for her 

Könnte zu einem Last-Problem werden, da der HAProxy das nicht machen sollte - aus Performancegründen sollte der nur weiterleiten

[docb]

Hm, meine Träume platzen wie Seifenblasen ;-)
Aber nachdem ich nie ein Performance-Problem haben werde, weil nur zwei APIs mit Basic Auth über den HAProxy laufen und das ganze noch dazu auf einem aktuellen Xeon betrieben wird, sollte das klappen. Ich bin ja nur so ein überambitionierter und it-affiner Heimanwender 
Dann frage ich mal den @freanki nach dem X-Header...

[docb]

Wie finde ich denn denn @freanki... im Search for Members kommt mit und ohne @ am Anfang kein Ergebnis...

[fabian]

Der hier: https://forum.opnsense.org/index.php?action=profile;u=19

BTW: das Tuturial gibt dem HAProxy noch ne Zusatzfunktion: (D)DoS-Verstärker (ist zwar nicht offensichtlich aber ist so -> Retransmissions)

[docb]

Top, danke!

BTW: das Tuturial gibt dem HAProxy noch ne Zusatzfunktion: (D)DoS-Verstärker (ist zwar nicht offensichtlich aber ist so -> Retransmissions)

Ok, großer Bahnhof für mich (nix verstehen) - aber ich werde mich einlesen. Zudem werden ich hier meine Ergebnisse noch posten, das Thema wird doch immer mal wieder angefragt. Wird aber ein bisschen dauern, gerade spiele ich mal mit der API. Genial ;-)

[docb]

Tja, der Fraenki hat leider PMs geblockt  . Hoffentlich stolpert er dann mal hier drüber...

[ChrisH]

Huch, ist mir gar nicht aufgefallen, dass die Option weg ist 
Ich hab mal ein Ticket aufgemacht:
https://github.com/opnsense/plugins/issues/647

[docb]

top, danke!

[ChrisH]

Fehler ist behoben, siehe Github. Entweder den Patch installieren oder einmal von HTTP auf TCP und wieder zurück stellen, dann taucht die Checkbox wieder auf.