Protección de SSH contra ataques

Publicado: febrero de 2026. Actualizado: agosto de 2026. Revisado por el equipo de seguridad SSH y gestión de claves de Encryption Consulting.

Secure Shell (SSH) protege la mayoría de las conexiones de administración remota, automatización y comunicación máquina a máquina en TI empresarial. El protocolo en sí, estandarizado actualmente en SSH-2, ha demostrado ser criptográficamente sólido. Los atacantes no rompen la criptografía de SSH; buscan algunas debilidades predecibles: servidores con autenticación por contraseña habilitada, binarios de OpenSSH sin parchear, acceso administrativo sin restricciones y claves reutilizadas o no administradas. Esta guía se centra específicamente en el endurecimiento proactivo , es decir, los controles concretos de servidor, acceso y red que detienen los ataques SSH antes de que tengan éxito. Para conocer las debilidades subyacentes del protocolo y el historial de CVE detrás de estos ataques, consulte nuestro artículo complementario sobre vulnerabilidades SSH . Para saber cómo administrar las claves SSH a lo largo de todo su ciclo de vida, desde el descubrimiento y la propiedad hasta la rotación y la auditoría, consulte nuestra guía de administración del ciclo de vida de las claves SSH.

¿Qué técnicas de ataque SSH se utilizan contra los servidores empresariales?

Los servidores SSH empresariales son atacados mediante cuatro técnicas principales: adivinación de contraseñas por fuerza bruta, relleno de credenciales, interceptación mediante ataque de intermediario y explotación de vulnerabilidades (CVE) sin parchear, además de fallos operativos como el robo de claves y la inserción de claves a través de puertas traseras que no requieren romper el protocolo en absoluto.

• Adivinación de contraseñas por fuerza bruta: Los scripts automatizados intentan miles de combinaciones de nombre de usuario y contraseña contra servidores SSH accesibles desde internet en el puerto 22. Cualquier servidor con autenticación por contraseña habilitada se convierte en objetivo en el momento en que un escáner de puertos lo detecta.
• Relleno de credenciales: Los atacantes reutilizan pares de nombres de usuario y contraseñas filtrados en brechas de seguridad no relacionadas, apostando a la reutilización de contraseñas. Dado que SSH no limita la velocidad de forma predeterminada, un solo servidor expuesto puede absorber miles de intentos de relleno por hora sin que se active una alerta.
• Intercepción de hombre en el medio (MITM): Un atacante ubicado en la ruta de red presenta una clave de host falsificada para interceptar o degradar una sesión. Esto es posible gracias a clientes SSH que ignoran las advertencias de clave de host o a servidores con la comprobación estricta de clave de host desactivada.
• Explotación conocida de CVE: Los binarios de OpenSSH sin parchear siguen siendo vulnerables mucho después de que se publique una solución. CVE-2024-6387 (“regreSSHion”), una condición de carrera en el manejador de señales del servidor OpenSSH (sshd) que afecta a las versiones 8.5p1 a 9.8p1, tiene una puntuación CVSS de 8.1 y permite que un atacante remoto no autenticado active un manejo de señales inseguro en sistemas Linux basados ​​en glibc (NVD, CVE-2024-6387). OpenSSH publicó una solución en la versión 9.8p1; los servidores que aún ejecutan una versión afectada permanecen expuestos independientemente de lo bien que esté configurado todo lo demás.
• Claves privadas robadas o filtradas: Una clave privada copiada de un punto final comprometido, una copia de seguridad expuesta o un repositorio de código público otorga acceso inmediato y autenticado. Dado que SSH considera una clave válida como prueba de identidad, ese inicio de sesión no genera ninguna alerta de autenticación fallida. El incidente de CircleCI de enero de 2023, en el que un atacante utilizó malware y una cookie de sesión robada en el portátil de un ingeniero para acceder a los sistemas de producción, llevó a la empresa a recomendar a todos sus clientes que rotaran las claves SSH, los tokens y otros secretos almacenados como medida de precaución (CircleCI, 2023).
• Inserción de llave por la puerta trasera: Con acceso limitado al sistema de archivos, un atacante agrega su propia clave pública a la de un usuario. ~ / .ssh / Authorizedkeys archivo. Sin malware, sin cambios binarios, solo una línea de confianza adicional que la mayoría de las organizaciones nunca auditan.

