«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 (contre 5 par défaut) 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 environ 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 doit-il être en netstat -tunacorrélation avec la taille du backlog?

Mise à jour

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

J'ai également découvert que 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 -pet désactivé les syncookies par sysctl -w net.ipv4.tcp_syncookies=0.

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

Je pense 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.

Donc, c'est une bonne question.

Au début, j'ai été surpris que vous ayez vu des connexions dans l'état SYN_RECV avec les cookies SYN activés. La beauté des cookies SYN est que vous pouvez participer sans état à la négociation TCP à 3 voies 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 car ce serait le même état que celui qui n'est pas pas gardé.

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 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)

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 du 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.

Le réglage du net.ipv4.tcp_max_syn_backlogparamè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 d'une mauvaise configuration) du côté de l'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 des documents apache et accédez à http://httpd.apache.org/docs/2.0/mod/mpm_common.html#listenbacklog

La valeur par défaut du ListenBacklogparamètre est 511. (Cela correspond au nombre de connexions que vous avez observées 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 du backlog pour les connexions entrantes. si vous avez beaucoup de connexions entrantes, et à tout moment (tout 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 assez 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 à l' /etc/apache2/ports.confun des autres fichiers .conf, qui sera chargé par apache ( /etc/apache2/apache2.confdevrait également être ok):

ListenBackLog 5000

vous devez également définir la net.ipv4.tcp_max_syn_backlogvaleur 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 config, 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.

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_backlogsi /proc/sys/net/ipv4/tcp_syncookiesest défini sur 0ou 100% si /proc/sys/net/ipv4/tcp_syncookiesest défini sur1
• ListenBackLog dans la configuration apache arrondie à 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.