Impostazione del Firewall del Server: Proteggere il Server da Attacchi DDoS e Bot

L'impostazione del firewall del server è il processo di mantenere aperti solo i porti necessari sul server, bloccando tutti gli accessi non necessari; costituisce il primo strato di difesa contro attacchi DDoS, brute force e traffico di bot dannosi. In pratica, l'obiettivo è limitare l'accesso SSH, aprire i servizi web in modo controllato, gestire le richieste sospette tramite limitazione del traffico, monitorare i log e, se possibile, filtrare il traffico prima che raggiunga il server con protezioni di livello superiore come CDN e WAF.

Non appena aprite un server web a Internet, potreste trovarvi a fronteggiare, in pochi minuti, scansioni di porte, tentativi di accesso SSH, bot di vulnerabilità e user-agent fasulli. Questo rende il firewall non solo una preferenza tecnica, ma un requisito necessario, soprattutto per strutture che eseguono WordPress, e-commerce, pannelli di controllo, API o server di gioco. In questa guida, costruiremo un'architettura firewall step-by-step applicabile su server Linux, discutendo dell'utilizzo di UFW, firewalld, nftables, Fail2ban, web application firewall e approcci di mitigazione DDoS.

Partiamo da un'importante verità: un firewall locale da solo non può fermare grandi attacchi DDoS. Quando un attacco di grandi dimensioni, come uno da 20 Gbps o 80 Gbps, raggiunge un data center o una rete backbone, pacchetti possono saturare la larghezza di banda prima di arrivare all'insieme di regole del vostro sistema operativo. Pertanto, l'approccio corretto è quello di utilizzare una sicurezza a strati: la protezione DDoS a livello fornitore, CDN/WAF, firewall del sistema operativo, limitazione del traffico applicativo e analisi regolare dei log devono lavorare insieme. Per una selezione dell'infrastruttura appropriata, si può fare riferimento alla pagina Soluzioni server VPS e VDS Hostragons e per le opzioni di hosting web sicuro si può consultare la pagina Pacchetti web hosting Hostragons.

A Cosa Serve un Firewall del Server?

Un firewall del server è uno strato di sicurezza che filtra il traffico di rete in base all’indirizzo IP di origine, all'indirizzo IP di destinazione, al porto, al protocollo, allo stato della connessione e, in alcuni casi, alle proprietà del pacchetto. Ad esempio, per il vostro sito web, i porti 80 e 443 devono essere aperti, mentre il porto del database 3306 non dovrebbe essere accessibile da Internet. È più sicuro permettere l'accesso sulla porta 22 solo dall'indirizzo IP della vostra azienda piuttosto che permettere a chiunque di tentare di connettersi tramite SSH.

L'obiettivo principale del firewall non è distruggere magicamente tutti gli attacchi. L'obbiettivo è ridurre la superficie di attacco. Maggiore è la riduzione della superficie di attacco, minori saranno le opzioni disponibili per un attaccante. Ad esempio, su un nuovo server Linux, SSH, il pannello web, il servizio di posta, il database, l'agente di monitoraggio e i servizi di test possono rimanere aperti simultaneamente. Ciascuno di questi introduce rischi distinti. Un firewall ben configurato funziona con il principio "rifiuta per impostazione predefinita, consenti ciò che è necessario".

Comprendere DDoS e Traffico di Bot

Perché gli Attacchi DDoS Sono Diversi?

DDoS, ovvero Distributed Denial of Service, mira a rendere un servizio inaccessibile mediante un traffico intenso proveniente da numerose fonti. L'attacco può saturare la larghezza di banda, esaurire le risorse CPU e RAM del server, o attivare operazioni costose a livello applicativo. Ad esempio, un piccolo server di applicazioni che riceve 50.000 richieste HTTP al secondo potrebbe non essere in grado di rispondere, anche se la connessione di rete non è satura, a causa di PHP-FPM, Node.js o della connessione al pool del database.

I Bot Sono Sempre Negativi?