Cada una de estas técnicas aprovecha una vulnerabilidad que el endurecimiento de la seguridad corrige directamente. El resto de esta guía detalla los controles específicos, por propietario, por capa de acceso y por mecanismo de rotación, que bloquean cada ruta. Para un análisis técnico más profundo de las debilidades del protocolo SSH y las vulnerabilidades históricas (CVE), consulte el artículo « Vulnerabilidades de SSH y cómo protegerse contra ellas».

¿Quién es el responsable del endurecimiento de SSH en la empresa?

Los controles de seguridad SSH suelen estar divididos entre tres responsables: el equipo de seguridad establece la política base, los equipos de infraestructura y plataforma la aplican en sshd_config y el aprovisionamiento de hosts, y los equipos de DevOps o automatización son responsables de las claves que generan sus pipelines. Sin un responsable designado para cada capa, la seguridad se desvía en el momento en que se aprovisiona un nuevo servidor fuera de la imagen estándar.

• Equipo de seguridad: Define la base de cifrado, MAC y algoritmo; establece la política de inicio de sesión de root y autenticación por contraseña; establece el requisito de MFA para el acceso administrativo.
• Equipo de infraestructura y plataforma: Aplica y mantiene esa línea base mediante la gestión de la configuración o imágenes maestras, y realiza un seguimiento de los niveles de parches de OpenSSH en toda la flota.
• Equipos de DevOps y de aplicaciones: Son propietarios de las claves de automatización y de las cuentas de servicio que generan sus canalizaciones, solicitan acceso a través de un flujo de trabajo de aprobación y son responsables de la rotación de lo que crean.

Esto refleja el modelo de propiedad detallado en nuestra guía completa de gestión del ciclo de vida de las claves SSH , que abarca el descubrimiento, el aprovisionamiento y la gobernanza de claves de principio a fin. Esta sección se centra específicamente en la cuestión de la propiedad que importa para el endurecimiento contra ataques: quién puede cambiar la configuración base de endurecimiento y quién es responsable cuando un host se desvía de ella. La desviación de la configuración, un único nodo sin parchear o mal configurado, es una de las formas más comunes en que una flota reforzada vuelve a ser vulnerable. Asigne a un equipo la propiedad de la configuración base de sshd_config y aplíquela mediante la gestión de la configuración, en lugar de pedir a cada administrador que la recuerde.

¿Cómo se refuerza la política de acceso SSH?

El endurecimiento de la política de acceso implica aplicar la autenticación solo con clave, deshabilitar el inicio de sesión directo como administrador y enrutar cada sesión administrativa a través de un servidor intermedio, de modo que una contraseña robada o un único punto final comprometido ya no puedan acceder directamente a un servidor.

• Deshabilitar la autenticación por contraseña (Autenticación de contraseña no): elimina por completo los ataques de fuerza bruta y de relleno de credenciales al eliminar el tipo de credencial al que se dirigen dichos ataques.
• Deshabilitar el inicio de sesión root (PermitRootLogin no): obliga a los atacantes y a los administradores a autenticarse como una cuenta con nombre y a escalar privilegios mediante sudo, preservando la atribución y añadiendo un paso antes de que sea posible el control total del sistema.
• Se requiere autenticación multifactor para las sesiones interactivas. utilizando OpenSSH Métodos de autenticación directiva (por ejemplo, clave pública, teclado interactivo), por lo que una clave privada robada por sí sola no es suficiente para acceder a la consola.
• Limitar la frecuencia de los intentos de autenticación: y configure MaxAuthTries a un valor bajo y un corto Iniciar sesiónGraceTimey añadir una herramienta como fail2ban o sshguard para bloquear automáticamente las direcciones IP de origen tras repetidos fallos. La Guía de seguridad de la infraestructura de red de la NSA recomienda limitar los reintentos de autenticación e imponer un retraso en el inicio de sesión específicamente para frenar los intentos de fuerza bruta (NSA, 2022).
• Restringir algoritmos: deshabilitar SSH-1, cifrados obsoletos (3DES, Blowfish, modo CBC) y MAC débiles (SHA-1), y podar módulos Diffie-Hellman menores de 2048 bits. / etc / ssh / moduli para reducir el riesgo de degradación e interceptación.
• Deshabilitar el reenvío innecesario: Desactivar el agente, X11 y el reenvío de puertos por defecto. Un host comprometido con el reenvío de agente habilitado permite que un atacante se autentique en otro lugar sin necesidad de acceder a la clave privada.
• Enrutar el acceso administrativo a través de un servidor bastión (de salto): Un único punto de acceso, bien supervisado, que aplica la autenticación multifactor (MFA), registra las sesiones y aplica controles consistentes, manteniendo los sistemas de producción aislados de la exposición directa.
• Redes de segmentos y acceso a zonas: Los sistemas de producción no deben aceptar acceso directo mediante claves desde los servidores de desarrollo o de pruebas. Aislar los límites de confianza limita el alcance del ataque una vez que un servidor se ve comprometido.

