Tener un firewall instalado y tener un firewall que realmente protege tu empresa son dos cosas completamente distintas. Esta diferencia, que muchos proveedores de IT prefieren no mencionar, es la brecha de seguridad más común y más costosa en las pequeñas y medianas empresas de hoy.
La realidad es incómoda: un firewall empresarial de gama alta mal configurado ofrece menos protección real que un dispositivo de gama media ajustado correctamente. Las configuraciones por defecto están diseñadas para funcionar rápidamente, no para defenderse contra las amenazas actuales. El resultado es una falsa sensación de seguridad que deja expuestas rutas de ataque concretas y evitables.
En este artículo desglosamos los cinco elementos de configuración que cualquier PYME debe verificar: el filtrado de salida, las reglas IDS/IPS, la configuración del VPN y el split tunnelling, la política de actualización de firmware y el registro auditable de eventos. Al terminar de leer, tendrás un checklist concreto de preguntas para exigirle a tu proveedor IT respuestas claras, porque la seguridad real no se mide en hardware instalado, sino en parámetros correctamente aplicados.
El firewall instalado no es el firewall configurado
Instalar un firewall y configurarlo correctamente son dos acciones distintas. La brecha entre ambas es donde ocurre la mayoría de los incidentes de seguridad en PYMEs: el dispositivo aparece como “operativo” en el contrato y sin embargo deja pasar tráfico que nunca debería cruzar el perímetro.
El caso WannaCry ilustra el coste de esa brecha. En mayo de 2017, el ransomware se propagó explotando el puerto 445 (SMB). Según el análisis de Carnegie Mellon SEI, una combinación correcta de filtrado de entrada y salida habría limitado su expansión, bloqueando la infección inicial y la comunicación con servidores externos de control.
La evidencia normativa apunta en la misma dirección. El DoD Security Requirements Guide, Firewall STIG V3R1 identifica 35 hallazgos de seguridad en firewalls, 3 de categoría crítica (CAT I), 30 de severidad media (CAT II), todos relativos a políticas y controles aplicados.
Muchos proveedores IT entregan el dispositivo funcional sin documentar qué reglas están activas, qué tráfico se permite por defecto y qué controles han quedado deshabilitados. El cliente recibe un firewall “instalado”, no un firewall configurado para su perfil de tráfico real.
Conocer los cinco elementos de configuración verificables que se abordan en este artículo permite exigir a cualquier proveedor de gestión de firewall protección real, no solo cumplimiento formal.
Por qué la configuración por defecto deja brechas reales
El problema no está en el hardware que llega a tu oficina, sino en la lógica con la que viene programado. Las configuraciones por defecto están diseñadas para que el dispositivo funcione en el mayor número de entornos posible desde el primer encendido. Tu PYME, con su perfil de tráfico específico y sus patrones de acceso remoto, no es el escenario que el fabricante tenía en mente.
El principio que los estándares exigen es el contrario: denegar todo el tráfico por defecto y permitir solo lo estrictamente necesario. Tanto NIST SP 800-41 como el NCSC irlandés lo establecen como base de cualquier política de firewall correcta. En la práctica, esta política rara vez viene activada de fábrica: un dispositivo que bloquea tráfico no reconocido genera llamadas de soporte inmediatas. Los proveedores priorizan la operatividad sobre la seguridad, dejando activas reglas permisivas que amplían la superficie de ataque.
El resultado es un problema contractual real. La cláusula “firewall instalado” puede cumplirse con un dispositivo que apenas filtra tráfico, y es posible superar una auditoría básica en ese estado. Instalado no significa configurado; operativo no significa seguro.
Las secciones siguientes desglosan cada uno de esos cinco controles con la pregunta exacta que debes plantear.
1. Filtrado de salida (egress filtering): el control que casi nadie activa
El primer control que los proveedores omiten con más frecuencia no tiene que ver con el tráfico que entra, sino con el que sale.
Sin filtrado de salida activo, cualquier dispositivo comprometido puede establecer comunicación con servidores de comando y control externos, enviar datos robados o participar en ataques coordinados sin que el firewall lo detecte. La brecha es silenciosa por definición.
Según Carnegie Mellon SEI, el egress filtering no protege primariamente tu propia red: protege a las demás. Impide que tu infraestructura se convierta en origen de tráfico falsificado (IP spoofing) o en vector de ataques hacia terceros.
La política correcta aplica denegación por defecto en salida: solo salen los puertos y destinos explícitamente autorizados. Esto dificulta la exfiltración de datos y corta la cadena de propagación del malware antes de que alcance sistemas externos.
En el contexto de endpoint security, este control funciona como red de contención final. Si un endpoint ya está comprometido y el antivirus no lo detecta, el egress filtering bloquea las comunicaciones que el malware necesita para operar.
Pregunta que debes hacer a tu proveedor:
“¿Está habilitado el filtrado de salida con política de denegación por defecto? ¿Puedes mostrarme el listado de reglas de salida activas y justificar cada puerto permitido?”
Un proveedor que no puede responder esto con documentación en mano no tiene el control configurado.
2. Reglas IDS/IPS y filtrado basado en amenazas: más allá del puerto
Controlar qué tráfico entra y sale por puerto es necesario, pero insuficiente. Un firewall que opera únicamente con filtrado de paquetes básico no ve lo que va dentro del tráfico. Por ejemplo, una inyección SQL puede viajar sobre el puerto 443, legítimo para HTTPS, sin que un firewall sin inspección profunda lo detecte.
Los estándares de referencia en seguridad de firewalls, como NIST SP 800-41, distinguen el filtrado de paquetes básico de la inspección profunda de contenido: los sistemas IDS/IPS evalúan el comportamiento del tráfico más allá del número de puerto. Esta distinción es crítica: un firewall sin IDS/IPS activo deja pasar amenazas que cualquier motor de inspección actualizado detectaría en milisegundos.
El segundo problema es la actualización. Las firmas de amenazas desactualizadas equivalen funcionalmente a no tener IDS/IPS. Un motor que no conoce las variantes de malware publicadas en los últimos 30 días no puede detectarlas, independientemente del hardware.
En soluciones como pfSense con Suricata o Snort, la diferencia entre la instalación por defecto y una configuración con conjuntos de reglas alineados a guías STIG es sustancial en términos de detección real. La instalación por defecto activa un subconjunto mínimo de reglas; la configuración endurecida habilita fuentes de inteligencia adicionales y ajusta umbrales de alerta al perfil de tráfico de la organización.
Pregunta que debes hacer a tu proveedor: “¿Está habilitado el IDS/IPS en modo activo (inline)? ¿Con qué frecuencia se actualizan las firmas y qué fuente de inteligencia de amenazas se utiliza?”
3. VPN y split tunnelling: la misconfiguration que anula tu firewall
El split tunnelling en conexiones VPN crea una vía de tráfico que elude por completo los controles configurados en el firewall.
Cuando un empleado trabaja en remoto con split tunnelling activo, su dispositivo divide el tráfico en dos rutas simultáneas: el tráfico corporativo va cifrado por la VPN, y el tráfico de Internet general sale directamente desde el dispositivo sin pasar por el firewall. Todos los controles configurados, egress filtering, IDS/IPS, políticas de bloqueo, quedan invisibles para ese flujo.
Por qué está activo en tantas PYMEs: los proveedores habilitan el split tunnelling para reducir la carga del servidor VPN y mejorar la velocidad percibida. Es una decisión de comodidad operativa que se convierte en decisión de seguridad sin que nadie lo haya analizado explícitamente.
El problema real es la puerta trasera que abre. Un dispositivo remoto navegando sin inspección puede comprometerse, y desde ese dispositivo el atacante tiene acceso directo al túnel VPN hacia la red interna.
El VPN Security Requirements Guide (STIG V3R5) identifica 12 hallazgos de categoría CAT I (alto riesgo) relacionados con configuración VPN. Las excepciones no documentadas como el split tunnelling silencioso pueden no aparecer en ningún log corporativo, porque el tráfico comprometido nunca toca el firewall.
Pregunta que debes hacer a tu proveedor: “¿Está deshabilitado el split tunnelling en todos los perfiles VPN? ¿Cómo se verifica que el tráfico de usuarios remotos pasa por los controles del firewall antes de salir a Internet?”
4. Política de actualización de firmware: sin parches, el firewall es una puerta abierta
Más allá de la configuración activa, el propio firmware del firewall puede ser un vector de entrada. Un dispositivo sin parchear puede ser comprometido antes de inspeccionar un solo paquete, convirtiendo tu primera línea de defensa en el punto de entrada del atacante.
El DoD STIG V3R1 exige que los cambios en mecanismos de cumplimiento, reglas, políticas de seguridad, zonas, se apliquen sin demora. La ausencia de una política de gestión de parches documentada es en sí misma un hallazgo auditable. Si tu proveedor no puede mostrarte ese documento, el firewall carece de gobernanza formal, independientemente del hardware instalado.
Una política de actualización válida debe especificar cuatro elementos concretos:
- Frecuencia de revisión de nuevas versiones de firmware
- Ventana máxima entre la publicación de un parche crítico y su despliegue en producción
- Procedimiento de prueba previo al despliegue para evitar interrupciones de servicio
- Responsable documentado del proceso, con nombre o rol asignado
La monitorización continua mediante herramientas RMM permite detectar automáticamente cuándo una versión de firmware queda obsoleta y generar alertas antes de que la ventana de exposición se amplíe. Un socio IT externo que gestione proactivamente tus sistemas debe incluir el estado de parches del firewall dentro de su monitorización rutinaria, no revisarlo solo cuando hay un incidente.
Pregunta que debes hacer a tu proveedor: “¿Existe una política de parches documentada para el firewall? ¿Cuál es el plazo máximo para aplicar un parche crítico de firmware desde su publicación?”
5. Logging completo y auditable: si no está registrado, no existe
El logging es el mecanismo forense esencial: sin registros completos, es imposible determinar cuándo comenzó un ataque, qué sistemas quedaron expuestos ni qué datos pudieron verse comprometidos. La investigación post-incidente no puede reconstruirse sobre memoria o suposiciones.
Un firewall correctamente configurado registra todas las decisiones de filtrado: conexiones permitidas, conexiones bloqueadas, intentos de acceso fallidos y cambios en las reglas. Registrar solo los bloqueos deja invisible el tráfico legítimo que podría haber sido manipulado, que es precisamente donde se ocultan los ataques más sofisticados.
Los registros deben almacenarse en un sistema externo al propio firewall, protegido contra modificación. Si el firewall es comprometido, sus propios logs no pueden considerarse fiables. La Directiva NIS2 (2022/2555) amplía las obligaciones de ciberseguridad a un número creciente de PYMEs europeas, lo que incluye necesariamente capacidades de registro y respuesta a incidentes. Consulta los requisitos aplicables a tu sector con tu asesor legal.
El acceso a esos registros debe ser tuyo, no solo de tu proveedor. Si únicamente el proveedor puede consultar los logs, la supervisión independiente es imposible. Al evaluar a cualquier proveedor IT para tu empresa, el acceso autónomo a los registros de seguridad es un criterio no negociable.
Pregunta que debes hacer a tu proveedor: “¿Qué eventos registra el firewall y dónde se almacenan esos registros? ¿Tengo acceso directo a los logs y durante cuánto tiempo se retienen?”
Checklist de preguntas para exigir a tu proveedor IT
Los cinco controles anteriores no son categorías teóricas: son preguntas concretas que puedes hacer a tu proveedor en la próxima reunión de revisión. Un proveedor que gestiona tu seguridad informática correctamente debe responderlas sin consultar manuales ni aplazar la respuesta.
Presenta estas ocho preguntas por escrito y exige respuestas documentadas:
- ¿Está habilitado el filtrado de salida con política de denegación por defecto? Solicita el listado completo de reglas de egress activas con justificación de cada puerto permitido.
- ¿El IDS/IPS está en modo activo (inline) y no solo en modo detección pasiva? Pide la fecha de la última actualización de firmas y el nombre de la fuente de inteligencia de amenazas utilizada.
- ¿El split tunnelling está deshabilitado en todos los perfiles VPN de la organización? Exige confirmación por escrito y pregunta cómo se verifica que el tráfico remoto pasa por los controles del firewall.
- ¿Existe una política documentada de parches de firmware con plazos máximos definidos para vulnerabilidades críticas? Sin documento escrito, no existe política real.
- ¿Qué eventos registra el firewall, dónde se almacenan los logs, y tienes acceso independiente a ellos? El acceso no debe depender de una solicitud al proveedor.
- ¿La política del firewall aplica denegación por defecto tanto para tráfico entrante como saliente? Esta es la base del modelo recomendado por NIST SP 800-41; una respuesta vaga indica configuración permisiva.
- ¿Cómo se documentan los cambios en las reglas del firewall y quién está autorizado para realizarlos? Debe existir un registro de auditoría de cambios con fecha, autor y motivo.
- ¿Puedes entregar un informe mensual de eventos de seguridad con análisis de anomalías? El reporting periódico es la diferencia entre gestión proactiva y simple instalación.
Una respuesta evasiva a cualquiera de estas preguntas es información relevante para evaluar la calidad real del servicio que estás contratando.
Tu proveedor IT debe responder estas preguntas sin dudar
Si tu proveedor no puede responder el checklist anterior con documentación en mano, la instalación del firewall no equivale a protección real.
Estos controles no son requisitos avanzados. Un socio IT serio documenta cada regla activa, mantiene el firmware parcheado dentro de plazos definidos y entrega registros auditables periódicamente, sin que el cliente tenga que pedirlos. Son controles fundamentales respaldados por marcos de referencia como NIST SP 800-41 y el DoD Firewall STIG V3R1. Cualquier PYME puede exigirlos contractualmente.
Si tu proveedor actual duda ante estas preguntas o no puede mostrar la documentación, tienes base suficiente para reclamar una revisión formal del servicio. La seguridad informática es una disciplina, no una casilla en un contrato.
KMU Informatik configura y gestiona firewalls, incluyendo Securepoint, con políticas documentadas desde el primer día. La monitorización proactiva vía Atera RMM garantiza que el estado de parches y las alertas de seguridad se traten antes de convertirse en incidentes. El reporting periódico es accesible directamente para el cliente, sin intermediarios. Puedes conocer cómo gestionamos la infraestructura de red y servicios gestionados para PYMEs para verificar exactamente qué incluye ese compromiso.
Conclusión
Un firewall instalado sin configuración adecuada no es seguridad: es una falsa sensación de protección.
Revisa hoy mismo el checklist con tu proveedor actual. Si las respuestas generan dudas o silencio, es el momento de exigir una revisión formal.
