Hardware Tweakers

Con l'evoluzione del progetto OPNsense vengono nel tempo introdotte modifiche quindi anche le guide richiedono di essere aggiornate.
In questo topic approfitto del "revamping" della configurazione del mio sistema per spiegare alcuni aggiornamenti.

IDS/IPS
In Service c'è un componente che si chiama Intrusion Detection, questo componente è basato su Suricata.

La sua pagina di configurazione è simile a questa: Grazie all'help in linea è tutto abbastanza semplice da capire, la parte nuova è la "Capture mode" che si è arricchita di una voce: "Divert (IPS)"
Diversamente dalla Netmap che richiede di selezionare le interfacce da filtrare e che filtra tutto quello che passa attraverso quelle interfacce, la modalità Divert filtra solo quello che riguarda una certa regola ma questo richiede di modificare le regole stesse del firewall.

Apro una parentesi:
Dalla versione 26 OPNsense ha cambiato il suo sistema di regole firewall.
Prima ogni interfaccia aveva le sue regole, ora c'è una unica finestra con tutte le regole con la solita priorità da quella più in alto a quella più in basso.
Se vogliamo che nella regola vengano applicati i filtri IPS bisogna editarla, attivare la modalità avanzata e scendere fino a trovare la voce Divert-to e selezionare la voce Intrusion Detection Novità
Perchè è stata fatta questa modifica e che impatto ha?
Leggendo la documentazione ho capito che un IPS che ascolta su una intera interfaccia analizza tutto quello che passa per essa, questo può aumentare di molto il carico computazionale richiesta dai filtri, sopratutto con alcuni che sono molto pesanti.
Dato che per loro natura i firewall bloccano tutto quello che non è esplicitamente permesso è inutile analizzare del traffico che verrebbe comunque bloccato a valle nelle regole firewall.
Inoltre protremmo avere diverse VLAN interne che necessitiamo che comunichino tra loro ma a cui non vogliamo aggiungere alcun filtro IPS sulle comunicazioni interne ma al tempo stesso vorremmo proteggere da e verso altre destinazioni. Con Netmap non sarebbe possibile, una volta selezionata l'interfaccia lui analizza tutto.
Quindi è sensato far transitare attraverso l'IPS solo il traffico che effettivamente andiamo a permettere e solo delle regole che ci interessano tipo la regola base "Default allow LAN to any rule".

Configurazione base
Tornando alla pagine di configurazione principale c'è un'altra voce a cui prestare attensione ovvero la "Home networks".
Qui bisogna inserire tutti gli indirizzi considerati interni alla lan, io uso indirizzi 192.168.*.* quindi ha senso inserire 192.168.0.0/24. Se usate indirizzi che iniziano per 10 o per 172 dovrete modificare questo parametro di conseguenza.
Questo ha impatto sulle molte regole IDS/IPS scritte pensando a un $HOME_NET ovvero a tutto quello che è un RFC1918

Rulesets
Passando alla scheda "Download" delle impostazioni del IDS/IPS troverete un sacco di voci che non sono granchè "parlanti".
Senza approfondire ogni singola voce riassumiamo così:

• abuse.ch = feed/IOC (URL/IP/certificati/hashes) “noti cattivi”
• ET Open = ruleset IDS/IPS gratuito “generalista” per minacce di rete
• ET Telemetry = ET Pro (più ricco) gratis ma con telemetria anonimizzata verso Proofpoint/ET
• OPNsense-App-detect = blocca/rileva applicazioni e servizi (policy), non nasce come feed “anti-malware”

L'IDS/IPS OPNsense (Suricata) può gestire due tipi di cose diverse:

• Feed/Blacklists = elenchi di indicatori (IP, domini, URL, certificati, hash…) noti come malevoli, utili per bloccare/riconoscere “nomi e indirizzi” cattivi
• Ruleset IDS/IPS = regole (signature) che analizzano il traffico e riconoscono comportamenti/pattern tipici di attacchi, malware, exploit, C2 ecc