¿Cuándo se deben rotar las claves y credenciales SSH después de un ataque?

Las claves SSH y las credenciales de host deben rotar según desencadenantes definidos, no solo según un calendario fijo: compromiso confirmado o sospechado, baja de usuario, una vulnerabilidad CVE recientemente revelada que afecte a la versión de SSH en uso, exposición en un repositorio o copia de seguridad, y el final de un criptoperíodo definido para claves de automatización de larga duración.

1. Compromiso de clave confirmado o sospechado: Rotar y revocar inmediatamente, en todos los hosts que confían en la clave afectada.
2. Desvinculación de empleados o contratistas: revocar el mismo día, no incluirlo en una revisión de acceso periódica.
3. Un nuevo CVE que afecta a la versión de OpenSSH en uso (como regreSSHion): primero aplique el parche y considere volver a emitir claves de host si la vulnerabilidad pudiera haber expuesto material de clave de manera plausible.
4. Una clave encontrada en un repositorio público, copia de seguridad o unidad compartida: Trátelo como si estuviera expuesto y rótelo, independientemente de si se ha confirmado un uso indebido.
5. Vencimiento programado del período criptográfico Para claves de automatización y de cuentas de servicio de larga duración, la norma NIST IR 7966 recomienda gestionar estas claves con el mismo rigor que se aplica a las contraseñas y los certificados.
6. Un cambio en el alcance o privilegio Para acceder al sistema se requiere una clave.

La rotación activada por eventos detecta los incidentes que la rotación basada en calendario no registra. Una clave robada al día siguiente de su última rotación programada sigue siendo válida durante meses bajo una política puramente periódica.

¿Qué evidencia de auditoría demuestra el cumplimiento de las medidas de endurecimiento de SSH?

Los auditores y los marcos de cumplimiento, como SOC 2, ISO 27001 y PCI DSS, esperan pruebas documentadas de que los controles de seguridad están configurados y se aplican, y no solo descritos en un documento de política.

• sshd_config Instantáneas de referencia o resultados de escaneo de CIS Benchmark que muestren la autenticación de contraseña, el inicio de sesión de root y los cifrados y MAC permitidos en toda la flota.
• Inventario actualizado de claves SSH: propietario, finalidad, fecha de creación, último uso e historial de rotación para cada clave.
• Registros de autenticación y de sesión del servidor bastión, conservados según la política establecida, que muestran quién accedió a qué y cuándo.
• Registros de aplicación de la autenticación multifactor para cuentas administrativas.
• Los registros de parches y versiones que muestran que OpenSSH está actualizado en todos los hosts son directamente relevantes para las ventanas de exposición de CVE como CVE-2024-6387.
• Los registros de rotación y revocación están vinculados a los desencadenantes mencionados anteriormente, no solo a los eventos programados.

La recopilación manual de esta información en cientos o miles de hosts es donde fallan la mayoría de los programas de seguridad. Centralizar el inventario de claves y el estado de configuración, en lugar de reconstruirlo durante la temporada de auditorías, es una de las ventajas más evidentes de una plataforma de gobernanza SSH gestionada.

Tipo de ataque frente a control de mitigación

La tabla que aparece a continuación relaciona cada técnica de ataque descrita anteriormente en esta guía con el control de endurecimiento que la aborda directamente.

