Vulnerabilidad "SynCookie" y cortafuegos, bajo Linux

Linux, con la opción de «SynCookie» activada, es susceptible a un ataque
que permite a un atacante remoto el conectarse a un puerto TCP/IP
protegido con los cortafuengos Linux nativos, si se dan una serie de
circunstancias y el atacante invierte los suficientes recursos.
«SynCookie» es un mecanismo que inmuniza una máquina Linux ante ataques
de denegación de servicio del tipo «Syn Flood» que, básicamente,
consiste en solicitar conexiones TCP/IP desde remitentes espúreos,
falseando la dirección IP de origen («IP Spoof»). Dado que el protocolo
TCP/IP requiere un establecimiento de conexión negociado en tres pasos,
si la IP origen no responde, la conexión no llega a completarse del
todo.

En un sistema operativo no protegido, el número de sesiones a medio
abrir es un valor muy bajo (por ejemplo 10-30), y cualquier intento de
conexión legítima subsiguiente será ignorado. Las sesiones a medio abrir
acaban por expirar, pero su número es tan bajo y su expiración tan alta
(minutos) que basta con que un atacante envíe unos pocos datagramas por
minuto para bloquear un servicio por completo, constituyendo un ataque
DoS (denegación de servicio) muy efectivo.

Ante este tipo de ataques, populares hace unos años y cuya fuente es muy
difícil de localizar, los sistemas operativos modernos han desarrollado
dos tipos de estrategia:

a. Algunos no imponen otros límites al número de sesiones semiabiertas
más que la cantidad de memoria del sistema (lo que de por sí ya puede
constituir un DoS en sí mismo). Si, por ejemplo, una conexión nos ocupa
512 bytes y tenemos 128 Megabytes de RAM para gastar en la tarea,
tendremos capacidad para 262144 sesiones simultaneas. Si expiramos las
sesiones no abiertas en dos minutos (valor típico), nos tienen que
llegar al menos casi 2200 peticiones de conexión nuevas por segundo para
bloquear el servicio. 2200 peticiones de conexión por segundo ocupan al
menos 700Kbps de ancho de banda, recurso no disponible para la mayoría
de los atacantes y que puede contrarrestarse reduciendo el tiempo de
vida de las sesiones a medio abrir o aumentando la cantidad de memoria
libre para gastar en esta protección.

b. Otros sistemas operativos, además del punto anterior, siguen la
filosofía de no reservar memoria para una sesión hasta que se ha
completado la conexión al 100%. Para ello utilizan técnicas
criptográficas reto-respuesta que aseguran que un atacante malicioso no
pueda utilizar IPs remitentes falsificadas.

En Linux, el reto criptográfico emplea 24 bits, lo que supone que, de
media, un atacante debe enviar unos ocho millones de datagramas para
poder conseguir que uno solo de ellos se considere creador de una
conexión válida. El resto se ignoran.

Aunque ocho millones de datagramas es muy poco en términos de
resistencia criptográfica, si pensamos que el ataque debe realizarse a
través de una red de datos, lo convierte en poco probable en la
práctica.

En el caso de Linux un atacante con suficiente recursos sólo conseguirá
que el Kernel acepte una conexión de cada ocho millones (en media) que
esté intentando.

Aunque tan minúscula proporción no sea muy atractiva como ataque DoS, sí
supone un grave riesgo de seguridad si estamos utilizando reglas de
cortafuegos que verifiquen el flag «Syn», ya que la conexión atravesaría
la regla del cortafuegos y se establecería. Una vez establecida, un
atacante podría enviar o recibir datos a través de la misma sin
interferencia del cortafuegos.

Una posible solución es deshabilitar el uso de «SynCookies» mediante el
comando «echo 0 > /proc/sys/net/ipv4/tcp_syncookies», aunque ello
limitaría la resistencia del sistema ante un ataque DoS del tipo «Syn
Flood».

Otra solución es parchear el kernel de forma que sólo se active la
protección «SynCookie» para los puertos que estén siendo atacados, no de
forma global para toda la máquina. Dado que el atacante debe tener
acceso al puerto para poder atacarlo, si tenemos el puerto filtrado por
«Syn» en el cortafuegos, éste no será accesible al atacante y no podrá,
por tanto, desarrollar el ataque.

El ataque en sí requiere que:

a) El kernel tenga activada la opción de «SynCookie».
b) Tengamos activado el cortafuegos, y deben existir reglas «Syn».
c) El atacante tenga acceso a, al menos, un puerto «abierto»: servidor
web, servidor de IRC, SMTP, etc.

El ataque se produce de la siguiente manera:

a) El atacante realiza un «Syn Flood» sobre el puerto «público» del
servidor, para desencadenar la respuesta «SynCookie» de la máquina.

b) El atacante envía datagramas al puerto que desea «conectar»,
intentando forzar el «hash» criptográfico. En media se necesitan unos
ocho millones de datagramas, lo que hace el ataque poco práctico, si
bien puede tener suerte y conseguir entrar al primer intento…

