Protezione DDoS
Le piene vengono assorbite ai margini, gli attacchi a livello di rete vengono filtrati a monte e tutto ciò che raggiunge il server è racchiuso all'interno della gabbia a livello di kernel del singolo sito di destinazione. Più livelli, ciascuno con una funzione specifica, in modo che un attacco mirato a un sito non si traduca in un'interruzione per quelli vicini. Questo è il modello di difesa che abbiamo creato per una piattaforma che ospita oltre 650.000 siti in tutto il mondo, e la configurazione di base è inclusa in ogni piano. Disponibilità: la limitazione delle risorse del database per singolo sito è attualmente in fase di sviluppo e non è ancora disponibile. Tutto il resto descritto qui è già attivo.
Un attacco di inondazione volumetrico, un attacco applicativo L7 e un attacco di esaurimento delle connessioni lento sono tre problemi differenti. Gestiamo ciascuno di essi nel punto in cui risulta più economico e veloce farlo: a monte della flotta, all'edge e all'interno della gabbia.
La protezione DDoS a livello di provider filtra i flussi a livello di rete a monte della nostra flotta di worker, prima che quel traffico consumi una porta, una scheda di rete o un ciclo CPU sulla macchina su cui è in esecuzione il tuo sito. Per i profili di rischio avanzati e aziendali, Cloudflare Magic Transit e Spectrum estendono la stessa filtrazione al traffico non HTTP.
Una rete edge gestita si trova davanti a ogni sito. Assorbe attacchi HTTP volumetrici, esegue un WAF L7, applica limitazioni di frequenza per sito e utilizza la gestione dei bot e sfide gestite per separare i veri visitatori dal traffico automatizzato, il tutto prima che una richiesta raggiunga l'origine.
LiteSpeed Enterprise applica il throttling delle connessioni e delle richieste con limiti di connessione per IP, Imunify360 esegue un firewall di rete con protezione da forza bruta e filtraggio della reputazione IP, e i limiti dei processi di ingresso CloudLinux LVE stabiliscono il numero massimo di richieste simultanee che un singolo sito può mantenere aperte.
LVE limita CPU, RAM, IO, IOPS, processi ed entry-process per ciascun sito individualmente. Un attacco che supera i livelli superiori viene limitato all'interno della gabbia del sito di destinazione, in modo che la pressione generata rimanga confinata su quel sito anziché propagarsi all'intero server.
La maggior parte delle interruzioni di hosting durante un attacco non è causata dal raggiungimento dell'obiettivo da parte dell'attacco. Sono causate dal consumo di risorse della destinazione che affama tutto il resto sulla macchina. Questa è la modalità di guasto che questa architettura è progettata per eliminare.
La richiesta più economica che possa sopravvivere è quella che non tocca mai PHP o MySQL. La nostra cache a due livelli fa sì che gran parte di un flusso a livello di applicazione venga gestita da byte statici anziché dal lavoro del vostro server d'origine.
La mitigazione non è un ticket di supporto. I segnali alimentano un motore di policy che mappa ciascuno di essi a un'azione di enforcement, a una notifica al cliente e — ove possibile — a una rimedio automatico, con ogni transizione registrata.
Quando si attiva un segnale DDoS, il motore delle policy applica la mitigazione di Cloudflare e il rate limiting per singolo sito, e può stringere dinamicamente i limiti LVE di quel sito. Quando il segnale si interrompe, i limiti si rilassano di nuovo. Graduale, reversibile e registrato a ogni passaggio.
Se un attacco minaccia l'origine, il sito passa allo stato 'limitato' (throttled) — limiti LVE e di frequenza più restrittivi, con il sito che rimane attivo e funzionante. Lo stato limitato si risolve automaticamente quando la pressione diminuisce; non si tratta di una sospensione.
Al di sotto del motore delle policy, LVE limita l'utilizzo di CPU, I/O e processi per sito in modo nativo e automatico. È la prima linea di difesa sempre attiva, in funzione indipendentemente dal fatto che il traffico sia stato o meno classificato come attacco.
Ogni transizione di conformità registra il relativo motivo, se sia stata automatica o avviata dal personale, e le prove alla base. Ricevi una notifica su cosa è cambiato e su come risolverlo, e ogni azione è appellabile.
La protezione di base non è facoltativa, poiché un sito attaccato o compromesso minaccia i suoi vicini, la reputazione del nostro server e i nostri intervalli di IP. Esistono protezioni più avanzate per i siti il cui profilo di rischio lo richiede.
Un picco di traffico è spesso un sintomo. La stessa pipeline di segnali che gestisce i flussi anomali rileva anche le violazioni che li provocano, consentendo di classificare correttamente un incidente anziché limitarsi ad assorbirlo.
L'obiettivo di progettazione è il contenimento. Ogni sito viene eseguito all'interno della propria gabbia CloudLinux LVE con limiti di CPU, RAM, IO, IOPS, processi ed entry-process, la propria vista file system CageFS e la limitazione dei database per singolo sito tramite MySQL Governor. Un sito sotto attacco viene limitato al proprio tetto massimo anziché consumare l'intera macchina, e i limiti di connessione per IP di LiteSpeed limitano la quantità di server web che può occupare. Il contenimento è progettato a livello di kernel, non configurato per singolo cliente.
La base è inclusa in ogni piano: isolamento LVE e CageFS, limitazione delle connessioni e delle richieste con LiteSpeed, un firewall di rete, WAF proattivo e scansione antimalware, con l'assorbimento ai margini di Cloudflare e il filtraggio di rete a livello di provider davanti all'infrastruttura. La includiamo perché non possiamo rendere opzionale la protezione della nostra stessa infrastruttura. Gestione avanzata dei bot, livelli DDoS superiori, regole WAF avanzate e regole firewall dedicate sono componenti aggiuntivi per i siti che ne hanno bisogno.
Essere un bersaglio DDoS attiva la mitigazione di Cloudflare unita a limiti di frequenza per singolo sito e, solo se l'attacco minaccia l'origine, allo stato 'throttled': limiti LVE più restrittivi con il sito comunque attivo e funzionante. Lo stato Throttled si risolve automaticamente non appena la pressione diminuisce. La sospensione è riservata al mancato pagamento o ad abusi accertati e, anche in tal caso, il sito mostra una pagina di cortesia personalizzata e specifica per il problema anziché una pagina di errore.
Non per i contenuti serviti dalla cache. LSCache risponde alle richieste di pagine memorizzate nella cache senza richiamare PHP o MySQL, e una cache di oggetti Redis per singolo sito scarica le letture per pagine veramente dinamiche. Ciò che rimane è limitato dai limiti dei processi LVE e dei processi di immissione del tuo sito e dalla limitazione del database per singolo sito di MySQL Governor, in modo che la pressione sul database di un sito non possa riversarsi sul server. Le pagine del carrello, del checkout, del mio account e delle sessioni rimangono non memorizzate nella cache per impostazione predefinita, in modo che il rafforzamento della sicurezza non interrompa mai una transazione.
Sì, a livello di rete. La protezione DDoS a livello di provider filtra i flussi L3/4 a monte della nostra infrastruttura indipendentemente dal protocollo e, per esigenze avanzate o enterprise, Cloudflare Magic Transit e Spectrum estendono la mitigazione di livello edge al traffico non HTTP.
Ogni transizione di conformità viene registrata con il relativo motivo, specificando se è stata automatica o avviata dal team, e le prove a supporto. Ricevi una notifica sulle modifiche apportate e su come risolverle, ogni azione è appellabile e le azioni privilegiate vengono registrate nei log di audit per la tua traccia di conformità. I segnali vengono aggregati in un unico Abuse Desk anziché essere dispersi tra vari strumenti.
Sì. L'hosting Footprint-Free inizia con una prova di 14 giorni senza carta di credito che copre fino a 5 siti: nessun dato di pagamento, nessun vincolo. I piani sono coperti da una garanzia di rimborso di 30 giorni senza storie, migrazioni gratuite e nessun blocco del vendor.
Il filtraggio di rete, l'assorbimento ai margini, la limitazione del server e il contenimento per singolo sito sono attivi dal momento in cui effettui il deployment: nulla da configurare, niente da attivare a incidente in corso. Inizia con una prova di 14 giorni senza carta di credito, supportata da una garanzia di rimborso di 30 giorni e migrazioni gratuite.
Inizia gratis