Tipo de ataque	Cómo Funciona	Control de endurecimiento primario
Adivinación de contraseñas por fuerza bruta	Intentos de inicio de sesión automatizados y repetidos contra un puerto expuesto 22	Deshabilitar la autenticación por contraseña; limitar la tasa con fail2ban/sshguard; MaxAuthTries bajo
Relleno de credenciales	Reproducción a gran escala de pares de nombre de usuario/contraseña vulnerados.	Autenticación solo con clave; MFA; lista blanca de direcciones IP en el host bastión.
Intercepción de hombre en el medio	El atacante intercepta o falsifica la sesión utilizando una clave de host falsificada.	Verificación estricta de la clave del host; identidad del host basada en certificados
Explotación conocida de CVE (por ejemplo, CVE-2024-6387)	Explotar de forma remota una vulnerabilidad de OpenSSH sin parchear	Gestión programada de parches; seguimiento de versiones; análisis de vulnerabilidades
Claves privadas robadas o filtradas	Clave exfiltrada desde un punto final, repositorio o copia de seguridad.	Claves protegidas con contraseña o respaldadas por HSM; claves de corta duración/efímeras; revocación inmediata en caso de exposición.
Inserción de llave de puerta trasera	El atacante agrega una clave no autorizada a authorized_keys después de un acceso limitado.	Permisos de archivo restringidos; inventario centralizado de claves; monitorización de la integridad de los archivos.
Movimiento lateral a través de la expansión de la confianza	Claves reutilizadas o duplicadas que se comparten entre los entornos de desarrollo, pruebas y producción.	Segmentación de red; host bastión; confianza con ámbito definido y específica del entorno

Refuerzo manual de sshd_config frente a gobernanza SSH gestionada: ¿Cuál se adapta mejor a cada situación?

El endurecimiento manual de sshd_config funciona para un número reducido de servidores. Más allá de eso, la deriva de la configuración y la rotación inconsistente de claves reintroducen precisamente los riesgos que el endurecimiento pretendía eliminar, razón por la cual la mayoría de las empresas migran a una plataforma de gobernanza SSH administrada o automatizada una vez que su flota supera las pocas docenas de hosts.

Dimensión	Refuerzo manual de sshd_config	Gobernanza SSH gestionada/automatizada
Esfuerzo de configuración inicial	Bajo para un solo anfitrión	Mayor precio inicial, pero constante a gran escala.
Coherencia en toda la flota	Depende de la disciplina; varía a medida que se añaden anfitriones.	Aplicado centralmente mediante política
Rotación de claves	Manual, propenso a errores, difícil de verificar	Basado en políticas, automatizado, registrado
Visibilidad sobre quién tiene qué llave	Limitado a lo que está documentado	Descubrimiento e inventario continuos
Generación de evidencia de auditoría	Reconstruido manualmente según auditoría	Generado de forma continua, exportable bajo demanda.
Velocidad de respuesta ante incidentes	Limitado por la rapidez con la que se pueden encontrar y revocar las claves manualmente.	Revocación centralizada en todos los hosts de confianza.

Ninguno de los enfoques reemplaza por completo al otro. La configuración base de sshd_config , el host bastión y la segmentación de red descritos anteriormente son fundamentales, independientemente de la escala. Lo que cambia a gran escala es si esos controles se mantienen aplicados y verificables a lo largo del tiempo, que es la brecha que las plataformas gestionadas están diseñadas para cerrar.

¿Cómo se implementa el endurecimiento de SSH? Un flujo de trabajo práctico

La implementación de medidas de seguridad reforzadas para SSH sigue una secuencia repetible: inventariar lo que existe, establecer la línea base, restringir el acceso y, a continuación, verificar continuamente.

1. Inventarie todos los hosts expuestos mediante SSH y las claves existentes. para que nada se endurezca por suposición.
2. Establecer una resistencia sshd_config base: Deshabilitar la autenticación por contraseña, deshabilitar el inicio de sesión como root, restringir los cifrados y los MAC, y exigir únicamente SSH-2.
3. Implemente la autenticación solo con clave, utilizando claves protegidas con contraseña o respaldadas por un módulo de seguridad de hardware (HSM).
4. Implementa un servidor bastión o un servidor de salto. para todo acceso administrativo y requerir autenticación multifactor.
5. Añadir limitación de velocidad y protección contra ataques de fuerza bruta. (fail2ban, sshguard o equivalente) en la capa de red y de host.
6. Redes de segmentos Por lo tanto, los sistemas de producción no confían en las claves de desarrollo o de preproducción.
7. Aplicar parches y control de versiones a OpenSSH en toda la flota. y realizar un seguimiento de las vulnerabilidades CVE en relación con las versiones realmente desplegadas.
8. Definir activadores de rotación y automatizar la rotación y la revocación contra ellos.
9. Activar el registro y la monitorización centralizados. con alertas para patrones de acceso anómalos.
10. Generar evidencia de auditoría según un cronograma y validar la flota comparándola con la configuración de referencia, en lugar de asumir que sigue coincidiendo con la configuración del primer día.

