[Tutorial de Segurança] Ataques SYN Flood, defesa de cookies SYN e modificação de parâmetros do kernel para Linux/FreeBSD

HackerÉ uma carreira desejável e promissora. Eu aprecio hackers bons e odeio hackers ruins. O chamado hacker mau é o tipo de cara que faz alguém do outro lado fazer hora extra.

    Ataques SYN Flood são um ataque típico de negação de serviço. O chamado ataque de negação de serviço é para alcançar indiretamente o propósito do ataque ao tornar o host ou a rede vítima incapaz de fornecer um bom serviço. Hackers gostam de jogar isso para mostrar que são equilibrados, capazes e corajosos, fazendo o outro lado trabalhar horas extras, mas, na verdade, não é nada.

   1: O que é um ataque SYN Flood?

    Os ataques SYN Flood aproveitam o processo de handshake triplo do protocolo TCP no IPv4. Esse protocolo estipula que, se uma extremidade quiser iniciar uma conexão TCP para a outra extremidade, ela precisa primeiro enviar um pacote TCP SYN (synchronize) para a outra parte, e a outra parte envia um pacote TCP SYN + ACK de volta após recebê-lo, e então o iniciador envia um pacote TCP ACK (ACKnowledge Character) de volta, de modo que os três handshakes terminem.

    No processo acima, há alguns conceitos importantes:

    A fila não está conectada: No protocolo de handshake de três vias, o servidor mantém uma fila não conectada que abre uma entrada para cada pacote SYN do cliente (syn=j) que indica que o servidor recebeu o pacote SYN e emite uma confirmação ao cliente, aguardando o pacote de confirmação do cliente. A conexão identificada por essas entradas está em estado Syn_RECV no servidor, e quando o servidor recebe um pacote de confirmação do cliente, a entrada é deletada e o servidor entra no estado ESTABELECIDO. Em outras palavras, quando o servidor TCP recebe o pacote de requisição TCP SYN, antes de enviar o pacote TCP SYN+ACK de volta ao cliente TCP, o servidor TCP deve primeiro alocar uma área de dados para atender à conexão TCP formada por essa mão. Geralmente, o estado de conexão é quando o pacote SYN é recebido, mas o pacote ACK ainda não foi recebidoConexão semiaberta(Conexão meio aberta)。

    Parâmetro de backlog: Indica o número máximo de filas desconectadas.

    Número de retransmissões SYN-ACK: Após o servidor enviar o pacote SYN-ACK, se o pacote de confirmação do cliente não for recebido, o servidor realiza a primeira retransmissão, espera por um período de tempo e não recebe o pacote de confirmação do cliente, e realiza a segunda retransmissão; se o número de retransmissões exceder o número máximo especificado pelo sistema, o sistema exclui as informações de conexão da fila semi-conexão. Note que o tempo de espera para cada repasse não é necessariamente o mesmo.

    Tempo de sobrevivência semi-conectado: Refere-se ao tempo máximo que uma entrada na fila semi-conexão sobrevive, ou seja, o tempo máximo desde o momento em que o serviço recebe o pacote SYN até o momento em que o pacote é confirmado como inválido, e o valor do tempo de tempo é a soma do tempo máximo de espera para todos os pacotes de retransmissão solicitados. Às vezes também chamamos de tempo de sobrevivência semi-conectado, SYN_RECV tempo de sobrevivência.

    No ataque de inundação SYN mais comum, o atacante envia um grande número de pacotes TCP SYN para a vítima em um curto período de tempo, momento em que o atacante é o cliente TCP e a vítima é o servidor TCP. De acordo com a descrição acima, a vítima atribuiria uma zona de dados específica a cada pacote TCP SYN, desde que os pacotes SYN tivessem endereços de origem diferentes (o que seria fácil para atacantes falsificarem). Isso vai sobrecarregar bastante o sistema de servidor TCP e, eventualmente, fazer com que o sistema não funcione direito.

    2. O princípio dos cookies SYN

    Uma das formas de prevenir efetivamente ataques SYN Flood são os cookies SYN. Motivo D. Cookie SYN. Inventado por J. Bernstain e Eric Schenk.

    Cookies SYN são uma modificação do protocolo TCP de handshake triplo do lado do servidor para prevenir ataques SYN Flood.Seu princípio é:Quando o servidor TCP recebe um pacote TCP SYN e retorna um pacote TCP SYN+ACK, ele não aloca uma área de dados dedicada, mas calcula um valor de cookie com base nesse pacote SYN. Quando um pacote TCP ACK é recebido, o servidor TCP verifica a legitimidade do pacote TCP ACK com base nesse valor de cookie. Se legal, uma área de dados dedicada é alocada para gerenciar futuras conexões TCP.

    Vamos falar sobre como configurar parâmetros do kernel para implementar cookies SYN no Linux e FreeBSD

    Três: Configurações Linux

    Se a configuração do seu servidor não for boa, o número de sockets TIME_WAIT TCP chega a 20.000 ou 30.000, e o servidor pode facilmente ser arrastado até a exaustão. Ao modificar os parâmetros do kernel do Linux, o número de soquetes de TIME_WAIT no servidor pode ser reduzido.

    TIME_WAIT pode ser visualizado com o seguinte comando:

No Linux, como o CentOS, você pode conseguir isso modificando o arquivo /etc/sysctl.conf.

    Adicione as seguintes linhas:

Ilustrar:

net.ipv4.tcp_syncookies = 1 significa que os cookies SYN estão habilitados, o que é um BOOLEANO. Quando o SYN espera a fila transbordar, permita que cookies lidiem com isso, o que pode evitar um pequeno número de ataques SYN, e o padrão é 0, o que significa que está fechado.
net.ipv4.tcp_tw_reuse = 1 significa que o reuso está ativado, o que é um BOOLEANO. Permite reutilizar soquetes TIME-WAIT para novas conexões TCP, com padrão em 0, indicando fechamento;
net.ipv4.tcp_tw_recycle = 1 significa permitir a reciclagem rápida de sockets TIME-WAIT em conexões TCP, que é BOOLEANO, e o padrão é 0, o que significa que está fechado.
net.ipv4.tcp_fin_timeout = 30 significa que, se o socket for fechado por uma solicitação local, esse parâmetro determina por quanto tempo permanecerá no estado FIN-WAIT-2. A unidade é de segundos.
net.ipv4.tcp_keepalive_time = 1200 indica com que frequência o TCP envia mensagens keepalive quando o keepalive é utilizado. O padrão é 2 horas, alterado para 20 minutos. A unidade é de segundos.
net.ipv4.ip_local_port_range = 1024 65000 indica o alcance das portas usadas para conexões externas. O caso padrão é pequeno: 32768 para 61000, alterado para 1024 para 65000.
net.ipv4.tcp_max_syn_backlog = 8192 indica o comprimento da fila SYN, que é 1024 por padrão, e o comprimento da fila aumentada é 8192 para acomodar mais conexões de rede aguardando conexão.
net.ipv4.tcp_max_tw_buckets = 5000 indica o número máximo de soquetes que o sistema mantém ao mesmo tempo TIME_WAIT e, se esse número for ultrapassado, TIME_WAIT soquetes serão imediatamente apagados e uma mensagem de aviso será impressa. O padrão é 180.000, alterado para 5.000. Para servidores como Apache e Nginx, os parâmetros nas linhas anteriores podem reduzir TIME_WAIT o número de sockets, mas para o Squid, o efeito não é bom. Esse parâmetro controla o número máximo de soquetes TIME_WAIT para evitar que o servidor Lula seja arrastado por um grande número de soquetes TIME_WAIT.
net.ipv4.tcp_synack_retries e net.ipv4.tcp_syn_retries definem o número de tentativas SYN.

Execute o seguinte comando para que a configuração entre em vigor:

Se você não quiser modificar /etc/sysctl.conf, também pode usar o comando para isso:

Quarto, configurado sob FreeBSD

    Ponto de vista pessoal de aprendizado do yayu: a defesa contra syn no FreeBSD pode não ser a mesma do Linux, os parâmetros configurados não são exatamente os mesmos, e a configuração e compreensão relevantes podem não estar corretas :)

    Há um no link TCPMSL (vida útil máxima do segmento)O conceito deTempo máximo de geraçãoO valor MSL é tomado por 30 segundos em implementações gerais, e algumas levam 2 minutos. "Desligamento passivo" na máquina de estados TCP: De CLOSE_WAIT a LAST_ACK, existe uma regra da seguinte forma: Quando o TCP realiza um desligamento ativo e envia de volta o último ACK, a conexão deve permanecer no estado TIME_WAIT por duas vezes mais tempo que o MSL. Isso permite que o TCP envie novamente o último ACK caso ele seja perdido (a outra extremidade expira e reenvia o último FIN).

    A existência dessa regra tem como consequência que o link (endereço do cliente, porta e endereço do lado do servidor, porta) nesse endereço não pode ser usado durante esse tempo de 2*MSL. Por exemplo, se fecharmos um link após criá-lo e depois reiniciarmos rapidamente o link, a porta ficará indisponível.

    TIME_WAIT tempo é 2*MSL. Assim, você pode reduzir TIME_WAIT tempo ajustando net.inet.tcp.msl. Para o servidor web, esse valor pode ser ajustado para 7500 ou 2000 (acesse uma web, a página não pode ser flasheada por mais de 4~15 segundos, você pode considerar abrir mão -_-)

    Referência de definição de parâmetro:

No FreeBSD, yayu não viu um comando como "/sbin/sysctl -p" que pudesse tornar o conteúdo de /etc/sysctl.conf eficaz, então ele apenas usou o comando: