In questo articolo presentiamo le migliori pratiche per la configurazione delle regole di filtraggio su un firewall. Utilizzeremo come esempio la configurazione di un firewall pfSense, ma tutte queste raccomandazioni sono applicabili ad altri firewall presenti sul mercato.
Raccomandazioni generali
La definizione di una politica di gestione del firewall deve essere strutturata e standardizzata, in modo che tutti coloro che partecipano alla configurazione dell’apparecchiatura abbiano un chiaro riferimento di lavoro e un modo uniforme di procedere.
A tal fine, si consiglia di applicare i seguenti principi:
1.La configurazione viene eseguita sull’interfaccia di arrivo dei pacchetti.
Quando si configurano le regole di filtraggio su un firewall, sono possibili due approcci: applicare il filtraggio quando il pacchetto di rete arriva al firewall, noto come filtraggio in ingress, o applicare il filtraggio quando il pacchetto di rete lascia il firewall, noto come filtraggio in egress.
In altre parole, per filtrare il traffico che va, ad esempio, dalla LAN a Internet o alla WAN, la configurazione deve essere effettuata sull’interfaccia LAN.
Questa è l’unica modalità operativa offerta da pfSense (filtraggio sull’interfaccia di arrivo dei pacchetti).
Per essere precisi, pfSense può filtrare sull’interfaccia di uscita del firewall dalle regole floating; ma questo non è chiaramente lo scopo principale delle regole floating.
2.È necessario essere il più precisi possibile.
Quando si scrivono le regole di filtraggio, bisogna sempre essere il più precisi possibile. Più una regola è precisa, meglio è. In primo luogo, perché si può essere certi che solo il traffico desiderato corrisponderà a questa regola e, in secondo luogo, perché le regole di filtraggio saranno molto più facili da leggere e da capire.
Quindi, non appena si conoscono l’indirizzo IP, la rete di origine o di destinazione, la porta di destinazione e il protocollo (TCP, UDP, ecc.), è necessario specificarli nella regola.
Nell’organizzare la politica di filtraggio, è importante anche classificare le regole dalla più precisa alla più ampia.
Le regole molto specifiche (riguardanti solo alcune postazioni di lavoro, ad esempio) saranno anteposte a quelle più ampie (riguardanti l’intera rete locale, ad esempio).
3.Specificare sempre l’origine per le interfacce interne.
È importante specificare sistematicamente l’indirizzo IP o la rete di origine quando i pacchetti da filtrare provengono dalla rete locale. In questo caso, gli indirizzi IP o la rete di origine sono noti. Non c’è quindi motivo di lasciare l’origine come “any” o *.
Come promemoria, nelle regole di filtraggio di pfSense, il valore “LAN address” corrisponde all’indirizzo IP del firewall sulla sua interfaccia LAN (192.168.1.1, ad esempio) e il valore “LAN net” corrisponde all’intera sottorete dell’interfaccia LAN (192.168.1.0/24, ad esempio).
4.Specificare la destinazione, se conosciuta.
Non appena è possibile identificare la destinazione di un flusso di rete, è importante non lasciare una destinazione generica nelle regole di filtraggio.
Ad esempio, se si desidera autorizzare il traffico DNS verso i server Quad9, non c’è motivo di non specificare gli indirizzi IP dei server Quad9 nella regola di filtro associata.
Allo stesso modo, se si desidera inviare e-mail, non c’è motivo di autorizzare il traffico SMTP verso una destinazione diversa dal proprio server di relay e-mail.
Essere il più precisi possibile nelle regole di filtraggio è una garanzia di sicurezza per la rete, gli utenti e i dati.
L’uso di una destinazione generica (any o *) dovrebbe essere riservato solo al traffico di cui non è possibile conoscere la destinazione.
5.Utilizzo di alias.
L’uso degli alias migliora notevolmente la leggibilità e consente di raggruppare gli indirizzi IP o le porte associate in un’unica regola di filtro.
Va notato che alcuni firewall richiedono l’uso di alias nella scrittura delle loro regole: non è possibile inserire una regola di filtraggio che contenga indirizzi IP o porte di rete; essi devono essere prima inseriti in alias. pfSense non richiede questo metodo operativo.
In pfSense, gli alias vengono creati dal menu Firewall > Aliases:
Gli alias devono essere raggruppati per area funzionale. Ad esempio, si può creare un alias per la navigazione Web contenente le porte HTTP e HTTPS.
Ad esempio, sotto pfSense:
Naturalmente, è necessario ricordarsi di salvare e poi applicare le modifiche.
6.Suddividere e raggruppare le regole.
La maggior parte dei firewall moderni //// <<<LIEN VERS BOUTIQUE //// offre la possibilità di utilizzare separatori o colori per suddividere e/o raggruppare le regole. Se il vostro firewall non dispone di questa funzione, prendete in considerazione la possibilità di migrare a pfSense 😉
Questa suddivisione e organizzazione rende le regole più facili da leggere e consente di amministrare la soluzione molto più rapidamente.
7.Commento, commento, commento.
Per mantenere una comprensione della storia dell’implementazione della regola, è essenziale aggiungere informazioni utili al campo dei commenti.
Ad esempio, il campo dei commenti potrebbe contenere le seguenti informazioni:
- la breve descrizione funzionale che ha portato alla creazione della regola ;
- la data di implementazione della regola (questa informazione è gestita automaticamente da pfSense) ;
- il riferimento della richiesta (numero di ticket o codice del progetto);
- il nome o il numero di matricola della persona che ha creato o modificato la regola (questa informazione è gestita automaticamente da pfSense, a patto che non tutti utilizzino l’account “admin” di default…)
Ordine delle regole di filtraggio
Una volta applicate le raccomandazioni generali, classifichiamo le nostre regole di filtraggio nell’ordine indicato di seguito.
1/5. Regole di autorizzazione per i flussi verso il firewall (amministrazione; servizi ospitati su pfSense)
Idealmente, il firewall dovrebbe essere amministrato da un’interfaccia dedicata. Se non dispone di un’interfaccia dedicata, è necessario almeno definire gli indirizzi IP di origine autorizzati.
Un buon modo per farlo è quello di prendere il controllo di un server di bounce (ad esempio, un server TSE), quindi connettersi al firewall. In questo caso, solo il server di bounce è autorizzato ad accedere all’interfaccia di amministrazione del firewall.
Il numero di flussi aperti deve essere ridotto al minimo (HTTPS + SSH – se necessario – nel caso di pfSense).
Esistono anche regole che autorizzano la supervisione del firewall (ad esempio snmp) e i servizi ospitati sul firewall (Squid, OpenVPN, DHCP, NTP, ecc.). ////<<<<LIENS VERS LES ARTICLES DEDIES /////
Per queste regole verranno specificati gli indirizzi IP di origine e di destinazione.
Per queste regole verranno attivati dei registri, in modo da poter rintracciare in seguito eventuali accessi anomali o fraudolenti.
Esempio di implementazione di queste regole per pfSense :
2/5. Regole di autorizzazione per i flussi inviati dal firewall (pfSense non è interessato)
Queste includono: regole che autorizzano l’invio dei log del firewall al server di logging (un server syslog, ad esempio), regole che autorizzano i servizi di avviso del gateway (avvisi e-mail, smtp, ecc.), regole che autorizzano i servizi MCO del gateway (flussi di backup – ssh, ad esempio).
In tutti i casi, è necessario specificare la destinazione (non utilizzare una destinazione “any” o *).
Anche per queste regole è necessario attivare i registri.
/!\ pfSense non è influenzato da queste regole. pfSense filtra i pacchetti che arrivano sulle sue interfacce. I pacchetti inviati dal firewall non vengono filtrati.
Se si desidera filtrare il traffico emesso da pfSense, è possibile utilizzare regole floating in cui il filtraggio viene applicato in direzione OUT.
Tuttavia, se si applica il filtraggio in questo modo, si filtrerà anche il traffico proveniente dalla LAN che ha preso l’indirizzo IP del firewall (SNAT / Outbound NAT). I pacchetti dovrebbero quindi essere contrassegnati per identificare con maggiore precisione la loro origine. Ma questo non è l’argomento di questo articolo.
3/5. Regole di protezione del firewall (regole specifiche)
In linea con la logica che tutto ciò che non è esplicitamente autorizzato deve essere proibito, è necessario impostare una regola di filtraggio per proibire tutti i servizi da tutte le fonti a tutte le interfacce del firewall.
In questo modo il firewall diventa invisibile e blocca tutti i servizi non necessari.
I log devono essere abilitati per questa regola.
4/5. Regole di autorizzazione dei flussi commerciali
Si consiglia di organizzare le regole in base a una logica aziendale. Sono possibili diversi approcci:
- organizzazione per unità di business (raggruppando le regole del reparto contabilità, risorse umane, acquisti, ecc;)
- organizzazione per funzioni e servizi offerti: accesso alle banche dati, accesso alla rete intranet, accesso al server di posta, accesso a Internet, ecc.
Queste regole devono essere adattate al contesto e mantenere una logica tra loro (ad esempio, non si deve passare da una logica di entità a una logica di funzione lungo il percorso).
In queste regole devono essere specificati gli indirizzi e i servizi di origine e di destinazione.
Queste regole costituiscono il nucleo della politica di filtraggio.
Esempio di risultato ottenuto su un pfSense:
5/5. Regola di divieto finale (inutile per pfSense)
Tutto ciò che non è stato esplicitamente autorizzato in precedenza deve essere bloccato.
Questa è la modalità operativa predefinita di pfSense: default deny.
Non è quindi necessario aggiungere una regola specifica per pfSense.
Per impostazione predefinita, questi pacchetti vengono registrati da pfSense, il che consente di tenere traccia di questi flussi non legittimi (o di aiutare nella troubleshooting in caso di errore o anomalia nella configurazione delle regole precedenti).
Applicando questa strategia, si ottiene il seguente esempio completo:
Si consiglia di seguire questi principi per organizzare le regole di filtraggio. In questo modo sarà più facile gestire il firewall e le sessioni di analisi e risoluzione dei problemi! ////<<<LIEN VERS ARTICLE ////
Per saperne di più