Supponiamo che domani il vostro server web venga compromesso. Quali altri dispositivi potrebbe raggiungere? La risposta contribuisce a determinare se l’incidente rimarrà circoscritto a un servizio o metterà a rischio altre parti dell’azienda. Una patch protegge da una vulnerabilità nota. Una rete ben progettata limita anche le possibili conseguenze.
Il nostro esempio è un portale clienti fittizio: gli utenti accedono, consultano ordini e scaricano documenti. L’applicazione ha bisogno di un collegamento ben definito al database. Questo non implica che debba accedere anche all’amministrazione del NAS, al server di backup o all’host di virtualizzazione. Tale distinzione deve essere applicata tecnicamente.
Un servizio compromesso utilizza i percorsi disponibili
Una vulnerabilità può consentire l’esecuzione di codice estraneo con i permessi dell’applicazione web. Le possibilità successive dipendono, tra l’altro, da regole di rete, account di servizio, credenziali memorizzate e ulteriori vulnerabilità. La raggiungibilità non equivale a un accesso riuscito. Un server web compromesso non prende automaticamente il controllo dell’intera LAN.
Il rischio aumenta quando servizi interni raggiungibili si combinano con permessi eccessivi. Chi attacca deve allora superare meno confini. Questa possibile propagazione verso altri sistemi viene chiamata movimento laterale. In fase di progettazione è quindi utile assumere che un’applicazione sia già stata compromessa.
Rete A: il portale si trova in una rete aziendale piatta
Nel primo scenario, portale, database, archiviazione dei file e interfacce amministrative condividono la stessa rete. Il firewall perimetrale limita le connessioni in ingresso. All’interno, però, autorizzazioni ampie o una separazione insufficiente rendono raggiungibili dal server web più sistemi di quanti ne richieda il suo compito.
Un account amministratore condiviso aggrava la situazione. Lo stesso vale per una directory di backup montata con permessi di scrittura o per credenziali estese conservate nella directory dell’applicazione. Un backup funzionante serve a poco se il servizio compromesso può modificarne anche l’amministrazione o tutte le copie.
Rete B: zone e regole limitano le connessioni
Nel secondo scenario, Internet raggiunge innanzitutto un frontend o un reverse proxy definito. Questo può contattare l’applicazione necessaria in un segmento web separato. L’applicazione riceve solo la connessione indispensabile verso un database specifico. Amministrazione, backup e altri servizi interni si trovano in zone distinte; gli accessi non necessari dal segmento web vengono bloccati.
Una VLAN divide logicamente la rete. Il controllo delle connessioni determina se tale divisione diventa un confine di sicurezza efficace. Un routing inter-VLAN troppo permissivo ricollega ampiamente le reti separate. Anche all’interno di una VLAN può essere necessario filtrare la comunicazione fra singoli carichi di lavoro.
OPNsense o Sophos Firewall sono possibili piattaforme per applicare regole adeguate, insieme ad altri prodotti idonei. Contano sorgenti, destinazioni, servizi, responsabilità e un’implementazione verificata. Interfacce e funzioni disponibili variano fra le piattaforme. Il nome di un prodotto, da solo, non descrive un’architettura di sicurezza collaudata.
Reverse proxy e WAF rimangono parte della protezione
Un reverse proxy può concentrare gli accessi pubblici, gestire connessioni TLS e indirizzare le richieste verso backend selezionati. HAProxy supporta, fra le altre, modalità HTTP e TCP. Ciò non implica una funzione proxy generale per qualsiasi protocollo. Un Web Application Firewall posto a monte può riconoscere e respingere determinate richieste web dannose.
Questi componenti non sostituiscono applicazioni sicure, aggiornamenti tempestivi e accessi restrittivi ai backend. Regole errate o un altro punto d’ingresso raggiungibile possono aggirare le protezioni. Nell’esempio, anche un’applicazione compromessa dietro il proxy deve quindi poter raggiungere solo le destinazioni espressamente necessarie.
Considerare il traffico in uscita e quello interno
La domanda decisiva non è soltanto chi possa collegarsi al server web. Verso quali destinazioni può avviare connessioni il server stesso? Può raggiungere l’interfaccia amministrativa del NAS? Deve contattare destinazioni Internet arbitrarie? Quali servizi interni servono realmente agli altri container?
La pianificazione del traffico in uscita, o egress, comprende risoluzione dei nomi, sincronizzazione dell’ora, aggiornamenti e interfacce esterne. Le destinazioni necessarie vengono autorizzate in modo mirato. Anche la comunicazione fra sistemi interni, spesso chiamata traffico est-ovest, richiede regole comprensibili. IPv6 e percorsi alternativi devono rispettare la stessa separazione prevista.
Un piano delle connessioni registra sorgente, destinazione, servizio richiesto, finalità e responsabile. Si verificano poi in modo controllato sia i percorsi consentiti sia quelli bloccati. Log e monitoraggio devono rendere riconoscibili connessioni riuscite inattese e tentativi bloccati sospetti. Una regola senza una verifica degli effetti non costituisce ancora una prova affidabile.
VM e container richiedono confini appropriati
Una macchina virtuale dispone di un proprio sistema operativo guest; i container condividono tipicamente il kernel dell’host. Entrambi i modelli richiedono una configurazione adeguata della rete e dei permessi. Proxmox VE offre regole firewall per host e guest. I livelli e le funzioni effettivamente operativi dipendono anche dal backend firewall e dalle opzioni concretamente attivate.
In Docker, i container della stessa rete bridge possono comunicare tra loro. Le connessioni in uscita non sono automaticamente limitate alle destinazioni pubbliche. Le porte pubblicate possono creare ulteriori accessi. Nella modalità di rete host, i container condividono il namespace di rete dell’host: non esiste quindi un isolamento di rete separato.
Privilegi aggiuntivi, mount dell’host non necessari e accesso al socket Docker possono ampliare notevolmente le conseguenze di un incidente. Reti applicative separate, permessi minimi, regole firewall appropriate sull’host e percorsi DNS ed egress controllati devono perciò essere progettati insieme. Anche qui conta la configurazione realmente efficace.
Un punto di partenza gestibile per le piccole imprese
- Censire i servizi: documentare applicazioni pubbliche, dipendenze e persone responsabili.
- Definire le zone: separare carichi pubblici, dati, amministrazione e backup secondo le esigenze di protezione.
- Motivare le connessioni: autorizzare solo sorgenti, destinazioni e servizi definiti; bloccare il resto dove opportuno per l’operatività.
- Proteggere l’amministrazione: utilizzare percorsi affidabili, metodi VPN e MFA adeguati e account distinti.
- Includere l’esercizio: prevedere aggiornamenti, log centralizzati, allarmi e backup protetti in modo indipendente, con ripristino collaudato.
- Verificare l’efficacia: riesaminare regolarmente le regole, limitare nel tempo le eccezioni e ripetere i test dopo le modifiche.
Le modifiche richiedono preparazione, una finestra di manutenzione adeguata e una procedura di ritorno. Un blocco indiscriminato può interrompere applicazioni legittime o il proprio accesso amministrativo. Prima si censiscono le dipendenze, poi si procede in modo controllato e si convalidano le funzioni aziendali con i responsabili.
Se cade un’applicazione, la rete dietro di essa può restare protetta
Gli articoli PHP2Shell sulla risposta alle vulnerabilità PHP e sull’inventario con il supporto dell’AI costituiscono l’occasione attuale. La verifica aggiuntiva di NAS, Docker e servizi pubblici porta a una domanda architetturale duratura: quali connessioni e permessi servono davvero a ciascun servizio?
DAXS supporta inventario, piano delle comunicazioni, implementazione ed esercizio verificabile. Che l’applicazione sia locale, in un cloud privato o su una piattaforma cloud pubblica, i confini di protezione devono corrispondere al fabbisogno reale. Parliamo del vostro ambiente concreto.
Fonti: OPNsense: regole e filtraggio stateful · Sophos Firewall: zone, regole e registrazione · HAProxy: modalità HTTP e TCP · Docker: reti bridge · Docker: modalità di rete host · Docker: daemon, permessi e confini di sicurezza · Proxmox VE: documentazione del firewall · NCSC: limitare la propagazione e proteggere amministrazione e backup.
