IIS y OCSP: guía de hardening y seguridad efectiva

Si tu servidor de Online Responder (OCSP) ejecuta IIS, una buena política de hardening puede marcar la diferencia entre un servicio de validación robusto y una puerta abierta a atacantes. Este artículo explica, paso a paso, cómo responder a dos hallazgos frecuentes en auditorías (“nivel de confianza .NET” y “bloqueo de extensiones”) y amplía con un conjunto de medidas concretas para blindar el entorno.

Índice

Contexto de la auditoría

Durante la revisión de un servidor Windows Server que aloja el rol Online Responder se detectaron dos advertencias de configuración:

  • “Asegure que el nivel global de confianza de .NET esté configurado”.
  • “Bloquee extensiones de archivo no listadas”.

Aunque parecen genéricas, afectan directamente al núcleo del servicio OCSP y es importante tratarlas con precisión para no degradar la disponibilidad de la autoridad.

¿El servicio OCSP utiliza .NET?

El rol Online Responder se implementa íntegramente mediante una extensión ISAPI nativa llamada ocspisapi.dll. Esta biblioteca se carga dentro del proceso w3wp.exe, pero:

  • No incluye componentes ASP.NET.
  • No se cargan ensamblados administrados; es código nativo C++.
  • No realiza peticiones a la Common Language Runtime (CLR).

Por ello, el parámetro Nivel de confianza .NET (que controla la granularidad con la que los ensamblados administrados pueden ejecutar operaciones privilegiadas y acceder a recursos) no influye en la ejecución del Online Responder.

Acción recomendada

ConfiguraciónEstado óptimoJustificación
“Nivel global de confianza de .NET”Valor por defecto (Full)
o deshabilitar ASP.NET por completo
El servicio es 100 % nativo: ningún ensamblado .NET necesita cargarse.

En servidores dedicados exclusivamente a OCSP, desinstalar las características .NET Extensibility y ASP.NET reduce la superficie de ataque y simplifica el mantenimiento de parches.

Extensiones de archivo y mapeos de controlador

Por diseño, los clientes envían sus solicitudes OCSP mediante HTTP GET o POST a una URL parecida a:

https://ocsp.ejemplo.local/ocsp

Esa ruta no incluye extensión de archivo; IIS reencamina internamente la petición a ocspisapi.dll gracias al Handler Mapping “ISAPI‐dll” que ya viene creado durante la instalación del rol. En consecuencia:

  • La única extensión que debe existir es .dll, asociada al ejecutor ISAPI.
  • El resto de extensiones dinámicas (.aspx, .ashx, .php, etc.) y estáticas (.txt, .log, …) pueden bloquearse sin afectar la funcionalidad.

Acción recomendada

ReglaConfiguraciónComentario
Módulo “ISAPI‐dll”HabilitadoPermite ejecutar ocspisapi.dll.
Filtering → “Deny unlisted file extensions”HabilitadoBloquea cualquier extensión no especificada; añade explícitamente .dll como permitida.

Otras medidas de hardening para IIS + Online Responder

Cubiertos los dos hallazgos principales, conviene reforzar el entorno con controles complementarios.

Módulos de IIS

  • Desinstala o deshabilita WebDAV, Tracing, CGI, FastCGI y cualquier módulo que no sea estrictamente necesario.
  • Limita los Request Filters internos (Cabeceras, Verbos HTTP, tamaño de URL y cuerpo).

Métodos HTTP permitidos

  • Autoriza únicamente GET y POST.
  • Bloquea TRACE, OPTIONS, PUT, DELETE y PROPFIND para minimizar vectores de enumeración o subida de archivos.

Protocolos y cifrados

  • Deshabilita SSL 2.0, SSL 3.0 y TLS 1.0/1.1 en el registro (SChannel).
  • Aplica TLS 1.2 y TLS 1.3 (si el sistema lo permite) junto con los cifrados recomendados por los nuevos baseline de Windows Server.
  • Usa certificados con firmas SHA‑256 o superiores; evita claves RSA < 2048 bits.

Limitaciones a nivel de solicitud

  • Content‑Length: fija un máximo razonable (p.ej. 10 KB) – suficiente para la mayoría de peticiones OCSP.
  • Content‑Type: acepta únicamente application/ocsp-request (POST) o application/ocsp-response (respuestas ascendentes).

Seguridad del Application Pool

  • Crea un pool dedicado, aislado del resto de sitios.
  • Ejecuta el pool con la identidad predeterminada Network Service o, mejor aún, una Group Managed Service Account sin privilegios locales.
  • Activa la opción Rapid Fail Protection para evitar ciclos de reinicio si la ISAPI presenta fallos.
  • Establece el Idle Timeout en 0 para que el proceso no se descargue en momentos de baja actividad, evitando latencias de “calentamiento”.

Auditoría y monitorización

  • Habilita el registro “Microsoft ► Windows ► OnlineResponder” y revisa periódicamente eventos con ID 5125, 5136 y 5140 (estado de la base de revocación y errores de descodificación).
  • Implementa alertas en tu SIEM para Eventos 36874 y 36886 de SChannel (errores de negociación TLS).
  • Archiva los logs de IIS en un repositorio central y aplícales retención WORM cuando así lo requiera tu regulación sectorial.

Política de parches

  • Incluye Cumulative Updates de IIS y SChannel en el ciclo mensual de Windows Update.
  • Valida cada parche en entorno de preproducción para asegurar compatibilidad con ocspisapi.dll.
  • Documenta las dependencias de librerías (Visual C++ Runtime) para evitar sorpresas tras un reinicio.

Checklist rápido para el equipo de operaciones

ControlEstado esperadoValidación
Nivel de confianza .NETValor “Full” o ASP.NET deshabilitadoGet-WindowsFeature Net-Framework-*
Extensiones no listadasBloqueadas excepto .dll“Request Filtering ► File Extensions”
Módulos no usadosEliminados“IIS Mgr ► Modules”
Métodos HTTPSolo GET, POST“IIS Mgr ► Request Filtering ► HTTP Verbs”
TLSSolo 1.2/1.3HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Pool dedicadoSí / identidad restringida“IIS Mgr ► Application Pools”
Logging y SIEMActivadoRevisión semanal de eventos

Preguntas frecuentes

¿Puedo hospedar otros sitios en el mismo servidor OCSP?

Técnicamente es posible, pero no recomendable. Cada sitio adicional amplía la superficie de ataque y complica la gestión de puertos y certificados. Si necesitas compartir infraestructura, emplea pools separados, reforzados con límites de CPU y memoria.
¿Cuánto afecta el hardening al rendimiento?

El impacto es nulo o positivo. Bloquear extensiones y deshabilitar módulos innecesarios reduce ciclos de CPU y memoria. Habilitar TLS 1.2/1.3 con cifrados modernos puede incluso mejorar el throughput si la CPU admite instrucciones AES‑NI.
¿Qué sucede si bloqueo por error .dll?

Las peticiones OCSP devolverán HTTP 500 “Internal Server Error” y el Event Log mostrará fallos de ISAPI Filter. Por eso conviene documentar y respaldar la configuración antes de aplicar políticas restrictivas.
¿Hace falta habilitar HTTP/2 o HTTP/3?

El protocolo OCSP no se beneficia especialmente de HTTP/2 o 3, ya que cada respuesta suele ser de pocos cientos de bytes. No obstante, HTTP/2 puede reducir la latencia en entornos con gran concurrencia. Actívalo solo si tu equilibrio de carga y tu cliente lo soportan.

Conclusiones

En el ecosistema PKI corporativo, el Online Responder es un eslabón crítico. Aplicar un hardening minimalista (mantener solo el handler .dll y omitir ASP.NET) basta para solventar los hallazgos típicos de auditoría sin interferir con la operativa. Complementar con capas adicionales —cifrado fuerte, módulos mínimos, auditoría continua— asegura un servicio OCSP resiliente, estable y alineado con las mejores prácticas de seguridad.

Índice