Come proteggere un server dagli attacchi DDoS con un proxy: configurazione in 15 minuti

Gli attacchi DDoS possono paralizzare il funzionamento di qualsiasi servizio web in pochi minuti. I malintenzionati inviano migliaia di richieste da diversi indirizzi IP, sovraccaricando il server e rendendolo non disponibile per gli utenti reali. I server proxy sono uno degli strumenti di protezione più efficaci, che consentono di filtrare il traffico dannoso, bilanciare il carico e nascondere l'indirizzo IP reale del tuo server.

In questa guida vedremo come configurare un proxy per proteggere da DDoS, quali tipi di proxy utilizzare e come costruire un sistema di sicurezza multilivello. Il materiale è rivolto ad amministratori di sistema, proprietari di servizi web e specialisti DevOps.

Come funzionano gli attacchi DDoS e perché i proxy aiutano

DDoS (Distributed Denial of Service) è un attacco distribuito di negazione del servizio. Il malintenzionato utilizza un botnet di migliaia di dispositivi infetti che inviano simultaneamente richieste al tuo server. L'obiettivo è esaurire le risorse del server (processore, memoria, banda) e renderlo non disponibile per gli utenti legittimi.

I principali tipi di attacchi DDoS:

• Attacchi volumetrici — riempiono la banda con un'enorme quantità di traffico (amplificazione DNS, inondazione UDP)
• Attacchi di protocollo — sfruttano vulnerabilità nei protocolli di rete (inondazione SYN, Ping of Death)
• Attacchi a livello applicativo — imitano richieste legittime a un'applicazione web (inondazione HTTP, Slowloris)

I server proxy aiutano a proteggersi da DDoS in diversi modi:

• Nascondere l'indirizzo IP reale del server — gli attaccanti vedono solo l'IP del proxy, non quello del tuo server principale
• Filtraggio del traffico dannoso — il proxy analizza le richieste e blocca quelle sospette
• Bilanciamento del carico — più server proxy distribuiscono il traffico tra i server backend
• Rate limiting — limitazione del numero di richieste da un singolo indirizzo IP
• Cache del contenuto statico — riduce il carico sul server principale

È importante capire che i proxy non sono una panacea per tutti i tipi di DDoS. Attacchi volumetrici potenti possono saturare la banda fino al server proxy. Pertanto, i proxy sono efficaci in combinazione con altri metodi di protezione: CDN, servizi anti-DDoS basati su cloud (Cloudflare, AWS Shield), firewall.

Tipi di proxy per proteggere da DDoS: inversi vs diretti

Per proteggere da DDoS si utilizzano due principali tipi di server proxy:

Proxy inversi (Reverse Proxy)

Un proxy inverso si trova davanti al tuo server web e accetta tutte le richieste in ingresso dai clienti. I clienti interagiscono solo con il proxy, senza conoscere l'indirizzo IP reale del tuo server. Questo è lo strumento principale per proteggere da DDoS.

Soluzioni popolari per proxy inversi:

• Nginx — server web veloce e leggero con funzionalità di proxy inverso
• HAProxy — bilanciatore di carico specializzato con potenti capacità di filtraggio
• Apache mod_proxy — modulo per Apache, meno performante rispetto a Nginx
• Varnish — acceleratore HTTP con focus sulla cache

Proxy diretti (Forward Proxy)

I proxy diretti vengono utilizzati dal lato client per le richieste in uscita. Nel contesto della protezione da DDoS, sono utilizzati meno frequentemente, ma possono essere utili per:

• Nascondere gli indirizzi IP dei tuoi server quando si accede a API esterne
• Distribuire il traffico in uscita attraverso molti indirizzi IP
• Superare i blocchi durante la raccolta di informazioni su potenziali attacchi

Per questi compiti sono adatti proxy residenziali — hanno indirizzi IP reali di utenti domestici e appaiono come traffico normale, rendendo difficile la loro rilevazione e blocco.

