"Posible inundación SYN" en el registro a pesar del bajo número de conexiones SYN_RECV

30

Recientemente tuvimos un servidor apache que respondía muy lentamente debido a las inundaciones de SYN. La solución para esto era habilitar tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf).

Publiqué una pregunta sobre esto aquí si quieres más información.

Después de habilitar las syncookies, comenzamos a ver el siguiente mensaje en / var / log / messages aproximadamente cada 60 segundos:

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

Vinko Vrsalovic me informó que esto significa que el backlog de sincronización se está llenando, así que elevé tcp_max_syn_backlog a 4096. En algún momento también bajé tcp_synack_retries a 3 (en lugar del valor predeterminado de 5) al emitir sysctl -w net.ipv4.tcp_synack_retries=3. Después de hacer esto, la frecuencia pareció disminuir, y el intervalo de mensajes varió entre aproximadamente 60 y 180 segundos.

A continuación, emití sysctl -w net.ipv4.tcp_max_syn_backlog=65536, pero sigo recibiendo el mensaje en el registro.

A lo largo de todo esto, he estado observando la cantidad de conexiones en estado SYN_RECV (ejecutando watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'), y nunca supera los 240, mucho más que el tamaño de la acumulación. Sin embargo, tengo un servidor Red Hat que ronda los 512 (el límite en este servidor es el predeterminado de 1024).

¿Hay alguna otra configuración de TCP que limitaría el tamaño del trabajo atrasado o estoy ladrando el árbol equivocado? ¿Debería netstat -tunacorrelacionarse el número de conexiones SYN_RECV con el tamaño de la acumulación?


Actualizar

Lo mejor que puedo decir es que estoy lidiando con conexiones legítimas aquí, netstat -tuna|wc -lronda los 5000. He estado investigando esto hoy y encontré esta publicación de un empleado de last.fm, que ha sido bastante útil.

También descubrí que tcp_max_syn_backlog no tiene efecto cuando las syncookies están habilitadas (según este enlace )

Entonces, como paso siguiente, configuro lo siguiente en 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

Luego configuré mi prueba de tiempo de respuesta, ejecuté sysctl -py deshabilité syncookies por sysctl -w net.ipv4.tcp_syncookies=0.

Después de hacer esto, el número de conexiones en el estado SYN_RECV aún permanecía alrededor de 220-250, pero las conexiones comenzaban a retrasarse nuevamente. Una vez que noté estos retrasos, volví a habilitar las syncookies y los retrasos se detuvieron.

Creo que lo que estaba viendo todavía era una mejora con respecto al estado inicial, sin embargo, algunas solicitudes aún se retrasaron, lo que es mucho peor que tener habilitadas las sincookies. Por lo tanto, parece que estoy atascado con ellos habilitados hasta que podamos obtener algunos servidores más en línea para hacer frente a la carga. Incluso entonces, no estoy seguro de ver una razón válida para deshabilitarlos nuevamente, ya que solo se envían (aparentemente) cuando los búferes del servidor se llenan.

¡Pero la acumulación de sincronización no parece estar llena con solo ~ 250 conexiones en el estado SYN_RECV! ¿Es posible que el mensaje de inundación SYN sea una pista falsa y sea algo más que el syn_backlog que se está llenando?

Si alguien tiene otras opciones de ajuste que aún no he probado, estaría encantado de probarlas, pero estoy empezando a preguntarme si la configuración syn_backlog no se aplica correctamente por alguna razón.

Alex Forbes
fuente

Respuestas:

27

Entonces, esta es una buena pregunta.

Inicialmente, me sorprendió que haya visto alguna conexión en estado SYN_RECV con las cookies SYN habilitadas. La belleza de las cookies SYN es que puedes participar sin estado en el protocolo de enlace TCP de 3 vías como un servidor usando criptografía, por lo que esperaría que el servidor no represente conexiones entreabiertas porque ese sería el mismo estado No se mantiene.

De hecho, un vistazo rápido a la fuente (tcp_ipv4.c) muestra información interesante sobre cómo el núcleo implementa las cookies SYN. Esencialmente, a pesar de activarlos, el núcleo se comporta como lo haría normalmente hasta que su cola de conexiones pendientes esté llena. Esto explica su lista existente de conexiones en estado SYN_RECV.

Solo cuando la cola de conexiones pendientes está llena, Y se recibe otro paquete SYN (intento de conexión), Y ha pasado más de un minuto desde el último mensaje de advertencia, el núcleo envía el mensaje de advertencia que ha visto ("enviando cookies" ) Las cookies SYN se envían incluso cuando el mensaje de advertencia no lo es; el mensaje de advertencia es solo para avisarle que el problema no ha desaparecido.

Dicho de otra manera, si desactiva las cookies SYN, el mensaje desaparecerá. Eso solo funcionará para ti si ya no estás inundado por SYN.

Para abordar algunas de las otras cosas que ha hecho:

  • net.ipv4.tcp_synack_retries:
    • Aumentar esto no tendrá ningún efecto positivo para las conexiones entrantes que son falsificadas, ni para ninguna que reciba una cookie SYN en lugar del estado del lado del servidor (tampoco hay reintentos para ellas).
    • Para las conexiones falsificadas entrantes, aumentar esto aumenta la cantidad de paquetes que envía a una dirección falsa, y posiblemente la cantidad de tiempo que esa dirección falsificada permanece en su tabla de conexiones (esto podría ser un efecto negativo significativo).
    • Bajo carga / número normal de conexiones entrantes, cuanto mayor sea esto, mayor será la probabilidad de completar conexiones rápida / exitosamente a través de enlaces que descartan paquetes. Hay rendimientos decrecientes para aumentar esto.
  • net.ipv4.tcp_syn_retries: Cambiar esto no puede tener ningún efecto en las conexiones entrantes (solo afecta las conexiones salientes)

Las otras variables que mencionas no las he investigado, pero sospecho que las respuestas a tu pregunta están más o menos aquí.

Si no se está inundando SYN y la máquina responde a conexiones que no son HTTP (por ejemplo, SSH), creo que probablemente haya un problema de red, y debe contar con un ingeniero de red que lo ayude a verlo. Si la máquina generalmente no responde incluso cuando no se está inundando SYN, suena como un problema grave de carga si afecta la creación de conexiones TCP (nivel bastante bajo y recursos no intensivos)

Slartibartfast
fuente
Gracias, esta es una respuesta interesante e informativa. Ciertamente responde a mi consulta sobre la relación entre las conexiones en el estado SYN_RECV y el envío de cookies. La máquina respondía a no HTTP, incluidos SSH y HTTPS, que recibe mucho menos tráfico que HTTP. Por lo tanto, hemos decidido que reducir el tráfico es el camino a seguir.
Alex Forbes
Con respecto a hacer que un ingeniero de redes eche un vistazo, es una buena sugerencia, pero estamos migrando fuera de este centro de datos, por lo que probablemente no valga la pena cuando traigamos un par de nuevos servidores en línea en otro lugar. Creo que podría tener razón acerca de que se trata de un problema de red, tal vez un problema con el equilibrador de carga o el firewall. Gracias de nuevo por sus ideas!
Alex Forbes
13

Me he enfrentado exactamente al mismo problema en una nueva instalación de Ubuntu Oneiric 11.10 que ejecuta un servidor web (apache2) con un sitio web cargado. En Ubuntu Oneiric 11.10, las sincookies estaban habilitadas por defecto.

Tenía los mismos mensajes del núcleo que indicaban un posible ataque de inundación SYN en el puerto del servidor web:

kernel: [739408.882650] TCP: Posible inundación de SYN en el puerto 80. Envío de cookies.

Al mismo tiempo, estaba bastante seguro de que no había ningún ataque. Tenía estos mensajes regresando a intervalos de 5 minutos Esto parecía un vistazo de carga, porque un atacante mantendría la carga alta todo el tiempo, mientras intentaba que el servidor dejara de responder a las solicitudes.

Ajustar el net.ipv4.tcp_max_syn_backlogparámetro no condujo a ninguna mejora: los mensajes continuaron a la misma velocidad. El hecho de que el número de conexiones SYN_RECV siempre fue realmente bajo (en mi caso por debajo de 250) fue un indicador de que debe haber algún otro parámetro responsable de este mensaje.

Encontré este mensaje de error https://bugzilla.redhat.com/show_bug.cgi?id=734991 en el sitio de red hat que indica que el mensaje del núcleo podría ser el resultado de un error (o una configuración incorrecta) en el lado de la aplicación . ¡Por supuesto, el mensaje de registro es muy engañoso! Como este no es el parámetro del kernel responsable en ese caso, sino el parámetro de su aplicación, se pasa al kernel.

Por lo tanto, también deberíamos echar un vistazo a los parámetros de configuración de nuestra aplicación de servidor web. Tome los documentos de Apache y vaya a http://httpd.apache.org/docs/2.0/mod/mpm_common.html#listenbacklog

El valor predeterminado del ListenBacklogparámetro es 511. (Esto corresponde con el número de conexiones que ha observado en su servidor de red hat. Su otro servidor posiblemente tenga un número menor configurado).

Apache tiene un parámetro de configuración propio para la cola de pedidos pendientes para las conexiones entrantes. Si tiene muchas conexiones entrantes, y en cualquier momento (solo como algo aleatorio), llegan todas juntas casi al mismo tiempo, de modo que el servidor web no puede atenderlas lo suficientemente rápido, su trabajo pendiente será esté lleno con conexiones 511 y el núcleo activará el mensaje anterior indicando un posible ataque de inundación SYN.

Para resolver esto, agrego la siguiente línea a /etc/apache2/ports.confuno de los otros archivos .conf, que será cargado por apache ( /etc/apache2/apache2.conftambién debería estar bien):

ListenBackLog 5000

También debe establecer el net.ipv4.tcp_max_syn_backlogvalor razonable. Según tengo entendido, el máximo del kernel limitará el valor, que podrá configurar en la configuración de apache. entonces corre:

sudo sysctl -w net.ipv4.tcp_max_syn_backlog=5000

Después de ajustar la configuración, no olvide reiniciar su apache:

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

En mi caso, este cambio de configuración detuvo inmediatamente las advertencias del kernel. Puedo reproducir los mensajes estableciendo un valor bajo de ListenBackLog en la configuración de apache.

Jeff
fuente
2
Gran respuesta. Suponiendo que lo que dices es correcto, marcaría esto como la respuesta aceptada, pero realmente no puedo probarlo: reducir la carga resolvió el problema y tengo una política de no jugar con servidores de producción sin una buena causa :)
Alex Forbes
Puedo confirmar que esto funciona esencialmente, es una función anti-DDOS del núcleo, sin embargo, cuando recibe, digamos, mucho tráfico web, ¡termina bloqueando a sus usuarios legítimos!
Areeb Soo Yasir
5