No. Bot come Googlebot e Bingbot, così come alcuni bot di monitoraggio, sono utili. Tuttavia, ci sono bot dannosi che eseguono scansioni del pannello di amministrazione, ricerche di directory aperte, spam su moduli, copiature di contenuto, abusi di XML-RPC, generazione di registrazioni false e tentativi di accesso. Quindi, il vero obiettivo nella gestione dei bot non è di bloccare tutti i bot, ma di fare distinzioni in base al comportamento. Un'alta percentuale di errori, troppe richieste in poco tempo, intestazioni che non si comportano come un vero browser e schemi URL sospetti sono segnali importanti.

Lista di Controllo Prima di Iniziare l'Installazione

Quando si scrivono regole del firewall su un server in produzione, il principale rischio è quello di bloccarsi fuori dal server. Pertanto, è necessario eseguire una preparazione rapida prima di apportare modifiche. La seguente lista di controllo è un approccio sicuro comunemente utilizzato negli ambienti di produzione.

• Non chiudere la sessione SSH attiva; testare con un secondo terminale.
• Accertarsi che il fornitore del server offra accesso alla console, VNC o modalità di recupero.
• Elencare le porte aperte attuali: esaminare l'output di ss -tulpn o netstat -tulpn.
• Annotare quali porte sono utilizzate dai servizi web, mail, DNS, database, pannello e monitoraggio.
• Se utilizzate IPv6, pianificare anche le regole del firewall per IPv6.
• Applicare prima le regole di autorizzazione, poi quelle di negazione.
• Accertarsi che l'insieme di regole sia permanente; non dovrebbe andare perso dopo un riavvio del server.

Ad esempio, in un tipico server che ospita solo un sito web, i porti che devono rimanere aperti sono spesso 80, 443 e un porto SSH limitato. Se il server di posta non è attivo, non è necessario che porti come 25, 465, 587, 993 siano aperti. Se il database è utilizzato solo all'interno dello stesso server, i porti 3306 o 5432 dovrebbero rimanere chiusi al mondo esterno.

Quale Strumento per il Firewall Dovreste Scegliere?

Nel mondo Linux ci sono vari strumenti e la maggior parte gestisce la stessa infrastruttura di filtraggio del kernel con diversi livelli di facilità d'uso. Per i principianti, UFW è semplice e veloce. In ambienti aziendali o sistemi basati su Red Hat, firewalld è molto comune. Per scenari più avanzati, nftables offre una struttura moderna e flessibile. La seguente tabella facilita la scelta.

Installazione del Firewall del Server Step by Step

1. Identificare le Porte e i Servizi Aperti

Il primo passo è vedere cosa è aperto. Il comando ss -tulpn su Linux mostra quali servizi sono in ascolto su quali porte. Ad esempio, se nginx è in ascolto su 0.0.0.0:80 e 0.0.0.0:443, significa che il traffico web è accettato da tutte le interfacce. Se MariaDB è in ascolto su 0.0.0.0:3306, questo è generalmente rischioso; su molti siti web, il database dovrebbe funzionare su 127.0.0.1.

La regola pratica qui è: nessun servizio che non richiede accesso da Internet dovrebbe ascoltare su 0.0.0.0. È più sano correggere prima la configurazione del servizio e poi bloccarlo con il firewall, perché, anche se il firewall è disabilitato, il servizio non dovrebbe essere accessibile al pubblico.

2. Impostare la Politica Predefinita su Rifiuta

Negli insiemi di regole di sicurezza, il traffico in entrata per impostazione predefinita viene rifiutato, mentre il traffico in uscita è liberato secondo le esigenze. Questo approccio previene l'apertura errata di servizi non intenzionati in rete. Su un server Ubuntu che utilizza UFW, la logica è: prima si consente SSH, poi si aprono le porte 80 e 443, quindi si imposta la politica di ingresso predefinita su deny e si attiva il firewall.

Un flusso esemplificativo: consentire l'accesso SSH all'indirizzo IP dell'amministratore, aprire il traffico HTTP e HTTPS, chiudere le porte non necessarie, quindi attivarlo. Aprire il firewall senza aver autorizzato prima SSH è uno degli errori più comuni, soprattutto su server remoti.

