pfSenseItaly

pfSense, NIS2 e usura degli SSD: perché il RAM Disk può fare la differenza

2026-11-01T21:32:00.000+01:00

La crescente necessità di monitorare il traffico di rete e registrare gli eventi di sicurezza sta cambiando il lavoro dei nostri firewall. Ma cosa succede quando un'appliance economica, progettata per gestire poche scritture su disco, si ritrova a registrare migliaia di eventi ogni giorno?

Negli ultimi anni pfSense si è trasformato da semplice firewall/router open source in una piattaforma di sicurezza perimetrale sempre più completa.

Oltre alle tradizionali funzionalità di routing, NAT e VPN, oggi molte installazioni utilizzano sistemi di rilevamento delle intrusioni, filtri DNS avanzati, strumenti di analisi del traffico e meccanismi di raccolta degli eventi di sicurezza.

L'entrata in vigore della direttiva europea NIS2 sta contribuendo ad accelerare questa evoluzione, spingendo molte aziende a prestare maggiore attenzione al monitoraggio delle proprie infrastrutture e alla capacità di individuare tempestivamente eventuali incidenti informatici.

Tutto questo, però, comporta un effetto collaterale spesso sottovalutato: l'aumento delle operazioni di lettura e, soprattutto, di scrittura sui dischi delle appliance firewall.

Un problema particolarmente significativo per chi utilizza dispositivi di fascia medio-bassa, frequentemente equipaggiati con SSD consumer o memorie flash economiche.

Fortunatamente pfSense integra una funzionalità che può contribuire a ridurre sensibilmente questo fenomeno: il RAM Disk.

Vediamo perché può essere utile, come funziona e soprattutto come configurarlo correttamente.

NIS2: quando il firewall deve fare molto più che filtrare il traffico

La direttiva NIS2 introduce un approccio alla sicurezza informatica basato sulla gestione del rischio, sulla prevenzione degli incidenti e sulla capacità di rilevare e affrontare tempestivamente eventuali compromissioni.

Tra gli aspetti più importanti troviamo il monitoraggio dei sistemi, la gestione degli incidenti, la continuità operativa e la verifica dell'efficacia delle misure di sicurezza adottate.

Questo non significa che NIS2 obblighi le aziende a installare specifici software o pacchetti aggiuntivi sui propri firewall.

Significa però che, per soddisfare questi obiettivi, molte organizzazioni stanno introducendo strumenti di sicurezza e monitoraggio che in passato non utilizzavano.

Nel caso di pfSense, alcuni degli strumenti più comuni sono:

Suricata e Snort, per il rilevamento e la prevenzione delle intrusioni.
pfBlockerNG, per il filtraggio di indirizzi IP, domini e contenuti DNS.
ntopng, per l'analisi approfondita del traffico di rete.
Syslog, per la registrazione e la centralizzazione degli eventi.
Strumenti di monitoraggio, per raccogliere metriche sulle prestazioni e sul funzionamento del firewall.

Questi componenti, soprattutto quando vengono utilizzati contemporaneamente, possono aumentare considerevolmente l'attività di I/O del sistema.

Un firewall che prima si limitava a gestire le connessioni potrebbe oggi dover registrare migliaia di eventi, aggiornare periodicamente database di sicurezza e mantenere statistiche dettagliate sul traffico.

E ogni operazione di scrittura, per quanto piccola, contribuisce al lavoro richiesto al dispositivo di memorizzazione.

Il problema degli SSD consumer nelle appliance economiche

Chi utilizza pfSense conosce bene la diffusione delle piccole appliance fanless basate su processori Intel Celeron, Atom o sulle più recenti piattaforme Intel N100 e N305.

Sono dispositivi interessanti: consumano poco, sono silenziosi e offrono prestazioni spesso più che sufficienti per gestire le reti di piccole e medie aziende.

Per mantenere contenuti i costi, però, molti produttori utilizzano componenti di memorizzazione economici.

Non è raro trovare SSD SATA privi di memoria DRAM dedicata, unità NVMe entry-level, memorie eMMC o dispositivi flash di qualità non sempre documentata.

Questi supporti possono funzionare perfettamente per anni, ma non tutti sono progettati per sostenere carichi caratterizzati da scritture continue, ventiquattro ore al giorno.

Che cosa sono i TBW?

Tra le caratteristiche più importanti di un SSD troviamo il valore TBW (Terabytes Written).

Questo parametro indica la quantità complessiva di dati scrivibili sull'unità prevista dalle specifiche di resistenza dichiarate dal produttore.

Non rappresenta una scadenza oltre la quale il disco smette necessariamente di funzionare, ma costituisce un riferimento utile per valutarne la durata in funzione del carico di lavoro.

Facciamo un esempio.

Immaginiamo un SSD con una resistenza dichiarata di 100 TBW.

Se il sistema genera mediamente 20 GB di scritture al giorno, nell'arco di un anno verranno scritti circa 7,3 TB.

Con 100 GB giornalieri si arriva invece a circa 36,5 TB all'anno.

In quest'ultimo scenario, il valore di 100 TBW verrebbe raggiunto in meno di tre anni.

Naturalmente si tratta di un esempio teorico: la durata effettiva dipende da numerosi fattori, tra cui la qualità delle celle NAND, il controller, il firmware, la temperatura e il comportamento del sistema.

Il punto è che un carico di scrittura apparentemente modesto, quando viene ripetuto senza interruzioni per mesi o anni, può diventare significativo.

E non bisogna dimenticare che il guasto di un SSD installato su un firewall può comportare l'interruzione della connettività di un'intera azienda.

Quali pacchetti pfSense generano più scritture?

Non tutti i componenti contribuiscono allo stesso modo all'attività del disco.

Alcuni generano prevalentemente operazioni di lettura o utilizzano la memoria RAM, mentre altri possono produrre una quantità significativa di file temporanei, statistiche e log.

Suricata e Snort

Suricata e Snort sono probabilmente tra i primi componenti da esaminare quando si vuole ridurre l'attività di scrittura.

Questi sistemi analizzano il traffico di rete alla ricerca di comportamenti sospetti e possono generare numerosi eventi.

La quantità di dati registrati dipende dalla configurazione.

Un sistema che memorizza soltanto gli alert più significativi avrà un impatto decisamente inferiore rispetto a uno che registra informazioni dettagliate sui flussi, sulle connessioni e sulle attività di rete.

Anche la frequenza di aggiornamento delle regole e la gestione dei file di log contribuiscono all'attività del disco.

In reti particolarmente trafficate, oppure in presenza di configurazioni molto verbose, il volume delle scritture può diventare importante.

pfBlockerNG

Anche pfBlockerNG può contribuire al fenomeno.

Il pacchetto gestisce liste di indirizzi IP e domini da bloccare, aggiornandole periodicamente e mantenendo informazioni sulle attività di filtraggio.

Le operazioni di aggiornamento delle liste, la gestione di DNSBL e la registrazione degli eventi possono generare scritture frequenti.

L'impatto dipende soprattutto dalle dimensioni delle liste utilizzate e dal livello di logging configurato.

ntopng

Un discorso particolare merita ntopng.

Questo strumento permette di analizzare il traffico di rete, identificare applicazioni e protocolli, monitorare gli host e conservare informazioni storiche sulle comunicazioni.

Per offrire queste funzionalità può utilizzare database, serie temporali e archivi di statistiche.

Su un'appliance con risorse limitate, soprattutto se configurato per conservare molti dati, ntopng può diventare uno dei componenti più impegnativi sia in termini di memoria sia di operazioni su disco.

È importante ricordare che parte dei dati può essere archiviata in posizioni che non beneficiano automaticamente del RAM Disk di pfSense.

Logging di sistema

Anche senza pacchetti aggiuntivi, pfSense genera continuamente eventi relativi al funzionamento del sistema.

Tra questi troviamo:

Connessioni bloccate o consentite dal firewall.
Eventi di autenticazione.
Connessioni e disconnessioni VPN.
Eventi DHCP e DNS.
Modifiche alla configurazione.
Errori e anomalie dei servizi.

In alcune installazioni, soprattutto quando vengono registrate numerose connessioni, il volume dei log può crescere rapidamente.

Il RAM Disk: spostare le scritture dalla memoria di massa alla RAM

Per limitare questo problema, pfSense dispone di una funzionalità integrata che permette di utilizzare una parte della memoria RAM come spazio di archiviazione temporaneo.

Si tratta del RAM Disk.

Il principio è semplice.

Normalmente, quando un servizio deve scrivere un file temporaneo o registrare un evento, utilizza una directory presente sul dispositivo di memorizzazione.

Con il RAM Disk, alcune directory vengono invece mantenute nella memoria RAM.

In particolare, pfSense permette di utilizzare questa modalità per:

/tmp

/var

La prima viene utilizzata prevalentemente per i file temporanei, mentre la seconda contiene numerosi dati variabili del sistema, inclusi log e informazioni utilizzate da diversi servizi.

Spostando queste directory in RAM è possibile ridurre significativamente il numero delle scritture effettuate sul dispositivo di memorizzazione.

Non si tratta di una soluzione nuova: è una funzionalità presente da tempo in pfSense, ma che merita maggiore attenzione proprio alla luce della crescente quantità di dati generata dai sistemi di sicurezza.

Quali sono i vantaggi?

Il primo è naturalmente la riduzione dell'usura del dispositivo di memorizzazione.

I file temporanei e molte informazioni soggette a frequenti modifiche non devono più essere continuamente scritti sull'SSD.

Il secondo vantaggio riguarda le prestazioni.

La memoria RAM offre tempi di accesso notevolmente inferiori rispetto a qualsiasi SSD.

Questo può rendere più rapide alcune operazioni sui file temporanei, anche se il beneficio reale dipende dal tipo di carico e non comporta necessariamente un aumento delle prestazioni del firewall nel suo complesso.

Infine, il RAM Disk può contribuire a migliorare l'affidabilità complessiva delle appliance che utilizzano dispositivi flash economici o particolarmente sensibili alle scritture.

Attenzione, però: non tutte le scritture vengono eliminate.

Alcuni pacchetti possono utilizzare percorsi differenti da /var e /tmp, mentre altre operazioni di sistema continuano necessariamente a interessare il dispositivo di memorizzazione.

Il RAM Disk è quindi uno strumento di ottimizzazione, non una soluzione universale.

Come abilitare il RAM Disk su pfSense

L'attivazione è piuttosto semplice e non richiede l'installazione di pacchetti aggiuntivi.

Dall'interfaccia di amministrazione accedere a:

System → Advanced → Miscellaneous

Scorrere fino alla sezione:

RAM Disk Settings

Qui troviamo l'opzione:

Use RAM Disks

Attivandola, pfSense utilizzerà un filesystem in memoria per le directory /tmp e /var.

Subito sotto sono presenti i campi che permettono di definire la dimensione dei due RAM Disk, espressa in MiB.

Prima di salvare la configurazione, però, è fondamentale scegliere valori adeguati.

L'attivazione o la disattivazione del RAM Disk richiede il riavvio del firewall, che viene avviato durante il salvataggio della modifica.

È quindi opportuno pianificare l'intervento in una finestra di manutenzione.

Come dimensionare correttamente il RAM Disk

Questa è probabilmente la parte più importante della configurazione.

Assegnare troppo poca memoria può provocare la saturazione delle directory temporanee, con conseguenti problemi di funzionamento dei servizi.

Assegnarne troppa può invece sottrarre risorse preziose al sistema operativo e ai pacchetti di sicurezza.

Non esiste quindi una configurazione universalmente corretta.

La quantità di RAM necessaria dipende dal numero di servizi attivi, dal traffico gestito, dai pacchetti installati e dalla frequenza con cui vengono generati e conservati i dati.

Netgate suggerisce di considerare 512–1024 MiB come punto di partenza per /var, quando il sistema dispone di memoria sufficiente, soprattutto in presenza di pacchetti aggiuntivi.

Possiamo comunque individuare alcune configurazioni indicative.

Appliance con 4 GB di RAM

Su dispositivi con 4 GB di memoria è necessario prestare particolare attenzione al consumo complessivo.

Una possibile configurazione iniziale, per installazioni leggere, potrebbe essere:

Directory	Dimensione
`/tmp`	64–128 MiB
`/var`	256–512 MiB

Questi valori possono essere sufficienti per firewall che svolgono prevalentemente funzioni di routing, NAT e VPN, con un numero limitato di servizi aggiuntivi.

Tuttavia, 256 MiB per /var potrebbero risultare insufficienti anche in configurazioni relativamente semplici.

Se il consumo misurato non consente di mantenere un adeguato margine di sicurezza, è preferibile non attivare il RAM Disk piuttosto che utilizzare dimensioni troppo ridotte.

Appliance con 8 GB di RAM

Con 8 GB di memoria aumentano le possibilità di utilizzare il RAM Disk anche in presenza di alcuni pacchetti di sicurezza.

Una configurazione iniziale potrebbe essere:

Directory	Dimensione
`/tmp`	128–256 MiB
`/var`	512–1024 MiB

