Iptables reglas contra fuerza bruta, escaneos

Hacked

Para evitar o paliar que evadan, esquiven nuestras medidas de seguridad, podemos añadir determinadas reglas contra servicios abiertos a todo el mundo, que eviten por ejemplo ataques de fuerza bruta. A pesar de contar con firewall, siempre puede existir alguna manera de evadirlo (técnicas como firewalk, polluting de peticiones, enmascaramientos o falsificaciones)

En nuestro caso, el servicio que limitamos el número de intentos fallidos, es contra ssh, pero combinando estas reglas con determinadas cadenas de texto como vimos en el siguiente artículo , podríamos limitar el número de intentos de acceso a un determinado formulario php de login de wordpress:

#Anti-Bruteforce for SSH
iptables -N SSHSCAN
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent –set –name SSH
iptables -A SSHSCAN -m recent –update –seconds 3600 –hitcount 5 –name SSH -j DROP
iptables -A SSHSCAN -m recent –update –seconds 3600 –hitcount 5 –name SSH -j LOG –log-level info –log-prefix “Anti SSH-Bruteforce: ”

Otras variantes que protegen contra fuerza bruta y escaneo de un servicio podrían ser las siguientes:
iptables -N SCAN
iptables -A SCAN -p tcp –dport 25 -m recent –set –name SMTP
iptables -A SCAN -p tcp –dport 22 -m recent –set –name SSH
iptables -A SCAN -p tcp –dport 21 -m recent –set –name FTP
iptables -A SCAN -m recent –update –seconds 300 –hitcount 5 –name SMTP -j DROP
iptables -A SCAN -m recent –update –seconds 300 –hitcount 5 –name SSH -j DROP
iptables -A SCAN -m recent –update –seconds 300 –hitcount 5 –name FTP -j DROP

Otra manera de implementar dicha protección sin tener que crear una cadena nueva y añadirla a las de entradas:
iptables -A INPUT -p tcp –dport 22 –syn -m limit –limit 1/m –limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp –dport 22 –syn -j DROP

En estas webs, encontramos una combinación de límite para el servicio dns para intentar detener los últimos ataques de amplificación dns:
http://server-support.co/blog/sysadmin/block-recursive-dns-queries-with-iptables-rate-limiting-rules/
http://www.junkemailfilter.com/blog/2013/03/03/how-to-block-dns-amplification-attack-isc-org-any-attack/

iptables -v -A INPUT -p udp –dport 53 -m recent –set –name dnsanyquery
iptables -v -A INPUT -p udp –dport 53 -m recent –name dnsanyquery –rcheck –seconds 1 –hitcount 10 -j DROP

Por último, vamos a intentar paliar los escaneos que pueden hacer sobre nuestros servidores mediante herramientas como nmap (y sus scripts NSE) o nc, aunque en artículos leídos en blogs, había un intenso debate sobre si realmente se puede evitar que te escaneen un puerto (aunque más adelante trataremos qué otras medidas adicionales podemos tomar para proteger los servicios como poner ports honeypots, port-knocking para determinados servicios, o otro tipo de medidas).

Antes de ponernos de lleno con las reglas, hemos de saber que con nmap y otras herramientas se pueden hacer determinados tipos de scaneos, como podemos ver de la propia entrada de nmap:
nmap_logo_vx
-sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans
-sU: UDP Scan
-sN/sF/sX: TCP Null, FIN, and Xmas scans
–scanflags : Customize TCP scan flags
-sI : Idle scan
-sY/sZ: SCTP INIT/COOKIE-ECHO scans
-sO: IP protocol scan
-b : FTP bounce scan

No entramos en detalle en cómo funciona cada tipo de escaneo, sino en que simplemente en función de las pruebas realizadas por el programa que escanea, y la respuesta que tiene, puede saber si un puerto está ofreciendo un servicio aunque esté enmascarado, redireccionado, o que utilice otras técnicas para proteger su servicio. Dicho esto, hay conjuntos de reglas que pueden ayudar a prevenir
escaneos, bien sea de un robot o de un humano en un proceso de gathering de nuestro sistema:

A) Escaneo Syn, Ack, Fin, o Rst:
iptables -A port-scan -p tcp –tcp-flags SYN,ACK,FIN,RST RST -m limit –limit 1/s -j RETURN
iptables -A port-scan -j DROP

B) Xmas, banner scan y otros:
iptables -A INPUT -p tcp –tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp –tcp-flags ALL FIN,URG,PSH -j DROP
iptables -A INPUT -p tcp –tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -p tcp –tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp –tcp-flags ALL FIN -j DROP

C) Antifragmentos: iptables -A INPUT -f -j DROP

D) Descartar paquetes nulos: iptables -A INPUT -p tcp –tcp-flags ALL NONE -j DROP

No he trabajado con netcat, así que este espectro de reglas sólo te pueden servir contra procesos de escaneo o gathering de nmap o aplicaciones que utilicen dichos métodos de detección de servicios. En caso de uso de otras herramientas, es posible que a pesar de tener estos paquetes, puedan existir maneras de conseguir saber si determinado puerto está abierto, filtrado o cerrado con herramientas como netcat.

Las referencias de estas reglas, muchas las podréis encontrar
http://volc-hara.blogspot.com.es/2008/03/iptables-anti-scan-tricks.html
http://www.techrepublic.com/blog/10things/10-iptables-rules-to-help-secure-your-linux-box/539
http://petermolnar.eu/linux-tech-coding/hardening-iptables-config-with-the-goodie-of-limit-rates/
http://support.novell.com/techcenter/articles/nc2001_03.html

Anuncios

Iptables NAT (snat y dnat) dport y balanceo

Continuamos con nuestra pequeña revisión de las capacidades de iptables en cuanto a la gestión de paquetes tcp/udp.

A día de hoy está tan extendido su uso, que entiendo que cualquier firewall implementa una variable de linux con iptables con un frontend de apache y una pequeña base de datos.

images (1)

Entre sus funcionalidades nos encontramos que podemos redirigir tráfico destinado a un puerto hacia otro, quedando una regla de ejemplo para aclararlo como la que sigue:

descarga (2)

iptables -A PREROUTING -t nat -i eth0 -p tcp –dport 80 -j REDIRECT –to-port 8080

Con la anterior regla estamos diciendo al sistema que todas las peticiones que vengan al puerto 80 sean enviadas al 8080 de la máquina. Esto mismo es lo que hace apache con un módulo que envía las peticiones que recibe apache (mod_jk) y las manda a tomcat.

También nos permite hacer NAT (o network adress translation) lo que muchas veces nos salvará cuando sólo dispongamos de una ip pública, montar una infraestructura de varias máquinas con ips internas bien mediante una máquina linux con iptables bien con un firewall de otras marcas.

Dentro de nat, existen diferentes tipos, como por ejemplo, hacer nat desde el origen (source nat o snat), que es lo que sucede cuando utilizamos el adsl de nuestra casa. Nuestra ip de rango privado 192.168.X.X es convertida “misteriosamente” en rango público. Esto se puede implementar con firewalls o linux con iptables que trabajan en capa 3. Las reglas para implementar un cambio de este tipo serían del estilo:

descarga

## Cambiar la dirección de origen por 192.168.2.1
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT –to 192.168.2.1
## Cambiar la dirección de origen a 192.168.2.1, 192.168.2.2 o 192.168.2.3
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT –to 192.168.2.1-192.168.2.3
## Cambiar la dirección de origen por 192.168.2.1, puertos 1-1023
# iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT –to 192.168.2.1:1-1023

Existe también un tipo de nat que permite hacer nat en el destino (dnat). Las reglas aplicables en ese caso:

## Cambia la dirección de destino por 192.168.2.1
# iptables -t nat -A PREROUTING -i eth1 -j DNAT –to 192.168.2.1

## Cambia la dirección de destino por 192.168.2.1, 192.168.2.2 o 192.168.2.3.
# iptables -t nat -A PREROUTING -i eth1 -j DNAT –to 192.168.2.1-192.168.2.3

## Cambia la dirección de destino del tráfico web por 192.168.2.1,
## puerto 8080.
# iptables -t nat -A PREROUTING -p tcp –dport 80 -i eth1 \
-j DNAT –to 192.168.2.1:8080

También es posible hacer dnat no sólo de todo el tráfico que entra, sino de una interfaz hacia otra:
iptables -t nat -A OUTPUT -p tcp -d 192.168.0.74 –dport 80 -j DNAT –to-destination 192.168.0.17:80

Con esta regla estamos indicando que todo el tráfico que venga por la interfaz de salida del propio firewall con ip 192.168.0.74 al puerto 80 vaya hacia la ip 192.168.0.17 al puerto 80.

Otras variantes de lo explicado anteriormente es la realización de dnat y dport al mismo tiempo, cambiamos la ip y puerto origen a ip y puertos destino :
iptables -t nat -A POSTROUTING -p tcp -s 192.168.1.2 –sport 12345:12356 -d 123.123.123.123 –dport 22 […]

Estamos indicando que el tráfico que provenga de la ip 192.168.1.2 del rango de puertos 12345 hasta el 12356 vayan hacia la ip 123.123.123.123 al puerto 22. Con eso no sólo hacemos un dnat, sino también un dport.

Esto es porque iptables trabaja en capa 3, lo cual también lo habilita para hacer funciones de balanceo, como en los siguientes ejemplos:

Para aplicar estas reglas de balanceo, se necesita la extensión de iptables nth.
Los siguientes ejemplos balancean el tráfico https a 3 direcciones ips diferentes. Por cada tercer paquete, este se balancea al servidor apropiado:

iptables -A PREROUTING -i eth0 -p tcp –dport 443 -m state –state NEW -m nth –counter 0 –every 3 –packet 0 -j DNAT –to-destination 192.168.1.101:443
iptables -A PREROUTING -i eth0 -p tcp –dport 443 -m state –state NEW -m nth –counter 0 –every 3 –packet 1 -j DNAT –to-destination 192.168.1.102:443
iptables -A PREROUTING -i eth0 -p tcp –dport 443 -m state –state NEW -m nth –counter 0 –every 3 –packet 2 -j DNAT –to-destination 192.168.1.103:443

Las referencias empleadas en el desarrollo del artículo podemos encontrarlas en:
http://www.netfilter.org/documentation/HOWTO/es/NAT-HOWTO-7.html
http://www.karlrupp.net/en/computer/nat_tutorial
http://www.blissend.com/?q=node/7

Nos veremos en el próximo capítulo que tratará sobre reglas antiescaneo y un pequeño compendio que deberíamos tener en nuestro firewall.

Iptables antiabuso

Investigando paquetes de reglas para iptables, dí con paquetes específicos que nos protegen contra determinados ataques del cual vamos a hablar hoy. Son ataques que pretenden derribar un servicio nuestro o ajeno, y que pueden formar parte de una botnet, como en la imagen se detalla.

DDoS-network-map

DNS

simpledns

Con las siguientes reglas tendremos más protección en nuestro servicio dns limitando el número de consultas a 20 en 10 segundos al servicio de dns:

iptables -t filter -I INPUT 1 -p udp –dport 53 -i eth0 -m recent –set
iptables -t filter -I INPUT 2 -p udp –dport 53 -i eth0 -m recent –update –seconds 10 –hitcount 20 -j DROP

HTTP

descarga

Con estas reglas, nuestra intención es la de imitar la protección del servicio dns que hemos configurado anteriormente con el servicio http. Podemos probar y utilizar aquella que mejor se ajuste a nuestras necesidades. Son distintas aproximaciones de un mismo fin:

A) iptables -A INPUT -p tcp –dport 80 -m hashlimit –hashlimit-upto 50/min –hashlimit-burst 80 –hashlimit-mode srcip –hashlimit-name http -j ACCEPT
B) iptables -A INPUT -p tcp –dport 80 -m state –state NEW -m limit –limit 50/minute –limit-burst 200 -j ACCEPT
C) iptables -t filter -I INPUT 2 -p tcp –dport 80 -i eth0 -m recent –update –seconds 10 –hitcount 20 -j DROP

Para comprobar si están funcionando, podemos configurarlas en un entorno de desarrollo y realizar con herramientas numerosas peticiones. Existen herramientas de pruebas de rendimiento como ab (apache benchmark) o generarnos nosotros un ataque de denegación de servicio con Low Orbit Ion Cannon, una herramienta pensada para hacer este tipo de ataques.

UDP FLOOD

Las siguientes reglas las configuraremos para prevenir que nuestro servidor no haga ataques de inundación udp (teardrop attack) sobre otros servidores/servicios:

iptables -N udp-flood # Creamos nueva cadena
iptables -A OUTPUT -p udp -j udp-flood # La ponemos en las reglas de salida
iptables -A udp-flood -p udp -m limit –limit 200/s -j RETURN # Limitamos a 200 peticiones de salida por segundo
iptables -A udp-flood -j LOG –log-level 4 –log-prefix ‘UDP-flood attempt: ‘ # Registramos en los logs de iptables intento de udp flooding
iptables -A udp-flood -j DROP # Descartamos el tráfico de udp-flood

Otra alternativa a esas reglas sería la de establecer:
iptables -A INPUT -p UDP -f -j DROP

Por último, procedemos a proteger nuestro servidor de ataques de inundación SYN (SYN flooding):

# SYN-Flood protection in a user defined chain
iptables -N syn-flood # De nuevo creamos una cadena de nombre syn-flood
iptables -A INPUT -p tcp –syn -j syn-flood # Indicamos que la nueva cadena de entrada es de paquetes de entrada de tipo tcp y syn
iptables -A syn-flood -m limit –limit 30/s –limit-burst 60 -j RETURN # Limitamos el límite de paquetes syn de entrada a 60 cada 30 segundos
iptables -A syn-flood -j LOG –log-level 4 –log-prefix ‘SYN-flood attempt: ‘ # Registramos los intentos de flooding syn (para devolver el ataque o reportar a listas negras e informar de infección o equipo que forma parte de una botnet)
iptables -A syn-flood -j DROP # Descartamos el tráfico de inundación.

También podemos implementar reglas contra servicios adicionales como ping limitando la entrada/salida del mismo o denegándolo:
iptables -A INPUT -p icmp -m state –state NEW –icmp-type echo-request -m limit –limit 1/s –limit-burst 1 -j ACCEPT (limitamos tráfico ping de entrada)
iptables -A OUTPUT -p icmp –icmp-type echo-request -j DROP (descartamos tráfico ping de salida)

Las referencias empleadas en este artículo:

http://blog.bodhizazen.net/linux/prevent-dos-with-iptables/
http://www.58bits.com/blog/2012/12/11/a-udp-flood-story/

Nos veremos en próximas actualizaciones de reglas para iptables para finalmente tener un pack y una visión general de tipos de ataques y la produndidad de defensa y alcance que iptables nos brinda.

Iptables screening filters

Hoy vamos a tratar de reglas de iptables que utilizan de un módulo de iptables que es capaz de analizar cadenas en paquetes y bloquear dichos paquetes donde vengan esas cadenas, lo que se conoce como DPI (Deep Packet Inspection) o bien con reglas que deniegan conexiones por sobrepasar un determinado tiempo de conexión.

photo_1011_20060203

