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

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.