Si tratta di valori che possono rappresentare un buon compromesso per molte installazioni, ma che devono comunque essere verificati in funzione del carico effettivo.

Appliance con 16 GB di RAM o superiori

Sui dispositivi con almeno 16 GB è possibile destinare una quantità maggiore di memoria ai filesystem temporanei.

Ad esempio:

Directory	Dimensione
`/tmp`	256–512 MiB
`/var`	1024–2048 MiB

In presenza di pacchetti particolarmente impegnativi potrebbe essere necessario aumentare ulteriormente questi valori.

Bisogna però ricordare che Suricata, Snort e altri componenti possono richiedere quantità significative di RAM per il proprio funzionamento.

Non è quindi opportuno destinare automaticamente tutta la memoria disponibile al RAM Disk.

I valori riportati sono esempi di configurazione iniziale e non rappresentano requisiti minimi, massimi o dimensionamenti ufficiali.

Come verificare lo spazio realmente necessario

Prima di abilitare il RAM Disk, il metodo migliore consiste nel misurare quanto spazio viene effettivamente utilizzato dalle directory interessate.

È possibile farlo direttamente dalla shell di pfSense.

Per verificare le dimensioni correnti di /var e /tmp possiamo utilizzare:

du -sh /var /tmp

Il comando restituisce lo spazio occupato dalle due directory.

È utile ripetere questa verifica in momenti diversi della giornata e, soprattutto, durante le attività che potrebbero generare un maggiore volume di dati.

Ad esempio, durante l'aggiornamento delle regole di Suricata o pfBlockerNG.

Per individuare le directory che occupano più spazio all'interno di /var, possiamo utilizzare:

du -h -d 1 /var | sort -h

Queste informazioni permettono di comprendere quali componenti stanno consumando più spazio.

È importante effettuare le misurazioni per alcuni giorni, in modo da non dimensionare il RAM Disk sulla base di un momento in cui l'utilizzo è particolarmente basso.

Monitorare il RAM Disk dopo l'attivazione

Una volta abilitato, possiamo verificare lo spazio disponibile con:

df -h /var /tmp

Il comando permette di controllare la capacità, lo spazio utilizzato e quello ancora disponibile.

È consigliabile monitorare questi valori anche dopo gli aggiornamenti dei pacchetti o l'attivazione di nuove funzionalità.

Per verificare anche l'utilizzo degli inode possiamo utilizzare:

df -hi

La saturazione del filesystem può infatti dipendere non soltanto dallo spazio occupato, ma anche dal numero di file creati.

Un RAM Disk completamente pieno può impedire il corretto funzionamento di servizi fondamentali del firewall.

Il problema della persistenza dei dati

Il RAM Disk presenta un limite importante: la memoria RAM è volatile.

Questo significa che, in caso di spegnimento improvviso o perdita di alimentazione, i dati presenti in memoria possono andare persi.

Per un firewall che registra eventi di sicurezza, questo aspetto merita particolare attenzione.

Pensiamo, ad esempio, a un incidente informatico che provoca l'interruzione del funzionamento di un dispositivo.

Se gli eventi sono stati registrati esclusivamente nel RAM Disk, una parte delle informazioni utili a ricostruire l'accaduto potrebbe non essere più disponibile al riavvio.

I backup periodici di pfSense

Per limitare questo problema, pfSense permette di effettuare salvataggi periodici di alcuni dati mantenuti nel RAM Disk.

Nella stessa sezione di configurazione troviamo le opzioni Periodic RAM Disk Data Backups.

Queste consentono di definire la frequenza di salvataggio di alcune categorie di dati, tra cui:

Dati RRD utilizzati dai grafici di monitoraggio.
Database dei lease DHCP.
Directory dei log di sistema.
Dati del Captive Portal.

Durante uno spegnimento regolare, pfSense provvede inoltre al salvataggio dei dati previsti da questo meccanismo.

In caso di riavvio imprevisto, può recuperare l'ultima copia disponibile.

Naturalmente esiste un compromesso.

Salvataggi più frequenti riducono la quantità di informazioni potenzialmente perse, ma aumentano nuovamente le scritture sul dispositivo di memorizzazione.

Per questo motivo è importante trovare un equilibrio tra conservazione dei dati e riduzione dell'attività del disco.

Va inoltre verificato separatamente il comportamento dei pacchetti aggiuntivi: non tutti i dati gestiti da questi componenti vengono necessariamente conservati dal meccanismo di backup del RAM Disk.

NIS2 e conservazione dei log: perché è preferibile utilizzare un server remoto

Se utilizziamo pfSense per contribuire alle attività di monitoraggio e sicurezza previste dalla NIS2, il tema della conservazione dei log diventa particolarmente importante.

La normativa richiede l'adozione di misure adeguate alla gestione dei rischi e degli incidenti, ma non stabilisce indistintamente che ogni firewall debba conservare localmente tutti i propri log per un periodo prefissato.

Le esigenze di registrazione, conservazione e protezione delle informazioni devono essere definite in funzione del rischio, della tipologia di organizzazione e delle disposizioni applicabili.

In questo contesto, affidarsi esclusivamente ai log locali del firewall presenta alcuni limiti.

Oltre al rischio di perdita dei dati, un eventuale attaccante che riuscisse a compromettere il dispositivo potrebbe tentare di cancellare o alterare le informazioni registrate.

Per questo motivo, la centralizzazione dei log rappresenta una soluzione decisamente preferibile alla conservazione esclusivamente locale.

Configurare il Remote Syslog di pfSense

pfSense integra nativamente la possibilità di inoltrare i log verso un server remoto.

Per configurarlo è sufficiente accedere a:

Status → System Logs → Settings

Nella sezione Remote Logging Options possiamo abilitare l'invio degli eventi verso un server Syslog esterno.

È possibile selezionare le categorie di log da inoltrare e indicare l'indirizzo del sistema che dovrà riceverli.

La destinazione potrebbe essere un semplice server Syslog oppure una piattaforma più strutturata, come Graylog, Wazuh o un sistema SIEM.

In questo modo otteniamo diversi vantaggi.

Innanzitutto, gli eventi vengono trasferiti fuori dal firewall, riducendo la dipendenza dalla memoria locale.

Possiamo inoltre definire politiche di conservazione più lunghe, proteggere gli archivi e correlare gli eventi provenienti da dispositivi differenti.

È importante ricordare che il semplice inoltro dei log non garantisce automaticamente la loro conservazione.

Il sistema remoto dovrà essere configurato per archiviare correttamente gli eventi, proteggerli da modifiche non autorizzate e mantenerli per il periodo previsto dalle politiche aziendali.

Anche la sicurezza del trasporto dei log deve essere valutata: quando necessario, è opportuno utilizzare una rete di management protetta oppure un tunnel VPN.

RAM Disk e Syslog remoto: una combinazione efficace

L'utilizzo congiunto delle due funzionalità permette di separare due esigenze che spesso vengono erroneamente considerate incompatibili.

Da una parte possiamo ridurre le scritture sul disco locale utilizzando il RAM Disk.

Dall'altra possiamo garantire una conservazione più affidabile degli eventi attraverso un sistema di raccolta centralizzato.

Il risultato è un'architettura nella quale il firewall mantiene soltanto i dati necessari al proprio funzionamento, mentre la gestione storica delle informazioni viene affidata a un'infrastruttura progettata per questo scopo.

Come controllare lo stato di salute dell'SSD

Anche dopo aver abilitato il RAM Disk è consigliabile verificare periodicamente lo stato del dispositivo di memorizzazione.

Molti SSD mettono a disposizione informazioni diagnostiche attraverso la tecnologia SMART.

Queste informazioni permettono di controllare parametri come la quantità complessiva di dati scritti, gli errori registrati e l'usura stimata della memoria.

Sui dispositivi compatibili, utilizzando gli strumenti SMART disponibili nel sistema, è possibile interrogare l'unità.

Ad esempio, per un SSD SATA identificato come ada0:

smartctl -a /dev/ada0

Per un'unità NVMe, il nome del dispositivo sarà differente, ad esempio:

smartctl -a /dev/nvme0

I nomi dei dispositivi sono indicativi e devono essere verificati sulla propria installazione.

Anche i parametri restituiti variano in funzione del produttore e della tecnologia utilizzata.

Tra le informazioni più interessanti troviamo:

Quantità complessiva di dati scritti.
Percentuale di vita utile consumata.
Eventuali errori del supporto.
Temperatura operativa.
Stato generale dell'unità.

È particolarmente utile osservare l'evoluzione di questi valori nel tempo.

Un SSD che presenta ancora uno stato di salute apparentemente buono potrebbe comunque essere sottoposto a un volume di scritture incompatibile con la durata operativa desiderata.

Confrontare i dati SMART prima e dopo l'attivazione del RAM Disk può inoltre aiutare a comprendere quanto l'intervento abbia effettivamente ridotto il carico sul dispositivo.

Alcune raccomandazioni pratiche

Prima di concludere, vale la pena riassumere alcune buone pratiche per chi utilizza pfSense su appliance con SSD consumer.

1. Valutare l'utilizzo del RAM Disk

Soprattutto sulle appliance dotate di memorie flash economiche o con capacità di scrittura limitata.

L'attivazione deve comunque essere preceduta da una verifica dello spazio utilizzato e della RAM disponibile.

2. Centralizzare i log di sicurezza

Il firewall non dovrebbe essere considerato l'archivio principale degli eventi.

Un server Syslog o una piattaforma SIEM permette di conservare le informazioni con maggiore affidabilità e di effettuare analisi più approfondite.

3. Evitare il logging eccessivo

Registrare ogni evento non significa necessariamente migliorare la sicurezza.

È preferibile individuare le informazioni realmente utili al monitoraggio, alla gestione degli incidenti e alle attività di audit.

4. Verificare i consumi dei pacchetti aggiuntivi

Suricata, Snort, pfBlockerNG e ntopng possono avere esigenze molto differenti.

È importante verificare quali directory utilizzano e quali informazioni memorizzano sul disco.

5. Monitorare lo stato dello storage

I parametri SMART possono fornire indicazioni utili sull'usura del dispositivo.

Quando possibile, è consigliabile monitorare anche la quantità di dati scritti nel tempo.

6. Non sottovalutare la qualità dell'hardware

Il RAM Disk non può compensare completamente l'utilizzo di un supporto di memorizzazione inadeguato.

Per le installazioni più critiche è preferibile scegliere SSD con caratteristiche di affidabilità e resistenza alle scritture coerenti con il carico previsto.

Conclusioni

L'evoluzione delle esigenze di sicurezza sta cambiando profondamente il ruolo dei firewall.

Dispositivi che fino a pochi anni fa si occupavano prevalentemente di filtrare il traffico e gestire le VPN oggi vengono sempre più spesso utilizzati anche per rilevare intrusioni, registrare eventi e fornire informazioni utili al monitoraggio delle infrastrutture.

La direttiva NIS2 contribuisce ad accelerare questo processo, rendendo ancora più importante la capacità di individuare tempestivamente anomalie e incidenti di sicurezza.

Ma l'introduzione di nuove funzionalità deve essere accompagnata da un'attenta valutazione delle risorse hardware necessarie.

Un'appliance economica può offrire prestazioni eccellenti come firewall, ma non è detto che il suo SSD sia adatto a sostenere per anni un carico elevato di scritture continue.

Il RAM Disk rappresenta una soluzione semplice ed efficace per ridurre questo carico, a condizione che venga dimensionato correttamente e utilizzato insieme a un sistema affidabile di raccolta e conservazione dei log.

Non è necessario attivarlo indiscriminatamente su qualsiasi installazione, così come non bisogna considerarlo una soluzione a tutti i problemi di usura dello storage.

È però uno strumento che merita di essere preso seriamente in considerazione, soprattutto quando utilizziamo pfSense su appliance di fascia medio-bassa equipaggiate con memorie flash economiche.

Perché anche il firewall più sicuro, se improvvisamente smette di funzionare per un guasto al disco, può trasformarsi in un problema per la continuità operativa dell'intera azienda.

Riferimenti ufficiali

Netgate – Troubleshooting Disk Writes: https://docs.netgate.com/pfsense/en/latest/troubleshooting/disk-writes.html
Netgate – RAM Disk Settings: https://docs.netgate.com/pfsense/en/latest/config/advanced-misc.html
Netgate – Troubleshooting Full File System: https://docs.netgate.com/pfsense/en/latest/troubleshooting/filesystem-usage.html
Direttiva europea NIS2 – Direttiva (UE) 2022/2555.

Due vulnerabilità critiche PHP interessano pfSense: come proteggere il firewall

2026-10-25T21:37:12.716+01:00

Il 21 ottobre 2026 sono state divulgate due gravi vulnerabilità di sicurezza che interessano PHP, il linguaggio utilizzato da moltissime applicazioni web e anche da alcuni componenti di pfSense.

