Passa al contenuto
Protezione DDoS · Peeryx · 15 Tbps+
Tutte le guide

Protezione DDoS L3, L4 e L7: cosa copre ogni livello

L’etichetta Anti-DDoS non specifica quali attacchi vengono filtrati su quali servizi. Un sito, un server di gioco e un transito protetto richiedono verifiche differenti. Valuta percorso reale e funzioni documentate, invece di affidarti soltanto a una grande capacità aggregata.

← Tutte le guideCubixServ

Prima di iniziare

Prepara un elenco di IP pubblici, porte, protocolli e origini. Individua dove avvengono filtro e inoltro. Conserva misure normali e condizioni del servizio per confrontarle durante un incidente. Prima di cambiare regole prevedi manutenzione, copia e ripristino.

L3: il traffico di rete

Il livello di rete considera pacchetti IP e schemi volumetrici. Un flusso può saturare il collegamento prima dell’applicazione, quindi interessa filtrarlo a monte. La capacità complessiva non coincide con quella del server: i 15 Tbps comunicati da CubixServ rappresentano capacità aggregata della rete di protezione, non la tua porta individuale né una garanzia per ogni attacco.

Un attacco può tentare di riempire un collegamento, esaurire lo stato della connessione o consumare il lavoro dell'applicazione. Diversi effetti possono verificarsi insieme. Identifica la risorsa minacciata e il traffico interessato prima di scegliere il filtraggio upstream, i controlli della connessione o le regole dell'applicazione.

L4: TCP e UDP

Il trasporto distingue connessioni TCP e flussi UDP. Porte, stati e frequenze possono essere oggetto di regole. Un profilo per siti non è automaticamente adatto a un gioco. Conferma la porta assegnata e separa l’amministrazione. Una verifica TCP riuscita non dimostra che l’inoltro UDP consenta il collegamento reale dei giocatori attraverso tutti i componenti previsti.

Controlla anche il traffico pulito consentito, i protocolli coperti, gli indirizzi protetti e i termini di intervento. La protezione può avere limiti di copertura o misure di contenimento. Un diritto illimitato non sostituisce le condizioni tecniche e il contratto.

L7: comprendere l’applicazione

Una richiesta apparentemente valida può generare lavoro costoso. Un proxy HTTP può controllare e limitare HTTP, ma non comprende automaticamente tutti i protocolli di gioco. Chiedi endpoint e funzioni precisi. In FiveM download HTTP e collegamento di gioco vanno valutati separatamente: proteggere una parte non certifica tutte le operazioni come protette a livello applicativo.

FiveM dimostra la distinzione: il punto di ingresso, i download e il gameplay di HTTP necessitano di un'architettura coerente. Un sito Web protetto può rimanere disponibile mentre il gioco fallisce. Una capacità L7 dovrebbe descrivere la sua portata effettiva piuttosto che pretendere di coprire ogni applicazione.

Proteggere anche l’origine

Un endpoint protetto è insufficiente se l’origine non protetta resta direttamente raggiungibile. Esamina DNS, download, amministrazione e altre porte. Limita le fonti soltanto dopo aver identificato tutti i percorsi autorizzati. Una regola di fiducia troppo ampia può aggirare i controlli; una troppo stretta può bloccare utenti legittimi. L’accesso amministrativo richiede una protezione dedicata al suo uso.

Per limitare un'origine è necessario comprendere fonti e servizi legittimi. Convalida percorsi, traffico di ritorno, voce, file e amministrazione prima di filtrare. Una lista consentita eccessivamente ampia espone l'origine; uno troppo stretto può causare un'interruzione. Non copiare una regola generica senza comprenderne l'architettura.

Confrontare rete e applicazione

Durante un incidente confronta traffico, scarti, connessioni riuscite e carico. Un thread principale o un database bloccato può fermare il gioco anche con rete apparentemente normale. Una maggiore capacità di filtraggio non corregge script costosi. Il solo timeout non prova un attacco: confronta perdita, percorsi, errori e differenze rispetto al funzionamento abituale del servizio.

Richiedi eventi con timestamp e una spiegazione del filtro quando le connessioni legittime falliscono. Distinguere i falsi positivi, le deviazioni del percorso e il carico dell'applicazione. Un test di carico non coordinato può degradare il servizio stesso; concordare una validazione attiva con il fornitore e limiti precisi.

Chiedere condizioni verificabili

Conferma copertura, banda assegnata, servizi consentiti, inoltro e assistenza. Verifica se occorrono un IP, un tunnel o cambiamenti all’origine. Prova l’intero percorso con utenti autorizzati prima e dopo la configurazione. Una pagina web raggiungibile non valida qualsiasi gioco; test di carico o attacco necessitano di un ambito esplicitamente autorizzato e coordinato con gli operatori coinvolti.

Quindi confronta i piani disponibili e i prezzi per l'ambito richiesto. Una scelta utile combina capacità di rete, gestione basata sul protocollo e capacità di diagnosticare gli incidenti. Nessun sistema di protezione elimina la necessità di mantenere software, account e backup.

Cosa fare nel tuo caso

SituazioneProssimo passo
Server di gioco UDPConferma porta reale, protocollo e profilo. Non usare una risposta HTTP come prova completa.
Richieste HTTP costoseValuta applicazione, limiti e proxy insieme. La riserva di rete non elimina il lavoro per richiesta.
Origine esterna da proteggereDocumenta fonti autorizzate e ritorno prima di restringere l’accesso diretto.

Fonti ufficiali

Queste fonti descrivono i protocolli e le impostazioni citati. Controlla sempre la documentazione della tua versione.

  1. RFC Editor / IETF/rfc/rfc4732
  2. NGINX/en/docs/stream/ngx_stream_proxy_module.html
  3. Cfx.re/docs/server-manual/proxy-setup/