Ubuntu UFW Regelwerk greift nicht

    Hallo zusammen,

    ich denke ich bin hier besser aufgehoben, sind ja einige Cracks hier :)

    Folgendes:
    Ich erhalte ständig Zugriffsversuche auf ssh aus dem Ausland mit unterschiedlichsten Usernamen. Natürlich sind alle "failed", aber so richtig super ist es nicht, da die Logs zugemüllt werden.
    Ubuntu 24.04 LTS
    UFW aktiviert.
    Einige Regeln manuell eingefügt (deny, allow..)
    Zusätzlich noch via Config Subnetze gesperrt, die immer wieder im Monitoring auftauchen.

    Die Firewall funktioniert an sich. Habe ich bereits getestet.
    Soweit ich weiß muss man in der before.rules EInträge erstellen, die trotz ufw-rule greifen und nicht nach dem "von oben nach unten Prinzip"
    Trotz allem ballert mir "ein Inder" ständig dazwischen (125.17.0.0/24) und ich habe innerhalb von einer Stunde 300 failed logins.
    Daher dachte ich, ich blockiere schlichtweg mal den ganzen Netzbereich. Aber die Meldungen kommen trotzdem noch, also wird nichts geblockt.

    Anbei mal die Konfiguration, wie ich sie erstellt habe.

    Vielleicht hat jemand noch eine Idee, oder erklärt mir meinen Denkfehler :)

    Danke euch!!

    UFW Status active

    To Action From

    -- ------ ----

    22/tcp ALLOW Anywhere

    22 ALLOW Anywhere

    443 ALLOW Anywhere

    Anywhere REJECT 171.110.83.48

    22/tcp DENY 171.110.0.0/24

    Anywhere DENY 125.17.0.0/24

    22/tcp (v6) ALLOW Anywhere (v6)

    22 (v6) ALLOW Anywhere (v6)

    443 (v6) ALLOW Anywhere (v6)

    /etc/ufw/before.rules

    #Block Spammer & Anfragen auf SSH

    -A ufw-before-input -s 171.110.83.0/24 -j DROP

    -A ufw-before-input -s 125.17.0.0/24 -j DROP

    -A ufw-before-input -s 85.209.11.0/24 -j DROP


    GeoLocation.city_name:

    Kottayam

    GeoLocation.country_name:

    India

    GeoLocation.region_name:

    Kerala

    full_log:

    2024-08-02T10:39:46.415121+02:00 v220240_hostTi sshd[24749]: Failed password for root from 125.17.108.33 port 55710 ssh2

    Ist der Syntax der before Rules richtig? Hast du an den Commit gedacht? Das ist ja ein iptables Aufruf, kein UFW Aufruf. Die Regeln sind dann später auch da und werden vor den anderen aufgerufen? Hast du das überprüft?

    Ansonsten sind die Sperr-Regeln im UFW natürlich hinter den allgemeinen Freigaben. Heißt: Das Paket wurde durch die Port 22 Regel schon lange durchgelassen und wird die Sperr-Regel nie erreichen.

    Zitat von ichbins

    Trotz allem ballert mir "ein Inder" ständig dazwischen (125.17.0.0/24) und ich habe innerhalb von einer Stunde 300 failed logins.

    Wäre geoblocking eine Alternative?

    Ich habe das vor kurzem auf einem Sever eingerichtet und dort alles geblockt, außer DE/AT/CH, weil der Server nur von dort erreichbar sein muss.

    Der Effekt war enorm. Totale Ruhe plötzlich. :)

    Wenn du die IP manuell sperren willst, kannst du ein

    Code
    ufw insert 1 deny from 125.17.0.0/24

    ausführen. Das schreibt die DENY Regel direkt an erster Stelle und diese greift dann vor den anderen (ALLOW) Regeln.

    Es scheint auch als würdest du dich auch mal näher mit Fail2ban auseinandersetzen wollen ;) Denn damit kannst du die IPs auch automatisch aussperren, wenn sie zu viele fehlgeschlagene Loginversuche durchführen. Das wäre in diesem Fall vermutlich sehr ratsam und bietet sich immer bei öffentlich erreichbaren SSH Servern an.

    Zitat von frank_m

    Ist der Syntax der before Rules richtig? Hast du an den Commit gedacht? Das ist ja ein iptables Aufruf, kein UFW Aufruf. Die Regeln sind dann später auch da und werden vor den anderen aufgerufen? Hast du das überprüft?

    Ansonsten sind die Sperr-Regeln im UFW natürlich hinter den allgemeinen Freigaben. Heißt: Das Paket wurde durch die Port 22 Regel schon lange durchgelassen und wird die Sperr-Regel nie erreichen.

    Hi und danke Dir!
    Ja, ich habe nun alls zehnmal kontrolliert. Mir dann einen Kaffee geholt. Und dann nochmal alles 10 mal kontrolliert :D
    Kurioserweise steht zu der Source IP nichts im ufw.log.
    Es rattert gerade kräftig durch, spätestens alle drei Minuten eine Reihe von Loginversuchen / BruteForce
    Vielleicht starte ich den Server heute Abend mal durch.

    Wie wäre es, wenn du die Ausgabe der Regeln einfach mal hier reinkopierst in CODE Tags? Dann können wir vielleicht selber sehen, woran es hakt.

    Ich vermute, die before Rules sind gar nicht aktiv, weil die Commit Zeile fehlt.

    Ich glaube ich hab's...
    Kann's sein dass in der before.rule keine Subnetze hinterlegt werden können?
    Setze ich dort eine eigene IP / Host rein, gibts keine Anmeldeversuche mehr.

    Und: Geoblocking habe ich schon rausgesucht. Weiß jemand was zur Performance bzw Last auf Servern? Das ist nämlich gerade eine Sorge meinerseits.

    Zitat von frank_m

    Wie wäre es, wenn du die Ausgabe der Regeln einfach mal hier reinkopierst in CODE Tags? Dann können wir vielleicht selber sehen, woran es hakt.

    Ich vermute, die before Rules sind gar nicht aktiv, weil die Commit Zeile fehlt.


    # rules.before

    #

    # Rules that should be run before the ufw command line added rules. Custom

    # rules should be added to one of these chains:

    # ufw-before-input

    # ufw-before-output

    # ufw-before-forward

    #

    # Don't delete these required lines, otherwise there will be errors

    *filter

    :ufw-before-input - [0:0]

    :ufw-before-output - [0:0]

    :ufw-before-forward - [0:0]

    :ufw-not-local - [0:0]

    # End required lines

    # Block Spammers

    -A ufw-before-input -s 171.110.83.0/24 -j DROP

    -A ufw-before-input -s 125.17.108.33 -j DROP

    -A ufw-before-input -s 85.209.11.0/24 -j DROP

    -A ufw-before-input -s 61.177.172.143/24 -j DROP

    -A ufw-before-input -s 66.108.40.7 -j DROP

    # allow all on loopback

    -A ufw-before-input -i lo -j ACCEPT

    -A ufw-before-output -o lo -j ACCEPT

    # quickly process packets for which we already have a connection

    -A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

    -A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

    -A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

    # drop INVALID packets (logs these in loglevel medium and higher)

    -A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny

    -A ufw-before-input -m conntrack --ctstate INVALID -j DROP

    # ok icmp codes for INPUT

    -A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT

    -A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT

    -A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT

    -A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

    # ok icmp code for FORWARD

    -A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT

    -A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT

    -A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT

    -A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT

    # allow dhcp client to work

    -A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

    #

    # ufw-not-local

    #

    -A ufw-before-input -j ufw-not-local

    # if LOCAL, RETURN

    -A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN

    # if MULTICAST, RETURN

    -A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN

    # if BROADCAST, RETURN

    -A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN

    # all other non-local packets are dropped

    -A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny

    -A ufw-not-local -j DROP

    # allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above

    # is uncommented)

    -A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT

    # allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above

    # is uncommented)

    -A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT

    # don't delete the 'COMMIT' line or these rules won't be processed

    COMMIT

    Grundsätzlich kann man in iptables Regeln Subnetze angeben, wenn der Syntax passt (siehe #2). Also auch in der before.ufw.

    Solche Sperrlisten mache ich allerdings nicht direkt über die Firewall, das ist viel zu ineffizient (meine IPv4 Blockliste hat 200.000 Einträge). Unter iptables mache ich es mit ipset, unter nftables mit Filter Tabellen.

    Zunächst, ohne alle einzeln zu erwähnen: vielen Dank! Ihr habt mich echt weitergebracht :)

    Ich weiß zwar immernoch nicht warum das mit der rules.before in Kombination mit Subnetzen nicht funktioniert, aber ich hab mal spaßeshalber fail2ban installiert.
    Von 07:00 bis 17:30 knapp 1800 failed logins über ssh. Und das bei einem eigentlich frischen Server ohne Public Inhalt.
    Jetzt ist seit 20 Minuten Ruhe.... mal schauen wie gut ich damit arbeiten kann.
    Wie ihr sicher gemerkt habt, kenne ich mich damit ja nicht aus und bin da erst seit gestern Nachmittag dran nachdem ich das SIEM aktiviert habe...

    Was mir aber im Geo-Blocking Zusammenhang einfällt: wie läuft es denn dann mit Systemupdates oder speziellen Dingen wie letsencrypt.
    Den Spaß hab ich bei meiner Nextcloud installiert und achte penibelst auf Updates.
    Und manchmal kommt es dann doch zu Blockierungen obwohl jemand aus DE auf die Cloud zugreift um sich was runterzuladen.

    Und schon sind welche drin:

    tail /var/log/fail2ban.log

    2024-08-02 18:20:20,407 fail2ban.jail [42995]: INFO Initiated 'pyinotify' backend

    2024-08-02 18:20:20,409 fail2ban.filter [42995]: INFO maxLines: 1

    2024-08-02 18:20:20,424 fail2ban.filter [42995]: INFO maxRetry: 5

    2024-08-02 18:20:20,424 fail2ban.filter [42995]: INFO findtime: 600

    2024-08-02 18:20:20,424 fail2ban.actions [42995]: INFO banTime: 600

    2024-08-02 18:20:20,424 fail2ban.filter [42995]: INFO encoding: UTF-8

    2024-08-02 18:20:20,425 fail2ban.filter [42995]: INFO Added logfile: '/var/log/auth.log' (pos = 27371589, hash = b3d65427aa5d61dc003045bedf80a8e29b642470)

    2024-08-02 18:20:20,429 fail2ban.jail [42995]: INFO Jail 'sshd' started

    2024-08-02 18:36:45,188 fail2ban.filter [42995]: INFO [sshd] Found 79.110.62.14 - 2024-08-02 18:36:45

    2024-08-02 18:58:56,776 fail2ban.filter [42995]: INFO [sshd] Found 79.110.62.145 - 2024-08-02 18:58:56

    Zitat von ichbins

    Was mir aber im Geo-Blocking Zusammenhang einfällt: wie läuft es denn dann mit Systemupdates oder speziellen Dingen wie letsencrypt.

    Mit geoip-shell kannst du das Geo-Blocking umsetzen. Du kannst das Script auch ganz einfach nur für Port 22 konfigurieren, damit andere Dienste wie gewohnt weiter funktionieren. Läuft hier, neben fail2ban, auf mittlerweile 7 Servern.

    https://github.com/friendly-bits/geoip-shell

    Geoblocking - netcup Kundenforum
    Kennt jemand eine möglichst einfache Methode für geoblocking in Ubuntu? (EIne die nicht mit aktiven fail2ban und ufw in Konflikt gerät) Einige meiner Server…
    forum.netcup.de

    Noch kurz zu fail2ban: In der Standardeinstellung wird eine erkannte IP nur für 10 Minuten blockiert. Ich stelle immer eine Bannzeit von 24 Stunden bei 3 Fehlversuchen ein.

    Stirbt der Elternprozess, während das Kind noch als Zombie herumsteht, wird das Kind an PID 1 weitergereicht.

    Zitat von ichbins

    Was mir aber im Geo-Blocking Zusammenhang einfällt: wie läuft es denn dann mit Systemupdates oder speziellen Dingen wie letsencrypt

    Das ist eine gute Fage. :thumbup:

    Ich selbst hatte sie mir nicht gestellt und musste dann feststellen, dass ich plötzlich keine Zertifikate mehr erstellen oder erneuern konnte. ^^

    (Letsencrypt gibt leider nicht preis, welche ips es nutzt, so dass man die nicht gezielt ausschließen kann)

    Man kann die automatische Erneuerung aber sicherstellen, indem man pre/post-hook-skripte in die entsprechenden Verzeichnisse in /etc/letsencrypt/renewal-hooks legt, mit welchen geoip-shell ab und wieder abgeschaltet wird.

    Ich habe noch kein geoblocking implementiert, aber die Let's Encrypt Challenge Thematik wurde ja hier schon diskutiert:

    Geoblocking (ff.)

    Nach etwas Recherche bin ich auf diesen Artikel gestoßen:

    Let's Encrypt Geoblocking FAQ

    Dort wird die Umstellung auf die DNS-01 Challenge vorgeschlagen:

    DNS-01 Challenge

    Meine weitere Recherche brachte mich diesbezüglich zu:

    ACME (mit bestätigten netcup-DNS-Challengern)

    einem Skript von coldfix hier

    und einem Dank für ??? an linuxinside hier

    Ganz schön spannend wenn man sich da so einliest 8)