Page 2 of 2
Re: Datenbank-Fehler nach Crash?
Posted: Thu 4. Apr 2024, 11:25
by tab-kh
Ja, eine Kopie der jail.conf als jail.local und darin de Änderungen zu machen ist zwar möglich, aber eben nicht updatesicher. Deswegen sollte auch in dieser Datei nur das drinstehen, was gegenüber der jail.conf geändert wurde. Das ist zumindest besser im Hinblick auf die Updatesicherheit und wird auch in der Manpage zu jail.conf so empfohlen.
In .local files specify only the settings you would like to change and the rest of the configuration will then come from the corresponding .conf file which is parsed first.
Re: Datenbank-Fehler nach Crash?
Posted: Thu 4. Apr 2024, 11:39
by Ralph
Bei F2B ist leider nichts wirklich Updatesicher bzw. weiterhin kompatibel
Re: Datenbank-Fehler nach Crash?
Posted: Thu 4. Apr 2024, 23:20
by blickgerecht
Hallo zusammen,
vielen Dank erstmal für eure Hilfe!
Ich wollte nochmal zusammenfassen, was ich nun gemacht habe. Vielleicht sucht ja noch jmd. nach einer Lösung für das gleiche Problem.
In der Datei
Code: Select all
/etc/fail2ban/jail.d/keyhelp.local
habe ich alle jails mit aktiviert, mit
enable = true
Ich habe einen neuen Filter erstellt, unter
Code: Select all
/etc/fail2ban/filter.d/apache-dos.conf
mit dem Inhalt
Code: Select all
[Definition]
failregex = ^<HOST>.*"(GET|POST|HEAD).*" (404|444|403|400) .*$
ignoreregex =.*(autodiscover|robots.txt|favicon.ico|login.svg|jpg|png|jpeg|ico|mp3|mp4|css|.well-known)
Dann habe ich eine Zusätzliche Konfiguration erstellt, unter
mit dem Inhalt
Code: Select all
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 <MEINE FESTE IP>
[apache-dos]
enabled = true
port = http,https
filter = apache-dos
logpath = /home/users/*/logs/*/access.log
/var/log/apache2/access.log
bantime = 1800
findtime = 600
maxretry = 5
Anschließend habe ich noch Fail2Ban neugestartet und den Status geprüft:
Code: Select all
service fail2ban restart
service fail2ban status
Im Fail2Ban-Log habe ich das dann noch etwas im Auge behalten:
Durch die Aktivierung von
[kh-recidive] in
/etc/fail2ban/jail.d/keyhelp.local werden die durch die eigene Regel eher kurzfristig gesperrten IPs bei mehrmaliger Aussperrung auch länger gesperrt.
Re: Datenbank-Fehler nach Crash?
Posted: Fri 5. Apr 2024, 09:01
by Ralph
Wow
sehe gerade die SSH Attacken sind derweil auch um das 10fache angestiegen seit letztem Jahr ... maxretry = 1, kein Standardport.
Hab vorhin mal bei einem Kunden VPS reingeschaut ... ca. 1400 SSH Blockings pro Tag, meine Hauptsysteme sind für SSH nur über meine fixe IP, VPN und Backupserver zugänglich, da gibt es also keine Einbruchsversuche.
Ich denke gerade darüber nach bei den Kunden VPS den SSH Port dicht zu machen, 1400 pro 24 Stunden ist schon heftig ... wirkt sich natürlich auch auf die Last der Systeme aus, ungefähr gleich sind auch die sasl auth Versuche.
Irgendwann sind die Systeme am Limit angelangt und das ist Ziel dieser Attacken!
Re: Datenbank-Fehler nach Crash?
Posted: Fri 5. Apr 2024, 09:07
by Jolinar
Ralph wrote: ↑Fri 5. Apr 2024, 09:01
1400 pro 24 Stunden ist schon heftig
1000 Versuche pro Minute wären heftig, aber doch nicht 1 pro Minute...Das ist völlig normales Grundrauschen...
Re: Datenbank-Fehler nach Crash?
Posted: Fri 5. Apr 2024, 09:21
by Jolinar
blickgerecht wrote: ↑Thu 4. Apr 2024, 23:20
Im Fail2Ban-Log habe ich das dann noch etwas im Auge behalten:
Das geht auch in Echtzeit am CLI:
Re: Datenbank-Fehler nach Crash?
Posted: Fri 5. Apr 2024, 09:34
by Ralph
Jolinar wrote: ↑Fri 5. Apr 2024, 09:21
Das geht auch in Echtzeit am CLI:
Korrekt, nur so siehst die Anfragen durchrattern und auch wohin.
Jolinar wrote: ↑Fri 5. Apr 2024, 09:07
1000 Versuche pro Minute wären heftig, aber doch nicht 1 pro Minute...Das ist völlig normales Grundrauschen...
haha, hör mir bloß auf mit Grundrauschen
Na ja, maxretry 1 d.h. es sind keine Wiederholungen von IP Adressen vorhanden, also eher keine Script-Kiddies
Re: Datenbank-Fehler nach Crash?
Posted: Mon 8. Apr 2024, 10:49
by blickgerecht
Hi,
ich hab' noch eine Frage zum Thema und komme selbst nicht auf eine einfache Antwort …
Seit ein paar Tagen beobachte ich die Aussperrungen, die unsere Filter machen. Bisher tauchen immer nur IPs auf, die ich auch in der AbuseIPDB finde. Jetzt ist allerdings auch die IP eines lokalen Internetanbieters aufgetaucht, für die ich auch keine Abuse-Einträge finde.
Gibt es einen einfachen weg, die IP in den Logs zu suchen? Mich würde interessieren, worauf sie versucht hat zuzugreifen, welche Adressen aufgerufen wurden.
In der Datei /var/log/apache2/keyhelp/other_vhosts_access.log sind ja schon viele Zugriffe zusammengefasst, aber dort finde ich nicht immer alle Zugriffe. Einzeln die Dateien /home/users/[USER]/logs/[DOMAIN]/access.log zu durchsuchen scheint mir zwar möglich, aber irgendwie nicht sonderlich effizient.
Re: Datenbank-Fehler nach Crash?
Posted: Mon 8. Apr 2024, 10:59
by Jolinar
blickgerecht wrote: ↑Mon 8. Apr 2024, 10:49
Gibt es einen einfachen weg, die IP in den Logs zu suchen?
Hint:
find,
grep
Re: Datenbank-Fehler nach Crash?
Posted: Mon 8. Apr 2024, 11:05
by Ralph
blickgerecht wrote: ↑Mon 8. Apr 2024, 10:49
Gibt es einen einfachen weg, die IP in den Logs zu suchen? Mich würde interessieren, worauf sie versucht hat zuzugreifen, welche Adressen aufgerufen wurden.
In dem Filter dürfen
NUR die Fake Ziele der Bots vorhanden sein, außer Ziele die bewusst blockiert werden sollen z.b. xmlrpc.php
Also wenn du reguläre Ziele da einbaust die tatsächlich vorhanden sind dann werden diese Zugriffe auch blockiert.
In den apache logs wird das Ziel doch angezeigt ...
oder die IP suchen
Code: Select all
grep "IPadress" /home/users/*/logs/*/access.log
Re: Datenbank-Fehler nach Crash?
Posted: Mon 8. Apr 2024, 11:10
by blickgerecht
Hallo!
Danke schonmal, mit "grep" und genau der Zeile von Ralph ging es wunderbar.
Bei einer Website gab es einen Fehler. Daher das Problem …
Danke euch!
Re: Datenbank-Fehler nach Crash?
Posted: Mon 8. Apr 2024, 13:29
by Ralph
ganz frisch vorhin noch rausgefischt
Code: Select all
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php\.original)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php_backup)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php__)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php_bk)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php\.txt)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.orig)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php_orig)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php-bak)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php\.bkp)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.txt)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php2)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php\.bk)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.bak)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php_bak)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php\.orig)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.old)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php-old)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php\.org)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php\.backup)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php1)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php_)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.phpOLD)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php_old)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.phpe)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php\.old)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php\.save)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php~)
^<HOST> -.*(GET|POST|HEAD).*(/wp-config\.php\.bak)