Appunti per regole firewall su OPNsense
Come già trattato in questi meandri riguardo le regole firewall su OPNsense ho pensato che sarebbe stata una buona idea consolidare e determinare varietà di scenari in un unico how-to magari per utilizzarla come guida rapida di riferimento su alcuni esempi specifici e sul come bloccare o consentire determinati tipi di traffico di rete.
Iniziamo
Vale la pena specificare che tutti gli indirizzi IP utilizzati in questo esempio potrebbero essere sostituiti e gestiti tramite degli alias, questo se prevediamo in special modo di creare più regole per un determinato dispositivo o si desidera combinare insieme più indirizzi IP di rete in un’unica regola. Gli alias consentono di specificare più valori ed è possibile modificare rapidamente i valori per più regole definite contemporaneamente. Aiuta anche a rendere le regole più leggibili dato che non dovrai ricordare il numero ip “192.168.10.10” su quale dispositivo è associato.
Per aggiungere nuove regole firewall per le varie interfacce di rete, vai alla pagina “Rules > Firewall”. Verrà visualizzato l’elenco di interfacce su cui è possibile definire regole.
Regole LAN/VLAN
Quando si crea una nuova VLAN o una rete su un’altra interfaccia fisica, l’accesso a tutte le altre reti viene bloccato di default poiché non sono definite regole su la nuova rete (oltre a quelle nascoste generate automaticamente necessarie per il funzionamento del DHCP, ad esempio).Molti di questi esempi presuppongono che si disponga di uno scenario con più reti locali e che si desideri consentire la comunicazione tra dispositivi presenti i queste diverse reti.
Vengono riportati di seguito alcuni scenari per la creazione di policy per le interfacce LAN/VLAN:
Consenti ad un dispositivo su “VLAN 10” di accedere a qualsiasi porta di un dispositivo su “VLAN 20”
Questa policy consente al dispositivo con l’indirizzo IP “192.168.10.10” su VLAN 10 di accedere a qualsiasi servizio aperto e in esecuzione sul dispositivo con l’indirizzo IP “192.168.20.10” che risiede su VLAN 20:
| Option | Value |
|---|---|
| Action | Pass |
| Interface | VLAN10 |
| Protocol | any |
| Source | 192.168.10.10 |
| Source Port | any |
| Destination | 192.168.20.10 |
| Destination Port | any |
| Description | Consentire accesso tra device |
Consenti a qualsiasi dispositivo su “VLAN 10” di accedere verso qualsiasi porta di un dispositivo su “VLAN 20”
Questa policy consente a tutti i dispositivi su VLAN 10 di accedere a qualsiasi servizio esposto e in esecuzione sul dispositivo con l’indirizzo IP “192.168.20.10” che risiede su VLAN 20:
| Option | Value |
|---|---|
| Action | Pass |
| Interface | VLAN10 |
| Protocol | any |
| Source | VLAN10 |
| Source Port | any |
| Destination | 192.168.20.10 |
| Destination Port | any |
| Description | Consentire VLAN 10 ad accedere al device |
Consentire a qualsiasi dispositivo di accedere a qualsiasi rete o dispositivo (reti locali e Internet)
Questa è la regola standard “consenti tutto - Allow All” creata da OPNsense sull’interfaccia LAN quando si installa OPNsense.
| Option | Value |
|---|---|
| Action | Pass |
| Interface | LAN |
| Protocol | any |
| Source | any |
| Source Port | any |
| Destination | any |
| Destination Port | any |
| Description | Consentire accesso a qualsiasi rete/device |
Se si utilizza questa regola, consiglio di limitare il più possibile il traffico di rete con altre policy definite più specifiche e restrittive sopra questa regola per ridurre al minimo il traffico indesiderato. Quando si ha regole più restrittive al di sopra di questa, diventa essenzialmente una regola “consenti a tutti gli altri” quindi consente il passaggio di qualsiasi traffico che non hai esplicitamente bloccato. Probabilmente è utile in un ambiente di rete domestica, dove non è necessario modificare costantemente le regole firewall per consentire ogni diverso tipo di traffico. In un ambiente aziendale o di “Produzione” disolito è presente di default il “negare tutto il resto - Deny all other” per essere il più restrittivi possibili, in quest’ultimo caso non si definirebbe la seguente regola “consenti tutto - Allow All” in fondo all’elenco.
(Suggerimento) Bloccare qualsiasi dispositivo ad accedere alle Reti Private
Se si vuole optare per la definizione della regola che abbiamo trattato poco sopra per un ambiente domestico, consiglio di definire sopra di essa una regola (attraverso alias “PrivateRanges” dove definite le diverse reti private) che blocca ogni rete/dispositivo ad accedere a queste. Per reti private si intendono alcune classi di indirizzi IPv4 definite nella RFC 1918 riservate alle reti locali create con lo scopo di ridurre le richieste per gli indirizzi pubblici.
| Option | Value |
|---|---|
| Action | Rejects |
| Interface | LAN1 |
| Protocol | any |
| Source | any |
| Source Port | any |
| Destination | PrivateRanges |
| Destination Port | any |
| Description | Bloccare accesso a qualsiasi rete/device su Ip range privati |
Impedire ad un singolo dispositivo su VLAN 10 di accedere a Internet
Se è necessario bloccare l’accesso a Internet e ad altre reti locali (come VLAN 20) per un particolare dispositivo con l’indirizzo IP “192.168.10.10” su VLAN 10:
| Option | Value |
|---|---|
| Action | Block |
| Interface | VLAN10 |
| Protocol | any |
| Source | 192.168.10.10 |
| Source Port | any |
| Destination | any |
| Destination Port | any |
| Description | Bloccare accesso a Internet |
Se le VLAN sono già isolate l’una dall’altra, l’accesso ad altre reti locali è bloccato, quindi questa regola aggiunge essenzialmente il blocco ad accedere su Internet.
Questa regola non blocca l’accesso a quel dato dispositivo per qualsiasi altra cosa all’interno della “VLAN 10”, perché qualsiasi traffico da un dispositivo all’altro all’interno della stessa VLAN è considerato traffico locale e non passa attraverso il router/firewall, il che significa che nessuna delle regole del firewall per VLAN 10 viene elaborata per tale traffico.
Blocca l’accesso a Internet su tutti i dispositivi presenti nella VLAN 10
Per bloccare tutti i dispositivi sull’intera rete “VLAN 10”, è sufficiente non definire alcuna policy firewall per l’interfaccia VLAN 10. di default, tutto il traffico in uscita è bloccato sia su Internet che su altre VLAN, quindi questa regola sarebbe ridondante. Tuttavia, ai fini dell’illustrazione e dell’apprendimento, la seguente regola bloccherebbe tutto il traffico in uscita (outbound):
| Option | Value |
|---|---|
| Action | Block |
| Interface | VLAN10 |
| Protocol | any |
| Source | VLAN10 net |
| Source Port | any |
| Destination | any |
| Destination Port | any |
| Description | Bloccare accesso a Internet |
Impedire a tutti i dispositivi su VLAN 10 ad accedere a un singolo host/server su Internet
Se desideri impedire l’accesso per tutti i dispositivi su VLAN 10 dall’accesso a un particolare indirizzo IP ad esempio “8.8.8.8” su Internet:
| Option | Value |
|---|---|
| Action | Block |
| Interface | VLAN10 |
| Protocol | any |
| Source | VLAN10 net |
| Source Port | any |
| Destination | 8.8.8.8 |
| Destination Port | any |
| Description | Bloccare accesso ad un host/server specifico |
Consenti protocollo ICMP (es. Ping) su tutte le reti interne per facilitare la risoluzione di problemi di raggiungibilità
Molti amministratori di rete disabilitano tutti i messaggi ICMP sulla rete sia interni che esterni poiché possono essere abusati.
Tuttavia, consentire il ping e messaggi di “destinazione non raggiungibile” sulla rete interna può essere utile per la risoluzione di diversi problemi di connettività.
Se si dispone di più VLAN, è consigliabile creare un gruppo di regole firewall o utilizzare regole mobili dette Floating Rules. Per il gruppo firewall o le “Floating Rules”, è necessario selezionare solo le interfacce LAN/VLAN in cui si desidera utilizzare ICMP. il seguente L’esempio utilizza il nome del gruppo “ICMPGroup” come interfaccia (il gruppo definito sa già su quali interfacce applicare le regole). Se invece si utilizzano “Floating Rules”, è possibile selezionare l’elenco appropriato di interfacce LAN/VLAN anziché utilizzare il nome del gruppo come interfaccia. Questi sono i messaggi ICMP più comuni e utili:
| Option | Value |
|---|---|
| Action | Pass |
| Interface | ICMPGroup |
| Protocol | ICMP |
| ICMP type | Echo Request |
| Source | any |
| Destination | any |
| Description | Consentire ICMP echo request |
| Option | Value |
|---|---|
| Action | Pass |
| Interface | ICMPGroup |
| Protocol | ICMP |
| ICMP type | Echo Reply |
| Source | any |
| Destination | any |
| Description | Consentire ICMP echo reply |
| Option | Value |
|---|---|
| Action | Pass |
| Interface | ICMPGroup |
| Protocol | ICMP |
| ICMP type | Destination Unreachable |
| Source | any |
| Destination | any |
| Description | Consentire ICMP destination unreachable |
| Option | Value |
|---|---|
| Action | Pass |
| Interface | ICMPGroup |
| Protocol | ICMP |
| ICMP type | Time Exceeded |
| Source | any |
| Destination | any |
| Description | Consentire ICMP time exceeded |
Se desideri utilizzare l’ICMP ma bloccare l’utilizzo per determinate reti come la VLAN di gestione o altre reti sensibili, è possibile aggiungere regole di “blocco” sopra le regole “consenti”. Dovresti semplicemente aggiungere regole come questa per ogni ICMP type che vuoi bloccare:
| Option | Value |
|---|---|
| Action | Block |
| Interface | ICMPGroup |
| Protocol | ICMP |
| ICMP type | Echo Request |
| Source | any |
| Destination | MGMT net |
| Description | Bloccare messagio ICMP echo request alla VLAN definita di managment |
Reindirizzare le richieste DNS su LAN ad DNS Unbound utilizzando il NAT port forwarding
Se desideriamo reindirizzare tutte le richieste DNS in uscita sulla porta 53 al resolver DNS Unbound locale, è possibile creare una regola di inoltro della porta NAT sulla rete LAN. Dovrai andare alla pagina “Firewall > NAT > Port Forward” per aggiungere la regola di reindirizzamento.
| Option | Value |
|---|---|
| Interface | LAN |
| Protocol | TCP/UDP |
| Source | any |
| Source Port | any |
| Destination / Invert | Spunta |
| Destination | LAN net |
| Destination Port | 53 (DNS) |
| Redirect target IP | 127.0.0.1 |
| Redirect target port | 53 (DNS) |
| Description | Reindirizzare le richieste DNS esterne ad un DNS resolver locale |
| Filter rule association | Add associated filter rule (or Pass) |
Se disponiamo di più reti locali al quale vogliamo reindirizzare le richieste DNS, è possibile creare un gruppo accedendo alla pagina “Firewall > Groups” e aggiungendo tutte le interfacce appropriate al gruppo. Creeremo una singola regola per reindirizzare le richieste DNS per l’intera rete. Puoi fare riferimento al gruppo chiamato “MyGroup” come nel seguente esempio:
| Option | Value |
|---|---|
| Interface | MyGroup |
| Protocol | TCP/UDP |
| Source | any |
| Source Port | any |
| Destination / Invert | Spunta |
| Destination | MyGroup net |
| Destination Port | 53 (DNS) |
| Redirect target IP | 127.0.0.1 |
| Redirect target port | 53 (DNS) |
| Description | Reindirizzare le richieste DNS esterne ad un DNS resolver locale |
| Filter rule association | Add associated filter rule (o Pass) |
il reindirizzamento delle richieste DNS NON crittografate sulla porta 53 non reindirizza le richieste DNS crittografate. Se non si utilizza DNS su TLS (DNS over TLS), è possibile bloccare la porta 853 in uscita nel caso in cui qualcosa stia eseguendo il tunneling del traffico su quella porta. Bloccare DNS su HTTPS è più difficoltoso perché si fonde con il traffico dei protocolli HTTPS, quindi dovrai ricorrere all’utilizzo di tecniche meno efficaci come gli elenchi di blocco (a meno che tu non utilizzi una sorta di software nel mezzo per decrittografare, ispezionare e crittografare quel traffico, ma ciò potrebbe introdurre potenziali vulnerabilità).
Reindirizzare le richieste NTP su LAN verso servizio NTP locale utilizzando il NAT port forwarding
Se necessitiamo di reindirizzare tutte le richieste NTP (Network Time Protocol) in uscita sulla porta 123 al resolver DNS Unbound locale, è possibile creare una regola di inoltro della porta NAT nella rete LAN allo stesso modo del reindirizzamento DNS. Per aggiungere la regola di reindirizzamento:
| Option | Value |
|---|---|
| Interface | LAN |
| Protocol | TCP/UDP |
| Source | any |
| Source Port | any |
| Destination / Invert | Spunta |
| Destination | LAN net |
| Destination Port | 123 (NTP) |
| Redirect target IP | 127.0.0.1 |
| Redirect target port | 123 (NTP) |
| Description | Rindirizzare richieste NTP esterne al NTP service locale |
| Filter rule association | Add associated filter rule (o Pass) |
Regole WAN
Vengono riportati di seguito alcuni scenari per la creazione di regole firewall per l’interfaccia WAN:
Consenti accesso remoto su WAN ad un server VPN su OPNsense
Il servizio OpenVPN viene esposto sul router OPNsense, è possibile definire la seguente regola per l’interfaccia WAN. Questo vale per qualsiasi servizio in esecuzione sul router, dato che non è necessario inoltrare alcuna porta a un dispositivo all’interno di una rete locale:
| Option | Value |
|---|---|
| Action | Pass |
| Interface | WAN |
| Protocol | UDP |
| Source | any |
| Source Port | any |
| Destination | WAN address |
| Destination Port | 1194 |
| Description | Consentire accesso remoto a OpenVPN |
Consentire l’accesso remoto al server Web su VLAN 10 utilizzando il NAT port forwarding
La creazione della regola segue un processo simile ad altre regole LAN/WAN poco sopra definite, ad eccezione del fatto che è necessario specificare anche l’IP o l’alias e il numero di porta del dispositivo interno sulla rete. Ciò significa che è necessario immettere i valori per i campi dati “Redirect target IP/port”.
Quando crei una regola di NAT port forward, devi andare su “Filter rule association - Associazione regole filtro” nella parte inferiore della pagina. Di Default, sarà impostato su “None”, il che significa che non sarai in grado di raggiungere il tuo server interno dall’esterno della tua rete. Selezionare “Pass” se non si utilizza una configurazione multi-WAN o ““Add associated filter rule - Aggiungi regola filtro associata” se si utilizza una configurazione multi-WAN o si preferisce avere una regola WAN corrispondente, creata automaticamente sull’interfaccia WAN. La cosa interessante dell’utilizzo dell’opzione “Pass” è che le regole WAN non vengono ingombrate dalle regole di NAT port forward. Tuttavia, se si preferisce visualizzare la regola sull’interfaccia WAN, è necessario selezionare “Add associated filter rule - Aggiungi regola filtro associato” in modo che sia visibile. Potresti essere abituato a vedere la regola se hai usato altri firewall o forse preferisci avere la regola visibile quando stai rielaborare le tue regole WAN. A colpo d’occhio si può vedere tutto ciò che è aperto sull’interfaccia WAN senza dover visitare la pagina delle regole NAT.
Ho notato che spesso ci si confonde su come configurare il port forwarding su OPNsense, la creazione delle regole NAT è simile alla creazione di altre regole firewall eseguite per le varie interfacce. La differenza maggiore sta nel popolare i valori di due ulteriori campi dati “redirect target” e selezionare l’appropriata “Associazione regole filtro”.
| Option | Value |
|---|---|
| Action | Pass |
| Interface | WAN |
| Protocol | TCP |
| Source | any |
| Source Port | any |
| Destination | WAN address |
| Destination Port | 443 (HTTPS) |
| Redirect target IP | 192.168.10.10 |
| Redirect target port | 443 (HTTPS) |
| Description | Consentire accesso remoto a un server esposto sulla 443 |
| Filter rule association | Add associated filter rule (o Pass) |
La porta che si vuole far raggiungere dall’esterno e la porta sul dispositivo interno della nostra rete lan dove ospita il servizio NON devono essere identiche. È possibile configurare esternamente qualsiasi porta alla porta del dispositivo host. Potresti effettivamente voler utilizzare una porta esterna diversa per determinati servizi come ad esempio per la accesso SSH in modo che il tuo servizio SSH esposto all’esterno non ottenga spam di scansioni automatiche o attacchi che si verificano più frequentemente sulle porte di default che sono conosciute da tutti!.
Suggerimenti e feedback
Se hai suggerimenti per altri esempi base di firewall, fammi sapere con un commento qui sotto o con un e-mail in modo di includerli nel seguente post. Tieni presente che preferirei non includere regole di esempio in cui l’unica differenza è la modifica di un numero di porta, dato che non posso includere ogni possibile servizio esistente nell’ecosistema di una rete. Gli esempi sopra elencati sono basati su scenari che sono principalmente semplici da configurare, sono pensati per essere più una rapida guida piuttosto che una procedura dettagliata di uno scenario distinto.