Posso fechar uma conexão TCP sem limpeza, para atenuar um ataque de negação de serviço?

Question

Eu trabalho em um serviço da web que pode ser o alvo de um ataque de negação de serviço. Temos algumas mitigações contra ataques ao estilo "inundação de SYN". Mas há outros ataques "no nível do aplicativo" contra nosso serviço, em que um cliente mal-intencionado / corrompido pode instruir repetidamente o serviço da Web a realizar tarefas caras.

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

Um método ingênuo seria encerrar a conexão TCP com close(2) , shutdown(2) ou similar. Mas, em seguida, o cliente pode se reconectar imediatamente (até o limite de conexões / segundo definido para atenuar as inundações de SYN), e essa reconexão é cara para nós devido a handshakes de 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 uma terminação de conexão TCP limpa não faz isso.

No entanto, se nosso processo puder terminar a conexão TCP sem limpeza , o cliente abusivo ficará atrasado por algum tempo antes de se reconectar, fornecendo assim um período de "desativação". Por "terminação impura", quero dizer fechar a conexão TCP (ambas as metades do full-duplex) no lado do servidor, sem enviar nenhum pacote FIN para notificar o cliente de terminação, e sem enviar mais nenhum pacote referente a essa conexão . Isso atrasaria o cliente enquanto o cliente considera a conexão ainda no estado ESTABLISHED (que é de 13 a 30 minutos no Linux).

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

Existe alguma opção no UNIX / Linux para terminação de conexão TCP imediata e impura, como uma mitigação para ataques do DOS?

    

Answer 1

O que você deve procurar é um firewall e fail2ban . O iptables ainda é praticamente padrão para distros do Linux e o fail2ban funcionará com a maioria dos serviços. O que você gostaria de fazer é configurar fail2ban para monitorar um arquivo de log específico usando um padrão específico de regex para saber quando um desses clientes 'problemáticos' está se conectando, e então fail2ban adicionar automaticamente a regra de firewall para descartar ou rejeitar a conexão. O fail2ban é configurável com como deixar a regra de firewall para que você possa bloquear um cliente por 5 minutos ou 5 dias, o que você quiser realmente.

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

No que diz respeito a um ataque do DOS, dependendo de como ele está sendo feito, você pode estar sem sorte com um firewall local e pode ter que obter com seu provedor de upstream rotas negras ou hosts que são conhecidos por serem problemática e causando grandes interrupções nos serviços. Parece que você não está nesse tipo de posição e tem apenas uma possível aplicação na camada de aplicativos, então isso é um exagero.

    

Answer 2

Once our process has identified an abusive client connection, we'd like to reduce our level of service to that client.

Como você já mencionou que há um custo associado para estabelecer uma nova conexão, recomendo que você considere uma abordagem alternativa em vez de encerrar a conexão. Pode ser que você considere limitar o limite dessa conexão a 1 byte por minuto ou algo semelhante. Com essa abordagem, você ainda pode manter os recursos de um invasor ocupado a um custo mínimo ao seu lado. 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 percam o limite de arquivos abertos. Como Andrew mencionou, você também pode considerar usar o fail2ban depois de confirmar que a conexão é do invasor e é seguro bani-la por algumas horas.