Posso fechar uma conexão TCP de maneira imprópria para mitigar um ataque de negação de serviço?

Posso fechar uma conexão TCP de maneira imprópria para mitigar um ataque de negação de serviço?

Trabalho em um serviço web que pode ser alvo de um ataque de negação de serviço. Implementamos algumas mitigações contra ataques do tipo "inundação SYN". Mas existem outros ataques no “nível da aplicação” contra o nosso serviço, onde um cliente mal-intencionado/quebrado pode instruir repetidamente o serviço web para executar tarefas caras.

Podemos identificar esses clientes abusivos na camada de aplicação, ou seja, em nossos processos de servidor. Depois que nosso processo identificar uma conexão abusiva de cliente, gostaríamos de reduzir nosso nível de serviço a esse cliente.

Um método ingênuo seria encerrar a conexão TCP com close(2), shutdown(2)ou similar. Mas então o cliente pode se reconectar imediatamente (até o limite de conexões/segundo definido para mitigar inundações de SYN), e essa reconexão é cara para nós devido aos handshakes TLS e outros custos de configuração de conexão. Estamos procurando uma maneira de impedir que o cliente interaja com nosso serviço por um tempo, mas um encerramento limpo da conexão TCP não faz isso.

No entanto, se nosso processo conseguisse encerrar a conexão TCPimpuro, o cliente abusivo demoraria algum tempo antes de se reconectar, proporcionando assim um período de "reflexão". Por "terminação suja", quero dizer fechar a conexão TCP (ambas as metades do full-duplex) no lado do servidor, sem enviar nenhum FINpacote para notificar o cliente sobre o encerramento e sem enviar mais pacotes referentes a essa conexão. Isso atrasaria o cliente enquanto ele considera a conexão ainda no ESTABLISHEDestado (que é de 13 a 30 minutos no Linux).

No entanto, não consigo ver nenhuma maneira de um processo UNIX/Linux encerrar uma conexão TCP de maneira imprópria. close(2), shutdown(2)e semelhantes parecem encerrar a conexão de forma limpa e não fornecem opções para um encerramento impuro.

Existe alguma opção no UNIX/Linux para encerramento imediato e impuro da conexão TCP, como uma mitigação para ataques DOS?

Responder1

O que você deve procurar é um firewall e um arquivo fail2ban. iptablesainda é praticamente padrão para distribuições Linux e fail2banfuncionará com a maioria dos serviços. O que você gostaria de fazer é configurar fail2banpara monitorar um arquivo de log específico usando um padrão regex específico para saber quando um desses clientes 'problemáticos' está se conectando e, em seguida, adicionar fail2banautomaticamente a regra de firewall para descartar ou rejeitar a conexão. fail2ban é configurável para deixar a regra de firewall para que você possa bloquear um cliente por 5 minutos ou 5 dias, o que você realmente quiser.

Você também pode usar um firewall de aplicativo da web (WAF) para esse tipo de coisa.

No que diz respeito a um ataque DOS, dependendo de como ele está sendo feito, você pode estar sem sorte com um firewall local e pode ter que entrar em contato com seu provedor upstream para rotas ou hosts de buraco negro que são conhecidos por serem problemáticos e causando grande interrupção do serviço. Parece que você não está nesse tipo de posição e apenas tem possíveis problemas na camada de aplicativo para solucionar, então isso é um exagero.

Responder2

Depois que nosso processo identificar uma conexão abusiva de cliente, gostaríamos de reduzir nosso nível de serviço a esse cliente.

Como você já mencionou que há custos associados para estabelecer uma nova conexão, recomendo que você considere uma abordagem alternativa do que encerrar a conexão. Pode ser que você considere limitar a taxa dessa conexão a 1 byte por minuto ou algo semelhante. Com essa abordagem, você ainda pode manter os recursos de um invasor ocupados com um custo mínimo para você. Se você tiver mais tempo e quiser ser criativo, redirecione todas essas conexões para um servidor em seu ambiente para que outros servidores não desperdicem seu limite de arquivos abertos. Como Andrew mencionou, você também pode considerar o uso do fail2ban depois de confirmar que a conexão é do invasor e é seguro bani-la por algumas horas.

informação relacionada