Le vulnerabilità, identificate come CVE-2026-109618 e CVE-2026-109619, hanno entrambe un livello di criticità elevato, con un punteggio CVSS di 9.2 su 10, e possono consentire a un attaccante remoto di eseguire codice arbitrario sui sistemi vulnerabili.

Netgate ha prontamente pubblicato un avviso di sicurezza e reso disponibili i pacchetti aggiornati per le principali versioni supportate di pfSense Community Edition e pfSense Plus.

Vediamo di cosa si tratta, quali installazioni sono realmente esposte e soprattutto come intervenire.

Le due vulnerabilità: CVE-2026-109618 e CVE-2026-109619

Entrambe le vulnerabilità interessano la gestione della memoria all'interno del motore PHP.

In determinate condizioni, un attaccante può sfruttare richieste HTTP opportunamente costruite per provocare un comportamento anomalo del processo PHP e arrivare, nei casi più gravi, all'esecuzione di codice remoto (Remote Code Execution, RCE).

Le due vulnerabilità presentano caratteristiche differenti.

CVE-2026-109618 – Gestione errata della memoria

La prima vulnerabilità riguarda il comportamento di PHP quando si verifica una condizione di esaurimento della memoria disponibile.

Durante l'elaborazione di una richiesta, alcune strutture interne potrebbero non essere inizializzate correttamente. Le successive operazioni di pulizia della memoria possono quindi utilizzare dati non validi, provocando una corruzione della memoria stessa.

Un attaccante potrebbe sfruttare questa condizione per eseguire codice arbitrario.

CVE-2026-109619 – Utilizzo di riferimenti a memoria non più valida

La seconda vulnerabilità riguarda invece la persistenza di alcuni riferimenti interni dopo che la memoria a cui puntano è stata liberata.

Quando il processo PHP gestisce una richiesta successiva, potrebbe utilizzare questi riferimenti prima che vengano correttamente reinizializzati.

Anche in questo caso, il risultato può essere una compromissione del processo PHP.

Il rischio è particolarmente significativo perché, in determinate configurazioni, lo sfruttamento delle vulnerabilità può avvenire senza necessità di autenticazione.

Quali versioni di pfSense sono interessate?

Le vulnerabilità interessano il linguaggio PHP e, di conseguenza, anche le versioni di pfSense che ne utilizzano una release vulnerabile.

Netgate ha reso disponibili i pacchetti corretti per le seguenti versioni:

Versione pfSense	Versione PHP corretta
pfSense CE 2.9.0	PHP 8.5.12
pfSense CE 2.8.1	PHP 8.3.36
pfSense Plus 26.07	PHP 8.5.12
pfSense Plus 26.03.1	PHP 8.5.12

Le installazioni che utilizzano versioni precedenti di PHP devono essere aggiornate.

Per le versioni di pfSense più datate, Netgate raccomanda di procedere all'aggiornamento verso una release attualmente supportata.

Tutti i firewall pfSense sono vulnerabili?

È importante chiarire che la presenza di una versione PHP vulnerabile non significa necessariamente che il firewall sia direttamente attaccabile da Internet.

Le vulnerabilità possono essere sfruttate attraverso i servizi che utilizzano PHP e che risultano raggiungibili dall'attaccante.

Nel caso di pfSense, i componenti principalmente interessati sono due.

Interfaccia di amministrazione web

L'interfaccia di amministrazione di pfSense utilizza PHP.

Nella configurazione predefinita, questa interfaccia non è accessibile dalla WAN, ma soltanto dalla rete locale.

Questo limita significativamente l'esposizione agli attacchi provenienti da Internet.

Il rischio aumenta quando l'interfaccia di amministrazione viene resa accessibile dalla WAN oppure da reti non attendibili, ad esempio reti guest, reti Wi-Fi pubbliche o segmenti di rete nei quali operano dispositivi non completamente controllati.

In questi casi, la disponibilità dell'interfaccia web potrebbe consentire a un attaccante di tentare lo sfruttamento delle vulnerabilità.

La soluzione migliore rimane quella di limitare l'accesso amministrativo a reti e dispositivi autorizzati, utilizzando una VPN per l'amministrazione remota.

Captive Portal

Una situazione differente riguarda il Captive Portal.

Questo servizio, frequentemente utilizzato per gestire l'accesso a reti Wi-Fi pubbliche o dedicate agli ospiti, è progettato proprio per essere raggiungibile da dispositivi non ancora autenticati.

Di conseguenza, un firewall che utilizza il Captive Portal può presentare una superficie di attacco maggiore, anche quando l'interfaccia di amministrazione è correttamente protetta.

Netgate raccomanda di aggiornare PHP il prima possibile su tutte le installazioni che utilizzano il Captive Portal.

Come aggiornare PHP su pfSense

Netgate ha distribuito i pacchetti PHP aggiornati attraverso i repository ufficiali.

Non è quindi necessario attendere una nuova release completa del firewall per correggere le vulnerabilità sulle versioni supportate indicate in precedenza.

C'è però un dettaglio importante: l'aggiornamento non può essere eseguito attraverso l'interfaccia web di pfSense.

È necessario utilizzare la console locale oppure una connessione SSH, accedendo alla shell del sistema.

Prima di procedere consigliamo, come sempre, di effettuare un backup della configurazione da Diagnostics > Backup & Restore e di pianificare l'intervento in una finestra di manutenzione.

Netgate propone tre differenti modalità di aggiornamento.

Metodo 1 – Aggiornamento completo e riavvio del firewall (consigliato)

Questa è la procedura raccomandata da Netgate.

Aggiorna tutti i pacchetti disponibili, reinstalla il pacchetto WireGuard per garantirne la compatibilità con la nuova versione PHP e riavvia il firewall.

Dalla shell eseguire:

pfSense-upgrade -c && \
pkg upgrade -y && \
pkg upgrade -fy pfSense-pkg-WireGuard && \
/etc/rc.reboot

Il riavvio permette di applicare correttamente anche eventuali altri aggiornamenti che richiedono il riavvio dei servizi o del sistema.

Attenzione: questa procedura comporta una temporanea interruzione dei servizi di rete durante il riavvio.

Metodo 2 – Aggiornamento senza riavvio del firewall

La seconda procedura permette di aggiornare i pacchetti senza riavviare completamente il sistema.

Vengono aggiornati i pacchetti disponibili e successivamente riavviati i servizi PHP, l'interfaccia web e il Captive Portal.

Eseguire:

pfSense-upgrade -c && \
pkg upgrade -y && \
pkg upgrade -fy pfSense-pkg-WireGuard && \
/etc/rc.php-fpm_restart && \
/etc/rc.restart_webgui && \
/etc/rc.captiveportal_configure

Questa modalità può essere utile quando non è possibile programmare un riavvio completo del firewall.

È particolarmente indicata per le installazioni che utilizzano il Captive Portal, perché prevede esplicitamente la riconfigurazione del servizio dopo l'aggiornamento.

Naturalmente, il riavvio dei servizi può comportare brevi interruzioni delle funzionalità interessate.

Metodo 3 – Aggiornamento senza riavvio e senza Captive Portal

La terza procedura è destinata alle installazioni che non utilizzano il Captive Portal.

Anche in questo caso vengono aggiornati i pacchetti, ma vengono riavviati soltanto i servizi necessari al funzionamento dell'interfaccia di amministrazione.

Eseguire:

pfSense-upgrade -c && \
pkg upgrade -y && \
pkg upgrade -fy pfSense-pkg-WireGuard && \
/etc/rc.php-fpm_restart && \
/etc/rc.restart_webgui

Questa soluzione consente di applicare gli aggiornamenti PHP senza eseguire un riavvio completo del firewall.

Rimane comunque preferibile la prima procedura quando le condizioni operative lo consentono.

Attenzione alle connessioni WireGuard

Tutte e tre le procedure prevedono la reinstallazione del pacchetto WireGuard.

Netgate ha introdotto questo passaggio per assicurare che il pacchetto utilizzi correttamente la nuova versione di PHP.

Chi amministra il firewall attraverso una connessione WireGuard deve prestare particolare attenzione: la connessione potrebbe interrompersi durante l'aggiornamento.

È quindi consigliabile disporre di un accesso alternativo al firewall prima di avviare la procedura.

Come verificare che l'aggiornamento sia riuscito

Al termine dell'aggiornamento è possibile verificare la versione di PHP installata accedendo nuovamente alla shell ed eseguendo:

php -v

Il comando deve restituire una delle versioni corrette, in funzione della release di pfSense utilizzata.

Ad esempio, su pfSense CE 2.9.0 il risultato dovrebbe indicare:

PHP 8.5.12

Mentre su pfSense CE 2.8.1:

PHP 8.3.36

È inoltre consigliabile verificare il corretto funzionamento dell'interfaccia amministrativa, delle VPN e, se presente, del Captive Portal.

Alcune raccomandazioni di sicurezza

L'aggiornamento di PHP rappresenta la soluzione definitiva alle vulnerabilità, ma l'occasione è utile anche per verificare alcune impostazioni di sicurezza del firewall.

Limitare l'accesso all'interfaccia di amministrazione

L'interfaccia web di pfSense non dovrebbe mai essere liberamente accessibile da Internet.

Per l'amministrazione remota è preferibile utilizzare una VPN e limitare l'accesso ai soli indirizzi e dispositivi autorizzati.

Verificare le regole firewall

È opportuno controllare che non esistano regole che permettano di raggiungere l'interfaccia amministrativa dalle reti WAN, guest o da altri segmenti non attendibili.

Prestare attenzione al Captive Portal

Se il Captive Portal è attivo, l'aggiornamento deve essere considerato prioritario.

Quando non è utilizzato, è preferibile mantenerlo disabilitato.

Non considerare un WAF una soluzione definitiva

Un Web Application Firewall può rappresentare un ulteriore livello di protezione, ma non deve essere considerato un sostituto dell'aggiornamento.

In particolare, trattandosi di vulnerabilità che interessano direttamente il motore PHP, non è possibile garantire che il semplice filtraggio delle richieste HTTP impedisca ogni possibile tentativo di sfruttamento.

Conclusioni

Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 rappresentano un problema di sicurezza importante, anche se il livello di rischio effettivo per un'installazione pfSense dipende soprattutto dai servizi esposti e dalla configurazione delle regole firewall.

Chi utilizza pfSense con le impostazioni di sicurezza consigliate, senza Captive Portal e con l'interfaccia amministrativa accessibile soltanto da reti attendibili, presenta un'esposizione decisamente inferiore.

Diversa è la situazione per i firewall che espongono l'interfaccia web o utilizzano il Captive Portal, sui quali consigliamo di intervenire con la massima priorità.

La disponibilità dei pacchetti corretti consente comunque di risolvere il problema senza necessariamente dover procedere all'aggiornamento completo della release di pfSense.

Il nostro consiglio è di verificare subito la versione PHP installata, controllare l'esposizione dei servizi e pianificare l'aggiornamento anche sulle installazioni non direttamente esposte.

Come sempre, una corretta configurazione del firewall e una gestione regolare degli aggiornamenti rimangono due elementi fondamentali per la sicurezza della rete.

Riferimenti ufficiali

Netgate – Critical PHP Security Update: https://www.netgate.com/blog/critical-php-security-update
PHP – Security Advisory: https://www.php.net/
CVE-2026-109618
CVE-2026-109619

Rilasciata la versione 2.9.0 di pfSense

2026-10-25T21:29:27.463+01:00

È arrivata la nuova versione 2.9.0 di pfSense Community Edition, che porta con sé numerose novità, aggiornamenti di sicurezza e correzioni di bug.

Come sempre, oltre alle nuove funzionalità, ci sono alcuni cambiamenti importanti da considerare prima di procedere con l'aggiornamento, soprattutto per chi utilizza pfSense in ambienti di produzione.

Vediamo le principali novità.

Sistema operativo e componenti aggiornati

La nuova release si basa su FreeBSD 16-CURRENT, un importante aggiornamento del sistema operativo su cui si appoggia pfSense.

Sono stati inoltre aggiornati diversi componenti fondamentali:

OpenSSL 3.5.7, per migliorare la sicurezza delle comunicazioni cifrate.
OpenSSH 10.3p1, con nuove funzionalità di sicurezza.
PHP, il linguaggio utilizzato anche dall'interfaccia di amministrazione.

Questi aggiornamenti consentono di mantenere il sistema allineato alle tecnologie più recenti, migliorando sicurezza e compatibilità.

Maggiore sicurezza per le connessioni SSH

Una delle novità più interessanti riguarda il supporto ad algoritmi crittografici post-quantistici per le connessioni SSH.

Si tratta di algoritmi progettati per resistere anche ad alcune tipologie di attacco che, in futuro, potrebbero diventare possibili grazie ai computer quantistici.

Contemporaneamente, sono stati rimossi alcuni algoritmi di crittografia più vecchi e considerati meno sicuri.

Attenzione: chi utilizza vecchi client SSH, SCP o SFTP potrebbe riscontrare problemi di connessione dopo l'aggiornamento. È quindi consigliabile verificare preventivamente la compatibilità degli strumenti utilizzati.

