Skydda SSH med Fail2ban i Debian 11

Introduktion

Fail2Ban är ett verktyg som skyddar Linux-baserade maskiner mot olika typer av attacker och skadligt beteende. Verktyget kan skydda ett flertal tjänster som till exempel SSH, HTTP och FTP.

Fail2ban övervakar loggfiler i realtid och letar efter tecken på automatiserade attacker mot din server. Verktyget ger ett effektivt skydd mot brute force-attacker genom att automatiskt svartlista angriparnas IP-adresser i brandväggen.

I den här guiden får du exempel på några av Fail2bans mest grundläggande funktioner och vi visar hur du konfigurerar verktyget att skydda SSH på en virtuell server som kör Debian 11 i GleSYS Cloud.

Förberedelser

• Skapa en Cloud VPS med Debian 11 som operativsystem. Tillvägagångssättet är detsamma i Ubuntu 22.04 – bortsett från den sista delen som handlar om omstart av brandväggen.
• Du behöver tillgång till en användare med root-rättigheter. Logga in som root eller använd sudo-prefixet för din egen användare.

1. Installera Fail2ban

Börja med att uppdatera paketlistorna i operativsystemet:

apt update

Installera sedan Fail2ban:

apt install fail2ban

När installationen är klar måste vi aktivera Fail2ban så att det startas automatiskt när servern startas om:

systemctl enable fail2ban.service

2. Konfigurera Fail2ban

Som standard ligger inställningarna i /etc/fail2ban/jail.conf, men denna filen skrivs över vid eventuell uppgradering av Fail2ban. Vi skapar därför istället en ny fil som heter jail.local. Inställningar vi gör i jail.local kommer ha företräde över jail.conf.

Skapa och öppna filen genom att använda följande kommando:

nano /etc/fail2ban/jail.local

Klistra in nedanstående stycke och ersätt <DIN IP-ADRESS> med din dators publika IP-adress. Detta förhindrar att du tillfälligt låser dig själv ute. Fail2ban har stöd för både IPv4- och IPv6-adresser.

[sshd]
ignoreip = 127.0.0.1 <DIN IP-ADRESS>
enabled = true
port = 22
filter = sshd
banaction = nftables-allports
logpath = /var/log/auth.log
maxretry = 3
bantime  = 600
findtime = 600

Dessa inställningar ger dig ett bra grundläggande skydd men du kan konfigurera den efter dina behov. Nedan ser du vad de olika inställningarna betyder:

ignoreip = 127.0.0.1 <DIN IP-ADRESS>

De IP-adresser som pekas ut med ignoreip kommer inte att kunna bli spärrade av Fail2ban. Byt ut <DIN IP-ADRESS> mot din egen IP-adress för att undvika att bli temporärt utelåst.

banaction = nftables-allports

banaction anger hur angriparens IP-adress ska blockeras. Som standard använder Fail2ban iptables, men sedan Debian 11 har nftables ersatt iptables. Med nftables-allports blockeras serverns alla portar för angriparen. Vill du istället enbart blockera SSH-porten för angriparen byter du ut banaction = nftables-allports mot banaction = nftables.

maxretry = 3

maxretry anger hur många inloggningsförsök som får göras innan en IP-adress blir svartlistad inom findtime.

bantime  = 600

bantime anger den totala tiden i sekunder som en IP-adress är svartlistad. Standardvärdet 600 är satt för att svartlista en IP-adress i 10 minuter.

findtime = 600

findtime anger inom vilket tidsintervall som antalet maxretry får ske innan IP-adressen svartlistas.

Efter att du har anpassat konfigurationen efter dina behov sparar du och stänger filen. Därefter startar du om Fail2ban genom att skriva:

systemctl restart fail2ban

3. Testa Fail2ban med SSH-anslutning

