¿Quién dijo que un cortafuegos doméstico tenía que ser simple?

Enviado por Black Rider el 15 Septiembre, 2012 - 01:03.

La mayoría de los usuarios de ordenadores domésticos se conectan a Internet a través de un enrutador con cortafuegos SPI. Los SPI (Stateless Packet Inspection) son firewalls diseñados para detener las actividades maliciosas más bizarras, entre otros propósitos, aunque los que vienen incorporados en los equipos de consumo suelen dejar un poco que desear.

Hay muchas razones por las que podemos decir que el cortafuegos de un enrutador doméstico no es suficiente para proteger la red de una casa. La más evidente es que se centra principalmente en amenazas externas, por lo que no evita por sí mismo que un adversario capture un ordenador de la red interna físicamente y lo utilice para machacar equipos de la misma red. O, sencillamente, nuestro router de baratillo no ofrece un grado de control elevado sobre lo que queremos que entre en nuestro equipo o no. Peor aún: quizá nosotros no somos el administrador de la red, y el que maneja el cotarro tiene el coeficiente intelectual de un ladrillo y no nos fiamos de su cortafuegos.

En definitiva: el cortafuegos del enrutador está bien tenerlo, pero nos conviene tener un cortafuegos personal en nuestro ordenador.

He elaborado un script de ejemplo que habilitaría un cortafuegos adecuado para un equipo GNU/Linux doméstico. Algunas de las asunciones que he hecho son:

+ No necesitamos que nuestro ordenador se conecte a otros equipos de la red interna.
+ Los módulos del kernel relacionados con el cortafuegos ya han sido cargados de un modo u otro.
+ Se han tomado ya las medidas de endurecimiento de la red no dependientes del cortafuegos, refiriéndonos a la manipulación de las variables del kernel de /proc.
+ No existe una red ipv6, o las funciones ipv6 están desactivadas de un modo u otro. Iptables no gestiona el tráfico ipv6, pues tal red es gestionada por el cortafuegos ip6tables.
+ Nos importa un rábano la seguridad de los demás ordenadores de la red.

El script está escrito en ash, pero debería ser tremendamente fácil de utilizar con cualquier otro shell.

#!/bin/ash

# Script de configuración del cortafuegos.

# Limpiar e iniciar.

/usr/sbin/iptables -F
/usr/sbin/iptables -X
/usr/sbin/iptables -P INPUT DROP
/usr/sbin/iptables -P FORWARD DROP
/usr/sbin/iptables -P OUTPUT ACCEPT

#### Definir cadenas de proceso. ###
# Cadena de análisis de paquetes no válidos: bad-units
/usr/sbin/iptables -N bad-units

# Cadena de análisis de servidores activos: active-servers
/usr/sbin/iptables -N active-servers

# Cadena de análisis de conexiones establecidas: active-connections
/usr/sbin/iptables -N active-connections

# Cadena de análisis para direcciones prohibidas.
/usr/sbin/iptables -N banned_machines

### Definición de bad-units. ###
/usr/sbin/iptables -A bad-units --proto ALL -m state --state INVALID -j DROP
/usr/sbin/iptables -A bad-units --proto tcp --tcp-flags ALL ALL -j DROP
/usr/sbin/iptables -A bad-units --proto tcp --tcp-flags ALL NONE -j DROP
/usr/sbin/iptables -A bad-units --proto tcp ! --syn -m state --state NEW -j DROP
/usr/sbin/iptables -A bad-units --proto tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
/usr/sbin/iptables -A bad-units --proto tcp --tcp-flags SYN,RST SYN,RST -j DROP
/usr/sbin/iptables -A bad-units --proto tcp --tcp-flags ALL FIN,URG,PSH -j DROP
/usr/sbin/iptables -A bad-units --proto tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
/usr/sbin/iptables -A bad-units -j RETURN

### Definición de active-servers. ###
# AÑADIR PUERTOS DE LOS SERVIDORES ACTIVOS
PUERTOS_TCP=""
PUERTOS_UDP=""

for ports in $PUERTOS_TCP
do
/usr/sbin/iptables -A active_servers --proto tcp --dport $ports -j ACCEPT
done

for ports in $PUERTOS_UDP
do
/usr/sbin/iptables -A active_servers --proto udp --dport $ports -j ACCEPT
done

/usr/sbin/iptables -A active-servers -j RETURN

### Definición de active-connections. ###

/usr/sbin/iptables -A active-connections -m state --state RELATED,ESTABLISHED -j ACCEPT

### Definición de banned_machines. ###
IPS_BASTARDAS="0.0.0.0/8 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 224.0.0.0/3"

for direction in $IPS_BASTARDAS
do
/usr/sbin/iptables -A banned_machines -s $direction -j DROP
done

### DEFINICIÓN DE INPUT ###