Certificati SSL/TLS: maggiore sicurezza e rinnovo automatico

Importanti novità anche nella gestione dei certificati digitali.

La nuova versione introduce controlli più rigorosi sulla sicurezza dei certificati, in particolare per quanto riguarda la lunghezza delle chiavi crittografiche.

I certificati che utilizzano chiavi troppo deboli, ad esempio inferiori a 2048 bit, potrebbero non essere più accettati.

Durante l'aggiornamento, pfSense verifica il certificato utilizzato dalla propria interfaccia web e, se necessario, ne genera automaticamente uno nuovo.

Viene inoltre introdotta una funzionalità particolarmente utile: il rinnovo automatico dei certificati.

Questa funzione permette di rinnovare automaticamente i certificati autofirmati oppure quelli emessi da una Certification Authority interna gestita da pfSense.

Per il certificato dell'interfaccia di amministrazione, il rinnovo automatico viene abilitato quando possibile.

Un'altra modifica riguarda la durata consigliata dei certificati server, che passa da 398 a 200 giorni, in linea con l'evoluzione degli standard di sicurezza.

Nuove funzionalità NAT per gaming, VoIP e applicazioni peer-to-peer

pfSense 2.9.0 introduce il supporto sperimentale a una nuova modalità di NAT chiamata Endpoint-independent Port Restricted Cone NAT.

Questa funzionalità permette di mantenere una corrispondenza più stabile tra indirizzi e porte utilizzate dai dispositivi interni quando comunicano con server differenti.

Il vantaggio riguarda soprattutto applicazioni che utilizzano comunicazioni UDP, come:

Videogiochi online.
Applicazioni VoIP.
Connessioni peer-to-peer.

La nuova modalità può aiutare a risolvere alcuni problemi di connettività senza ricorrere necessariamente a configurazioni statiche delle porte.

La funzionalità è ancora sperimentale, non è attiva automaticamente e deve essere abilitata sulle singole regole NAT.

Miglioramenti alle VPN IPsec e OpenVPN

Anche la gestione delle VPN beneficia di diversi aggiornamenti.

Per IPsec, il componente strongSwan viene aggiornato alla versione 6.0.3.

Sono inoltre stati corretti alcuni problemi relativi alla gestione dei gateway, al monitoraggio delle connessioni e alla stabilità del servizio durante le operazioni di rinnovo delle associazioni di sicurezza.

Per OpenVPN, le migliorie riguardano principalmente:

Una gestione più corretta dei gateway IPv6.
La configurazione automatica dell'MTU dei tunnel in determinate condizioni.
La correzione di alcuni problemi nelle configurazioni peer-to-peer.
Una gestione più selettiva dei riavvii delle istanze VPN quando vengono modificate le interfacce.

Quest'ultimo intervento è particolarmente interessante negli ambienti con numerose connessioni VPN, perché evita riavvii non necessari di tutte le istanze OpenVPN in seguito alla modifica di una singola interfaccia assegnata.

DHCP e DNS: aggiornamenti e maggiore stabilità

Il server DHCP Kea viene aggiornato alla versione 3.0.2.

È stata inoltre introdotta la possibilità di configurare il livello di dettaglio dei log generati dal servizio, facilitando le attività di diagnostica.

Sono stati corretti anche alcuni problemi relativi alla registrazione DNS degli indirizzi assegnati tramite DHCP, soprattutto in ambienti IPv6.

Per quanto riguarda il DNS Resolver, Unbound viene aggiornato alla versione 1.24.2, includendo la correzione della vulnerabilità CVE-2025-11411.

Ulteriori miglioramenti riguardano la gestione degli indirizzi NAT64 e la validazione delle configurazioni DNS.

Firewall e gestione delle connessioni

Diversi interventi riguardano direttamente il funzionamento del firewall.

In particolare, è stato rivisto il meccanismo di generazione delle regole PF, con l'obiettivo di migliorare affidabilità e gestione delle configurazioni.

È stata inoltre migliorata la gestione dei ricaricamenti delle regole, riducendo il rischio di interruzioni temporanee del traffico causate da operazioni non necessarie.

Altri interventi interessano il funzionamento del NAT64, la gestione delle regole flottanti e il comportamento delle connessioni in presenza di gateway multipli.

Per chi utilizza configurazioni Multi-WAN, è stata introdotta anche una funzionalità di recupero dei gateway che interviene quando tutti quelli appartenenti al gruppo di failover predefinito risultano offline.

Log di sistema e diagnostica

La nuova versione introduce alcuni miglioramenti anche nella gestione dei log.

È ora possibile impostare un livello di logging predefinito e sono stati corretti diversi problemi relativi alla registrazione e alla visualizzazione degli eventi.

Tra questi, anche un problema che poteva provocare l'interruzione del servizio syslog quando un server remoto rifiutava la connessione.

È stata inoltre corretta una condizione che poteva causare l'invio duplicato di alcuni eventi ai server syslog remoti.

Miglioramenti utili soprattutto negli ambienti in cui pfSense invia i propri log a sistemi centralizzati di monitoraggio e sicurezza.

Numerose correzioni di sicurezza

Oltre alle nuove funzionalità, la versione 2.9.0 include un numero significativo di aggiornamenti di sicurezza.

Gli interventi riguardano diverse componenti del sistema, tra cui l'interfaccia web, la gestione delle autenticazioni, OpenVPN, DHCP e il sistema operativo.

Sono state corrette diverse vulnerabilità di tipo Cross-Site Scripting (XSS), oltre ad alcune problematiche potenzialmente più gravi che, in specifiche condizioni, potevano consentire l'esecuzione di comandi.

Sono inoltre state integrate correzioni provenienti da FreeBSD, comprese quelle relative a WireGuard, OpenSSL e al client DHCP.

Il pacchetto System Patches, già utilizzato per distribuire alcune correzioni senza attendere una nuova release, viene ora incluso per impostazione predefinita.

Prima di aggiornare

Come per ogni aggiornamento importante, consigliamo di effettuare alcune verifiche preventive.

1. Effettua un backup della configurazione

Prima di procedere, scarica una copia aggiornata della configurazione del firewall.

2. Verifica la compatibilità hardware

Alcuni dispositivi, tra cui determinati sistemi con processori Intel Celeron J e specifici problemi firmware, potrebbero incontrare un errore critico durante l'avvio della versione 2.9.0.

Netgate ha documentato una soluzione che prevede la disabilitazione di uno specifico driver ACPI tramite il parametro:

hint.acpi_spmc.0.disabled=1

È importante verificare se il proprio hardware rientra tra quelli interessati prima di aggiornare.

3. Controlla i certificati

Verifica che i certificati utilizzati dai servizi, in particolare HTTPS e VPN, rispettino i nuovi requisiti di sicurezza.

4. Verifica le connessioni SSH

Se utilizzi software datati o dispositivi che si collegano al firewall tramite SSH, accertati che supportino gli algoritmi crittografici più recenti.

5. Controlla i pacchetti aggiuntivi

Verifica che tutti i pacchetti installati siano disponibili e compatibili con la nuova versione. Se necessario, pianifica la loro reinstallazione seguendo le indicazioni ufficiali.

6. Pianifica una finestra di manutenzione

Se il firewall gestisce una rete aziendale, programma l'aggiornamento in un momento di ridotta attività e assicurati di avere un accesso alternativo alla console in caso di problemi.

Conclusioni

pfSense 2.9.0 rappresenta un aggiornamento importante, soprattutto dal punto di vista della sicurezza e della manutenzione del sistema.

Le novità più interessanti riguardano la crittografia, la gestione automatica dei certificati, il miglioramento delle VPN e l'introduzione di nuove funzionalità NAT.

Non si tratta di una release che rivoluziona il funzionamento di pfSense, ma di un aggiornamento che consolida la piattaforma e introduce miglioramenti utili sia nelle piccole installazioni sia nelle infrastrutture più complesse.

Come sempre, il nostro consiglio è di non avere fretta di aggiornare i sistemi di produzione: meglio verificare prima la compatibilità dei componenti e, quando possibile, effettuare qualche test in un ambiente non critico.

Per chi vuole approfondire tutte le modifiche introdotte, comprese le numerose correzioni di bug, rimandiamo alla documentazione ufficiale Netgate.

Riferimenti ufficiali: https://docs.netgate.com/pfsense/en/latest/releases/2-9-0.html

Rilasciata la versione 2.8.0 di pfSense

2025-06-12T17:02:00.003+02:00

E' uscita a fine maggio la nuova versione di pfSense, 2.8.0

Questa nuova release, attesa ormai da qualche mese, porta con se parecchie novità e, come sempre, qualche controllo da fare per la compatibilità con sistemi obsoleti e poco performanti, nonchè alcune attenzioni da tenere durante il processo di aggiornamento.

Ecco le principali migliorie e nuove implementazioni:

Sistema operativo aggiornato

pfSense ora si basa su una versione più recente di FreeBSD (15-CURRENT). Ciò garantisce migliori prestazioni, compatibilità con nuovi hardware e un supporto più durevole nel tempo.

Un’interfaccia di backup più semplice

Ora è più facile fare il backup delle impostazioni del sistema grazie a una nuova schermata più chiara e comoda da usare. Puoi anche scaricare direttamente i backup, rinominarli o cambiare la chiave del dispositivo associato

Connessioni Internet più veloci con il nuovo driver

Chi usa connessioni Internet tipo PPPoE, come alcune offerte in fibra o ADSL, potrà notare prestazioni migliori. Questo grazie a un nuovo “motore” che gestisce meglio queste connessioni, utilizzando meno risorse del sistema. Non è attivo di default, ma si può abilitare facilmente.

Nuova tipologia di server DHCP

Il vecchio motore del server DHCP è stato aggiornato. Il nuovo sistema si chiama Kea, ed è più moderno e flessibile, soprattutto per chi utilizza IPv6. Questo cambiamento migliora la registrazione DNS

Compatibilità migliore con reti miste IPv6/IPv4

È stato aggiunto il supporto al NAT64, facilitando l'accesso da IPv6 a IPv4 in ambienti misti. .

Nuove impostazioni predefinite

Sono stati aggiunti alcuni nuovi "alias", ovvero scorciatoie per identificare gruppi di indirizzi IP in modo più semplice. Inoltre, alcune impostazioni di default sono state cambiate per rendere il sistema più stabile, soprattutto quando ci sono molte regole di firewall attive.

Prima di aggiornare

Fai un backup completo: Prima di tutto, salva le impostazioni attuali del sistema, così potrai sempre tornare indietro in caso di problemi.

Disinstalla i pacchetti aggiuntivi: Se hai installato estensioni o componenti aggiuntivi, meglio rimuoverli prima. Alcuni potrebbero non essere ancora compatibili con la nuova versione.

Controlla che il tuo hardware sia adatto: Verifica che il tuo dispositivo abbia abbastanza memoria e risorse per supportare la nuova versione.

riferimenti ufficiali: https://docs.netgate.com/pfsense/en/latest/releases/2-8-0.html

Creare un VPN IPsec per collegare 2 sedi

2025-02-11T09:00:00.001+01:00

Il protocollo IPsec è il più diffuso protocollo per creare una connessione VPN site to site ed è presente su pressochè tutti i firewall, garantendo così l'interoperabilità anche tra apparati differenti.

Come funziona IPsec?

In breve una connessione IPsec si articola in 4 punti:

Negoziazione (Fase 1): i due dispositivi che fanno da terminatori della VPN per le rispettive reti negoziano il metodo di crittografia e autenticazione tramite IKE.
Creazione della connessione (Fase 2): viene stabilita una Security Association (SA) e generata una chiave condivisa.
Trasferimento dati: i pacchetti IP vengono cifrati e trasmessi.
Chiusura della connessione: la SA viene terminata alla fine della comunicazione.

Prerequisiti

Per la configurazione di base che vedremo oggi è necessario che i due endpoint dispongano ciascuno di un IP pubblico e che le sottoreti interne da mettere in comunicazione non siano uguali o anche parzialmente sovrapposte.

In caso questi requisiti non siano presenti, nei prossimi articoli studieremo alcune di queste casistiche.

Configurazione

Nella nostra configurazione supporremo di avere due sedi:

1) Milano con IP pubblico 4.3.2.1 e lan con subnet 192.168.0.0/24

2) Roma con IP pubblico 1.2.3.4 e lan con subnet 192.168.1.0/24

Colleghiamoci al firewall della sede di Milano e configuriamo la connessione verso il server di Roma

Accediamo al menù VPN > IPsec

Clicchiamo su Add P1

Inseriamo una descrizione

Selezioniamo l'interfaccia su cui rimanere in ascolto

Nel remote gateway inseriamo l'ip pubblico della sede di Roma

Inseriamo una chiave condivisa

Selezioniamo gli algoritimi di crittografia secondo gli standard di sicurezza necessari, ad es.

AES256 - SHA512 - DH19

Una configurazione tipica sarà questa:

Lasciamo invariati gli altri parametri e salviamo.

