Administratorii care rulează Vaultwarden dockerizat în spatele reverse proxy-ului Caddy pe Debian întâmpină frecvent o defecțiune de securitate perplexă: Fail2Ban detectează corect încercările de autentificare eșuate, logurile arată adrese IP banate, totuși atacatorii continuă să acceseze pagina de login fără obstacole. Aceasta nu este o problemă de filtru sau configurare regex greșită—este o nepotrivire fundamentală de arhitectură firewall unde regulile de ban ajung în subsistemul netfilter greșit sau în lanțul iptables pe care rutarea pachetelor Docker nu îl traversează niciodată. Înțelegerea modului în care valorile implicite moderne ale Debian creează această deconectare și implementarea soluțiilor specifice topologiei asigură că managerul tău de parole self-hosted blochează efectiv atacurile brute-force în loc să le înregistreze doar.

Acest follow-up cuprinzător la ghidul ENGINYRING de instalare Vaultwarden explică stratul de networking Docker, prioritățile lanțurilor iptables, conflictele de migrare nftables și cerințele de forwarding IP real ale Caddy care determină colectiv dacă aplicarea Fail2Ban protejează efectiv vault-ul tău. Soluția necesită alinierea backend-ului acțiunii tale de ban (iptables vs nftables) cu sistemul activ de firewall Docker, țintirea lanțului corect pentru topologia reverse proxy-ului tău (INPUT vs DOCKER-USER vs FORWARD) și asigurarea că Vaultwarden înregistrează IP-ul real al clientului în loc de localhost sau adrese proxy.

Înțelegerea arhitecturii Docker networking și firewall

Docker alterează fundamental fluxul de pachete al firewall-ului Linux prin inserarea de lanțuri iptables personalizate care interceptează traficul înainte ca acesta să ajungă la lanțurile tradiționale INPUT sau OUTPUT. Când publici porturi container cu -p 8080:80, Docker nu doar deschide un port—creează reguli NAT în lanțul PREROUTING care redirecționează pachetele destinate portului 8080 al host-ului către IP-ul intern al containerului pe portul 80, apoi rutează acele pachete prin lanțul FORWARD în loc de INPUT. Această decizie arhitecturală înseamnă că regulile firewall din lanțul INPUT nu văd niciodată traficul destinat containerelor, făcând configurațiile tradiționale Fail2Ban complet ineficiente pentru aplicațiile dockerizate.

Docker creează mai multe lanțuri iptables personalizate în tabela filter pentru a gestiona această rutare de pachete:

  • DOCKER-USER: Proiectat explicit ca punct de inserare a regulilor definite de utilizator, procesat înaintea tuturor lanțurilor gestionate de Docker, oferind administratorilor o locație pentru filtrare personalizată pe care Docker nu o va suprascrie în timpul operațiunilor de lifecycle ale containerului
  • DOCKER-FORWARD: Procesare de prima etapă determinând dacă pachetele fără legătură cu conexiuni stabilite ar trebui să procedeze la alte lanțuri Docker sau să accepte pachete parte din conexiuni stabilite
  • DOCKER: Conține reguli generate dinamic determinând dacă pachetele care nu fac parte din conexiuni stabilite ar trebui acceptate pe baza configurării de forwarding de porturi a containerelor în execuție
  • DOCKER-ISOLATION-STAGE-1 și DOCKER-ISOLATION-STAGE-2: Implementează izolarea rețelei între diferite rețele Docker

Perspectiva critică: fluxul de pachete Docker pentru porturile container publicate urmează PREROUTING (NAT) → FORWARD → DOCKER-USER → DOCKER-FORWARD → DOCKER în loc de calea tradițională PREROUTING → INPUT. Regulile Fail2Ban inserate în lanțul INPUT nu evaluează niciodată pachetele destinate containerelor deoarece acele pachete ocolesc complet INPUT. Aceasta explică de ce administratorii văd starea "Banned" în fail2ban-client status vaultwarden dar atacatorii continuă să ajungă la pagina de login Vaultwarden—banul există într-un lanț pe care traficul nu îl traversează niciodată.