c) Una vez vulnerado el cortafuegos, puede enviar y recibir datos a
través de la conexión abierta, de forma libre.

Todos los kernel Linux con soporte «Syncookie» (a partir de la serie
2.0.*, inclusive) son vulnerables al ataque. Se recomienda actualizar a
los últimos kernel, 2.2.20 o 2.4.14, versiones *NO* vulnerables.

Gracias a los beneficios del código «Open Source», los administradores
que no puedan actualizar el kernel, pueden aplicar directamente el
siguiente parche o uno similar:

diff -urN linux.orig/include/net/sock.h linux/include/net/sock.h
- --- linux.orig/include/net/sock.h Wed Aug 15 22:21:32 2001
+++ linux/include/net/sock.h Wed Nov 7 14:24:36 2001
@@ -416,6 +416,8 @@
 unsigned int keepalive_time; /* time before keep alive takes place */
 unsigned int keepalive_intvl; /* time interval between keep alive probes */
 int linger2;
+
+ unsigned long last_synq_overflow;
 };
 
 
diff -urN linux.orig/net/ipv4/syncookies.c linux/net/ipv4/syncookies.c
- --- linux.orig/net/ipv4/syncookies.c Wed May 16 18:31:27 2001
+++ linux/net/ipv4/syncookies.c Wed Nov 7 14:23:54 2001
@@ -9,7 +9,7 @@
 * as published by the Free Software Foundation; either version
 * 2 of the License, or (at your option) any later version.
 * 
- - * $Id: syncookies.c,v 1.14 2001/05/05 01:01:55 davem Exp $
+ * $Id: syncookies.c,v 1.17 2001/10/26 14:55:41 davem Exp $
 *
 * Missing: IPv6 support. 
 */
@@ -23,8 +23,6 @@
 
 extern int sysctl_tcp_syncookies;
 
- -static unsigned long tcp_lastsynq_overflow;
- -
 /* 
 * This table has to be sorted and terminated with (__u16)-1.
 * XXX generate a better table.
@@ -53,7 +51,9 @@
 int mssind;
 const __u16 mss = *mssp;
 
- - tcp_lastsynq_overflow = jiffies;
+ 
+ sk->tp_pinfo.af_tcp.last_synq_overflow = jiffies;
+
 /* XXX sort msstab[] by probability? Binary search? */
 for (mssind = 0; mss > msstab[mssind + 1]; mssind++)
 ;
@@ -78,14 +78,11 @@
 * Check if a ack sequence number is a valid syncookie. 
 * Return the decoded mss if it is, or 0 if not.
 */
- -static inline int cookie_check(struct sk_buff *skb, __u32 cookie) 
+static inline int cookie_check(struct sk_buff *skb, __u32 cookie)
 {
 __u32 seq; 
 __u32 mssind;
 
- - if ((jiffies - tcp_lastsynq_overflow) > TCP_TIMEOUT_INIT)
- - return 0; 
- -
 seq = ntohl(skb->h.th->seq)-1; 
 mssind = check_tcp_syn_cookie(cookie,
 skb->nh.iph->saddr, skb->nh.iph->daddr,
@@ -126,8 +123,8 @@
 if (!sysctl_tcp_syncookies ¦¦ !skb->h.th->ack)
 goto out;
 
- - mss = cookie_check(skb, cookie);
- - if (!mss) {
+ if (time_after(jiffies, sk->tp_pinfo.af_tcp.last_synq_overflow +
TCP_TIMEOUT_INIT) ¦¦
+ (mss = cookie_check(skb, cookie)) == 0) {
 NET_INC_STATS_BH(SyncookiesFailed);
 goto out;
 }
@@ -178,7 +175,7 @@
 opt && 
 opt->srr ? opt->faddr : req->af.v4_req.rmt_addr,
 req->af.v4_req.loc_addr,
- - sk->protinfo.af_inet.tos ¦ RTO_CONN,
+ RT_CONN_FLAGS(sk),
 0)) { 
 tcp_openreq_free(req);
 goto out; 

Más información:

Linux Syn Filter Evasion Vulnerability
http://www.securityfocus.com/bid/3505

Ataques masivos. ¿Es tan fiero el león como lo pintan?
http://www.hispasec.com/unaaldia.asp?id=474

[suse-security-announce] SuSE Security Announcement: kernel (update)
(SuSE-SA:2001:039)
http://www.suse.com/de/support/security/2001_039_kernel2_txt.txt

Syncookie vulnerability
http://www.linuxsecurity.com/advisories/other_advisory-1683.html

Linux – syncookies firewall breaking problem
http://www.caldera.com/support/security/advisories/CSSA-2001-038.0.txt

kernel 2.2 and 2.4: syncookie vulnerability
http://www.redhat.com/support/errata/RHSA-2001-142.html