Firewall o WAF: cosa vede e cosa ferma ciascuno

Cosa decide un firewall stateful

Un firewall di Layer 3/4 traccia le connessioni e giudica ogni nuova connessione in base ai suoi indirizzi, alla sua porta e allo stato del flusso a cui appartiene. Cisco Firepower, OPNsense e netfilter lo fanno tutti bene: una porta che nessuna regola apre è chiusa, una risposta è ammessa solo per una connessione iniziata dall'interno, e le porte di gestione rispondono solo agli intervalli in allow list. La sua vista si ferma al livello di trasporto. Con TLS sul percorso non può vedere dentro il payload affatto, a meno che non termini la sessione, e anche in chiaro non ha alcun concetto di URL, header, stato di risposta o login.

Cosa aggiunge un WAF

Un web application firewall legge la transazione HTTP dopo la terminazione TLS, il che in pratica significa che vive nel reverse proxy o accanto a esso. Aggiunge tre tipi di controllo che il firewall non può esprimere. Le regole a firma, come ModSecurity con l'OWASP Core Rule Set, riconoscono injection, traversal e payload di exploit noti nella richiesta. Le regole comportamentali contano per client e per percorso: richieste al minuto sulla rotta di login, risposte di login fallito per indirizzo, segnali di bot negli header e nei tempi. Le regole positive dichiarano cosa accetta un percorso, per esempio quali metodi, quali content type e quale dimensione del body, e rifiutano il resto.

Un WAF non sostituisce il firewall. Vede solo il traffico che lo raggiunge, e non sa nulla di SSH, delle porte dei database o del piano di gestione.

Dove l'abuso dei login diventa visibile

Un login fallito è un fatto nella risposta. L'applicazione risponde a una POST sul percorso di login con uno stato o un redirect che distingue il fallimento dal successo, e il proxy lo scrive nel suo access log a ogni tentativo. Contare i fallimenti per client al minuto è una riga di awk su quel log, ed è il segnale che un packet filter non ha modo di vedere.

Il controllo deve essere agganciato al client, non all'account. Il blocco dell'account da solo ferma i tentativi contro un singolo nome utente e lo chiude fuori al suo proprietario, mentre il bot passa al nome successivo della sua lista. Un rate limit per client sulla rotta di login fa ciò che il blocco non può fare:

# nginx: at most 5 login attempts a minute per client, small burst allowed
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /login {
    limit_req zone=login burst=5 nodelay;
    proxy_pass http://app;
}

HAProxy esprime la stessa idea con una stick table agganciata all'indirizzo sorgente, e un set di regole WAF può contare direttamente il codice di risposta dei login falliti.

Come i due si combinano

L'ordine è firewall, poi terminazione TLS e proxy con le sue regole WAF, poi l'applicazione. Il rilevamento appartiene al Layer 7, perché è lì che stanno le prove. L'applicazione della misura può stare in uno dei due livelli. Il proxy può rispondere al client che abusa con un 429 o un 403 alla sua richiesta successiva, il che basta per la maggior parte degli abusi. Per un client che insiste, il proxy può spingere l'indirizzo nella tabella dinamica del packet filter per un periodo stabilito, il che fa cadere anche le altre connessioni di quel client e non costa nulla al firewall per pacchetto.

Due scelte di progetto vengono prima di armare quel circuito di feedback. Gli intervalli di gestione e monitoraggio dell'operatore vanno in allow list per primi, così un test o un refuso non possono chiudere fuori le persone che gestiscono la piattaforma. E gli indirizzi condivisi esistono davvero: il NAT di un ufficio o un carrier-grade NAT mettono molte persone dietro un solo indirizzo, quindi i blocchi hanno una scadenza breve e un modo documentato per rimuoverli. L'intera catena viene poi testata da un host fuori dalla rete, come la incontrerebbe un attaccante, prima che qualcuno ci faccia affidamento.

Cosa nessuno dei due vede

Una password corretta. Il credential stuffing con una password trapelata e valida sembra un login riuscito a ogni livello. Quella lacuna si chiude con l'autenticazione a più fattori sull'account e mettendo in allow list i percorsi amministrativi sul firewall, così che una credenziale valida sia inutile da un indirizzo che non è il vostro.