3. Limitare l'Accesso SSH

SSH è uno dei servizi più frequentemente mirati dagli aggressori. Un server con il porto 22 aperto può subire centinaia o migliaia di tentativi di accesso al giorno. L'approccio più sicuro è limitare l'accesso SSH a specifici indirizzi IP. Se usate un IP statico, consentite solo il traffico dal vostro indirizzo IP dell'ufficio o della VPN. Se non avete un IP statico, utilizzate almeno un'autenticazione basata su chiavi e disabilitate l'accesso tramite password.

• Disabilitare l'accesso SSH diretto come root.
• Utilizzare chiavi SSH al posto delle password.
• Limitare gli utenti con AllowUsers o AllowGroups.
• Utilizzare Fail2ban per bloccare automaticamente i tentativi falliti.
• Se utilizzate un pannello di controllo, sottoporre anche il pannello a restrizioni IP.

Cambiare il porto non garantisce sicurezza di per sé, ma può ridurre il rumore generato dai bot automatici. Tuttavia, la vera protezione è fornita da limitazioni IP, autenticazione forte e monitoraggio dei log.

4. Aprire i Porti Web in Modo Controllato

Per la maggior parte dei server che pubblicano siti web, i porti 80 e 443 sono essenziali. Tuttavia, oggi il porto 443, ovvero HTTPS, dovrebbe essere il principale, mentre il 80 dovrebbe essere utilizzato solo per reindirizzare a HTTPS. I siti senza certificato SSL danneggiano sia la fiducia degli utenti sia le prestazioni SEO. A questo proposito, il collegamento Certificati SSL Hostragons rappresenta una naturale opportunità di collegamento interno per indirizzare il lettore verso un'installazione HTTPS sicura.

Quando si aprono i porti web, prestare attenzione al comportamento dell'IP reale. Se utilizzate CDN o proxy inverso, è più sicuro permettere l'accesso ai porti 80 e 443 del server solo dal range di IP della CDN, piuttosto che aprirli direttamente a tutto Internet. In questo modo, anche se l'attaccante conosce l'indirizzo IP reale del server, non può accedere direttamente al servizio web.

5. Chiudere il Database e i Servizi Interni a Internet

Lasciare aperti a Internet servizi come MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB e simili è estremamente rischioso. La mancanza di autenticazione per Redis, l'accesso non autorizzato agli indici in Elasticsearch o un porto di amministrazione aperto in MongoDB hanno portato in passato a numerose perdite di dati. Questi servizi dovrebbero, se possibile, ascoltare solo da localhost o da una rete privata.

Ad esempio, per un sito WordPress che gira sullo stesso server, il database deve operare su 127.0.0.1. Se state utilizzando un'applicazione separata e un server di database, consentite solo l'indirizzo IP privato del server applicativo. Lasciare accessibile il porto 3306 o 5432 da Internet è un errore noto che i bot tendono costantemente a sfruttare.

6. Bloccare i Tentativi di Brute Force con Fail2ban

Fail2ban monitora i file di log per rilevare tentativi di accesso ripetuti e falliti e blocca temporaneamente il relativo indirizzo IP. Possono essere definiti jail per SSH, nginx, Apache, Postfix, Dovecot, il login di WordPress e alcuni servizi del pannello. Ad esempio, bloccare per un'ora l'indirizzo IP che ha tentato 5 accessi SSH falliti in 10 minuti è un modo semplice ma efficace per iniziare.

Fate attenzione ad usare regole troppo aggressive nella configurazione di Fail2ban. Un modello di log errato può bloccare anche utenti legittimi. Pertanto, inizialmente è meglio mantenere il valore di bantime ragionevole, monitorare i log, e poi procedere a un’irrigidimento graduale.

7. Aggiungere Limitazioni di Traffico e Connessione

La limitazione del traffico a livello di sistema operativo può aiutare contro DDoS e traffico di bot. Ad esempio, se ci sono troppi nuovi accessi da un unico indirizzo IP al secondo, può essere applicata una limitazione. A livello del server web, utilizzate i moduli limit_req e limit_conn per nginx, o mod_evasive e soluzioni simili per Apache. A livello dell'applicazione, occorre inoltre impostare un limite di richiesta per login, ricerche, carrello, pagamenti e endpoint API.

