Iptables blocking broadcast y multicast

ID-1008828
Dentro del compendio de reglas que se pueden añadir a iptables (que también existen módulos iptables ( -m pkttype–pkt-type) que implementan el tipo de bloqueo de tráfico del que tratamos a continuación, y también se puede tratar mediante parametrización de la pila tcp/ip del kernel de linux), podemos añadir también reglas para bloqueo de tráfico broadcast.

¿Por qué bloquear este tipo de tráfico?

Son direccionamientos especiales, donde enviar tráfico a la dirección de broadcast supone envío de tráfico a todas las máquinas, se utiliza por arp para hacer descubrimientos de redes, o también para hacer descubrimentos por otros protocolos como netbios.  Si se envía tráfico de manera indiscriminada a una dirección de broadcast, este se propagará por todas las ips del segmento de red al que pertenezca esa dirección broadcast.

Algo parecido sucede con tráfico multicast, con la diferencia que este tráfico en lugar de ser a todos, es de uno a muchos o de muchos a muchos. Permitir este tipo de tráfico sin ningún control podría conllevar a problemas de red o saturación de la misma.

Las reglas que he visto a nivel de iptables sin añadir módulos, no me convencen, ya que la red puede estar segmentada (vlan) y las direcciones broadcast y multicast pueden variar de las siguientes reglas:

iptables -A OUTPUT -s 0/0 -d 255.255.255.255 -o eth0 -j DROP
iptables -A INPUT -s 0/0 -d 255.255.255.255 -i eth0 -j DROP
iptables -A OUTPUT -s 0/0 -d xx.xx.xx.255 -o eth0 -j DROP
iptables -A INPUT -s 0/0 -d xx.xx.xx.255 -i eth0 -j DROP

por lo que no añadiría dichas reglas a nuestro firewall.

El bloqueo de este tipo de tráfico se hace a nivel de elementos de red, aunque también se puede implementar a nivel de servidor dedicado bloqueando tráfico de salida hacia esas direcciones. En este caso, podríamos implementarlo como:

A nivel de kernel:

/bin/echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Con módulos adicionales de iptables, bloqueandopor tipo de paquetes:

/sbin/iptables -I INPUT -m pkttype –pkt-type broadcast -j DROP
/sbin/iptables -I INPUT -m pkttype –pkt-type multicast -j DROP

Personalmente, en lugar de tráfico broadcast de entrada, bloquearía el tráfico broadcast de salida de la máquina:

/sbin/iptables -I OUTPUT -m pkttype –pkt-type broadcast -j DROP
/sbin/iptables -I OUTPUT -m pkttype –pkt-type multicast -j DROP

Pero esto implica añadir módulos a iptables por lo que quizás tengas que recompilar el kernel.

Otra tercera opción sería bloquear tráfico a la dirección broadcast del segmento de red al que pertenezca tu máquina, independientemente del tipo de ataque (flood syn, flood udp…) o del tipo de tráfico que salga de tu servidor (tcp, udp)-

La opción más viable sea configurar correctamente la pila tcp/ip, tema que trataremos más adelante.

Iptables tcp flags filtering

Cuando se establece una comunicación cliente-servidor, el inicio de  ese proceso se conoce como three-way-handshake, o lo que es lo mismo, modo “3 apretones de manos”.

Esto quiere decir, por la propia descripción,  que el proceso del inicio de  la comunicación es:

Cliente: Manda un paquete tcp con el flag de syn contra la máquina que quiere conectar, en este caso el servidor que sirve la aplicación

Servidor: Recibe ese paquete syn y se lo hace saber al cliente mandándole a su vez otro paquete tcp con los flags de SYN+ACK

Cliente: El cliente ha de hacer saber al servidor de alguna manera, que el servidor se ha enterado de que el cliente quiere establecer comunicación  (o lo que es lo mismo, el cliente tiene que decir al servidor que ha recibido ese paquete tcp con los flags SYN y ACK), por lo que el cliente manda un paquete tcp con el flag ACK al servidor.

Como una imagen vale más que mil palabras:

3way-handshake

Una vez el cliente manda el ACK al servidor, el cliente comenzará a transmitir datos.

