Klik hier voor informatie over de wijziging in de levering van diensten en ondersteuning.

Vaultwarden hosting en beveiligen

kluis

Introductie

Wachtwoorden opslaan in een Excel-sheet is onveilig en niet meer van deze tijd. Gelukkig zijn er een aantal goede password managers op de markt - waarmee wachtwoorden veilig opgeslagen en beheerd kunnen worden. Wanneer wachtwoorden lokaal op worden geslagen - bijvoorbeeld op een eigen server - dan is het verstandig om de toegang goed te beveiligen. In dit artikel wordt beschreven hoe de web interface van Vaultwarden beschikbaar gemaakt en afgeschermd kan worden.

Bitwarden vs Vaultwarden

Persoonlijk vind ik Bitwarden één van de betere password managers. Voor het zelf hosten van Bitwarden kies ik al snel voor het alternatief Vaultwarden.

Vaultwarden is een Bitwarden compatible server geschreven in Rust. Vaultwarden vraagt minder systeembronnen dan Bitwarden. Vaultwarden ondersteund een groot aantal features - maar een aantal features die Bitwarden wel biedt zijn momenteel niet beschikbaar onder Vaultwarden. Op https://github.com/dani-garcia/vaultwarden/wiki staan de features - en de ontbrekende features - opgesomd.

Docker vs packages

Standaard draait Vaultwarden in Docker. Ik heb er voor gekozen om de Vaultwarden packages voor Arch Linux te gebruiken (dus buiten Docker om). Dat is een uitzondering - maar het heeft mijn persoonlijke voorkeur om Vaultwarden op deze manier te draaien.

Reverse proxy en TLS (SSL)

Omdat Vaultwarden standaard op TCP poort 8000 draait - en het netwerkverkeer niet automagisch wordt versleuteld - is er iets nodig wat Vaultwarden op een veilige manier beschikbaar maakt. Dat wordt een reverse proxy genoemd. Er zijn oplossingen met Nginx en Apache of Traefik - maar ik zocht een oplossing wat ook zorgt voor de versleuteling (middels een SSL certificaat). Ik kwam uit bij Caddy.

Caddy-Logo

Caddy is een opensource web server met automatische SSL. Caddy gebruik ik als reverse proxy voor Vaultwarden onder Arch Linux. Hiermee wordt http verkeer over poort 8000 op localhost vertaald (proxied) naar https verkeer over poort 443.

Samenvatting oplossing

In het kort gaat het om een oplossing die bestaat uit:
Hypervisor — Container — Linux — Caddy — Vaultwarden

Als hypervisor gebruik ik Proxmox. Dit is de hypervisor waar de virtuele machines en Linux containers op draaien. In één van de containers draait Arch Linux. Onder Arch Linux zijn onder andere Caddy en Vaultwarden geïnstalleerd.

vaultwarden-screenshot De gebruiker kan door middel van een webbrowser de web interface van Vaultwarden gebruiken. Het is van belang dat de omgeving beveiligd wordt. Uiteraard moeten gebruikers zich authenticeren met een gebruikersnaam + wachtwood + token. Maar het is verstandig om de toegang tot de web interface ook te beperken. In deze post wordt ingegaan op het beveiligen van de toegang tot de web interface van Vaultwarden door gebruik te maken van de functionaliteit van Caddy (hosts beperken) en van Fail2Ban (verdachte hosts blokkeren).

Zoals aangegeven wordt Caddy ingezet als reverse proxy voor Vaultwarden. Zonder een reverse proxy is het praktisch nut van Vaultwarden nul - er is versleuteling - via https - nodig.
Caddy zorgt voor een certificaat - poort 443 staat daarvoor open.

Webtoegang beperken

De toegang kan beperkt worden met de opties die Caddy reeds biedt - en aangevuld worden met behulp van Fail2Ban.

Caddy

De toegang tot Vaultwarden - via Caddy - heb ik reeds beperkt met een lijst met toegestane hosts. Ik heb deze beperking in de Caddy configuratie van de onderliggende website gezet.

Wanneer ik een fout maak in de beperking (lees: afscherming) - dan kan er een probleem ontstaan (ongeautoriseerde toegang). Daarnaast kan het zijn dat de beperking op een gegeven moment wordt verruimd (bijvoorbeeld tot Nederland). Kortom: om risico op ongeautoriseerde toegang te verkleinen heb ik Fail2Ban toegevoegd aan de installatie. Met Fail2Ban kan ik verdachte hosts (tijdelijk of permanent) blokkeren. Bijvoorbeeld wanneer er (een x aantal keren) een http error code 400, 401, 403 of 404 gegenereerd wordt door een bepaalde host.

Fail2Ban

Fail2Ban Fail2ban werkt door logbestanden (zoals bijvoorbeeld /var/log/auth.log, /var/log/apache/access.log, et cetera) te controleren op geselecteerde items en voert op basis daarvan scripts uit. Meestal wordt dit gebruikt om verdachte IP-adressen te blokkeren die mogelijk behoren tot hosts die proberen de systeembeveiliging te doorbreken. Fail2Ban kan elk host-IP-adres blokkeren dat te veel inlogpogingen doet of andere ongewenste acties uitvoert binnen een door de beheerder bepaald tijdsbestek.

Configuratie

In de volgende paragrafen ga ik in op de configuratie van Caddy. Er zijn een aantal aanpassingen nodig om de log van Caddy door Fail2ban te laten filteren. Vervolgens ga ik in op de configuratie van Fail2Ban.

Caddy

Configuratiebestanden

Er zijn twee configuratiebestanden die van primair belang zijn: /etc/caddy/Caddyfile en /etc/caddy/config.d/v1.domeinnaam.ext (de echte domeinnaam is vervangen door domeinnaam.ext omdat ik de echte domeinnaam niet mag vermelden). Er is nog een derde configuratiebestand /etc/caddy/caddy_security.conf - maar die wordt beschreven in de paragraaf over de configuratie van Fail2Ban.

In /etc/caddy/Caddyfile staat de algemene configuratie.

# nano /etc/caddy/Caddyfile

# The Caddyfile is an easy way to configure your Caddy web server.
#
# https://caddyserver.com/docs/caddyfile
#
# The configuration below serves a welcome page over HTTP on port 80.
# To use your own domain name (with automatic HTTPS), first make
# sure your domain's A/AAAA DNS records are properly pointed to
# this machine's public IP, then replace the line below with your
# domain name.
#
# https://caddyserver.com/docs/caddyfile/concepts#addresses

{
        # Restrict the admin interface to a local unix file socket whose directory
        # is restricted to caddy:caddy. By default the TCP socket allows arbitrary
        # modification for any process and user that has access to the local
        # interface. If admin over TCP is turned on one should make sure
        # implications are well understood.
          admin "unix//run/caddy/admin.socket"
}

# Import additional caddy config files in /etc/caddy/conf.d/
  import /etc/caddy/conf.d/*

Met de laatste regel worden de configuratiebestanden onder conf.d geïmporteerd.

In /etc/caddy/config.d/v1.domeinnaam.ext staat de configuratie voor Vaultwarden.

# nano /etc/caddy/config.d/v1.domeinnaam.ext

v1.domeinnaam.ext {

# General settings
  encode gzip
  file_server

# Security
  import /etc/caddy/caddy_security.conf

# Allowed hosts
  @allowed {
    remote_ip forwarded 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 100.64.0.0/10
    }
    handle @allowed {
      reverse_proxy * localhost:8000
    }
    respond "Access denied - 403" 403

# Logging
  log {

    format transform "{common_log}"

    # access logs
      output file /var/log/caddy/v1.domeinnaam.ext/access.log {
        roll_size 100MiB
        roll_keep 90
        roll_keep_for 2160h
        level INFO
        }

    # error logs
      output file /var/log/caddy/v1.domeinnaam.ext/errors.log {
        roll_size 100MiB
        roll_keep 90
        roll_keep_for 2160h
        level ERROR
        }

      }

}

Met de subnet's / IP's achter remote_ip forwarded wordt bepaald welke hosts toegang hebben tot Vaultwarden. Met format transform "{common_log}" wordt het log-formaat bepaald. In dit geval worden er geen json regels maar ongestructureerde log regels weggeschreven - die sterk lijken op de regels die Apache weg schrijft. Dat laatste is prettig - omdat ik een generieke regex van Apache of Nginx kan hergebruiken.

Belangrijk is om alvast /etc/caddy/caddy_security.conf aan te maken: touch /etc/caddy/caddy_security.conf.

Log formaat

Probleem
De module om met een ander format te werken zit standaard niet in Caddy (tenminste: niet in de package voor Arch Linux).

Oplossing
Gelukkig kan de module geïnstalleerd worden met xcaddy. Het gaat om module caddy.logging.encoders.transform en deze wordt beschreven op https://caddyserver.com/docs/modules/caddy.logging.encoders.transform. Op dezelfde pagina wordt het commando xcaddy build --with github.com/caddyserver/transform-encoder weergegeven. Daarmee wordt een nieuwe caddy executable gecompileerd - inclusief de module caddy.logging.encoders.transform.

Ik zag dat xcaddy beschikbaar is in AUR (Arch User Repositories) - maar op de Github pagina van xcaddy staat ook een beschrijving van de installatie. Een voorwaarde is dat Go is geïnstalleerd. Op https://wiki.archlinux.org/title/Go wordt beschreven hoe Go geïnstalleerd kan worden onder Arch Linux. Ik heb voor deze laatste optie gekozen.

Ik heb eerst het pad naar de bin map van Go toegevoegd aan de path variabele (van mijn gebruikersaccount). Dat heb ik gedaan door in ~/.bash_profile de volgende regel toe te voegen: export PATH="${PATH}:~/go/bin" (~/ staat voor /home/uw-gebruikersnaam/). Door export PATH="${PATH}:~/go/bin" uit te voeren is de bin map direct toegevoegd aan de pad variabele (maar je kunt ook even uit-/inloggen).

Met het commando go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest heb ik vanuit mijn home folder xcaddy geïnstalleerd. De executable komt vervolgens in ~/go/bin terecht.

Met het commando xcaddy build --with github.com/caddyserver/transform-encoder kon ik tot slot een nieuwe caddy executable compileren - inclusief de benodigde module. Ik heb dat vanuit de map ~/src/ uitgevoerd (mkdir ~/src/ && cd ~/src/). De (ingekorte) uitvoer staat hieronder. 

[main@v1 src]$ xcaddy build --with github.com/caddyserver/transform-encoder
2022/06/19 19:40:24 [INFO] Temporary folder: /tmp/buildenv_2022-06-19-1940.587263106
2022/06/19 19:40:24 [INFO] Writing main module: /tmp/buildenv_2022-06-19-1940.587263106/main.go
package main

import (
    caddycmd "github.com/caddyserver/caddy/v2/cmd"

    // plug in Caddy modules here
    _ "github.com/caddyserver/caddy/v2/modules/standard"
    _ "github.com/caddyserver/transform-encoder"
)

func main() {
    caddycmd.Main()
}
2022/06/19 19:40:24 [INFO] Initializing Go module
2022/06/19 19:40:24 [INFO] exec (timeout=10s): /usr/bin/go mod init caddy 
go: creating new go.mod: module caddy
go: to add module requirements and sums:
    go mod tidy
2022/06/19 19:40:24 [INFO] Pinning versions
2022/06/19 19:40:24 [INFO] exec (timeout=0s): /usr/bin/go get -d -v github.com/caddyserver/caddy/v2 
go: added github.com/beorn7/perks v1.0.1
go: added github.com/caddyserver/caddy/v2 v2.5.1

[ --- knip --- knip --- knip --- ]

go: upgraded golang.org/x/net v0.0.0-20220127200216-cd36cc0744dd => v0.0.0-20220225172249-27dd8689420f
go: upgraded golang.org/x/sys v0.0.0-20220209214540-3681064d5158 => v0.0.0-20220310020820-b874c991c1a5
go: upgraded golang.org/x/tools v0.1.7 => v0.1.9
2022/06/19 19:40:24 [INFO] exec (timeout=0s): /usr/bin/go get -d -v  
2022/06/19 19:40:25 [INFO] Build environment ready
2022/06/19 19:40:25 [INFO] Building Caddy
2022/06/19 19:40:25 [INFO] exec (timeout=0s): /usr/bin/go mod tidy 
2022/06/19 19:40:25 [INFO] exec (timeout=0s): /usr/bin/go build -o /home/main/src/caddy -ldflags -w -s -trimpath 
2022/06/19 19:40:26 [INFO] Build complete: ./caddy
2022/06/19 19:40:26 [INFO] Cleaning up temporary folder: /tmp/buildenv_2022-06-19-1940.587263106

Tot slot heb ik een kopie gemaakt van het originele caddy bestand - wat in /usr/bin/ staat (mkdir ~/kopie/ && cp /usr/bin/caddy ~/kopie/caddy). Vervolgens heb ik de gecompileerde versie over het origineel gekopieerd. Dat is misschien wat vreemd - maar er is niet echt een andere optie: cp ~/src/caddy /usr/bin/caddy.

Wat je nog wel eens ziet is dat update-alternatives gebruikt wordt. Daarmee kunnen alternatieven geboden worden voor eenzelfde soort programma - waarbij het geselecteerd en toegepaste programma onder een generieke naam beschikbaar gemaakt wordt. Ik zie geen reden om zoiets in te regelen voor deze Linux container.

Fail2Ban

Nu alle voorbereidingen zijn doorgevoerd - kan Fail2Ban geconfigureerd worden.

Installatie en configuratie

  1. Eerst moet Fail2Ban geïnstalleerd worden:
    # pacman -Sy fail2ban

  2. Vervolgens kan Fail2Ban ingeschakeld worden - zodat de service start tijdens de systeem boot.
    # systemctl enable --now fail2ban.service

  3. Er is een filter nodig wat de log evalueert:
    # nano /etc/fail2ban/filter.d/caddy.conf

[Definition]
failregex = ^<HOST>.*"(GET|POST).*" (400|401|403|404) .*$
ignoreregex =
  1. Ik vond nog een tip om de beveiliging van Caddy te verbeteren. Daarvoor kan het bestand /etc/caddy/caddy_security.con toegevoegd worden met het commando # nano /etc/caddy/caddy_security.conf.
header {
    Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Xss-Protection "1; mode=block"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Content-Security-Policy "upgrade-insecure-requests"
        Referrer-Policy "strict-origin-when-cross-origin"
        Cache-Control "public, max-age=15, must-revalidate"
        Feature-Policy "accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'self'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; m>
}
  1. Tot slot is er een jail nodig waar de benodigde configuratie in staat voor Fail2Ban
    # nano /etc/fail2ban/jail.d/jail.local
# file: jail.local

[DEFAULT]
enabled         = false
ignoreip        = 127.0.0.1/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 100.64.0.0/10

[caddy]
enabled         = true
port            = http,https,8000
logpath         = /var/log/caddy/*/errors.log
maxretry        = 3
findtime        = 3600
bantime         = 1200
  1. Zodra het bovenstaande gereed is, kan Fail2Ban gestart worden:
    # systemctl start fail2ban

Evaluatie

De werking kan gecontroleerd worden door de logs van Fail2Ban en Caddy te controleren.

Controle services

Het is verstandig om te controleren of Caddy en Fail2Ban actief zijn. Dat kan met de commando's systemctl status caddy.services en systemctl status fail2ban.service.

[main@v1 /]$ systemctl status caddy.service
* caddy.service - Caddy web server
     Loaded: loaded (/usr/lib/systemd/system/caddy.service; enabled; vendor preset: disabled)
     Active: active (running) since Sun 2022-06-19 18:28:46 UTC; 2h 13min ago
       Docs: https://caddyserver.com/docs/
   Main PID: 239906 (caddy)
      Tasks: 22 (limit: 76920)
     Memory: 10.0M
     CGroup: /system.slice/caddy.service
             `-239906 /usr/bin/caddy run --environ --config /etc/caddy/Caddyfile

Jun 19 18:28:46 v1 caddy[239906]: {"level":"warn","ts":1655663326.9492743,"msg":"Caddyfile input is not formatted; run the 'caddy fmt' command to fix inconsistencies","adapter":"caddyfile",>
Jun 19 18:28:46 v1 caddy[239906]: {"level":"info","ts":1655663326.9496415,"logger":"admin","msg":"admin endpoint started","address":"unix//run/caddy/admin.socket","enforce_origin":false,"or>
Jun 19 18:28:46 v1 caddy[239906]: {"level":"info","ts":1655663326.949701,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to >
Jun 19 18:28:46 v1 caddy[239906]: {"level":"info","ts":1655663326.94971,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
Jun 19 18:28:46 v1 caddy[239906]: {"level":"info","ts":1655663326.949786,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc0003b61c0"}
Jun 19 18:28:46 v1 caddy[239906]: {"level":"info","ts":1655663326.950006,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["v1.domeinnaam.ext"]}
Jun 19 18:28:46 v1 caddy[239906]: {"level":"info","ts":1655663326.950024,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/var/lib/caddy"}
Jun 19 18:28:46 v1 caddy[239906]: {"level":"info","ts":1655663326.9502811,"logger":"tls","msg":"finished cleaning storage units"}
Jun 19 18:28:46 v1 caddy[239906]: {"level":"error","ts":1655663326.9503055,"msg":"unable to autosave config","file":"/etc/caddy/autosave.json","error":"open /etc/caddy/autosave.json: read-o>
Jun 19 18:28:46 v1 caddy[239906]: {"level":"info","ts":1655663326.9503129,"msg":"serving initial configuration"}
lines 1-20/20 (END)
[main@v1 /]$ systemctl status fail2ban.service 
* fail2ban.service - Fail2Ban Service
     Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled; vendor preset: disabled)
     Active: active (running) since Sun 2022-06-19 17:57:39 UTC; 2h 45min ago
       Docs: man:fail2ban(1)
   Main PID: 237552 (fail2ban-server)
      Tasks: 5 (limit: 76920)
     Memory: 11.9M
     CGroup: /system.slice/fail2ban.service
             `-237552 /usr/bin/python /usr/bin/fail2ban-server -xf start

