Como me propuse, ya que he acabado de estudiar el estado actual del cortafuegos en Linux, y el estudio nos puede servir de base para implementar la seguridad en Cerbero y Tormenta. El estudio lo he documentado en el epígrafe correspondiente del manual sobre Linux.
Aprovecho la entrada en el blog para hacer un resumen de nuestras necesidades y las conclusiones del estudio.
Necesidades
- Cerbero
- Fiscalizar la red y servir de pasarela de acceso al servidor de contenidos de la red TIC. Lo primero exige reglas de filtrado de paquetes más o menos triviales y lo segundo algunas técnicas no tan trivales de traducción de direcciones de red (NAT). El firmware de Cerbero incluye una versión modificada de Debian con el clásico xtables.
- Tormenta
- Asegurar el acceso y, sobre todo, inutilizar los ataques de fuerza bruta sobre el servicio SSH. En esta máquina instalaremos la última versión de Debian que, en principio, usa el nuevo nftables.
Estudio y conclusiones
En
Linux conviven ahora mismo dos aplicaciones de cortafuegos: el ya casi jubilado
xtables y su sustituto
nftables. Tenemos necesidad de usar ambos, porque
Cerbero requiere el primero; y
Tormenta, el segundo.
- Cerbero
- Requerirá hacer las mismas funciones que hacía zipi. Como ambos utilizan el mismo cortafuegos (xtables), no debería haber problemas más allá de que para algunas operaciones haya que recurrir directamente a xtables, porque la interfaz CLI del firmware del router, no permita definir algunas de las reglas más extravagantes de NAT.
- Tormenta
- Las reglas para controlar su acceso son bastante triviales, excepto aquellas que se usen para impedir los ataques de fuerza bruta. Con iptables la defensa contra estos ataques es el módulo recent, pero en nftables no existe tal módulo. Sin embargo, se puede implementar una solución que funciona de manera muy parecida con limit y meters. Eso evita tener que recurrir a fail2ban.