Durante nossa revisão anual de segurança, lembrei-me de um incidente no início deste ano em que recebemos uma ameaça ao servidor web de nossa organização. Foi por causa de uma política da organização e ameaçou DDoS em nosso site. Felizmente, nada de ruim aconteceu e acabou sendo uma ameaça vazia. No entanto, ainda notificamos imediatamente o CIO, o CSO e o CEO e nosso provedor de hospedagem, que aplaudiram nossa resposta. Devido à natureza da nossa organização (na educação), a resposta preventiva envolveu muitas pessoas, incluindo a coordenação com as autoridades locais.
Mesmo que nossa resposta tenha sido suficiente para uma ameaça vazia, isso me fez perceber quão pouco planejamento de ataque o aplicativo da web sofreu. No momento a configuração é:
- Um Linode VPS que não está atrás do firewall empresarial (há uma longa história por trás disso que não vale a pena explicar)
- um banco de dados PostgreSQL no mesmo servidor que permite apenas conexões locais
- um servidor Nginx que atualmente estamos seguindo as práticas recomendadas para proteger [1]
- Acesso SSH que estamos migrando para autenticação de certificado
- Um VPS de backup que possui todas as configurações de servidor mais recentes e só precisa da versão mais recente do código enviado e das configurações do banco de dados migradas (no momento usado como servidor de teste, mas também concebido como uma opção de georedundância)
Acho que minha pergunta provavelmente pode ser resumida em quais outras etapas devo seguir para bloquear meu servidor e também protegê-lo contra DDoS? Gostaríamos muito de usarNegócios Cloudflarecom sua proteção DDoS, mas nem sempre precisamos dela e US$ 200 por mês é um pouco caro para a organização. Eu preciso mesmo disso? Existe uma solução que permite proteção temporária contra DDoS? Caso contrário, qual é a melhor maneira de manter a estabilidade durante/após um ataque? Finalmente, que tipo de registro deve ser implementado para que possamos ajudar as autoridades policiais no caso de ocorrer um ataque?
Responder1
que outras etapas devo seguir para bloquear meu servidor e protegê-lo contra DDoS?
- Firewall de todas as portas e protocolos que não são utilizados. Limite o acesso apenas a IPs confiáveis, quando aplicável e possível.
- Aplique todos os patches e atualizações de segurança em tempo hábil
- Implemente um monitor de rede que possa alertar sobre surtos de atividades suspeitas
US$ 200 por mês é um pouco caro para a organização. Eu preciso mesmo disso?
Não. Não até que agregue valor e se torne um item obrigatório.
Existe uma solução que permite proteção temporária contra DDoS?
Sim. Eles podem envolver uma quantidade razoável de investimento inicial para resolver as complicações da implementação de seu serviço DDoS. http://www.blacklotus.net/protect/emergency-ddos-protectioné um desses serviços sob demanda.
Caso contrário, qual é a melhor maneira de manter a estabilidade durante/após um ataque?
Apenas sente aí e pegue. Essa é a natureza do DDoS. Você pode tentar proteger os IPs com firewall, mas se o ataque for realmente distribuído... bem, isso é como combater um incêndio florestal com uma pistola de água.
Finalmente, que tipo de registro deve ser implementado para que possamos ajudar as autoridades policiais no caso de ocorrer um ataque?
Mantenha registros de IPs de origem de entrada e carimbos de data/hora e quaisquer outros dados forenses relevantes. Por exemplo, se for um servidor web, tente registrar o agente do usuário e os recursos solicitados. As taxas de tráfego, como pacotes por segundo, e o número de solicitações por segundo são úteis.
DDoS se resume a análise matemática. Se alguém está tentando extorquir você, está apostando que pode atrapalhar seus negócios o suficiente para forçá-lo a pagar dinheiro de proteção para evitá-lo. A escala é um fator, é mais fácil derrubar operadoras menores, mas elas conseguem pagar menos. Se você receber uma ameaça por e-mail, a melhor ação é ignorá-la. São necessários recursos significativos de botnet para iniciar e sustentar ataques DDoS – eles não podem simplesmente atacar todo mundo como spammers. Provavelmente, eles estão apenas realizando uma grande explosão de phishing em busca de alvos fáceis de intimidar. Devido à natureza da fera DDoS, as vítimas ficam bastante indefesas, a menos que possam implantar um esquema sofisticado de prevenção de filtragem de pacotes ou tenham orçamento para contratar serviços externos.
Responder2
a resposta do inetplumber é ótima.
Eu acrescentaria que outra opção é configurar seu aplicativo em escala, para que você possa lidar com um ataque maior sem impactar seu usuário. Você pode configurar uma nuvem privada virtual (VPC) no Amazon AWS, por exemplo, com seu servidor PostgreSQL acessível apenas de dentro de sua VPC. Você pode configurar um front-end de balanceador de carga para distribuir a carga entre vários servidores.
A vantagem de fazer isso dessa forma é que você pode escalar rapidamente até 100 (ou mais) servidores sem investimento inicial e muito rapidamente (se já estiver configurado), tornando-se um alvo muito mais difícil. Você só precisaria pagar por esses servidores durante as horas em que estivesse realmente sob ataque. Quando você não estava sob ataque, você só precisaria pagar por um servidor web e um servidor de banco de dados.
A parte difícil seria configurar e certamente é um pouco mais complexo do que a configuração atual. A preparação para uma expansão rápida exigiria ainda mais trabalho. Mas se você está procurando algo que possa fazer para planejar (especialmente se, devido a outras questões, você acha que pode ser um alvo no futuro), é isso.
Responder3
que outras etapas devo seguir para bloquear meu servidor e protegê-lo contra DDoS?
se o seu webapp não for interativo e apenas exibir conteúdo: use nginx + proxy-cache com um tempo de cache curto (geralmente de 1 a 5 minutos é aceitável). isso aumenta muito o desempenho e força um invasor a alocar mais recursos
configure um firewall restrito que filtre tudo o que for desnecessárioDentro e foradefinindo a política INPUT/OUTPUT/FORWARD como DROP; certifique-se de registrar todas as tentativas de conexão de saída (exceto para a porta UPD 53 :)
se você não pode restringir o SSH a um ip de gerenciamento estático, use uma porta alta alternativa como 22222, isso evitará muitos "olá mcfyl - alguém aí" - aldravas
além disso, use fail2ban/denyhosts para proteger o ssh de ataques de força bruta
se você tiver recursos administrativos: use OSSEC e um WAF leve (há naxsi para nginx, leve e não tão PITA como mod_security), mas você precisará de alguém para configurar e manter tais instalações
implemente backups e use seu servidor standby como destino de backup
mantenha seu código do webapp atualizado; se você usa um projeto de código aberto, inscreva-se na lista de discussão de segurança.
tente evitar software que é conhecido por ter muitas vulnerabilidades
se você usar admin-login e/ou managament-webapps: estabeleça autenticação básica para esses logins + SSL (certificado autoassinado está OK).
use o tunelamento ssh sempre que puder, em vez de abrir portas, por exemplo, para desenvolvimento
Caso contrário, qual é a melhor maneira de manter a estabilidade durante/após um ataque
- fique calmo
- tenha alguém com experiência disponível para esse caso
- tenha alguns planos de emergência prontos
a coisa mais importante que você já fez: pensar nisso (e possíveis contramedidas) antes que aconteça.