Hay que adelantar que hacer DPI sobre sitios con mucha carga de tráfico puede provocar problemas. Para ello están los ingenieros o arquitectos de infraestructuras y/o aplicaciones que son capaces de dimensionar la plataforma y diseñarla para que sea escalable en función de las necesidades del servicio.

Las reglas que filtran por cadenas de texto, las he obtenido del siguiente enlace: http://www.securitybydefault.com/2011/05/iptables-like-pr0.html , es un blog de seguridad al que sigo y que publica artículos muy interesantes. Si os interesa la seguridad, recomiendo encarecidamente su suscripción. Las reglas que indico como ejemplo serían:

iptables -A INPUT -p tcp –dport 80 -m string –string “/etc/passwd” –algo kmp -j LOG –log-ip-options –log-tcp-options –log-prefix “passwd access ”
iptables -A INPUT -p tcp –dport 80 -m string –string “/etc/passwd” –algo kmp -j DROP

Existen otras webs y referencias donde bloquean otros tipos de cadenas, por ejemplo bloqueo de determinados patrones de inyección, aunque para eso ya hay otras utilidades como firewalls de aplicación o waf (web application firewall) o bien reglas de ids como snort, donde ya tienen definidos determinados parámetros y van sacando actualizaciones o appliances como los de f5 que también tienen reglas para prevención de este tipo de ataques o bien los que están por llegar y sobre los que no he investigado mucho de los NGFW o Next Generation Firewall o firewalls de siguiente generación.

Por ejemplo, se podrían bloquear agentes de navegación que fueran sospechosos, aunque ya existe el archivo robots.txt para ello, en esta regla encontramos un ejemplo de lo que indico:
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “User-Agent: sipcli” –algo bm –to 65535 -m comment –comment “deny sipcli” -j SIPDOS

Se podría hacer algún script que analizara los logs de acceso de apache y encontrara errores 404 y si se observan más de X peticiones desde una misma ip con un mismo agente y obtiene varios 404, entenderemos que es un robot, y se podría generar automáticamente una regla de iptables o bien que bloqueara la ip o bien que bloqueara la cadena del agente o robot lo que nos permitiría bloquear en un espectro más amplio ya que dicho robot seguramente pueda venir a visitarnos desde diferentes ips o bien de tor o bien de China y países similares:
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “User-Agent: sipcli” –algo bm –to 65535 -m comment –comment “deny sipcli” -j SIPDOS

Aunque ya sabemos también que no es difícil para estos robots, cambiar y disfrazar el agente que nos visita, para lo cual, existen otros mecanismos de protección web que mencionaré más adelante.

Como última entrada en la actualización de hoy, detallaremos cómo bloquear accesos a aquellas conexiones que han establecido conexión durante un determinado tiempo. Esto yo sólo lo veo útil para el caso de servicios que no tienen timeout, para forzar expiración de cookies de conexiones, es decir que una conexión no esté más de determinado tiempo abierta y forzamos a que el cliente tenga que conectar de nuevo generando un nuevo id. Con esto podríamos prevenir hijacking de cookies:

iptables -A INPUT -p tcp –dport 22 -m state –state NEW,ESTABLISHED -m time –timestart 09:00 –timestop 18:00 –weekdays Mon,Tue,Wed,Thu,Fri -j ACCEPT
iptables -A INPUT -p tcp –dport 22 -m state –state NEW,ESTABLISHED -j DROP

En este caso la regla está destinada a proteger el servicio ssh. Se podría añadir la ip origen, servicio http, string el dominio de acceso, y con eso forzar que cada ip de conexión tenga un determinado tiempo de conexión, aunque eso es algo que se puede definir a nivel de aplicación, por lo que entiendo que no atañe a iptables, y la mayoría de servicios que corren bajo nuestro sistema vienen con un timeout tanto para conexiones inactivas o ociosas como para conexiones activas.

Seguiré actualizando el blog con más paquetes de reglas que podrían venir bien tener en nuestro servidor.

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