Cortafuegos

Tutorial creado por Kurt Seifried. Extraido de: http://es.tldp.org/Manuales-LuCAS/GSAL/gsal-19991128-htm/
16 de Febrero de 2006
Un cortafuegos consiste en filtrar el tráfico TCP-IP, generalmente en el punto donde la red se conecta a otra (p. ej. a Internet, a una LAN de clientes, etc), que puede ser no fiable (en el caso de Internet) o quizás incluso fiable (otro piso de tu edificio). Al igual que los cortafuegos de los grandes edificios, un cortafuegos de red puede evitar e incluso bloquear la extensión del ataque si un segmento se ve comprometido con éxito, al igual que su homónimo cortafuegos puede evitar que la red se siga viendo comprometida.

Linux ha tenido capacidad de cortafuegos desde hace ya un tiempo, en forma de ipfwadm, que era un filtro a nivel de paquetes muy sencillo. Con la llegada del kernel 2.1, se ha visto reemplazado por ipchains, que es un poco más sofisticado. Este a su vez se verá reemplazado en el propuesto kernel 2.4, con un filtrado de paquetes todavía más avanzado, que es más independiente. Sin embargo, ambos todavía siguen siendo filtros de paquetes, y no permiten características más avanzadas como la inspección de estados o algunos tipos de conexiones proxy. Sin embargo Linux soporta IPMASQ, una forma de NAT (Traducción de Direcciones de Red, Network Address Translation). El IPMASQ permite enganchar una red de ordenadores a Internet, pero haciendo un proxy de sus conexiones a nivel de IP. De tal forma que todo el tráfico parezca provenir y dirigirse a una máquina (la máquina Linux con IPMASQ), lo cual proporciona un alto grado de protección a la red interna. Como plus añadido, los clientes de la red interna NO necesitan configurar su proxy; mientas el servidor IPMASQ del Linux esté bien configurado y los clientes lo utilicen como su puerta de enlace por defecto, todo irá bien.

Ambos ipchains e ipfwadm proporcionan las siguientes funcionalidades:

  • bloqueo / permiso del paso de datos basado en IP/puerto/interface origen/destino
  • enmascaramiento de conexiones, basado en IP/puerto/interface origen/destino

Además, ipchains soporta:

  • redireccionamiento de puertos
  • creación de cadenas, para reglas y condiciones más complejas, más fácil de mantener
  • routing de calidad de servicio (QOS, Quality of Service), útil en conexiones de baja velocidad o saturadas
  • especificación de IP/puerto/interface además de especificación inversa (utilizando el !)

El HOWTO del cortafuegos y las páginas “man <command>” (ipchains o ipfwadm) se ocupan en gran detalle de la mecánica para la configuración de las reglas, pero en realidad no se ocupan de la estrategia para hacer un filtrado de forma segura. La primera elección que se debe hacer es si se va a seguir una política de denegación o de permisión por defecto, seguido de qué servicios y hosts se quiere permitir y bloquear.

Cuando se vaya a decidir la política, se debería escoger aquella que deniego todo por defecto, a menos que esté específicamente permitido (de forma que si existe un fallo, con suerte se vea minimizado vía política por defecto) o una política que permita todo y bloquee ciertos servicios/hosts. Generalmente suelo utilizar una política de denegación por defecto, pues de esta forma puedo arreglar errores y cambios de forma más segura que una política que permita el flujo de datos por defecto.

Pongamos por caso, se tiene un servidor asegurado vía filtrado con cortafuegos, ejecutando Apache, se instala WU-FTPD para uso interno (de modo que la gente pueda subir ficheros) a las 3 de la mañana, y se te olvida cambiar las reglas del cortafuegos. Si se ha escogido una política permisiva por defecto, cualquiera puede acceder al servidor ftp desde Internet, y además, cometiste el error de instalar una versión antigua que permitía a cualquiera comprometer la máquina. Si por otra parte, se sigue una política de denegación por defecto, no hubiesen accedido al servidor de ftp, ni lo hubiesen hecho tus usuarios, pero te darías cuenta más rápidamente. Los usuarios enfadados son algo más sencillo de tratar que una red que haya sido comprometida.

En esta sección, he decidido no tratar específicamente las reglas de filtrado del cortafuegos, daré ejemplos para cada servicio de red, puesto que para filtrar adecuadamente un protocolo primero hay que entender cómo se comporta. Por ejemplo, existe una gran diferencia entre filtrar el www y el ftp en cuanto a accesos internos y externos. Algunas reglas/conceptos generales:

IPFWADM

El Ipfwadm es un sólido paquete de filtrado para Linux, aunque carece de muchas características disponibles en Ipchains. Ipfwadm sólo soporta 3 objetivos para cada paquete: aceptar, denegar o rechazar, mientras que las reglas del ipchains se pueden dirigir a 6 objetivos, o a un objetivo definido por el usuario. En realidad, el Ipfwadm sólo es apropiado para un cortafuegos sencillo a nivel IP, enmascaramiento de IP y si se tiene previsto utilizar FreeS/WAN. Las opciones básicas son: especificar una dirección (dentro, fuera, o ambas, útil con el flag de interface), reglas de entrada, reglas de salida, reglas de redireccionamiento (pongamos que se tienen múltiples interfaces, también se ocupa de las reglas de enmascaramiento) y reglas de enmascaramiento que controlan el comportamiento del enmascaramiento (timeouts, etc). Se pueden insertar, añadir y borrar reglas, configurar políticas por defecto y listar todas las reglas. Aparte de eso es muy parecido a ipchains, con pequeñas variaciones. Lo que viene a continuación es un script apropiado para un servidor que está haciendo de bridge entre 2 redes (10.0.0.x en eth0, 10.0.0.1 y 192.168.0.x en eth1, 192.168.0.1) ejecutando un servidor de correo.

#!/bin/bash

#

# Primero limpiar todas las reglas

#

ipfwadm -f -I

ipfwadm -f -O

ipfwadm -f -F

#

# Permitir el redireccionamiento entre las dos redes y si no es entre # ellas, denegarlo

#

ipfwadm -F -a accept -P all -S 10.0.0.0/24 -i eth0 -D 192.168.0.0/24

ipfwadm -F -a accept -P all -S 192.168.0.0/24 -i eth1 -D 10.0.0.0/24

ipfwadm -F -p deny

#

# Y por supuesto hay que dejar que entren los paquetes

#

ipfwadm -I -a accept -P tcp -S 10.0.0.0/24 -i eth0 -D 192.168.0.0/24

ipfwadm -I -a accept -P tcp -S 192.168.0.0/24 -i eth1 -D 10.0.0.0/24

#

# Dejarles acceder al servidor de correo pero a nada más

#

ipfwadm -I -a accept -P tcp -S 10.0.0.0/24 -i eth0 -D 10.0.0.1 25

ipfwadm -I -a accept -P tcp -S 192.168.0.0/24 -i eth0 -D 192.168.0.1 25

ipfwadm -I -p deny

Ahora el FreeS/WAN soporta la serie 2.2.x del kernel, nunca se debería escoger ipfwadm sobre ipchains. Ipchains ofrece un grado de control mucho más afinado y es mucho más flexible que ipfwadm.

IPCHAINS

El ipchains contiene algunas características nuevas comparado con ipfwadm; se pueden crear cadenas de reglas (de aquí el nombre) y enlazarlas juntas, haciendo más sencilla la administración de cortafuegos. El ipchains soporta más objetivos que ipfwadm; se puede apuntar una regla a: ACCEPT, DENY, REJECT, MASQ, REDIRECT o RETURN o a una cadena definida por el usuario. Como tal es bastante potente, se podría, por ejemplo, redireccionar todos los paquetes destinados al puerto 80 (tráfico www) de mi puerta de enlace para que se redirigiesen al puerto local 3128, el servidor proxy de Squid. También se puede utilizar esto junto con el routing de calidad de servicio, el ejemplo dado en la documentación de ipfwadm es priorizar el tráfico sobre un enlace PPP, se le puede dar una prioridad más alta al tráfico de telnet que al de, pongamos, ftp, reduciendo los problemas de latencia causados por un enlace saturado. Por lo general, creo un fichero /etc/rc.d/init.d/ipchains-sh (o en cualquier otro lugar apropiado) y lo llamo inmediatamente después de que arranca la red, lo cual deja un tiempo pequeño durante el cual el servidor es vulnerable, pero mínimamente, pues todavía no se están ejecutando demonios de red.