Troveremo perciò la nostra connessione elencata nella pagina delle IP

Clicchiamo ora su Show Phase 2 e poi su Add P2

Scegliamo una descrizione per questa fase 2 e enseriamo la subnet locale e quella remota da mettere in comunicazione

e configuriamo la parte di sicurezza per la gestione di crittografia e autenticazione coi parametri come in figura (ESP - AES256 - SHA512 - DH 19)

Lasciamo gli altri parametri come proposti e salviamo.

Ci spostiamo ora sul firewall di Roma, dove faremo delle configurazioni identiche facendo attenzione a inserire:

- in fase 1, l'IP pubblico di Milano come remote gateway

- in fase 2, la local la remote subnet invertite

Una volta terminato il lavoro anche sul secondo firewall non ci resta che creare le regole sulle interfacce IPsec di entrambe le sedi per permettere il passaggio del traffico nelle due direzioni.

Ci posizioniamo perciò sul firewall prima di Milano e poi di Roma e creiamo una regola su ciascuno che, per semplicità, permette il passaggio di tutto il traffico:

A questo punto non ci resta che verificare lo stato del collegamento sotto Status > Ipsec e testare la bontà della connessione provando a far comunicare tra loro 2 apparati che risiedono sulle lan delle sedi che abbiamo collegato.

La Dashboard di pfSense

2025-02-04T09:30:00.009+01:00

Esploriamo oggi una delle funzioni maggiormente date per scontate, ma non sempre sfruttate al meglio: la Dashboard

La dashboard di pfSense è l'home page dell'interfaccia web e fornisce una panoramica completa sullo stato e sulle prestazioni del firewall.

La dashboard serve principalmente a:

Monitorare lo stato del sistema (utilizzo della CPU, RAM, spazio su disco, uptime).
Visualizzare interfacce di rete con indirizzi IP, stato delle connessioni e velocità.
Gestire connessioni VPN attive.
Controllare i log di sistema e traffico.
Accedere rapidamente alle impostazioni di firewall, NAT, regole e diagnostica.
Verificare gli aggiornamenti del sistema e dei pacchetti installati.

Per sfruttarla al meglio personalizza e minimizza i widget

La dashboard è composta da widget che possono essere aggiunti, rimossi o riorganizzati.
Vai su "Dashboard" > "Aggiungi widget" e seleziona quelli più utili per te

Sui miei pfSense non mancano mai:

System Information con le info generali più rilevanti
Traffic Graph che mi da informazioni sull'uso della banda in tempo reale
i due widget Gateways e Interfaces, che mi segnalano stato e velocità delle connessioni
Disks: che mi segnala lo stato del disco
Service status, che monitora i servizi
i due widget OpenVPN e Ipsec che mi descrivono lo stato delle connessioni remote

Un altro widget secondo me davvero utile è Pictures, che permette di caricare un'immagine: la utilizzo per distinguere le diverse sedi in modo da avere un riscontro immediato quando un cliente ha più firewall e non commettere errori di identificazione della macchina su cui sto lavorando (es. quando le sedi sono in diversi paesi, carico la bandiera)

URL Alias in pfSense

2025-01-28T09:00:00.002+01:00

Per chiudere la panoramica sugli alias che ci ha accompagnato in queste ultime settimane andiamo ad analizzare una tipologia di alias molto utile, che è quella delle URL Tables: posso caricare su un sito web, in una pagina raggiungibile dal firewall (pubblica o privata) un txt con un elenco di URL o IP e il sistema sarà in grado di fare il fetch di tutti i valori contenuti, utilizzandoli all'interno delle regole.

Questo permette di avere alias dinamici basati sul contenuto del file di cui viene fatto il retrieve.

Applicazioni interessanti possono essere quelle per creare regole di blocco sfruttando blacklist pubbliche, piuttosto che regole di permit basate su elenchi custom che andiamo a inserire in un txt online.

Vediamo i passi per creare una regola sfruttando questa funzionalità:

Creiamo l'alias di tipo URL Table (IPs): Firewall > Alias > URLs > Add

Verifichiamo che il sistema sia in grado di fare il fetch degli IP presenti su quella pagina web: Diagnostics - Tables - Selezioniamo l'Alias appena creato:

Scorrendo la pagina sono elencate tutte le entry presenti che possono essere anche in numero molto alto (gli Alias URL Table supportano oltre 30k indirizzi)

Andiamo ora a creare una regola ad hoc per vietare l'accesso a questi ip dalla LAN

Allo stesso modo potremo pubblicare dei file con un elenco di IP consentiti e creare regole che permettano l'accesso a specifici servizi in base agli IP sorgenti in esso contenuti.

Questa funzionalità spesso è utile quando vanno mantenute aggiornate in automatico liste di ip molto lunghe o spesso variabili e sopratutto liste di ip di fornitori di servizi terzi che pubblicano direttamente un url contenenti le liste di ip aggiornate al variare del loro indirizzi.

La nomenclatura degli Alias in pfSense

2025-01-17T15:26:00.002+01:00

La scorsa settimana abbiamo visto a cosa servono gli Alias.

Oggi voglio condividere con voi la nomenclatura che utilizzo per mantenerli ordinati:

Prefisso

IP_ = per gli IP
P_ = per le porte
NET_ = per liste di subnet
FQDN_ = per liste di FQDN
URL_ = per liste di IP/Porte/… scaricati da URL

Subnet di riferimento per IP o Subnet

Nome dell’alias

Ottenendo quindi questa forma: PREFISSO_SUBNET_NOME

Esempi possono essere:

IP_LAN_SRV_WEB_01
P_VOIP_UDP
NET_VOIP_IP_PHONE
URL_GOOGLE

Nella scelta dei nomi il trattino alto e lo spazio non sono utilizzabili, andremo quindi ad usare _

Utilizzare gli Alias in pfSense

2025-01-08T14:38:00.007+01:00

Gli Alias in pfSense sono dei placeholders per IP, Network, Porte e FQDN

Rappresentano uno strumento molto utile al fine di migliorare la comprensione delle regole che creiamo e la loro modifica in modo massivo.

Per gestire gli Alias dobbiamo posizionarci su Firewall > Alias

E' consigliato stabilire una nomenclatura standard per mantenere ordine e leggibilità

Cliccando su Add possiamo aggiungere un Alias assegnadogli un nome secondo la nomenclatura stabilita, scegliendo il tipo (host, port, ip table, ecc) ed inserendone infine i valori.

Gli Alias sono utilizzabili in modo annidato e per contenere più valori contemporaneamente.

Possono essere utilizzati in diversi punti della configurazione per creare regole e si autocompletano e autovalidano: se inizio a scrivere il nome di un alias in un campo, il sistema mi suggerisce con l'autocompletamento tutti i nome che matchano, ma solo se sono alias compatibili con quella tipologia di campo (es. un Port Alias mi sarà proposto solo in un campo dove va indicata una porto o un port range).

Gestire lo spegnimento pilotato di una appliance pfSense tramite NUT con UPS APC

2025-01-02T10:30:00.011+01:00

Quando si installa pfSense su una macchina fisica conviene proteggerlo dagli sbalzi o le mancanze di corrente tramite un UPS.

Oggi vediamo come gestire questo tipo di configurazione in uno scenario in cui il pfSense è collegato a un UPS della APC.

L'UPS APC è dotato di scheda di rete per la gestione remota via web (NMC2 o NMC3).

I passi da seguire sono i seguenti:

Installazione del pacchetto NUT su pfSense
Configurazione dell'SNMP sulla Network Card dell'UPS
Conifgurazione utente per lo shutdown sulla Network Card dell'UPS
Configurazione del NUT su pfSense

Eccoli nel dettaglio

Installazione del pacchetto NUT su pfSense

Da System > Package Manager > Available Packages > cercare e installare il pacchetto NUT

Configurazione dell'SNMP sulla Network Card dell'UPS

Loggarsi via web sulla Network Card e attivare l'SNMP v1 e configurare l'accesso in lettura al firewall:

Configuration > Network > SNMPv1 > Access > Abilitare
Configuration > Network > SNMPv1 > Access Control > Creare la community e inserire l'ip del firewall

Configurazione utente per lo shutdown sulla Network Card dell'UPS

Loggarsi via web sulla Network Card e crreare l'utente dedicato

Configuration > Security > Local Users > Management > Add User

Enable: Si
Username: shutdown
Password: sceglierne una sicura e univoca
User Type: device
Descrizione: utente per shutdown firewall
Next - Apply

Configurazione del NUT su pfSense

Una volta preparato tutto lato Network Card, non ci resta che configurare il pacchettoNUT che troviamo sotto Services > UPS

Services > UPS > UPS Settings

UPS Type: Remote snmp
UPS NAme: il nome dell'ups a cui ci colleghiamo
Enable Notifications: Si

Remote IP address: IP dell'UPS

Extra Arguments to driver (optional):

mibs = auto
community = nome_community_snmp_UPS
snmp_version = v1
pollfreq = 30

ignorelb

override.battery.charge.warning = XX //stimare dal runtime e poi verificare col test di shutdown. E' la soglia di warning pre shutdown calcolata in % della carica della batteria dell'UPS

override.battery.charge.low = YY //stimare dal runtime e poi verificare col test di shutdown. Questa è la % di carica dell'UPS raggiunta la quale parte lo shutdown del firewall

In Advanced

Additional configuration lines for upsmon.conf:

NOTIFYFLAG ONLINE SYSLOG+EXEC
NOTIFYFLAG ONBATT SYSLOG+EXEC
NOTIFYFLAG LOWBATT SYSLOG+EXEC
NOTIFYFLAG FSD SYSLOG+EXEC
NOTIFYFLAG COMMOK SYSLOG+EXEC
NOTIFYFLAG COMMBAD SYSLOG+EXEC
NOTIFYFLAG SHUTDOWN SYSLOG+EXEC
NOTIFYFLAG REPLBATT SYSLOG+EXEC
NOTIFYFLAG NOCOMM SYSLOG+EXEC
NOTIFYFLAG NOPARENT SYSLOG+EXEC

SHUTDOWNCMD "/sbin/shutdown -p +0

Additional configuration lines for upsd.users

shutdown //lo username dell'utente creato sulla network card (es. "shutdown")
password = la password dell'utente "shutdown"
upsmon slave

Al termine della configurazione è opportuno testarne la bontà e validare le soglie percentuali con un test di spegnimento programmato.

Reinstallare pfSense utilizzando il backup della configurazione

2024-12-27T09:00:00.005+01:00

Abbiamo visto qualche mese fa come installare da zero un pfSense versione 2.7

Come fare però se abbiamo necessità di reinstallare mantenendo le configurazioni?

Creare un backup

Il primo passo per poter fare il restore delle configurazioni è assicurarsi di avere un backup recente utile.

Accedere all'interfaccia web e andare su Diagnostics > Backup & Restore e selezionare "Backup extra data" oltre a quanto già selezionato di default

Cliccare su "Download configuration as XML"

Eseguire la reinstallazione

Per reinstallare pfSense possiamo utilizzare la guida creata in precedenza: Installare pfSense 2.7

Effettuare il restore della configurazione

Accedere all'interfaccia web tramite le credenziali di default, andare su Diagnostics > Backup & Restore e cliccare "Choose File" dal menù Configuration File sotto la sezione Restore Backup

Cliccare su Restore Configuration e attendere il reboot

Creare una VPN Site to Site con OpenVPN in pfSense 2.7

2024-12-24T15:03:00.006+01:00

Riproponiamo oggi la versione aggiornata di uno degli articoli più apprezzati del blog.

Questa volta però abbandoneremo la configurazione basata su chiave condivisa per passare a quella più sicura basata su certificati SSL.

Lo scenario prevede sempre una sede A che fa da server e una sede B che fa da client.

Nella sede A è necessaria la presenza di 1 IP pubblico statico, nella sede B può esserci o non esserci.

Sede A (Server):
LAN: 192.168.0.0/24
IP Pubblico: 1.2.3.4

Sede B (Client):
LAN: 192.168.5.0/24
IP Pubblico: 5.6.7.8

Rete Tunnel VPN: 192.168.254.0/24

1. Creazione della CA e dei Certificati

Accedere all'interfaccia web di pfSense (Sede A).

Navigare su System > Cert. Manager > CAs e cliccare su "Add" e inserire i seguenti parametri:

Descriptive Name: OpenVPN_CA
Method: Create internal Certificate Authority
Key Length: 2048
Digest Algorithm: SHA256
Common Name: OpenVPN-CA
Salvare cliccando su "Save".

Passare alla scheda Certificates e cliccare su "Add" per creare il certificato del server:

Method: Create internal Certificate
Certificate Authority: OpenVPN_CA
Descriptive Name: OpenVPN_Server
Common Name: server
Type: Server Certificate
Key Length: 2048
Digest Algorithm: SHA256

Ripetere l'operazione per creare il certificato del client (che sarà utilizzato sulla sede B):

Descriptive Name: OpenVPN_Client
Common Name: client
Type: Client Certificate

2. Configurazione del Server OpenVPN (Sede A)

