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

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

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

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

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:

1. 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
2. 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.
3. Versione TCP/IP: Puoi specificare se la regola si applica solo a IPv4, IPv6 o entrambi.
4. Protocollo: Indica il protocollo, ad esempio, TCP, UDP o ICMP.
5. 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.
6. 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.
7. 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

 

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

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

1. System
2. Firewall
3. DHCP
4. Authentication
5. OpenVPN e IPsec
6. Packages 

1. SISTEMA

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

1. 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 
2. 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
3. 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

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

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

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

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

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

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

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.

Rilasciata la versione 2.7.2 di pfSense

 

 E' stata rilasciata la versione 2.7 di pfSense a cui sono seguite, nel giro di poche settimane, le minor release 2.7.1 e 2.7.2.

Vediamo quali sono le principali migliorie e i fix più importanti introdotti.

Versione 2.7.0

La versione 2.7.0 (qui i dettagli) ha introdotto diverse novità interessanti, in particolare i major upgrade delle versioni di PHP e del sistema operativo FreeBSD.

In particolare:

• PHP è stato aggiornato dalla versione 7.4.x a 8.2.6.
• Il sistema operativo di base è stato aggiornato a FreeBSD 14-CURRENT

Sono poi state apportate diverse modifiche agli algoritmi accettati dalle VPN Ipsec:

• Sono stati rimossi diversi algoritmi IPsec deprecati, tra cui:
• 3DES Encryption
• Blowfish Encryption
• CAST 128 Encryption
• MD5 HMAC Authentication

Stanti queste modifiche, prima di aggiornare, è importante controllare e riconfigurare le tue connessioni IPsec utilizzando algoritmi di crittografia più sicuri, e testarle.

• E’ stato aggiunto il supporto per la crittografia ChaCha20-Poly1305 con IPsec.

Altre modifiche:

• Captive Portal è stato migrato da IPFW a PF
• E’ stata introdotta una nuova GUI per il Packet Capture
• OpenVPN è stata upgradata alla 2.6.4

Sono state inoltre fixate diverse vulnerabilità e migliorata la GUI

NB. Il processo di aggiornamento da versioni più vecchie (2.5.x) prevede la necessità di fare un aggiornamento intermedio alla 2.6.

Come sempre, prima di effettuare un aggiornamento è consigliato effettuare il backup della configurazione.

Versioni 2.7.1 e 2.7.2

Le versioni 2.71. e 2.7.2 apportano poche modifiche sostanziali, ma implementano il fix di diverse vulnerabilità:

• 2.7.1 (elenco completo qui)

• Migliora il supporto a SCTP
• PHP è stato aggiornato alla versione 8.2.11.
• Il sistema operativo di base è stato aggiornato a un punto più recente su FreeBSD 14-CURRENT.
• OpenSSL nel sistema base è stato aggiornato dalla versione 1.1.1g a 1.1.1n.
• Risolve la vulnerabilità di tipo remote code execution CVE-2023-42326

• 2.7.2  (elenco completo qui)

• Sono state apportate correzioni per diverse Notices e Security Advisories di FreeBSD, tra cui:
• Vulnerabilità di spoofing TCP in pf (4) (FreeBSD-SA-23:17.pf)
• Possibile corruzione dei dati ZFS (FreeBSD-EN-23:16.openzfs)
• Utilizzo elevato della CPU da parte dei thread del kernel ZFS (FreeBSD-EN-23:18.openzfs)
• Implementazione AES-GCM errata in ossl (4) (FreeBSD-EN-23:17.ossl)
• Problemi di prestazioni in OpenSSL, corretti con accelerazione come AES-NI
• Viene installata la versione 2.6.8 di OpenVPN che risolve le vulnerabilità CVE-2023-46849  e CVE-2023-46850

 

Come sempre, prima di effettuare un aggiornamento è consigliato effettuare il backup della configurazione. Al termine dell’update, installare tramite l'apposito addon le eventuali patch presenti.

Per quanto riguarda gli update, nei test effettuati anche su configurazioni complesse, non ho riscontrato problemi.

Se aggiornate in presenza di pacchetti deprecati perderete le funzionalità offerte da tali pacchetti, non sono state previste migrazioni automatiche a versioni alternative dei servizi.

Se durante gli aggiornamenti doveste riscontrare anomalie, scrivetelo nei commenti