/usr/sbin/iptables -A INPUT -i lo -s 127.0.0.1 -j ACCEPT
/usr/sbin/iptables -A INPUT -j banned_machines
/usr/sbin/iptables -A INPUT -j bad-units
/usr/sbin/iptables -A INPUT -j active-servers
/usr/sbin/iptables -A INPUT -j active-connections

exit

¿Qué significa todo este galimatías?

La sección "Limpiar e Iniciar" borra cualquier regla activa de iptables antes de añadir las nuestras.

La sección "Definir cadenas de proceso" crea una serie de cadenas.

---> La cadena "bad-units" detiene paquetes defectuosos, inválidos, malformados o que obedecen a patrones típicos de algunos ataques.

---> La cadena "active-servers" sirve para abrir puertos, lo cuál sólo es útil si el equipo tiene algún servidor corriendo. En estos casos, el usuario tiene que identificar los puertos y protocolos que usa su servidor y rellenar las variables "PUERTOS_TCP" y "PUERTOS_UDP" a su gusto.

---> La cadena "active-connections" garantiza que las conexiones que hemos iniciado desde nuestro ordenador no sean bloqueadas por nuestro cortafuegos (a no ser que nos envíe información que sea detenida por "bad-units").

---> La cadena "banned-machines" identifica una serie de direcciones ip y prohíbe la entrada de paquetes desde las mismas.

La sección "DEFINICIÓN DE INPUT" se asegura de que cualquier paquete entrante pasa por todas las cadenas, por lo que sólo las conexiones que hayamos iniciado nosotros, o las que se dirijan a un servicio abierto Y no parezcan sospechosas, serán dadas de paso.

La cadena "bad-units" resulta particularmente interesante. Teóricamente, el propio kernel debería saber qué hacer con la mayoría de los paquetes malformados que reciba, pero creo que no está de más ponerle un cortafuegos delante. Las reglas de "bad-units" las he elaborado tras mucho rebuscar en la documentación de iptables y varios artículos que describen las entrañas del protocolo TCP. No garantizo que no rompa el funcionamiento de tu red si la utilizas, así que estúdiala y no la apliques ciegamente.

Cualquier sugerencia o crítica constructiva será apreciada.

Como nota adicional, me gustaría decir que no soy amigo de cargar las normas de los cortafuegos mediante scripts, sino más bien con iptables-restore.

Imagen de Chapero
Enviado por Chapero el 15 Septiembre, 2012 - 19:17.

Nunca está de más tener unas buenas iptables.

Yo uso arno-iptables-firewall, lo tienes en los repositorios y puedes tambien instalarlo desde la web del autor, es un script.

Hechalé un ojo si quieres, las reglas que implementa están muy bien.

Saludos.

Imagen de hall9000
Enviado por hall9000 el 15 Septiembre, 2012 - 20:08.
Chapero escribió:

Nunca está de más tener unas buenas iptables.

Yo uso arno-iptables-firewall, lo tienes en los repositorios y puedes tambien instalarlo desde la web del autor, es un script.

Hechalé un ojo si quieres, las reglas que implementa están muy bien.

Saludos.

+1
yo también lo tengo en Debian, aunque la verdad que con una configuración básica. en Arch no tengo nada.
la verdad es que no me fío de trastear con iptables neutral

Imagen de Black Rider
Enviado por Black Rider el 16 Septiembre, 2012 - 10:25.

Las herramientas automáticas están bien para hacer despliegues rápidos o para organizarte si gestionas redes y servicios complicados, pero mi vena Slacker prefiere reducir las capas de abstracción al mínimo.

Más que nada, es una filosofía. Cuanto más software y más capas de abstracción metes entre el usuario y las variables de netfilter, más fácil es que se introduzcan bugs, que el usuario se acostumbre al point & click y que cuando haga falta nadie sepa nada de los protocolos de red pertinentes. Menos mal que configurar el cortafuegos a base de sysctl.conf no es práctico, que si no no iba a estar utilizando ni Iptables :-)

En realidad, el 90% de la gente está a salvo con sólo tres reglas:

iptables -P FORWARD DROP
iptables -P INPUT DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Me parece bastante sencillo. Las reglas adicionales sólo tienen sentido si el equipo tiene algún servidor abierto (típicamente un Torrent, servicio de impresión o Samba/NFS en una red casera), porque limpian un poco la roña que golpea estos puertos. De hecho, se supone que el router que conecta la red con Internet debería filtrar los paquetes malformados e impedir el Ip spoofing y otras lindezas que te lancen desde fuera, pero no está mal tener algo de redundancia.

Imagen de alnus
Enviado por alnus el 17 Septiembre, 2012 - 10:23.

Buen artículo. Gracias.
¿Qué opinas de aplicaciones como "Firestarter", "Guarddog", etc?

Imagen de Black Rider
Enviado por Black Rider el 17 Septiembre, 2012 - 11:29.
alnus escribió:

¿Qué opinas de aplicaciones como "Firestarter", "Guarddog", etc?

Hombre, si creo que ya lo he dicho :-)

Las apliaciones gráficas o automáticas están bien porque te permiten crear reglas útiles con unos conocimientos mínimos, pero no dejan de introducir más puntos de fallo en la cadena de seguridad y de evitar que te metas un poco más en el funcionamiento de netfilter. Por otra parte, iptables está disponible en virtualmente cualquier sistema GNU/Linux, lo que significa que será más fácil que encuentres éste y no algún sucedáneo gráfico en caso de que te toque revisar las reglas de un ordenador ajeno -por ejemplo, si tu padre se hincha a cerrar puertos con gufw y se corta a sí mismo el acceso a Internet.

Además, si quieres estar lo bastante seguro de lo buenas que son las reglas creadas por las aplicaciones automatizadas, vas a tener que meter "iptables -L" y revisar las reglas a mano para estar seguro.

P.D: En el ejemplo de mi último post, se me olvidó añadir una regla para no interferir con el tráfico interno del sistema:

/usr/sbin/iptables -A INPUT -i lo -s 127.0.0.1 -j ACCEPT

Si no lo pones, no podrás ni utilizar la impresora.

Imagen de alnus
Enviado por alnus el 17 Septiembre, 2012 - 16:01.
Black Rider escribió:
alnus escribió:

¿Qué opinas de aplicaciones como "Firestarter", "Guarddog", etc?

Hombre, si creo que ya lo he dicho :-)

Las apliaciones gráficas o automáticas están bien porque te permiten crear reglas útiles con unos conocimientos mínimos, pero no dejan de introducir más puntos de fallo en la cadena de seguridad y de evitar que te metas un poco más en el funcionamiento de netfilter. Por otra parte, iptables está disponible en virtualmente cualquier sistema GNU/Linux, lo que significa que será más fácil que encuentres éste y no algún sucedáneo gráfico en caso de que te toque revisar las reglas de un ordenador ajeno -por ejemplo, si tu padre se hincha a cerrar puertos con gufw y se corta a sí mismo el acceso a Internet.

Además, si quieres estar lo bastante seguro de lo buenas que son las reglas creadas por las aplicaciones automatizadas, vas a tener que meter "iptables -L" y revisar las reglas a mano para estar seguro.

P.D: En el ejemplo de mi último post, se me olvidó añadir una regla para no interferir con el tráfico interno del sistema:

/usr/sbin/iptables -A INPUT -i lo -s 127.0.0.1 -j ACCEPT

Si no lo pones, no podrás ni utilizar la impresora.

Gracias, Black.

Imagen de roma
Enviado por roma el 17 Septiembre, 2012 - 19:05.

Yo no termino de entender el tema de los tcp flags como funciona. Tengo entendido que el primer grupo es el que queres evaluar y el segundo una almohadilla contra la cual se compara?. Bue de todas formas no me queda claro :/

Imagen de Black Rider
Enviado por Black Rider el 17 Septiembre, 2012 - 19:52.

Vamos a ver...

Cojamos una regla de ejemplo:

/usr/sbin/iptables -A bad-units --proto tcp --tcp-flags ALL SYN,FIN -j DROP

Lo que esta hace es coger el primer grupo (todas las banderas TCP) y comprueba que, dentro de ese grupo, sólo están activadas las dadas por el segundo (SYN,FIN)

En éste ejemplo, que no tiene por qué tener sentido, la regla saltará si SYN y FIN están activadas y las demás están desactivadas.

Imagen de Chapero
Enviado por Chapero el 18 Septiembre, 2012 - 00:50.

Puedo llegar a entender que no te gusten las cosas automatizadas, pero no estoy deacuerdo que a más reglas más bugs, si hay bugs metiendo más reglas, estás realmente diciendo que los bugs los tiene iptables.

el único problema que le veo a iptables es que no tiene para añadir un ejecutable al firewall, hay aplicaciones que funcionan con puertos aleatorios salientes, y eso se puede convertir en un problema si eres de los que le gustan meter a drop al grupo OUT de reglas.

Imagen de roma
Enviado por roma el 18 Septiembre, 2012 - 02:55.
Black Rider escribió:

Vamos a ver...

Cojamos una regla de ejemplo:

/usr/sbin/iptables -A bad-units --proto tcp --tcp-flags ALL SYN,FIN -j DROP

Lo que esta hace es coger el primer grupo (todas las banderas TCP) y comprueba que, dentro de ese grupo, sólo están activadas las dadas por el segundo (SYN,FIN)

En éste ejemplo, que no tiene por qué tener sentido, la regla saltará si SYN y FIN están activadas y las demás están desactivadas.

Esta bien ahora sería lo mismo poner SYN,FIN SYN,FIN?