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. `logrotate`muss 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 -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

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. `logrotate`muss 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 Host auf shared Hostings alle eigene Logs haben. Das muss Logrotate dann auch berücksichtigen. 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 -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

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. `Logrotate`muss 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 Host auf shared Hostings alle eigene Logs haben. Das muss Logrotate dann auch berücksichtigen. 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 -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

Hello, > Mir gefällt fail2ban gut. Was brauche ich für Filter für diese beiden Zugänge. `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. `Logrotate`muss 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 Host auf shared Hostings alle eigene Logs haben. Das muss Logrotate dann auch berücksichtigen. 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 -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

Hello, > Mir gefällt fail2ban gut. Was brauche ich für Filter für diese beiden Zugänge. `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. Das muss auch passend eingerichtet werden, damit sowohl die aktive, als auch die bereits zurückgestellte `*.log.1`-Datei unkomprimiert zur Verfügung stehen. 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 -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

Hello, > Mir gefällt fail2ban gut. Was brauche ich für Filter für diese beiden Zugänge. `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. Hiwerzu 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. Das muss auch passend eingerichtet werden, damit sowohl die aktive, als auch die bereits zurückgestellte `*.log.1`-Datei unkomprimiert zur Verfügung stehen. 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 -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

Hello, > Mir gefällt fail2ban gut. Was brauche ich für Filter für diese beiden Zugänge. 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. Hiwerzu 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. Das muss auch passend eingerichtet werden, damit sowohl die aktive, als auch die bereits zurückgestellte `*.log.1`-Datei unkomprimiert zur Verfügung stehen. 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 -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

Hello, > Mir gefällt fail2ban gut. Was brauche ich für Filter für diese beiden Zugänge. 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 einheitlich 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. Hiwerzu 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. Das muss auch passend eingerichtet werden, damit sowohl die aktive, als auch die bereits zurückgestellte `*.log.1`-Datei unkomprimiert zur Verfügung stehen. 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 -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz

Hello, > Mir gefällt fail2ban gut. Was brauche ich für Filter für diese beiden Zugänge. 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 einheitlich 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. 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 -- Es gibt soviel Sonne, nutzen wir sie. [www.Solar-Harz.de](https://www.Solar-Harz.de) S☼nnige Grüße aus dem Oberharz