Existen distintos tipos de ataques a máquinas, por ejemplo, inundación SYN, un cliente manda un paquete SYN para iniciar una comunicación pero no espera a que el servidor le devuelva un SYN+ACK, sino que le vuelve a mandar paquetes SYN, hasta que degrada el servicio del servidor, o split handshake (saludo dividido) http://watchguardsecuritycenter.com/2011/04/15/what-is-the-tcp-split-handshake-attack-and-does-it-affect-me/, donde un cliente manda un SYN a un servidor y el cliente recibe un ACK de dos máquinas, una que no es el servidor, pero el cliente mandará peticiones al servidor.

Es por eso, que como iptables actúa a nivel de kernel, y es capaz de ver el campo flag de los paquetes tcp/ip, podemos forzar que a  nuestro servidor reciba flags sólo en un determinado orden, para evitar ese tipo de ataques (bien es cierto que para evitar flood SYN, también se puede configurar a nivel de pila tcp/ip del sistema).

Es posible a través de iptables filtrar aquellos flags tcp que no cumplen con este procedimiento de inicio de comunicación o que sean sospechosos de un posible ataque:

Así, podrían marcarse como BADFLAGS, las siguientes flags de paquetes tcp recibidos:

// TCP_FLAGS — check tcp flags
iptables -N TCP_FLAGS
iptables -A TCP_FLAGS -p tcp –tcp-flags ACK,FIN FIN -j BADFLAGS
iptables -A TCP_FLAGS -p tcp –tcp-flags ACK,PSH PSH -j BADFLAGS
iptables -A TCP_FLAGS -p tcp –tcp-flags ACK,URG URG -j BADFLAGS
iptables -A TCP_FLAGS -p tcp –tcp-flags FIN,RST FIN,RST -j BADFLAGS
iptables -A TCP_FLAGS -p tcp –tcp-flags SYN,FIN SYN,FIN -j BADFLAGS
iptables -A TCP_FLAGS -p tcp –tcp-flags SYN,RST SYN,RST -j BADFLAGS
iptables -A TCP_FLAGS -p tcp –tcp-flags ALL ALL -j BADFLAGS
iptables -A TCP_FLAGS -p tcp –tcp-flags ALL NONE -j BADFLAGS
iptables -A TCP_FLAGS -p tcp –tcp-flags ALL FIN,PSH,URG -j BADFLAGS
iptables -A TCP_FLAGS -p tcp –tcp-flags ALL SYN,FIN,PSH,URG -j BADFLAGS
iptables -A TCP_FLAGS -p tcp –tcp-flags ALL SYN,RST,ACK,FIN,URG -j BADFLAGS
#—- Descarta el primer paquete de una conversación si no tiene glag SYN
iptables -A TCPFLAGS -p tcp ! –syn -m state –state NEW -j BADFLAGS
#—- Ayuda a prevenir TCP spoofing
iptables -A TCPFLAGS -p tcp –tcp-flags SYN,ACK SYN,ACK -m state –state NEW -j REJECT –reject-with tcp-reset
#—- FIN, PSH o URG deberían siempre venir acompañados por ACK
iptables -A TCPFLAGS -p tcp –tcp-flags ACK,FIN FIN -j BADFLAGS
iptables -A TCPFLAGS -p tcp –tcp-flags ACK,PSH PSH -j BADFLAGS
iptables -A TCPFLAGS -p tcp –tcp-flags ACK,URG URG -j BADFLAGS
#—- FIN, SYN y RST son exclusivos mútuamente
iptables -A TCPFLAGS -p tcp –tcp-flags FIN,RST FIN,RST -j BADFLAGS
iptables -A TCPFLAGS -p tcp –tcp-flags SYN,FIN SYN,FIN -j BADFLAGS
iptables -A TCPFLAGS -p tcp –tcp-flags SYN,RST SYN,RST -j BADFLAGS
#—- Paquetes sin flags no son válidos
$IPTABLES -A TCPFLAGS -p tcp –tcp-flags ALL NONE -j BADFLAGS

En donde definimos la cadena BADFLAGS como:

iptables -N BADFLAGS
iptables -A BADFLAGS -j LOG –log-prefix “IPT BADFLAGS: ” =logopt
iptables -A BADFLAGS -j DROP

O también poner una regla que descarte todos los paquetes que sean nuevos que no vengan con el flag de SYN:
iptables -A INPUT -p tcp ! –syn -m state –state NEW -j DROP

En general, se pueden definir conjuntos o paquetes de reglas que se carguen en un script para proteger nuestros servicios con iptables.

He utilizado como referencias para esta protección de iptables, los siguientes blogs:
http://www.kriptopolis.org/iptables-1
http://pikt.org/pikt/samples/iptables_tcp_flags_programs.cfg.html
Iré publicando más paquetes de reglas a lo largo del tiempo.