abuse.ch (feed di threat intel “community-driven”): è un insieme di piattaforme che pubblicano dati/indicatori su malware e botnet (URL malevoli, C2, certificati SSL, ecc.) usati poi come feed/blacklist.

• abuse.ch/URLHaus = Regole per identificare URL/siti che distribuiscono malware (malware distribution). OPNsense descrive URLHaus come lista di siti compromessi che distribuiscono malware
• abuse.ch/Feodo Tracker = Contiene regole/IOC per botnet C2 tracciati da Feodo Tracker (Dridex/Heodo/TrickBot/QakBot/BazarLoader ecc.), pensate per rilevare/bloccare connessioni verso C2
• abuse.ch/SSL Fingerprint Blacklist = Si basa su fingerprint di certificati SSL (e relativi indicatori) per intercettare connessioni TLS malevole associate a botnet/malware. La pagina SSLBL descrive esplicitamente l’uso di ruleset Suricata basati su fingerprint per detect/block
• abuse.ch/SSL IP Blacklist = È una blacklist di IP/port di C2 associati a certificati SSL blacklisted: SSLBL spiega che raccoglie IP che presentano certificati malevoli e che sono spesso server C2
• abuse.ch/ThreatFox = ThreatFox esporta un ruleset Suricata di IOC “network-based” (domini/IP ecc.) con “scadenza” (solo ultimi 6 mesi) per ridurre falsi positivi, e viene rigenerato frequentemente

ET Open (Emerging Threats Open – ruleset IDS/IPS “gratis”) = è un ruleset di firme per Suricata/Snort rilasciato “Open”, usatissimo per rilevare minacce di rete; in OPNsense è spesso il punto di partenza. Rispetto ad abuse.ch sono regole che analizzano il traffico e riconoscono pattern di attacco (non solo “liste di cattivi”)

ET Telemetry (ET Pro Telemetry Edition – “ET Pro gratis in cambio di telemetria”) = è un programma/edizione in cui ottieni regole ET Pro (più ricche e aggiornate) gratuitamente, ma il tuo firewall invia a Proofpoint/ET telemetria anonimizzata sugli alert
Invia un sottoinsieme anonimizzato dei log eventi IDS di Suricata, pensato per identificare gli “attaccanti”, con altri campi rimossi o randomizzati sul firewall ed un heartbeat periodico per mantenere attivo l’accesso al ruleset Telemetry.
In cambio si ha accesso a ET Pro ruleset con aggiornamenti frequenti e molte categorie di firme; dichiarato come miglioramento rispetto a ET Open. Se la telemetria “manca” per un certo periodo, il sistema può tornare a ET Open finché la telemetria riprende (meccanismo di “good standing”).

OPNsense-App-detect (Application Detection rules – “blocca app/siti, non (solo) malware”) = è un ruleset OPNsense pensato per riconoscere e bloccare app/servizi web specifici (tipo YouTube, Netflix, social, chat), più che minacce “malware”
Contiene regole generate da liste (.lst) che mappano nome app + categoria + dominio/URL da bloccare (es. streaming, social, messaging, mail…).
È presentato in OPNsense come ruleset “App detection rules”.
Rispetto a ET Open / ET Telemetry è focalizzato su policy/controllo: “voglio impedire l’uso di X (YouTube, WhatsApp Web, ecc.)”


