NethSecurity 8: regole, port forward, VPN e protezioni

Zone e politiche

Questa è la seconda parte. Do per scontato un firewall già installato, con la procedura guidata completata e le interfacce assegnate alle zone, come in NethSecurity 8: installazione e prima configurazione del firewall.

In NethSecurity il traffico si governa su due livelli:

• le zone raggruppano le interfacce e hanno politiche predefinite: cosa può andare verso il firewall, verso le altre zone e dentro la zona stessa;
• le regole fanno eccezione alle politiche, per indirizzi e servizi precisi.

Lo scenario di questa guida:

Le politiche predefinite

In Firewall › Zones & policies (Firewall › Zone e politiche) trovi le zone lan e wan, che non si possono cancellare:

Creare le zone dmz e guest

Clicca Add zone. La documentazione indica queste impostazioni:

Salva e applica le modifiche. Il nome dmz o guest fa colorare la zona in automatico. Poi assegna le interfacce alle nuove zone in Network › Interfaces and devices.

Per ogni zona puoi attivare l’opzione Logging: registra il traffico scartato, con un limite predefinito di 5 righe al secondo.

Regole firewall e oggetti

La pagina Firewall › Rules (Firewall › Regole) ha tre schede:

• Forward rules: traffico che attraversa il firewall tra due zone;
• Input rules: traffico diretto al firewall stesso;
• Output rules: traffico generato dal firewall.

Le regole si leggono dall’alto: vince la prima che corrisponde. Per questo ogni regola ha il campo Rule position, che la mette in cima o in fondo all’elenco.

I campi di una regola

Esempio 1: consentire un servizio dalla DMZ

Il server web in DMZ deve leggere un database PostgreSQL in LAN, e nient’altro. Nella scheda Forward rules:

È una porta stretta: se il server web viene compromesso, dalla DMZ si raggiunge solo quel database su quella porta. Tutto il resto dalla DMZ verso la LAN resta bloccato dalla politica della zona.

Se i server in DMZ devono usare il DNS del firewall, aggiungi nella scheda Input rules una regola con Source zone dmz, servizio DNS (53 TCP e UDP), azione Accept.

Esempio 2: bloccare un host

Un PC della LAN, 192.168.1.50, non deve uscire su Internet. Regola di forward con Source zone lan, Source address 192.168.1.50, Destination zone wan, qualsiasi servizio, Action Reject e Rule position in cima. Uso Reject e non Drop per i client interni: l’utente vede subito l’errore invece di aspettare il timeout, e il supporto capisce prima cosa succede. Su un host di cui conosci solo il MAC, dalla 8.8.1 puoi usare il MAC address come sorgente.

Oggetti: host set e domain set

Se lo stesso gruppo di indirizzi compare in più regole, crealo una volta sola in Users and objects › Objects (Utenti e oggetti › Oggetti):

• Host sets (Add host set): indirizzi, reti CIDR, intervalli, prenotazioni DHCP, record DNS e utenti VPN con IP riservato. Ogni set è solo IPv4 o solo IPv6, e il nome ammette solo lettere e numeri;
• Domain sets: nomi di dominio che il firewall risolve e mantiene aggiornati, utili per regole verso servizi cloud con IP variabili.

Esempio: un host set AmministratoriIT con i PC dei tecnici, usato come sorgente di una regola che consente SSH e RDP dalla LAN verso la DMZ. Quando cambia un PC, modifichi il set e tutte le regole si aggiornano. Con Show usages vedi dove è usato un oggetto; un oggetto in uso non si può cancellare.

Port forward verso la DMZ

Il port forward (DNAT) pubblica un servizio interno sull’indirizzo pubblico del firewall. Vai in Firewall › Port forward e crea due regole per il server web 192.168.20.10.

HTTPS aperto a tutti

SSH solo dall’ufficio

Per amministrare il server da remoto pubblico SSH su una porta diversa e solo per l’IP fisso dell’ufficio, 198.51.100.7:

Altre opzioni utili:

• WAN IP: lega la regola a uno specifico indirizzo pubblico, se ne hai più d’uno come alias sulla WAN;
• Traffic type All traffic: inoltra all’host interno tutto il traffico, senza filtro. Di fatto lo esponi per intero: evitalo;
• Hairpin NAT: per default il port forward vale solo per chi arriva dalla WAN. Se gli utenti della LAN devono raggiungere il server con l’indirizzo pubblico, attiva l’opzione e scegli le zone. In alternativa crea un record DNS interno che risolva il nome del sito in 192.168.20.10.

