Come scegliere una policy di firewall efficace per proteggere i tuoi server

Introduzione

Utilizzare un firewall riguarda tanto prendere decisioni di politica intelligenti quanto imparare la sintassi. I firewall come iptables sono progettati per applicare politiche interpretando le regole impostate dall’amministratore. Tuttavia, come amministratore, è necessario sapere quali tipi di regole abbiano senso per la propria infrastruttura.

Mentre altri guide si concentrano sui comandi necessari per iniziare, in questa guida parleremo delle decisioni che dovrai prendere durante l’implementazione di un firewall. Queste scelte influenzeranno il comportamento del tuo firewall, quanto sia sicuro il tuo server e come risponderà a varie condizioni che si verificano. Utilizzeremo iptables come esempio specifico, ma la maggior parte dei concetti sarà ampiamente applicabile.

Decidere una politica predefinita

Quando si costruisce un firewall, una delle decisioni più importanti da prendere riguarda la policy predefinita. Questa determina cosa succede quando il traffico non corrisponde a nessuna altra regola. Per impostazione predefinita, un firewall può sia ACCETTARE qualsiasi traffico non corrispondente alle regole precedenti, o SCARTARE quel traffico.

Default Drop vs Default Accept

A default policy of ACCEPT means that any unmatched traffic is allowed to enter the server. This is generally not recommended, because it means that you would need to work backwards from there, blocking all unwanted traffic. Blocklist-type approaches are difficult to manage, because you’d need to anticipate and block every type of unwanted traffic. This can lead to maintenance headaches and is generally prone to mistakes, misconfigurations, and unanticipated holes in the established policy.

Come alternativa, c’è la policy predefinita di SCARTARE. Ciò significa che qualsiasi traffico non corrispondente a una regola esplicita non sarà consentito. Ogni servizio deve essere esplicitamente autorizzato, il che potrebbe sembrare una quantità significativa di configurazione iniziale. Tuttavia, ciò significa che la tua policy tende verso la sicurezza e che sai esattamente cosa è consentito ricevere traffico sul tuo server. Inoltre, quasi tutte le policy preconfigurate seguiranno questo approccio, il che significa che puoi basarti sulle impostazioni predefinite esistenti.

Default Drop Policy vs Final Drop Rule

La scelta di una policy di default di scarto porta a un’altra decisione sottile. Con iptables e altri firewall simili, la policy predefinita può essere impostata utilizzando la funzionalità di policy integrata del firewall, o implementata aggiungendo una regola di scarto catch-all alla fine dell’elenco delle regole.

La distinzione tra questi due metodi si basa su cosa succede se le regole del firewall vengono azzerate.

Se la funzione di politica integrata nel tuo firewall è impostata su DROP e le regole del firewall vengono azzerate (ripristinate), o se determinate regole di corrispondenza vengono rimosse, i tuoi servizi diventeranno immediatamente inaccessibili in remoto. Questa è spesso un’ottima idea quando si imposta la politica per servizi non critici in modo che il tuo server non sia esposto a traffico dannoso se le regole vengono rimosse.

L’inconveniente di questo approccio è che i tuoi servizi saranno completamente non disponibili ai tuoi clienti fino a quando non stabilirai nuovamente regole permissive. Potresti addirittura trovarti bloccato fuori dal server se non hai accesso remoto locale o basato sul web come alternativa.

Un’alternativa all’impostazione di una politica di drop utilizzando la funzionalità di politica integrata è impostare la politica predefinita del tuo firewall su ACCEPT e quindi implementare una politica DROP con regole regolari. Puoi aggiungere una normale regola del firewall alla fine della tua catena che corrisponde e nega tutto il traffico rimanente non corrisposto.

In questo caso, se le regole del tuo firewall vengono azzerate, i tuoi servizi saranno accessibili ma non protetti. A seconda delle tue opzioni di accesso locale o alternativo, potrebbe essere un male necessario per garantire che tu possa rientrare nel tuo server se le regole vengono azzerate. Se decidi di utilizzare questa opzione, assicurati che la regola di cattura tutto rimanga sempre l’ultima regola nel tuo set di regole.

Dropping vs Rejecting Traffic

Ci sono diversi modi per impedire a un pacchetto di raggiungere la sua destinazione prevista. La scelta tra questi ha un impatto su come il client percepisce il tentativo di connessione e quanto velocemente può determinare che la sua richiesta non verrà servita.