¿Qué ocurre si un atacante ya tiene acceso SSH?

Si el acceso SSH ya se ha visto comprometido, los controles de seguridad limitan el alcance del ataque, pero la respuesta en sí, la revocación, el análisis del alcance y la recuperación siguen un proceso independiente y urgente. El endurecimiento reduce la frecuencia de este escenario y el alcance del ataque una vez dentro del sistema, pero no constituye un plan de respuesta a incidentes. Para conocer el proceso paso a paso de contención, análisis de impacto y recuperación que se debe seguir una vez que se confirma la exposición de una clave o credencial, consulte nuestra guía específica: Respuesta a incidentes para claves SSH expuestas.

Limitaciones

Reforzar la seguridad reduce significativamente la superficie de ataque, pero no hace que SSH sea invulnerable, y tratarlo como un proyecto puntual en lugar de un control continuo socava todo el esfuerzo.

• Las medidas de seguridad no pueden evitar que se explote una vulnerabilidad de día cero antes de que exista un parche. Las actualizaciones oportunas reducen este margen de tiempo, pero nunca lo eliminan por completo.
• Deshabilitar el inicio de sesión de root y la autenticación por contraseña no impide que un empleado haga un uso indebido de una clave emitida legítimamente. Para ello, se requiere acceso con privilegios mínimos y monitorización.
• Un servidor bastión y la segmentación de la red reducen el movimiento lateral, pero no lo eliminan si el propio servidor bastión no está suficientemente monitorizado o tiene privilegios excesivos.
• El endurecimiento de la configuración, aplicado una sola vez y nunca vuelto a verificar, se degrada a medida que se añaden nuevos hosts, imágenes y sistemas de automatización.
• Ninguno de estos controles sustituye a un plan de respuesta ante incidentes probado cuando una clave o credencial queda expuesta.

¿Qué recomendaría Encryption Consulting?

Encryption Consulting recomienda combinar la configuración manual de seguridad descrita anteriormente con una plataforma que la aplique de forma continua y pueda demostrar su validez durante una auditoría, ya que la configuración manual por sí sola rara vez se mantiene a pesar del crecimiento de la infraestructura. Aquí es precisamente donde entra en juego SSH Secure , que subsana las deficiencias que dejan las modificaciones individuales de sshd_config.

• Mapeo centralizado de visibilidad y propiedad

  SSH Secure detecta todas las claves SSH en servidores y estaciones de trabajo de usuarios mediante escaneo con y sin agente, consolidándolas en un único inventario vinculado a los datos de propietario y uso. Esto elimina los puntos ciegos, suprime las claves huérfanas y cierra la brecha de visibilidad que los atacantes aprovechan para insertar claves de acceso no autorizado o reutilizar credenciales obsoletas.

• Claves efímeras vinculadas a la sesión

  Para accesos sensibles o temporales, SSH Secure puede emitir claves de corta duración vinculadas a la sesión que caducan automáticamente tras su uso. Una clave que ya no existe no puede ser descifrada mediante fuerza bruta, manipulada ni robada de una copia de seguridad meses después.

• Protección de clave privada respaldada por HSM

  Las claves privadas se generan y almacenan en módulos de seguridad de hardware (HSM), lo que garantiza su inexportabilidad y resistencia a la manipulación, abordando directamente los escenarios de robo de claves y vulneración de sistemas. Los algoritmos compatibles incluyen RSA-4096, ECDSA y Ed25519.

• Aplicación de la normativa básica basada en políticas

  La generación, aprobación, rotación y revocación de claves se rigen por controles de políticas consistentes, lo que evita la desviación de la configuración que, con el tiempo, permite la reapertura silenciosa de una flota reforzada.

• Supervisión continua, auditoría y preparación para el cumplimiento normativo.

  La monitorización en tiempo real, el registro detallado de eventos y la detección de anomalías generan la evidencia de auditoría descrita anteriormente en esta guía sin necesidad de reconstrucción manual. Los registros se integran con plataformas como Splunk o Loki/Grafana para su correlación y la generación de alertas.

Conclusión