Per un server FTP in modalità passiva servono gli helper nf_conntrack_ftp e nf_nat_ftp, da attivare in Firewall › NAT, scheda NAT helpers, più due comandi sulla zona WAN:

uci set firewall.ns_wan.auto_helper='0'
uci set firewall.ns_wan.helper='ftp'
uci commit firewall
reload_config

NAT: SNAT, masquerade ed eccezioni

Per default tutto il traffico dalle zone interne verso la WAN esce in masquerade, con l’indirizzo della WAN. Le eccezioni si gestiscono in Firewall › NAT, scheda Rules and NETMAP, con quattro tipi di regola:

Le regole NAT valgono per tutti i protocolli. Il DNAT invece non si configura qui ma nella pagina del port forward.

Per il netmap usa Add source NETMAP e Add destination NETMAP: servono due regole per lato. La documentazione mette a disposizione un Netmap planner che calcola le regole per entrambi i firewall.

Multi-WAN: failover e bilanciamento

Il multi-WAN richiede almeno due interfacce nella zona wan. Al primo accesso alla pagina MultiWAN devi creare la politica predefinita, che non si può cancellare:

• Balanced: le WAN lavorano insieme e il traffico si divide secondo il peso di ciascuna (da 1 a 1000). Con una fibra da 1 Gbit/s e una FWA da 100 Mbit/s, pesi 10 e 1 sono un buon inizio;
• Backup: la seconda WAN entra in gioco solo se cade la prima;
• Custom: livelli di priorità, ciascuno con più WAN bilanciate. Esempio: due WAN bilanciate al primo livello e una terza al secondo livello (Add priority level), usata solo se cadono entrambe.

Regole di instradamento

Con Create policy e Create rule mandi traffico specifico su una WAN precisa, in base a sorgente, destinazione, protocollo e porte. Esempio tipico: il centralino VoIP esce sempre dalla fibra, con la FWA come riserva. L’opzione Sticky tiene sulla stessa WAN, per 10 minuti, il traffico di una sorgente: serve per i siti di banche e assicurazioni che non sopportano il cambio di IP durante la sessione. L’instradamento per dominio di destinazione non è supportato.

Controllo dei collegamenti

In General settings indichi gli host da interrogare con il ping, quanti pacchetti inviare e dopo quanti test falliti una WAN è considerata giù. Scegli host affidabili e diversi tra loro, non il gateway del provider: il modem risponde anche quando la linea è giù.

VPN road warrior con OpenVPN

Il road warrior collega i portatili dei colleghi alla sede. Prima crea gli utenti in Users and objects › Users databases, nel database locale oppure collegando un LDAP/Active Directory: il database si sceglie alla creazione del server e non si cambia più.

Il server

In VPN › OpenVPN Road Warrior clicca Create Server:

Nelle impostazioni avanzate trovi protocollo e porta (predefiniti UDP 1194), Route all client traffic through VPN (di solito spento), Push network routes (le LAN sono già incluse), cifratura (predefinita AES-256-GCM), versione TLS minima e opzioni DHCP come il DNS da passare ai client. Lascia spenti Allow client-to-client network traffic e Compression.

Gli account

Per ogni utente clicca Add VPN Account. Se gli assegni un Reserved IP fuori dall’intervallo dinamico, l’utente diventa un oggetto da usare nelle regole. Poi, dal menu dell’account, Download configuration scarica il file pronto per il client OpenVPN (OpenVPN Connect, Tunnelblick, il client della community). Un account si usa da un solo dispositivo alla volta.

Il server deve essere raggiungibile da Internet sulla sua porta. Dopo la creazione controlla in Firewall › Rules › Input rules che esista una regola per la porta 1194/UDP dalla WAN; la documentazione non dice se viene creata in automatico, quindi verificalo sulla tua versione.

Se gli utenti si collegano ma alcune applicazioni si bloccano, il problema è quasi sempre l’MTU. Riduci MTU e MSS nelle opzioni avanzate del server, senza toccare i client:

uci set openvpn.ns_<nome>.tun_mtu='1300'
uci set openvpn.ns_<nome>.mssfix='1250'
uci commit openvpn.ns_<nome>
/etc/init.d/openvpn restart ns_<nome>

Controlla anche le scadenze: CA, certificato del server e certificati dei client hanno ognuno la propria data, visibile nell’interfaccia, e tutti devono essere validi. La scheda Connection History conserva accessi e disconnessioni, esportabili in CSV.

VPN IPsec tra sedi

Per collegare NethSecurity a un firewall o router di un altro produttore usa IPsec: è lo standard supportato da tutti. NethSecurity usa VPN route-based (ogni tunnel ha la sua interfaccia) e come autenticazione solo la chiave condivisa.

Parametri speculari e parametri identici

Esempio: sede A (NethSecurity, WAN 203.0.113.10, LAN 192.168.1.0/24) e sede B (WAN 198.51.100.1, LAN 192.168.50.0/24).

Creare il tunnel

In VPN › IPsec tunnels clicca Add IPsec tunnel, dai un nome e compila i tre passi: il primo contiene solo i parametri di rete (WAN, reti, identificatori), gli altri due i parametri di cifratura che devono coincidere con l’altro capo. Dalle note di rilascio risultano disponibili IKEv1 e IKEv2, i gruppi Diffie-Hellman 19, 20 e 21 e l’opzione PFS: scegli IKEv2, AES-GCM o AES-256 con SHA-256 e un gruppo DH moderno, gli stessi dall’altra parte.

• Se uno dei due capi è dietro NAT, usa come identificatori nomi unici in stile e-mail, per esempio nsec@sede-a e router@sede-b.
• Un tunnel può portare più reti locali e remote: NethSecurity crea una child SA per ogni coppia. Se dopo una modifica le child SA non si aggiornano, usa Restart in alto a destra nella pagina.
• Con il multi-WAN crea una rotta statica verso l’IP remoto attraverso il gateway della WAN usata dal tunnel.
• Il traffico dei tunnel appartiene alla zona ipsec: le regole tra le sedi si scrivono su quella zona.

Il lato remoto lo configuri come descritto nelle mie guide: VPN IPsec tra Cisco e Ubuntu con strongSwan spiega algoritmi, chiave condivisa e verifiche su un router Cisco e su strongSwan, che puoi usare come controparte di NethSecurity. Per i client Windows senza software aggiuntivo vedi Accesso remoto IKEv2: client Windows verso Ubuntu con strongSwan.

Protezioni: Threat Shield, DPI e IPS

Le protezioni stanno nella sezione Security (Sicurezza). Sono tutte disattivate per default.

Threat shield IP

Blocca il traffico da e verso indirizzi malevoli. In Security › Threat shield IP, scheda Settings, attiva Status; nella scheda Blocklist feeds scegli le liste:

• Community: gratuite, “così come sono”, senza punteggio di affidabilità; controlla contenuto e licenza prima di usarle in produzione. Le liste “level 1” sono in genere le più prudenti;
• Enterprise (Nethesis e Yoroi): richiedono sottoscrizione e il servizio aggiuntivo, hanno un punteggio Confidence da 1 a 10.

Ogni lista agisce in una direzione (Inbound, Outbound o entrambe) e a volte solo su certe porte. Il traffico tra reti locali non viene mai controllato. Nella stessa pagina trovi:

• Local allowlist e Local blocklist: indirizzi, reti, MAC o nomi da consentire o bloccare sempre. Metti in allowlist gli IP dei tuoi uffici e dei fornitori;
• Geoblocking: blocca per paese il traffico in ingresso; non bloccare le regioni da cui lavorano i tuoi utenti;
• Block brute force attacks: banna gli IP che sbagliano la password su SSH, interfaccia web e OpenVPN (3 tentativi è il valore tipico). Funziona sul traffico da Internet: un tentativo dalla LAN viene rilevato ma non bloccato.

Threat shield DNS

Blocca la risoluzione dei domini malevoli (si basa su Adblock). In Security › Threat shield DNS attivi il servizio, scegli le liste in Blocklist sources e, in Force DNS redirection on these zones, le zone i cui client sono obbligati a usare il DNS del firewall: senza questa opzione un client con il DNS impostato a mano scavalca il filtro. Non si usa insieme a FlashStart, il filtro DNS commerciale integrato: l’interfaccia impedisce di attivarli entrambi.

DPI filter

