Maneira correta de lidar com ameaças de segurança ao servidor Web dentro do orçamento [closed]

Question

Durante a nossa análise de segurança anual, lembrei-me de um incidente no início deste ano em que recebemos uma ameaça ao servidor Web das nossas organizações. Foi sobre uma política da organização e ameaçou DDoS nosso site. Felizmente, nada de mal aconteceu e acabou por ser uma ameaça vazia. No entanto, ainda notificamos imediatamente o CIO, CSO e 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 a polícia local.

Mesmo que a nossa resposta tenha sido suficiente para uma ameaça vazia, isso está me fazendo perceber como o planejamento de ataque foi pouco afetado pelo aplicativo da web. No momento, a configuração é:

• Um Linode VPS que não está por trás do firewall corporativo (há uma longa história por trás disso que não vale a pena explicar)
• um banco de dados do PostgreSQL no mesmo servidor que permite somente conexões locais
• um servidor Nginx que atualmente seguimos as práticas recomendadas para proteger [ 1 ]
• acesso SSH que estamos migrando para a autenticação de certificado
• Um VPS de backup que possui todas as configurações do servidor mais recentes e precisa apenas da versão mais recente do código enviado e das configurações do banco de dados migradas (agora usado como servidor de teste, mas também previsto como uma opção de redundância geográfica)

Eu acho que minha pergunta provavelmente pode ser resumida a quais outras etapas devo tomar para bloquear meu servidor e proteger contra DDoS? Gostaríamos muito de usar Cloudflare Business com a proteção contra DDoS, mas nem sempre precisamos disso e US $ 200 por mês é um pouco caro para a organização. Eu preciso disso? Existe uma solução que permita proteção temporária contra DDoS? Se não, qual é a melhor maneira de manter a estabilidade durante / após um ataque? Finalmente, que registro deve ser implementado para que possamos ajudar a aplicação da lei no caso de ocorrer um ataque?

    

Answer 1

what other steps should I take to lock down my server as well as protect from DDoS?

1. Firewall de todas as portas e protocolos que não são usados. Limite o acesso a apenas IPs confiáveis, quando aplicável e possível.
2. Aplicar todos os patches de segurança e atualizações em tempo hábil
3. Implementar um monitor de rede que possa alertar sobre explosões suspeitas de atividade

$200 a month is a bit steep for the organization. Do I even need this?

Não. Não até que agregue valor e se torne um must have.

Is there a solution that allows temporary DDoS protection?

Sim. Eles podem envolver uma quantidade razoável de investimento inicial em tempo para resolver as complicações da implementação do serviço DDoS. link é um desses serviços sob demanda.

If not, what is the best way to maintain stability during/after an attack?

Apenas sente aí e pegue. Essa é a natureza do DDoS. Você pode tentar proteger os IPs, mas se o ataque for realmente distribuído ... bem, é como lutar contra um incêndio com uma pistola de água.

Finally, what logging should be implemented so that we can assist law enforcement in the event an attack occurs?

Manter registros de IPs e registros de data e hora de origem e quaisquer outros dados forenses relevantes. Por exemplo, se for um servidor da Web, tente e registre o agente do usuário, os recursos solicitados. As taxas de tráfego, como pacotes por segundo e número de solicitações por segundo, são úteis.

O DDoS resume-se à análise matemática. Se alguém está tentando extorquir você, eles estão apostando que podem atrapalhar o seu negócio o suficiente para forçá-lo a pagar dinheiro para protegê-lo. A escala é um fator, é mais fácil derrubar operadores menores, mas eles podem pagar menos. Se você receber uma ameaça por email, o melhor curso de ação é ignorá-la. São necessários recursos significativos de botnets para iniciar e sustentar ataques de DDoS - eles não podem simplesmente atacar todos como spammers. As chances são de que eles estão apenas fazendo uma grande explosão de phishing procurando alvos fáceis para intimidar. Devido à natureza da besta DDoS, as vítimas são bastante indefesas, a menos que possam implementar um esquema sofisticado de prevenção de filtragem de pacotes ou que tenham orçamento para contratar serviços externos.

    

Answer 2

A resposta do inetplumber é ótima.

Gostaria de acrescentar que outra opção é configurar seu aplicativo para escalonar, para que você possa lidar com um ataque maior sem afetar seu usuário. Você pode configurar uma Virtual Private Cloud (VPC) no Amazon AWS, por exemplo, com seu servidor PostgreSQL acessível somente de dentro do seu 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 você já estiver configurado), tornando-o um alvo muito mais difícil. Você só precisaria pagar por esses servidores durante as horas em que estava realmente sob ataque. Quando você não estava sob ataque, você só precisaria pagar pelo seu servidor da Web e um servidor de banco de dados.

A parte difícil estaria sendo configurada, e certamente é um pouco mais complexa que sua configuração atual. Configurar para escalar rapidamente exigiria ainda mais trabalho. Mas se você está procurando algo que você poderia fazer para planejar (especialmente se, devido a outros problemas, você acha que pode ser um alvo no futuro), seria isso.

    

Answer 3

what other steps should I take to lock down my server as well as protect from DDoS?

4. se o seu webapp não for interativo e exibir apenas conteúdo: use o nginx + proxy-cache com um tempo de cache curto (normalmente, 1 a 5 minutos está ok). isso aumenta muito o desempenho e força um invasor a alocar mais recursos

5. configure um firewall restrito que filtre tudo o que é necessário IN e OUT configurando INPUT / OUTPUT / FORWARD-Policy para DROP; não se esqueça de registrar todas as tentativas de conexão de saída (exceto para a porta UPD 53:)

6. se você não puder 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

7. adicionalmente, use fail2ban / denyhosts para proteger o ssh de ataques de força bruta

8. se você tiver recursos de administrador: use o OSSEC e um leve WAF (há naxsi para nginx, leve e não um PITA como mod_security), mas você precisará de alguém para configurar e manter essas instalações

9. implemente backups e use seu servidor em espera como um destino de backup

10. mantenha seu webapp-code atualizado; Se você usar um projeto de código aberto, inscreva-se na lista de discussão de segurança.

11. tente evitar o software que é conhecido por ter muitas vulnerabilidades

12. se você usar admin-login e / ou managament-webapps: estabeleça o basic-auth para esses logins + ssl (o certificado auto-assinado é OK).

13. use o ssh-tunneling whevener em vez de abrir portas, por exemplo para desenvolvimento

If not, what is the best way to maintain stability during/after an attack

1. mantenha a calma
2. tenha alguém com experiência em mãos para esse caso
3. tenha alguns planos de emergência prontos

a coisa mais importante que você já fez: pensar nisso (e possíveis contramedidas) antes que isso aconteça.