Protezione DDoS
I picchi di traffico anomali vengono assorbiti all'edge, gli attacchi a livello di rete sono filtrati a monte e qualsiasi elemento raggiunga il server viene isolato all'interno della gabbia a livello di kernel del sito target. Diversi livelli, ognuno con una funzione distinta, affinché un attacco mirato a un sito non provochi un disservizio per quelli adiacenti. Questo è il modello di difesa che abbiamo sviluppato per una piattaforma che ospita oltre 700.000 siti in tutto il mondo, e il livello di base è attivo su ogni piano. Disponibilità: la limitazione del database per singolo sito è in fase di sviluppo attivo e non è ancora disponibile. Tutto il resto descritto qui è operativo già oggi.
Un flood volumetrico, un flood applicativo L7 e un attacco lento per l'esaurimento delle connessioni rappresentano tre problemi differenti. Gestiamo ciascuno di essi dove risulta più economico e rapido intervenire: a monte dell'infrastruttura, sull'edge e all'interno della gabbia.
La protezione DDoS a livello di provider filtra i sovraccarichi del livello di rete a monte del nostro parco worker, prima che tale traffico consumi una porta, una scheda di rete (NIC) o un ciclo di CPU sulla macchina su cui è eseguito il Suo sito. Per i profili di rischio avanzati e aziendali, Cloudflare Magic Transit e Spectrum estendono il medesimo filtraggio al traffico non HTTP.
Una rete perimetrale gestita si trova davanti a ogni sito. Assorbe le inondazioni HTTP volumetriche, esegue un WAF L7, applica la limitazione della frequenza per sito e utilizza la gestione dei bot e verifiche gestite per separare i visitatori reali dal traffico automatizzato, il tutto prima che una richiesta raggiunga l'origine.
LiteSpeed Enterprise applica la limitazione delle connessioni e delle richieste con limiti di connessione per IP, Imunify360 esegue un firewall di rete con protezione da attacchi brute-force e filtraggio della reputazione IP, e i limiti dei processi di ingresso di CloudLinux LVE vincolano il numero di richieste simultanee che un singolo sito può tenere aperte.
LVE limita CPU, RAM, IO, IOPS, processi e processi di ingresso individualmente per ogni sito. Un flusso di traffico che supera i livelli superiori viene limitato all'interno dell'ambiente isolato del sito di destinazione, cosicché il carico generato rimane confinato a quel sito invece di propagarsi sull'intero server.
La maggior parte delle interruzioni dell'hosting durante un attacco non è causata dal fatto che l'attacco raggiunga il proprio bersaglio. È causata dal consumo di risorse del bersaglio che priva di risorse qualsiasi altra cosa sul server. Questo è il tipo di guasto che questa architettura è progettata per eliminare.
La richiesta più economica da gestire è quella che non raggiunge mai PHP o MySQL. La nostra cache a due livelli fa sì che gran parte del traffico anomalo a livello applicativo riceva risposta tramite byte statici, senza sovraccaricare il Suo server di origine.
La mitigazione non è un ticket di assistenza. I segnali alimentano un motore di policy che associa ciascuno di essi a un'azione di applicazione, una notifica al cliente e — ove possibile — una correzione automatica, con ogni transizione registrata.
Quando viene attivato un segnale DDoS, il motore delle policy applica la mitigazione Cloudflare e la limitazione di frequenza per sito, potendo inoltre inasprire dinamicamente i limiti LVE di quel sito. Quando il segnale cessa, i limiti vengono nuovamente allentati. Graduale, reversibile e registrato a ogni passaggio.
Se un attacco minaccia il server di origine, il sito passa a uno stato "limitato" (throttled): limiti LVE più restrittivi e limitazione della frequenza delle richieste, con il sito ancora attivo e funzionante. La limitazione si risolve automaticamente non appena la pressione diminuisce; non si tratta di una sospensione.
Al di sotto del motore delle policy, LVE regola nativamente e automaticamente l'utilizzo di CPU, IO e processi per ciascun sito. È la prima linea di difesa sempre attiva, in esecuzione a prescindere dal fatto che il traffico sia già stato classificato o meno come un attacco.
Ogni transizione di applicazione registra il relativo motivo, se è stata automatica o avviata dal personale, e le prove a supporto. Riceverà una notifica su cosa è cambiato e su come risolvere il problema, e ogni azione è impugnabile.
La protezione di base non è facoltativa, poiché un sito attaccato o compromesso minaccia i siti vicini, la reputazione dei nostri server e i nostri intervalli di indirizzi IP. È disponibile una protezione più avanzata per i siti il cui profilo di rischio lo richiede.
Un picco di traffico è spesso un sintomo. La stessa pipeline di segnali che gestisce le inondazioni rileva anche le compromissioni che le producono, consentendo di classificare correttamente un incidente anziché limitarsi ad assorbirlo.
L'obiettivo di progettazione è l'isolamento. Ogni sito opera all'interno della propria gabbia CloudLinux LVE con limiti massimi per CPU, RAM, IO, IOPS, processi e processi di ingresso, una propria vista del file system CageFS e la limitazione del database per singolo sito tramite MySQL Governor. Un sito sotto attacco viene limitato al proprio massimale invece di consumare le risorse dell'intera macchina, e i limiti di connessione per IP di LiteSpeed vincolano la quantità di server web che può occupare. L'isolamento è progettato a livello di kernel, non configurato per singolo cliente.
Il livello di base è incluso in ogni piano: isolamento LVE e CageFS, limitazione delle connessioni e delle richieste LiteSpeed, firewall di rete, WAF proattivo e scansione malware, con assorbimento perimetrale Cloudflare e filtraggio di rete a livello di provider a monte dell'infrastruttura. È incluso perché la protezione della nostra infrastruttura non può essere facoltativa. La gestione avanzata dei bot, livelli di protezione DDoS superiori, regole WAF potenziate e regole firewall dedicate sono componenti aggiuntivi per i siti che ne hanno necessità.
Essere bersaglio di un attacco DDoS comporta la mitigazione tramite Cloudflare unita alla limitazione della frequenza per singolo sito e — solo se l'attacco minaccia l'origine — lo stato 'throttled': limiti LVE più restrittivi, mantenendo il sito attivo e funzionante. Lo stato throttled si ripristina automaticamente non appena la pressione diminuisce. La sospensione è riservata al mancato pagamento o a violazioni confermate e, anche in tal caso, il sito mostra una pagina temporanea personalizzata con il motivo specifico anziché una pagina di errore.
Non per tutto ciò che viene servito dalla cache. LSCache risponde alle richieste di pagine memorizzate nella cache senza invocare PHP o MySQL, e una cache degli oggetti Redis per sito alleggerisce le letture per le pagine realmente dinamiche. Ciò che rimane è limitato dai tetti dei processi LVE e dei processi di ingresso del Suo sito, nonché dalla limitazione del database per sito di MySQL Governor, garantendo che la pressione sul database proveniente da un singolo sito non possa riversarsi sul server. Le pagine del carrello, del checkout, dell'account personale e delle sessioni rimangono non memorizzate nella cache per impostazione predefinita, affinché le misure di hardening non interrompano mai una transazione.
Sì, a livello di rete. La protezione DDoS a livello di provider filtra i flood L3/4 a monte della nostra flotta indipendentemente dal protocollo e, per esigenze avanzate o aziendali, Cloudflare Magic Transit e Spectrum estendono la mitigazione di livello edge al traffico non HTTP.
Ogni transizione di applicazione viene registrata con il relativo motivo, sia essa automatica o avviata dal personale, e con le prove a supporto. Riceverà una notifica su cosa è cambiato e su cosa permette di risolverlo, ogni azione è impugnabile e le azioni con privilegi vengono registrate nel registro di controllo per la Sua traccia di conformità. I segnali vengono aggregati in un unico Abuse Desk invece di essere dispersi tra più strumenti.
Sì. L'hosting Footprint-Free inizia con una prova di 14 giorni senza carta che copre fino a 5 siti — senza dati di pagamento, senza impegno. I piani sono supportati da una garanzia di rimborso di 30 giorni senza obiezioni, migrazioni gratuite e nessun vincolo di fornitore.
Il filtraggio di rete, l'assorbimento perimetrale, la limitazione del server e il contenimento per singolo sito operano dal momento della distribuzione: non c'è nulla da configurare, nulla da attivare durante un incidente. Iniziate con una prova di 14 giorni senza carta, supportata da una garanzia di rimborso di 30 giorni e migrazioni gratuite.
Inizia gratis