Jun 19 17:57:39 v1 systemd[1]: Starting Fail2Ban Service...
Jun 19 17:57:39 v1 systemd[1]: Started Fail2Ban Service.
Jun 19 17:57:39 v1 fail2ban-server[237552]: Server ready

Uiteraard moet Vaultwarden ook actief zijn. Die service kan op dezelfde manier gecontroleerd worden (systemctl status vaultwarden.service).

Controle log files

Met het tail commando kan het laatste deel van een log file in de gaten gehouden worden. Door -f toe te voegen, zie je steeds de laatste wijzigingen. Stoppen met monitoring met CTRL + C.

[root@v1 ~]# tail -f /var/log/fail2ban.log 
2022-06-19 17:57:39,456 fail2ban.filter         [237552]: INFO      maxRetry: 3
2022-06-19 17:57:39,456 fail2ban.filter         [237552]: INFO      findtime: 3600
2022-06-19 17:57:39,457 fail2ban.actions        [237552]: INFO      banTime: 1200
2022-06-19 17:57:39,457 fail2ban.filter         [237552]: INFO      encoding: UTF-8
2022-06-19 17:57:39,457 fail2ban.filter         [237552]: INFO    Added logfile: '/var/log/caddy/v1.domeinnaam.ext/errors.log' (pos = 6807, hash = 123aafe15c900raldaldalefd153d96c8125fyyy)
2022-06-19 17:57:39,457 fail2ban.jail           [237552]: INFO    Jail 'caddy' started
2022-06-19 18:10:24,028 fail2ban.filter         [237552]: INFO    [caddy] Ignore 77.xxx.yyy.155 by ip
2022-06-19 18:10:26,814 fail2ban.filter         [237552]: INFO    [caddy] Ignore 77.xxx.yyy.155 by ip
2022-06-19 18:28:51,601 fail2ban.filter         [237552]: INFO    [caddy] Found 62.xxx.yyy.240 - 2022-06-19 18:28:51
2022-06-19 18:31:21,459 fail2ban.filter         [237552]: INFO    [caddy] Ignore 77.xxx.yyy.155 by ip

Uit de bovenstaande log blijkt dat er een verdacht IP werd gevonden (één na laatste regel). 