Un esempio concreto: per una pagina di login, 10 tentativi al minuto per singolo IP possono essere ragionevoli. Un endpoint di ricerca potrebbe gestire da 2 a 5 richieste al secondo. Se offrite un’API, i limiti basati su token utente, limiti IP e analisi del comportamento dovrebbero essere progettati insieme. In questo modo, l'attaccante non può semplicemente superare il limite cambiando IP.

Esempio di Impostazione Sicura con UFW

Su un server web basato su Ubuntu o Debian, uno scenario di avvio sicuro può essere impostato con la seguente logica: prima controllate i servizi attuali, poi consentite l'accesso SSH solo dal vostro indirizzo IP di amministrazione, aprite le porte 80 e 443, rifiutate il traffico in ingresso per impostazione predefinita e verificate lo stato di UFW. Se non potete limitare l'accesso SSH a un IP statico, potete periodicamente concedere permesso a tutti gli IP per SSH e successivamente passare a una soluzione VPN o IP statica.

Un esempio di decisione potrebbe essere: supponiamo che l'indirizzo IP dell'amministratore sia 203.0.113.10. SSH deve venire solo da questo IP. Il traffico web può rimanere aperto per tutti sui porti 80 e 443. I porti di database, Redis, pannello e test devono essere chiusi. Questa configurazione è un buon inizio per molti siti web aziendali di piccole e medie dimensioni. Per fare correttamente la reindirizzazione a livello di dominio e DNS, si potrebbe fare riferimento alla pagina Verifica dominio e registrazione Hostragons.

Logica delle Zone con firewalld

firewalld è ampiamente utilizzato su server basati su AlmaLinux, Rocky Linux e RHEL. Firewalld funziona con il concetto di zone. La zona pubblica è per interfacce aperte su Internet, la trusted zone è per reti locali fidate, mentre la drop zone viene utilizzata per scartare silenziosamente il traffico indesiderato. Il punto più importante è la differenza tra regole runtime e permanenti. La regola runtime è applicata immediatamente ma può andare persa dopo un riavvio; la regola permanente è duratura, ma potrebbe necessitare un reload.

Nell'ambiente aziendale, utilizzare definizioni basate su servizi con firewalld semplifica le operazioni. Ad esempio, potete aprire i servizi http e https sulla zona pubblica, consentendo a SSH di essere accessibile solo da indirizzi IP specifici. Se la rete di gestione, la rete di backup e il traffico degli utenti sono su interfacce distinte, la struttura delle zone migliora la sicurezza e la leggibilità.

CDN, WAF e Protezione DDoS a Livello di Fornitore

Un firewall locale prende decisioni sui pacchetti dopo che questi sono arrivati al server. In caso di grandi attacchi DDoS, l'obiettivo è filtrare il traffico prima che raggiunga il server. Pertanto, CDN, WAF e protezione DDoS a livello di fornitore sono critici. I CDN presentano contenuti statici presso le posizioni edge, il WAF filtra le richieste dannose a livello applicativo, e la protezione del fornitore assorbe o pulisce attacchi volumetrici a livello di rete.

Nel modello ideale, i vostri record DNS passano attraverso il CDN, l'indirizzo IP reale del server è nascosto, e il firewall del server accetta solo porte 80 e 443 dagli IP della CDN. Le porte di gestione, invece, sono accessibili tramite VPN o IP statico. Un modello di questo tipo riduce la possibilità di attacchi diretti e permette di eliminare il traffico di bot prima che raggiunga l'applicazione. Per contenuti che affrontano insieme questioni di sicurezza web e prestazioni, si può utilizzare il collegamento Guide alla velocizzazione e sicurezza del sito web.

Misure a Livello di Applicazione Contro i Bot

