Un firewall applicato a ogni server è uno dei modi più semplici per ridurre la superficie di attacco di un ambiente aziendale. Limita quali sistemi possono connettersi, da dove e per quale scopo. È importante anche quando un server si trova dietro un security group cloud, una rete virtuale o un firewall perimetrale fisico.
Il punto di partenza più affidabile è una policy deny by default: bloccare il traffico in ingresso non richiesto, consentire solo i servizi documentati e controllare il traffico in uscita quando il rischio lo giustifica. Le regole dovrebbero riflettere il ruolo del server, invece di essere copiate da un elenco generico di porte. Un server web pubblico, un database server, un mail relay e una sorgente di backup hanno requisiti diversi.
Questo approccio rende anche più chiara la responsabilità. Ogni server ha una policy di rete esplicita, quindi un servizio dimenticato non è automaticamente raggiungibile solo perché è in ascolto.
Inizia con una policy deny by default
Un firewall per server pratico prevede normalmente tre livelli decisionali:
- Traffico in ingresso: negato per impostazione predefinita, consentendo poi solo le porte necessarie ai servizi legittimi.
- Traffico in uscita: consentire le connessioni necessarie, ma limitare ove possibile le destinazioni sensibili o non necessarie.
- Traffico interno: consentire solo le comunicazioni necessarie tra ruoli server, reti o sistemi di gestione definiti.
Prima di modificare le regole, documenta la funzione del server, i servizi in ascolto, i relativi client previsti e se questi sono pubblici, privati o amministrativi. Tra le fonti utili rientrano la configurazione dei servizi, i security group cloud, le impostazioni del bilanciatore, i record DNS, la documentazione applicativa e i log delle connessioni.
Non considerare una porta sicura o pericolosa in modo isolato. Il numero di porta identifica un servizio convenzionale, non la qualità della sua configurazione. La porta 443 può comunque esporre un’applicazione vulnerabile, mentre SSH sulla porta 22 può essere ben protetto quando l’accesso è limitato e l’autenticazione è stata rafforzata. Cambiare la porta predefinita può ridurre le scansioni automatiche, ma non sostituisce il controllo degli accessi.
Porte dei servizi comuni e rischio di esposizione
I team cercano spesso le porte firewall comuni da aprire e bloccare sui server, ma un elenco deve sempre essere seguito da una decisione sull’accesso. La domanda importante non è solo se un servizio utilizza una porta, ma chi deve raggiungerlo e da quale rete.
Porte 80 e 443: servizi web pubblici
Le porte 80 e 443 sono normalmente appropriate per un sito web o un’applicazione web pubblica. La porta 443 trasporta HTTPS e dovrebbe essere il principale punto di accesso pubblico. La porta 80 può essere necessaria per i reindirizzamenti da HTTP a HTTPS, la convalida dei certificati, la compatibilità con sistemi legacy o un servizio HTTP volutamente pubblico.
Se il server si trova dietro un reverse proxy, una CDN o un bilanciatore del carico, l’origine non deve necessariamente accettare traffico web dall’intera internet. Limitare le connessioni in ingresso agli intervalli di indirizzi pubblicati dal proxy può ridurre gli attacchi diretti all’origine. Assicurati che l’applicazione riceva comunque informazioni affidabili sul client e che nel progetto siano inclusi health check, rinnovo dei certificati e processi di deployment.
Per un’applicazione interna, nessuna delle due porte deve essere pubblica. Consenti l’accesso dalla rete aziendale, dalla VPN, dal gateway applicativo o da subnet private specifiche.
Porta 22: sicurezza SSH
SSH è essenziale per l’amministrazione Linux, l’automazione e alcuni flussi di trasferimento dei file, ma esporlo globalmente favorisce tentativi di password guessing, attacchi alle credenziali e lo sfruttamento di vulnerabilità nello stack SSH o nella configurazione circostante.
Per una sicurezza SSH efficace, consenti la porta 22 solo da un intervallo di indirizzi VPN, da un IP di uscita aziendale, da un bastion host adeguatamente protetto o da una rete privata di gestione. Preferisci l’autenticazione basata su chiavi, disabilita quando possibile l’accesso diretto con password, limita gli accessi privilegiati e usa account nominativi separati con elevazione dei privilegi sottoposta ad audit. L’autenticazione a più fattori può aggiungere un ulteriore livello di protezione, soprattutto quando l’accesso amministrativo attraversa una rete non affidabile.
Spostare SSH su un’altra porta può ridurre il rumore nei log, ma non rende privato un servizio esposto su internet. Se l’amministrazione remota è occasionale, una VPN o una regola firewall just-in-time è generalmente un controllo migliore rispetto alla sicurezza basata sull’oscurità.
Porta 3389: sicurezza RDP
RDP è un obiettivo di grande valore perché fornisce accesso interattivo ai sistemi Windows. La porta 3389 non dovrebbe essere aperta alla rete internet pubblica come modello operativo normale. Usa una VPN, una rete privata, un gateway di accesso remoto o un servizio bastion, e limita gli indirizzi di origine alle reti amministrative approvate.
Una buona sicurezza RDP dipende anche dall’autenticazione a livello di rete, da controlli solidi sulle identità, dall’applicazione delle patch, da criteri di blocco degli account o da policy di rilevamento equivalenti e dalla limitazione degli amministratori autorizzati ad accedere. Se un team di supporto esterno necessita di accesso, fornisci un percorso definito e un’autorizzazione a tempo invece di una regola permanente valida per qualsiasi origine.
Porta 25: SMTP
La porta 25 viene utilizzata per la consegna delle email tra server. Un server di posta che invia o riceve direttamente i messaggi può averne bisogno, anche se provider e reti upstream a volte limitano l’SMTP in uscita per ridurre gli abusi. Un server che non gestisce servizi di posta non dovrebbe esporre la porta 25.
Non dare per scontato che consentire la porta 25 in uscita su ogni server sia innocuo. Un application server compromesso può diventare una fonte di spam o danneggiare la reputazione email dell’organizzazione. Quando possibile, instrada le email applicative tramite un relay approvato e consenti l’SMTP in uscita solo verso quel relay. La porta 25 in ingresso dovrebbe essere limitata a un ruolo reale di gestione della posta, con controlli anti-abuso gestiti separatamente.
Porta 53: DNS
Il DNS utilizza sia la porta UDP 53 sia la porta TCP 53. Un resolver ricorsivo può dover rispondere alle richieste dei client di una rete interna, mentre un server DNS autorevole può dover rispondere alle query pubbliche. Si tratta di ruoli diversi che non dovrebbero essere combinati senza una valutazione.
Non esporre mai su internet un resolver ricorsivo aperto. Limita la ricorsione alle reti approvate, consenti i trasferimenti di zona solo tra name server designati e abilita la porta TCP 53 quando sono necessarie risposte di grandi dimensioni, DNSSEC o operazioni di trasferimento di zona. Un server che si limita a utilizzare il DNS dovrebbe normalmente inviare le query in uscita a resolver specifici, invece di accettare traffico DNS in ingresso.
Porte 3306 e 5432: MySQL e PostgreSQL
MySQL è in ascolto comunemente sulla porta 3306 e PostgreSQL sulla porta 5432. Queste porte non dovrebbero quasi mai essere pubbliche. I database contengono dati aziendali di grande valore e sono obiettivi frequenti di attacchi alle credenziali, individuazione di configurazioni errate e sfruttamento di software non aggiornato.
Consenti il traffico verso il database solo dai server applicativi, dai sistemi di reportistica, dal bastion amministrativo o dalla rete privata che ne ha realmente bisogno. Usa l’autenticazione nativa del database, la crittografia quando supportata, account con privilegi minimi e regole di rete che corrispondano alla topologia dell’applicazione. Collegare un database a un’interfaccia privata è utile, ma dovrebbe integrare il firewall e non sostituirlo.
Pannelli di controllo, interfacce di orchestrazione, console degli hypervisor ed endpoint di monitoraggio richiedono lo stesso trattamento. Dovrebbero essere disponibili solo tramite una rete di gestione, una VPN o una allowlist strettamente controllata. Un’interfaccia di gestione esposta pubblicamente può trasformare una singola password rubata o un componente non aggiornato nel controllo del server e, potenzialmente, dell’ambiente a esso connesso.
Separa il traffico pubblico, applicativo e di gestione
Le regole sulle porte sono più efficaci quando la rete è segmentata. Una tipica infrastruttura di una piccola azienda potrebbe separare:
- Servizi pubblici: servizi web o di posta che devono accettare connessioni da internet.
- Servizi applicativi: API, code e componenti applicativi interni raggiungibili solo dai sistemi approvati.
- Servizi dati: database e storage raggiungibili esclusivamente dalle reti applicative o amministrative.
- Servizi di gestione: SSH, RDP, pannelli di controllo, strumenti di monitoraggio e orchestrazione raggiungibili solo tramite percorsi amministrativi privati.
- Connettività di backup: connessioni in uscita dai server protetti verso una destinazione di backup approvata, senza accesso generale in ingresso al repository di backup.
Questo modello limita i movimenti laterali. Se un servizio web pubblico viene compromesso, l’aggressore non dovrebbe poter connettersi automaticamente al database, all’hypervisor o al sistema di backup. Le regole firewall dovrebbero indicare il ruolo di origine e destinazione, invece di consentire semplicemente un’intera rete virtuale per comodità.
Anche il traffico interno deve essere esaminato. Gli indirizzi IP privati non sono automaticamente affidabili. Un server interno compromesso può scansionare e attaccare un altro sistema con la stessa efficacia di un host internet. Applica il principio del privilegio minimo tra subnet e ruoli server ed evita regole estese come consentire ogni porta da qualsiasi indirizzo interno.
Proteggi la connettività dei backup e le copie di ripristino
Il traffico di backup necessita di un percorso progettato consapevolmente, perché i sistemi di backup sono obiettivi di grande valore. Un modello più sicuro e comune prevede che il server sorgente controllato dal cliente avvii una connessione in uscita verso il servizio di backup, mentre le connessioni in ingresso da internet al repository di backup restano bloccate. Consenti solo la destinazione, il protocollo e la direzione richiesti dal progetto di backup.
Non pubblicare direttamente su internet un repository di backup, un endpoint di storage o un’interfaccia di gestione dei backup. Se un prodotto di backup richiede comunicazioni in ingresso, instradale tramite una rete privata, una VPN o una allowlist strettamente limitata e documenta perché siano necessarie. Separa le credenziali di backup da quelle di produzione ed evita di usare un account amministratore di dominio per le operazioni di backup.
Safenix fornisce backup off-site per i server aziendali controllati dal cliente. I backup sono crittografati con una chiave che Safenix non possiede, archiviati in Germania e resi immutabili per tutta la durata della finestra di conservazione. Il cliente dovrebbe comunque limitare le connessioni di backup nel firewall sorgente e consentire solo il traffico necessario per raggiungere il servizio. I dettagli sulla protezione Safenix per il backup dei server aziendali e il ripristino off-site possono essere esaminati insieme al progetto firewall del cliente.
La connettività di backup esposta crea due rischi. Un aggressore può usarla come percorso verso la piattaforma di backup oppure interrompere, eliminare o crittografare le copie di ripristino. Mantenere il traffico di backup circoscritto e, ove possibile, unidirezionale riduce la probabilità che la compromissione di un server di produzione diventi una compromissione dell’ambiente di ripristino.
Le regole IPv4 e IPv6 devono corrispondere
Un errore frequente nei firewall consiste nel proteggere IPv4 lasciando IPv6 ampiamente raggiungibile. Se il server dispone di un indirizzo IPv6 pubblico, è necessaria una policy firewall IPv6 con lo stesso approccio deny by default, le stesse limitazioni dei servizi e le stesse aspettative di logging previste per IPv4.
Non presumere che disabilitare una regola IPv4 protegga il servizio. Controlla gli indirizzi in ascolto, i security group cloud, la configurazione del firewall dell’host e i controlli a livello di provider per entrambi i protocolli. Se IPv6 non è necessario, disabilitalo solo dopo aver verificato che applicazioni, monitoraggio, DNS e dipendenze di rete continueranno a funzionare. In caso contrario, gestiscilo correttamente.
Esamina il traffico IPv6 in uscita oltre a quello in ingresso. Un’applicazione che può raggiungere sistemi esterni tramite una famiglia di indirizzi non monitorata potrebbe aggirare le ipotesi alla base di un progetto di sicurezza solo IPv4.
Regole in uscita, logging e alerting
Bloccare tutto il traffico in uscita è raramente pratico per un server aziendale. Aggiornamenti, DNS, sincronizzazione dell’ora, email, API, monitoraggio e backup possono richiedere accesso in uscita. Una policy sensata inizia identificando queste dipendenze, quindi limita destinazioni e porte quando il rischio operativo lo giustifica.
Ad esempio, un application server può aver bisogno di HTTPS verso servizi software specifici, DNS verso resolver approvati, NTP verso fonti orarie approvate e di una connessione di backup in uscita. Potrebbe non avere alcun motivo per connettersi a server SMTP arbitrari, porte di database o servizi di amministrazione remota su internet.
Registra il traffico negato, ma rendi i log utili invece di sovraccaricarli. Memorizza origine, destinazione, porta, protocollo, interfaccia, azione e timestamp. Limita la frequenza degli eventi ripetitivi e inoltra i log importanti in una posizione che un aggressore non possa modificare facilmente. Genera alert per schemi come tentativi SSH o RDP ripetuti, scansioni su molte porte, SMTP in uscita imprevisto, nuovo accesso alle porte dei database o un cambiamento improvviso nel comportamento delle connessioni di backup.
Il logging dovrebbe supportare le indagini, non sostituire la prevenzione. Una regola che genera migliaia di alert ogni giorno finirà per essere ignorata. Regola le soglie in base al traffico normale e definisci chi esamina gli alert, con quale rapidità e quali prove devono essere conservate.
Come le agenzie possono gestire molti ambienti cliente
Le agenzie hanno bisogno di coerenza senza fingere che ogni cliente disponga della stessa architettura. La risposta è una baseline controllata con eccezioni documentate.
- Crea template basati sui ruoli per server web, applicativi, database, posta, amministrazione Windows e server sorgente dei backup.
- Usa variabili per gli intervalli IP dei clienti, gli indirizzi VPN, le subnet private e le destinazioni dei servizi approvati invece di codificare ipotesi rigide.
- Salva le regole firewall come configurazione sottoposta a controllo versione, quando la piattaforma lo consente, con revisione tra pari e cronologia delle modifiche.
- Applica una convenzione standard per la denominazione delle regole, includendo scopo, origine, destinazione, responsabile e data di revisione.
- Usa l’automazione per testare la sintassi, confermare che le porte necessarie siano in ascolto e verificare l’allineamento delle policy IPv4 e IPv6.
- Mantieni separate le procedure di accesso di emergenza e limitale nel tempo, impostando quando possibile una scadenza automatica.
Prima di distribuire un template, crea un inventario dei servizi. Controlla la documentazione applicativa, le connessioni attive e i processi pianificati, e chiedi al cliente quali fornitori esterni necessitano di accesso. Una breve fase di analisi costa meno che interrompere un’integrazione di fatturazione, un agente di monitoraggio o una pipeline di deployment.
Distribuisci le modifiche per fasi. Applica quando disponibile una policy proposta in modalità di audit o logging, confronta il traffico osservato con il progetto previsto e poi applicala durante una finestra di manutenzione. Mantieni disponibile una console out-of-band o un percorso di ripristino, così un amministratore non resterà bloccato a causa di una regola errata.
Firewall VPS rispetto all’hosting condiviso
Un VPS offre al cliente il controllo sul sistema operativo, sui servizi installati e generalmente sul firewall a livello di host. Ciò significa che il cliente o la sua agenzia è responsabile di decidere quali porte sono in ascolto e quali origini possono raggiungerle, oltre a gestire gli eventuali controlli forniti dalla piattaforma di hosting.
L’hosting condiviso è diverso. Più clienti utilizzano un ambiente gestito dal provider, che controlla il perimetro, l’isolamento della rete e l’esposizione dei servizi. In genere il cliente non può applicare una policy firewall completa per singolo server all’host sottostante né modificare le regole in ingresso del provider. Per una distinzione utile tra infrastruttura VPS gestita dal cliente e servizi di hosting condiviso, consulta questo riferimento alle infrastrutture VPS e di hosting.
Questa distinzione è importante per la pianificazione della sicurezza. Un sito web su hosting condiviso non equivale a un server aziendale controllato dal cliente e dotato di firewall del sistema operativo. Safenix protegge i server controllati dal cliente; non fornisce un piano di backup per un sito semplicemente perché è ospitato su hosting condiviso. Prima di progettare le procedure di backup e ripristino, è necessario confermare le capacità del provider di hosting e le responsabilità del cliente.
Esamina le regole firewall nell’ambito delle attività operative
Una policy firewall diventa inesatta non appena cambiano servizi, fornitori, reti o amministratori. Esamina le regole almeno periodicamente e dopo modifiche architetturali significative, migrazioni, incidenti di sicurezza o cambiamenti nel personale.
Durante una revisione, rimuovi le regole prive di responsabile, origine o finalità aziendale documentata. Controlla le allowlist temporanee mai revocate, gli intervalli di rete troppo ampi, le voci duplicate, i servizi in ascolto inutilizzati e le porte di gestione esposte tramite IPv6. Verifica che le interfacce di database e backup restino private e che i servizi pubblici utilizzino ancora certificati aggiornati e configurazioni sicure.
Conserva un registro semplice per ogni eccezione: cosa consente, perché esiste, chi l’ha approvata, quando deve essere riesaminata e cosa potrebbe sostituirla. In questo modo l’amministrazione del firewall passa da una raccolta di correzioni ad hoc a un controllo ripetibile.
Un firewall per singolo server con policy deny by default non impedirà ogni compromissione, ma può bloccare molti percorsi non necessari verso un sistema e limitare i movimenti dopo un incidente. Abbinalo ad autenticazione rafforzata, gestione delle patch, segmentazione, monitoraggio e backup off-site protetti. Il risultato è una superficie di attacco più ridotta e un percorso di ripristino più affidabile quando un server o una rete non sono più attendibili.