Conflictul de migrare nftables din Debian Bookworm

Debian 12 (Bookworm) a introdus nftables ca backend implicit de firewall, cu Debian 13 (Trixie) continuând această modernizare. Fail2Ban versiunea 1.1.0 și mai nou detectează automat disponibilitatea nftables și implicit folosește banactions bazate pe nftables când este instalat pe aceste distribuții. Însă, Docker Engine până la versiunea 25.0.3 încă gestionează regulile firewall exclusiv prin iptables decât dacă este configurat altfel cu suport experimental nftables care rămâne incomplet. Acest lucru creează o nepotrivire devastatoare: Fail2Ban scrie reguli de ban în tabelele nftables în timp ce Docker rutează tot traficul containerului prin lanțurile iptables, rezultând în eșec complet de aplicare.

Când Fail2Ban folosește banaction = nftables-multiport (implicit Debian 12+), creează reguli în tabela inet filter a nftables. Aceste reguli au efect zero asupra traficului gestionat de Docker deoarece lanțurile iptables ale Docker din tabela filter procesează pachetele primele, iau decizii de forwarding, și regulile NAT ale Docker din tabela nat redirecționează traficul către containere înainte ca evaluarea nftables să apară. Pachetul nu ajunge niciodată la ruleset-ul nftables unde Fail2Ban a plasat banul. Invers, chiar dacă forțezi Fail2Ban să folosească acțiuni iptables în timp ce nftables este activ, riști conflicte dacă alte componente sistem gestionează reguli nftables așteptându-se la un anumit flux de pachete.

Agravând această problemă, comanda iptables pe sistemele Debian moderne poate fi de fapt iptables-nft, un shim de compatibilitate oferind sintaxă iptables în timp ce scrie în backend-ul nftables. Rularea iptables -L ar putea afișa reguli traduse din nftables în loc să arate reguli iptables-legacy reale. Pentru a determina backend-ul tău real de firewall:

# Verifică dacă iptables este de fapt shim nftables
update-alternatives --display iptables

# Vizualizează regulile iptables-legacy reale
iptables-legacy -L -n -v

# Vizualizează ruleset-ul nftables
nft list ruleset

# Verifică configurația firewall Docker
docker info | grep -i firewall

Dacă Docker arată "iptables" ca backend firewall dar sistemul tău folosește iptables-nft, ești într-o stare hibridă necesitând configurare atentă Fail2Ban pentru a ținti stratul de compatibilitate iptables în loc de acțiuni nftables native.

Topologia reverse proxy și selecția lanțului

Alegerea lanțului iptables corect pentru regulile Fail2Ban depinde în întregime de topologia de deployment a reverse proxy-ului tău—dacă Caddy rulează pe sistemul host sau într-un container Docker determină care lanț vede traficul clientului primul.

Topologia A: Caddy pe host, Vaultwarden în Docker

Când Caddy rulează direct pe host (instalat via apt sau binar compilat) și face proxy la http://127.0.0.1:8080 unde Vaultwarden ascultă, conexiunile clientului se termină la interfața de rețea a host-ului mai întâi. Fluxul de pachete urmează: Client → NIC host → lanț INPUT → proces Caddy → loopback localhost → container Vaultwarden. În această topologie, banarea în lanțul INPUT blochează efectiv conexiunile clientului înainte să ajungă la Caddy deoarece handshake-ul TCP inițial pe porturile 80/443 apare în contextul lanțului INPUT.

# Pentru Caddy bazat pe host, lanțul INPUT este corect
# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled = true
port = http,https
filter = vaultwarden
banaction = iptables-multiport[name=vaultwarden, port="http,https", protocol=tcp]
logpath = /var/lib/docker/volumes/vaultwarden/_data/vaultwarden.log
maxretry = 5
bantime = 1d
findtime = 10m