Puede encontrarse más información de iptables en el siguiente enlace: http://www.netfilter.org/documentation/index.html

Iptables screening masquerading os

Cuando intentas protegerte contra posibles ataques a través del firewall de iptables, me viene a la cabeza la técnica conocida como seguridad por oscuridad. Consiste en no dar más información de la necesaria al atacante, e intentar enmascarar cualquier tipo de información que se muestre, ya sea de una aplicación que ofrece un servicio a través de internet o de una intranet, ya sea a nivel de sistema operativo.

Seguramente ya conozcáis de qué voy a hablar a continuación, y es de que con una simple prueba de ping, puedes obtener información de un sistema remoto en base a su ttl. En el siguiente enlace http://noahdavids.org/self_published/TTL_values.html podréis ver a qué me refiero.

Cada sistema operativo de los descritos posee un valor que si no se cambia a nivel de sistema (pila tcp/ip) o instalar módulos de iptables como osf,  o a través de iptables, con herramientas como nmap, nessus o similares es posible que vean el sistema que corre en una determinada plataforma. Quise ver  si a nivel de iptables, podemos enmascarar el sistema que administramos de tal manera que no tengamos que modificar nada a nivel de sistema ni añadir módulos al kernel de linux.

Viendo que la tabla mangle de iptables se utiliza para la modificación de paquetes. En este caso nos interesa modificar los paquetes que salen de nuestra máquina, siendo el TTL lo que pretendemos modificar, por lo que deberíamos aplicar una regla como la siguiente:

iptables -t mangle -I OUTPUT -j TTL –ttl-set 200

Esto puede ayudarnos a prevenir exploits como los que hacen referencia en este artículo, que detectan el sistema operativo y en función de este, lanzan el troyano apropiado para ese sistema: http://www.theregister.co.uk/2012/07/11/multi_platform_backdoor/. De esta manera se engaña al exploit

 

Iptables screening against spoofed ips

Continuando con mi post anterior, y en la misma línea, el objetivo de las reglas de iptables que detallo a continuación es definir aquellas reglas que van a interactuar con tráfico de entrada provenientes de direcciones ip o rangos ips que no deberían de mandar peticiones.

Añadiendo estas reglas, no sólo bloquearemos ataques de denegación de servicio (no distribuidos), sino que evitaremos que puedan utilizar cualquier servicio de nuestro servidor, o bien mandar spam o bien realizar ataques contra nuestra máquina al menos desde esas ips.

Las reglas de iptables destinadas a este propósito son las siguientes:

iptables -A INPUT -s 10.0.0.0/8 -j DROP
iptables -A INPUT -s 169.254.0.0/16 -j DROP
iptables -A INPUT -s 172.16.0.0/12 -j DROP
iptables -A INPUT -s 127.0.0.0/8 -j DROP
iptables -A INPUT -s 224.0.0.0/4 -j DROP
iptables -A INPUT -d 224.0.0.0/4 -j DROP
iptables -A INPUT -s 240.0.0.0/5 -j DROP
iptables -A INPUT -d 240.0.0.0/5 -j DROP
iptables -A INPUT -s 0.0.0.0/8 -j DROP
iptables -A INPUT -d 0.0.0.0/8 -j DROP
iptables -A INPUT -d 239.255.255.0/24 -j DROP
iptables -A INPUT -d 255.255.255.255 -j DROP

Como puede verse en los rangos, se bloquean direcciones que no deberían de estar realizando peticiones de ningún tipo, y por eso se descarta cualquier tipo de tráfico proveniente de las mismas.

Iptables screening ddos rules

Los firewalls de juniper vienen con una plantilla de configuración contra determinados ataques conocida como screening que previene contra diferentes tipos de ataques.

El objetivo de este artículo es hacer un compendio de directivas que puedan cubrir un espectro de reglas útiles que puedan añadirse a iptables a modo del screening de juniper, siempre con precaución y no haciéndolas permanentes (no grabándolas a fichero), hasta que se compruebe que no se bloquea ningún servicio que no se debiera.

Una de los primeros problemas que nos enfrentaremos con iptables es intentar parar ataques de denegación de servicio, bien sea distribuido bien sea desde un único origen:

ANTIDoS/ANTIDDoS:

Bloqueamos paquetes con determinada longitud:

iptables -A INPUT -p tcp -d IP -m length –length 40:48 -j DROP
Bloqueamos paquetes con determinado ttl:
iptables -A INPUT -p tcp -s 0.0.0.0/0 -d IP -m ttl –ttl 111 -j DROP

SYN FLOOD PREVENTION:
$IPT -N syn-flood
$IPT -A INPUT -i eth+ -p tcp –tcp-flags SYN,ACK,FIN,RST RST -j syn-flood
$IPT -A FORWARD -i eth+ -p tcp –tcp-flags SYN,ACK,FIN,RST RST -j syn-flood
$IPT -A syn-flood -m limit –limit 4/s –limit-burst 16 -j RETURN
$IPT -A syn-flood -m limit –limit 75/s –limit-burst 100 -j RETURN -A syn-flood -j LOG –log-prefix “SYN FLOOD ” –log-tcp-sequence –log-tcp-options –log-ip-options -m limit –limit 1/second
$IPT -A syn-flood -j DROP

UDP FLOOD PREVENTION:
$IPT -A OUTPUT -p udp -m state –state NEW -j ACCEPT
$IPT -A OUTPUT -p udp -m limit –limit 100/s -j ACCEPT
$IPT -A OUTPUT -p udp -j DROP

Limitando el máximo de conexiones al puerto 80 (o otro puerto, en general defensa en capa 7):
$IPT -A INPUT -p tcp –dport 80 -m hashlimit –hashlimit-upto 50/min –hashlimit-burst 80 –hashlimit-mode srcip –hashlimit-name http -j ACCEPT
$IPT -A INPUT -p tcp –dport 80 -j DROP

Limita el máximo número de conexiones por minuto contra apache:
iptables -A INPUT -p tcp –dport 80 -m state –state NEW -m limit –limit 50/minute –limit-burst 200 -j ACCEPT

ICMP FLOOD:
Permite ping, pero a 1 paquete por segundo, evitar ataques ICMP Flood
$IPT -A INPUT -p icmp -m state –state NEW –icmp-type echo-request -m limit –limit 1/s –limit-burst 1 -j ACCEPT
$IPT -A INPUT -p icmp -j DROP

RECENT TABLE:
Por por cada ip en la tabla de recent si hace mas de x hits en x segundos, se descarta.
$IPT -I INPUT -p tcp –syn -m recent –set
$IPT -I INPUT -p tcp –syn -m recent –update –seconds 10 –hitcount 30 -j DROP

Nota: Algunas de las siguientes reglas de bloqueo DDOS (más bien mitigación), utilizan un parámetro como iplimit-above que quizás no venga con iptables que tengas instalado (con un man, deberías de poder ver si viene en la ayuda de iptables). Si es así, quizás te toque compilar el kernel con plugins para iptables/netfilter.

echo “Block DOS – Ping of Death” Bloquea por tamaño de paquetes icmp.
iptables -A INPUT -p ICMP –icmp-type echo-request -m length –length 60:65535 -j ACCEPT

echo “Block DOS – Teardrop” Bloque tráfico de entrada udp fragmentado
iptables -A INPUT -p UDP -f -j DROP

echo “Block DDOS – SYN-flood”
iptables -A INPUT -p TCP –syn -m iplimit –iplimit-above 9 -j DROP

echo “Block DDOS – Smurf”
iptables -A INPUT -m pkttype –pkt-type broadcast -j DROP
iptables -A INPUT -p ICMP –icmp-type echo-request -m pkttype –pkttype broadcast -j DROP
iptables -A INPUT -p ICMP –icmp-type echo-request -m limit –limit 3/s -j ACCEPT

echo “Block DDOS – Connection-flood”
iptables -A INPUT -p TCP –syn -m iplimit –iplimit-above 3 -j DROP

echo “Block DDOS – Fraggle” Bloquea tráfico udp de entrada broadcast y limitándolo a 3 paquetes por segundo
iptables -A INPUT -p UDP -m pkttype –pkt-type broadcast -j DROP
iptables -A INPUT -p UDP -m limit –limit 3/s -j ACCEPT

echo “Block DDOS – Jolt” Bloquea paquetes fragmentados ICMP:
iptables -A INPUT -p ICMP -f -j DROP

echo “Block DDOS – SMBnuke” Esta regla más que para parar un ataque DDOS es para bloquear el acceso al troyano SMBnuke
iptables -A INPUT -p UDP –dport 135:139 -j DROP
iptables -A INPUT -p TCP –dport 135:139 -j DROP