Navigare su VPN > OpenVPN > Servers e cliccare su "Add" e configurare i seguenti parametri:

Server Mode: Peer to Peer (SSL/TLS)
Protocol: UDP
Device Mode: tun
Interface: WAN
Local Port: 1194
Description: Site-to-Site VPN Server

Cryptographic Settings:

TLS Authentication: Spuntare "Use a TLS Key" e generare la chiave cliccando su "Generate TLS Key".
Peer Certificate Authority: OpenVPN_CA
Server Certificate: OpenVPN_Server
Encryption Algorithm: CHACHA20-POLY1305; AES-256-GCM
Auth Digest Algorithm: SHA256
Hardware Crypto: No Hardware Crypto Acceleration

Tunnel Settings:

Tunnel Network: 192.168.254.0/24
Local Network: 192.168.0.0/24
Remote Network: 192.168.5.0/24

Salvare e applicare le modifiche

3. Configurazione del Firewall su Sede A

Andare su Firewall > Rules > WAN e cliccare su "Add" e configurare:

Action: Pass
Interface: WAN
Protocol: UDP
Source: Any
Destination: WAN Address
Destination Port Range: 1194
Description: Allow OpenVPN Traffic
Salvare e applicare le modifiche.

4. Esportazione e Importazione Certificati Client

Su pfSense (Sede A), navigare su System > Cert. Manager > Certificates.

Scaricare il certificato e la chiave privata del client OpenVPN.
Importare questi file su pfSense (Sede B) in System > Cert. Manager > Certificates cliccando su "Add" e selezionando "Import an existing certificate".

5. Configurazione del Client OpenVPN (Sede B)

Accedere all'interfaccia web di pfSense (Sede B). Navigare su VPN > OpenVPN > Clients e cliccare su "Add" e configurare i seguenti parametri:

Server Mode: Peer to Peer (SSL/TLS)
Protocol: UDP
Device Mode: tun
Interface: WAN
Server Host or Address: 1.2.3.4
Server Port: 1194
Description: Site-to-Site VPN Client

Cryptographic Settings:

Peer Certificate Authority: OpenVPN_CA
Client Certificate: OpenVPN_Client
Encryption Algorithm: CHACHA20-POLY1305; AES-256-GCM
Auth Digest Algorithm: SHA256
Hardware Crypto: No Hardware Crypto Acceleration

Tunnel Settings:

Tunnel Network: 192.168.254.0/24
Remote Network: 192.168.0.0/24

Salvare e applicare le modifiche.

6. Verifica della Connessione VPN

Navigare su Status > OpenVPN in entrambe le sedi: se la configurazione è corretta, vedrai la connessione attiva.

Log Management in pfSense - Come leggere i log in formato Raw

2024-08-27T08:00:00.001+02:00

pfSense di default ci presenta i log in formato parsed, più leggibili ma meno ricchi di informazioni.

Tramite i Log Raw invece possiamo riuscire a ricavare dati aggiuntivi che ci permettono di analizzare il traffico ed eventuali anomalie in modo più preciso.

Leggere un Log Raw di pfSense può sembrare complicato, ma con un po’ di pratica e una buiona guida che ce li spieghi non è così difficile. In questo articolo scopriremo come interpretarli

Visualizzare i Log Raw

Vai su Status - System Logs.

Seleziona la scheda Firewall.

Nelle impostazioni (icona della chiave inglese), sotto Formatted/Raw Display, scegliere Raw e salvare

Struttura dei Log Raw

I log raw di pfSense sono generalmente formattati come una singola linea di valori separati da virgole. Ecco una panoramica dei campi comuni che potresti trovare:

Timestamp: Data e ora dell’evento.

Hostname: Nome dell’host (non incluso nei log inviati tramite syslog).

Rule Number: Numero della regola che ha generato il log.

Interface: Interfaccia reale (es. em0).

Reason: Motivo dell’entrata nel log (es. match).

Action: Azione intrapresa (es. block, pass).

Direction: Direzione del traffico (in/out).

IP Version: Versione IP (4 per IPv4, 6 per IPv6).

Source IP: Indirizzo IP sorgente.

Destination IP: Indirizzo IP di destinazione.

Protocol: Protocollo (es. TCP, UDP).

Source Port: Porta sorgente.

Destination Port: Porta di destinazione.

Esempio di Log Raw

Un esempio di log raw potrebbe apparire così:

Aug 13 23:11:04 pfSense filterlog: 1000000103,0,,1000000103,em0,match,pass,in,4,0x0,,64,4500,0,DF,6,tcp,60,192.168.1.100,1.2.3.4,443,80,0,PA,123456789,987654321,1024,0,,mss;nop;wscale

Interpretazione del Log

Timestamp: Aug 13 23:11:04 - Data e ora dell’evento.

Hostname: pfSense - Nome dell’host.

Rule Number: 1000000103 - Numero della regola.

Interface: em0 - Interfaccia reale.

Reason: match - Motivo dell’entrata nel log.

Action: pass - Azione intrapresa.

Direction: in - Direzione del traffico.

IP Version: 4 - IPv4.

Source IP: 192.168.1.100 - Indirizzo IP sorgente.

Destination IP: 1.2.3.4 - Indirizzo IP di destinazione.

Protocol: tcp - Protocollo.

Source Port: 443 - Porta sorgente.

Destination Port: 80 - Porta di destinazione.

Strumenti Utili

grep: Puoi usare grep per filtrare i log e trovare informazioni specifiche.

Ad esempio: grep "192.168.1.100" /var/log/filter.log

clog: Per versioni precedenti di pfSense, puoi usare clog per leggere i file di log binari: clog /var/log/filter.log

Creare Regole di NAT in pfSense - Parte 1

2024-08-20T08:00:00.006+02:00

NAT IN PFSENSE

Il Network Address Translation (NAT) è una tecnica utilizzata per modificare gli indirizzi IP nei pacchetti di rete mentre transitano attraverso un router o un firewall. pfSense offre potenti funzionalità di NAT che possono essere configurate per gestire sia il traffico in entrata (inbound) che quello in uscita (outbound).
NAT InbounD.

NAT INBOUND

Il NAT Inbound, noto anche come Port Forwarding, consente di reindirizzare il traffico proveniente dall’esterno verso un indirizzo IP interno specifico.

Questo è utile quando si desidera rendere accessibili servizi interni, come un server web, agli utenti esterni.

Configurazione del NAT Inbound su pfSense

Navigare su Firewall - NAT: Selezionare la scheda “Port Forward”.

Aggiungere una nuova regola: Cliccare su “Add” per creare una nuova regola di port forwarding.

Configurare i dettagli della regola:

Interface: Selezionare l’interfaccia WAN.
Protocol: Scegliere il protocollo (TCP).
Destination: Selezionare “WAN address”.
Destination Port Range: Inserire la porta esterna
Redirect Target IP: Inserire l’indirizzo IP interno del server
Redirect Target Port: Inserire la porta interna
Salvare e applicare le modifiche: Cliccare su “Save” e poi su “Apply Changes”.

Esempio di NAT Inbound

Supponiamo di avere un server web interno con l’indirizzo IP 192.168.1.100 e di voler rendere accessibile il sito web tramite HTTPS su Internet. La configurazione della regola di port forwarding sarà la seguente:

NAT Outbound

Il NAT Outbound, noto anche come Source NAT, controlla come gli indirizzi IP interni vengono tradotti quando il traffico esce dalla rete locale verso Internet. Questo è utile per nascondere gli indirizzi IP interni e utilizzare un singolo indirizzo IP pubblico.

Configurazione del NAT Outbound su pfSense

Navigare a Firewall - NAT: Selezionare la scheda “Outbound”.

Selezionare la modalità di NAT Outbound: Scegliere tra Automatic, Hybrid, o Manual.

Automatic: pfSense gestisce automaticamente le regole di NAT Outbound.
Hybrid: Consente di aggiungere regole manuali mantenendo quelle automatiche.
Manual: Tutte le regole devono essere configurate manualmente.

Aggiungere una nuova regola (se in modalità Hybrid o Manual):

Interface: Selezionare l’interfaccia WAN.

Source: Inserire l’indirizzo IP del dispositivo interno

Source Port Range: Lasciare vuoto per tutte le porte.

Destination: Inserire l’indirizzo IP di destinazione

Translation / target: Selezionare “Interface address”.

Salvare e applicare le modifiche: Cliccare su “Save” e poi su “Apply Changes”.

Esempio di NAT Outbound

Supponiamo di avere un centralino con l’indirizzo IP 192.168.1.120 che deve contattare un SIP provider con l’indirizzo IP pubblico 1.2.3.4 presentandosi con un IP pubblico diverso da quello su cui è attestata l'interfaccia WAN del firewall. La configurazione della regola di NAT Outbound sarà la seguente:

Come aggiornare pfSense con fix e minor update

2024-08-13T23:07:00.018+02:00

Oltre agli update di versione e sottoversione, (da 2.6 a 2.7, oppure da 2.7 a 2.7.2) pfSense offre la possibilità di applicare dei fix per la risoluzione di bug e vulnerabilità tramite un pacchetto aggiuntivo chiamato System Patches.

Questo pacchetto è uno di quelli che consigliamo di installare sempre e di mantenere monitorato: ogni volta che risulta da aggiornare, significa che sono stati rilasciati uno o più aggiornamenti minori.

Ecco cosa fare quindi per installarlo, mantenerlo aggiornato ed applicare i fix:

Installazione: posizionarsi su System - Package Manager - Available Packages e cercare "patch"

Cliccare su install e attendere il termina dell'installazione.

Applicazione : posizionarsi poi su System - Patches e cliccare su Apply All Recomanded in fondo alla pagina per attivare tutte le patch.

Riavviare il firewall o il servizio coinvolto o ricaricare il filtro (di fianco a ogni patch è spiegato cosa serve fare per renderla subito operativa)

Creare regole di firewall in pfSense - parte 1

2024-06-05T23:45:00.001+02:00

Le regole del firewall in pfSense sono fondamentali per controllare il traffico tra le reti ad esso connesse, che siano esse reti Internet (WAN) o reti locali (LAN).

Le caratteristiche principali delle regole di firewall in pfSense sono:

Azione: Ogni regola può avere un’azione specifica:

Pass: Permette al traffico di passare attraverso il firewall.
Block: Scarta il traffico senza inviare alcuna risposta.
Reject: Scarta il traffico e invia un messaggio al mittente indicando che la connessione è stata rifiutata

Interfaccia: Specifica l’interfaccia su cui applicare la regola. La regola è sempre applicata in ingresso all'interfaccia in questione. In altre parole, le regole dell’interfaccia LAN si applicano al traffico proveniente dalla rete locale (LAN), mentre le regole dell’interfaccia WAN si applicano al traffico proveniente da Internet.
Versione TCP/IP: Puoi specificare se la regola si applica solo a IPv4, IPv6 o entrambi.
Protocollo: Indica il protocollo, ad esempio, TCP, UDP o ICMP.
Origine e destinazione: Le regole possono specificare sia l’indirizzo IP che la porta/e di origine che quelli di destinazione. Ad esempio, puoi consentire il traffico solo da un indirizzo IP specifico verso il centralino VoIP sulla VLAN fonia.
Ordine di valutazione: Le regole vengono valutate dall’alto verso il basso. La prima regola corrispondente viene applicata. L’ordine delle regole è perciò fondamentale affinchè il firewall si comporti come desiderato.
Negazione implicita: Se non c’è una regola corrispondente, il traffico viene implicitamente negato.

Ecco alcuni esempi:

1. Regola per permettere il traffico da Internet verso un web server interno posizionato nella LAN:

- Web Server:

- Nome della regola: "Permetti traffico HTTPS al Web Server"

- Interfaccia: WAN

- Protocollo: TCP

- Porte: 80 (HTTP) e 443 (HTTPS)

- Origine: Qualsiasi

- Destinazione: Indirizzo IP del web server nella LAN

- Azione: Pass

2. Regola che rigetta il traffico RDP dalla VLAN Users alla VLAN Server:

- Nome della regola: "Blocco traffico RDP tra VLAN Users e VLAN Server"

- Interfaccia: VLAN Users

- Protocollo: TCP

- Porta: 3389 (RDP)

- Origine: VLAN Users

- Destinazione: VLAN Server

- Azione: Reject

E' possibile poi specificare ulteriori parametri per controllare in modo ancor più granulare le regole (gateway da utlizzare, limiter, logging, ecc.), è possibile aggregare IP, subnet o porte tramite alias e molto altro ancora che scopriremo negli articoli delle prossime settimane.

Stay tuned!

Autenticazione Active Directory con pfSense

2024-05-14T07:30:00.001+02:00

Tra le più interessanti e utili funzioni che offre pfSense c'è l'opportunità di autenticare gli utenti appoggiandosi su back end di tipo LDAP, tipicamente Active Directory.

Ciò permette a un utente di accedere con le proprie credenziali di dominio alla OpenVPN remota o all'interfaccia web del firewall, laddove autorizzato.