Personalmente ho scaricato tutti i rulesets abuse.ch e ET telemetry.
Poi bisogna passare alla sottosezione "Policy" dove le cose si fanno un po' più complicate.
A titolo di esempio queste sono le mie policy: Potete vedere le regole selezionate per ogni policy e cosa fanno (nell'ultima ho solezionato tutte le regole ET Telemetry rimaste fuori)

Questa schermata serve a creare/modificare una Policy (una “regola di policy”) che dice a Suricata/OPNsense:

• A quali regole Suricata applicarsi (scegliendo set di regole, filtri e metadati)
• Che cosa fare quando quelle regole “matchano” (es.: solo avviso = Alert, oppure blocco = Drop, ecc.)
• Con quale priorità rispetto alle altre policy

Una policy è un “filtro” che seleziona un gruppo di regole Suricata e gli assegna un’azione. Se lasci un campo su Nothing selected, significa in pratica: “non filtrare per questo criterio” (quindi vale per tutto).

Quando si va a creare una nuova regola ci si trova di fronte a questo: 1) Sezione: Rule details
Enabled (checkbox)

• Cosa fa: attiva o disattiva questa policy.
• Quando usarlo: se vuoi “provare” una policy senza cancellarla, basta togliere la spunta.
• Suggerimento: in fase di test, crea più policy e abilita/disabilita per capire l’effetto.

Priority (campo numerico)
Nella schermata si legge: “Policies are processed as if first match wins; a lower number means more important.”

Quindi:

• Cosa fa: decide l’ordine in cui le policy vengono valutate.
• Regola generale: numero più basso = maggiore priorità.
• Meccanismo tipico: quando una policy “matcha” una regola, l’azione applicata è quella della policy con priorità più alta (di solito “first match wins”).

Perché è importante: se hai una policy “generica” con priorità alta (numero basso), potrebbe “catturare” tutto e rendere inutili le policy più specifiche.

2) Sezione: Rulesets
Rulesets (menu a tendina / selezione multipla) + opzioni Clear e Select all

• Cosa sono: i “pacchetti”/insiemi di regole che hai scaricato/abilitato (es. set ET, Snort, abuse.ch, ecc. — dipende da cosa hai scaricato).
• Cosa fa questo campo: limita questa policy alle regole che appartengono ai Ruleset selezionati.
• Nothing selected: la policy non limita per Ruleset → potenzialmente si applica a tutti i ruleset.
• Clear: azzera la selezione (torni a “Nothing selected”).
• Select all: seleziona tutti i ruleset disponibili.

Consiglio per neofiti: Inizia selezionando solo i ruleset che vuoi davvero gestire con questa policy (es. solo un set “malware/cnc”). Evita “Select all” finché non hai confidenza, perché potresti generare molti alert o blocchi indesiderati.

3) Sezione: Action
Action (menu a tendina) + opzioni Clear e Select all

• Cosa fa: filtra ulteriormente le regole in base all’azione “originaria”/classificazione che OPNsense/Suricata attribuisce o che risulta dalla gestione regole.
• Uso pratico: in molte installazioni, questo campo si usa meno come “filtro” e più come parte della logica interna della policy. Se non sai cosa scegliere, lascialo su Nothing selected per non restringere inutilmente.
• Clear: rimuove la selezione.
• Select all: include tutte le azioni disponibili.

Nota importante (IDS vs IPS)

• In modalità IDS, Suricata tipicamente avvisa (alert) ma non blocca.
• In modalità IPS, Suricata può bloccare (drop/reject) se le policy/azioni lo prevedono.

Quindi è fondamentale capire in che modalità stai lavorando prima di “spingere” su azioni aggressive.

4) Sezione: Rules (filtri per metadati)
Questa è la parte più lunga: qui puoi filtrare quali regole verranno coinvolte dalla policy usando i metadati delle firme Suricata.
Come leggere questi campi

• Ogni riga è un criterio (metadato) con una selezione (spesso multipla).
• Nothing selected = non filtro per quel metadato.
• Quando selezioni più criteri diversi (es. classtype + confidence_level), in genere la logica è: la regola deve soddisfarli tutti (AND).
• Quando selezioni più valori nello stesso campo (es. 3 “classtype”), in genere significa: uno qualsiasi di quei valori (OR).

Di seguito la spiegazione campo per campo come appare nella schermata.

affected_product

