“Possível inundação de SYN” no log, apesar do baixo número de conexões SYN_RECV

Question

Recentemente, tivemos um servidor apache que estava respondendo muito lentamente devido a inundações de SYN. A solução para isso era ativar tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf ).

Postei uma pergunta sobre este aqui se você quer mais fundo.

Depois de ativar os syncookies, começamos a ver a seguinte mensagem em / var / log / messages aproximadamente a cada 60 segundos:

[84440.731929] possible SYN flooding on port 80. Sending cookies.

Vinko Vrsalovic me informou que isso significa que o backlog syn está ficando cheio, então eu aumentei tcp_max_syn_backlog para 4096. Em algum momento eu reduzi tcp_synack_retries para 3 (abaixo do padrão de 5) emitindo sysctl -w net.ipv4.tcp_synack_retries=3 . Depois disso, a frequência pareceu diminuir, com o intervalo das mensagens variando entre 60 e 180 segundos.

Em seguida, emiti sysctl -w net.ipv4.tcp_max_syn_backlog=65536 , mas ainda estou recebendo a mensagem no log.

Ao longo de tudo isso, eu tenho assistido o número de conexões no estado SYN_RECV (executando watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l' ), e ele nunca vai além de cerca de 240, muito mais baixo que o tamanho do backlog. Ainda tenho um servidor Red Hat que paira em torno de 512 (limite neste servidor é o padrão de 1024).

Existem outras configurações de TCP que limitam o tamanho do backlog ou estou latindo na árvore errada? O número de conexões SYN_RECV em netstat -tuna deve ser correlacionado ao tamanho do backlog?

Atualizar

Como melhor eu posso dizer que estou lidando com conexões legítimas aqui, netstat -tuna|wc -l cerca de 5000. Eu tenho pesquisado isso hoje e descobri este post de um funcionário do last.fm, que tem sido bastante útil.

Eu também descobri que o tcp_max_syn_backlog não tem efeito quando os syncookies são habilitados (conforme este link )

Então, como próximo passo, eu configurei o seguinte em sysctl.conf:

net.ipv4.tcp_syn_retries = 3
        # default=5
net.ipv4.tcp_synack_retries = 3
        # default=5
net.ipv4.tcp_max_syn_backlog = 65536
        # default=1024
net.core.wmem_max = 8388608
        # default=124928
net.core.rmem_max = 8388608
        # default=131071
net.core.somaxconn = 512
        # default = 128
net.core.optmem_max = 81920
        # default = 20480

Depois, configurei meu teste de tempo de resposta, executei sysctl -p e desativei syncookies em sysctl -w net.ipv4.tcp_syncookies=0 .

Depois de fazer isso, o número de conexões no estado SYN_RECV ainda permaneceu por volta de 220-250, mas as conexões começaram a atrasar novamente. Uma vez que notei esses atrasos, reativei os syncookies e os atrasos pararam.

Eu acredito que o que eu estava vendo ainda era uma melhoria em relação ao estado inicial, no entanto, algumas solicitações ainda estavam atrasadas, o que é muito pior do que ter syncookies habilitados. Então, parece que eu estou preso com eles habilitado até que possamos obter mais alguns servidores on-line para lidar com a carga. Mesmo assim, não tenho certeza se vejo um motivo válido para desativá-los novamente, já que eles só são enviados (aparentemente) quando os buffers do servidor ficam cheios.

Mas o backlog syn não parece estar cheio com apenas ~ 250 conexões no estado SYN_RECV! É possível que a mensagem de inundação de SYN seja um arenque vermelho e seja algo diferente do syn_backlog que está sendo preenchido?

Se alguém tiver outras opções de ajuste que eu ainda não tenha experimentado, ficaria mais do que feliz em testá-las, mas estou começando a me perguntar se a configuração syn_backlog não está sendo aplicada corretamente por algum motivo.

    

Answer 1

Então, essa é uma pergunta interessante.

Inicialmente, fiquei surpreso que você viu qualquer conexões no estado SYN_RECV com os cookies SYN habilitados. A beleza dos cookies SYN é que você pode participar sem estados do handshake de 3 vias TCP como um servidor usando criptografia, então eu esperaria que o servidor não representasse conexões abertas pela metade porque esse seria o mesmo estado que não é não sendo mantido.

Na verdade, uma olhada rápida na fonte (tcp_ipv4.c) mostra informações interessantes sobre como o kernel implementa cookies SYN. Essencialmente, apesar de ativá-los, o kernel se comporta normalmente até que sua fila de conexões pendentes esteja cheia. Isso explica sua lista existente de conexões no estado SYN_RECV.

Somente quando a fila de conexões pendentes está cheia, E outro pacote SYN (tentativa de conexão) é recebido, E foi mais de um minuto desde a última mensagem de aviso, o kernel enviou a mensagem de aviso que você viu (" enviando cookies "). Os cookies SYN são enviados mesmo quando a mensagem de aviso não é; a mensagem de aviso é apenas para avisar que a questão não foi embora.

Em outras palavras, se você desativar os cookies SYN, a mensagem irá embora. Isso só funcionará se você não estiver mais sendo inundado por SYN.

Para abordar algumas das outras coisas que você fez:

• %código%:
  • Aumentar isso não terá nenhum efeito positivo para as conexões de entrada que são falsificadas, nem para qualquer um que receba um cookie SYN em vez do estado do lado do servidor (nenhuma tentativa também para eles).
  • Para conexões falsificadas de entrada, o aumento aumenta o número de pacotes que você envia para um endereço falso e, possivelmente, a quantidade de tempo que o endereço falsificado permanece na tabela de conexão (isso pode ter um efeito negativo significativo).
  • Sob carga normal / número de conexões de entrada, quanto maior, maior a probabilidade de concluir conexões rapidamente / com êxito através de links que descartam pacotes. Há retornos decrescentes para aumentar isso.
• net.ipv4.tcp_synack_retries : Alterar isso não pode ter nenhum efeito nas conexões de entrada (afeta apenas as conexões de saída)

As outras variáveis que você mencionou eu não pesquisei, mas suspeito que as respostas para sua pergunta estão bem aqui.

Se você não estiver sendo inundado por SYN e a máquina estiver respondendo a conexões não HTTP (por exemplo, SSH), acho que provavelmente há um problema de rede, e você deve ter um engenheiro de rede para ajudá-lo a examiná-lo. Se a máquina geralmente não responde mesmo quando você não está sendo inundado por SYN, isso soa como um sério problema de carga se afetar a criação de conexões TCP (muito baixo nível e recurso não intensivo)

    

Answer 2

Eu enfrentei exatamente o mesmo problema em uma nova instalação do Ubuntu Oneiric 11.10 rodando um servidor web (apache2) com um site pesado carregado. No Ubuntu Oneiric 11.10 syncookies foram habilitados por padrão.

Eu tive as mesmas mensagens do kernel informando um possível ataque de inundação SYN na porta do servidor web:

kernel: [739408.882650] TCP: Possible SYN flooding on port 80. Sending cookies.

Ao mesmo tempo, eu tinha certeza de que não havia nenhum ataque acontecendo. Eu tive essas mensagens retornando no intervalo de 5 minutos. Isso parecia apenas uma espiada de carga, porque um invasor manteria a carga alta o tempo todo, enquanto tentava fazer com que o servidor parasse de responder às solicitações.

O ajuste do parâmetro net.ipv4.tcp_max_syn_backlog não levou a melhorias - as mensagens continuaram na mesma velocidade. o fato de que o número de conexões SYN_RECV sempre foi realmente baixo (no meu caso abaixo de 250) foi um indicador, que deve haver algum outro parâmetro, que é responsável por essa mensagem.

Eu encontrei este link da mensagem de erro no site da red hat informando que a mensagem do kernel poderia seja como resultado de um bug (ou configuração incorreta) no lado do aplicativo. Claro que a mensagem de log é muito enganadora! Como este não é o parâmetro do kernel que é responsável nesse caso, mas o parâmetro da sua aplicação, foi passado para o kernel.

Portanto, devemos também dar uma olhada nos parâmetros de configuração do nosso aplicativo de servidor web. Agarre os documentos do apache e vá para o link

O valor padrão do parâmetro ListenBacklog é 511. (Isso corresponde ao número de conexões que você observou em seu servidor red hat. Seu outro servidor pode ter um número menor configurado.)

O Apache possui um parâmetro de configuração próprio para a fila de pendências para conexões de entrada. se você tem muitas conexões de entrada, e a qualquer momento (como algo aleatório) elas chegam juntas quase ao mesmo tempo, de modo que o servidor da Web não é capaz de atendê-las rápido o suficiente de forma apropriada, seu backlog estar completo com 511 conexões e o kernel irá disparar a mensagem acima informando um possível ataque de inundação SYN.

Para resolver isso, eu adiciono a seguinte linha a /etc/apache2/ports.conf ou um dos outros arquivos .conf, que serão carregados pelo apache ( /etc/apache2/apache2.conf também deve ser ok):

ListenBackLog 5000

você também deve definir o net.ipv4.tcp_max_syn_backlog para um valor razoável. no meu entender, o máximo do kernel limitará o valor, que você poderá configurar na configuração do apache. então corra:

sudo sysctl -w net.ipv4.tcp_max_syn_backlog=5000

Depois de ajustar a configuração, não esqueça de reiniciar o seu apache:

sudo service apache2 restart ( or sudo /etc/init.d/apache2 restart )

No meu caso, esta mudança de configuração interrompeu imediatamente os avisos do kernel. Eu sou capaz de reproduzir as mensagens, definindo um baixo valor ListenBackLog na configuração do Apache.

    

Answer 3

Após alguns testes com o kernel 3.4.9, o número de conexões SYN_RECV no netstat depende de

• /proc/sys/net/core/somaxconn arredondado para a próxima potência de 2 (por exemplo, 128 - > 256)
• 75% de /proc/sys/net/ipv4/tcp_max_syn_backlog se /proc/sys/net/ipv4/tcp_syncookies estiver definido como 0 ou 100% se /proc/sys/net/ipv4/tcp_syncookies estiver definido como 1
• ListenBackLog na configuração do apache arredondada para a próxima potência de 2 (por exemplo, 128 - > 256)

o mínimo de cada um desses parâmetros é usado. Depois de alterar o somaxconn ou ListenBackLog, o apache deve ser reiniciado.

E depois de aumentar o tcp_max_syn_backlog, o apache também deve ser reiniciado.

Sem o tcp_syncookies o apache está bloqueando, porque neste caso apenas 75% do tcp_max_syn_backlog é o limite é estranho. e aumentar esse parâmetro aumenta as conexões SYN_RECV para 100% do valor antigo sem reiniciar o apache.