Che cos'è LDAP?

LDAP è un protocollo applicativo utilizzato per gestire e accedere a servizi informativi distribuiti di directory. Organizza i dati in modo gerarchico, facilitandone il controllo e la gestione. E' il protocollo su cui Active Directory di Microsoft si appoggia per accedere al proprio database di utenti computer e oggetti.

Configurazione autenticazione LDAP con Active Directory su pfSense

Posizionarsi su System - User Manager - Authentication Servers

Cliccare su Add

Scegliere un Nome Descrittivo: SRV-DC

Type: LDAP

Hostname or IP address: l'ip o l'hostname di un domain controller che il firewall può raggiungere

Porta e protocollo: lasciare di default o impostare su LDAPS se necessario coi relativi parametri

Search Scope: Entire Subtree

Base DN: la base del vostro AD - es. DC=pfsenseitaly,DC=local

Authentication container: la OU che contine gli utenti da autenticare (utilizzare il tasto "Select a container") - es. OU=Users,DC=pfsenseitaly,DC=local

Extended Query: da flaggare

Query: gruppo precedentemente creato in AD e utilizzato per identificare uno specifico gruppo di utenti autorizzati - es. memberOf=CN=OpenVPN_Auth,OU=Groups,DC=pfsenseitaly,DC=local

Bind credentials: inserire le credenziali di un utente che abbia accesso in lettura al db di AD

Lasciare il resto di default e salvare.

Verifica autenticazione

Posizionarsi su Diagnostics - Authentication

Scegliere il back-end di autenticazione appena creato

Inserire le credenziali di un utente e cliccare su Test

Log Management in pfSense: quali quali informazioni fondamentali ci offrono

2024-05-07T00:11:00.000+02:00

Abbiamo visto in precedenza come conservare i log generati da pfSense su un server syslog remoto, ma non ci siamo ancora soffermati ad analizzare quali sono le principali voci che vengono registrate sul nostro firewall.

Ricordiamo che i log di pfSense sono conservati nel percorso /var/log e sono fruibili tramite interfaccia web nel menù Status > System Logs.

Andremo ad analizzare le sezioni più significative

System
Firewall
DHCP
Authentication
OpenVPN e IPsec
Packages

1. SISTEMA

I log di tipo System a loro volta contengono diverse sottosezioni, queste le principali

General: racchiude tutti gli eventi generati dai processi, da quelli generati dal kernel, all'interfaccia web e a molti altri sottosistemi sia quelli installati di default che alcuni pacchetti aggiuntivi. Si tratta comunque di processi che non producono molte registrazioni, I sottosistemi che generano grosse quantità di log, hanno il loro menù dedicato. Questi log sono utili per monitorare le attività dei principali processi e servizi (start e stop), sicurezza (sshguard), sincronia di membri di un cluster, login via web, comandi di riavvio o eventi legati allo stato dell'UPS se ce n'è uno collegato, e così via
Gateways: registra gli eventi relativi ai Gateway (in particolare perdita di pacchetti, stato online/offline, latenza dei monitor). Sono utili per il troubleshooting sulla connettività e sul multiwan
Os Boot: riporta l'output della procedura di boot ed è utile per il trobleshooting dell'avvio

2. FIREWALL

I log di questo tipo di default intercettano tutti gli eventi di block svolti dal Packet Filter.

Come configurazione globale o su singole regole è attivabile anche il logging dei pass

Viene segnalata l'azione (block o pass), l'orario, l'interfaccia di origine, la regola matchata, ip e porta di origine e di destinazione e tipo di protocollo (TCP/UDP + flag di extra information).

Sono fondamentali per verificare se c'è un evento di blocco e dovuto a cosa o, viceversa, per capire se il traffico stia effettivamente passando.

L'interpretazione di questi log merita un articolo a parte, che linkeremo appena disponibile

3. DHCP

Quando attivo su una o più interfacce, registrano i log del servizio DHCP server.

Contiene tutte le informazioni necessarie per verificarne il corretto funzionamento (gestione del lease, pool pieno, ecc.)

4. AUTHENTICATION

Contiene le informazioni circa i login riusciti e non, sia al firewall stesso sia per quei servizi per i quali svolge la funzione di back-end di autenticazione (Captive Portal per esempio o le VPN L2TP)

Monitora inoltre lo stato e i cambiamenti di diversi servizi (CARP, sshguard,ecc.)

5. VPN