Il blocco dei bot non si limita a una lista nera di IP. I bot moderni possono utilizzare proxy, reti mobili, IP di data center e user agent variabili. Pertanto, è necessario un approccio basato sul comportamento. Le analisi di login ripetuti in breve tempo dallo stesso IP, scansioni costanti che generano 404, elevata frequenza di accessi a wp-login.php o xmlrpc.php, schemi di clic sospetti e intestazioni inusuali devono essere analizzati.

• Utilizzate limitazione di traffico su form di login e registrazione.
• Disabilitate o limitate l'accesso XML-RPC non necessario.
• Proteggete il pannello di gestione con URL diversi, restrizioni IP, e autenticazione a più fattori.
• Filtrate schemi user-agent e referrer sospetti a livello WAF.
• Utilizzate CAPTCHA o meccanismi di verifica invisibili in modo bilanciato nei form.
• Per gli endpoint API, aggiungete controlli per chiave, firma, quote e timestamp.

Nella gestione dei bot, è cruciale non compromettere l'esperienza utente. Eccessivi controlli CAPTCHA, blocchi aggressivi o errati configurazioni di blocco per nazione possono danneggiare i vostri clienti reali. Pertanto, la misurazione, i test e un irrigidimento graduale sono i migliori metodi.

Monitoraggio dei Log e Regole di Allerta

Pensare che l'installazione sia finita è un errore comune. Il firewall è un sistema vivo e deve essere monitorato regolarmente. Le statistiche di accesso, i log di autenticazione (auth.log o secure), anomalie nei log access di nginx, l'aumento degli errori nei log (404 e 500), e metriche di sistema devono essere monitorati per CPU e numero di connessioni. Anche un semplice allerta può far risparmiare minuti preziosi quando inizia un attacco.

I valori soglia iniziali potrebbero essere i seguenti: 100 o più richieste 404 dallo stesso IP in 5 minuti, oltre 20 tentativi sulla pagina di login in 1 minuto, utilizzo della CPU che rimane sopra il 90% per 10 minuti, e il numero di connessioni che supera di 3 volte la norma. Questi valori soglia variano da sito a sito; la cosa importante è conoscere il vostro profilo di traffico normale.

Errori Comuni e Modi per Evitarli

• Attivare il firewall senza autorizzazione SSH: Questo può causarvi la perdita di accesso a un server remoto. Testate sempre con una seconda sessione.
• Dimenticare IPv6: Il lato IPv4 può essere chiuso mentre il servizio è aperto su IPv6.
• Lasciare il database aperto a Internet: Porte come 3306, 5432, 6379 e 9200 sono continuamente scansionate dai bot.
• Usare un CDN ma lasciare l'IP reale aperto: Gli aggressori possono bypassare il CDN e attaccare direttamente il server.
• Modificare le regole senza documentarle: In caso di emergenza, sarà difficile capire a cosa serviva ogni regola.
• Non avere un piano di accesso di emergenza: Se non c'è accesso alla console in caso di regola errata, l'interruzione può durare a lungo.

Esempio di Politica Firewall Pratica

Per un piccolo sito web aziendale, una politica sintetica praticabile potrebbe essere la seguente: il traffico in ingresso è bloccato per impostazione predefinita; 443 è aperto per tutti; 80 è aperto solo per il reindirizzamento a HTTPS; SSH è accessibile solo tramite VPN o dall'indirizzo IP di amministratore statico; il database è sull'localhost o su una rete privata; se si utilizza un CDN, 80 e 443 sono aperti solo agli IP della CDN; Fail2ban monitora i tentativi di accesso SSH e web; i log vengono inviati a uno strumento di monitoraggio centralizzato.

Per un sito di e-commerce di medie dimensioni, si potrebbero aggiungere IP di callback di pagamento in whitelist, spostare il pannello di amministrazione dietro una VPN, applicare limiti di quota a livello di API, abilitare regole per prevenire SQL injection e XSS nel WAF, e sviluppare un piano di filtraggio temporaneo basato su paesi o ASN. È importante che questo piano sia documentato; eseguire procedure predefinite invece di decidere al momento dell'attacco riduce i tempi di inattività.

Test: Le Regole Funzionano Davvero?

