Experiencia práctica

OPNsense en la empresa: zonas de red en lugar de una única red grande

Puestos de trabajo, servidores, invitados y dispositivos técnicos necesitan accesos diferentes. Cómo OPNsense convierte esta separación en un conjunto de reglas comprensible.

FirewallSeguridad
Cables de conexión naranjas y azules unen grupos separados de un panel de red con un switch.

Una impresora, el dispositivo de una visita y el servidor de archivos no necesitan utilizar las mismas rutas de red. Unas zonas claras permiten describir quién necesita cada servicio. OPNsense puede controlar los pasos entre ellas; una distribución útil comienza por los procesos de trabajo de la empresa.

Del inventario de dispositivos a los flujos de datos permitidos

Una pequeña matriz de accesos es un buen punto de partida. Indica la zona de origen, el servicio necesario, el destino y el motivo de negocio. Un puesto puede necesitar una aplicación empresarial en un servidor. Un dispositivo invitado necesita Internet. La administración de un switch debería ser accesible únicamente mediante una ruta administrativa prevista.

Después se implementan las zonas técnicamente, por ejemplo mediante VLAN y puertos de switch adecuados. El nombre de una VLAN por sí solo no crea una frontera de protección completa. El tráfico entre redes debe pasar realmente por el punto controlado; también se revisan routers adicionales, puentes Wi-Fi olvidados y conexiones de red dobles.

Las reglas describen un propósito concreto

OPNsense utiliza un filtro de paquetes con estado. Las reglas se consideran junto con la interfaz, la dirección, el orden y los estados de conexión existentes. Los alias reutilizables pueden hacer más legible el conjunto de reglas si su contenido está claramente definido y mantenido. Un alias llamado «Servidores» no sustituye una definición documentada.

Una autorización describe destinos concretos y servicios necesarios con la mayor precisión posible. Una regla de prueba inicialmente amplia recibe un responsable y una fecha de fin. De lo contrario, un diagnóstico temporal se convierte rápidamente en un acceso permanente y poco transparente. Los cambios se evalúan mejor si el motivo de negocio queda reflejado directamente en el comentario de la regla.

Registrar los accesos; asignar zonas; aplicar reglas; probar accesos permitidos y denegados.Registrar los accesos; asignar zonas; aplicar reglas; probar accesos permitidos y denegados.
Secuencia de comprobación simplificada; el procedimiento concreto depende del entorno existente.

Tener en cuenta NAT, resolución de nombres e IPv6

La traducción de direcciones y las reglas de acceso cumplen funciones diferentes. Una redirección pública necesita una autorización adecuada; una dirección de origen modificada no explica si una aplicación debe ser accesible. DNS, DHCP, servicios horarios y rutas de retorno también deben seguir siendo adecuados para el entorno después de la división en zonas.

IPv6 se comprueba expresamente. Una matriz de accesos pensada solo para IPv4 puede pasar por alto una segunda familia de protocolos activa. Las interfaces de administración, las conexiones VPN y el tráfico originado en el propio firewall también requieren recorridos de prueba específicos. Las reglas deben reflejar las conexiones que realmente se utilizan.

Un pequeño piloto muestra las dependencias

Para el primer paso resulta adecuado un grupo reducido de dispositivos con un proceso de trabajo conocido. Se prueban las mismas aplicaciones antes y después de la separación. El registro incluye también accesos denegados deliberadamente: los invitados no alcanzan la interfaz de administración y un dispositivo técnico no puede acceder libremente a la red de servidores.

DAXS relaciona la planificación de red con los switches, el Wi-Fi, los servicios de servidor y la operación existente. El resultado es una matriz de accesos mantenible con reglas comprensibles. El número adecuado de zonas depende de las necesidades de protección, la gestión de dispositivos y la mantenibilidad; tener muchas VLAN no es por sí mismo un objetivo de calidad.

Infraestructura y plataformas · Situar las medidas técnicas de protección en contexto · Hablar de un proyecto de red

Fuentes: OPNsense: reglas de firewall con estado (enlace externo) · OPNsense: traducción de direcciones de red (enlace externo)