• Cos’è: prodotto/ambiente potenzialmente colpito (es. un software, un componente, una piattaforma).
• A cosa serve: creare policy mirate (es. protezione specifica per un prodotto presente nella tua rete).
• Esempio pratico: se in rete hai molti host con un certo servizio, puoi “alzare la guardia” solo su quel prodotto.

attack_target

• Cos’è: “bersaglio” tipico dell’attacco (es. client, server, endpoint, ecc., dipende da come il ruleset definisce il metadato).
• A cosa serve: distinguere regole che proteggono client vs regole che proteggono server, e applicare azioni diverse.
• Esempio: policy più severa sui server esposti, più permissiva sui client interni.

classtype

• Cos’è: classificazione della regola (categoria dell’evento: malware, policy-violation, attempted-admin, trojan, ecc. — dipende dal ruleset).
• A cosa serve: è uno dei filtri più utili per i neofiti perché raggruppa le regole per “tipo di problema”.
• Esempio:
  • Alert per “policy-violation”
  • Drop per “trojan-activity” o “command-and-control”

confidence

• Cos’è: indicazione “testuale” o generica del grado di affidabilità della firma (dipende dal set regole).
• A cosa serve: filtrare regole più “sicure” (meno falsi positivi) vs più “rumorose”.
• Suggerimento: se sei all’inizio, privilegia regole ad alta confidenza per eventuali blocchi.

confidence_level

• Cos’è: livello di confidenza espresso come “livello” (spesso più strutturato di “confidence”).
• A cosa serve: simile a confidence, ma spesso più comodo da usare (Low/Medium/High o simili, secondo ruleset).
• Suggerimento: ottimo per creare una policy “Drop solo High”, e “Alert per Medium/Low”.

cve

• Cos’è: identificativo CVE (vulnerabilità nota) associato alla firma.
• A cosa serve: policy mirate a specifiche vulnerabilità (es. quando devi proteggere un servizio non ancora patchato).
• Esempio: se ti interessa solo CVE-XXXX-YYYY, selezioni quel CVE e applichi un’azione forte.

deployment

• Cos’è: contesto di utilizzo previsto della regola (es. perimeter, internal, ecc. — dipende dal ruleset).
• A cosa serve: usare firme pensate per un certo posizionamento (bordo rete vs rete interna).
• Suggerimento: se Suricata è sul firewall perimetrale, ha senso dare priorità a regole “perimeter”.

deprecated_reason

• Cos’è: motivo per cui una regola è deprecata (vecchia/sostituita/non più valida).
• A cosa serve: normalmente per evitare regole obsolete o gestirle separatamente.
• Suggerimento: da neofita, in genere conviene non “potenziare” regole deprecate.

first_seen

• Cos’è: indicazione temporale di quando una minaccia/firma è stata osservata per la prima volta (secondo il ruleset).
• A cosa serve: filtrare minacce recenti vs vecchie.
• Esempio: policy “attenzione massima” su minacce viste di recente, specialmente se correlate a campagne attive.

former_category

• Cos’è: categoria precedente della regola (se è stata riclassificata nel tempo).
• A cosa serve: utile soprattutto per chi mantiene policy nel tempo e vuole continuità con vecchie categorizzazioni.
• Per neofiti: di solito puoi ignorarlo.

former_sid

• Cos’è: SID (Signature ID) precedente, se la regola è stata rinumerata o sostituita.
• A cosa serve: mantiene tracciabilità storica.
• Per neofiti: in genere non serve, a meno che tu non stia migrando da vecchie configurazioni.

malware_family

• Cos’è: famiglia di malware associata (es. nomi di famiglie note; dipende dal set regole).
• A cosa serve: policy mirate contro famiglie specifiche (molto utile se stai gestendo un incidente).
• Esempio: se in rete sospetti una famiglia specifica, puoi alzare l’azione solo su quella.

mitre_tactic_id