Configurazione di un proxy inverso su Nginx per proteggere il server

Nginx è uno degli strumenti più popolari per creare un proxy inverso. Gestisce rapidamente le richieste in ingresso, supporta il rate limiting e può filtrare il traffico sospetto.

Configurazione di base del proxy inverso

Installa Nginx su un server separato, che accetterà tutto il traffico in ingresso. Il vero server web deve essere nascosto dietro il proxy e ricevere richieste solo da esso.

# /etc/nginx/nginx.conf

http {
    # Limitazione del numero di connessioni da un IP
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    limit_conn conn_limit 10;

    # Limitazione del numero di richieste (rate limiting)
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
    limit_req zone=req_limit burst=20 nodelay;

    # Timeout per proteggere da Slowloris
    client_body_timeout 10s;
    client_header_timeout 10s;
    keepalive_timeout 5s 5s;
    send_timeout 10s;

    upstream backend {
        # IP del tuo vero server web
        server 192.168.1.100:80;
        # Puoi aggiungere più server per il bilanciamento
        # server 192.168.1.101:80;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            # Inoltro delle richieste al backend
            proxy_pass http://backend;
            
            # Trasferimento dell'IP originale del cliente
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;
            
            # Timeout per il proxy
            proxy_connect_timeout 5s;
            proxy_send_timeout 10s;
            proxy_read_timeout 10s;
        }
    }
}

Blocco degli User-Agent sospetti

Molti attacchi DDoS utilizzano bot con User-Agent caratteristici. Aggiungi regole per bloccarli:

# Blocco dei bot noti
map $http_user_agent $bad_bot {
    default 0;
    ~*bot 1;
    ~*crawler 1;
    ~*spider 1;
    ~*scraper 1;
    "" 1; # User-Agent vuoto
}

server {
    listen 80;
    server_name example.com;

    if ($bad_bot) {
        return 403;
    }

    location / {
        proxy_pass http://backend;
    }
}

Geo-blocco dei paesi indesiderati

Se il tuo servizio funziona solo per determinati paesi, puoi bloccare il traffico da altre regioni utilizzando il modulo GeoIP:

# Installazione del modulo GeoIP
# apt-get install nginx-module-geoip

load_module modules/ngx_http_geoip_module.so;

http {
    geoip_country /usr/share/GeoIP/GeoIP.dat;

    # Consenti solo il traffico dalla Russia e dall'Ucraina
    map $geoip_country_code $allowed_country {
        default no;
        RU yes;
        UA yes;
    }

    server {
        listen 80;
        server_name example.com;

        if ($allowed_country = no) {
            return 403;
        }

        location / {
            proxy_pass http://backend;
        }
    }
}

HAProxy per bilanciamento del carico e filtraggio del traffico

HAProxy è un potente bilanciatore di carico con avanzate capacità di filtraggio del traffico. Supporta ACL (Access Control Lists) complesse per bloccare attacchi a livello applicativo.

Configurazione di base di HAProxy

# /etc/haproxy/haproxy.cfg

global
    maxconn 50000
    # Logging
    log /dev/log local0
    log /dev/log local1 notice

defaults
    mode http
    log global
    option httplog
    option dontlognull
    
    # Timeout
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    
    # Limitazione della dimensione della richiesta (protezione da POST flood)
    maxconn 3000

frontend http_front
    bind *:80
    
    # Rate limiting: massimo 100 richieste in 10 secondi da un IP
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src
    http-request deny if { sc_http_req_rate(0) gt 100 }
    
    # Blocco delle richieste senza intestazione Host
    acl has_host hdr(host) -m found
    http-request deny if !has_host
    
    # Blocco degli User-Agent sospetti
    acl bad_bot hdr_sub(User-Agent) -i bot crawler spider scraper
    http-request deny if bad_bot
    
    # Inoltro al backend
    default_backend web_servers

backend web_servers
    balance roundrobin
    option httpchk GET /health
    
    # Elenco dei server backend
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check
    server web3 192.168.1.102:80 check

