Kassinipedia

SSL Inbound Inspection

Se lee en 7 min

SSL Inbound Inspection

Resumen

Cuando publicas un servidor propio en Internet (por ejemplo un servidor web en la DMZ), usuarios de cualquier lugar se conectan a él por HTTPS. Ese tráfico llega cifrado y el firewall no puede ver si dentro viene un exploit, una inyección SQL o un archivo malicioso. SSL Inbound Inspection permite descifrar ese tráfico entrante, inspeccionarlo con los perfiles de seguridad, y entregarlo al servidor.
A diferencia de Forward Proxy, aquí el firewall no genera certificados falsos: usa el certificado real del servidor y su clave privada, que importas en el firewall. Como tiene la clave, el firewall puede descifrar la sesión y volver a cifrarla. Los clientes no ven ninguna diferencia, porque reciben el certificado real del servidor. Esta nota explica cómo importar el certificado con su clave (PKCS12), crear la regla de Decryption de tipo SSL Inbound Inspection y comprobar que el tráfico se descifra.

Requisitos previos

Sin la clave privada no hay Inbound Inspection

El firewall solo puede descifrar la sesión si tiene la clave privada del servidor. Con un certificado sin clave, esta función no puede funcionar.

Cómo funciona

sequenceDiagram
    participant C as Cliente (outside)
    participant F as Firewall (Inbound Inspection)
    participant S as Servidor (dmz)
    C->>F: HTTPS hacia el servidor publicado
    F->>F: Usa certificado y clave privada del servidor<br/>para descifrar la sesión
    F->>F: Inspección: AV, Vulnerability, WildFire...
    F->>S: Reenvía el tráfico al servidor
    S-->>F: Respuesta
    F-->>C: Respuesta cifrada
DiferenciaForward ProxyInbound Inspection
DirecciónUsuarios hacia InternetInternet hacia tu servidor
CertificadoGenerado por el firewall con Forward TrustCertificado real del servidor, importado con su clave
ClientesDeben confiar en tu CANo necesitan nada
Dos sesiones TLSSí (cliente-firewall y firewall-servidor); el firewall usa la clave privada del servidor para terminar la sesión del cliente

Configuración (Ejemplo, Lab PCNSA)

Servidor web en la DMZ: 10.30.0.100, zona dmz, publicado hacia outside (ver Lab PCNSA (curso)).

1. Importar el certificado con la clave

  1. Device > Certificate Management > Certificates > Device Certificates > Import.
  2. Certificate Type Local.
  3. Certificate Name DMZ-Servers-Cert-and-Keys.
  4. Certificate File: Browse, el archivo .pfx.
  5. File Format Encrypted Private Key and Certificate (PKCS12).
  6. Passphrase y Confirm Passphrase: la contraseña del .pfx.
  7. Opcional: marca Block Private Key Export.
  8. OK. Commit.

2. Confirmar que NAT y Security Policy ya funcionan

  1. Antes de descifrar, comprueba que el servidor responde por HTTPS desde fuera.
  2. Debes tener una regla de NAT de destino y una regla de Security Policy Allow (por ejemplo out2dmz) con perfiles aplicados.

3. Decryption Profile (opcional pero recomendado)

  1. Objects > Decryption > Decryption Profile > Add. Name Inbound-Profile.
  2. Pestaña SSL Decryption > SSL Inbound Inspection: Block sessions with unsupported versions, Block sessions with unsupported cipher suites, Block sessions if resources not available.
  3. OK.

4. Regla de Decryption

  1. Policies > Decryption > Add. Name Inbound-DMZ.
  2. Source: Source Zone outside.
  3. Destination: Destination Zone dmz, Destination Address la misma que usa tu regla de Security Policy para ese servidor (la IP pública original si hay DNAT; 10.30.0.100 si no hay NAT). En la Decryption Policy se evalúa como en la Security Policy: zona de destino posterior al NAT y dirección original. Verifícalo con test decryption-policy-match.
  4. Options: Action Decrypt, Type SSL Inbound Inspection, Certificate DMZ-Servers-Cert-and-Keys, Decryption Profile Inbound-Profile.
  5. OK y Commit.