Această configurație folosește acțiunea implicită iptables-multiport care inserează reguli în lanțul INPUT. Deoarece Caddy gestionează conexiunea de intrare pe host, aceste reguli interceptează traficul la punctul corect.

Topologia B: Caddy în Docker, Vaultwarden în Docker

Când atât Caddy cât și Vaultwarden rulează ca containere Docker (comun cu orchestrarea Docker Compose), pachetele clientului nu intră niciodată în lanțul INPUT pentru traficul destinat containerului. În schimb, NAT-ul PREROUTING al Docker redirecționează pachetele direct către lanțul FORWARD, apoi prin lanțurile DOCKER-USER și DOCKER pentru a determina rutarea containerului. Fluxul de pachete devine: Client → NIC host → PREROUTING (DNAT) → FORWARD → DOCKER-USER → DOCKER-FORWARD → DOCKER → container.

În această topologie, Fail2Ban trebuie să insereze reguli de ban în lanțul DOCKER-USER pentru a intercepta traficul înainte ca regulile proprii de forwarding ale Docker să îl accepte. Lanțul DOCKER-USER există specific pentru acest scop—Docker îl procesează primul și nu elimină niciodată regulile adăugate de utilizator în timpul operațiunilor de lifecycle ale containerului, spre deosebire de lanțul DOCKER pe care Docker îl regenerează dinamic.

# Pentru Caddy dockerizat, lanțul DOCKER-USER necesar
# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled = true
port = http,https
filter = vaultwarden
# Țintește explicit lanțul DOCKER-USER
banaction = iptables-multiport[name=vaultwarden, chain="DOCKER-USER", port="http,https", protocol=tcp]
logpath = /var/lib/docker/volumes/vaultwarden/_data/vaultwarden.log
maxretry = 5
bantime = 1d
findtime = 10m

Diferența crucială: adăugarea parametrului chain="DOCKER-USER" la banaction direcționează Fail2Ban să insereze reguli în DOCKER-USER în loc de lanțul INPUT implicit.

Topologia C: în spatele Cloudflare sau CDN

Când proxy-ul Cloudflare sau alt CDN stă în fața VPS-ului tău, IP-ul sursă al conexiunii TCP devine IP-ul serverului edge CDN, nu clientul real. Banurile firewall Layer 3/4 nu pot bloca clienți individuali deoarece din perspectiva VPS-ului, toate conexiunile provin de la infrastructura CDN legitimă. Banarea adreselor IP CDN sparge întregul tău site. Pentru deployment-uri CDN-fronted, Fail2Ban trebuie să baneze la nivelul API-ului CDN în loc de firewall local, sau trebuie să implementezi blocare la nivel de aplicație în Caddy citind header-ele CF-Connecting-IP sau X-Forwarded-For.

Rezolvarea conflictului backend iptables vs nftables

Cea mai fiabilă soluție pentru Vaultwarden dockerizat pe sistemele Debian 12+: forțează Fail2Ban să folosească banactions bazate pe iptables potrivite cu backend-ul firewall Docker în loc să încerci să migrezi Docker la nftables.

# /etc/fail2ban/jail.local - Valori implicite globale
[DEFAULT]
# Forțează backend iptables pentru compatibilitate Docker
banaction = iptables-multiport
banaction_allports = iptables-allports

# Folosește backend systemd journal pentru citire log
backend = systemd

# Configurare timing de bază
bantime = 1d
findtime = 10m
maxretry = 5

# Ignoră localhost
ignoreip = 127.0.0.1/8 ::1/128

Această configurație globală asigură că toate jail-urile implicit folosesc acțiuni bazate pe iptables indiferent de valori implicite sistem. Setarea backend = systemd spune Fail2Ban să citească loguri din journal-ul systemd în loc de fișiere, ceea ce funcționează fără probleme cu containere Docker care logheză în journald.

Configurarea logging-ului Vaultwarden pentru IP-uri client reale