Dopo l'installazione del firewall, è essenziale eseguire dei test. Eseguite una scansione delle porte aperte da una rete differente, verificate che l'accesso SSH funzioni solo dagli IP autorizzati, controllate che il sito web sia accessibile tramite HTTPS, e assicuriatevi che il porto del database sia chiuso dall'esterno. Se usate un CDN, verificate che richieste HTTP dirette all'IP reale del server siano bloccate.

Durante il processo di test, evitate scansioni aggressive che possano danneggiare i sistemi di produzione. L'obiettivo è quella di effettuare una verifica sicura. Inoltre, dopo ogni modifica, esportate o annotate l'insieme di regole. In questo modo, sarà più facile tornare alla configurazione precedente se si verifica un problema.

Piano di Manutenzione e Aggiornamento

La sicurezza del server non è un'installazione una tantum, ma un processo di manutenzione regolare. Quando viene aggiunto un nuovo servizio, le esigenze delle porte devono essere riviste; quando un servizio precedente viene rimosso, le relative autorizzazioni devono essere eliminate; le aggiornamenti di sicurezza devono essere applicate in modo tempestivo e i log controllati periodicamente. Effettuare un controllo delle porte aperte almeno una volta al mese e rivedere il set di regole del firewall ogni tre mesi è un buon inizio pratico.

Inoltre, un piano di backup è parte integrante della strategia di sicurezza. Un attacco DDoS può costringere a chiudere l'accesso, ma malware o accesso non autorizzato possono portare a perdite di dati. L'hosting sicuro, SSL, gestione del dominio e backup devono essere considerati insieme. In questo contesto, i collegamenti Cosa considerare quando si sceglie un hosting sicuro e come si installa il certificato SSL sono naturalmente connessi.

Conclusione

Impostare un firewall del server non rende il server completamente invisibile agli attacchi DDoS e ai bot; tuttavia, riduce significativamente la superficie di attacco, diminuisce il rischio di accesso non autorizzato e consente di rispondere agli incidenti in modo più controllato. Il risultato migliore deriva dall'implementazione combinata della protezione DDoS a livello fornitore, CDN/WAF, politiche portuali severe, restrizioni SSH, Fail2ban, limitazione del traffico e monitoraggio regolare dei log.

Se state lanciando un nuovo progetto, pianificare la politica del firewall all'inizio è più facile che fare correzioni dopo. Valutate le vostre esigenze di sicurezza mentre esaminate server, hosting, domini e SSL su Hostragons per creare un ambiente web più resiliente. Se avete bisogno di far partire con una piccola lista di controllo: chiudete le porte aperte, limitate l'accesso SSH, rendete HTTPS obbligatorio e monitorate i log.

Domande Frequenti

Un firewall del server può bloccare completamente un attacco DDoS?

No. Un firewall locale può ridurre alcuni attacchi di piccola scala e di livello protocollo, ma per grandi attacchi DDoS è necessario utilizzare protezione DDoS a livello di fornitore, CDN e WAF.

Quali porte devono rimanere aperte su un server web?

Su un tipico server web, i porti 80 e 443 rimangono aperti. Il porto SSH dovrebbe essere accessibile solo da IP di amministratore autorizzati. Le porte del database e dei servizi interni dovrebbero essere chiuse a Internet.

Devo usare UFW o firewalld?

UFW offre un avvio più semplice per Ubuntu e Debian. Firewalld è comune su sistemi basati su AlmaLinux, Rocky Linux e RHEL. Per scenari avanzati e personalizzati, si può optare per nftables.

Posso fermare il traffico dei bot solo con il blocco degli IP?

In genere, no. I bot moderni utilizzano IP diversi e proxy. Ciò richiede l'uso della limitazione del traffico, regole WAF, analisi del comportamento, CAPTCHA e quote basate sull'applicazione.

Qual è il rischio maggiore durante l'installazione del firewall?

Il rischio più grande è quello di bloccare il proprio accesso SSH a causa di una regola errata. Pertanto, è necessario definire prima l'autorizzazione SSH, testare con una seconda sessione, e assicurarsi di avere accesso alla console del fornitore disponibile.