[root@v1 ~]# tail -f /var/log/caddy/v1.domeinnaam.ext/errors.log 
77.xxx.yyy.155 - - [19/Jun/2022:18:31:15 +0000] "GET /app/vendor.89744fbeca9ac2e1b54f.js HTTP/2.0" 200 951251
77.xxx.yyy.155 - - [19/Jun/2022:18:31:16 +0000] "GET /locales/nl/messages.json?cache=sk2erj HTTP/2.0" 200 33628
77.xxx.yyy.155 - - [19/Jun/2022:18:31:16 +0000] "GET /locales/en/messages.json?cache=sk2erj HTTP/2.0" 200 31820
77.xxx.yyy.155 - - [19/Jun/2022:18:31:16 +0000] "GET /images/favicon-32x32.png HTTP/2.0" 200 434
77.xxx.yyy.155 - - [19/Jun/2022:18:31:16 +0000] "GET /70501c97b33df95adb32.json HTTP/2.0" 200 352
77.xxx.yyy.155 - - [19/Jun/2022:18:31:16 +0000] "GET /fonts/Open_Sans-normal-600.woff HTTP/2.0" 200 57744
77.xxx.yyy.155 - - [19/Jun/2022:18:31:21 +0000] "POST /api/accounts/prelogin HTTP/2.0" 200 32
77.xxx.yyy.155 - - [19/Jun/2022:18:31:21 +0000] "POST /identity/connect/token HTTP/2.0" 400 351
77.xxx.yyy.155 - - [19/Jun/2022:18:31:21 +0000] "GET /fonts/Open_Sans-normal-700.woff HTTP/2.0" 200 58016
77.xxx.yyy.155 - - [19/Jun/2022:18:31:21 +0000] "GET /fonts/Open_Sans-italic-400.woff HTTP/2.0" 200 53108
62.xxx.yyy.240 - - [19/Jun/2022:20:52:03 +0000] "GET / HTTP/2.0" 403 19
62.xxx.yyy.240 - - [19/Jun/2022:20:52:08 +0000] "GET / HTTP/2.0" 403 19
62.xxx.yyy.240 - - [19/Jun/2022:20:52:12 +0000] "GET /test HTTP/2.0" 403 19

Uit de bovenstaande log blijkt dat er iets of iemand geen toegang had "403" en ook nog eens een map "/test" probeerde te bekijken (laatste drie regels).

Met fail2ban-client kan onder andere de status van Fail2Ban gecontroleerd worden. 

[root@v1 ~]# fail2ban-client status
Status
|- Number of jail:  1
`- Jail list:   caddy

Er is slechts één jail beschikbaar. Indien er ook een SSH server gedraaid wordt, dan is het verstandig om daar ook een jail voor aan te maken - naast het beperken van toegang.

Belangrijk is ook om te controleren of er IP's geblokkeerd worden. 

[root@v1 ~]# fail2ban-client get caddy banned 
['62.xxx.yyy.240']

Uit het bovenstaande commando blijkt een blokkade.

Ook het aantal seconden dat een host geblokkeerd blijft kan opgevraagd worden:

[root@v1 ~]# fail2ban-client get caddy bantime
1200

Mocht een host eerder vrijgegeven moeten worden, dan kan dat met het commando fail2ban-client unban met daarachter het IP adres.

[root@v1 ~]# fail2ban-client unban 62.xxx.yyy.240
1

Pas de waarden maxretry, findtime en bantime naar wens aan in /etc/fail2ban/jail.d/jail.local. De bantime kan ook op -1 gezet worden. Hiermee blijft een host voor altijd geblokkeerd (totdat deze vrij wordt gegeven met het unban commando - zoals hierboven weergegeven).

Ik heb de volgende instellingen in de config gezet:

[caddy]
enabled         = true
port            = http,https,8000
logpath         = /var/log/caddy/*/errors.log
maxretry        = 3
findtime        = 2592000
bantime         = -1

Dit betekent dat er drie maal geprobeerd kan worden binnen 30 dagen - en dat de ban voor altijd is. Ik heb ook poort 8000 toegevoegd. Dat is in principe niet nodig omdat die op localhost draait. Ik heb dit erin gezet om eventuele foutjes te ondervangen.

Een wijziging in de configuratie doorvoeren kan met het commando systemctl reload fail2ban of systemctl restart fail2ban.

Het is verstandig om https://wiki.archlinux.org/title/fail2ban door te nemen. Het is bijvoorbeeld ook mogelijk om Fail2Ban e-mails te laten versturen. Mocht je e-mail naar buiten sturen, dan is het misschien handig om sSMTP te configureren: https://wiki.archlinux.org/title/SSMTP. Er zijn meer opties - maar sSMTP is waarschijnlijk één van de meest eenvoudige. Het viel mij op dat in het voorbeeld een GMail.com account gebruikt wordt - maar dat werkt niet (op deze manier) aangezien GMail.com tegenwoordig OAuth vereist - en niet meer werkt met plain passwords (LOGIN).

Next Post Previous Post