Você está enfrentando um ataque de negação de serviço. Se você vir tráfego proveniente de várias redes (IPs diferentes em sub-redes diferentes), terá uma negação de serviço distribuída (DDoS); se tudo vier do mesmo lugar, você tem um DoS antigo e simples. Pode ser útil verificar se você é capaz; use netstat para verificar. Isso pode ser difícil de fazer, no entanto.
A negação de serviço geralmente se enquadra em duas categorias: baseada no tráfego e baseada na carga. O último item (com o serviço de travamento) é um DoS baseado em exploração e é bem diferente.
Se você está tentando identificar que tipo de ataque está acontecendo, convém capturar algum tráfego (usando wireshark, tcpdump ou libpcap). Se possível, você deve estar ciente de que provavelmente capturará bastante tráfego.
Na maioria das vezes, eles vêm de botnets (redes de hosts comprometidos sob o controle central de algum invasor, cuja oferta eles farão). Essa é uma boa maneira de o invasor (muito barato) adquirir a largura de banda upstream de vários hosts diferentes em redes diferentes para atacá-lo, enquanto cobre suas faixas. O canhão de íon de baixa órbita é um exemplo de botnet (apesar de ser voluntário em vez de derivado de malware); Zeus é mais típico.
Baseado no tráfego
Se você estiver sob um DoS baseado em tráfego, verá que há tanto tráfego chegando ao seu servidor que sua conexão com a Internet está completamente saturada. Há uma alta taxa de perda de pacotes ao executar ping em seu servidor de outro lugar e (dependendo dos métodos de roteamento em uso) às vezes você também vê latência muito alta (o ping é alto). Esse tipo de ataque geralmente é um DDoS.
Embora seja um ataque realmente "alto" e seja óbvio o que está acontecendo, é difícil para um administrador de servidores atenuar (e basicamente impossível para um usuário de hospedagem compartilhada atenuar). Você vai precisar de ajuda do seu ISP; informe-os de que você está sob um DDoS e eles poderão ajudar.
No entanto, a maioria dos ISPs e provedores de transporte público realizará proativamente o que está acontecendo e publicará uma rota blackhole para o seu servidor. O que isso significa é que eles publicam uma rota para o servidor com o menor custo possível, via 0.0.0.0: eles tornam o tráfego no servidor não mais roteável na Internet. Essas rotas são geralmente / 32s e, eventualmente, são removidas. Isso não ajuda em nada; o objetivo é proteger a rede do ISP do dilúvio. Durante esse período, seu servidor perderá efetivamente o acesso à Internet.
A única maneira de o seu ISP (ou você, se você tiver seu próprio AS) ajudar é se eles estiverem usando shapers de tráfego inteligentes que podem detectar e limitar o tráfego provável de DDoS. Nem todo mundo tem essa tecnologia. No entanto, se o tráfego vier de uma ou duas redes ou um host, eles também poderão bloquear o tráfego à sua frente.
Em suma, há muito pouco que você pode fazer sobre esse problema. A melhor solução a longo prazo é hospedar seus serviços em muitos locais diferentes da Internet, que precisariam ser DDoSed individual e simultaneamente, tornando o DDoS muito mais caro. As estratégias para isso dependem do serviço que você precisa proteger; O DNS pode ser protegido com vários servidores de nomes autoritativos, SMTP com registros MX de backup e trocadores de correio e HTTP com DNS round-robin ou hospedagem múltipla (mas, de qualquer maneira, alguma degradação pode ser perceptível).
Os balanceadores de carga raramente são uma solução eficaz para esse problema, porque o próprio balanceador de carga está sujeito ao mesmo problema e apenas cria um gargalo. IPTables ou outras regras de firewall não ajudarão, porque o problema é que seu canal está saturado. Depois que as conexões são vistas pelo seu firewall, já é tarde demais ; a largura de banda no seu site foi consumida. Não importa o que você faz com as conexões; o ataque é atenuado ou finalizado quando a quantidade de tráfego recebido volta ao normal.
Se você puder fazer isso, considere usar uma rede de distribuição de conteúdo (CDN) como Akamai, Limelight e CDN77 ou use um serviço de lavagem de DDoS como CloudFlare ou Prolexic. Esses serviços tomam medidas ativas para mitigar esses tipos de ataques e também têm tanta largura de banda disponível em tantos locais diferentes que geralmente não é possível inundá-los.
Se você decidir usar o CloudFlare (ou qualquer outro CDN / proxy), lembre-se de ocultar o IP do seu servidor. Se um invasor descobrir o IP, ele poderá novamente fazer DDoS diretamente no servidor, ignorando o CloudFlare. Para ocultar o IP, seu servidor nunca deve se comunicar diretamente com outros servidores / usuários, a menos que sejam seguros. Por exemplo, seu servidor não deve enviar emails diretamente aos usuários. Isso não se aplica se você hospedar todo o seu conteúdo na CDN e não tiver um servidor próprio.
Além disso, alguns provedores de hospedagem e VPS são melhores para mitigar esses ataques do que outros. Em geral, quanto maiores, melhores serão; um provedor muito bem parecido e com muita largura de banda será naturalmente mais resiliente, e um provedor com uma equipe de operações de rede ativa e com equipe completa poderá reagir mais rapidamente.
Baseado em carga
Quando você está enfrentando um DDoS baseado em carga, percebe que a média de carga é anormalmente alta (ou CPU, RAM ou uso de disco, dependendo da plataforma e dos detalhes). Embora o servidor não pareça estar fazendo algo útil, ele está muito ocupado. Freqüentemente, haverá grandes quantidades de entradas nos logs, indicando condições incomuns. Geralmente, isso vem de muitos lugares diferentes e é um DDoS, mas esse não é necessariamente o caso. Nem precisa haver muitos hosts diferentes .
Esse ataque é baseado em fazer com que seu serviço faça muitas coisas caras. Isso pode ser algo como abrir um número gigantesco de conexões TCP e forçar você a manter o estado para elas, ou fazer upload de arquivos excessivamente grandes ou numerosos para o seu serviço, ou talvez fazer pesquisas muito caras ou realmente fazer qualquer coisa que seja cara de manusear. O tráfego está dentro dos limites do que você planejou e pode assumir, mas os tipos de solicitações feitas são muito caros para lidar com muitos deles .
Em primeiro lugar, que esse tipo de ataque é possível geralmente indica um problema ou bug de configuraçãoem seu serviço. Por exemplo, você pode ter o log excessivamente detalhado ativado e pode estar armazenando logs em algo que é muito lento para gravar. Se alguém percebe isso e faz muitas coisas que fazem com que você grave grandes quantidades de logs no disco, o servidor fica lento. Seu software também pode estar fazendo algo extremamente ineficiente para certos casos de entrada; as causas são tão numerosas quanto os programas, mas dois exemplos seriam uma situação que faz com que seu serviço não feche uma sessão que, de outra forma, foi concluída e uma situação que faz com que ele gere um processo filho e o deixe. Se você acabar com dezenas de milhares de conexões abertas com o estado para acompanhar, ou dezenas de milhares de processos filhos, terá problemas.
A primeira coisa que você pode fazer é usar um firewall para eliminar o tráfego . Isso nem sempre é possível, mas se houver uma característica que você possa encontrar no tráfego de entrada (o tcpdump pode ser bom para isso, se o tráfego estiver fraco), você pode soltá-lo no firewall e isso não causará mais problemas. A outra coisa a fazer é corrigir o bug em seu serviço (entre em contato com o fornecedor e esteja preparado para uma longa experiência de suporte).
No entanto, se for um problema de configuração, comece por aí . Reduza o log dos sistemas de produção para um nível razoável (dependendo do programa, esse geralmente é o padrão e geralmente envolve garantir que os níveis de log "de depuração" e "detalhado" estejam desativados; se tudo o que um usuário fizer estiver logado exatamente e detalhes, seu registro é muito detalhado). Além disso, verifique o processo filho e os limites de solicitação , possivelmente estrangule solicitações de entrada, conexões por IP e o número de processos filhos permitidos, conforme aplicável.
Escusado será dizer que quanto melhor configurado e provisionado o servidor, mais difícil será esse tipo de ataque. Evite ser mesquinho com RAM e CPU em particular. Garanta que suas conexões com coisas como bancos de dados back-end e armazenamento em disco sejam rápidas e confiáveis.
Baseado em exploração
Se o seu serviço travar misteriosamente extremamente rapidamente após a ativação, principalmente se você puder estabelecer um padrão de solicitações que precedem a falha e a solicitação for atípica ou não corresponder aos padrões de uso esperados, você poderá estar enfrentando um DoS baseado em exploração. Isso pode vir de apenas um host (com praticamente qualquer tipo de conexão à Internet) ou de vários hosts.
Isso é semelhante a um DoS baseado em carga em muitos aspectos e tem basicamente as mesmas causas e atenuações. A diferença é apenas que, nesse caso, o bug não causa desperdício no servidor, mas morre. O invasor geralmente está explorando uma vulnerabilidade de falha remota, como entrada ilegível que causa uma referência nula ou algo em seu serviço.
Lide com isso da mesma forma que um ataque de acesso remoto não autorizado. Firewall contra os hosts de origem e o tipo de tráfego, se eles puderem ser fixados. Use a validação de proxies reversos, se aplicável. Reúna evidências forenses (tente capturar parte do tráfego), registre um tíquete de bug com o fornecedor e considere registrar uma queixa de abuso (ou queixa legal) contra a origem também.
Esses ataques são razoavelmente baratos de montar, se for possível encontrar uma exploração, e eles podem ser muito potentes, mas também relativamente fáceis de rastrear e parar. No entanto, técnicas úteis contra DDoS baseado em tráfego geralmente são inúteis contra DoS baseado em exploração.