OpenBSD 7.7 come base robusta per firewall: una pf.conf e una sysctl.conf che ti coprono le spalle

OpenBSD 7.7 come base robusta per firewall: una pf.conf e una sysctl.conf che ti coprono le spalle

OpenBSD è noto da anni per il suo ethos di sicurezza senza compromessi: impostazioni predefinite sensate, codice pulito e “secure by default” come mandato, non come slogan. Se cerchi un firewall affidabile e spiegabile nell’uso quotidiano, OpenBSD offre una base solida. Allo stesso tempo, i buoni default sono ottimi, ma pochi accorgimenti mirati aumentano in modo netto il livello di sicurezza e la prevedibilità—senza trasformare il tuo ambiente in un esperimento fragile.
Con questo articolo vogliamo fornirti una baseline pratica che metta al sicuro con sicurezza reti piccole, home‑lab e molti ambienti PMI, rimanendo al contempo leggibile e semplice da mantenere.

Invece di checklist infinite e consigli di tuning arbitrari, troverai decisioni motivate con una spiegazione chiara. Ti mostreremo perché viene impostata una certa opzione, quali rischi affronta e quali effetti collaterali tenere a mente. L’obiettivo non è coprire ogni scenario teorico di attacco, ma darti un punto di partenza affidabile: regole snelle, poche eccezioni, comportamento prevedibile.

Questa guida segue una linea chiara: consenti esplicitamente; altrimenti blocca. Dall’esterno verso l’interno si permette solo ciò di cui il router ha veramente bisogno; dall’interno verso l’esterno passa solo ciò che tu vuoi davvero. Il DNS rimane visibile e controllabile. DoH, DoT, DoQ e QUIC non ottengono scorciatoie silenziose, così non compaiono “canali invisibili”. Gli stati sono vincolati intenzionalmente alle interfacce affinché le connessioni restino dove sono nate. Questo rende il sistema prevedibile e il troubleshooting sopportabile. E poiché la trasparenza vale più di dieci trucchi furbi, tutti i percorsi critici sono etichettati: nell’operatività quotidiana vedi subito cosa è consentito, cosa viene negato e dove stringere le maglie.

Per restare concreti, proponiamo due profili pf tra cui scegliere: una variante solo router per scenari LAN‑verso‑internet classici e una variante router+DMZ se vuoi isolare i servizi. Forziamo il DNS dei client esclusivamente verso 1.1.1.1 (con 1.0.0.1 opzionale come fallback). Non è pignoleria: è una scelta architetturale consapevole con cui riacquisti visibilità e controllo. Se un’applicazione vuole altro, salta all’occhio e decidi consapevolmente se e dove concedere un’eccezione.

Il file sysctl.conf completa questa postura a livello di kernel. OpenBSD porta già molto di suo, ma alcuni interruttori offrono un guadagno misurabile di robustezza: una configurazione di malloc indurita che fa fallire i bug di memoria prima e più rumorosamente; la disattivazione di SMT/Hyper‑Threading quando i rischi di side‑channel non danno alcun beneficio; W^X, che preferisce terminare i processi piuttosto che lasciarli correre in zone grigie pericolose; lo spegnimento di redirect e protocolli di tunneling non essenziali; opzioni TCP moderne e limiti di frequenza moderati che smorzano il “rumore” di rete senza rompere funzioni legittime. Non sono “tweak” appariscenti, ma igiene coerente: meno superficie d’attacco, meno sorprese, comportamento più stabile sotto carico.

Fuori ambito sono attacchi altamente mirati o implementazioni IDS/IPS complete. Se desideri monitoraggio multi‑livello, ispezione profonda dei protocolli o feed di threat‑intel, questa configurazione non ti ostacola; è il fondamento su cui aggiungere in modo metodico quei blocchi in seguito. Inoltre omettiamo deliberatamente politiche multi‑WAN complesse, scenari elaborati di port‑forwarding o overlay di rete esotici. Tutto ciò è fattibile, ma non senza annacquare la chiarezza della baseline.

