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.
Respuestas:
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: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)
fuente
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:
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):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:Después de ajustar la configuración, no olvide reiniciar su apache:
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.
fuente
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/somaxconnredondeado a la siguiente potencia de 2 (por ejemplo, 128 -> 256)/proc/sys/net/ipv4/tcp_max_syn_backlogsi/proc/sys/net/ipv4/tcp_syncookiesestá configurado en0o 100% si/proc/sys/net/ipv4/tcp_syncookiesestá configurado en1ListenBackLogen 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.
fuente
/bin/echo m >/proc/sysrq-triggermenudo conduce a una posible inundación de SYN en el puerto 80. Envío de mensaje de cookies .