Una banaction, due trasporti: riparare una jail fail2ban per VPN

Niente in fail2ban scarta un pacchetto da solo: invoca un'azione, ed è quell'azione a nominare un protocollo e una porta. Quando la jail segnala un ban mentre il demone continua ad accettare accessi, il ban di solito è reale e più stretto di quanto implichi il registro. Un client che si riconnette sull'altro trasporto non incontra mai la regola installata. Confrontate ciò che l'azione ha installato con ciò su cui il demone ascolta prima di cambiare qualsiasi cosa, perché la prova sta nella catena del firewall che l'azione ha scritto, non nell'elenco della jail.

Leggete la catena, non il riepilogo della jail

fail2ban inserisce la propria catena davanti alla catena del servizio, così un elenco dei contatori mostra esattamente ciò che esiste. Una catena intitolata alla jail, che contiene una sola regola la cui colonna del protocollo dice udp, è una spiegazione completa per gli accessi TCP che continuano ad arrivare. Solo i pacchetti UDP provenienti dall'origine bloccata vengono rifiutati. Il servizio ha un listener TCP, e nulla in quella catena lo tocca.

Attenzione anche all'effetto della jail vicina. Un host può sembrare perfettamente configurato solo perché un'altra jail fornisce la metà mancante, e la stessa build non fa nulla dove quella jail non è installata.

L'azione nomina un solo protocollo, ed è lì che si rompe

Ogni banaction è un modello di comando del firewall, e il protocollo sta in uno dei suoi segnaposto. La strettezza è intenzionale, dato che una jail web e una jail DNS non hanno nulla a che fare con il bloccare porte identiche. Diventa una trappola quando il servizio ascolta su più di un trasporto, cosa che i demoni VPN fanno abitualmente. Il filtro può sorvegliare gli accessi falliti di entrambi i trasporti mentre l'azione ne copre uno.

Le installazioni di SoftEther e OpenVPN di solito ascoltano su UDP e TCP insieme, e poiché la riga di registro appare uguale in entrambi i casi il filtro sorveglia entrambi. L'asimmetria non compare mai nel rapporto della jail stessa. fail2ban ha contato correttamente i fallimenti e poi ha installato una regola che vale per metà del traffico su cui quei fallimenti sono arrivati.

Fate coprire entrambi i trasporti al ban

Correggete invece nella definizione della jail; le regole scritte a mano verranno rimescolate al prossimo ricaricamento. Scrivete due azioni, una per ogni protocollo:

action = %(banaction)s[name=%(__name__)s-tcp, actionname=%(__name__)s-tcp, protocol="tcp", port="%(port)s", chain="%(chain)s"]
         %(banaction)s[name=%(__name__)s-udp, actionname=%(__name__)s-udp, protocol="udp", port="%(port)s", chain="%(chain)s"]

Non provate ad accorciarlo con protocol = all. La banaction predefinita è un'azione multiport, e si espande in -p <protocol> -m multiport --dports <port>; senza protocollo L4 non c'è nulla che la corrispondenza della porta possa verificare, quindi iptables rifiuta la regola mentre la jail segnala ancora un ban riuscito. Un'azione di tutte le porte come iptables-allports o nftables-allports accetta una sola voce, ma blocca ogni porta su quell'origine, che è una decisione diversa e richiede una propria giustificazione. Lasciate protocol su tcp o udp e accettate le due voci.

Dimostrate che la regola esiste invece di fidarvi dell'impostazione, perché un'impostazione descrive un'intenzione finché una catena non la sostiene:

iptables -S f2b-vpn-tcp
iptables -S f2b-vpn-udp

Ogni catena dovrebbe elencare una regola, con -p tcp nella prima e -p udp nella seconda, entrambe che nominano l'indirizzo bloccato. Poi confermate che lo stesso indirizzo viene rifiutato su entrambi i trasporti. Un ban che non avete visto nella catena è una speranza, e il prossimo rapporto sullo stesso sintomo costerà di nuovo la stessa ora.

Ciò che un ban ancora manca, e il prossimo caso

Ciò che l'azione fa è rifiutare una singola origine, e solo sulle porte elencate in essa. Non fa nulla contro un attaccante che ruota gli indirizzi, e non può separare una macchina ostile da un'uscita NAT di livello operatore condivisa da centinaia di utenti, dove un solo ban esclude persone che non hanno fatto nulla. Assicuratevi che il filtro legga l'indirizzo che il client ha davvero, non un'intestazione inoltrata né un indirizzo proxy. Tenete la finestra abbastanza corta perché un errore scada da solo.

Niente di tutto ciò sostiene che si salti la correzione del protocollo; sostiene che si tengano due idee insieme. Il ban è più stretto di quanto suggerisca il riepilogo della jail, e perfino un ban completo è più stretto della minaccia. Mettete la catena del firewall accanto all'elenco dei listener del demone e confrontate protocollo per protocollo, perché sono quelle due liste a decidere se un ban può raggiungere il servizio.

Tenete il comando di ricaricamento e l'elenco delle catene nel runbook accanto alla jail. La persona successiva avrà bisogno di entrambi, e il riepilogo della jail non le dirà né l'uno né l'altro.