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.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s