Mostrando entradas con la etiqueta iptables. Mostrar todas las entradas
Mostrando entradas con la etiqueta iptables. Mostrar todas las entradas

20 mayo 2011

Iptables like a pr0

Mucho tiempo ha pasado desde los albores del sistema firewall de Linux, los tiempos del comando Ipchains que tenía una funcionalidad bastante básica.

Con el advenimiento de Iptables el filtrado de paquetes en Linux dio un salto cualitativo en cuanto a funcionalidad y actualmente, existen opciones realmente interesantes que merecen la pena explorar. Veamos unas cuantas:


Iptables como IPS

Hace tiempo que los cortafuegos evolucionaron a partir de las típicas reglas IN / OUT / NAT y se convirtieron en 'IPSs' ampliando el formato de las reglas haciendo inspección completa del paquete y pudiendo permitir o denegar tráfico si el payload del paquete cumple una determinada característica, integrando el concepto IDS dentro del cortafuegos.

Iptables soporta filtrado de contenido permitiendo una variedad de reglas al-estilo-Snort. De hecho, existe un proyecto llamado fwsnort que integra todo el juego de reglas Snort dentro de IPtables.

Veamos un ejemplo sencillo de como buscar y detener tráfico sospechoso con Iptables. Buscamos el string "/etc/passwd" en cualquier paquete que vaya dirigido hacia el puerto 80:

# 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

De esta forma primero logeamos el paquete y posteriormente lo bloqueamos

Se puede dar el caso que el patrón que buscamos no sea posible representarlo usando ascii, para eso Iptables soporta reglas en formato Hex con el flag --hex-string

Reglas de acceso basadas en tiempo

Muchas veces mas allá del tipo de puertos que permitimos / denegamos basados en protocolos, tenemos la necesidad de aplicar lógica de tiempo a esas reglas. Por ejemplo, permitir acceso a la VPN corporativa en horario laboral parece una buena idea, pero mantener ese acceso durante los fines de semana puede no ser necesario.

Iptables permite crear reglas empleando valores de tiempo, tanto en el campo Hora como en el campo días-de-la-semana.

Veamos un ejemplo:

# 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

Con estas dos reglas, primero permitimos el acceso al servidor ssh (puerto 22) desde las 9 de la mañana hasta las 18, los días Lunes, Martes, Miércoles, Jueves y Viernes. La segunda regla bloquea el resto del tiempo el acceso al puerto 22

Conclusión: Iptables siempre gozó de una excelente fama por su rendimiento y fiabilidad como cortafuegos, a esa fama de fiable hay que sumar muy merecidamente la de versátil y moderno ya que en cuanto a funcionalidad, hay pocos sistemas de filtrado comerciales que puedan presumir de mayor funcionalidad
Leer más...

07 enero 2011

Recopilación de frontends para IPtables

Configurar iptables (netfilter) a mano puede ser una tarea algo tediosa, incluso para operaciones sencillas como configurar nuestro firewall personal. Admite un nivel de personalización bastante profundo por lo que normalmente requiere configuraciones algo extensas.

Por este motivo existen frontends que tratan de facilitar al usuario final la configuración proporcionando una interfaz amigable, o configuraciones más sencillas.

Las aplicaciones gráficas pueden ser de gran utilidad, sobre todo en ordenadores personales donde se quiera configurar el firewall:

- Firestarter: Uno de los conocidos, se configura mediante GUI (gnome) y nos permite algunas opciones extra como monitorizar entradas y salidas de tráfico.


- Guarddog: También bastante usado, pensado para escritorios KDE. Permite configuraciones sencillas y avanzadas, por lo que se adapta al nivel del usuario.


- KMyFirewall: Parecido a los anteriores y pensado para escritorios KDE.


- fwbuilder: Posiblemente uno de los más populares junto con Firestarter. Permite ser usado también mediante terminal y soporta más firewalls para otros sistemas, no solo iptables.


Por otro lado tenemos los frontends que se usan mediante terminal o ficheros de configuración. Especialmente útiles para automatizarlos mediante scripts, utilizarlos en servidores, o cualquiera de las ventajas que nos ofrece una terminal:

- ufw (Uncomplicated Firewall): Fue desarrollado por Canonical para Ubuntu, permite configuraciones muy sencillas y potentes. La parte mala es que al ser relativamente nuevo todavía no está incluido en los repositorios de muchas distribuciones (por ejemplo Debian a día de hoy lo tiene en testing y sid, pero no en stable). Personalmente, mi preferido y recomendado para usos no demasiado ninjas.

- shorewall: Sin duda es una de las estrellas en cuanto a popularidad, flexibilidad y potencia. Se interacciona con él mediante ficheros de configuración. Necesita múltiples ficheros, incluso para configuraciones simples. Está pensado para usuarios avanzados.

- uruk: Es un frontend muy ligero, lo que por un lado nos da facilidad a la hora de modificarlo a nuestro gusto, pero por otro nos limita a configuraciones no demasiado avanzadas. Funciona mediante un fichero de configuración en el que escribimos las reglas. Podemos ver su sintaxis en este fichero de ejemplo.

El criterio para seleccionar éstos frontends ha sido la calidad, popularidad y lanzamiento de versiones de cada uno, pero hay muchos, muchos más disponibles.

- Referencias:
Debian Firewalls
Artículo en Wikipedia sobre iptables / netfilter
Leer más...

04 agosto 2009

Mantente a salvo de las direcciones IP amenazantes

El Internet Storm Center del portal SANS.org guarda una relación de direcciones IP a modo de TOP que clasifica aquellas que están suponiendo una amenaza para nuestras máquinas. En dicha tabla, que se puede encontrar en esta dirección, se incluye el número de ataques reportados, así como las fechas de cuando se reportó por primera y última vez.

En este portal de seguridad también podemos encontrar otros tops y clasificaciones actualizadas diariamente en base a diversos factores (puertos con mayor actividad, países orígen con más ataques reportados...). Vienen bien, sobretodo para saber si "algo se avecina"...

Volviendo a la primera lista comentada, veo en commandlinefu.com, la página de tips para línea de comandos por excelencia y que debería estar en vuestros favoritos, un comando que gracias a unas cucharadas de curl, un poco de grep, una dósis de awk y otra de perl, es capaz de obtener esas direcciones IP que están suponiendo una amenaza para muchos sistemas:

curl -s http://isc.sans.org/ipsascii.html|grep -v '#'|awk '{print $1}'|perl -pi -e 's/(?:^0{1,})|(?:(?<=\.)0{1,}(?!\.))//g'|egrep -v '^192\.|^10\.|^172\.|^224\.'

Ya con esta lista, lo más normal sería por ejemplo aprovecharse de esta valiosa información y meterla en nuestra output chain del iptables. El comando completo sería el siguiente:

curl -s http://isc.sans.org/ipsascii.html|grep -v '#'|awk '{print $1}'|perl -pi -e 's/(?:^0{1,})|(?:(?<=\.)0{1,}(?!\.))//g'|egrep -v '^192\.|^10\.|^172\.|^224\.'|xargs -n1 sudo iptables -A OUTPUT -j DROP -d > 2&>1

La versión inicial tomaba como fuente la primera lista en html, pero en los comentarios se habla de la versión ASCII más fácilmente parseable que se encuentra en ipascii.html. Este script directamente elimina los ceros incluídos en las direcciones IP para el padding y demás, por lo que no hay que tener más consideraciones en cuenta.

He dejado primero el comando que saca la lista de direcciones IP para que hagáis lo que queráis con ella, ¡apartir de ahí no me responsabilizo de lo que commandlineeis!

Y vosotros, ¿tenéis algún comando que queráis compartir con todos nosotros?


ACTUALIZACIÓN : Modificado el script (egrep añadido al final) para evitar que en la lista se cuelen direcciones IP que puedan utilizarse en direccionamiento interno (la primera dirección IP que está en el TOP es una 10.X.X.X...) Desde SecurityByDefault recomendamos la monitorización de este sistema por lo menos los primeros días en caso de que se vaya a utilizar para evitar posibles fallos en esta automatización.

Leer más...