Eficacitatea Fail2Ban depinde de Vaultwarden logând adresele IP reale ale clienților în loc de localhost (127.0.0.1) sau IP-ul containerului proxy. Când logurile Vaultwarden arată IP: 127.0.0.1 pentru login-uri eșuate, regex-ul tău potrivește și banează localhost, neîndeplinind nimic.

Vaultwarden citește IP-ul clientului din header-ul X-Real-IP implicit, revenind la X-Forwarded-For dacă X-Real-IP este absent. Caddy setează automat X-Forwarded-For dar ar trebui să configurezi explicit X-Real-IP pentru claritate:

# Configurare Caddyfile
vault.domeniultau.com {
    reverse_proxy vaultwarden:80 {
        # Setează explicit header IP real
        header_up X-Real-IP {remote_host}
        
        # Caddy setează X-Forwarded-For automat
        # dar configurarea explicită documentează intenția
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }
}

Pentru deployment-uri proxied Cloudflare, configurează variabila de mediu IP_HEADER a Vaultwarden pentru a citi header-ul Cloudflare:

# docker-compose.yml pentru Vaultwarden în spatele Cloudflare
services:
  vaultwarden:
    image: vaultwarden/server:latest
    environment:
      # Spune Vaultwarden să aibă încredere în CF-Connecting-IP
      IP_HEADER: "CF-Connecting-IP"
    volumes:
      - ./vw-data:/data
    ports:
      - "8080:80"

După configurare, testează eșuând intenționat un login și verificând fișierul log Vaultwarden (/data/vaultwarden.log în container) pentru o intrare arătând IP-ul tău public real în loc de 127.0.0.1 sau un IP container.

Configurație completă funcțională pentru Docker + Caddy

Această configurație completă combină toate elementele pentru aplicare fiabilă Fail2Ban cu Vaultwarden dockerizat în spatele Caddy pe Debian 12+.

Pasul 1: Vaultwarden Docker Compose cu logging

# docker-compose.yml
version: '3'

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      # Activează logging fișier (necesar pentru Fail2Ban)
      LOG_FILE: "/data/vaultwarden.log"
      LOG_LEVEL: "info"
      # Dezactivează înregistrare utilizatori noi după setup inițial
      SIGNUPS_ALLOWED: "false"
      # Setează domeniul pentru link-uri corecte în emailuri
      DOMAIN: "https://vault.domeniultau.com"
    volumes:
      - ./vw-data:/data
    ports:
      - "127.0.0.1:8080:80"
    networks:
      - vaultwarden_net

  caddy:
    image: caddy:latest
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./caddy_data:/data
      - ./caddy_config:/config
    networks:
      - vaultwarden_net

networks:
  vaultwarden_net:
    driver: bridge

Pasul 2: Caddyfile cu header-e IP real

# Caddyfile
vault.domeniultau.com {
    # HTTPS automat cu Let's Encrypt
    
    reverse_proxy vaultwarden:80 {
        # Treci IP-ul real client la Vaultwarden
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
        
        # Suport WebSocket pentru notificări
        header_up Connection {>Connection}
        header_up Upgrade {>Upgrade}
    }
    
    # Header-e securitate
    header {
        # Activează HSTS
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        # Previne clickjacking
        X-Frame-Options "SAMEORIGIN"
        # Previne MIME sniffing
        X-Content-Type-Options "nosniff"
        # Politică referrer
        Referrer-Policy "same-origin"
    }
    
    # Logging pentru debugging
    log {
        output file /var/log/caddy/vault-access.log
    }
}

Pasul 3: filtru Fail2Ban pentru Vaultwarden

# /etc/fail2ban/filter.d/vaultwarden.local
[INCLUDES]
before = common.conf

[Definition]
# Potrivește încercări login eșuate
failregex = ^.*Username or password is incorrect\. Try again\. IP: \. Username:.*$
            ^.*Invalid admin token\. IP: .*$

ignoreregex =

[Init]
datepattern = ^%%Y-%%m-%%d %%H:%%M:%%S

Acest filtru combină atât încercările eșuate web vault cât și panoul admin într-un pattern. Placeholder-ul <ADDR> (sau <HOST> pe versiuni Fail2Ban mai vechi) extrage adresa IP din linia log.

Pasul 4: configurație jail Fail2Ban

# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled = true

# Citește loguri din volumul Docker
# Ajustează calea pentru a se potrivi mount-ului volume docker-compose
logpath = /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log

# Alternativ: folosește Docker logs via journald
# backend = systemd
# journalmatch = _SYSTEMD_UNIT=docker.service CONTAINER_NAME=vaultwarden

# Țintește lanțul DOCKER-USER pentru reverse proxy dockerizat
banaction = iptables-multiport[name=vaultwarden, chain="DOCKER-USER", port="http,https", protocol=tcp]

# Banează toate porturile pentru a preveni orice acces
# banaction = iptables-allports[name=vaultwarden, chain="DOCKER-USER"]

# Configurație timing
findtime = 10m
bantime = 24h
maxretry = 5

# Filtru
filter = vaultwarden

# Porturi de monitorizat
port = http,https

Parametri critici explicați:

  • logpath: Trebuie să indice la locația reală a fișierului log pe filesystem-ul host, nu calea containerului. Volumele Docker se montează de obicei la /var/lib/docker/volumes/
  • chain="DOCKER-USER": Esențial pentru topologia reverse proxy dockerizat. Omiterea acestui parametru implicit la lanțul INPUT pe care Docker îl ocolește
  • banaction: Folosește iptables explicit în loc de nftables pentru a se potrivi cu backend-ul firewall Docker
  • findtime: Fereastra de timp pentru numărarea eșecurilor. 10 minute permite utilizatorilor legitimi mai multe încercări în timp ce prinde brute force rapid
  • bantime: Durata banului. 24 ore descurajează atacatorii fără blocări permanente care ar putea prinde IP-uri dinamice realocate utilizatorilor legitimi
  • maxretry: Număr de eșecuri înainte de ban. 5 oferă toleranță rezonabilă pentru greșeli de tastare în timp ce oprește brute force rapid

Pasul 5: aplică configurația și testează

# Repornește Fail2Ban pentru a încărca noua configurație
sudo systemctl restart fail2ban

# Verifică jail-ul este activ
sudo fail2ban-client status
sudo fail2ban-client status vaultwarden

# Testează cu login eșuat intenționat
# De pe o mașină diferită sau browser incognito, încearcă login cu parolă greșită de 6 ori

# Verifică dacă IP-ul a fost banat
sudo fail2ban-client status vaultwarden

# Verifică regula iptables a fost creată în lanțul DOCKER-USER
sudo iptables -L DOCKER-USER -n -v

# Urmărește banuri în timp real
sudo tail -f /var/log/fail2ban.log

# Testează că IP-ul banat efectiv nu se poate conecta
# Din IP-ul banat, încearcă să faci curl la site - ar trebui timeout sau respins

# Debanează pentru testare
sudo fail2ban-client set vaultwarden unbanip IP.TAU.ADRESA

Configurația de succes arată IP-ul banat în output-ul status jail, o regulă iptables în lanțul DOCKER-USER cu contoare pachete și bytes non-zero potrivind IP-ul banat, și eșecuri reale de conexiune de la adresa banată.

Depanarea problemelor comune

Problemă: banul apare dar IP-ul poate încă să se conecteze

Simptome: fail2ban-client status vaultwarden arată IP în lista banată, dar acel IP poate încă accesa site-ul.

Diagnostic:

# Verifică ce lanț a folosit Fail2Ban
sudo iptables -L INPUT -n -v | grep IP.BANAT
sudo iptables -L DOCKER-USER -n -v | grep IP.BANAT
sudo iptables -L FORWARD -n -v | grep IP.BANAT

