Un firewall situado delante de un servidor web decide si determinados flujos de red pueden llegar a un puerto o a una dirección. Puede reducir exposición, pero no interpreta necesariamente si una petición HTTP cambia el precio de un producto o accede a la cuenta equivocada. Para entender qué protege hay que separar red, host y aplicación.
La pregunta operativa no es cuántas reglas tiene el firewall, sino qué servicios deben estar expuestos, desde qué orígenes y con qué respuesta cuando una regla bloquea tráfico legítimo.
Firewall de red y firewall del host
Un control de red puede filtrar direcciones, protocolos y puertos antes de que el tráfico alcance el servidor. El firewall del host aplica una política cerca del servicio y puede limitar conexiones entrantes o salientes desde ese sistema. Ambos reducen superficie, pero tienen visibilidad y puntos de fallo diferentes.
Un inventario debe relacionar cada puerto abierto con un proceso, su responsable y la necesidad real de exposición. Cerrar un puerto sin identificar su función puede interrumpir monitorización o correo; dejarlo abierto indefinidamente mantiene un servicio olvidado al alcance de Internet.
Reglas de entrada y salida
Las reglas de entrada controlan quién puede iniciar conexiones hacia un servicio. Las de salida limitan a qué destinos puede conectarse un proceso, algo útil para reducir el alcance de una cuenta comprometida, aunque requiere conocer dependencias y actualizaciones. Un enfoque restrictivo debe incluir una vía de administración y recuperación probada.
Prioriza reglas comprensibles y específicas. Permitir una red de administración puede ser razonable, pero sus direcciones deben mantenerse y el acceso debe tener autenticación fuerte. Filtrar por IP no reemplaza la autorización de la aplicación.
Qué no ve un firewall de red
Una conexión permitida al puerto HTTPS puede transportar una petición con un parámetro mal validado, un usuario sin permisos o una operación de negocio incorrecta. El firewall ve el flujo y algunos metadatos de red, no necesariamente el significado de la solicitud. La aplicación necesita sus propias comprobaciones.
Un WAF puede inspeccionar elementos HTTP como rutas, cabeceras y cuerpos, pero es otra clase de control. Ni un firewall de red ni un WAF corrigen por sí solos código vulnerable, contraseñas expuestas o software sin actualizar.
Diseñar y mantener la política
Documenta el motivo, origen, destino, puerto, responsable y fecha de revisión de cada regla. Registra bloqueos y cambios para distinguir un ataque de una configuración que acaba de romper una integración. Las reglas temporales deben tener una caducidad explícita.
Una política de denegación por defecto puede reducir exposición, pero si el equipo no sabe recuperar el acceso puede generar una interrupción grave. Prueba cambios en una ventana controlada y conserva una ruta de administración separada.
Qué puede bloquear y qué debe resolver otro control
El firewall puede impedir que un servicio innecesario reciba conexiones o limitar una administración a una red concreta. La autenticación, las actualizaciones, los permisos, la validación de entradas y las copias resuelven problemas distintos. Una regla que impide el acceso externo no convierte el servicio en seguro para los usuarios autorizados.
Qué comprobar antes de abrir un puerto
Identifica el proceso, el protocolo, el origen previsto, la autenticación, los logs y la forma de actualizarlo. Abre solo lo necesario, monitoriza el resultado y revisa si la aplicación necesita además controles de capa web. El firewall es una frontera útil; no debe presentarse como protección completa del sitio.
Inventariar antes de aplicar una política
Relaciona cada regla con un servicio real, su propietario, el origen autorizado y el motivo de la excepción. Un inventario de puertos ayuda a encontrar demonios que quedaron activos después de una prueba o de una migración. Repite la revisión cuando se añadan servicios, direcciones IPv6 o nuevas redes de administración.
La salida también merece atención. Un servidor comprometido puede intentar conectarse a un destino externo para extraer datos o descargar componentes. Restringirla requiere conocer actualizaciones, DNS, correo y APIs necesarias; una denegación genérica puede romper el servicio sin resolver el origen del compromiso.
Pruebas y cambios reversibles
Prueba primero desde un origen autorizado y otro que deba bloquearse. Comprueba que el servicio responde, que los logs registran la decisión y que una persona distinta puede restaurar la política. Mantén una sesión de recuperación separada mientras cambias reglas remotas para no quedar fuera del servidor.
Las alertas de bloqueos repetidos deben tener un responsable. Miles de eventos sin revisión no ofrecen la misma utilidad que una señal que identifica el puerto, el origen, el proceso y la acción recomendada.
Revisar excepciones y dependencias
Una excepción amplia suele nacer para resolver una incidencia y permanecer después. Anota su motivo, alcance y fecha de caducidad. Cuando cambie un proveedor o una dirección, comprueba si la regla sigue siendo necesaria antes de añadir otra más permisiva.
Las políticas de red deben convivir con DNS, certificados, monitorización y acceso administrativo. Una regla que funciona para IPv4 puede dejar el mismo servicio expuesto por IPv6; una regla que permite el proxy debe limitar también la administración directa.
El firewall dentro de una respuesta
Durante una incidencia puede ser útil bloquear temporalmente un origen o aislar un servicio, pero la medida debe acompañarse de investigación y corrección. Un bloqueo puede contener una ruta de entrada sin explicar cómo se obtuvo la credencial o qué software quedó vulnerable. Retira la excepción cuando el riesgo esté tratado y conserva la evidencia del cambio.