Proteção contra DDoS
Inundações são absorvidas na borda, ataques na camada de rede são filtrados a montante, e o que chega ao servidor é contido dentro da própria gaiola em nível de kernel do site de destino. Várias camadas, cada uma realizando uma função diferente, para que um ataque direcionado a um site não se torne uma interrupção para os que estão ao lado dele. Este é o modelo de defesa que construímos para uma plataforma que hospeda mais de 650.000 sites em todo o mundo, e a base opera em todos os planos. Disponibilidade: a limitação de taxa de banco de dados por site está em desenvolvimento ativo e ainda não está disponível. Todo o resto descrito aqui está ativo hoje.
Um ataque de inundação volumétrica, uma inundação de aplicação L7 e um ataque lento de esgotamento de conexão são três problemas diferentes. Nós tratamos cada um deles onde é mais barato e rápido lidar com eles — antes da frota, na borda e dentro da gaiola.
A proteção contra DDoS em nível de provedor filtra ataques de inundação na camada de rede antes do nosso cluster de workers, antes mesmo que esse tráfego consuma uma porta, uma placa de rede (NIC) ou um ciclo de CPU na máquina onde seu site é executado. Para perfis de risco avançados e corporativos, o Cloudflare Magic Transit e o Spectrum estendem essa mesma filtragem ao tráfego não HTTP.
Uma rede de borda gerenciada fica na frente de cada site. Ela absorve ataques volumétricos de HTTP, executa um WAF de camada 7, aplica limitação de taxa por site e usa gerenciamento de bots e desafios gerenciados para separar visitantes reais de tráfego automatizado — tudo antes que uma requisição chegue à origem.
O LiteSpeed Enterprise aplica limitação de conexões e de requisições com limites de conexão por IP, o Imunify360 executa um firewall de rede com proteção contra força bruta e filtragem de reputação de IP, e os limites de processos de entrada do CloudLinux LVE restringem quantas requisições simultâneas um único site pode manter abertas.
O LVE limita o CPU, RAM, IO, IOPS, processos e entry-processes de cada site individualmente. Um pico de tráfego que consiga passar pelas camadas superiores é contido dentro da própria cage do site de destino, de modo que a pressão gerada permaneça restrita a esse site, em vez de se espalhar pelo servidor.
A maioria das quedas de hospedagem durante um ataque não é causada pelo fato de o ataque atingir seu alvo. Elas são causadas pelo consumo de recursos do alvo que esgota todo o resto na máquina. Esse é o modo de falha que esta arquitetura foi projetada para eliminar.
A solicitação mais barata de sobreviver é aquela que nunca toca no PHP ou no MySQL. Nosso cache de duas camadas significa que uma grande parcela de uma inundação na camada de aplicação é respondida por bytes estáticos em vez de pela sua origem realizando trabalho.
A mitigação não é um ticket de suporte. Os sinais alimentam um mecanismo de políticas que mapeia cada um para uma ação de imposição, uma notificação ao cliente e — sempre que possível — uma remediação automática, com cada transição registrada.
Quando um sinal de DDoS é disparado, o motor de políticas aplica a mitigação do Cloudflare e a limitação de taxa por site, podendo ajustar dinamicamente os limites de LVE desse site. Quando o sinal desaparece, os limites relaxam novamente. Gradual, reversível e registrado em cada etapa.
Se um ataque estiver ameaçando a origem, o site entra em um estado 'limitado' — com limites de LVE e de taxa mais restritos, mantendo o site no ar e funcionando. A limitação é revertida automaticamente assim que a pressão diminui; não se trata de uma suspensão.
Abaixo do motor de políticas, o LVE limita o uso de CPU, E/S e processos por site de forma nativa e automática. É a primeira linha de defesa sempre ativa, funcionando independentemente de qualquer classificação prévia do tráfego como ataque.
Cada transição de imposição registra seu motivo, se foi automático ou iniciado pela equipe, e as evidências por trás dela. Você é notificado sobre o que mudou e como resolver isso, e cada ação é passível de recurso.
A proteção básica não é opcional, pois um site atacado ou comprometido ameaça seus vizinhos, a reputação do nosso servidor e nossas faixas de IP. Uma proteção mais robusta existe para os sites cujo perfil de risco exija isso.
Um pico de tráfego costuma ser um sintoma. A mesma pipeline de sinais que lida com enxurradas também detecta os comprometimentos que as produzem, permitindo que um incidente seja classificado corretamente em vez de apenas absorvido.
O objetivo de design é o isolamento. Cada site é executado dentro de sua própria gaiola CloudLinux LVE com limites de CPU, RAM, IO, IOPS, processos e processos de entrada, sua própria visualização de sistema de arquivos CageFS e limitação de banco de dados por site via MySQL Governor. Um site atacado é limitado em seu próprio teto em vez de consumir toda a máquina, e os limites de conexão por IP do LiteSpeed controlam quanto do servidor web ele pode ocupar. O isolamento é projetado no nível do kernel, não configurado por cliente.
A base de segurança está incluída em todos os planos: isolamento LVE e CageFS, limitação de conexões e requisições do LiteSpeed, um firewall de rede, WAF proativo e verificação de malware, com absorção de borda do Cloudflare e filtragem de rede em nível de provedor diante da frota. Nós a incluímos porque não podemos deixar a proteção de nossa própria frota como opcional. Gerenciamento avançado de bots, camadas de DDoS mais altas, regras de WAF aprimoradas e regras de firewall dedicadas são complementos para sites que precisam deles.
Ser um alvo de DDoS resulta na mitigação do Cloudflare combinada com limitação de taxa por site e — apenas se o ataque estiver ameaçando a origem — no estado 'throttled': limites de LVE mais rígidos, com o site ainda ativo e funcionando. O estado throttled se recupera automaticamente assim que a pressão diminui. A suspensão é reservada para falta de pagamento ou abuso confirmado e, mesmo nesses casos, o site exibe uma página de retenção personalizada e específica para o motivo, em vez de uma página quebrada.
Nada do que é servido a partir do cache. O LSCache atende a solicitações de páginas em cache sem invocar o PHP ou o MySQL, e um cache de objetos Redis por site descarrega leituras para páginas genuinamente dinâmicas. O que resta é limitado pelos limites de processos LVE e de processos de entrada do seu site e pela limitação de banco de dados por site do MySQL Governor, de modo que a pressão no banco de dados de um site não pode transbordar para o servidor. As páginas de carrinho, finalização de compra, minha conta e sessão permanecem sem cache por padrão para que o endurecimento nunca interrompa uma transação.
Sim, na camada de rede. A proteção contra DDoS em nível de provedor filtra ataques de inundação L3/4 antes de chegarem à nossa infraestrutura, independentemente do protocolo, e para requisitos avançados ou empresariais, o Cloudflare Magic Transit e o Spectrum estendem a mitigação de nível de borda para tráfego não HTTP.
Cada transição de penalidade é registrada com seu motivo, se foi automática ou iniciada pela equipe, e as evidências por trás dela. Você é notificado sobre o que mudou e o que resolve isso, cada ação pode ser recorrida, e ações privilegiadas são registradas em log de auditoria para a sua própria trilha de conformidade. Os sinais são agregados em uma única Central de Abuso, em vez de ficarem dispersos entre ferramentas.
Sim. O Footprint-Free Hosting começa com um teste de 14 dias sem cartão, cobrindo até 5 sites — sem dados de pagamento e sem compromisso. Os planos contam com uma garantia de reembolso sem complicações de 30 dias, migrações gratuitas e sem fidelização a fornecedores.
Filtragem de rede, absorção no edge, limitação de taxa no servidor e contenção por site funcionam desde o momento do seu deploy — nada para configurar, nada para ativar no meio de um incidente. Comece com um teste de 14 dias sem cartão de crédito, respaldado por uma garantia de reembolso de 30 dias e migrações gratuitas.
Comece grátis