Hallo,
fail2ban scheint ja eine nette Sache zu sein. Ich habe mir das nun mal angeschaut und eigentlich ist es ja gar nicht so schwer. Aus der Ursprungskonfigurationsdatei eine Kopie gemacht, die angepasst wird, jail.local. Da sind dann einzelne Regeln drin. Ok.
Nun kann ich ganz oben mit bantime und maxretry und findtime wohl Standardwerte definieren, diese aber auch für jede einzelne [Regel] nochmal separat festlegen. Richtig?
In der ersten Regel, [ssh-iptables] steht bei mir in der action bei sendmail-whois der sender. Diesen habe ich einfach mal fail2ban@externe-domain.de gesetzt. In den weiteren Regeln untendrunter ist dieser sender nicht mehr definiert, ich vermute, dass er auch nur einmal festgelegt werden muss und dann nicht mehr? Richtig?
In den folgenden Regeln ist nur noch die Rede von dest, da habe ich auch einfach mal eine hallo@externe-domain.de eingetragen.
Ich habe allerdings bisher noch keine einzige E-Mail erhalten. Die Domains/Mailadressen die ich bei dest und sender eingetragen habe, liegen auf einem anderen Server. Aber das sollte ja nichts zur Sache tun, oder? Komisch.
So, dann kann man schön den Filter angeben, wozu eine gleichnamige Datei mit .conf hinten dran im VZ filter.d liegen muss. Ok.
So habe ich z.B. [ssh-iptables] auf true gestellt, meinen geänderten Port eingetragen und den logpath überprüft. Ok. Dies scheint zu klappen, habe es mal mit Fehlversuchen getestet. Abgesehen von den Info-E-Mails wie oben angesprochen.
Auch [proftpd-iptables] habe ich angepasst, aktiviert und getestet. Auch dies - abgesehen von den E-Mails - scheint zu funktionieren. Nach der festgesetzten Anzahl an Login-Fehlversuchen kommt gar keine Antwort mehr im FTP-Programm vom Server an. Ok.
Nun dachte ich mir, da ich ja auch einige geschützte Verzeichnisse verwende (zwar in Vergangenheit nie größere Mengen an automatisierten Fehlzugriffen auf diese verzeichnet habe), könnte ich ja mittels einer Apache-Regel auch mehrmalige Fehl-Logins aus dem error-log filtern. Dazu gibt es ja bereits einen Filter (apache-auth).
Die Regel nannte sich wohl [apache-tcpwrapper] und die action lief über hostsdeny. Da dies nicht funktioniert hatte, dachte ich, man könnte dies ja auch über iptables machen. So habe ich die Regel in Folgendes geändert:
Dies funktioniert nur begrenzt, und das kann ich mir nicht erklären (fail2ban-Dienst natürlich neugestartet).
Angenommen ich gebe nun beim Aufruf eines gesch. Verzeichnisses im Browser mehrmals falsche oder keine Daten an, die Fehlzugriffe werden geloggt, aber ich werde nicht gebannt.
Probiere ich weiter, oder warte einfach ab, passiert nichts. Starte ich dann irgendwann fail2ban neu, erkennt er es beim Starten und sperrt mich. Aber nicht im Live-Betrieb. Macht ja irgendwie so keinen Sinn. Dies wie gesagt nur bei dem Apache-Error-Log.
Wenn ich fail2ban starte, erkennt er jedoch das logfile:
Dies irritiert mich. Ich wollte z.B. auch noch Plesk (Login) absichern (obwohl ich nicht weiß, ob das nicht eine interne Firewall hat - habe davon gelesen aber konnte in meinem Plesk noch nichts einer solchen möglichen Firewall finden) und noch einen Autoban für zu viele falsche Postfix-Loginversuche.
Ach, dann wollte ich noch mit fail2ban diese ganzen neuerdings unentwegt kommenden Einträge im Log "messages":
Oder ist das komplett falsch? Ich vermute doch, diese Meldungen werden durch dieses hier verursacht:
Danke.
fail2ban scheint ja eine nette Sache zu sein. Ich habe mir das nun mal angeschaut und eigentlich ist es ja gar nicht so schwer. Aus der Ursprungskonfigurationsdatei eine Kopie gemacht, die angepasst wird, jail.local. Da sind dann einzelne Regeln drin. Ok.
Nun kann ich ganz oben mit bantime und maxretry und findtime wohl Standardwerte definieren, diese aber auch für jede einzelne [Regel] nochmal separat festlegen. Richtig?
In der ersten Regel, [ssh-iptables] steht bei mir in der action bei sendmail-whois der sender. Diesen habe ich einfach mal fail2ban@externe-domain.de gesetzt. In den weiteren Regeln untendrunter ist dieser sender nicht mehr definiert, ich vermute, dass er auch nur einmal festgelegt werden muss und dann nicht mehr? Richtig?
In den folgenden Regeln ist nur noch die Rede von dest, da habe ich auch einfach mal eine hallo@externe-domain.de eingetragen.
Ich habe allerdings bisher noch keine einzige E-Mail erhalten. Die Domains/Mailadressen die ich bei dest und sender eingetragen habe, liegen auf einem anderen Server. Aber das sollte ja nichts zur Sache tun, oder? Komisch.
So, dann kann man schön den Filter angeben, wozu eine gleichnamige Datei mit .conf hinten dran im VZ filter.d liegen muss. Ok.
So habe ich z.B. [ssh-iptables] auf true gestellt, meinen geänderten Port eingetragen und den logpath überprüft. Ok. Dies scheint zu klappen, habe es mal mit Fehlversuchen getestet. Abgesehen von den Info-E-Mails wie oben angesprochen.
Auch [proftpd-iptables] habe ich angepasst, aktiviert und getestet. Auch dies - abgesehen von den E-Mails - scheint zu funktionieren. Nach der festgesetzten Anzahl an Login-Fehlversuchen kommt gar keine Antwort mehr im FTP-Programm vom Server an. Ok.
Nun dachte ich mir, da ich ja auch einige geschützte Verzeichnisse verwende (zwar in Vergangenheit nie größere Mengen an automatisierten Fehlzugriffen auf diese verzeichnet habe), könnte ich ja mittels einer Apache-Regel auch mehrmalige Fehl-Logins aus dem error-log filtern. Dazu gibt es ja bereits einen Filter (apache-auth).
Die Regel nannte sich wohl [apache-tcpwrapper] und die action lief über hostsdeny. Da dies nicht funktioniert hatte, dachte ich, man könnte dies ja auch über iptables machen. So habe ich die Regel in Folgendes geändert:
Code:
[apache-iptables]
enabled = true
filter = apache-auth
action = iptables[name=ApacheError, port=http, protocol=tcp]
sendmail-whois[name=ApacheError, dest=hallo@xxx.de]
logpath = /var/www/vhosts/*/logs/error_log
maxretry = 2
bantime = 180Dies funktioniert nur begrenzt, und das kann ich mir nicht erklären (fail2ban-Dienst natürlich neugestartet).
Angenommen ich gebe nun beim Aufruf eines gesch. Verzeichnisses im Browser mehrmals falsche oder keine Daten an, die Fehlzugriffe werden geloggt, aber ich werde nicht gebannt.
Probiere ich weiter, oder warte einfach ab, passiert nichts. Starte ich dann irgendwann fail2ban neu, erkennt er es beim Starten und sperrt mich. Aber nicht im Live-Betrieb. Macht ja irgendwie so keinen Sinn. Dies wie gesagt nur bei dem Apache-Error-Log.
Wenn ich fail2ban starte, erkennt er jedoch das logfile:
Dies irritiert mich. Ich wollte z.B. auch noch Plesk (Login) absichern (obwohl ich nicht weiß, ob das nicht eine interne Firewall hat - habe davon gelesen aber konnte in meinem Plesk noch nichts einer solchen möglichen Firewall finden) und noch einen Autoban für zu viele falsche Postfix-Loginversuche.
Ach, dann wollte ich noch mit fail2ban diese ganzen neuerdings unentwegt kommenden Einträge im Log "messages":
unterbinden. Habe zwar gelesen, dass dies nicht weiter schlimm sei ("Grundrauschen"?), aber trotzdem ist es ja beunruhigend wenn peeeeeermanent sowas im Log auftaucht. Auch meine ich gelesen zu haben, solche messages deaktivieren zu können, aber 1. konnte ich die Einträge in der Datei bei denen die Werte geändert werden sollen nicht finden und 2. könnte man dies doch bestimmt auch mit fail2ban lösen, oder?
Code:
[named-refused-tcp]
enabled = true
filter = named-refused
action = iptables-multiport[name=Named, port="domain,953", protocol=tcp]
sendmail-whois[name=Named, dest=hallo@domain.de]
logpath = /var/log/messages
ignoreip = 168.192.0.1Oder ist das komplett falsch? Ich vermute doch, diese Meldungen werden durch dieses hier verursacht:
Danke.