Basiskonfiguration (Debian 11 + fail2ban / nftables)

  • Nabend,


    ich möchte mich nach langer Zeit wieder mit einem VPS auseinandersetzen um nicht alles zu vergessen. Die Idee ist es eine Basis (nur Grundinstallation inkl. SSH, Fail2Ban und nftables) für eine "Docker Spielwiese" zu schaffen die ich bei Bedarf immer wieder herstellen kann falls was in die Hose geht. Zuerst wird das minimale Debian 11 Image installiert und ab gehts:


    /etc/ssh/sshd_config (edit)

    Code
    Port 721
    PasswordAuthentication no
    PermitRootLogin prohibit-password

    Danach wird ein SSH Keypaar generiert und mittels Passphrase geschützt. (Ich erlaube bewusst das Einloggen per root da ich nicht so Lust drauf habe immer den User wechseln zu müssen und mit Key (inkl. Passphrase) und anderem Port sollte ich doch einigermassen geschützt sein). Jetzt gehts nach der Installation von "fail2ban" und dem kopieren von "jail.conf" nach "jail.local" an die Konfiguration:


    /etc/fail2ban/jail.local (edit)

    /etc/nftables/fail2ban.conf (edit)

    Code
    #!/usr/sbin/nft -f
    
    # Use ip as fail2ban doesn't support ipv6 yet
    table ip fail2ban {
            chain input {
                    # Assign a high priority to reject as fast as possible and avoid more complex rule evaluation
                    type filter hook input priority 100;
            }
    }

    /etc/fail2ban/action.d/nftables-common.local (edit)

    Code
    [Init]
    # Definition of the table used
    nftables_family = ip
    nftables_table  = fail2ban
    
    # Drop packets 
    blocktype       = drop
    
    # Remove nftables prefix. Set names are limited to 15 char so we want them all
    nftables_set_prefix =

    /etc/fail2ban/jail.d/recidive.conf (edit)


    nach einem Reboot kann ich mich auch wie gewünscht nur per Key einloggen und gemäss "fail2ban-client status sshd" werden auch einzelne IPs bereits gebannt. Ist das als Basis so in Ordnung oder gibt es Sachen die ich ändern sollte / muss. Danke fürs Lesen :)

  • mit Key (inkl. Passphrase) und anderem Port sollte ich doch einigermassen geschützt sein

    Nur um da mit einem Missverständnis aufzuräumen - der geänderte Port dient nicht der Sicherheit sondern nur dem Komfort. Vor einem gezielten Angriff auf sshd kann ein geänderter Port nicht schützen. Der geänderte Port sorgt aber dafür, dass die Systemlogs nicht von Scannern zugemüllt werden.

  • Ne, das leuchtet mir schon ein. Mit nem geänderten Port kann ich aber viele Script Kiddies erstmal kalt stellen. Trotzdem danke für den Hinweis!


    Mir gehts mehr darum das die Sachen die ich geändert habe passen und nicht "Türe zu, Fenster auf" darstellen. Habe noch einiges notiert aber die Sachen sind halt auch schon wieder ein 3/4 Jahr alt.

  • Nur um da mit einem Missverständnis aufzuräumen - der geänderte Port dient nicht der Sicherheit sondern nur dem Komfort. Vor einem gezielten Angriff auf sshd kann ein geänderter Port nicht schützen. Der geänderte Port sorgt aber dafür, dass die Systemlogs nicht von Scannern zugemüllt werden.

    Nun, die Gesamtzahl der Angriffe wird durchaus reduziert.

    Bei jedem neuen Server, den ich aufsetzte registriert fail2ban zunächst Zugriffsversuche. Teilweise erhebliche. Nach Ändern des ssh-Ports ist dann auf den meisten Servern Ruhe und zwar dauerhaft.

    Da zeigt, dass die meisten Skripts sich auf Port 22 beschränken. Die schließe damit schon mal alle aus.

    Es ist also nicht nur logfile-Kosmetik.

  • /etc/nftables/fail2ban.conf (edit)

    Code
    #!/usr/sbin/nft -f
    
    # Use ip as fail2ban doesn't support ipv6 yet
    table ip fail2ban {
            chain input {
                    # Assign a high priority to reject as fast as possible and avoid more complex rule evaluation
                    type filter hook input priority 100;
            }
    }


    Ich würde die Datei ganz weg lassen, die Einstellungen werden schon in der /etc/fail2ban/action.d/nftables.conf gesetzt, und dort für ip4 und ip6.

    In der /etc/fail2ban/action.d/nftables-common.local am besten die Tabellendefinition auch weg lassen, sonst überschreibt sie den Wert in der .conf, da wird die Tabelle ja schon auf inet gesetzt.


    Die priority kann ja auch in der .local gesetzt werden, allerdings sollte der Wert negativ sein. Je niedriger der Wert, desto früher ist die Regel dran.
    Die Input Chain hat standardmäßig 0, daher sollte die f2b-chain höchstens -1 haben.


    # nft list ruleset >