Server mit Fail2Ban absichern

  • Danke @Eisen
    Also in die my.cnf eintragen und dann mysqld neustarten wie es beschrieben wird in den FAQ
    MySQL stoppen mit:

    Code
    svc -d /service/mysqld; /usr/local/pd-admin2/bin/mysqladmin -p`cat /opt/pdadmin/etc/mysql_rootpw.conf` shutdown


    und MySQL starten mit:

    Code
    svc -u /service/mysqld


    weiter nix oder ?


    WebTeufel


    versuch mal als Failregex mal dies:

    Code
    failregex = [[]Warning[]] Access denied for user '\w+'@'<HOST>' [(]using password: (YES|NO)[)]


    Bei mir sah das Resultat dann so aus:

    • Offizieller Beitrag

    Würde ich genau so machen bzw. mache ich auch immer, wenn ich das Logging mal bei einem MySQL aktivieren will. Nur bevor Du die my.cnf bearbeitest solltest Du den MySQL stoppen, dann eintragen in der my.cnf und dann wieder starten. Wobei ich es bis jetzt bei pd-admin noch nie probiert habe, aber da es sonst klappt denke ich mal, dass es klappen sollte.

  • Ich greife das Thema mal wieder auf. Leider zwingen einfache DOS Atacken den Server regelmässig in die Knie. Ob Wordpress diese Atacken anzieht oder ob hier einfach nur ins Blaue geschossen wird, entzieht sich meiner Kenntnis. Fakt ist, dass man einfach die Seite massiv "abruft", es entstehen also keine Fehler, nur haufenweise GET Einträge im access_log.


    Gelöst habe ich das wie folgt:


    /etc/fail2ban/jail.conf

    Code
    [http-get-dos]
    enabled = true
    port = http,https
    filter = http-get-dos
    action = iptables-multiport[name=http-get-dos, port="http,https", protocol=tcp]
           sendmail-whois-lines[name=http-get-dos-Banned,dest=root, sender=fail2ban@localhost]
    logpath = /usr/local/pd-admin2/logs/access_log
    maxretry = 500
    findtime = 300


    /etc/fail2ban/filter.d/http-get-dos.conf (Kommentare fürs Forum gelöscht)

    Code
    [Definition]
    before = common.conf
    failregex = ^\S+ <HOST> .*$
    ignoreregex =


    Damit werden nun konsequent IPs ausgesperrt, die mehr als 500 Hits in 300 Sekunden verursachen.

    Das Funktioniert. Ich hab versucht, mit einem Tool eine Homepage runter zu laden, da hat es gegriffen.

    False positives halte ich für Unwahrscheinlich, beobachte das aber erstmal ein paar Tage.


    Was leider nicht geklappt hat, war das einbinden der Umgebungsvariable __hostname aus der common.conf, warum auch immer.

    Deswegen ist diese Zeile wieder auskommentiert.


    Viele Grüße,

    Martin

  • Um einen Post vom Anfang dieses Threads nochmal aufzugreifen: hat es jemand umgesetzt, blocklist.de einzubinden? Zum einen fürs Reporting, zum anderen aber auch zur Nutzung der gesammelten IPs. Ich blick das irgendwie nicht...


    Viele Grüße,

    Martin

    • Offizieller Beitrag

    nitram70

    Deine Ansatz finde ich ziemlich brutal. 300 Hits in 300 Sekunden hat mal schnell mal beisammen. Braucht sich nur jemand durch Seiten mit vielen Bildern klicken.


    Ich würde an Deiner Stelle mal prüfen, auf welche Seiten hier genau los geballert wird bei so einer Attacke und dann dies etwas expliziter sperren. Für mich hat sich der von mir dokumentierte Ansatz für Wordpress sehr bewährt: fail2ban für Wordpress


    Die gesamte Serverlast ging dadurch erheblich zurück - bei bisher null Kundenbeschwerden.

  • Die Lösung mittels fail2ban halte ich auch für ungeeignet. Die "Angriffe" sollten zuerst analysiert werden. Ich konnte in letzter Zeit vermehrt SQL Injection Versuche beobachten. In der Regel werden die Seiten von PHP ausgegeben. Durch die vielen Auftufe werden viele PHP Prozesse erzeugt, wodurch die Last steigt. ImFalle von SQL Injection Versuchen lässt sich dies besser durch mod_security verhindern.


    fail2ban für Wordpress nutze ich auch. Ist auch getestet und funktioniert. Hab es aber nicht weiter beobachtet, um den tatsächlichen Nutzen darzulegen.


    blocklist nutze ich nicht. Ich verwende derzeit abuseipdb.com. Jedoch nur für das Reporting. Die Integration in fail2ban war ziemlich einfach und problemlos.

  • Deine Ansatz finde ich ziemlich brutal. 300 Hits in 300 Sekunden hat mal schnell mal beisammen. Braucht sich nur jemand durch Seiten mit vielen Bildern klicken.

    Da hast Du recht, bisher habe ich einen False Positive. Allerdings komme ich mit der benannten Lösung "fail2ban für Wordpress" nicht weiter, wobei auch dies bei mir läuft, aber nur eben zuviele gescheiterte Login-Versuche abfängt. Das aber sehr effizient.

    Problem hier ist, dass man die Seiten offenbar einfach nur aufruft und dadurch versucht, den Server in die Knie zu zwingen. Ich vermute auch, dass es egal ist, ob es sich um Wordpress handelt oder nicht. Ich hab halt nur Wordpress Hosting auf dem Server.


    Ich würde vielleicht mit den Regeln mal etwas rumspielen, Aufrufe aus dem Verzeichnis wp-includes und wp-content ignorieren, dann hat man sicher "echtere" Seitenaufrufe.

  • Noch ein Nachtrag: Es hat sich gezeigt, dass das abwarten von 500 Hits in 300 Sekunden sehr gut funktioniert. Bisher keine False Positives, aber sicherheitshalber sollte man das einige Zeit überwachen.


    Nun hatte ich heute und gestern Probleme mit Serverlast und festgestellt, dass 80% der Zugriffe aus China kamen, hierbei arbeite ich gerade daran, mittels iptables und ipset ungewünschte Subnetze komplett auszusperren. Das ganze verursacht bei mir enorme Last, hat mit fail2ban aber nicht direkt was zu tun, daher gehe ich hier nicht weiter darauf ein.
    Ich verwende diese Anleitung: https://askubuntu.com/question…block-china-with-iptables


    Wo ich aber aktuell dran bin ist das aussperren von Bots. Ob das die Jobboerse oder sonstige Marketing-Bots sind, eigentlich sollte alles ausser Google draussen bleiben.

    Auch das verursacht nicht unerheblich last und die Summer der Maßnahmen bringen hoffentlich Besserung.


    Hier meine Konfiguration:


    jail.conf

    Code
    [blockbots]
    enabled  = true
    port     = http,https
    filter   = blockbots
    logpath  = /usr/local/pd-admin2/logs/access_log
    maxretry = 2 
    findtime = 600 


    filter.d/blockbots.conf

    Code
    [Definition]
    blockbots = 360Spider|AhrefsBot|AwarioRssBot|Baiduspider|BLEXBot|BuiBui|CCBot|coccoc|crawler|datasift|dotbot|EmailCollector|Exabot|Finderlein|Genieo|Jimdo_Feed_Fetcher|linkdexbot|meanpathbot|Mail.RU_Bot|Mediatoolkitbot|MJ12bot|NetSeer|Pixray|proximic|publiclibraryarchive|Riddler|SemrushBot|SEMrushBot|SentiBot|SeznamBot|SEOkicks|SiteExplorer|Sogou|SurveyBot|TrackBack|trendiction|Uptimebot|WebEMailExtrac|webmeup|Yandex
    failregex = ^\S+ <HOST>.*(?:%(blockbots)s).*$
    ignoreregex =
  • habe habe ein Problem mit paar filtern die hier vorgestellt wurden...


    das steht in den logs


    das sind die einträge aus der jail

    kann es daran liegen das sich, wie ich festgestellt habe, die log einträge von f2b geändert haben


    habe Fail2Ban v0.9.6

    auf debian stretch

  • danke schön für den Hinweis

    da ich es nicht geschafft habe dort vorgeschlagene Änderungen bei mir einzuarbeiten, habe ich einfach mal aus den backports die gefixte version installiert, 0.10.2

    jetzt scheint es wieder wie gewohnt funktionieren

  • Guten morgen,

    ich bastele mal wieder mit fail2ban und versuche, "ungültige" smtp Loginversuche zu unterbinden.
    Dazu habe ich eine Regel aus dem ersten Beitrag dieses Threads angepasst:


    pdqmail-smtp.conf

    Code
    failregex = User [a-zA-Z0-9@._-]+: smtp-auth login failed from <HOST> \(no such user\)
                User [a-zA-Z0-9@._-]+: smtp-auth login failed from <HOST> \(wrong password: \w.+, \w.+\)$
                User [a-zA-Z0-9@._-]+: login failure from <HOST>$


    jail.conf

    Code
    [pdqmail-smtpSd]
    enabled = true
    port    = 587 
    filter  = pdqmail-smtp
    action  = iptables[name=smtpSd-Banned, port=587, protocol=tcp]
    logpath = /var/log/syslog
    findtime  = 600 
    maxretry = 3 
    bantime = 10800


    Das funktioniert soweit prima, die IPs werden geblockt. Die Loginversuche hören aber nicht auf, im Logfile häufen sich die Einträge in der Art:

    Code
    WARNING [pdqmail-smtpSd] 45.13.39.53 already banned


    iptables Ausgabe für die oben genannte IP:

    Code
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
    fail2ban-smtpSd-Banned  tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:587
    
    Chain fail2ban-smtpSd-Banned (1 references)
    target     prot opt source               destination         
    DROP       all  --  45.13.39.53          0.0.0.0/0 


    Was hab ich da falsch gemacht? Stimmen "port" und "protocol"?

  • smtp-auth ist nicht nur auf Port 587 möglich, sondern auch auf Port 25 und 465. Ich würde daher IPs direkt für alle drei Ports blocken.


    Auch kann es sein, dass nach einem Blocking wine bestehende Verbindung nicht sofort beendet wird. So lange können dann noch Versuche gestartet werden.

  • Danke, das hats gebracht. Was man wissen muss ist, dass man dann den action Befehl etwas anpassen muss.

    Folgende zwei Zeilen, vorher und nachher.

    Code
    action = iptables[name=smtpSd-Banned, port=587, protocol=tcp]
    action = iptables-multiport[name=smtpSd-Banned, port="25,465,587", protocol=tcp]


    Vielen Dank!

  • Auf ein neues!

    Ich stelle fest, dass 90% aller "ausporobierenden" Logins aus immer jeweils einem /24 Subnetz erfolgen, die IPs rotieren über bis zu 10 Adressen. Das Netz zu blocken ist dann eher eine leichte Übung, einfach /24 dahinter und gut.


    Aber wie könnte man realisieren, dass diese überhaupt als zusammenhängend erkannt und zu einem "Angriff" gebündelt von fail2ban gezählt werden?

  • Ich hatte eine ganze Zeit lang verschiedene Stufen für z.b. den SSH Dienst. Vor einiger Zeit habe ich dann die Optionen


    bantime.increment
    bantime.multipliers


    Für mich entdeckt. Damit habe ich nun für alle Dienste eine gesetzt Standard bantime, welche sich bei häufigeren Treffern erhöht. Wie sich dies langfristig macht, muss sich noch zeigen.