• Cos’è: ID della “tattica” MITRE ATT&CK associata alla regola (alto livello: obiettivo dell’attaccante).
• A cosa serve: ragionare per fasi/obiettivi dell’attacco (es. Initial Access, Execution, Lateral Movement…).
• Suggerimento: utile per report e tuning “strategico”, meno per i primissimi passi.

mitre_tactic_name

• Cos’è: nome della tattica MITRE (come sopra, ma in formato leggibile).
• A cosa serve: stessa utilità di mitre_tactic_id, ma più facile da selezionare a colpo d’occhio.

mitre_technique_id

• Cos’è: ID della “tecnica” MITRE ATT&CK (più specifico della tattica).
• A cosa serve: creare policy molto precise (es. bloccare o evidenziare una particolare tecnica).
• Esempio: se vuoi evidenziare tentativi di credential dumping o C2, puoi filtrare per tecnica.

mitre_technique_name

• Cos’è: nome della tecnica MITRE (leggibile).
• A cosa serve: come sopra, ma più user-friendly.

performance_impact

• Cos’è: indicazione del “peso” della regola sulle prestazioni (alcune firme sono più costose da valutare).
• A cosa serve: se il firewall ha risorse limitate, puoi evitare regole ad alto impatto o gestirle con cautela.
• Consiglio: su hardware debole, inizia con regole a basso impatto e aggiungi il resto gradualmente.

reviewed_at

• Cos’è: data di revisione della firma (quando è stata rivista/validata nel ruleset).
• A cosa serve: in alcuni casi aiuta a fidarsi di più di regole recenti e mantenute.
• Per neofiti: utile come criterio secondario, non il primo.

signature_severity

• Cos’è: severità assegnata alla firma (quanto è “grave” secondo il ruleset).
• A cosa serve: ottimo per policy a livelli:
  • Severità alta → azione più dura (es. Drop in IPS)
  • Severità media/bassa → Alert (monitoraggio)
• Suggerimento: inizia con Alert su tutto, poi valuta Drop solo su severità alta e confidenza alta.

tag

• Cos’è: etichette generiche associate alla regola (dipende dal ruleset: possono essere “informative”, “policy”, “malware”, ecc.).
• A cosa serve: filtro flessibile quando non c’è un metadato più specifico.
• Esempio: tag dedicati a un certo tipo di traffico o minaccia.

tls_state

• Cos’è: stato/contesto TLS relativo alla regola (tipicamente legato a traffico cifrato o fasi della sessione).
• A cosa serve: distinguere firme che lavorano su aspetti TLS (es. handshake, SNI, certificati) e gestirle separatamente.
• Nota: molte analisi profonde su traffico cifrato sono limitate se non hai visibilità (non si “vede” il contenuto cifrato).

5) Sezione: New action
New action (menu a tendina) — nella schermata è impostato su Alert

• Cosa fa: definisce l’azione da applicare alle regole che “rientrano” in questa policy (cioè che matchano i filtri sopra).
• Alert: genera un evento/log (ti avvisa) ma normalmente non blocca il traffico.
• Drop (se disponibile e se sei in IPS): blocca il traffico che matcha la firma.
• Altre azioni possibili (a seconda della versione/configurazione): pass/reject/disable/noalert, ecc.

Logging
Se non avete un servizio di raccolta log esterno vi conviene lasciare tutto disabilitato.
Nel mio caso ho poi selezionato log settimanale con 4 settimane, in pratica posso vedere quello che è successo nell'ultimo mese circa. Quando un evento "matcha" con una policy troverete nella sezione "Services: Intrusion Detection: Administration: Alerts" l'evento con tutte le info aggiuntive per capire quale regola si è attivata ed i dettagli dell'evento






Chiedo agli utenti che volessero diffondere queste informazioni in altri lidi di non copiare pari pari le immagini ed il testo ma piuttosto di inserire il link di questa pagina.
Grazie.