Il DPI filter usa Netify per riconoscere applicazioni e protocolli. Prima crei i gruppi in Application groups (Create application group), poi le regole in Rules (Add rule). Anche qui vince la prima regola che corrisponde, e il traffico che non corrisponde a nessuna regola passa. Esempio dalla documentazione: per bloccare lo streaming a tutta la LAN tranne un host, metti prima una regola Allow per 192.168.1.10, poi una regola Block con il gruppo “streaming” per 192.168.1.0/24. Con una sottoscrizione le firme salgono da circa 500 a circa 2800 applicazioni.

IPS

L’IPS è Snort 3. In Security › IPS attiva Status e scegli la politica:

• connectivity: privilegia le prestazioni e riduce i falsi positivi;
• balanced: consigliata per iniziare;
• security: massima protezione, più falsi positivi.

Indica in Home Networks le reti interne; non si aggiornano da sole se cambi l’indirizzo di un’interfaccia. Le regole community sono libere; con un Oinkcode di snort.org scarichi le regole Registered (con 30 giorni di ritardo) o Subscriber. Nella scheda Today event list vedi gli allarmi del giorno; da lì puoi aprire un modulo per sopprimere o disattivare la regola che dà falsi positivi. Le eccezioni stanno in Filter bypass, Disabled Rules e Suppressed alerts.

Log, monitoraggio e controller

Monitoraggio dall’interfaccia

• Real-time monitor: traffico del giorno, Live Flows (connessioni attive con l’applicazione riconosciuta), Top Talkers, stato e latenza delle WAN, VPN collegate e minacce bloccate (la sezione Security richiede Threat shield IP attivo). Sono dati in RAM, azzerati a ogni riavvio;
• Metrics (dalla 8.8): grafici storici e allarmi, conservati 7 giorni in RAM o un anno su storage persistente, senza bisogno di sottoscrizione;
• Firewall › Connections: la tabella delle connessioni tracciate, filtrabile per protocollo, stato, IP e porta, con la possibilità di chiuderne una o tutte.

I log

Le regole, le zone e i port forward con il log attivo scrivono nel log di sistema, con il nome della regola come prefisso (limite predefinito: 1 riga al secondo per regole e port forward, 5 per le zone). In SSH:

tail -f /var/log/messages | grep Web-DMZ-SSH-ufficio

Per conservarli altrove, inoltrali a un server syslog:

uci set rsyslog.clm=forwarder
uci set rsyslog.clm.source=*.*
uci set rsyslog.clm.protocol=udp
uci set rsyslog.clm.port=514
uci set rsyslog.clm.target=192.168.1.88
uci commit rsyslog
/etc/init.d/rsyslog restart

Il controller

Quando i firewall sono più di due o tre, il controller fa la differenza. È un’applicazione di NethServer 8 (NethSecurity Controller, dal Software Center) che gestisce più firewall, chiamati unità, da un’unica interfaccia: accesso diretto all’interfaccia di ogni unità, log centralizzati in Loki, metriche in Grafana, SSH dal browser, aggiornamenti.

1. Nel controller clicca Add unit: viene generato un join code.
2. Sul firewall apri la pagina Controller e incolla il codice nel campo Join code. Se il controller non ha un certificato Let’s Encrypt valido, disattiva Verify TLS certificate.
3. L’unità apre una VPN OpenVPN verso il controller e compare come Connected.

Il controller raggiunge l’interfaccia dell’unità sulla porta 9090 attraverso la VPN: non serve aprirla dalla WAN, ma non va spostata su un’altra porta. Firewall e server del controller devono avere lo stesso stato di sottoscrizione (entrambi con o entrambi senza), altrimenti l’unità non si collega.

Il passo successivo

Ricapitolando, per ogni nuovo firewall:

• disegna la matrice dei flussi tra le zone e traducila in politiche e poche regole precise, con nomi parlanti e oggetti riutilizzabili;
• pubblica i servizi con il port forward e, dove puoi, limita l’origine con Restrict access to;
• dai ai road warrior solo l’accesso che serve e usa IPsec verso gli apparati di altri produttori;
• attiva le protezioni una alla volta e guarda i log.

Se vuoi capire cosa succede sotto il cofano, NethSecurity si basa su OpenWrt e sul suo firewall nftables: in Firewall completo su Linux con nftables trovi gli stessi concetti (zone, masquerade, DNAT, MSS clamping) scritti a mano. Per la base dell’installazione torna a NethSecurity 8: installazione e prima configurazione del firewall.