{"id":20882,"date":"2026-08-22T08:31:38","date_gmt":"2026-08-22T06:31:38","guid":{"rendered":"https:\/\/webhosting.de\/tcp-syn-cookies-schutz-syn-flood-kernel\/"},"modified":"2026-08-22T08:31:38","modified_gmt":"2026-08-22T06:31:38","slug":"proteccion-contra-syn-cookies-de-tcp-inundacion-de-syn-kernel","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/tcp-syn-cookies-schutz-syn-flood-kernel\/","title":{"rendered":"\u00abTCP SYN Cookies\u00bb en el n\u00facleo de Linux: protecci\u00f3n contra las inundaciones de SYN"},"content":{"rendered":"<p><strong>Cookies TCP SYN<\/strong> En el n\u00facleo de Linux, se mantiene baja la carga del handshake codificando criptogr\u00e1ficamente la informaci\u00f3n de estado en el n\u00famero de secuencia inicial (Initial Sequence Number) y estableciendo la conexi\u00f3n por completo solo tras recibir un ACK v\u00e1lido. De este modo, evito que las inundaciones de SYN saturen la cola de conexiones semiabiertas y bloqueen a los clientes leg\u00edtimos.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<ul>\n  <li><strong>Funcionalidad<\/strong>: Cookie en el ISN, estado solo tras el ACK<\/li>\n  <li><strong>Control mediante Linux<\/strong>: net.ipv4.tcp_syncookies con los modos 0\/1\/2<\/li>\n  <li><strong>Beneficio<\/strong>: bajo consumo de memoria ante una carga de ataques<\/li>\n  <li><strong>L\u00edmites<\/strong>: no sirve para defenderse de los ataques a la ancho de banda o a las aplicaciones<\/li>\n  <li><strong>Sintonizaci\u00f3n<\/strong>: Configurar cuidadosamente los valores de backlog y retry<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-syn-schutz-8574.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>C\u00f3mo los ataques SYN-Flood ralentizan el protocolo de enlace TCP<\/h2>\n\n<p>Un atacante inunda el servidor con <strong>Paquetes SYN<\/strong> e ignora las respuestas SYN\/ACK siguientes, lo que hace que las entradas semiabiertas ocupen espacio en la cola SYN. Entonces observo que las nuevas solicitudes leg\u00edtimas no encuentran espacio y se acumulan los tiempos de espera agotados. Es precisamente aqu\u00ed donde entran en juego <strong>Syncookies<\/strong> : El n\u00facleo no almacena inicialmente ning\u00fan estado de conexi\u00f3n y traslada los datos necesarios al n\u00famero de secuencia. Solo un ACK correcto confirma la existencia de un interlocutor real, de modo que el establecimiento de la conexi\u00f3n contin\u00faa con normalidad. LWN.net y la documentaci\u00f3n de la TUM describen este principio como una protecci\u00f3n contra el \u00abhandshake\u00bb consolidada y eficaz que no requiere un elevado consumo de memoria. Esta arquitectura mantiene la capacidad de respuesta del servidor incluso ante un tr\u00e1fico masivo, ya que no crea los costosos estados hasta mucho m\u00e1s tarde.<\/p>\n\n<h2>Procedimiento t\u00e9cnico: una \u00abcookie\u00bb en lugar del antiguo sistema de estado<\/h2>\n\n<p>El n\u00facleo responde a un <strong>SYN<\/strong> con un SYN\/ACK codificado especialmente, cuyo ISN se deriva de una clave secreta, opciones TCP y intervalos de tiempo. Si llega un ACK con el n\u00famero correspondiente, reconstruyo los par\u00e1metros de la sesi\u00f3n a partir del ISN y abro el socket de forma normal. Si no llega la respuesta, tampoco existe un estado semiabierto ocupado, lo que ahorra memoria y recursos de la CPU. Este enfoque reduce dr\u00e1sticamente la vulnerabilidad de la fase de aceptaci\u00f3n sin modificar de forma permanente la ruta habitual. Seg\u00fan la documentaci\u00f3n de Ubuntu y Red Hat, esta t\u00e9cnica lleva funcionando de forma fiable desde hace muchas generaciones de kernel y solo se activa cuando la cola amenaza con desbordarse.<\/p>\n\n<h2>Activaci\u00f3n y comprobaci\u00f3n: tcp_syncookies en la pr\u00e1ctica<\/h2>\n\n<p>Acerca del par\u00e1metro sysctl <strong>net.ipv4.tcp_syncookies<\/strong> Controlo el comportamiento: 0 = desactivado, 1 = solo en caso de sobrecarga, 2 = de forma permanente. En entornos de producci\u00f3n suelo configurar el modo 1, para que el protocolo de Handshake est\u00e1ndar se mantenga intacto y la protecci\u00f3n solo se active cuando sea necesario. Puedo consultar r\u00e1pidamente el estado en el shell; los cambios los aplico mediante sysctl o de forma permanente en \/etc\/sysctl.d\/. Un art\u00edculo de fondo adecuado sobre el comportamiento de los sockets y los patrones de ataque ayuda a planificar todo el proceso; profundizo en los detalles en la entrada <a href=\"https:\/\/webhosting.de\/es\/syn-proteccion-contra-inundaciones-gestion-de-sockets-defensa-del-servidor\/\">SYN protecci\u00f3n contra inundaciones<\/a>. Utilizo habitualmente los siguientes comandos:<\/p>\n\n<pre><code>Mostrar el estado de #\nsysctl net.ipv4.tcp_syncookies\n\nActivar # temporalmente (hasta el reinicio)\nsudo sysctl -w net.ipv4.tcp_syncookies=1\n\nConfigurar # de forma permanente\necho \"net.ipv4.tcp_syncookies = 1\" | sudo tee \/etc\/sysctl.d\/60-syncookies.conf\nsudo sysctl --system\n<\/code><\/pre>\n\n<h2>L\u00edmites: lo que las cookies SYN no pueden hacer<\/h2>\n\n<p>Las cookies SYN se dirigen principalmente a los <strong>Syn-Queue<\/strong> y evitan que los estados semiabertos ocupen memoria. Sin embargo, no son eficaces contra una l\u00ednea sobrecargada, una l\u00f3gica de aplicaci\u00f3n desbordada o la saturaci\u00f3n de la CPU. En caso de ataques volum\u00e9tricos, necesito filtros previos, QoS y, si es necesario, scrubbing. Los ataques a nivel de aplicaci\u00f3n, como las inundaciones HTTP-GET, tambi\u00e9n requieren controles, l\u00edmites y cach\u00e9s adicionales. Por ello, siempre integro las \u00absyncookies\u00bb en una defensa de varias capas que a\u00fana la red, el n\u00facleo y el nivel de servicio.<\/p>\n\n<h2>Optimizaci\u00f3n: trabajo pendiente, colas y reintentos<\/h2>\n\n<p>Antes de que se produzca una emergencia, estoy de acuerdo con... <strong>atrasos<\/strong> y los reintentos, para que los picos leg\u00edtimos no activen el modo de protecci\u00f3n innecesariamente. tcp_max_syn_backlog influye en la cola de conexiones semiabiertas, mientras que somaxconn determina la longitud m\u00e1xima de la cola de aceptaci\u00f3n para las conexiones en espera de accept(). Con tcp_synack_retries determino cu\u00e1ntas veces el n\u00facleo intenta repetir un SYN\/ACK antes de darse por vencido. Un backlog mayor absorbe los picos de carga breves, pero consume memoria; un n\u00famero menor de reintentos libera ranuras antes, aunque conlleva el riesgo de afectar demasiado a los clientes desconectados. Pruebo estas opciones bajo una carga realista con herramientas como hping3 o tcp_syn_flooder en una red aislada.<\/p>\n\n<pre><code>#: candidatos para picos de carga\nsudo sysctl -w net.core.somaxconn=4096\nsudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192\nsudo sysctl -w net.ipv4.tcp_synack_retries=3\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcpsyncookies_7432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparaci\u00f3n de modos de funcionamiento: efectos y aplicaciones<\/h2>\n\n<p>Para el d\u00eda a d\u00eda, elijo la <strong>Modos<\/strong> Hay que tenerlo en cuenta, ya que influyen en el diagn\u00f3stico, las m\u00e9tricas y el comportamiento bajo presi\u00f3n. Las cookies permanentes (2) evitan cualquier establecimiento precoz del estado, pero modifican los valores de medici\u00f3n para los reintentos y pueden influir en casos extremos poco frecuentes con opciones TCP. El modo adaptativo (1) permite que la pila funcione con normalidad e interviene cuando existe riesgo de desbordamiento. La opci\u00f3n \u00abdesactivado\u00bb (0) solo tiene sentido, como mucho, en entornos de laboratorio o en redes cerradas. La siguiente tabla lo resume de forma concisa:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Modo<\/th>\n      <th>Descripci\u00f3n<\/th>\n      <th>Ventaja<\/th>\n      <th>Posibles efectos secundarios<\/th>\n      <th>Ejemplo<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>0<\/td>\n      <td><strong>Desactivado<\/strong>, sin cookies<\/td>\n      <td>Comportamiento claro en la l\u00ednea de base<\/td>\n      <td>El atacante llena la cola Syn<\/td>\n      <td>Red de pruebas aislada<\/td>\n    <\/tr>\n    <tr>\n      <td>1<\/td>\n      <td><strong>Adaptativo<\/strong>, solo en caso de desbordamiento<\/td>\n      <td>TCP normal en reposo<\/td>\n      <td>Calibrar el punto de conmutaci\u00f3n<\/td>\n      <td>Servicios p\u00fablicos<\/td>\n    <\/tr>\n    <tr>\n      <td>2<\/td>\n      <td><strong>Obligatorio<\/strong>, siempre activo<\/td>\n      <td>Alivio precoz<\/td>\n      <td>Los valores anal\u00edticos var\u00edan<\/td>\n      <td>Situaci\u00f3n de ataque dif\u00edcil<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Efectos cuantificables: latencias y tasa de \u00e9xito<\/h2>\n\n<p>A medida que aumenta la presi\u00f3n, el <strong>Memoria necesaria<\/strong> Esto se nota claramente al inicio de cada conexi\u00f3n, ya que no se produce ning\u00fan estado semiabierto. De este modo, las \u00abSYN cookies\u00bb mantienen alta la tasa de aceptaci\u00f3n, y las r\u00e1fagas cortas provocan menos interrupciones. Observo una recuperaci\u00f3n m\u00e1s r\u00e1pida ante el tr\u00e1fico de avalancha en cuanto la fuente se agota. Las directrices de Ubuntu y Tenable recomiendan un uso adaptativo, para que los clientes normales sigan funcionando sin cambios. Para las pruebas de regresi\u00f3n, compruebo las retransmisiones, las tasas de p\u00e9rdida y la latencia del servidor al pasar al modo de cookies.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-syn-cookies-lnx-protection-4281.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Capas de protecci\u00f3n adicionales: cortafuegos y l\u00edmites<\/h2>\n\n<p>Las \u00absyncookies\u00bb las elimino con <strong>Reglas de filtrado<\/strong> y establezco l\u00edmites de velocidad para que la carga ni siquiera llegue a la pila TCP. En Linux, prefiero utilizar reglas de nftables para limitar o rechazar desde el principio a los usuarios que superen los l\u00edmites de velocidad de conexi\u00f3n. La gu\u00eda ofrece una visi\u00f3n general concisa de los filtros de paquetes modernos <a href=\"https:\/\/webhosting.de\/es\/netfilter-frente-a-nftables-tecnologias-modernas-de-cortafuegos-en-linux-shield\/\">nftables frente a Netfilter<\/a>. Adem\u00e1s, los escenarios SYNPROXY en los cortafuegos perimetrales ayudan a finalizar el protocolo de enlace y a permitir \u00fanicamente las conexiones v\u00e1lidas. Para los puertos expuestos, defino aperturas estrictas, umbrales de registro y un n\u00famero m\u00e1ximo de intentos de conexi\u00f3n por direcci\u00f3n de origen.<\/p>\n\n<h2>Enfoques de alto rendimiento: XDP y otros.<\/h2>\n\n<p>Cuando los ataques masivos... <strong>Tasa de PPS<\/strong> Para optimizar el rendimiento, traslado la l\u00f3gica de filtrado mediante XDP al borde de la red de la tarjeta de red. De este modo, descarto los SYN sospechosos incluso antes de que lleguen a la capa de socket, lo que reduce la carga de la CPU y alivia la cola de recepci\u00f3n. Para iniciarse en esta t\u00e9cnica, resulta \u00fatil una introducci\u00f3n a la <a href=\"https:\/\/webhosting.de\/es\/xdp-procesamiento-de-paquetes-de-alto-rendimiento-velocidad-del-nucleo\/\">Procesamiento de paquetes XDP<\/a>. En combinaci\u00f3n con las cookies SYN, se crea un sistema de dos fases: primero, una selecci\u00f3n aproximada en la tarjeta; despu\u00e9s, una comprobaci\u00f3n fiable del \u00abhandshake\u00bb en el n\u00facleo. Esta cadena reduce notablemente la superficie de ataque y mantiene los servicios accesibles.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tech_office_tcp_syn_cookies_4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diagn\u00f3stico: c\u00f3mo interpretar correctamente las m\u00e9tricas y los mensajes de registro<\/h2>\n\n<p>En caso de que se observen <strong>Tiempos muertos<\/strong> Reviso las estad\u00edsticas de netstat\/ss, los mensajes de dmesg y los paneles de Grafana con las tasas de conexi\u00f3n. Un aumento en la proporci\u00f3n de SYN-RECV, un elevado n\u00famero de retransmisiones y de paquetes perdidos indican el cambio al modo de protecci\u00f3n. Presto atenci\u00f3n a los mensajes de desbordamiento de la cola de SYN y los correlaciono con la carga de la CPU y de las IRQ. Las capturas de paquetes con tcpdump corroboran la l\u00f3gica de los n\u00fameros de secuencia y ayudan a detectar falsos positivos. Adem\u00e1s, con los contadores de iptables\/nftables mido el n\u00famero de coincidencias con las reglas de limitaci\u00f3n de velocidad.<\/p>\n\n<h2>Compatibilidad: opciones TCP y casos extremos<\/h2>\n\n<p>Programaci\u00f3n de n\u00facleos modernos <strong>Opciones<\/strong> como MSS, SACK o Timestamp, de modo que las cookies se transmitan de forma que puedan reconstruirse. Las pilas m\u00e1s antiguas o poco comunes pueden presentar peculiaridades, por lo que compruebo las rutas cr\u00edticas antes del despliegue. Observo minuciosamente el comportamiento, especialmente en el caso de proxies, NAT y topolog\u00edas anycast. LWN.net analiza detalles de dise\u00f1o que explican por qu\u00e9 las implementaciones actuales funcionan de forma fiable. En escenarios muy espec\u00edficos, el modo de funcionamiento forzado (2) sigue siendo una herramienta que solo utilizo de forma selectiva.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/developer_desk_tcp_syn_8793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ideas err\u00f3neas habituales: lo que suelo corregir a menudo<\/h2>\n\n<p>Las \u00absyncookies\u00bb no sustituyen a <strong>Defensa DDoS<\/strong> en la periferia; protegen sobre todo la fase de establecimiento de la conexi\u00f3n. Un valor elevado de somaxconn por s\u00ed solo no evita los desbordamientos si nunca se responde a SYN\/ACK. Del mismo modo, es err\u00f3nea la suposici\u00f3n de que las cookies permanentes (2) sean siempre la mejor opci\u00f3n; los diagn\u00f3sticos y los casos especiales se ven afectados por ello. Sin supervisi\u00f3n, carezco de se\u00f1ales para ajustar los puntos de conmutaci\u00f3n y los l\u00edmites. Las pruebas de carga siguen siendo indispensables para que la configuraci\u00f3n y el hardware se adapten a la din\u00e1mica real de acceso.<\/p>\n\n<h2>An\u00e1lisis pr\u00e1ctico: pasos para llegar a una hip\u00f3tesis s\u00f3lida<\/h2>\n\n<p>Empiezo con <strong>Modo 1<\/strong> para tcp_syncookies y compruebo el punto de intervenci\u00f3n bajo carga. A continuaci\u00f3n, aumento moderadamente tcp_max_syn_backlog y somaxconn, al tiempo que reduzco tcp_synack_retries y mido las tasas de \u00e9xito. Los l\u00edmites de tasa del cortafuegos y los filtros geogr\u00e1ficos\/ASN eliminan el ruido antes de que llegue a la pila. Me reservo los filtros XDP o SmartNIC para situaciones de alto PPS, con el fin de utilizar los recursos de forma espec\u00edfica. Por \u00faltimo, documento las m\u00e9tricas para que los ajustes posteriores se basen en datos.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/netzsicherheit-datenzentrum-8173.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>IPv6 y doble pila: mismo conmutador, misma l\u00f3gica<\/h2>\n\n<p>En entornos de doble pila, se comportan <strong>IPv4 e IPv6<\/strong> es coherente en el contexto de las cookies. El bot\u00f3n <em>net.ipv4.tcp_syncookies<\/em> controla la protecci\u00f3n de forma global para TCP, es decir, tambi\u00e9n para los sockets v6. Por eso compruebo la transici\u00f3n al modo \u00abcookie\u00bb en ambos protocolos, sobre todo cuando los dispositivos de upstream en IPv6 utilizan otras rutas de filtrado. Importante: las cookies SYN protegen exclusivamente el TCP. Los servicios UDP o QUIC requieren sus propios l\u00edmites de tasa y pol\u00edticas de borde para que el tr\u00e1fico volum\u00e9trico no sature la CPU.<\/p>\n\n<h2>M\u00e9tricas del n\u00facleo: indicadores fiables<\/h2>\n\n<p>Para realizar un seguimiento fiable, utilizo contadores del n\u00facleo que registran expl\u00edcitamente las cookies. Adem\u00e1s de <em>ss -s<\/em> Y, en cuanto a las distribuciones de estado, observo los contadores de cookies enviadas, aceptadas y fallidas. As\u00ed puedo detectar si la protecci\u00f3n funciona, si los clientes leg\u00edtimos logran pasar y si hay errores de configuraci\u00f3n.<\/p>\n\n<pre><code>Resumen de #\nss -s\nss -ant state syn-recv | wc -l\n\nContador de cookies de # (kernel: \/proc\/net\/netstat)\ngrep -E 'Syncookies|ListenOverflows|ListenDrops' \/proc\/net\/netstat\n\n# Vista en tiempo real\nwatch -n1 'grep -E \"Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n\n# Indicaciones en el registro (mensaje de ejemplo)\n# dmesg muestra, entre otras cosas:\n# TCP: Posible inundaci\u00f3n de SYN en el puerto 443. Enviando cookies. Comprueba los contadores SNMP.\n<\/code><\/pre>\n\n<p>Subir <em>Desbordamientos de listas<\/em> y <em>ListenDrops<\/em> en paralelo a <em>SyncookiesSent<\/em> ajusto los backlogs, los reintentos y los filtros de upstream. Quedan <em>SyncookiesRecv<\/em> ... eso apunta a una aut\u00e9ntica avalancha de bots; en cambio, si se multiplican <em>SyncookiesFailed<\/em>, compruebo las rutas NAT\/proxy y las posibles manipulaciones que puedan producirse en el trayecto.<\/p>\n\n<h2>Proxies, equilibradores de carga y Kubernetes<\/h2>\n\n<p>En <strong>Cadenas de proxy y de equilibrio de carga<\/strong> Determina la ubicaci\u00f3n de la protecci\u00f3n de cookies. Si un equilibrador de carga L4\/L7 interrumpe el handshake TCP, una avalancha de paquetes SYN ni siquiera llega a los backends; en ese caso, activo las cookies en el borde. Si el equilibrador de carga solo funciona de forma pasiva (DSR, ECMP), los nodos backend deben protegerse por s\u00ed mismos. En Kubernetes, ajusto los sysctls en los nodos de trabajo, especialmente en cargas de trabajo con NodePort o HostNetwork. Para los controladores de Ingress con su propia defensa contra SYN (SYNPROXY, eBPF), ajusto las pol\u00edticas para que no se frenen entre s\u00ed. Tengo en cuenta las comprobaciones de estado del equilibrador de carga en las pruebas, ya que, de lo contrario, las ventanas de prueba cortas con pocos reintentos pueden dar lugar a falsos indicios de inestabilidad.<\/p>\n\n<h2>Casos l\u00edmite en detalle: opciones, intervalos de tiempo, NAT<\/h2>\n\n<p>Las cookies solo codifican <strong>par\u00e1metros limitados<\/strong>. Las implementaciones modernas de Linux suelen reconstruir MSS, SACK y el escalado de ventanas de forma fiable; sin embargo, las marcas de tiempo y algunas opciones poco habituales pueden presentar limitaciones dependiendo de la versi\u00f3n del n\u00facleo. Por lo tanto, considero preferible el modo de funcionamiento (1), para que predomine la ruta est\u00e1ndar y las cookies solo se activen en caso de desbordamiento. La validez de una \u00abcookie\u00bb est\u00e1 vinculada a intervalos de tiempo; en rutas muy asim\u00e9tricas o con picos de retardo, un ACK leg\u00edtimo puede quedar justo fuera de la ventana. Por eso, en escenarios de WAN y sat\u00e9lite, mido la varianza de ida y vuelta antes de reducir el n\u00famero de reintentos. Los NAT y los dispositivos intermedios que modifican los n\u00fameros de secuencia u opciones son otros posibles casos extremos; mediante capturas espec\u00edficas, determino d\u00f3nde se pierden los bits.<\/p>\n\n<h2>Ataques de inundaci\u00f3n de ACK\/RST y variantes m\u00e1s all\u00e1 de la \u00abtormenta de SYN\u00bb<\/h2>\n\n<p>No todos los <strong>Ataque al transporte<\/strong> Se trata de una inundaci\u00f3n pura de paquetes SYN. Las inundaciones de paquetes ACK o RST se dirigen a la CPU y a las rutas de los paquetes sin activar el handshake; las cookies apenas sirven de ayuda en este caso. En ese caso, utilizo filtros tempranos (nftables\/XDP) con l\u00f3gica de estado o una limitaci\u00f3n m\u00ednima de la tasa de ACK. En concreto, las oleadas de RST contra conexiones establecidas las detengo mediante un conjunto de reglas que descarta los RST inesperados sin una ventana adecuada. Tambi\u00e9n cubro los repetidores semiabiertos (SYN con suplantaci\u00f3n de identidad m\u00e1s ACK tard\u00edos) mediante l\u00edmites de tasa por espacio de red de origen.<\/p>\n\n<h2>Otros ajustes: colas de lista\/aceptaci\u00f3n y errores r\u00e1pidos<\/h2>\n\n<p>Adem\u00e1s de los par\u00e1metros cl\u00e1sicos, utilizo interruptores complementarios que determinan el comportamiento en los l\u00edmites:<\/p>\n\n<ul>\n  <li><strong>Backlog frente a somaxconn<\/strong>: El valor en <em>listas (pendientes)<\/em> por proceso se calcula mediante <em>net.core.somaxconn<\/em> limitado. Me encargo de que el software del servidor y el n\u00facleo funcionen en armon\u00eda; de lo contrario, las optimizaciones no sirven de nada.<\/li>\n  <li><strong>tcp_abort_on_overflow<\/strong>: Si, cuando la cola de aceptaci\u00f3n est\u00e1 llena, se descarta la solicitud sin aviso o se responde activamente con un RST. En las API de gran volumen, un error r\u00e1pido puede permitir al cliente realizar un nuevo intento r\u00e1pidamente; en el caso de clientes TLS o heredados, suelo preferir el descarte por defecto.<\/li>\n  <li><strong>Gesti\u00f3n de puertos y del estado TIME-WAIT<\/strong>: Las galletas no evitan que <em>Cuello de botella del puerto ef\u00edmero<\/em>. Tengo pensado <em>rango_de_puertos_locales_ip<\/em> S\u00e9 generoso y utiliza las optimizaciones de TIME-WAIT con prudencia, para que la reutilizaci\u00f3n no provoque errores de Heisenbug.<\/li>\n  <li><strong>SO_REUSEPORT<\/strong>: Varias colas de aceptaci\u00f3n por puerto distribuyen la carga entre los procesos de trabajo y reducen los desbordamientos en las CPU individuales.<\/li>\n<\/ul>\n\n<h2>M\u00e9todos de ensayo: reproducibles y fiables<\/h2>\n\n<p>Simulo una carga lo m\u00e1s cercana posible a la real y mido el punto de conmutaci\u00f3n al modo \u00abcookie\u00bb, la tasa de \u00e9xito de las conexiones leg\u00edtimas y el tiempo de recuperaci\u00f3n tras el pico de carga. Para ello, combino inundaciones sint\u00e9ticas de paquetes SYN con solicitudes reales de aplicaciones.<\/p>\n\n<pre><code>Generar tr\u00e1fico de inundaci\u00f3n # (\u00a1en laboratorio!)\nsudo hping3 -S -p 443 --flood --rand-source \n\nVariar las condiciones de red #\nsudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%\n\n# Mezclar tr\u00e1fico leg\u00edtimo\nwrk -t8 -c512 -d60s https:\/\/\/\n\n# Observaci\u00f3n en paralelo\nwatch -n1 'ss -s; echo; grep -E \"Syncookies|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n<\/code><\/pre>\n\n<p>Con estos pasos, puedo detectar si los reintentos se reducen de forma demasiado agresiva, si los cortafuegos de upstream filtran err\u00f3neamente las marcas de tiempo o si las colas de aceptaci\u00f3n de determinados trabajadores se desbordan de forma desproporcionada. Documento los indicadores clave (aproximaci\u00f3n a una tasa de \u00e9xito de 100% en conexiones leg\u00edtimas, tasa de aciertos de cookies, comportamiento de la latencia) para poder realizar ajustes posteriores basados en datos.<\/p>\n\n<h2>Funcionamiento y mantenimiento: garantizar la estabilidad a lo largo de la vida \u00fatil<\/h2>\n\n<p>En funcionamiento continuo, tengo previsto <strong>Rotaci\u00f3n secreta<\/strong> (autom\u00e1ticamente por parte del kernel) y observo si los cambios de intervalo de tiempo tienen efectos visibles en tramos con RTT muy largos. Mantengo actualizados el kernel y los controladores para que surtan efecto las mejoras en la implementaci\u00f3n de cookies (mejor codificaci\u00f3n de opciones, intervalos de tiempo robustos). Para las auditor\u00edas, anoto cu\u00e1ndo se activ\u00f3 el modo de protecci\u00f3n, cu\u00e1ntas conexiones dej\u00f3 pasar y si se activaron filtros adicionales. Cuando se producen cambios en el MTU, la descarga o las pilas NF (por ejemplo, nuevos conjuntos de nftables), repito pruebas breves para detectar a tiempo posibles interacciones err\u00f3neas.<\/p>\n\n<h2>Versi\u00f3n abreviada para los que tienen prisa<\/h2>\n\n<p>Las cookies de SYN almacenan la <strong>Carga del protocolo de enlace<\/strong> peque\u00f1a, ya que crean los estados solo tras recibir un ACK confirmado, protegiendo as\u00ed la cola de SYN contra las inundaciones. Activo el modo 1, ajusto con cuidado los backlogs y los reintentos, y mido los efectos con m\u00e9tricas claras. Capas adicionales como los l\u00edmites de tasa de nftables, SYNPROXY y XDP frenan el tr\u00e1fico incluso antes de que llegue a la pila TCP. En resumen, de este modo protejo los servicios web, de correo electr\u00f3nico, VPN y API contra las inundaciones SYN sin perjudicar a los clientes habituales. Quien aplique estos pasos de forma rigurosa refuerza la disponibilidad y reduce notablemente las interrupciones del servicio ante una carga de ataques.<\/p>","protected":false},"excerpt":{"rendered":"<p>Las \u00abcookies\u00bb TCP SYN del n\u00facleo de Linux ofrecen una protecci\u00f3n fiable contra los ataques de inundaci\u00f3n SYN. Descubre c\u00f3mo funciona este mecanismo y c\u00f3mo configurarlo.<\/p>","protected":false},"author":1,"featured_media":20875,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-20882","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"119","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"TCP SYN Cookies","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20875","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20882","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=20882"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20882\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20875"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20882"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20882"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20882"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}