web-dev-qa-db-fra.com

"Inondation SYN possible" dans le journal malgré le faible nombre de connexions SYN_RECV

Récemment, nous avions un serveur Apache qui répondait très lentement en raison des inondations SYN. La solution de contournement était d'activer tcp_syncookies (net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf).

J'ai posté une question à ce sujet ici si vous voulez plus d'informations.

Après avoir activé les syncookies, nous avons commencé à voir le message suivant dans/var/log/messages toutes les 60 secondes environ:

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

Vinko Vrsalovic m'a informé que cela signifie que le backlog de synchronisation est plein, j'ai donc augmenté tcp_max_syn_backlog à 4096. À un moment donné, j'ai également abaissé tcp_synack_retries à 3 (en baisse par rapport à la valeur par défaut de 5) en émettant sysctl -w net.ipv4.tcp_synack_retries=3. Après cela, la fréquence a semblé baisser, l'intervalle des messages variant entre environ 60 et 180 secondes.

Ensuite, j'ai émis sysctl -w net.ipv4.tcp_max_syn_backlog=65536, Mais je reçois toujours le message dans le journal.

Tout au long de tout cela, j'ai regardé le nombre de connexions dans l'état SYN_RECV (en exécutant watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'), Et il ne dépasse jamais 240, beaucoup plus bas que la taille du backlog. Pourtant, j'ai un serveur Red Hat qui oscille autour de 512 (la limite sur ce serveur est la valeur par défaut de 1024).

Existe-t-il d'autres paramètres TCP qui limiteraient la taille du backlog ou suis-je en train d'aboyer la mauvaise arborescence? Le nombre de connexions SYN_RECV dans netstat -tuna Doit-il correspondre à la taille du backlog?

Mise à jour

Du mieux que je puisse dire, j'ai affaire à des connexions légitimes ici, netstat -tuna|wc -l Plane autour de 5000. J'ai fait des recherches sur ce sujet aujourd'hui et j'ai trouvé ce message d'un employé de last.fm, qui a été plutôt utile.

J'ai également découvert que le tcp_max_syn_backlog n'a aucun effet lorsque les syncookies sont activés (selon ce lien )

Donc, comme étape suivante, j'ai défini ce qui suit dans 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

J'ai ensuite configuré mon test de temps de réponse, exécuté sysctl -p Et désactivé les syncookies par sysctl -w net.ipv4.tcp_syncookies=0.

Après cela, le nombre de connexions dans l'état SYN_RECV restait toujours autour de 220-250, mais les connexions commençaient à nouveau à retarder. Une fois que j'ai remarqué ces retards, j'ai réactivé les syncookies et les retards se sont arrêtés.

Je crois que ce que je voyais était toujours une amélioration par rapport à l'état initial, mais certaines demandes ont toujours été retardées, ce qui est bien pire que l'activation des syncookies. Il semble donc que je suis bloqué avec eux activés jusqu'à ce que nous puissions obtenir plus de serveurs en ligne pour faire face à la charge. Même alors, je ne suis pas sûr de voir une raison valable de les désactiver à nouveau car ils ne sont envoyés (apparemment) que lorsque les tampons du serveur sont pleins.

Mais le backlog de synchronisation ne semble pas être plein avec seulement ~ 250 connexions dans l'état SYN_RECV! Est-il possible que le message d'inondation SYN soit un hareng rouge et que ce soit autre chose que le syn_backlog qui se remplit?

Si quelqu'un a d'autres options de réglage que je n'ai pas encore essayées, je serais plus qu'heureux de les essayer, mais je commence à me demander si le paramètre syn_backlog n'est pas appliqué correctement pour une raison quelconque.

linuxtcpkernelflooding
30
Alex Forbes

Donc, c'est une bonne question.

Au début, j'ai été surpris que vous ayez vu toutes connexions dans l'état SYN_RECV avec les cookies SYN activés. La beauté des cookies SYN est que vous pouvez participer de manière apatride à la prise de contact à 3 voies dans TCP en tant que serveur utilisant la cryptographie, donc je m'attends à ce que le serveur ne représente pas du tout les connexions semi-ouvertes parce que ce serait le très même état qui n'est pas conservé.

En fait, un rapide coup d'œil à la source (tcp_ipv4.c) montre des informations intéressantes sur la façon dont le noyau implémente les cookies SYN. Essentiellement, malgré leur activation, le noyau se comporte comme il le ferait normalement jusqu'à ce que sa file d'attente de connexions en attente soit pleine. Cela explique votre liste existante de connexions dans l'état SYN_RECV.

Ce n'est que lorsque la file d'attente des connexions en attente est pleine, ET qu'un autre paquet SYN (tentative de connexion) est reçu, ET cela fait plus d'une minute depuis le dernier message d'avertissement, que le noyau envoie le message d'avertissement que vous avez vu ("envoi de cookies" ). Les cookies SYN sont envoyés même lorsque le message d'avertissement ne l'est pas; le message d'avertissement est juste pour vous avertir que le problème n'a pas disparu.

Autrement dit, si vous désactivez les cookies SYN, le message disparaîtra. Cela ne fonctionnera pour vous que si vous n'êtes plus inondé de SYN.

Pour aborder certaines des autres choses que vous avez faites:

  • net.ipv4.tcp_synack_retries:
    • L'augmentation de ceci n'aura aucun effet positif pour les connexions entrantes qui sont usurpées, ni pour celles qui reçoivent un cookie SYN au lieu de l'état côté serveur (pas de nouvelle tentative pour elles non plus).
    • Pour les connexions entrantes usurpées, l'augmentation de cela augmente le nombre de paquets que vous envoyez à une fausse adresse, et peut-être la durée pendant laquelle cette adresse usurpée reste dans votre table de connexion (cela pourrait avoir un effet négatif significatif).
    • Sous une charge/un nombre normal de connexions entrantes, plus il est élevé, plus vous avez de chances de terminer rapidement/avec succès des connexions sur des liens qui abandonnent des paquets. Il y a des rendements décroissants pour augmenter cela.
  • net.ipv4.tcp_syn_retries: La modification de ceci ne peut avoir aucun effet sur les connexions entrantes (elle affecte uniquement les connexions sortantes)

Je n'ai pas recherché les autres variables que vous mentionnez, mais je soupçonne que les réponses à votre question sont à peu près ici.

Si vous n'êtes pas inondé de SYN et que la machine est sensible aux connexions non HTTP (par exemple SSH), je pense qu'il y a probablement un problème de réseau, et vous devriez avoir un ingénieur réseau pour vous aider à le regarder. Si la machine ne répond généralement pas même si vous n'êtes pas inondé de SYN, cela ressemble à un problème de charge grave s'il affecte la création de connexions TCP (niveau assez bas et ressources non intensives)

27
Slartibartfast

J'ai rencontré exactement le même problème sur une nouvelle installation d'Ubuntu Oneiric 11.10 exécutant un serveur Web (Apache2) avec un site Web lourdement chargé. Sur Ubuntu Oneiric 11.10, les syncookies étaient activés par défaut.

J'ai eu les mêmes messages de noyau indiquant une possible attaque flood SYN sur le port du serveur Web:

noyau: [739408.882650] TCP: inondation SYN possible sur le port 80. Envoi de cookies.

En même temps, j'étais presque sûr qu'il n'y avait pas eu d'attaque. J'ai eu ces messages revenant à 5min d'intervalle. Cela ressemblait à un aperçu de la charge, car un attaquant maintiendrait la charge élevée tout le temps, tout en essayant de faire en sorte que le serveur cesse de répondre aux demandes.

Réglage du net.ipv4.tcp_max_syn_backlog le paramètre n'a entraîné aucune amélioration - les messages ont continué au même rythme. le fait que le nombre de connexions SYN_RECV était toujours vraiment faible (dans mon cas, moins de 250) était un indicateur, qu'il doit y avoir un autre paramètre, qui est responsable de ce message.

J'ai trouvé ce message de bogue https://bugzilla.redhat.com/show_bug.cgi?id=734991 sur le site Red Hat indiquant que le message du noyau pourrait être le résultat d'un bogue ( ou mauvaise configuration) côté application. Bien sûr, le message du journal est très trompeur! Comme ce n'est pas le paramètre du noyau qui est responsable dans ce cas, mais le paramètre de votre application, transmis au noyau.

Nous devons donc également jeter un coup d'œil aux paramètres de configuration de notre application de serveur Web. Récupérez les documents Apache et accédez à http://httpd.Apache.org/docs/2.0/mod/mpm_common.html#listenbacklog

La valeur par défaut du paramètre ListenBacklog est 511. (Cela correspond au nombre de connexions que vous avez observé sur votre serveur Red Hat. Votre autre serveur peut éventuellement avoir un nombre inférieur configuré.)

Apache a son propre paramètre de configuration pour la file d'attente de backlog pour les connexions entrantes. si vous avez beaucoup de connexions entrantes, et à tout moment (comme une chose aléatoire), elles arrivent toutes ensemble presque en même temps, de sorte que le serveur Web n'est pas en mesure de les servir suffisamment rapidement d'une manière appropriée, votre backlog sera être complet avec 511 connexions et le noyau déclenchera le message ci-dessus indiquant une possible attaque par saturation SYN.

Pour résoudre ce problème, j'ajoute la ligne suivante à /etc/Apache2/ports.conf ou l'un des autres fichiers .conf, qui seront chargés par Apache (/etc/Apache2/Apache2.conf devrait aussi être ok):

ListenBackLog 5000

vous devez également définir le net.ipv4.tcp_max_syn_backlog à une valeur raisonnable. à ma connaissance, le maximum du noyau limitera la valeur que vous pourrez configurer dans la configuration Apache. alors lancez:

Sudo sysctl -w net.ipv4.tcp_max_syn_backlog=5000

Après avoir réglé la configuration, n'oubliez pas de redémarrer votre Apache:

Sudo service Apache2 restart ( or Sudo /etc/init.d/Apache2 restart )

Dans mon cas, ce changement de configuration a immédiatement arrêté les avertissements du noyau. Je suis capable de reproduire les messages en définissant une faible valeur ListenBackLog dans la configuration Apache.

13
Jeff

Après quelques tests avec le noyau 3.4.9, le nombre de connexions SYN_RECV dans netstat dépend de

  • /proc/sys/net/core/somaxconn arrondi à la puissance suivante de 2 (par exemple, 128 -> 256)
  • 75% de /proc/sys/net/ipv4/tcp_max_syn_backlog si /proc/sys/net/ipv4/tcp_syncookies est réglé sur 0 ou 100% si /proc/sys/net/ipv4/tcp_syncookies est réglé sur 1
  • ListenBackLog dans la configuration Apache arrondi à la puissance suivante de 2 (par exemple 128 -> 256)

le minimum de chacun de ces paramètres est utilisé. Après avoir changé somaxconn ou ListenBackLog, Apache doit être redémarré.

Et après avoir augmenté tcp_max_syn_backlog, Apache doit également être redémarré.

Sans tcp_syncookies Apache bloque, pourquoi dans ce cas seulement 75% de tcp_max_syn_backlog est la limite est étrange. et l'augmentation de ce paramètre augmente les connexions SYN_RECV à 100% de l'ancienne valeur sans redémarrer Apache.

5
usoft