L’impegno per la leggibilità significa anche preferire meccanica alla magia. Il NAT è statico dove i protocolli real‑time ne traggono vantaggio e dinamico dove non importa. QUIC resta fuori così il DNS non si nasconde dentro flussi TLS. IPv6 è bloccato inizialmente per evitare l’“IPv6 a metà”, dove i client preferiscono v6 mentre il firewall non lo controlla; più avanti troverai una ricetta pulita per abilitare IPv6 nel modo giusto, se ti serve. E, dove aiuta, marchiamo i casi limite con etichette—non per colorare i log, ma per ottenere risposte: chi ha provato a parlare DoT? Quali host sbattono contro la regola anti‑rebind? Cosa innesca i blocchi di uscita?

A chi è rivolto? A te che vedi l’amministrazione come un mestiere e preferisci investire un’ora in una base pulita piuttosto che tre settimane a inseguire effetti collaterali strani. A te che vuoi capire la tua rete invece di farti sorprendere dai permessi di default. E a te che ti senti “nel mezzo”: non abbastanza grande per un SOC/blue team, ma troppo esigente per un router da scaffale. Questa baseline non è un trucco: è uno standard sensato—abbastanza piccolo da padroneggiarlo, abbastanza robusto da tenerlo a lungo.

Modello di minaccia: contro cosa ci difendiamo—e contro cosa no

Questa baseline è pensata per ambienti senza un blue team dedicato che vogliono comunque standard affidabili. Protegge dal rumore tipico che colpisce il tuo perimetro ogni giorno: scanning massivi, exploit opportunistici, abuso di protocollo (il “DNS sopra qualsiasi cosa”), configurazioni errate o policy di egress permissive che rendono possibile l’esfiltrazione di dati. Incapsula server opzionali in una DMZ, impedendo il movimento laterale verso la LAN. Non sono nel focus attacchi altamente mirati o stack IDS/IPS completi—potrai aggiungerli più avanti su questo fondamento.

Principi di design: poca superficie d’attacco, responsabilità chiare

La configurazione segue linee guida che aiutano anche nei futuri aggiustamenti:

Fail‑closed. Se qualcosa non è esplicitamente consentito, resta chiuso—sia in ingresso che in uscita. Così, nei test scopri presto di cosa un’app ha davvero bisogno e mantieni il controllo.

Stati deterministici. if-bound garantisce che una connessione resti legata all’interfaccia dove è nata. Su router single‑WAN questo pone fine alla caccia agli “stati flottanti” magici e semplifica il troubleshooting.

Minimalismo in uscita (egress). Dall’interno verso l’esterno passa solo il necessario: web classico, submission e‑mail, range UDP definiti per VoIP/WebRTC—e DNS solo verso dove decidi tu.

Trasparenza invece di congetture. Blocchiamo QUIC e anche DoH/DoT/DoQ. Sì, può essere scomodo per alcune app. In cambio ottieni chiarezza: DNS è DNS, TLS è TLS. Se qualcuno ha bisogno di “DNS ombra”, si noterà.

Default robusti. Scrubbing, limite MSS, ID randomizzati, filtri bogon, anti‑spoofing, igiene dei flag TCP e limiti ragionevoli per ICMP e RST. Nulla di spettacolare; insieme, igiene solida.

IPv6 su scelta. IPv6 è spento di default. Se lo vuoi, nel testo c’è un percorso pulito per abilitarlo. Evitiamo in modo coerente l’“IPv6 a metà”.

sysctl.conf — Leve di sicurezza a livello kernel che contano davvero

OpenBSD offre già ottimi default, ma pochi settaggi alzano in modo evidente sicurezza e prevedibilità. Ecco l’essenziale—senza liste infinite, con ragioni chiare.

Hardening della memoria (vm.malloc_conf=CFGJRS). Guard page, pattern “junk”, red zone e canary rendono molto più difficile sfruttare bug classici e fanno fallire i processi “a voce alta” invece di corrompere in silenzio. Il piccolo overhead vale in quasi tutti gli scenari da router.

CPU/Hardware: SMT disattivato, aperture chiuse. hw.smt=0 riduce i rischi di side‑channel (Hyper‑Threading); sui router l’impatto è di solito minimo. machdep.allowaperture=0 chiude accessi in stile /dev/mem—ideale per macchine headless. Se ti serve X11/KMS lo saprai; altrimenti lascialo chiuso.

Routing e protocolli: IPv4 attivo, IPv6 intenzionalmente inattivo. net.inet.ip.forwarding=1 trasforma la macchina in router IPv4. net.inet6.ip6.forwarding=0 evita routing “accidentale” IPv6. Disattiviamo inoltre tunnel non necessari (IP‑in‑IP, GRE, ESP/AH, EtherIP). Meno macchinari di cifra/incapsulamento = meno superficie d’attacco e meno sorprese.

Disinnesco delle trappole legacy. Directed broadcast spenti, redirect ignorati (IPv4 e IPv6). I redirect ICMP sono un classico “colpo sul piede”; se vuoi alterare i percorsi, fallo esplicitamente nel routing o in PF, non per scorciatoie.

ICMP con misura. Niente echo a broadcast, niente timestamp/netmask; i pacchetti di errore hanno un rate‑limit ragionevole. Questo smorza rumore da DDoS senza rompere funzioni legittime. ICMP non è il nemico, ma ha bisogno di guardrail.

Hardening UDP/TCP senza magia. Checksum UDP obbligatori; buffer socket sensati evitano drop spiacevoli. In TCP manteniamo attive le funzioni moderne (window scaling, timestamp, SACK) per aumentare la stabilità. ECN è attivo; raramente crea problemi e aiuta sotto carico. I limiti del SYN cache/bucket e il rate‑limit di RST assorbono le ondate tipiche di scanning.

Queue, BPF e W^X. Una if‑queue più lunga riduce i drop nelle raffiche. Buffer BPF più ampi sono un regalo al tuo “te stesso del futuro” in debug. kern.wxabort=1 fa rispettare W^X: il codice è o scrivibile o eseguibile, mai entrambi. Le violazioni terminano il processo—fail‑closed, come vogliamo. La cifratura dello swap rimane attiva, così i residui sensibili non finiscono su disco in chiaro.

Questa selezione di sysctl è volutamente sobria. Sposta la curva da “di solito funziona” a “si comporta in modo coerente sotto stress”. Caricala con sysctl -f, verifica qualche contatore (sysctl -n net.inet6.icmp6.errppslimit, netstat -m, pfctl -s memory) e ricorda: se ritocchi i budget mbuf/cluster, potresti dover adeguare limiti PF come set limit frags.

pf.conf: regole che puoi spiegare

pf ti dà possibilità infinite. La nostra baseline prende esattamente quanto serve per standard robusti—né più né meno.

Macro, tabelle ed etichette: metà della battaglia è la struttura. Parti da interfacce e reti definite chiaramente: WAN, LAN e—nella variante DMZ—DMZ. Aggiungi tabelle per bogon, abuser, scanner e una watchlist per endpoint DoH sospetti. Non è decorazione: con persist sopravvivono ai reload e, tramite overload, le sorgenti rumorose vengono aggiunte automaticamente. Etichette coerenti sulle regole ti danno visibilità operativa senza pcap pesante: pfctl -vvsr o systat pf mostrano dove c’è attività.

Opzioni globali: comportamento prevedibile. set block-policy drop e ottimizzazione “aggressive” sono default conservativi sensati. set state-policy if-bound ancora le connessioni all’interfaccia d’ingresso. Definiamo limiti per stati, frammenti e src‑node, timeout adattivi e abilitiamo syncookies in modo adattivo—utili quando la marea si alza. loginterface ti fornisce statistiche WAN; set skip on lo0 evita l’“autogol”.
In pf, IPv6 è bloccato di default, in linea con sysctl, e previene l’“IPv6 a metà”. Se lo vuoi, abilitalo in modo deliberato e visibile.

ICMP in ingresso: abbastanza aperto per restare in salute. Sull’interfaccia WAN permettiamo echo e “unreachable”, con state e rate‑limit. Migliora la diagnosi (altrimenti come scopri problemi MTU/percorso?) e ti protegge dai flood di ping. Il resto—specialmente i redirect—resta spento.