Protezione da HTTP Flood con ACL

HTTP Flood è un attacco in cui il malintenzionato invia un gran numero di richieste HTTP legittime. HAProxy consente di creare regole complesse per la loro rilevazione:

frontend http_front
    bind *:80
    
    # Tracciamento del numero di richieste da un IP
    stick-table type ip size 100k expire 30s store http_req_rate(10s),conn_cur
    http-request track-sc0 src
    
    # Blocco al superamento dei limiti
    acl too_many_requests sc_http_req_rate(0) gt 50
    acl too_many_connections sc_conn_cur(0) gt 10
    
    http-request deny deny_status 429 if too_many_requests
    http-request deny deny_status 429 if too_many_connections
    
    # Blocco delle richieste a percorsi non esistenti (scansione)
    acl valid_path path_beg /api /static /login /
    http-request deny if !valid_path
    
    default_backend web_servers

Whitelist di indirizzi IP fidati

Crea una whitelist per indirizzi IP fidati (ad esempio, i tuoi indirizzi di ufficio o dei partner), che non saranno soggetti a rate limiting:

frontend http_front
    bind *:80
    
    # Whitelist di indirizzi IP fidati
    acl whitelist src 203.0.113.0/24 198.51.100.50
    
    # Rate limiting solo per IP non in whitelist
    stick-table type ip size 100k expire 30s store http_req_rate(10s)
    http-request track-sc0 src if !whitelist
    http-request deny if { sc_http_req_rate(0) gt 100 } !whitelist
    
    default_backend web_servers

Utilizzo di proxy residenziali per nascondere l'infrastruttura

Oltre ai proxy inversi davanti al tuo server, puoi utilizzare proxy residenziali per una protezione aggiuntiva dell'infrastruttura. Questo è particolarmente utile se hai bisogno di:

• Nascondere gli indirizzi IP dei tuoi server di monitoraggio — se monitori attacchi DDoS o raccogli informazioni sulle minacce, i proxy residenziali possono aiutarti a nascondere le tue azioni
• Accedere a API esterne senza rivelare l'infrastruttura — i tuoi server possono effettuare richieste tramite proxy residenziali, rendendo difficile la loro rilevazione
• Testare la protezione da DDoS — simulare attacchi da diversi indirizzi IP per verificare l'efficacia dei tuoi filtri

I proxy residenziali hanno indirizzi IP di utenti domestici reali, il che li rende indistinguibili dal traffico normale. Questo rende difficile il loro blocco e consente di superare le restrizioni geografiche.

Esempio: Monitoraggio delle minacce tramite proxy residenziali

Supponiamo che tu voglia monitorare l'attività dei botnet che potrebbero attaccare il tuo servizio. Utilizzando proxy residenziali, puoi raccogliere informazioni senza rivelare gli indirizzi IP dei tuoi server:

import requests

# Configurazione del proxy residenziale
proxies = {
    'http': 'http://username:password@residential-proxy.com:8080',
    'https': 'http://username:password@residential-proxy.com:8080'
}

# Raccolta di informazioni su potenziali minacce
threat_sources = [
    'http://suspicious-site1.com',
    'http://suspicious-site2.com'
]

for source in threat_sources:
    try:
        response = requests.get(source, proxies=proxies, timeout=5)
        # Analisi della risposta per identificare schemi di attacco
        print(f"Status: {response.status_code}, IP: {response.headers.get('X-Your-IP')}")
    except Exception as e:
        print(f"Errore nell'accesso a {source}: {e}")

Regole di filtraggio: come distinguere un attacco da traffico legittimo

La principale difficoltà nella protezione da DDoS a livello applicativo (L7) è distinguere il traffico dannoso da quello legittimo. Gli attacchi moderni imitano il comportamento degli utenti reali, rendendo difficile la loro rilevazione.

Segnali di un attacco DDoS