El siguiente script es apropiado para una puerta de enlace ejecutándose con 2 interfaces, que es por lo que he utilizado el objetivo DENY en lugar de REJECT, de modo que se descarte el paquete y no se responda de ninguna manera, lo cual ralentiza los escaneos de red (puesto que esperan el timeout en lugar de recibir una respuesta) y revela menos información. También desaconsejaría guardar logs de los datos, a menos que se disponga de la suficiente cantidad de espacio en disco duro, puesto que cada paquete que se envía (varios bytes) se utilizan muchos bytes de disco duro para crear la entrada del log, siendo fácil saturar el syslog y/o el disco duro en una conexión rápida. La página del ipchains se encuentra en: http://www.rustcorp.com/linux/ipchains/

#!/bin/bash

#

# Este script configura las reglas apropiadas de un cortafuegos para un

# servidor con 2 interfaces ejecutándose como puerta de enlace.

#

# Si se planea utilizarlo, es necesario editar este script.

#

# Se supone que las máquinas internas hacen todas una llamada a la puerta

# de enlace, de modo que las reglas no bloquean el tráfico interno.

#

# Un par de variables

#

# ETH0IP es la dirección IP de ETH0 (el interfaz externo)

# ETH0NET es la red

# ETH0NETMASK es la máscara de red

# HOSTFIABLE1 es un host fiable (para administración de web/ssh)

# HOSTFIABLE2 es un host fiable (para administración de web/ssh)

# ETH1IP es la dirección IP de ETH1 (el interfaz interno)

# ETH1NET es la red

# ETH1NETMASK es la máscara de red

#

ETH0IP=1.1.1.1

ETH0NET=1.1.1.0

ETH0NETMASK=24

HOSTFIABLE1=1.5.1.1

HOSTFIABLE2=1.5.1.2

ETH1IP=10.0.0.1

ETH1NET=10.0.0.0

ETH1NETMASK=24

#

PATH=/sbin

# LIMPIAR TODAS LAS REGLAS

ipchains -F input

ipchains -F output

ipchains -F forward

# ANTI-SPOOFING

ipchains -A input -p all -j DENY -s 10.0.0.0/8 -i eth0 -d 0.0.0.0/0

ipchains -A input -p all -j DENY -s 127.0.0.0/8 -i eth0 -d 0.0.0.0/0

ipchains -A input -p all -j DENY -s 192.168.0.0/16 -i eth0 -d 0.0.0.0/0

ipchains -A input -p all -j DENY -s 172.16.0.0/16 -i eth0 -d 0.0.0.0/0

ipchains -A input -p all -j DENY -s $ETH0IP -i eth0 -d 0.0.0.0/0

# PRIMERO ICMP

ipchains -A input -p icmp -j ACCEPT -s $ETH0NET/$ETH0NETMASK -i eth0 -d 0.0.0.0/0

ipchains -A input -p icmp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0

# SSH

ipchains -A input -p tcp -j ACCEPT -s $HOSTFIABLE1 -i eth0 -d 0.0.0.0/0 22

ipchains -A input -p tcp -j ACCEPT -s $HOSTFIABLE2 -i eth0 -d 0.0.0.0/0 22

# BLOQUEO 1:1023

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1:1023

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1:1023

# BLOQUEO DE OTRAS COSAS

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1109

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1524

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1600

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 2003

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 2049

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 2105

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3001

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3001

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3128:3130

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3128:3130

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3306

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 3306

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 4444

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 6000:6100

ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 6000:6100

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 6667

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 7000

# ADMINISTRACIÓN DE WEB

ipchains -A input -p tcp -j ACCEPT -s $HOSTFIABLE1 -i eth0 -d 0.0.0.0/0 10000

ipchains -A input -p tcp -j ACCEPT -s $HOSTFIABLE2 -i eth0 -d 0.0.0.0/0 10000

ipchains -A input -p tcp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 10000

# REGLAS DE REDIRECCIONAMIENTO

ipchains -P forward DENY

ipchains -A forward -p all -j MASQ -s $ETH1NET/$ETH1NETMASK -d 0.0.0.0/0

NETFILTER

El NETFILTER es la siguiente generación de filtrado de paquetes para Linux. Debería de hacer otro tipo de cosas más fácilmente, como cortafuegos, IPSec, cualquier cosa que tenga que ver con la gestión de paquetes. El HOWTO se encuentra disponible en: http://netfilter.kernelnotes.org/

IPF

El IPF es un paquete de cortafuegos alternativo, disponible para Linux (y la mayoría de sistemas operativos). Se puede conseguir en: http://cheops.anu.edu.au/

SINUS Firewall

