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.
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.
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.
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.
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.
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.
Cosa fare nel tuo caso
| Situazione | Prossimo passo |
|---|---|
| Server di gioco UDP | Conferma porta reale, protocollo e profilo. Non usare una risposta HTTP come prova completa. |
| Richieste HTTP costose | Valuta applicazione, limiti e proxy insieme. La riserva di rete non elimina il lavoro per richiesta. |
| Origine esterna da proteggere | Documenta 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.