fail2ban auf apache2 Webserver

[Piet]

Hallo,

ich nutze einen eigenen Webserver mit Apache2 und Zugang "basic" Der Webserver dient nur zur Visualisierung einer Maschine. Es kann nichts auf oder vom Webserver kopiert werden.

Weiterhin habe ich einen ssh public-Key Zugang.

Mir gefällt fail2ban gut. Was brauche ich für Filter für diese beiden Zugänge.

Eigentlich brauche ich für ssh public-key nichts, aber doppelt ist besser 😉

Für den Apache2 nutze ich aktuell nur den apache-auth Filter.

Wer hat hier Erfahrung, welcher Filter noch wichtig wäre ?

Danke piet

[Mitleser 2.0]

ich nutze einen eigenen Webserver mit Apache2 und Zugang "basic" Der Webserver dient nur zur Visualisierung einer Maschine. Es kann nichts auf oder vom Webserver kopiert werden.

Weiterhin habe ich einen ssh public-Key Zugang.

Mir gefällt fail2ban gut. Was brauche ich für Filter für diese beiden Zugänge.

Eigentlich brauche ich für ssh public-key nichts, aber doppelt ist besser 😉

Für den Apache2 nutze ich aktuell nur den apache-auth Filter.

Wer hat hier Erfahrung, welcher Filter noch wichtig wäre ?

M.E. erstmal gar keinen - ich hab allerdings keine Ahnung ob dein "apache-auth Filter" irgendwas taugt - was auch immer für einer das sein mag.

Guck, dass Du das sauber konfiguriert bekommst und das System aktuell hältst.

Mit allerlei Filter- und Helferlein das System zuballern ist mindestens Zeitverschwendung und im Zweifel sogar kontraproduktiv.

[Piet]

Hallo,

fail2ban ist schon gut.

Bei z.B. 3x Falscheingabe kann die die IP für Stunden sperren. Das ist schon einmal ein einfacher, aber effektiver Schutz für einen Passwortroboter.

[Raketenwilli]

M.E. erstmal gar keinen - ich hab allerdings keine Ahnung ob dein "apache-auth Filter" irgendwas taugt - was auch immer für einer das sein mag.

Zu „dein“:

Bei mir sind das „out of the Box“:

• /etc/fail2ban/filter.d/apache-auth.conf
• /etc/fail2ban/filter.d/apache-common.conf
• /etc/fail2ban/filter.d/common.conf

Nicht vergessen:

• /etc/fail2ban/jail.conf, respektive eine eventuell anzulegende Datei in /etc/fail2ban/jail.d

Nun, so lange diese Dateien nicht angepasst wurden (und danach zum übergroßen Teil) steht der Autor drin…

Und nun zu Piets „fail2ban ist schon gut.“:

Wirklich?

fail2ban hat den Vorteil, ein recht universelles Werkzeug zu sein. Und weil wir hier neulich Links zu lustigen Fotos von faktisch unbenutzbaren Schweizer „Messern“ hatten gebe ich zu denken, dass es auch die Nachteile universeller Werkzeuge hat.

Da man nun den Apache mit

ErrorDocument 401 /pfad/zum/skript

überreden kann, bei Anmeldefehlern z.B. ein PHP-Skript auszuführen (dem dann sogar der benutzte Username und (wohl sogar) das Passwort zur Verfügung stehen), könnte man überlegen, ob man in dem Fall womöglich auch abhängig vom Benutzernamen nur dessen Login sperrt oder, ob man aus Effektivitätsgründen die Sperre dann durch PHP triggern lässt. Also so ähnlich wie hier die IP zeitweise gleich mittels firewall sperrt.

Immerhin muss das PHP-Skript nur loslegen, wenn Benutzername oder Passwort falsch waren - und nicht das gesamte Logfile ständig gefiltert und (teilweise) in eine sqlite-Datenbank geschrieben werden...

Da das aber beides viel und unerhörte Sorgfalt erfordernde Arbeit macht UND weil eine Attacke auf Passwörter SEHR viele Versuche erfordert (insbesondere eine „brut force“-Attacke) könnte es gut sei, dass das hoffentlich ohnehin konfigurierte mod_evasive bereits ausreichend Abhilfe schafft.

[TS]

Hello,

Mir gefällt fail2ban gut. Was brauche ich für Filter für diese beiden Zugänge.

Jeder Eingriff in die Sicherheits-Architektur eines Hosts bedarf einer gesamtheitlichen Betrachtung. Sonst fühlt man sich vielleicht sicher, hat aber enorme Löcher im System

fail2ban benötigt ein sauber eingerichtetes iptables oder nftables.

Es sollte für jeden offenen Port mindestens ein Filter vorhanden sein. Bei HTTP kann aber zusätzlich zum Status 401 auch für den 404 ein Filter sinnvoll sein, das dann aber nicht schon bei drei Fehlversuchen, sondern vielleicht erst nach 20 anschlägt.

Vergessen wird häufig, auch die Ablehnungen in Applikationen im zentralen Log (das, was fail2ban auswertet) mit einer Meldung zu würdigen. Diese sollte dann für alle Applikationen gleichartig aufgebaut sein, damit fail2ban die mit einem zusätzlichen einheitlichen Filter auswerten kann.

Zusätzich zur ersten Stufe von fail2ban gibt es eine zweite (rekursive) Ebene. Das filter recidive. Wenn eine IP innerhalb eines gewissen Zeitrahmens mehrfach gesperrt wurde, greift dieses Filter und sperrt die IP längerfristig und kann auch eine eMail an den Admin absetzen. Da stehen dann z. Zt. meistens die Russen in den erweiterten Informationen, die recidive aus dem DNS beschafft.

Hierzu sollte recidive sowohl das aktive Log, als auch das zugehörige *.log.1 auswerten, damit es auch noch vernünftig auswertet, wenn logrotate zugeschlagen hat. logrotatemuss auch passend eingerichtet werden, damit sowohl die aktive, als auch die bereits zurückgestellte *.log.1-Datei unkomprimiert zur Verfügung stehen. Außerdem sollten die virtuellen Hosts auf Shared-Hosting-Systemen alle eigene Logs haben. Da muss in Logrotate dann der Pfad passend eingerichtet sein. Hier zahlt sich eine einheitliche Grundeinrichtung der Shared Hosts aus!

Zusätzlich ist in Systemen, auf die mehrere Leute Zugriff haben, eine Anmeldekontrolle ganz hilfreich. Immer, wenn sich ein User eine Shell holt, wird eine Meldung abgesetzt.

Trotzdem geschehen immer wieder mysteriöse Dinge, und keiner wars gewesen ;-P

Glück Auf
Tom vom Berg