• Aumento improvviso del numero di richieste — 2-10 volte di più del normale in un breve periodo
• Richieste con lo stesso User-Agent — i bot spesso utilizzano lo stesso User-Agent
• Assenza di Referer — richieste dirette senza passare da altre pagine
• Richieste simili — accessi allo stesso URL con minime variazioni
• Assenza di JavaScript — i bot non eseguono codice JS sulla pagina
• Basso tempo sulla pagina — i bot chiudono immediatamente la connessione dopo aver ricevuto una risposta
• Intervalli IP sospetti — richieste massicce da una stessa sottorete

Filtraggio multilivello

Una protezione efficace utilizza più livelli di filtraggio:

Esempio: JavaScript Challenge in Nginx

Un modo semplice per filtrare i bot è richiedere l'esecuzione di JavaScript per impostare i cookie:

server {
    listen 80;
    server_name example.com;

    # Verifica della presenza di cookie
    set $has_cookie 0;
    if ($http_cookie ~* "verified=true") {
        set $has_cookie 1;
    }

    # Se il cookie non è presente, mostriamo la sfida JS
    location / {
        if ($has_cookie = 0) {
            return 200 '
                <html>
                <head><title>Verifica</title></head>
                <body>
                <script>
                    document.cookie = "verified=true; path=/";
                    window.location.reload();
                </script>
                <noscript>Abilita JavaScript</noscript>
                </body>
                </html>
            ';
        }

        proxy_pass http://backend;
    }
}

Monitoraggio e risposta a DDoS in tempo reale

Una protezione efficace da DDoS richiede un monitoraggio costante del traffico e una risposta rapida alle anomalie. Configura un sistema di monitoraggio che tenga traccia delle metriche chiave:

• Numero di richieste al secondo — un aumento improvviso può indicare un attacco
• Numero di indirizzi IP unici — DDoS spesso proviene da molti IP
• Percentuale di errori 4xx/5xx — un aumento degli errori può essere un segno di sovraccarico
• Tempo di risposta del server — un aumento della latenza indica problemi
• Consumo delle risorse — CPU, memoria, traffico di rete

Strumenti di monitoraggio

Configurazione degli avvisi in Prometheus

Crea regole per avvisare automaticamente quando vengono rilevate anomalie:

# prometheus_alerts.yml

groups:
  - name: ddos_detection
    interval: 10s
    rules:
      # Avviso per aumento improvviso delle richieste
      - alert: HighRequestRate
        expr: rate(nginx_http_requests_total[1m]) > 1000
        for: 1m
        labels:
          severity: warning
        annotations:
          summary: "Tasso di richieste elevato rilevato"
          description: "Il tasso di richieste è {{ $value }} req/s"

      # Avviso per aumento degli errori 5xx
      - alert: HighErrorRate
        expr: rate(nginx_http_requests_total{status=~"5.."}[5m]) > 10
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Tasso di errore 5xx elevato"
          description: "Errori 5xx: {{ $value }} req/s"

      # Avviso per alta CPU
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Utilizzo CPU elevato"
          description: "L'utilizzo della CPU è {{ $value }}%"

Risposta automatica con Fail2ban

Fail2ban analizza i log e blocca automaticamente gli indirizzi IP che superano i limiti di richieste:

# /etc/fail2ban/jail.local

[nginx-req-limit]
enabled = true
filter = nginx-req-limit
logpath = /var/log/nginx/access.log
maxretry = 100
findtime = 60
bantime = 3600
action = iptables-multiport[name=ReqLimit, port="http,https", protocol=tcp]

# /etc/fail2ban/filter.d/nginx-req-limit.conf
[Definition]
failregex = ^<HOST> -.*"(GET|POST).*HTTP.*"
ignoreregex =

Protezione multilivello: combinare proxy con altri metodi

I server proxy sono un elemento importante nella protezione da DDoS, ma sono più efficaci in combinazione con altri metodi. Esaminiamo l'architettura di una protezione multilivello:

Livello 1: Protezione di rete (L3/L4)