Proteger SSH contra ataques no se trata de encontrar una solución mágica. Las herramientas de fuerza bruta y de relleno de credenciales fallan ante la autenticación basada únicamente en claves. La interceptación de ataques Man-in-the-Middle (MITM) falla ante la verificación estricta de la clave del host. Las vulnerabilidades CVE conocidas, como regreSSHion, fallan ante un programa de parches real. Las claves robadas y con puertas traseras fallan ante el almacenamiento respaldado por HSM, las credenciales efímeras y un inventario centralizado que hace visibles las claves no autorizadas en lugar de invisibles.

Ninguno de estos controles funciona de forma aislada, y ninguno se mantiene efectivo sin un responsable, un mecanismo de rotación y evidencia de auditoría que los respalde. Las organizaciones que consideran el endurecimiento de SSH como una base de referencia que se aplica continuamente, y no como una configuración única, cierran las vías que los atacantes realmente utilizan. Para conocer el ciclo de vida completo de las claves que respaldan estos controles, consulte nuestra guía de gestión del ciclo de vida de las claves SSH ; para saber qué hacer cuando una clave ya está expuesta, consulte Respuesta a incidentes para claves SSH expuestas.

Preguntas frecuentes

¿Cuál es la medida de control más eficaz contra los ataques de fuerza bruta SSH? Deshabilitar la autenticación por contraseña y exigir el inicio de sesión solo con clave es la medida más eficaz, ya que elimina el tipo de credenciales que las herramientas de fuerza bruta y de relleno de credenciales están diseñadas para adivinar. Combínala con la limitación de la tasa de conexiones (MaxAuthTries, un LoginGraceTime corto y una herramienta como fail2ban o sshguard) para que los intentos fallidos repetidos desde cualquier origen se bloqueen automáticamente.

¿Deshabilitar el inicio de sesión como root impide la escalada de privilegios en un servidor SSH comprometido? No. Deshabilitar el inicio de sesión como root (PermitRootLogin no) obliga al atacante a autenticarse como una cuenta con nombre y a escalar privilegios mediante sudo, lo que facilita la identificación del atacante y añade un paso, pero no impide la escalada por sí solo. Debe combinarse con reglas de sudo de mínimo privilegio, registro de comandos y monitorización del uso inusual de privilegios.

¿Con qué frecuencia se deben rotar las claves SSH para protegerse contra ataques? No existe un intervalo único que se ajuste a todas las claves. Las claves de automatización y de cuentas de servicio de larga duración deben seguir un criptoperiodo definido, pero la rotación también debe activarse inmediatamente ante eventos específicos: sospecha de compromiso, baja de un empleado o contratista, detección de una clave en un repositorio público o copia de seguridad, o una vulnerabilidad CVE recientemente descubierta que afecte a la versión de SSH en uso.

¿Sigue siendo necesario un servidor bastión si los administradores ya utilizan la autenticación solo con clave? Sí. La autenticación solo con clave detiene los ataques basados ​​en contraseñas, pero un servidor bastión ofrece ventajas que la autenticación basada en claves por sí sola no proporciona: aplicación centralizada de la MFA, registro de sesiones, un único punto de entrada auditado y el aislamiento de los sistemas de producción frente a la exposición directa. Sin él, cada servidor se convierte en un punto de acceso independiente y descoordinado, con controles inconsistentes.

¿Aplicar el parche para la vulnerabilidad CVE-2024-6387 garantiza la seguridad de un servidor SSH? No. Si bien actualizar OpenSSH a la versión 9.8p1 ​​o posterior soluciona esa condición de carrera específica, regreSSHion era solo una de las muchas vulnerabilidades posibles. Un servidor puede estar completamente actualizado y aun así quedar expuesto mediante autenticación por contraseña, inicio de sesión de root permitido, claves no administradas o falta de segmentación de red. La actualización es necesaria, pero no suficiente.

Referencias

• NIST IR 7966, “Seguridad de la gestión de acceso interactivo y automatizado mediante Secure Shell (SSH)”: https://nvlpubs.nist.gov/nistpubs/ir/2015/nist.ir.7966.pdf
• NVD, registro detallado de CVE-2024-6387: https://nvd.nist.gov/vuln/detail/CVE-2024-6387
• NSA, “Guía de seguridad de la infraestructura de red” (2022): https://media.defense.gov/2022/Jun/15/2003018261/-1/-1/0/CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDE_20220615.PDF
• CircleCI, “Informe de incidentes de seguridad del 4 de enero de 2023”: https://circleci.com/blog/jan-4-2023-incident-report