5. Probar

  1. Desde un cliente externo, abre https://<IP-pública-del-servidor>.
  2. El navegador debe mostrar el certificado real del servidor (el mismo de antes).
  3. En Monitor > Logs > Traffic debes ver la sesión con Decrypted yes.
  4. Para probar la inspección, genera una amenaza de prueba contra el servidor (por ejemplo una petición con un patrón de inyección conocido de laboratorio) y busca el log en Monitor > Logs > Threat.

Verificación

Comando o lugarQué debes verSi no lo ves
Monitor > Logs > Traffic, columna Decryptedyes en las sesiones al servidorSi dice no, la regla de Decryption no coincidió
Monitor > Logs > DecryptionHandshakes correctos con la versión TLS y el cipherActiva el logging de handshakes en la regla
Monitor > Logs > ThreatDetecciones en el tráfico descifradoSi está vacío, no hubo amenazas o falta el perfil en la regla Allow
show session id <n>Indicación de descifrado y la regla de DecryptionSi no aparece, no se descifró
test decryption-policy-match from outside to dmz destination <IP original del servidor> (verificar con Tab o ?)La regla Inbound-DMZSi no coincide, revisa zonas y dirección
Policies > Decryption: hit countContador sube al probarSi es cero, no coincide
Device > Certificate Management > CertificatesEl certificado importado, con la marca de clave privadaSi no tiene clave, importa de nuevo el PKCS12
Navegador: ver el certificadoEl del servidor, con emisor y fechas correctasSi cambió, algo más está interceptando

Errores comunes

El tráfico no se descifra

  • Causa: la regla de Decryption no coincide (zonas, IP de destino, orden), o falta el commit.
  • Revisa: test decryption-policy-match y la columna Decrypted en Traffic.
  • Solución: ajusta zona de destino e IP. Recuerda que se evalúa con la zona posterior al NAT y la IP original; si dudas, prueba con any en destino para aislar el problema.

La sesión falla al activar la regla

  • Causa: el certificado o la clave importados no corresponden al servidor, o el servidor usa un cipher o versión que el perfil bloquea.
  • Revisa: Monitor > Logs > Decryption (campo de error).
  • Solución: importa el PKCS12 correcto y ajusta el perfil.

No puedo importar el certificado

  • Causa: contraseña incorrecta, formato distinto a PKCS12 o archivo sin la clave privada.
  • Solución: exporta de nuevo desde el servidor incluyendo la clave privada y usa la contraseña correcta.

Hay intercambio de claves que no se puede descifrar

  • Causa: algún cipher o versión del servidor no está soportado por el firewall, o el Decryption Profile lo bloquea (por ejemplo “Block sessions with unsupported cipher suites”). Los cifrados con Perfect Forward Secrecy (ECDHE/DHE) sí se soportan, porque el firewall termina la sesión.
  • Solución: revisa la compatibilidad de versión y cipher en el Decryption Profile y en el servidor, y la documentación de tu versión de PAN-OS.

El servidor sigue sin protección aunque descifra

  • Causa: la regla Allow no tiene perfiles de seguridad.
  • Solución: aplica el perfil o grupo a la regla Allow que permite el tráfico.

Quiero proteger varios servidores con certificados distintos

  • Causa: una regla usa un solo certificado.
  • Solución: crea una regla de Decryption por servidor (destino distinto), cada una con su certificado, y ordénalas de lo específico a lo general.

Se renovó el certificado del servidor y Inbound Inspection falló

  • Causa: el firewall sigue con el certificado viejo.
  • Solución: importa el nuevo PKCS12, selecciónalo en la regla y haz commit cada vez que el servidor renueve su certificado.

Preocupación por la seguridad de la clave privada

  • Causa: la clave del servidor ahora está también en el firewall.
  • Solución: marca Block Private Key Export, restringe quién administra el firewall (ver Admin Authentication y RBAC) y protege los respaldos de configuración.

Vista Gráfica

Retroenlaces