# Verifică dacă nftables are reguli dar iptables nu
sudo nft list ruleset | grep IP.BANAT

# Verifică Docker folosește iptables nu nftables
docker info | grep -i firewall

Soluție: Dacă regulile apar în INPUT dar reverse proxy-ul tău este dockerizat, schimbă configurația jail pentru a folosi chain="DOCKER-USER". Dacă regulile apar în nftables dar Docker folosește iptables, schimbă configurația jail pentru a folosi banaction = iptables-multiport în loc de acțiune bazată pe nftables.

Problemă: Fail2Ban banează localhost (127.0.0.1)

Simptome: Toate banurile arată IP: 127.0.0.1 în log-ul Fail2Ban. Log-ul Vaultwarden arată IP: 127.0.0.1 pentru toate încercările eșuate.

Diagnostic: Caddy nu forwarding IP-ul real client la Vaultwarden. Verifică Caddyfile pentru directiva header_up X-Real-IP lipsă.

Soluție: Adaugă forwarding explicit header în Caddyfile așa cum este arătat în configurația de mai sus. Repornește Caddy, testează login eșuat, verifică log-ul Vaultwarden arată acum IP-ul real client.

Problemă: Fail2Ban nu poate citi fișierul log

Simptome: /var/log/fail2ban.log arată "Unable to open file" sau erori permission denied.

Diagnostic:

# Verifică fișierul log există și permisiuni
ls -la /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log

# Verifică Fail2Ban poate să-l citească
sudo -u fail2ban cat /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log | tail

Soluție: Asigură-te că utilizatorul Fail2Ban are permisiune de citire pe directorul volume Docker. Adaugă utilizatorul Fail2Ban la grupul docker: sudo usermod -aG docker fail2ban, apoi repornește serviciul Fail2Ban.

Problemă: adresele IPv6 nu sunt banate

Simptome: Adrese IPv4 banate cu succes, dar adresele IPv6 ocolesc banurile.

Soluție: Adaugă banaction IPv6:

# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled = true
logpath = /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log
filter = vaultwarden
port = http,https
findtime = 10m
bantime = 24h
maxretry = 5

# Acțiuni ban IPv4 și IPv6
banaction = iptables-multiport[name=vaultwarden, chain="DOCKER-USER", port="http,https", protocol=tcp]
            ip6tables-multiport[name=vaultwarden, chain="DOCKER-USER", port="http,https", protocol=tcp]

Opțiuni de configurare avansate

Timpi de ban progresivi

Implementează durate de ban crescătoare exponențial pentru infractori recidiviști:

# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled = true
logpath = /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log
filter = vaultwarden
port = http,https
findtime = 10m
maxretry = 5

# Configurare ban progresiv
bantime = 1h
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 30d
bantime.rndtime = 30m

# Primul ban: 1 oră
# Al doilea ban: 2 ore
# Al treilea ban: 4 ore
# Continuă dublarea până la maximum 30 zile

Jail recidive pentru atacatori persistenți

Creează un jail separat monitorizând propriul log Fail2Ban pentru a prinde IP-uri banate de mai multe ori pe diferite jail-uri:

# /etc/fail2ban/jail.d/recidive.local
[recidive]
enabled = true
logpath = /var/log/fail2ban.log
banaction = iptables-allports[name=recidive, chain="DOCKER-USER"]
findtime = 7d
bantime = 30d
maxretry = 3

# Banează IP-uri care primesc ban de 3+ ori în 7 zile pentru 30 zile pe toate porturile

Notificări email la ban

# /etc/fail2ban/jail.local
[DEFAULT]
# Configurare SMTP
destemail = admin@domeniultau.com
sender = fail2ban@domeniultau.com
mta = sendmail

# Acțiune cu notificare email
action = %(action_mwl)s

# action_mwl = ban + trimite email cu date whois și linii log

Monitorizare și mentenanță

Monitorizarea regulată asigură că Fail2Ban continuă să protejeze instanța ta Vaultwarden efectiv:

# Verificări zilnice
# Vizualizează IP-uri banate curent pe toate jail-urile
sudo fail2ban-client status | grep "Jail list" | sed 's/.*://; s/,//g' | xargs -n1 sudo fail2ban-client status

# Verifică statistici ban
sudo fail2ban-client status vaultwarden

# Vizualizează banuri recente în log-ul Fail2Ban
sudo grep "Ban" /var/log/fail2ban.log | tail -20

# Verifică lanțul DOCKER-USER iptables are banuri curente
sudo iptables -L DOCKER-USER -n -v | grep DROP

# Verifică contoarele iptables pentru a asigura regulile potrivesc pachete
# Contoare pachete/bytes non-zero indică reguli filtrând activ

Configurează monitorizare automatizată cu un script cron simplu:

#!/bin/bash
# /usr/local/bin/fail2ban-report.sh
# Sumar zilnic Fail2Ban

echo "Raport status Fail2Ban - $(date)"
echo "======================================"
echo

for jail in $(fail2ban-client status | grep "Jail list" | sed 's/.*://; s/,//g'); do
    echo "Jail: $jail"
    fail2ban-client status "$jail" | grep "Currently banned"
    echo
done

# Adaugă în cron: 0 9 * * * /usr/local/bin/fail2ban-report.sh | mail -s "Raport zilnic Fail2Ban" admin@domeniultau.com

Considerații de performanță

Fail2Ban introduce overhead minim de performanță pentru deployment-uri tipice Vaultwarden self-hosted gestionând sute de încercări zilnice de autentificare. Totuși, scenariile cu trafic înalt necesită optimizare:

  • Gestionarea dimensiunii fișierului log: Implementează rotație log pentru a preveni fișiere enorme care încetinesc potrivirea regex Fail2Ban. Configurează logrotate pentru loguri Vaultwarden cu rotație zilnică și reținere 7 zile
  • Optimizarea regex filtru: Folosește pattern-uri ancorate (^ și $) pentru a reduce backtracking în motorul regex. Filtrele furnizate implementează deja această practică optimă
  • Selecția backend: Backend-ul systemd performează mai bine decât polling fișier pentru containere Docker logând în journald. Totuși, backend-ul fișier direct cu pyinotify oferă latență minimă pentru logging bazat pe fișier
  • Journal bază date: Fail2Ban menține o bază date SQLite urmărind banuri. Curățarea periodică previne umflarea: configurează dbpurgeage = 30d în jail.local pentru a purja istoricul ban mai vechi de 30 zile

Securitate hardening dincolo de Fail2Ban

Fail2Ban oferă apărare reactivă împotriva atacurilor brute-force dar ar trebui să completeze, nu să înlocuiască, măsurile proactive de securitate. În timp ce Fail2Ban blochează atacatorii după detectarea activității rău intenționate, securitatea cuprinzătoare VPS necesită multiple straturi defensive. Pentru o abordare completă de hardening acoperind configurarea SSH, parametri kernel, controale de acces obligatorii și practici avansate de securitate, consultă ghidul nostru suprem de securitate VPS acoperind tot de la hardening de bază la tehnici elite pentru sysadmin.

  • Parole master puternice: Impune cerințe minime de complexitate pentru parolele master vault. Vaultwarden nu poate impune acest lucru direct, dar educația client-side se dovedește critică
  • Autentificare cu doi factori: Activează 2FA pentru toate conturile Vaultwarden. Chiar ghicirea cu succes a credențialelor nu poate accesa vault-urile fără al doilea factor
  • Protecția paginii admin: Dezactivează panoul admin când nu este necesar: ADMIN_TOKEN="". Când activat, folosește un token aleatoriu criptografic puternic și consideră allowlisting IP în Caddy
  • Rate limiting la reverse proxy: Caddy poate implementa rate limiting cereri înainte ca traficul să ajungă la Vaultwarden, oferind defense-in-depth
  • Restricții geografice: Dacă utilizatorii tăi se concentrează în anumite țări, blochează traficul din regiuni neașteptate folosind filtrare GeoIP în iptables sau Caddy
  • Actualizări regulate: Menține Vaultwarden, Caddy, Fail2Ban și sistemul de operare host actualizate cu patch-uri de securitate. Abonează-te la notificările release GitHub pentru Vaultwarden
  • Detectare intruziuni: Dincolo de banarea reactivă, implementează detectare proactivă intruziuni pentru a identifica sisteme compromise, monitorizează procese suspecte și detectează backdoor-uri înainte să cauzeze daune. Ghidul nostru despre detectarea intruşilor în serverul tău VPS oferă proceduri detaliate pentru monitorizare cuprinzătoare de securitate

Cum ENGINYRING VPS susține securitatea self-hosted

Infrastructura ENGINYRING VPS oferă resursele dedicate, izolarea rețelei și controlul administrativ necesar pentru implementarea protecției robuste Fail2Ban cu aplicații dockerizate. Spre deosebire de gazduirea partajată unde accesul firewall rămâne restricționat, planurile VPS oferă acces root complet permițând lanțuri iptables personalizate, configurarea Fail2Ban și arhitectura networking Docker necesară pentru gestionarea securizată a parolelor self-hosted.

Mediul de rețea consistent și reputația IP curată asigură că utilizatorii legitimi experimentează acces Vaultwarden fiabil în timp ce Fail2Ban blochează efectiv atacatorii fără pozitive false de la intervale IP partajate sau resurse supravândute cauzând eșecuri intermitente de conectivitate care ar putea declanșa banuri. Capacitățile snapshot permit testarea configurațiilor Fail2Ban în siguranță—creează un snapshot înainte de modificarea regulilor firewall, testează temeinic și restaurează instant dacă erorile de configurare blochează accidental accesul legitim.

Pentru întrebări despre configurarea VPS sau optimizarea infrastructurii pentru aplicații self-hosted, revizuiește Termenii și condițiile și contactează suportul tehnic pentru ghidare despre implementarea securității la nivel de rețea.

Concluzie

Fail2Ban cu Vaultwarden dockerizat în spatele Caddy necesită înțelegerea fluxului de pachete prin lanțurile iptables Docker, alinierea backend-ului firewall Fail2Ban cu sistemul activ Docker, țintirea lanțului corect pentru topologia reverse proxy-ului tău și asigurarea că Vaultwarden înregistrează IP-uri client reale în loc de adrese proxy. Problemele de bază—nepotriviri nftables/iptables, selecția lanțului INPUT versus DOCKER-USER și header-e IP real lipsă—fiecare previn independent banurile să blocheze atacatorii în ciuda Fail2Ban raportând aplicare cu succes.

Implementarea configurației complete furnizate în acest ghid rezolvă simultan toate cele trei moduri de eșec: forțarea banactions bazate pe iptables se potrivește cu backend-ul firewall Docker, specificarea chain="DOCKER-USER" țintește calea corectă de pachete, și configurarea header_up X-Real-IP în Caddy asigură că Vaultwarden înregistrează adrese IP semnificative. După aplicarea acestor modificări, Fail2Ban se transformă dintr-un fals sentiment de securitate în protecție genuină brute-force, blocând imediat atacatorii după încercări eșuate maxretry în timp ce menține acces fiabil pentru utilizatori legitimi. Testează temeinic, monitorizează regulat și combină Fail2Ban cu practici de securitate defense-in-depth pentru protecție password vault de grad producție.

Sursă și Atribuire

Aceast articol se bazează pe date originale ale ENGINYRING.COM. Pentru metodologia completă și pentru a asigura integritatea datelor, articolul original trebuie citat. Sursa canonică este disponibilă la: Rezolvarea Fail2Ban cu Vaultwarden dockerizat în spatele Caddy: de ce IP-urile "banate" continuă să ajungă la site și cum să rezolvi.