• Servizi anti-DDoS basati su cloud — Cloudflare, AWS Shield, Google Cloud Armor filtrano il traffico prima che raggiunga i tuoi server
• Firewall hardware — hardware specializzato per filtrare il traffico di rete
• BGP blackholing — reindirizzamento del traffico dannoso in un "buco nero" a livello del provider

Livello 2: CDN e caching

• CDN (Content Delivery Network) — distribuisce contenuti statici su molti server, riducendo il carico sull'origine
• Caching sui proxy — Varnish, Nginx memorizzano nella cache le pagine popolari e le restituiscono senza contattare il backend
• Ottimizzazione dei contenuti — minificazione di CSS/JS, compressione delle immagini riducono il volume del traffico

Livello 3: Proxy e bilanciamento (L7)

• Proxy inversi — Nginx, HAProxy filtrano le richieste a livello applicativo
• Bilanciamento del carico — distribuzione del carico tra più server backend
• Rate limiting — limitazione del numero di richieste da un IP
• WAF (Web Application Firewall) — ModSecurity, AWS WAF bloccano attacchi alle applicazioni web

Livello 4: Ottimizzazione del backend

• Ottimizzazione del database — indici, caching delle query, repliche di lettura
• Elaborazione asincrona — compiti pesanti vengono eseguiti in background tramite code (RabbitMQ, Redis)
• Scalabilità orizzontale — aggiunta di nuovi server all'aumentare del carico

Esempio di architettura

Cliente
  ↓
Cloudflare (anti-DDoS L3/L4, CDN)
  ↓
Nginx proxy inverso (rate limiting, filtraggio)
  ↓
HAProxy (bilanciamento del carico)
  ↓
Server backend (applicazione web)
  ↓
Database (con replica)

Questa architettura fornisce protezione a tutti i livelli: rete, trasporto, applicativo. Anche se un attacco supera un livello, il successivo lo fermerà.

Utilizzo di proxy di data center per un ulteriore livello

In alcuni casi ha senso aggiungere proxy di data center come strato intermedio tra CDN e i tuoi server. Offrono un'elevata velocità di elaborazione e possono eseguire un ulteriore filtraggio del traffico. I proxy di data center sono più economici rispetto ai proxy residenziali e mobili, rendendoli una soluzione economicamente vantaggiosa per gestire grandi volumi di traffico.

Conclusione

Proteggere da attacchi DDoS con server proxy è un metodo efficace che consente di filtrare il traffico dannoso, nascondere gli indirizzi IP reali dei server e bilanciare il carico. I proxy inversi basati su Nginx o HAProxy offrono una configurazione flessibile delle regole di filtraggio, rate limiting e blocco delle richieste sospette.

Punti chiave che abbiamo esaminato:

• Proxy inversi (Nginx, HAProxy) — strumento principale di protezione a livello applicativo (L7)
• Rate limiting e filtraggio per User-Agent, reputazione IP aiutano a filtrare la maggior parte degli attacchi
• I proxy residenziali sono utili per nascondere l'infrastruttura di monitoraggio e raccogliere informazioni sulle minacce
• La protezione multilivello (CDN + proxy + WAF + ottimizzazione del backend) garantisce la massima resilienza
• Monitoraggio e risposta automatica sono fondamentali per una rapida rilevazione e blocco degli attacchi

Ricorda che gli attacchi DDoS evolvono costantemente, quindi il sistema di protezione richiede aggiornamenti e test regolari. Esegui test di carico, analizza i log, aggiorna le regole di filtraggio e rimani aggiornato sui nuovi metodi di attacco.

Se stai pianificando di costruire un sistema di protezione multilivello utilizzando proxy, ti consigliamo di considerare proxy residenziali per nascondere infrastrutture critiche e proxy di data center per un'elaborazione ad alta velocità di grandi volumi di traffico. La combinazione di diversi tipi di proxy offre un equilibrio ottimale tra sicurezza, prestazioni e costo.