I filen /var/log/auth.log loggas inloggningsförsök via SSH. Om Fail2ban upptäcker upprepade inloggningsförsök över SSH från en och samma IP-adress kommer den till slut – enligt dina inställningar ovan – att svartlista IP-adressen i brandväggen.

Du kan testa detta genom att ansluta till din server upprepade gånger med SSH med fel inloggningsuppgifter från en annan dator.

Titta sedan i Fail2bans loggfil genom att skriva:

cat /var/log/fail2ban.log 

Nu kommer du få ett resultat liknande det här:

2023-01-27 11:02:44,128 fail2ban.filter     [3066]: INFO    [sshd] Found 192.0.2.56 - 2023-01-27 11:02:44
2023-01-27 11:02:46,144 fail2ban.filter     [3066]: INFO    [sshd] Found 192.0.2.56 - 2023-01-27 11:02:46
2023-01-27 11:02:46,876 fail2ban.filter     [3066]: INFO    [sshd] Found 192.0.2.56 - 2023-01-27 11:02:46
2023-01-27 11:02:47,472 fail2ban.actions    [3066]: NOTICE  [sshd] Ban 192.0.2.56

Här har Fail2ban loggat tre inloggningsförsök från IP-adressen 192.0.2.56 som den sedan har blockerat i brandväggen.

Du kan kontrollera att Fail2ban har lagt till brandväggsreglerna genom att skriva nft list table inet f2b-table

Du bör nu få något liknande det här:

table inet f2b-table {
        set addr-set-sshd {
                type ipv4_addr
                elements = { 192.0.2.56 }
        }

        chain f2b-chain {
                type filter hook input priority filter - 1; policy accept;
                meta l4proto { tcp } ip saddr @addr-set-sshd reject
        }
}

Fail2ban har här skapat en brandväggsregel som svartlistar all inkommande trafik från 192.0.2.56. Om du har bytt ut banaction = nftables-allports mot banaction = nftables i konfigurationsfilen /etc/fail2ban/jail.local kommer istället endast port 22 att blockeras.

Tänk på att Fail2ban är tänkt att fungera tillsammans med övriga säkerhetsåtgärder på din server. Det ska inte användas istället för brandväggsregler.

4. Omstart av Fail2ban tillsammans med brandväggen i Debian 11 (Frivilligt)

Om vi startar om brandväggen nu med systemctl restart nftables kommer de svartlistade IP-adresserna försvinna. Detta beror på att det är Fail2ban som lägger till reglerna i brandväggen. Reglerna sparas inte i själva brandväggen.

För att komma runt detta lägger vi till ett beroende i systemd-tjänsten för Fail2ban. Vi talar då om för systemd att brandväggen nftables och Fail2ban hör ihop, och att en omstart av brandväggen även ska trigga en omstart av Fail2ban. Eftersom Fail2ban då startas om efter att brandväggen har startas kommer reglerna att läggas till på nytt.

Skriv kommandot:

systemctl edit fail2ban.service

Nu öppnas standardeditorn, mest troligen nano. I filen finns redan en mängd kommentarer. Redigera filen så att de första elva raderna ser ut som nedan (raderna som börjar ### finns redan i filen):

### Editing /etc/systemd/system/fail2ban.service.d/override.conf  
### Anything between here and the comment below will become the new contents of the file  

[Unit]
Requires=nftables.service
PartOf=nftables.service

[Install]
WantedBy=multi-user.target nftables.service

### Lines below this comment will be discarded

Spara filen och avsluta editorn.

Nu måste vi starta om systemd-demonen så att beroendena uppdateras. Det gör vi med:

systemctl daemon-reload

Nu kan vi starta om brandväggen utan att reglerna för de svartlistade IP-adresserna försvinner.

5. Sammanfattning

Fail2ban är ett bra sätt att skydda alla typer av tjänster som använder någon form av autentsiering. Nu är du förhoppningsvis mer redo att konfigurera och använda Fail2ban för att skydda just de tjänster som du använder.