IpSec e OpenVPN dispongono entrambe di un log dedicato, ognuno dei quali contiene informazioni sulle connessioni in corso e permettono di verificare al livello di dettaglio necessario (la verbosità potrebbe essere necessario cambiarla a livello dell'istanza da monitorare) eventuali problemi sulle connessioni (mancate risposte, certificati scaduti, mismatch di configurazione, configurazioni deprecate, autenticazione riuscita/fallita, ecc.)

6. PACKAGES

Questo log di default è vuoto, ma alcuni pacchetti extra (es. HAProxy) hanno un flag che permette di registrare i propri log, che finiranno in questa sezione.

Il menù dei log di pfSense contiene anche altre voci, ma oggi abbiamo voluto dettagliare maggiormente quelle che riteniamo più importanti.

Aggiugnere rotte alla OpenVPN con FQDN

2024-04-17T16:54:00.003+02:00

Un utilizzo abbastanza classico della VPN è quello di veicolare il traffico verso indirizzi specifici facendo passare il traffico dal tunnel, per presentarsi alla destinazione, anzichè col proprio indirizzo, con l'IP del sito in cui si trova la VPN.

Per esempio se il Sito A è configurato per poter essere accessibile solo dall'IP pubblico del mio ufficio, posso creare una VPN con l'ufficio che mi permetta di veicolando il traffico via VPN per arrivare al sito A.

In OpenVPN esistono i comandi di push route per ottenere questo comportamento: tuttavia nell'utilizzo base e più diffuso, è possibile passare solo degli indirizzi IP e non dei nomi FQDN.

Oggi vedremo come attuare questa configurazione avanzata.

Per prima cosa inseriamo nelle custom options del Server il push della rotta FQDN necessaria.

posizionarsi su VPN --> OpenVPN --> Server:
editare il Server utilizzato e posizionarsi su su Advanced Configuration -> Custom Options
inserire il push route con questa stringa: push "route google.com 255.255.255.255";

In questo modo tutto il traffico verso google.com sarà veicolato nel tunnel VPN e uscirà con l'ip pubblico del firewall pfSense che termina la VPN

Posizionarsi poi su VPN --> OpenVPN --> Client Export Utility:

sotto Advanced fare il push dell’opzione: “allow-pull-fqdn”

Una volta salvate le modifiche è possibile scaricare il certificato con la nuova configurazione.

Installare pfSense 2.7

2024-03-25T15:59:00.004+01:00

L'installazione di pfSense 2.7 può avvenire tranquillamente su una appliance fisica (persino su un pc purchè abbia almeno 2 schede di rete, anche se è fortemente consigliato utilizzare hardware dedicato), cosiccome in un ambiente virtuale on premises o in cloud.

La procedura di installazione è pressochè la medesima, fatto salvo il fatto che su hardware fisico dovremo preparare uno stick USB, mentre in ambito virtuale dovremo aver pre-caricato la ISO da cui far avviare la VM.

L'immagine con l'ultima versione la troviamo sul sito ufficiale: https://www.pfsense.org/download/, dove avremo anche la possibilità di leggere le release notes dell'ultima versione, prima di scaricarla.

Avviato l'installer tramite di default partirà l'installer senza fare nulla se non attendere

Accettiamo la licenza

Scegliamo Install e poi Auto (ZFS) - per approfondire l'uso di ZFS: Link

Andiamo a selezionare il disco di installazione e al termine clicchiamo su "Proceed with Installation"

Accettiamo l'avviso che ci mette in guardia sul fatto che tutto il contenuto del disco verrà distrutto, attendiamo il processo di installazione e poi procediamo col reboot

Attendiamo il riavvio e in meno di 10 minuti abbiamo il nostro nuovo firewall pfSense installato.

A questo punto possiamo procedere a configurare le interfacce di rete e poi il software stesso, tramite interfaccia web partendo dalle credenziali di default admin / pfsense

Riservare un IP specifico ai client collegati in VPN su pfSense 2.7

2024-03-14T08:30:00.000+01:00

Se utilizzate OpenVPN una delle necessità più ricorrenti è quella di operare un assegnamento statico degli indirizzi IP di uno o più client.

Tale necessità può sorgere, in genere, quando serve abilitare per una specifico utente l'accesso a un particolare servizio.

A livello di rules sarà necessario creare la regola di pass verso il servizio, limitandola alla source autorizzata: per fare questa limitazione sull'indirizzo sorgente, dovremo fare in modo che ogni volta che l'utente si collega, acquisisca sempre lo stesso IP.

Avevamo già scritto un articolo in precedenza (Assegnare IP statico a client OpenVPN), di cui riportiamo qui i requisiti, sempre validi, mentre aggiorniamo la procedura di configurazione che ora è ancora più semplice.

Prima di iniziare rammentiamo alcuni concetti di base:

tutte le configurazioni OpenVPN sono di tipo Client-Server;
anche le VPN Site to Site sono di tipo Client-Server;
quando parliamo di IP del client ci stiamo riferendo all'IP del tunnel stabilito tra client e server.

Sebbene siano nozioni scontate è bene rinfrescarle perchè spesso ci si dimentica che:

anche una connessione tra due firewall pfSense o più in generale tra due gateway deve essere configurata come client-server
al nostro client non verrà mai assegnato un IP della subnet locale del server.

Per poter assegnare un indirizzo IP statico ad un client è necessario:

poterlo individuare con certezza;
che non esistano due client che si presentino con lo stesso nome.

L'unico modo per farlo è utilizzare connessioni OpenVPN con certificati dove ogni client è identificato da un certificato con CN univoco e soprattutto usato per una sola installazione.

Se non sapete come fare vi consiglio di legere prima l'articolo "OpenVPN server su pfSense 2.7"

A questo punto assumiamo:

di aver configurato correttamente server e client;
di aver creato un certificato client: mario.rossi;
di aver scelto come subnet per il tunnel 10.0.0.0/24;

Per poter assegnare un IP statico alle due connessioni occorre effettuare la seguente configurazione sul server.
Accediamo a VPN > OpenVPN > Client Specific Overrides

In questa sezione dovremo creare un override per ogni client a cui vogliamo assegnare un IP statico
Per ogni Overrides dovremo indicare:

la descrizione dell'override in Description: es. Mario Rossi
l'identificativo del certificato sotto Common Name: es. mario.rossi
l'ip da assegnare staticamente in IPv4 Tunnel Network: es. 10.0.0.250/24

Questa configurazione, in cui viene indicato direttamente l'ip da assegnare, sostituisce la precedente, un pochino più tricky, che utilizzava le subnet /30.

La nuova modalità è onfigurata in questo del server Ovpn dove deve essere selezionato il valore di default "One IP address per client in a common subnet". Se selezioniamo l'altra opzione disponibile (net30), torniamo alla modalità con le subnet /30, che è ancora presente per retrocompatibilità e ambienti legacy.

Una volta effettuata questa configurazione avremo un ip statico sulla VPN per il Sig. Rossi da utilizzare per creare delle regole ad hoc che lo riguardano.

Log Management in pfSense

2024-03-11T09:00:00.005+01:00

La gestione dei log è un tema ormai fondamentale quando si parla di sicurezza informatica.

I log ci permettono di mantenere traccia degli eventi che impattano il nostro sistema e delle attività svolte dagli amministratori e dagli utenti.

Attualmente inoltre, una corretta gestione dei log non è solo un tema di sicurezza, ma anche di ottemperanza a leggi quali il GDPR, o di compliance a normative come la ISO27001 e a direttive europee, ad esempio la recente NIS2.

Oggi vedremo quali sono i principali strumenti di logging che ci offre pfSense e come configurarli in modo ottimale, per porterne gestire lo storico in modo flessibile e confacente le proprie necessità.

I log di pfSense sono conservati nel percorso /var/log e sono fruibili tramite interfaccia web nel menù Status > System Logs.

Sono organizzati in diversi macroblocchi, sfogliando i quali possiamo andare a rintracciare le attività legate a:

Sistema
Filtraggio del traffico
DHCP
Autenticazione
VPN (OpenVPN, IPsec, ecc.)
NTP
Pacchetti aggiuntivi

Ciascuna di queste voci dispone di una serie di sotto menù per la registrazione puntuale di diverse ti

topologie di eventi.

Log Settings

In questa voce di menù, che è l'ultima, troviamo tutte opzioni di configurazione per la raccolta dei log che andremo ad analizzare oggi.

PfSense mette a disposizione di default un numero molto ampio di log, tuttavia la loro conservazione in locale ha limiti di spazio, prestazioni e durata, motivo per cui porremo particolare attenzione alla conservazione in remoto.

Opzioni Generali

Log Message Format: è il formato dei syslog messaggi che vengono conservati in locale o che vengono inviati a un eventuale syslog server remoto. Sono disponibili due formati (RFC3164 o RFC5424): la scelta tra i due dipende dalla compatibilità col sistema di raccolta remoto.

RFC3164 è lo standard più datato, nativo di BSD, mentre RFC5424 è uno standard più recente che permette una gestione più precisa del timestamp.

La scelta tra i due formati dipende dalla compatibilità col sistema di parsing prescelto per renderli maggiormente leggibili, anche se entrambi gli standard possono essere utilizzati in qualsiasi demone syslog (syslog-ng e rsyslog, ecc.) e tendenzialmente i template per parsarli sono presenti nei principali motori di aggregazione log, come Splunk o Elastic, su cui si basa la maggior parte dei prodotti di log management in commercio.

La trasmissione dei messaggi Syslog inoltre può avvenire sia in UDP che in TCP.

Se non ci sono esigenze particolari, possiamo lasciare il default (RFC3164)

Selezionare le seguenti opzioni, valutando le altre alla bisogna:

Forward/Reverse Display
Log firewall default blocks
Log packets blocked by 'Block Bogon Networks' rules
Log packets blocked by 'Block Private Networks' rules
Log errors from the web server process
Generate log entries when making changes to the configuration

GUI Log Entries: 1000

Il tasto Reset log files, ci permette di eliminare tutti i log presenti in locale compresi i file di rotazione dei log.

Log Rotation

In questa sezione possiamo decidere la dimensione dei singoli file di log e poichè il sistema non è studiato per una conservazione long term in locale si consiglia di mantenere questi valori:

Log Rotation Size (Bytes): tra 512000 e 10240000

Log Retention Count: tra 7 e 14

Queste impostazioni si applicheranno a tutte e 20 le tipologie di file di log presenti, bisogna perciò fare attenzione allo spazio occupato.

Il sistema ci preallerta, indicandoci l'attuale spazio occupato dai log, il massimo raggiungibile con le dimensioni da noi impostate e lo spazio libero su disco in questo momento.

Log Compression: La compressione dei log va attivata solo in caso di file system diverso da ZFS, che di default comprime già il contenuto del disco.

Può essere utile disattivarla anche in caso di file di log molto grandi per i quali ci metterebbe troppa a comprimere o per sistemi particolarmente lenti.

Remote Logging Options

In questa sezione possiamo fare il redirect dei log verso un sistema remoto.

Source Address: scelgo l'interfaccia su cui fare il bind del servizio

IP Protocol: IPv4/IPv6

Remote log servers: ip_remote_syslog_server:port

E' possibile specificare fino a 3 server syslog remoti. E' necessario specificare la porta solo se differente dalla 514 UDP che è la porta di default del syslog.

L'invio avviene solo in UPD, se necessario attivarlo in TCP, si può utilizzare il pacchetto aggiuntivo syslog-ng, di cui non parleremo oggi, ma sarà oggetto di un articolo futuro.

Remote Syslog Contents: è possibile filtrare la tipologia di eventi da inviare al remote syslog selezionando le voci di interesse in questo menù.

Salvare al termine delle modifiche.

OpenVPN Server su pfSense 2.7

2024-03-07T08:00:00.001+01:00

Una delle funzionalità più utilizzate e più apprezzate di pfSense è la possibilità di fare da terminatore per la OpenVPN.

Abbiamo già descritto come creare un Server OpenVPN in diversi articoli precedenti (OpenVPN Server su pfSense 2.3, l'ultimo), ma vogliamo riprendere l'argomento, in quanto col passare del tempo e delle versioni sono cambiati gli algoritmi supportati e anche alcune delle funzionalità offerte dal configuratore.

In questo articolo prendiamo in considerazione la configurazione di un server pfSense come terminatore per una VPN Road Warrior, che permetta agli utenti remoti di collegare il proprio pc, da ovunque si trovino, alla rete aziendale.

Per autenticarsi saranno necessari un certificato SSL + username e password.

Il backend di autenticazione sarà il database locale del firewall stesso.

La configurazione che vedremo in seguito è effettuata su un pfSense 2.7.2

Gli step da effettuare sono i seguenti:

Creazione dei certificati (CA - Server - User)
Configurazione del server OpenVPN
Configurazione dell'interfaccia virtuale
Impostazione regole di firewall
Export della configurazione del client

Creazione dei certificati

Creazione del certificato della CA

Portarsi nel menù System > Cert Manager > CAs

Cliccare su Add

Compilare in modo preciso i campi sotto ripotati per la creazione del nostro certificato

Descriptive Name: Nome del certificato
Method: Create an internal Certificate Authority
Key length: 4096
Digest Algorithm: sha512
Lifetime: 3650 days (10 anni)
Country Code:
State or Province:
City:
Organization:
Email Address:
Common Name: internal-ca

Cliccare su Save

Creazione del certificato Server

Portarsi nel menù System > Cert Manager > Certificates

Cliccare su Add

Compilare in modo preciso i campi sotto ripotati per la creazione del nostro certificato

Method: Create an internal Certificate
Descriptive Name: Nome del certificato
Certificate Authority: la CA creata in precedentza
Key length: 4096
Digest Algorithm: sha512
Lifetime: 3650 days (10 anni)
Common Name: nome dns firewall
Country Code:
State or Province:
City:
Organization:
Email Address:
Certificate Type: Server Certificate

Cliccare su Save

Creazione della Certificate Revocation List

A questo punto è buona prassi creare anche una Certificate Revocation List che tornerà utile nel momento in cui ci sarà da invalidare dei certificati.

Portarsi nel menù System > Cert Manager > Certificate Revocation

Cliccare su Add or Import CRL in corrispondenza del nome del certificato della nostra CA

Compilare in modo preciso i campi sotto riportati per la creazione del nostro certificato

Certification Authority: la CA creata in precedentza
Method: Create an internal Certificate Revocation List
Descriptive Name: CRL
Lifetime: 730 days
Serial: 0

Cliccare su Save

Creazione del certificato User

Portarsi nel menù System > Cert Manager > Certificates

Cliccare su Add

Compilare in modo preciso i campi sotto riportati per la creazione del nostro certificato

Method: Create an internal Certificate
Descriptive Name: Nome del certificato (per esempio lo username dell'utente)
Certificate Authority: la CA creata in precedentza
Key length: 4096
Digest Algorithm: sha512
Lifetime: 3650 days (10 anni)
Common Name: lo username dell'utente
Distinguished Name:
Country Code:
State or Province:
City:
Organization:
Email Address:
Certificate Type: User Certificate

Se si utilizzano utenti locali al firewall la creazione del certificato può essere fatta contestualmente alla creazione dell'utente cliccando sulla voce apposita

Configurazione del server OpenVPN

Portarsi nel menù VPN > OpenVPN > Server

Cliccare su Add

Impostare i seguenti campi:

Description: il nome descrittivo
Server Mode: Remote Access (SSL/TSL + User Auth)
Selezioniamo i backend di autenticazione

Device Mode: tun
Protocol: UDP
Interface: WAN (interfaccia su cui viene fatto il bind)
Local Port: 1194
TLS authentication: YES
Automatically generate a shared TLS authentication key: YES
Peer Certificate Authority: Selezionare il certificato della CA appena creato
Peer Certificate Revocation List: Selezionare la CRL appena creata
Server Certificate: Selezionare il certificato del server appena creato
DH Parameters Length: 4096 bits
Encryption algorithm: CHACHA20-POLY1305 + AES-256-GCM
Auth digest algorithm: SHA256 (256-bit)
Hardware Crypto: selezionare una eventuale scheda di accelerazione
Certificate Depth: One (Client+Server)
Flaggare Strict User-CN Matching
Flaggare Enforce key usage
Tunnel Network: Inserire una subnet per il tunnel, non usare subnet già in uso.
Ipv4 Local network(s): inserire le subnet locali raggiugibili tramite la VPN separandole con virgola
Allow Compression: Refuse any non-stub compression
Topology: One IP address per client
Configurare eventuali impostazioni relative a DNS default domain, server DNS, NTP, NetBIOS secondo le proprie esigenze

Cliccare su Save

Configurazione dell'interfaccia virtuale

Per poter utilizzare il tunnel VPN come gateway nelle roules o per creare rotte statiche, è necessario assegnare al tunnel VPN un interfaccia virtuale.

Portarsi nel menù Interfaces > (assign)
Nella colonna Network port selezionare ovpns1 (REMOTE ACCESS)
Cliccare su Add per aggiungere la nuova interfaccia
Cliccare sul nome della nuova interfaccia, tipicamente optx
Nell'interfaccia effettuare le seguenti modifiche:

Enable: Yes
Description: OPENVPN_REMOTE

Cliccare su Save

Impostazione regole di firewall

A questo punto non ci resta che configurare il firewall affinchè permetta il traffico verso la wan sulla porta 1194 UDP per ricevere le connessioni dai client OpenVPN e creare le regole sull'interfaccia virtuale per permettere il traffico tra i client e il site della vpn.

Portarsi sul menù Firewall > Rules > WAN

Cliccare su Add

E compilare i seguenti campi:

Action: Pass
Protocol: UDP
Destination Port Range: From OpenVPN to OpenVPN

Cliccare su Save

Portarsi sul menù Firewall > Rules > OPENVPN_REMOTE

Cliccare su Add

E compilare i seguenti campi:

Action: Pass
Protocol: Any
Source: Any
Destination: Any

Cliccare su Save (questa regola fa passare tutto il traffico verso le subnet raggiungibili in VPN, restringere le regole secondo necessità).

Export della configurazione del client

Per esportare la configurazione da inserire nel client OpenVPN sul proprio device, installare il pacchetto aggiuntivo openvpn-client-export

Una volta installato posizionarsi su VPN > OpenVPN > Client Export

Scaricare il file di configurazione cliccando sul tasto Most Clients di fianco al nome dell'utnete di nostro interesse

Bloccare regole con gateway specifico in ambiente MultiWAN quando questo non è disponibile

2024-03-04T11:27:00.090+01:00

In ambienti MultiWAN può sorgere l'esigenza di configurare una regola affinché utilizzi sempre e solo uno specifico gateway.

In caso il gateway in questione si trovi in stato di down, il comportamento di default di pfSense è quello di ignorare tale specifica e di far fluire il traffico tramite il gateway di default.

Se questo comportamento non è quello desiderato, è possibile inibire tale l'automatismo, vincolando il traffico intercettato dalla regola alla disponibilità del suo specifico gateway.

La modifica va apportata in System - Advanced - Miscellaneous ed ha valenza globale

E' consigliabile, infine, creare una regola di reject coi medesimi criteri sotto la rule incriminata, per evitare possibili match con eventuali regole seguenti.

Abilitare FTP Client Proxy su pfSense

2024-02-28T11:19:00.007+01:00

Il FTP Client Proxy su pfSense è uno strumento che offre vantaggi di sicurezza e gestione per le connessioni FTP.

Funziona come intermediario tra il client e il server FTP, intercettando le richieste FTP e gestendo separatamente le connessioni di dati e di controllo.
I principali vantaggi di una sua implementazione sono:

NAT traversal: Facilita la gestione delle connessioni in presenza di NAT

Sicurezza: L'FTP Proxy Client può fornire un livello aggiuntivo di sicurezza agendo come un punto di controllo per monitorare e filtrare il traffico FTP in base alle politiche di sicurezza dell'azienda;

Controllo degli accessi: Può essere utilizzato per controllare e limitare gli accessi agli utenti FTP. Ad esempio, è possibile configurarlo per consentire solo determinati indirizzi IP o utenti autorizzati a connettersi ai server FTP interni;

Logging: L'FTP Proxy Client registra le attività FTP, consentendo agli amministratori di rete di monitorare e analizzare il traffico per identificare eventuali problemi di sicurezza o anomalie;

Riduzione del carico di lavoro: In ambienti con un alto volume di traffico FTP, l'FTP Proxy Client può ridurre il carico sui server FTP interni, gestendo in modo efficiente le connessioni e ottimizzando le risorse di rete;

Supporto per protocolli FTP attuali e legacy: Può essere configurato per supportare sia il tradizionale protocollo FTP (File Transfer Protocol) che le sue varianti più sicure come FTPS (FTP over SSL/TLS) e SFTP (SSH File Transfer Protocol).

Gli step di installazione e configurazione sono i seguenti:

Installare il package da System à Package Manager à Avaiable Packages
Individuare il Package: FTP_Client_Proxy

Una volta installando andare su à Services à FTP Client Proxy
Posizionarsi su Local Interface à Selezionare l’interfaccia locale sul quale applicare questo package (la/le LAN/VLAN desiderate): in questo caso lo applichiamo su un interfaccia di Bridge.

Flaggare Early Firewall Rule per posizionare le regole FTP in cima al set di regole per ignorare i blocchi espliciti; aiuta inoltre a consentire l’FTP passivo verso destinazioni arbitrarie
Flaggare Rewrite Source to Port 20
Abilitare le Log Connection per avere una traccia all’interno dei log.