Il primo modo in cui i pacchetti possono essere negati è con DROP. Drop può essere utilizzato come politica predefinita o come target per le regole di corrispondenza. Quando un pacchetto viene droppato, iptables lo scarta semplicemente. Non invia alcuna risposta al client che cerca di connettersi e non fornisce alcuna indicazione che abbia mai ricevuto i pacchetti in questione. Ciò significa che i client (legittimi o meno) non riceveranno alcuna conferma della ricezione dei loro pacchetti.

Per i tentativi di connessione TCP (come le connessioni effettuate da un browser web), la connessione si interromperà fino a quando non sarà stato raggiunto il limite di timeout. La mancanza di risposta per i client UDP è ancora più ambigua. Infatti, non ricevere un pacchetto UDP indietro è spesso un’indicazione che il pacchetto è stato accettato. Se il client UDP si preoccupa della ricezione dei suoi pacchetti, dovrà rinviarli per cercare di determinare se sono stati accettati, persi durante il trasporto o droppati. Questo può aumentare il tempo che un attore malintenzionato dovrà trascorrere per ottenere informazioni sullo stato delle porte del tuo server, ma potrebbe anche causare problemi con il traffico legittimo.

Un’alternativa al lasciare cadere il traffico è quella di respingere esplicitamente i pacchetti che non si desidera permettere. ICMP, o Internet Control Message Protocol, è un meta-protocollo utilizzato in tutto Internet per inviare messaggi di stato, diagnostici e di errore tra gli host come un canale out-of-band che non si basa su protocolli di comunicazione convenzionali come TCP o UDP. Quando si utilizza il target REJECT invece del target DROP, il traffico viene negato e viene restituito un pacchetto ICMP al mittente per informarlo che il suo traffico è stato ricevuto ma non sarà accettato. Un messaggio di stato può anche essere incluso per fornire una ragione.

Ciò ha una serie di conseguenze. Presumendo che il traffico ICMP sia consentito di raggiungere il client, verranno immediatamente informati che il loro traffico è bloccato. Per i client legittimi, ciò significa che possono contattare l’amministratore o controllare le loro opzioni di connessione per assicurarsi di raggiungere la porta corretta. Per gli utenti malintenzionati, ciò significa che possono completare le loro scansioni e mappare le porte aperte, chiuse e filtrate in un periodo più breve di tempo.

C’è molto da considerare nella decisione se lasciare cadere o respingere il traffico. Una considerazione importante è che la maggior parte del traffico malevolo in realtà sarà perpetrato da script automatizzati. Poiché questi script di solito non sono supervisionati, il lasciare cadere il traffico illegittimo non li scoraggerà in modo significativo e avrà effetti negativi per gli utenti legittimi. Maggiori informazioni su questo argomento possono essere trovate sul sito web di Peter Benie.

Tabella delle risposte di rifiuto vs. drop

La tabella sottostante mostra come un server protetto da un firewall reagirà a diverse richieste a seconda della policy applicata alla porta di destinazione.

La prima colonna indica il tipo di pacchetto inviato dal client. La seconda colonna contiene i comandi nmap che possono essere utilizzati per testare ogni scenario. La terza colonna indica la policy di porta applicata alla porta. La quarta colonna è la risposta che il server invierà e la quinta colonna è ciò che il client può dedurre sulla porta in base alla risposta ricevuta.

Policy ICMP

Come per la decisione se scartare o rifiutare il traffico negato, hai la possibilità di accettare o rifiutare i pacchetti ICMP destinati al tuo server.

ICMP è un protocollo utilizzato per molte cose. Come accennato, spesso viene inviato per fornire informazioni sullo stato delle richieste utilizzando altri protocolli. Una delle sue funzioni più popolari è inviare e rispondere a ping di rete per verificare la connettività con host remoti. Ci sono molti altri utilizzi di ICMP che non sono così noti, ma comunque utili.

I pacchetti ICMP sono organizzati per “tipo” e poi ulteriormente per “codice”. Un tipo specifica il significato generale del messaggio. Ad esempio, il Tipo 3 significa che la destinazione non è raggiungibile. Un codice viene spesso utilizzato per fornire ulteriori informazioni su un tipo. Ad esempio, ICMP Tipo 3 Codice 3 significa che la porta di destinazione non era disponibile, mentre ICMP Tipo 3 Codice 0 significa che la rete di destinazione non poteva essere raggiunta.

Tipi da bloccare a seconda della configurazione di rete

Alcuni tipi ICMP sono utili in determinate configurazioni di rete, ma dovrebbero essere bloccati in altre.

