9
Mit iptables auf 2. Webserver umleiten
Guten Morgen
Ich betreibe einige Webanwendungen, die ich über Fail2Ban abgesichert habe, nach dem mir einge hundert erfolglose Loginversuche von gleichen IPs in den Logfiles aufgefallen sind.
Gegenwärtig erlaube ich 10 Versuche und sperre dann für 30 Minuten. Wenn ich jetzt aber in mein Ticketsystem gucke, dann scheint das nicht meine beste Idee gewesen zu sein. Zumindest habe ich heute morgen gut 200 Meldungen vorgefunden, dass der Server tot sei. Ist er natürlich nicht aber Fail2Ban ist gut am arbeiten
Die User versuchen sich mehrfach an ihre username/password Kombination zu "erinnern“ und irgend wann sperrt Fail2Ban die IP. Für die Anwender sieht es dann aus als wäre die Seite tot. Ich hatte mir vorher gedacht, dass das sowieso nie bei nem Anwender passiert und Scripte will ich ja hart aussperren. Aber anscheinend sind mehr als 10 Versuche wohl doch "normal“.
Jetzt möchte ich einen zweiten Webserver (nginx) mit einer statischen Statusseite ("Du bist zu blöd dich an dein Passwort zu erinnern! Ich gebe dir 30 Minuten Bedenkzeit.“) auf dem Server installieren und diesen auf localhost:8443 oder so laufen lassen und über iptables alle Anfragen von der gesperrten IP an diesen Webserver „umleiten“.
Irgend wie habe ich Google anscheinend noch nicht mit den passenden Suchwörtern gefüttert, denn ich finde einfach keine Anleitung, wie man das am besten mit iptables umsetzt. Kann mir hier jemand einen Tipp geben?
Vielen Dank!
Ich betreibe einige Webanwendungen, die ich über Fail2Ban abgesichert habe, nach dem mir einge hundert erfolglose Loginversuche von gleichen IPs in den Logfiles aufgefallen sind.
Gegenwärtig erlaube ich 10 Versuche und sperre dann für 30 Minuten. Wenn ich jetzt aber in mein Ticketsystem gucke, dann scheint das nicht meine beste Idee gewesen zu sein. Zumindest habe ich heute morgen gut 200 Meldungen vorgefunden, dass der Server tot sei. Ist er natürlich nicht aber Fail2Ban ist gut am arbeiten
Die User versuchen sich mehrfach an ihre username/password Kombination zu "erinnern“ und irgend wann sperrt Fail2Ban die IP. Für die Anwender sieht es dann aus als wäre die Seite tot. Ich hatte mir vorher gedacht, dass das sowieso nie bei nem Anwender passiert und Scripte will ich ja hart aussperren. Aber anscheinend sind mehr als 10 Versuche wohl doch "normal“.
Jetzt möchte ich einen zweiten Webserver (nginx) mit einer statischen Statusseite ("Du bist zu blöd dich an dein Passwort zu erinnern! Ich gebe dir 30 Minuten Bedenkzeit.“) auf dem Server installieren und diesen auf localhost:8443 oder so laufen lassen und über iptables alle Anfragen von der gesperrten IP an diesen Webserver „umleiten“.
Irgend wie habe ich Google anscheinend noch nicht mit den passenden Suchwörtern gefüttert, denn ich finde einfach keine Anleitung, wie man das am besten mit iptables umsetzt. Kann mir hier jemand einen Tipp geben?
Vielen Dank!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 386761
Url: https://administrator.de/forum/mit-iptables-auf-2-webserver-umleiten-386761.html
Ausgedruckt am: 23.12.2024 um 00:12 Uhr
9 Kommentare
Neuester Kommentar
Hallo TrialAndError,
warum machst du das per Fail2Ban? (wenn ich dich richtig verstehe geht es um eine Webanwendung?) Programmier das in die Webanwendung rein und leite dann von dort weiter...
VG
warum machst du das per Fail2Ban? (wenn ich dich richtig verstehe geht es um eine Webanwendung?) Programmier das in die Webanwendung rein und leite dann von dort weiter...
VG
Hallo certifiedit.net,
die Idee ist mir ehrlich gesagt bisher nicht gekommen. Allerdings stelle ich mir das ziemlich umständlich vor. Ich gebe das mal an den Entwickler weiter.
Allerdings gibt es auch Anwendungen, die nur von uns betrieben werden. Spätestens bei denen bin ich dann wieder auf Fail2Ban angewiesen.
die Idee ist mir ehrlich gesagt bisher nicht gekommen. Allerdings stelle ich mir das ziemlich umständlich vor. Ich gebe das mal an den Entwickler weiter.
Allerdings gibt es auch Anwendungen, die nur von uns betrieben werden. Spätestens bei denen bin ich dann wieder auf Fail2Ban angewiesen.
Zitat von @TrialAndError:
Hallo certifiedit.net,
die Idee ist mir ehrlich gesagt bisher nicht gekommen. Allerdings stelle ich mir das ziemlich umständlich vor. Ich gebe das mal an den Entwickler weiter.
Wieso? Das sind einfache Zähler in einer Datenbank, die sich pro Fehlversuch und IP hoch zählen lassen.Hallo certifiedit.net,
die Idee ist mir ehrlich gesagt bisher nicht gekommen. Allerdings stelle ich mir das ziemlich umständlich vor. Ich gebe das mal an den Entwickler weiter.
Findest du es besser eine ganze IP, hinter der sich übrigens mehrere User befinden können, zu sperren und damit potenziell weitere User aus zu sperren die sich hinter dieser IP befinden, aber selbst Ihr Passwort nicht falsch eingegeben haben?! Siehst du das ist leider nicht zu Ende gedacht.
Trial and Error eben...
Siehst du das ist leider nicht zu Ende gedacht.
Eigentlich ist es schon das Ziel die gesamte IP zu sperren. Auch wenn es über die Webanendung laufen würde, würde ich es nicht anders realisieren wollen. Sonst tippt einfach irgend ein Troll 10x das falsche PW ein und ein Mitarbeiter ist gesperrt. Außerdem scheinen sich die Anwender ja nicht mal bei dem username sicher zu sein. Soll ich die Sperrseite also von nem cookie abhängig machen?Wie gesagt es handelt sich um verschiedene Webanwendungen, von denen wir nur eine im Haus entwickeln.
Ich habe gerade noch mal in der Doku einer gekauften Lösung nachgeguckt. Laut best practice des Herstellers ist Fail2Ban die empfohlene Lösung. Selbst wenn ich jetzt sage ich hätte es gerne anders, dann wird der Hersteller eben die Hand aufhalten. Hilft mir also auch net weiter ;)
Jetzt könnte man darüber streiten ob es so oder so besser ist. Aber es hilft mir nicht wirklich bei meinem Problem weiter. Ziel ist es über Fail2Ban auf einen anderen Server "umzuleiten".
Aber dennoch danke für den Tipp Loginversuche zusätzlich in den Anwendungen auszuwerten.
Trial and Error eben...
Ich habe bisher noch keinen Admin kennen gelernt, der nicht früher oder Später nach diesem Motto arbeitet. Genau dafür gibt es Testumgebungen.
Eigentlich ist es schon das Ziel die gesamte IP zu sperren.
Sperrst dann also auch potenziell unbeteiligten den Zugang, Stichwort NAT.Sonst tippt einfach irgend ein Troll 10x das falsche PW ein und ein Mitarbeiter ist gesperrt.
Das Problem hast du immer wenn man mit generischen leicht zu erratenden Usernamen hantiert.Macht ne 2Faktor Auth draus dann wird es ein Schuh.
Wenn du es partou nicht lassen kannst IPTables mit einer dynamsichen IP-List und redirect ist dein Stichwort.
https://www.debuntu.org/how-to-redirecting-network-traffic-to-a-new-ip-u ...
Ich habe bisher noch keinen Admin kennen gelernt, der nicht früher oder Später nach diesem Motto arbeitet.
Leider gibt es zu viele davon.Genau dafür gibt es Testumgebungen.
Und Handbücher .
und Anfragemöglichkeiten beim Hersteller - wenn er schon fail2ban empfiehlt
Moin,
dein Ansatz mit Fail2Ban ist trotzdem leider blöd. Du sperrst nach 10 Versuchen die IP, ja? Was machst du denn bei Firmen-Accounts? 10 User vertippen sich einmal, dank Nat haben aber alle dieselbe IP -> blöd gelaufen.... Egal ob du die jetzt alle zur Sperrseite schickst oder einfach blockst, jetzt fliegen dir vermutlich sogar die aktiven Sessions weg.
Was du machen kannst (und was programmtechnisch auch max. ne Aufgabe für nen Azubi is der 30 min Zeit hat):
a) Login-Counter, nach 10 Versuchen sperrst du den Account für 30 Min (das geht mit ner Datenbank recht einfach, 3 Felder max.)
b) Die ersten 3 Versuche gehen normal, danach nach jedem weiteren Versuch eine Warteschleife einbauen - immer verdoppeln mehr (d.h. nach dem 3ten Versuch 10 Sek warten, nach dem 4ten 20 sek, nach dem 5 40 sek,....)
c) Deine Web-Anwendung schreibt in die Log-File (je nach Programmiersprache) eine Nachricht das ein falscher Username genutzt wurde: Hier kannst du dann nach x Versucen die IP sperren - da die Usernamen eher selten vergessen werden und natürlich nen Bot probieren würde...
Aber nur dein F2B wird dich halt nicht wirklich weiterbringen - da jedes System hinter nem NAT oder Proxy damit auchh schnell in Probleme läuft. Und zumindest noch haben wir meistens IPv4 mit NAT im Einsatz....
dein Ansatz mit Fail2Ban ist trotzdem leider blöd. Du sperrst nach 10 Versuchen die IP, ja? Was machst du denn bei Firmen-Accounts? 10 User vertippen sich einmal, dank Nat haben aber alle dieselbe IP -> blöd gelaufen.... Egal ob du die jetzt alle zur Sperrseite schickst oder einfach blockst, jetzt fliegen dir vermutlich sogar die aktiven Sessions weg.
Was du machen kannst (und was programmtechnisch auch max. ne Aufgabe für nen Azubi is der 30 min Zeit hat):
a) Login-Counter, nach 10 Versuchen sperrst du den Account für 30 Min (das geht mit ner Datenbank recht einfach, 3 Felder max.)
b) Die ersten 3 Versuche gehen normal, danach nach jedem weiteren Versuch eine Warteschleife einbauen - immer verdoppeln mehr (d.h. nach dem 3ten Versuch 10 Sek warten, nach dem 4ten 20 sek, nach dem 5 40 sek,....)
c) Deine Web-Anwendung schreibt in die Log-File (je nach Programmiersprache) eine Nachricht das ein falscher Username genutzt wurde: Hier kannst du dann nach x Versucen die IP sperren - da die Usernamen eher selten vergessen werden und natürlich nen Bot probieren würde...
Aber nur dein F2B wird dich halt nicht wirklich weiterbringen - da jedes System hinter nem NAT oder Proxy damit auchh schnell in Probleme läuft. Und zumindest noch haben wir meistens IPv4 mit NAT im Einsatz....