Después de algunas pruebas con el núcleo 3.4.9, el número de conexiones SYN_RECV en netstat depende de

  • /proc/sys/net/core/somaxconn redondeado a la siguiente potencia de 2 (por ejemplo, 128 -> 256)
  • 75% de /proc/sys/net/ipv4/tcp_max_syn_backlogsi /proc/sys/net/ipv4/tcp_syncookiesestá configurado en 0o 100% si /proc/sys/net/ipv4/tcp_syncookiesestá configurado en1
  • ListenBackLog en la configuración de apache redondeado a la siguiente potencia de 2 (por ejemplo, 128 -> 256)

Se utiliza el mínimo de cada uno de estos parámetros. Después de cambiar somaxconn o ListenBackLog, apache debe reiniciarse.

Y después de aumentar tcp_max_syn_backlog, apache también debe reiniciarse.

Sin tcp_syncookies, apache está bloqueando, por lo que en este caso solo el 75% de tcp_max_syn_backlog es el límite es extraño. y al aumentar este parámetro, las conexiones SYN_RECV aumentan al 100% del valor anterior sin reiniciar apache.

usoft
fuente
Y también la llamada a /bin/echo m >/proc/sysrq-triggermenudo conduce a una posible inundación de SYN en el puerto 80. Envío de mensaje de cookies .
usoft