Ad esempio, i messaggi di reindirizzamento ICMP (tipo 5) possono essere utili per illuminare una cattiva progettazione di rete. Un reindirizzamento ICMP viene inviato quando è disponibile un percorso migliore direttamente per il client. Quindi, se un router riceve un pacchetto che dovrà essere instradato verso un altro host sulla stessa rete, invia un messaggio di reindirizzamento ICMP per indicare al client di inviare i pacchetti attraverso l’altro host in futuro.

Questo è utile se ti fidi della tua rete locale e vuoi individuare inefficienze nelle tue tabelle di routing durante la configurazione iniziale. In una rete non attendibile, un utente malintenzionato potrebbe potenzialmente inviare reindirizzamenti ICMP per manipolare le tabelle di routing sugli host.

Altri tipi di ICMP che sono utili in alcune reti e potenzialmente dannosi in altre sono i pacchetti di annuncio del router (tipo 9) e le richieste del router (tipo 10). I pacchetti di annuncio e di richiesta del router sono utilizzati come parte di IRDP (Protocollo di scoperta del router Internet Control Message Protocol), un sistema che consente agli host, durante l’avvio o l’accesso a una rete, di scoprire dinamicamente i router disponibili.

Nella maggior parte dei casi, è meglio che un host abbia percorsi statici configurati per i gateway che utilizzerà. Questi pacchetti dovrebbero essere accettati nelle stesse situazioni dei pacchetti di reindirizzamento ICMP. Infatti, poiché l’host non conoscerà il percorso preferito per il traffico di eventuali percorsi scoperti, i messaggi di reindirizzamento sono spesso necessari subito dopo la scoperta. Se non stai eseguendo un servizio che invia pacchetti di richiesta del router o modifica i tuoi percorsi in base ai pacchetti di annuncio (come rdisc), puoi bloccare in modo sicuro questi pacchetti.

Tipi che sono spesso sicuri da consentire

I tipi di ICMP che di solito sono sicuri da consentire sono elencati di seguito, ma potresti volerli disabilitare se vuoi essere particolarmente attento.

• Tipo 8 — Richiesta di eco: Queste sono richieste di ping dirette al tuo server. Di solito è sicuro permetterle (negare questi pacchetti non nasconde il tuo server, dato che ci sono molti altri modi per gli utenti per scoprire se il tuo host è attivo), ma puoi bloccarle o limitare gli indirizzi di origine a cui rispondi se preferisci.
• Tipo 13 — Richiesta di timestamp: Questi pacchetti possono essere utilizzati dai client per raccogliere informazioni sulla latenza. Possono essere utilizzati in alcune tecniche di fingerprinting OS, quindi puoi bloccarli o limitare il range degli indirizzi a cui rispondi.

I tipi sottostanti di solito possono essere consentiti senza regole esplicite configurando il tuo firewall per consentire risposte alle richieste che ha effettuato (utilizzando il modulo conntrack per consentire il traffico ESTABLISHED e RELATED).

• Tipo 0 — Risposte di eco: Queste sono risposte alle richieste di eco (ping).
• Tipo 3 — Destinazione non raggiungibile: I pacchetti legittimi di destinazione non raggiungibile sono risposte alle richieste create dal tuo server che indicano che il pacchetto non poteva essere recapitato.
• Tipo 11 — Tempo scaduto: Si tratta di un errore diagnostico restituito se un pacchetto generato dal tuo server è morto prima di raggiungere la destinazione a causa del superamento del suo valore TTL.
• Tipo 12 — Problema di parametro: Questo significa che un pacchetto in uscita dal tuo server era malformato.
• Tipo 14 — Risposte di timestamp: Queste sono le risposte alle query di timestamp generate dal tuo server.

Bloccare tutto il traffico ICMP in ingresso è ancora raccomandato da alcuni esperti di sicurezza, tuttavia molte persone ora incoraggiano politiche di accettazione ICMP intelligenti. Questi due thread di Stackexchange hanno ulteriori informazioni.

Limitazione della Connessione e Limitazione del Tasso

Per alcuni servizi e modelli di traffico, potresti voler consentire l’accesso solo fintanto che il client non abusa di tale accesso. Due modi per limitare l’utilizzo delle risorse sono la limitazione della connessione e la limitazione del tasso.

Limitazione della Connessione

La limitazione della connessione può essere implementata utilizzando estensioni come connlimit per verificare quante connessioni attive ha aperto un client. Questo può essere utilizzato per limitare il numero di connessioni consentite contemporaneamente. Se decidi di imporre limiti di connessione, dovrai prendere alcune decisioni:

• Limiti per indirizzo, rete o globali?
• Corrispondi e limita il traffico per un servizio specifico o per l’intero server?

Le connessioni possono essere limitate su base host per host o è possibile impostare un limite per un segmento di rete fornendo un prefisso di rete (come un intervallo di indirizzi IP per un’intera organizzazione). È anche possibile impostare un numero massimo globale di connessioni per un servizio o per l’intera macchina. Tieni presente che è possibile combinare queste opzioni per creare politiche più complesse per controllare il numero di connessioni.

Limitazione della velocità

La limitazione della velocità consente di definire regole che governano la frequenza con cui il traffico verrà accettato dal server. Esistono diverse estensioni del firewall che possono essere utilizzate per la limitazione della velocità, tra cui limit, hashlimit e recent. La scelta dell’estensione da utilizzare dipenderà principalmente dal modo in cui si desidera limitare il traffico.

L’estensione limit farà corrispondere la regola in questione fino a quando il limite non verrà raggiunto, dopodiché i pacchetti successivi verranno eliminati. Un limite come 5/sec permetterà la corrispondenza di 5 pacchetti al secondo, dopodiché la regola non farà più corrispondenza. Questo è utile per impostare un limite di velocità globale per un servizio. È anche possibile utilizzare un servizio aggiuntivo come Fail2ban per bloccare i tentativi di connessione ripetuti.

La hashlimit extension è più flessibile, consentendoti di specificare alcuni dei valori che iptables utilizzerà per hashare e valutare una corrispondenza. Ad esempio, può esaminare l’indirizzo di origine, la porta di origine, l’indirizzo di destinazione, la porta di destinazione o una combinazione di questi quattro valori per valutare ciascuna voce. Può limitare per pacchetti o per byte ricevuti. Ciò fornisce un limite flessibile per singolo cliente o servizio.

La recent extension aggiunge dinamicamente gli indirizzi IP dei client a un elenco o li verifica in un elenco esistente quando la regola corrisponde. Ciò consente di distribuire la logica di limitazione su diverse regole per modelli complessi. Ha la capacità di specificare un conteggio colpi e un intervallo di tempo come gli altri limitatori, ma può anche reimpostare l’intervallo di tempo se viene rilevato traffico aggiuntivo, costringendo un cliente a interrompere tutto il traffico se viene limitato.

Gestione Monolitica vs Basata su Catena

Tutte le politiche del firewall di iptables e nftables sono essenzialmente radicate nell’estensione delle catene integrate. Inizialmente, ciò significa modificare la politica predefinita per le catene esistenti e aggiungere regole. Per firewall più complessi, spesso è una buona idea estendere il framework di gestione creando catene aggiuntive.

Le catene create dagli utenti sono chiamate secondariamente e sono intrinsecamente legate alla loro “catena di chiamata” di origine. Le catene create dagli utenti non hanno una politica predefinita, quindi se un pacchetto passa attraverso una catena creata dall’utente, tornerà alla catena di chiamata e continuerà la valutazione. Tenendo presente ciò, le catene create dagli utenti sono principalmente utili per scopi organizzativi, per rendere le condizioni di corrispondenza delle regole più mantenibili e per migliorare la leggibilità suddividendo le condizioni di corrispondenza.

Se ti trovi a ripetere determinati criteri di corrispondenza per un numero significativo di regole, potrebbe valere la pena creare una regola di salto con i criteri di corrispondenza condivisi per una nuova catena. All’interno della nuova catena, puoi aggiungere quel set di regole con i criteri di corrispondenza ridondanti omessi.

La decisione se raggruppare tutte le tue regole in una delle catene incorporate o creare e utilizzare catene aggiuntive dipenderà da quanto complesso è il tuo set di regole.

Conclusione

Ora dovresti avere una migliore comprensione delle decisioni che dovrai prendere quando progetti le politiche del firewall per i tuoi server. Di solito, l’investimento di tempo coinvolto nei firewall tende ad essere fortemente orientato alla configurazione iniziale. Sebbene possa richiedere un po’ di tempo e sperimentazione per trovare una politica che meglio soddisfi le tue esigenze, farlo ti darà un maggiore controllo sulla sicurezza del tuo server.

Se desideri saperne di più sui firewall e specificamente su iptables, dai un’occhiata ai seguenti articoli:

• Come funziona il firewall Iptables
• A Deep Dive into Iptables and Netfilter Architecture

Le seguenti guide possono aiutarti a implementare le tue politiche. Scegli la guida che corrisponde al tuo firewall per iniziare:

• Come configurare un firewall utilizzando Nftables su Ubuntu 22.04
• Come configurare un firewall con UFW su Ubuntu 22.04
• Come configurare un firewall utilizzando FirewallD su Rocky Linux 9