Tema 10

10. Alta disponibilidad, redundancia, respaldos y gestión de cambios en firewalls

Un firewall protege, pero también puede convertirse en un punto crítico de falla. La defensa necesita continuidad: equipos redundantes, configuraciones respaldadas, pruebas de recuperación y cambios controlados.

Objetivo Mantener controles de firewall disponibles y recuperables
Enfoque HA, failover, backups y cambios seguros
Resultado Reducir caídas, errores de configuración y pérdida de control

10.1 Introducción

Un firewall suele estar en puntos críticos de la infraestructura: salida a internet, conexión entre sedes, acceso a DMZ, segmentación interna o enlaces con la nube. Si falla o queda mal configurado, puede interrumpir servicios importantes o dejar tráfico expuesto.

Por eso la defensa no termina al escribir reglas. También hay que asegurar que el firewall siga funcionando, que pueda recuperarse ante fallas, que sus configuraciones estén respaldadas y que los cambios se apliquen con control.

Este tema explica los conceptos esenciales de alta disponibilidad, redundancia, respaldos y gestión de cambios aplicados a firewalls.

10.2 Alta disponibilidad

La alta disponibilidad, o HA por High Availability, busca que el servicio continúe funcionando incluso si un componente falla. En firewalls, suele implementarse con dos o más equipos trabajando como par o clúster.

La idea es que si el firewall activo falla, otro firewall tome su lugar con la menor interrupción posible. Esto se conoce como failover.

Alta disponibilidad no elimina fallas. Reduce el impacto cuando ocurren y permite recuperar servicio con menor tiempo de interrupción.

10.3 Activo-pasivo y activo-activo

Los esquemas de alta disponibilidad más comunes son activo-pasivo y activo-activo.

Modelo Cómo funciona Uso típico
Activo-pasivo Un firewall procesa tráfico y el otro queda en espera. Diseños donde se prioriza simplicidad y failover claro.
Activo-activo Varios firewalls procesan tráfico simultáneamente. Escenarios con necesidad de distribuir carga o alta capacidad.

Activo-activo puede aportar capacidad, pero también aumenta complejidad. No debe elegirse solo porque suena más avanzado.

10.4 Failover

Failover es el proceso por el cual un equipo secundario asume el rol del principal cuando se detecta una falla. Para que funcione bien, los firewalls deben sincronizar estado, configuración o ambos, según el diseño.

Aspectos importantes:

  • Detección de falla del equipo activo.
  • Sincronización de configuración.
  • Sincronización de sesiones cuando sea necesaria.
  • Tiempo de conmutación aceptable.
  • Pruebas periódicas de failover.
  • Alertas cuando ocurre un cambio de rol.

10.5 Sincronización de sesiones

Algunos pares HA pueden sincronizar la tabla de sesiones. Esto permite que, ante un failover, las conexiones existentes continúen o se interrumpan menos.

Sin sincronización de sesiones, un cambio de firewall activo puede cortar conexiones existentes, aunque las nuevas conexiones funcionen correctamente. Esto puede impactar VPN, aplicaciones críticas, transferencias o sesiones de usuarios.

La decisión depende de criticidad, capacidad del equipo y complejidad aceptable.

10.6 Redundancia de enlaces

No alcanza con tener dos firewalls si todos dependen de un único enlace, switch, proveedor o camino físico. La redundancia debe analizarse de extremo a extremo.

Elementos a revisar:

  • Enlaces a internet.
  • Conexiones entre sedes.
  • Switches conectados a los firewalls.
  • Fuentes de energía.
  • Rutas hacia redes internas.
  • Dependencias de DNS, autenticación y monitoreo.
La alta disponibilidad del firewall pierde valor si otro componente único puede dejar todo fuera de servicio.

10.7 Redundancia de rutas y proveedores

En entornos críticos, puede ser necesario contar con más de un proveedor de internet, rutas alternativas o enlaces privados redundantes. Esto evita que la caída de un único proveedor interrumpa toda la conectividad.

Sin embargo, más rutas también implican más diseño: hay que controlar qué tráfico sale por cada enlace, cómo se mantiene la seguridad, cómo se registran eventos y cómo se evita una ruta alternativa sin controles equivalentes.

Una ruta de respaldo no debe convertirse en un camino menos protegido.

10.8 Respaldos de configuración

Los respaldos de configuración permiten recuperar un firewall después de una falla, reemplazo, error humano o actualización problemática. Deben incluir reglas, objetos, NAT, rutas, VPN, certificados, usuarios locales si existen, perfiles de seguridad y parámetros del sistema.

Un respaldo útil debe ser:

  • Automático o realizado con frecuencia definida.
  • Versionado.
  • Protegido contra accesos no autorizados.
  • Cifrado si contiene secretos o información sensible.
  • Almacenado fuera del propio firewall.
  • Probado mediante restauración controlada.

10.9 Qué debe incluir un respaldo

Elemento Por qué importa
Reglas y objetos Representan la política de acceso.
NAT y rutas Definen cómo se alcanza cada red o servicio.
VPN Permiten recuperar acceso remoto o conectividad entre sedes.
Certificados Pueden ser necesarios para inspección, VPN o administración segura.
Perfiles IDS/IPS o seguridad Evitan recuperar solo conectividad sin controles defensivos.
Configuración administrativa Usuarios, roles, logging, NTP, DNS y monitoreo.

10.10 Pruebas de restauración

Tener respaldos no alcanza. Hay que probar que pueden restaurarse. Muchas organizaciones descubren en una emergencia que el respaldo está incompleto, corrupto, desactualizado o protegido con una clave que nadie conoce.

Una prueba de restauración puede realizarse en laboratorio, equipo de reemplazo o entorno controlado. Debe verificar que la configuración carga, que las reglas aparecen correctamente y que servicios críticos pueden recuperarse.

También conviene documentar el tiempo estimado de recuperación.

10.11 Gestión de cambios

La gestión de cambios busca que las modificaciones en firewalls se realicen con control. Una regla mal aplicada puede cortar servicios, abrir accesos indebidos o afectar monitoreo.

Un cambio controlado debería incluir:

  • Solicitud clara.
  • Justificación y alcance.
  • Análisis de riesgo.
  • Aprobación.
  • Respaldo previo.
  • Plan de implementación.
  • Plan de reversión.
  • Prueba posterior.
  • Documentación final.

10.12 Ventanas de mantenimiento

Una ventana de mantenimiento es un período acordado para realizar cambios que pueden afectar la operación. No todos los cambios requieren una ventana extensa, pero los cambios de alto impacto sí deben planificarse.

Ejemplos de cambios que suelen requerir ventana:

  • Actualización de firmware o sistema operativo del firewall.
  • Cambios en rutas principales.
  • Modificación de VPN críticas.
  • Activación de inspección profunda en tráfico sensible.
  • Pruebas de failover.
  • Migraciones de políticas o reemplazo de equipos.

10.13 Plan de reversión

Un plan de reversión indica cómo volver al estado anterior si el cambio falla. Debe definirse antes de implementar, no durante la emergencia.

Un buen plan de reversión incluye:

  • Configuración respaldada antes del cambio.
  • Pasos concretos para volver atrás.
  • Criterios para decidir reversión.
  • Responsables disponibles.
  • Tiempo estimado de recuperación.
  • Pruebas para confirmar que el servicio volvió a la normalidad.
Si no existe forma clara de volver atrás, el cambio tiene más riesgo del que parece.

10.14 Actualizaciones de firewall

Los firewalls también necesitan actualizaciones. Estas pueden corregir vulnerabilidades, mejorar estabilidad, agregar firmas, resolver fallas o incluir nuevas funciones.

Antes de actualizar conviene revisar:

  • Notas de versión del fabricante.
  • Compatibilidad con hardware, licencias y configuraciones actuales.
  • Impacto en VPN, HA, inspección y perfiles de seguridad.
  • Respaldo reciente y probado.
  • Plan de reversión.
  • Ventana de mantenimiento.
  • Monitoreo posterior a la actualización.

10.15 Monitoreo de disponibilidad

Un firewall crítico debe monitorearse. No basta con esperar a que los usuarios reporten caída de internet o de aplicaciones.

Métricas y eventos útiles:

  • Estado de HA y rol activo/pasivo.
  • Uso de CPU, memoria y sesiones.
  • Estado de interfaces y enlaces.
  • Caídas de VPN.
  • Errores de sincronización.
  • Eventos de failover.
  • Espacio disponible para logs.
  • Estado de licencias y firmas de seguridad.

10.16 Ejemplo práctico: cambio de regla crítica

Supongamos que se necesita permitir una nueva comunicación desde una aplicación en DMZ hacia una base de datos interna. Un proceso responsable podría ser:

  1. Recibir solicitud con origen, destino, puerto, protocolo y justificación.
  2. Evaluar riesgo de permitir DMZ hacia red interna.
  3. Confirmar que el acceso es mínimo y necesario.
  4. Respaldar configuración del firewall.
  5. Crear regla específica con logging.
  6. Probar conectividad desde el origen autorizado.
  7. Confirmar que otros accesos siguen bloqueados.
  8. Monitorear logs y alertas IDS/IPS.
  9. Documentar cambio, responsable y fecha de revisión.

10.17 Ejemplo práctico: prueba de failover

Una prueba de failover debe realizarse con planificación. No se trata de apagar un equipo sin aviso y esperar que todo salga bien.

Pasos recomendados:

  • Definir ventana de prueba.
  • Confirmar respaldos recientes.
  • Registrar estado inicial de HA.
  • Notificar equipos afectados.
  • Ejecutar failover controlado.
  • Validar navegación, VPN, servicios publicados y comunicación interna.
  • Revisar logs y alertas.
  • Volver al estado esperado si corresponde.
  • Documentar tiempos, problemas y mejoras.

10.18 Errores frecuentes

  • Tener HA sin probarla: un diseño redundante no probado puede fallar cuando más se necesita.
  • Guardar respaldos solo en el firewall: si el equipo falla, el respaldo puede perderse.
  • No tener plan de reversión: aumenta el impacto de cambios fallidos.
  • Actualizar sin revisar compatibilidad: puede afectar VPN, HA o inspección.
  • Ignorar enlaces y switches: el firewall puede estar duplicado, pero la ruta seguir teniendo puntos únicos de falla.
  • No monitorear licencias o firmas: algunas funciones defensivas pueden quedar degradadas.

10.19 Lista de verificación inicial

  • Identificar firewalls críticos y puntos únicos de falla.
  • Verificar si existe HA y cuándo fue probada por última vez.
  • Revisar redundancia de enlaces, switches y energía.
  • Automatizar o calendarizar respaldos de configuración.
  • Guardar respaldos fuera del firewall y protegerlos.
  • Probar restauración de configuraciones.
  • Exigir respaldo y plan de reversión antes de cambios importantes.
  • Monitorear estado de HA, interfaces, VPN, recursos y logs.
  • Documentar ventanas de mantenimiento y resultados.
  • Revisar reglas y objetos después de cambios mayores.

10.20 Ideas clave para recordar

  • Un firewall puede ser un punto crítico de falla si no hay redundancia.
  • Alta disponibilidad reduce interrupciones, pero debe probarse.
  • La redundancia debe incluir enlaces, energía, switches y rutas.
  • Los respaldos de configuración deben estar protegidos, versionados y probados.
  • Todo cambio importante necesita análisis, respaldo, prueba y reversión.
  • El monitoreo operativo es parte de la defensa.

10.21 Conclusión

La seguridad de un firewall no depende solo de sus reglas. También depende de que esté disponible, respaldado, monitoreado y administrado con cambios controlados. Un firewall bien configurado pero sin continuidad operativa puede convertirse en un riesgo para la organización.

En el próximo tema estudiaremos registro y monitoreo de firewalls: logs, métricas, alertas y trazabilidad. Allí veremos cómo convertir la actividad del firewall en información útil para defensa e investigación.