IPTABLES: conociendo las bases de los firewall

Hoy en día es relativamente sencillo montar un firewall que bloquee o acepte conexiones según los criterios que hayamos establecido previamente.

Todo está a golpe de click y las interfaces gráficas han ayudado tanto que crear una regla no te hace plantearte mucho cómo va a gestionar los paquetes el firewall.

Hace cosa de un par de semanas pregunté en mi LinkedIn sobre si los actuales sysadmin o ingenieros de redes veían necesario el conocer el funcionamiento de iptables para poder tener un buen desempeño a la hora de darle seguridad a una red.

Porque no es lo mismo configurar un firewall que hacerlo configurarlo bien. La primera opción te permite dar un servicio básico y -quizá- no del todo seguro ya que es posible que te dejes cosas a medias (o por contrapartida, abriendo demasiado el abanico).

La segunda opción te permite saber cuales son las necesidades reales que hay que cubrir, y para ello, es necesario saber cómo funcionan las redes en su parte más básica.

Entonces, ¿qué considero necesario para configurar un firewall?

En primer lugar, saber y entender el modelo OSI. De nada vale saber poner reglas en un firewall si no sabes realmente a qué hay que permitir o denegar el acceso y a qué nivel.

Disclaimer: a lo largo de mi trayectoria profesional, a la hora de auditar una red, me he encontrado con firewalls que tenian un ACCEPT ANY cuando en realidad lo único que tenían que hacer era permitir el tráfico HTTPS.

---

Historia de los firewall

La década de 1980 marcó los inicios de Internet, una red que, si bien ofrecía un potencial transformador, aún adolecía de mecanismos de seguridad robustos. Los incidentes de seguridad registrados en este período demostraron la vulnerabilidad de los sistemas interconectados y la urgencia de desarrollar soluciones para proteger la información y garantizar la continuidad de los servicios.

El incidente del Gusano Morris en 1988 marcó un hito en la historia de la ciberseguridad, revelando las vulnerabilidades de la infraestructura de red de la época. La rápida propagación del malware y su impacto en instituciones de prestigio, junto con las investigaciones de Stoll y Cheswick, evidenciaron la necesidad de desarrollar soluciones de seguridad más robustas para proteger los sistemas interconectados.

En respuesta a los desafíos de seguridad emergentes a finales de los 80, DEC introdujo el concepto de filtrado de paquetes. Este mecanismo, basado en la inspección de atributos clave de cada paquete IP (direcciones, protocolos, puertos), permitió implementar políticas de seguridad de red más sofisticadas. Los firewalls basados en filtrado de paquetes se convirtieron en un componente esencial de la arquitectura de seguridad de las redes.

---

Algo más moderno: Linux + iptables

Antes de iptables, Linux utilizaba ipfwadm (en su kernel 2.0) y posteriormente ipchains (en su kernel 2.2) para el filtrado de paquetes, pero tenían limitaciones.

En la version 2.4 del kernel de Linux se introdujo una nueva herramienta: iptables

Iptables fue desarrollado a finales de los años 90 como sucesor de ipchains, otra herramienta de filtrado de paquetes. Su introducción se produjo en un momento en el que la seguridad informática se estaba convirtiendo en una preocupación cada vez mayor, debido al crecimiento exponencial de Internet y la aparición de nuevas amenazas.

---

Funcionamiento de iptables

El filtrado de paquetes se hace mediante 3 tablas, según las necesidades que se tengan.

La primera tabla es la tabla FILTER. Esta tabla es la tabla por defecto y contiene 3 cadenas (chains) predefinidas: INPUT, FORWARD y OUTPUT.

• INPUT: Son los paquetes que van dirigidos al propio cortafuegos.

• FORWARD: Aquellos paquetes que son enrutados a través de la máquina que contiene el cortafuegos.

• OUTPUT: Son los paquetes generados localmente y que tienen cualquier destino que no sea el propio cortafuegos.

La segunda tabla es la tabla NAT. Esta tabla se consulta cada vez que un paquete inicia una nueva conexión, y tiene 3 cadenas predefinidas: PREROUTING, OUTPUT y POSTROUTING.

• PREROUTING: La cadena se consulta con los paquetes que entran en la máquina cortafuegos, antes de decidir qué hacer con ellos. En esta cadena tenemos la acción DNAT (destination NAT) la cual modifica la IP de destino y se redirige a un host dentro de la red. Es comúnmente conocido como "abrir puertos".

• OUTPUT: Altera paquetes generados localmente.

• POSTROUTING: Esta cadena se consulta para alterar los paquetes que se reciben y van a salir de la máquina. La acción usada aquí es SNAT (source NAT) la cual modifica la dirección IP de origen por una IP especificada, o enmascarada con la IP del propio cortafuegos con la opción MASQUERADE.

Y la tercera tabla, que poca gente conoce o utiliza es la tabla MANGLE. Es una tabla especial para modificar determinados parámetros de los paquetes.

Tiene cinco cadenas predefinidas: INPUT, OUTPUT, PREROUTING, POSTROUTING, FORWARD.

Con esta tabla tenemos muchas posibilidades como, por ejemplo, modificar el TTL de los paquetes ICMP.

Como la gran mayoría ya sabréis, hay unos valores de TTL por defecto que un atacante puede aprovechar para conocer qué dispositivo se encuentra al otro lado.

También se puede aplicar QoS, marcar el tráfico de aplicaciones específicas o bloquear tráfico con una dirección concreta en el SNI. (Si no sabes lo que es el SNI te recomiendo que le eches un vistazo a esta entrada: DNS over HTTPS y el SNI

Aquí os dejo un pequeño esquema del funcionamiento de las tablas y cadenas.

¡Nos vemos en la siguiente entrada!