Scrubbing: meno frammentazione, meno frustrazione. Scrubbiamo in entrambe le direzioni: ID IP randomizzati, TTL minimo conservativo, MSS limitato a 1440 (valore sano nella pratica) e riassemblaggio TCP. Evita che pacchetti frammentati dubbi intasino gli stati e riduce i mal di testa PMTU. Con questo, raramente devi toccare MSS via sysctl.

NAT: statico dove il real‑time conta; dinamico dove no. UDP ottiene porte statiche—oro per VoIP/WebRTC, gaming e molti protocolli real‑time. Tutto il resto usa un range ephemeral alto per rendere più semplice l’attribuzione in uscita nelle catture ed evitare collisioni. Il NAT si applica a tutto, tranne che a destinazioni di gestione definite esplicitamente—niente percorsi a sorpresa.

Anti‑spoofing, bogon, porte nulle. antispoof vigila tutte le interfacce rilevanti. Ciò che arriva alla WAN con sorgente rotta viene lasciato cadere presto. Blocchiamo i bogon sia in ingresso che in uscita; traffico, ad esempio, da 10/8 o 127/8 verso internet di solito indica altri problemi. Ripuliamo anche le porte 0 e i flag TCP implausibili—non è scienza missilistica, ma risparmia dolori con scanner e tool “creativi”.

Default deny: la grande scopa. Dopo l’igiene arriva il taglio netto: block all. D’ora in poi, tutto è un’eccezione consapevole.

Ingresso su WAN: solo ciò che serve al router. Permettiamo DHCP in ingresso se lo richiede l’upstream. Stop. Una DMZ pubblica raggiungibile da internet non è lo scopo di questa baseline; per quello definiresti port‑forward—con parsimonia.

QUIC: HTTP/3 resta fuori. Blocchiamo UDP 80/443 su WAN. Questo soffoca QUIC. Perché così severi? Perché QUIC è un tunnel comodo—anche per varianti di DoH e altri trucchi “tutto in un flusso”. Se in seguito davvero ti serve HTTP/3 verso target specifici (e sai perché), aggiungi eccezioni chirurgiche. La baseline privilegia trasparenza alla velocità.

Visibilità per DoH/DoT/DoQ—con confini chiari. DoT (853/TCP) e DoQ (784/UDP) sono bloccati in uscita e loggati in ingresso. In LAN/DMZ etichettiamo le connessioni TLS verso host DoH noti—senza cambiare la policy, a meno che tu non scelga la variante “strict”. L’idea è: vedere quando i client tentano DNS occulto.

Accesso admin al firewall: stretto e con rate control. SSH dalla LAN al firewall è consentito con state, igiene dei flag e lieve limitazione della frequenza. I percorsi di gestione upstream (ad es. la GUI di un modem/router) hanno pass mirati; limiti di connessione per sorgente smorzano spray e clic sbagliati. Le etichette tengono questi percorsi ben visibili.

Politica DNS senza resolver locale: imporre, non sperare. Punto centrale: i client in LAN (e in DMZ, se presente) possono usare solo 1.1.1.1 e, opzionalmente, 1.0.0.1 sulla porta 53/TCP+UDP. Tutto il resto verso la 53 viene bloccato e loggato. Non è un “nice to have”—è cruciale per la visibilità. Vedrai subito tentativi di altri resolver—o DoH/DoT/DoQ, che blocchi separatamente. Puoi sostituire in qualsiasi momento con un altro resolver esterno; la meccanica è la stessa.

DMZ: niente porte laterali, niente scorciatoie. Nella variante DMZ non c’è comunicazione intra‑DMZ, non c’è ritorno verso la LAN e ci sono solo passaggi mirati in uscita per i servizi che vivono lì (web classico, submission e‑mail, range UDP VoIP/WebRTC). L’accesso dalla DMZ a GUI upstream è vietato; così eviti che un server compromesso tocchi la tua rete di gestione. Tutto il resto è bloccato—e loggato—così trovi in fretta la vite mancante.

Mitigare i rischi in uscita: chiudere i classici. In uscita blocchiamo i soliti sospetti: SMB/NetBIOS, RPC/NFS, TFTP, SNMP, RDP/VNC/WinRM e SMTP opportunistico. Ognuno ha il suo posto dentro la rete o su percorsi deliberati; su internet, di default, no. Se ti serve un’eccezione, definiscila consapevolmente—e con un’etichetta.

Il firewall stesso: può uscire, ma in modo visibile. Il firewall può accedere a internet—con stati, limiti ed etichette. Ti serve per aggiornamenti, pacchetti e diagnostica. Non esagerare: questa macchina è router e guardiano, non un terminale di navigazione.

Anti‑rebind, LAN→DMZ e il grande riordino. Tra LAN e DMZ sono permessi solo percorsi espliciti (ad es. client verso un servizio in DMZ); il ritorno rimane chiuso. Le regole anti‑rebind evitano che i client raggiungano target interni protetti tramite trucchetti DNS attraverso il firewall. Altrove PF dice “no” in modo chiaro—con return dove un errore immediato aiuta il debug.

Solo router vs. router+DMZ: quale profilo fa per te?

Se vuoi solo collegare una LAN a internet, solo router è ideale: compatto, chiaro e comunque indurito. Ottieni anti‑spoofing, filtri bogon, una postura severa in uscita, DNS forzato a 1.1.1.1/1.0.0.1, controlli su DoH/DoT/DoQ/QUIC, SSH admin da LAN al firewall e default ordinati per scrubbing, stati e limiti.

Non appena ospiti servizi—anche solo interni—router+DMZ ha senso. Una DMZ contiene i guasti e riduce la probabilità che un servizio compromesso diventi trampolino verso la tua LAN. La comunicazione intra‑DMZ rimane chiusa; l’uscita è a lista bianca ed è più stretta che in LAN. Il DNS è ugualmente severo; NTP resta chiuso finché davvero non ti serve.

Abilitare IPv6 nel modo giusto

La baseline blocca IPv6 per non lasciare nulla “a metà”. Se ti serve, abilitalo in modo deliberato e coerente: routing via sysctl, regole inet6 corrispondenti in pf, un piano pulito per l’uscita (sì, anche qui enforcement DNS—ma per v6) e decisioni chiare su RA/DHCPv6. Rifletti le buone idee di v4: anti‑spoofing, deny di default, gestione di QUIC/DoH/DoQ ed eccezioni visibili—né più né meno. Consiglio chiave: non “infilare” v6 in silenzio. Se c’è, che sia fatto bene; altrimenti, meglio aspettare.

Operatività, diagnostica e forense: misurare, non indovinare

Una policy rigida vale solo se riesci a leggerla ogni giorno. pf aiuta in tre modi:

Etichette. Ogni regola rilevante ha un’etichetta descrittiva. In pfctl -vvsr vedi quali percorsi sono usati, quali bloccati e dove c’è attività. Spesso basta per circoscrivere i problemi.

Tabelle. Con pfctl -t <table> -T show leggi le voci di abuser/scanner. overload popola queste tabelle automaticamente quando i client aprono troppe connessioni. Non è punizione; è una cintura di sicurezza.

pcap minimo. tcpdump è un ottimo alleato—usalo con criterio. Per controllo DNS/DoH bastano spesso rapide occhiatine come:
tcpdump -n -e -ttt -i $wan 'port 53 or port 853 or (udp and port 784)'
È forense con un piano, non “Wireshark finché bruciano gli occhi”.

Un canone di test sano. Quando modifichi le regole, compilale prima senza caricarle: pfctl -nf /etc/pf.conf. Poi pfctl -f e, se qualcosa si rompe, etichette e tabelle guidano la correzione. Per l’enforcement DNS: drill @1.1.1.1 openbsd.org deve riuscire; drill @9.9.9.9 openbsd.org deve essere bloccato. Per QUIC, verifica che curl -I --http3 https://example.com non vada su UDP e che scenda a HTTP/2. Valida DoT/DoQ tentando 1.1.1.1:853 e UDP 784—devono fallire, e vedrai i contatori di blocco sulle regole etichettate.

Un consiglio per i cambi in uscita. Quando apri qualcosa, marcalo temporaneamente con un’etichetta molto esplicita e, dopo una settimana, verifica se è davvero usato. Se non lo è, rimuovilo. Così la tua baseline resta snella.

Considerazioni sulle prestazioni senza folclore

Questo assetto non è tirato “al limite”—è tarato per la stabilità. Alcune conseguenze contano:

Bloccare QUIC può rendere leggermente più lenti alcuni siti. È uno scambio deliberato: visibilità sopra velocità. Se hai motivi validi per consentire HTTP/3, fallo chirurgicamente (target in una tabella, etichetta e via).

ECN attivo va bene nella maggior parte delle reti moderne. Se qualche middlebox esotica lo detesta, te ne accorgi subito e puoi disattivarlo in quel caso—la baseline non ti ostacola.

Porte NAT statiche per UDP sono un regalo per i protocolli real‑time. Chi ha inseguito problemi WebRTC lo sa: valgono oro. Non costano nulla, se non capire che la “casualità” della porta in UDP non è una funzione di sicurezza.

If‑queue e buffer BPF sono dimensionati con pragmatismo: margine per i picchi e sessioni di debug che non muoiono su buffer da 4 KB. Se davvero spingi al massimo, misura e aggiusta—non il contrario.

Trappole comuni—e come gestirle con eleganza

“La mia app funziona solo con DoH!” Allora serve un’eccezione o, meglio, una valutazione onesta. DoH non è intrinsecamente cattivo, ma ostacola il controllo di rete (casa/azienda). Puoi consentire host specifici in una tabella; mantienilo come eccezione consapevole, non apertura globale.

“Le videochiamate scattano.” Verifica prima di tutto se i range UDP del tuo provider (Zoom/Teams/WebRTC) sono coperti. Le porte UDP statiche aiutano, ma senza il giusto corridoio di uscita non migliora nulla. Aggiusta su misura, non a caso.

“Il client e‑mail non invia direttamente.” Giusto: la porta 25 in uscita è bloccata. La posta deve andare via submission (465/587) al provider/server—non direttamente su internet. Se serve, consenti quelle porte—con etichetta.

“IPv6 si è rotto all’improvviso.” In questa baseline, v6 è bloccato. Se i client preferiscono v6 mentre il firewall non lo instrada, vedrai timeout. O abiliti v6 correttamente (con regole) oppure indichi ai client (RA/ND) che v6 non è ancora disponibile.

“Effetti strani dopo una modifica alle regole.” Pensa agli stati. Quelli vecchi sopravvivono di default. Quando modifichi la policy di fondo (p. es. apri una nuova porta in uscita), uccidi gli stati interessati (pfctl -k ...) o, se necessario, svuotali tutti (pfctl -F state). Dopo, il mondo torna coerente.

Perché questa baseline è “sicura”—e cosa significa sicurezza qui

La sicurezza non è mai assoluta. Ma è misurabile quando definisci obiettivi chiari e verifichi il percorso con onestà. Questa baseline riduce la superficie d’attacco perché:

minimizza ogni esposizione in ingresso,

rende l’uscita eccezione e non regola,

impone e mantiene visibile il DNS,

blocca percorsi offuscati (QUIC/DoH/DoT/DoQ),

disattiva pseudo‑funzioni (redirect, broadcast),

applica default robusti per TCP/ICMP,

rende la gestione degli stati deterministica,

e ti dà strumenti per osservare l’uso quotidiano.

Al contempo, la configurazione resta mantenibile. Non è “sicura” perché ha 3.000 righe, ma perché puoi spiegare ogni riga.

Migrazione: come procedere

Se arrivi da una configurazione pf esistente, avanza a tappe:

1. Prima sysctl. Carica l’hardening che non interrompe i servizi. Controlla i log per rumori ICMP/RST inusuali.
2. Prova la policy pf in parallelo. Usa pfctl -nf e un lab o una finestra di manutenzione. Alla prima attivazione, cura l’SSH da LAN al firewall—non c’è nulla di peggio che chiudersi fuori.
3. Stringi l’uscita. Attiva l’enforcement DNS e osserva. Poi chiudi progressivamente i servizi classici a rischio. Una‑due settimane di monitoraggio aiutano a scovare punti ciechi.
4. Introduci una DMZ (se serve). Sposta i servizi, mantieni chiusi intra‑DMZ e DMZ→LAN. Apri solo le uscite strettamente necessarie. Osserva e affina.
5. Decidi IPv6 con intenzione. O lo abiliti come si deve—oppure lo tieni spento e informi i client.

Ogni fase alza la sicurezza senza un big bang rischioso.

Cosa puoi estendere facilmente in seguito

Questa baseline è un fondamento, non una gabbia. Estensioni tipiche:

• Eccezioni chirurgiche per QUIC/DoH quando hai motivi validati—sempre con tabelle ed etichette.
• VPN site‑to‑site con minima superficie d’attacco; i sysctl di default non ti limitano se consenti esplicitamente i protocolli.
• Monitoraggio/alerting. I contatori pf e systat pf sono ottimi per metriche di base. Per di più, invia i log pf a un sistema centralizzato.
• IPv6, specchiando completamente la logica v4—non come innesto.

Aggiornamenti e manutenzione

OpenBSD mantiene le promesse—ma leggi le release note ad ogni upgrade, specie su sintassi pf e default del kernel. Etichette, tabelle e macro chiare rendono veloce la verifica tra versioni. Mantieni la disciplina di commentare ogni eccezione: perché esiste, chi la richiede, quando l’hai rivista l’ultima volta. Le eccezioni non sono un peccato; le eccezioni non documentate sono debito tecnico.

Conclusione: la chiarezza è il miglior hardening

Questa baseline persegue un obiettivo semplice: chiarezza sopra complessità. Ottieni un firewall OpenBSD prevedibile nel quotidiano, con superficie d’attacco ridotta, che mostra—attraverso etichette, tabelle e default sensati—cosa accade davvero. Diamo priorità a scelte esplicite invece che a effetti collaterali impliciti: policy di uscita severa, DNS forzato verso resolver definiti, niente canali silenziosi via QUIC o DoH/DoT/DoQ, stati deterministici e leve robuste di kernel. Il risultato non è un esercizio accademico, ma un punto di partenza durevole su cui costruire con fiducia.

È importante notare che questa baseline intenzionalmente presume assenza di resolver locale e assenza di servizio NTP locale. È rivolta a contesti che devono stabilizzarsi rapidamente senza infrastrutture aggiuntive. Se più avanti desideri più controllo on‑prem, puoi aggiungerlo senza attriti—l’architettura è pronta, senza abbandonare la postura centrale.

Per evitarti ricerche: qui sotto trovi le proposte di configurazione complete—entrambi i profili pf.conf (solo router senza DMZ e router+DMZ con isolamento rigoroso) e la sysctl.conf indurita. Questo articolo spiega le decisioni; i file sottostanti le implementano alla lettera. Se segui la sequenza “validare → caricare → misurare”, arriverai rapidamente a un risultato riproducibile.

È altrettanto importante essere onesti sull’ambito: qui non sono in focus attacchi altamente mirati o scenari IDS/IPS completi. Non significa rinunciarvi—tutt’altro. Questo fondamento è predisposto affinché tu possa aggiungerli con metodo. Tre percorsi di estensione si sono dimostrati utili nella pratica.

Se hai idee per affinare regole specifiche, requisiti particolari o vuoi condividere osservazioni dalla tua operatività: contattaci. Il feedback reale è il miglior catalizzatore di miglioramenti sensati—e alimenterà evoluzioni future. La sicurezza è un processo, non uno sprint; con una baseline chiara e una comunità che condivide esperienza, il “buono” diventa “eccellente” molto in fretta.

Scarica sysctl.conf: https://www.protectstar.com/download/blog/sysctl.txt
Scarica pf.conf (con DMZ): https://www.protectstar.com/download/blog/pf.conf_withDMZ.txt
Scarica pf.conf (senza DMZ): https://www.protectstar.com/download/blog/pf.conf_noDMZ.txt