El SINUS Firewall es un cortafuegos alternativo para Linux (kernel 2.0.x and 2.2.x). Se puede conseguir en: http://www.sinusfirewall.org/.

Phoenix Adaptive Firewall

Estoy en proceso de evaluar el producto, sin embargo parece bastante prometedor. Reemplaza ipchains completamente y añade un montón de inteligencia al proceso de filtrado. Sin embargo es un producto comercial (sobre los 3000$ US), y es el primer cortafuegos para Linux en estar certificado por la ICSA. Está disponible en: http://www.progressive-systems.com/products/phoenix/

Creación de Reglas

ipfwadm2ipchains

Un simple script que convierte las reglas de ipfwadm a ipchains, haciendo más fácil la migración. El script se encuentra disponible en la siguiente dirección: http://users.dhp.com/~whisper/ipfwadm2ipchains/

mason

Mason es un generador automático de reglas para ipfwadm e ipchains. Se carga y monitoriza el flujo de paquetes a través de la máquina, y después, basándose en eso crea un conjunto de reglas para permitir ese tipo de actividad (p. ej. si se hace un ftp al servidor desde un sitio remoto, permitirá ese tipo de acceso en las reglas que crea). Es una buena herramienta para administradores de cortafuegos novatos, disponible en: http://users.dhp.com/~whisper/mason/

firewall.sh

Un script basado en diálogo que te conduce a través de la creación de reglas de filtrado, bastante bien hecho y está orientado a nuevos usuarios, disponible en: http://devplanet.fastethernet.net/Utilities/

Mklinuxfw

Mklinuxfw es una herramienta perl dirigida a proporcionar una variedad de interfaces (CGI, KDE, línea de comandos, etc.) para la creación de reglas de cortafuegos. Actualmente soporta interfaz CGI y está en progreso el GTK. Se puede descargar de: http://www.madhouse.org.uk/~red/framepage.phtml?/mklinuxfw/index.html

kfirewall

kfirewall es una aplicación basada en GUI para la creación de reglas ipfwadm o ipchains. Se puede conseguir en: http://megaman.ypsilonia.net/kfirewall/

fwconfig

fwconfig es una herramienta interesante para configurar ipfwadm e ipchains, basada en www. Se puede descargar desde: http://www.mindstorm.com/~sparlin/fwconfig.shtml

xipfwadm

xipfwadm es una aplicación Tcl/Tk para X que simplifica la creación de reglas ipfwadm. Se puede conseguir en: http://www.x25.org/xipfwadm.html

Firewall Manager

Firewall Manager es una aplicación Tcl/Tk orientada a ser ejecutada desde X-Window que proporciona un GUI para gestión de cortafuegos. Se puede descargar desde: http://www.tectrip.net/arg/

Linux Firewall Tools

Un sitio interesante, tiene un cgi online para crear scripts de cortafuegos, aunque a mi no me funcionó (muy lento). Se puede ver en: http://www.linux-firewall-tools.com/.

FCT – Firewall Configuration Tool

Una de las herramientas de configuración online mediante cgi más avanzadas. Se puede probar en http://www.fen.baynet.de/~ft114/FCT/index.htm.

DNi

DNi es un cgi online que te ayuda a crear reglas de cortafuegos para ipfwadm. Se puede probar en: http://members.tripod.com/~robel/dni/.

Una respuesta a Cortafuegos

  1. Hal dice:

    Mi negro . . . yo que pasaba por acá, te dejo una opinión chiquita.
    Lo que hoy por hoy se usa, son las iptables famosas, que claramente tienen papa, abuelo, y bisabuelo conocido como pusiste en este post. Sin embargo, TODAS ESTAS, son un cacho de configurar, con muchas mas combinaciones y reglas de las que uno quiere recordar, y claramente mas difíciles de seguir el paso de lo que uno quiere. Llega el momento en que se hace hasta DESORDENADO (ademas de desagradable), tener control de las reglas creadas.
    como no soy el único (gracias a D´s) que cree eso, alguien se ilumino, y nació ShoreWall | http://shorewall.net/ | que hace de interprete entre el pobre y humilde ADMIN humano, y el todo poderoso Kernel (iptables).
    Pégale una miradita, porque en verdad, ha sido un gran alivio desde hace un BUEN tiempo, tener ShoreWall… aunque mis guías siguen siendo con IPTABLES (nostalgia supongo).

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

A %d blogueros les gusta esto: