Roadmap de ciberseguridad: profesional sosteniendo una tablet de la que surge un escudo con un candado

El Roadmap de Ciberseguridad que Siguió la Mayoría del Sector

Si llevas semanas leyendo rutas de aprendizaje en ciberseguridad y cada una te dice algo distinto, el problema no es tuyo. Muchas están escritas al revés: primero se decide qué curso vender y después se dibuja el camino que lleva hasta él.

Los roles reales del sector están definidos en marcos públicos y gratuitos, y este roadmap de ciberseguridad se apoya en ellos en lugar de inventarse las etapas. También te dice qué cambió hace poco, porque varias recomendaciones que siguen circulando ya son falsas.

También responde de frente las dos preguntas que más bloquean a quien empieza: por qué las rutas se contradicen entre sí, y si conviene empezar por seguridad ofensiva o defensiva.

Lo esencial

  • Los roadmaps de ciberseguridad se contradicen porque casi ninguno se apoya en un marco de roles público. Existen al menos tres, y son gratuitos.
  • La pregunta “¿ofensiva o defensiva?” no tiene respuesta útil al principio. Las tres primeras fases son las mismas en ambos casos.
  • El camino estadísticamente normal no empieza en seguridad: el 56 % de los profesionales llegó desde un puesto de TI, y solo el 10 % desde formación específica en ciberseguridad.
  • El acceso gratuito a la certificación CC de ISC2 se cerró el 20 de mayo de 2026. Hoy el examen cuesta 199 USD. Muchas guías lo siguen recomendando como gratuito.
  • Ningún marco oficial publica cuánto se tarda. Quien te da un número exacto se lo está inventando.
  • Protege tu propia huella desde el primer día, antes de tocar nada. Es lo único de esta lista que sigue valiendo aunque abandones el sector.
Roadmap de ciberseguridad: las seis fases, de fundamentos de redes a validación
Las tres primeras fases son idénticas tanto si vas a atacar como si vas a defender.

Por qué los roadmaps de ciberseguridad se contradicen entre sí

Se contradicen porque cada autor define sus propias fases, sin referencia común. No hay un desacuerdo técnico de fondo: hay ausencia de anclaje.

Hay además un segundo problema, más silencioso. Las respuestas habituales no son falsas: son inservibles por generales.

Cuando alguien pregunta por dónde empezar, la contestación suele ser “Linux” y “redes”. Las dos son ciertas. Ninguna de las dos dice nada, porque cada una es un océano.

Quien se apunta a un curso con esa indicación acaba decepcionado con lo básico que aprende, no porque el curso sea malo, sino porque nadie le dijo a dónde llevaba. Sin destino, lo que sigue es repetir el mismo nivel una y otra vez, o saltar de un área a otra hasta dar por casualidad con la que servía.

Y el anclaje existe. Hay marcos públicos, gratuitos y mantenidos por organismos que no venden formación, que ya definen qué roles existen en ciberseguridad y qué competencias pide cada uno.

El NICE Framework del NIST, en su versión 2.2.0, organiza el trabajo en cinco categorías: Oversight and Governance, Design and Development, Implementation and Operation, Protection and Defense e Investigation.

El propio marco advierte: “Work Roles are not synonymous to job titles or occupations”. Los roles no son puestos de trabajo, sino agrupaciones de tareas y competencias.

El ECSF de ENISA, el marco europeo, resume el sector en 12 perfiles profesionales. Su documento de perfiles se publicó el 19 de septiembre de 2022 y ahora mismo está en revisión para incorporar niveles de competencia.

Ninguno de los dos etiqueta un perfil como “de entrada”. Eso ya te dice algo: la idea de que hay un primer puesto obvio y universal es una simplificación de las academias, no una realidad del sector.

Usa estos marcos como mapa de destinos, no como temario. Sirven para saber a dónde puedes llegar; qué estudiar el lunes lo decides tú.

¿Seguridad ofensiva o defensiva? La pregunta que te está bloqueando

No la respondas todavía. Es una decisión de la quinta fase, no de la primera.

Las tres primeras etapas de cualquier ruta seria son idénticas en ambos caminos. Necesitas entender redes, sistemas operativos y conceptos de seguridad tanto si vas a atacar como si vas a defender. Elegir rama antes de tener esa base es elegir sin información.

Hay además un desequilibrio de atención. La rama ofensiva concentra casi todo el interés público, pero el sector es mucho más ancho: operaciones de seguridad, respuesta a incidentes, forense, arquitectura, auditoría, riesgo, cumplimiento, investigación y formación son territorios propios, con sus propios perfiles en los marcos que acabas de ver.

Si te atrae lo ofensivo, perfecto. Pero llegarás mejor preparado si recorres las mismas fases iniciales que todo el mundo. La prisa por saltar directamente a técnicas de ataque es la causa más frecuente de rutas abandonadas a medias.

El camino que de verdad recorre la mayoría

El dato que ordena todo lo demás es este: la mayoría de la gente no entró al sector por la puerta de la ciberseguridad.

Según el estudio de fuerza laboral de ISC2 publicado el 4 de diciembre de 2025, con 16.029 profesionales encuestados, las vías de entrada reales son estas:

Vía de entradaPorcentaje
Desde un puesto de TI56 %
— asumiendo tareas de seguridad dentro de un puesto de TI antes de moverse36 %
— pasando directamente de TI a seguridad, sin paso intermedio20 %
Desde formación específica en ciberseguridad10 %
Desde experiencia profesional ajena a TI8 %
A través de certificaciones6 %
Explorando por cuenta propia4 %
Desde el ámbito militar3 %
Por prácticas o programas de aprendizaje3 %

Lee otra vez la segunda fila. El 36 % empezó a hacer tareas de seguridad mientras ya trabajaba en TI, y desde ahí se movió a un puesto dedicado.

Un empleo de soporte técnico, de administración de sistemas o de redes no es un desvío ni un premio de consolación. Es la rampa de acceso que usó más de la mitad del sector.

Lo curioso es que nadie llega buscando eso.

En nuestras propias páginas sobre cómo convertirse en hacker vemos entrar cuarenta búsquedas distintas en tres meses. Encabezan “aprender hacking”, “cómo ser hacker”, “aprender a hackear” y “cómo empezar a hackear”.

Ninguna de las cuarenta menciona defensa, análisis, respuesta a incidentes ni empleo. Ni una. Esa distancia entre lo que se busca y lo que se contrata es, probablemente, el motivo por el que tantas rutas terminan abandonadas.

El patrón se desplaza entre los más jóvenes, pero menos de lo que parece. Entre los 21 y los 29 años, el 38 % entró por la vía de TI, otro 38 % por vías distintas a TI o a la formación en ciberseguridad, y el 23 % completando un programa universitario.

En los tramos de más edad la vía de TI domina con claridad: 54 % entre 30 y 44 años, 64 % entre 45 y 59, y 65 % a partir de 60.

Que existan puestos sin requisitos formales no significa que se cubran rápido.

En Europa, el 19 % de las organizaciones tiene vacantes de nivel inicial que no exigen experiencia, título ni credenciales. Aun así, el 45 % tarda entre tres y seis meses en cubrirlas.

Son datos de ISACA, sobre 740 profesionales europeos de una muestra global de más de 3.800, con trabajo de campo en mayo de 2025.

La búsqueda de empleo es, entonces, una fase con duración propia, y no empieza cuando terminas de estudiar.

Las seis fases de un roadmap de ciberseguridad

Las rutas publicadas se contradicen en los detalles, pero coinciden en el orden general. Esta es la columna vertebral de cualquier roadmap de ciberseguridad.

Fase 1. Fundamentos de TI, redes y sistemas operativos

Aprende cómo funciona lo que vas a proteger, antes de estudiar cómo protegerlo.

Necesitas el modelo de capas y el funcionamiento de TCP/IP, direccionamiento, DNS, HTTP y HTTPS. Del lado de los sistemas, manejo real de línea de comandos en Linux y en Windows, permisos, procesos, servicios y registro de eventos. Y virtualización suficiente para levantar máquinas y conectarlas entre sí.

Sabrás que terminaste esta fase cuando puedas montar una red pequeña con varias máquinas virtuales, explicar qué ocurre desde que escribes una dirección hasta que se carga la página, y leer la salida de un comando de red sin buscar qué significa cada columna.

Al final de esta guía tienes el ejercicio concreto con el que comprobarlo.

Fase 2. Conceptos de seguridad

Aquí entra el vocabulario que estructura todo lo demás: confidencialidad, integridad y disponibilidad; criptografía simétrica y asimétrica; funciones hash; certificados; autenticación, autorización y gestión de identidades.

Es la fase más teórica y la que más gente se salta. Saltarla tiene un coste concreto: sin estos conceptos, las herramientas de las fases siguientes se convierten en recetas que ejecutas sin entender.

Sabrás que terminaste cuando puedas explicar por qué un certificado caducado rompe la confianza de una conexión, sin recurrir a analogías.

Fase 3. Defensa operativa

Cómo se detecta y se contiene lo que ocurre en una red real: amenazas comunes, seguridad del endpoint, recolección y lectura de registros, correlación de eventos, y el ciclo de respuesta ante un incidente.

Esta es la fase que más se parece al trabajo diario de la mayoría de los puestos de entrada. También es la que más se ignora en las rutas orientadas al hacking.

Tres ideas sostienen todo lo demás. La correlación de eventos une señales que por separado no significan nada.

La línea base define qué es normal en ese entorno, porque sin normalidad no hay excepción. Y el triaje decide qué se mira primero cuando llegan más alertas de las que caben en un turno.

Ninguna de las tres es una herramienta. Son criterio, y por eso no caducan.

Hay algo que las tres comparten: casi nada de lo que ves es concluyente por sí solo.

Sabrás que terminaste esta fase cuando, ante un conjunto de registros como los que deja un sistema Linux, puedas reconstruir qué pasó y en qué orden.

Fase 4. Práctica en laboratorios

La teoría sin práctica no se sostiene. Necesitas un entorno propio donde romper cosas sin consecuencias.

Plataformas como TryHackMe, la Web Security Academy de PortSwigger, OverTheWire o picoCTF cubren este terreno con niveles progresivos. No las acumules: elige una y termina una ruta completa antes de abrir otra. La dispersión entre plataformas es una forma cómoda de sentir que avanzas sin avanzar.

Sabrás que terminaste cuando puedas resolver ejercicios de dificultad media sin leer la solución, y documentar por escrito lo que hiciste.

Fase 5. Elección de rama y especialización

Ahora sí toca elegir, y ya con criterio propio.

Las ramas principales son la defensiva y de operaciones, la ofensiva, la forense y de respuesta a incidentes, la seguridad de aplicaciones, la de infraestructura y nube, y la de gobierno, riesgo y cumplimiento.

Si la que te tira es la ofensiva, aquí empieza el camino del hacking ético. Los 12 perfiles del ECSF y las cinco categorías del NICE Framework te sirven para ver qué hay detrás de cada una antes de comprometerte.

Los datos de demanda ayudan a decidir. En el estudio de ISC2 de 2025, las necesidades de competencias más citadas fueron inteligencia artificial, con un 41 %, y seguridad en la nube, con un 36 %.

Sabrás que terminaste esta fase cuando puedas nombrar el puesto concreto al que aspiras y las competencias que te faltan para él.

Fase 6. Validación: certificación y portafolio

Validar es demostrar a un tercero lo que sabes. Hay dos vías y son complementarias.

La certificación es la vía formal, y varios emisores publican su propio roadmap de certificaciones en ciberseguridad.

CompTIA declara una progresión que va de A+ y Network+ a Security+, y de ahí a CySA+ y SecurityX. Cisco sitúa CCST Cybersecurity como punto de partida y encadena CCNA Cybersecurity y CCNP Cybersecurity. SANS mantiene un itinerario que alinea sus cursos con NICE, ECSF y DoD 8140.

Cada emisor ordena su propio catálogo, así que ese orden te dice cómo está construida su oferta, no cuál te conviene a ti. Esa comparación merece su propio análisis y no se resuelve dentro de una ruta.

El portafolio es la vía práctica, y en perfiles sin experiencia pesa más de lo que parece. Escribir lo que resuelves, documentar un laboratorio propio o mantener un repositorio ordenado demuestra criterio, que es justo lo que un examen tipo test no mide.

El equilibrio entre ambas vías tiene respaldo. Entre los profesionales europeos consultados por ISACA, el 84 % considera importantes las credenciales profesionales y el 73 % la formación práctica.

¿Empezar por “introducción a la ciberseguridad” o por redes?

Aquí es donde las rutas publicadas se separan de verdad. Unas abren con un curso introductorio de ciberseguridad; otras exigen redes y sistemas antes de tocar nada de seguridad.

Empieza por redes y sistemas. La seguridad consiste en proteger algo, y no se puede razonar sobre cómo se rompe un sistema que todavía no entiendes. Un curso introductorio que llega antes de esa base deja vocabulario suelto sin nada donde fijarlo.

El propio sector lo ordena así. La progresión declarada por CompTIA coloca los fundamentos de TI y redes antes de la certificación de seguridad, y Cisco presenta su nivel de entrada como punto de partida para quien llega nuevo al área.

Los datos de ISC2 apuntan en la misma dirección: la mayoría llegó a la seguridad con experiencia previa en TI, no al revés.

Un curso introductorio corto sí tiene un uso legítimo: sirve para confirmar que el área te interesa antes de invertir meses. Úsalo como orientación: el cimiento va antes.

Preguntas frecuentes sobre empezar en ciberseguridad

¿Hace falta saber programar para ciberseguridad?

No para entrar, y no de forma general. Depende de la rama y del momento.
Conviene separar tres cosas que suelen confundirse: programar, que es construir algo nuevo; escribir scripts, que es automatizar lo que ya haces a mano; y leer código ajeno, que es entender lo que hace algo que no escribiste tú.
Para operaciones de seguridad y respuesta a incidentes basta con las dos últimas. En los marcos de competencias, el conocimiento de programación aparece de forma central en los perfiles de desarrollo seguro, no como exigencia transversal de los perfiles de defensa y operación.
La programación profunda llega después, y llega solo si tu rama la pide.

¿Hace falta un título universitario para trabajar en ciberseguridad?

No como requisito universal, y no es lo más valorado.
Entre los profesionales europeos consultados por ISACA, el título universitario lo valora el 55 %, frente al 84 % que considera importantes las credenciales profesionales.
No existe una fuente con metodología publicada que demuestre que ese requisito esté desapareciendo. Que hoy pese menos que la experiencia y las credenciales sí está medido; que la tendencia siga en una dirección concreta, no.

¿Qué herramientas aprender primero en ciberseguridad?

Las que corresponden a las tareas de un puesto de entrada, y conviene pensarlas por función más que por nombre.
El orden en que se tocan las herramientas importa, pero ninguna sustituye al concepto que hay debajo.
Primero, las de visibilidad y detección: monitorización, gestión de registros, sistemas de detección de intrusiones. Son las que permiten hacer el trabajo diario del que hablaba la fase 3.
Después, las de evaluación de vulnerabilidades, que sirven para priorizar. Y por último las de respuesta y documentación.
Las herramientas ofensivas, que son las que más se recomiendan en foros, no figuran como prioritarias en los objetivos publicados de las certificaciones de nivel inicial. Aparecen más tarde, cuando ya elegiste rama.

Cuánto se tarda en trabajar en ciberseguridad

Ningún marco oficial lo publica. Ni el NICE Framework, ni el ECSF, ni los itinerarios de los emisores fijan una duración para llegar a un puesto de entrada.

Cuando una ruta sí da una cifra, mira de dónde sale. Suele ser la duración de un temario concreto, que mide cuánto dura ese curso, no cuánto tarda una persona en ser contratable.

Por eso esta guía usa hitos verificables en lugar de horas. Un hito no depende de tu ritmo ni de tu punto de partida: o puedes hacer la cosa, o todavía no.

Lo que sí puedes planificar es la parte final. Si el 45 % de las organizaciones europeas tarda entre tres y seis meses en cubrir un puesto inicial, la búsqueda de empleo es un bloque de meses que se suma al tiempo de estudio. Contarlo desde el principio evita la sensación de fracaso cuando el proceso se alarga.

Lo que cambió hace poco

Varias recomendaciones que siguen circulando dejaron de ser ciertas. Estas son las que más afectan a quien empieza.

El acceso gratuito a la certificación CC de ISC2 se terminó. El programa One Million Certified in Cybersecurity dejó de aceptar nuevos participantes el 20 de mayo de 2026. Quienes ya tenían un código sin caducar pueden presentarse hasta el 31 de diciembre de 2026.

El examen cuesta hoy 199 USD, con precios equivalentes en otras regiones, y no se anunció ninguna vía gratuita que lo sustituya. Buena parte de las rutas en español lo sigue listando como gratuito.

El temario de ese mismo examen cambió el 1 de septiembre de 2026. Los cinco dominios se reorganizaron, con más peso de gobierno, identidad y nube. El material de estudio publicado antes de esa fecha ya no corresponde del todo al examen actual.

El ciclo de respuesta a incidentes del NIST ya no son cuatro fases. Durante años, la referencia fue la publicación SP 800-61 en su revisión 2, con su secuencia de preparación, detección y análisis, contención, erradicación y recuperación, y actividad posterior al incidente. Esa secuencia sigue apareciendo en casi todo el material de estudio en español.

La revisión 3, publicada el 3 de abril de 2025, la sustituye. Ahora la respuesta a incidentes se organiza con las seis funciones del Cybersecurity Framework 2.0 —Govern, Identify, Protect, Detect, Respond y Recover— en lugar de un ciclo secuencial.

El propio documento explica el motivo del cambio: cuando se escribió el modelo anterior, «los incidentes eran relativamente raros, el alcance de la mayoría era estrecho y estaba bien definido, y la respuesta y la recuperación solían completarse en uno o dos días».

En el original: “incidents were relatively rare, the scope of most incidents was narrow and well-defined, and incident response and recovery was usually completed within a day or two”. Ya no.

Si estudias esto por un manual que enumera cuatro fases, estás estudiando el modelo anterior.

La cifra de 4,8 millones de puestos sin cubrir está retirada. Procede de la edición de 2024 del estudio de ISC2. En la de diciembre de 2025 la organización dejó de publicarla, y lo explica sin rodeos: «este año ISC2 no ha incluido una estimación de la brecha de fuerza laboral en ciberseguridad».

El motivo es que los encuestados sitúan la carencia de competencias por delante de la falta de personas. Cualquier guía que siga presentando esa cifra como actual está citando datos de hace dos años.

Lo que sí publica el estudio de 2025 es más útil que la cifra retirada. El 95 % de los equipos declara al menos una carencia de competencias, y el 59 % la califica de crítica o significativa, frente al 44 % del año anterior.

Fortinet reestructuró su programa de certificación el 15 de julio de 2026. Pasó de cinco a ocho niveles, con certificaciones NSE 1 a NSE 8. Las certificaciones caducan a los dos años desde su emisión.

En TryHackMe, varias rutas avanzadas cambiaron de plan. Red Teaming, SOC Level 2, Web Application Red Teaming y Advanced Endpoint Investigations pasaron al plan MAX.

Esas rutas estaban antes en Premium, que también es de pago. El movimiento fue de un plan de pago a otro superior, no de gratuito a pago.

Errores que cuestan meses al empezar en ciberseguridad

Creer que esto va de terminales. Es lo que atrae, y es la parte visible. Pero el peso del trabajo está en el razonamiento crítico y en el criterio ético, y del otro lado hay gente haciendo daño de verdad.

Quien viene solo por la estética de la consola se cansa cuando descubre cuánto hay que pensar y cuánto hay que decidir.

Coleccionar certificaciones antes de tener base. El examen se aprueba memorizando; el trabajo no. Sin las fases 1 a 3, una certificación abre una entrevista que después no se sostiene.

Saltarse redes. Es la carencia más común y la más cara de arreglar después, porque todo lo demás se apoya ahí.

Aprender herramientas en lugar de conceptos. Las herramientas cambian de nombre cada pocos años. Los conceptos que hay debajo, no.

Elegir rama en la primera semana. Decidir sin base es decidir por estética, y suele terminar en un cambio de rumbo a mitad de camino.

Seguir listas de recursos gratuitos desactualizadas. Como muestra el apartado anterior, parte de lo que se recomienda como gratuito ya no lo es.

Cambiar de plataforma cada dos semanas. Empezar rutas y no terminar ninguna produce la sensación de avanzar sin avance real.

Lo que no sabemos

Estas son las preguntas que esta guía no responde, porque no hay datos verificables.

Cuánto se cobra en un primer puesto en el mundo hispanohablante. No existe una fuente con metodología publicada que cubra la región. Las cifras que circulan proceden casi siempre de academias que venden formación, sin muestra ni método declarados. Antes que dar un número inventado, es preferible decir que no lo hay.

Qué porcentaje de gente aprueba cada certificación. Los emisores no publican tasas de aprobados. Cualquier cifra concreta que encuentres es una estimación sin respaldo.

Cuánto tarda una persona concreta. Depende del punto de partida, de las horas semanales y de si ya trabajas en TI.

Qué pide exactamente el mercado local. Los datos de demanda por rol más citados proceden de fuentes centradas en Estados Unidos, con ventanas de recogida que pueden tener más de un año. Sirven para ver tendencias, no para planificar una búsqueda concreta en tu ciudad.

Cuida tu huella desde el primer día

Este es el consejo que no vas a encontrar en una ruta escrita por una academia, y es el que más te va a durar.

Antes de instalar tu primera herramienta, ocúpate de tu propia exposición. Qué cuentas tienes abiertas, con qué correo, con qué contraseñas repetidas, qué se encuentra buscando tu nombre, qué dejaste publicado hace años.

Hay dos razones y las dos son prácticas. La primera es que vas a trabajar rodeado de gente que sabe buscar, y tu propia superficie expuesta es lo primero que se mira. La segunda es que aquí se aprende probando, y probar deja rastro.

Si quieres el procedimiento completo, lo tenemos reunido en nuestro manual para no dejar huella.

Lo que hace distinto a este consejo es que sobrevive a la decisión de seguir o no. Si dentro de un año esto no era lo tuyo, todo lo demás de esta guía se te olvida. La higiene digital que montes ahora te sigue sirviendo igual.

Empieza por lo simple: correos separados para lo personal y lo técnico, gestor de contraseñas, doble factor donde se pueda, y una revisión de qué hay publicado sobre ti.

Por dónde empezar esta semana: el laboratorio mínimo

Elige una sola cosa y termínala.

Levanta dos máquinas virtuales en tu equipo y consigue que se comuniquen entre ellas. Es gratis, cabe en una tarde y toca de golpe tres cosas de la fase 1: virtualización, direccionamiento y diagnóstico de red.

Lo interesante no es que funcione. Es lo que aprendes cuando no funciona.

Este es el ejercicio tal como salió en nuestro laboratorio, con tres máquinas sobre el mismo hipervisor: una Kali, una Ubuntu y una Windows 11, las tres en red compartida.

Necesitas un hipervisor —el que ya uses sirve— y las imágenes de instalación de las tres distribuciones, con memoria suficiente para tenerlas encendidas a la vez.

Los nombres de interfaz y el comportamiento de la red por defecto cambian según el hipervisor, así que no esperes ver exactamente estas salidas. Lo que tiene que cumplirse es que las tres máquinas queden en la misma red; lo que vas a practicar es distinguir un problema de comunicación de un comportamiento previsto del sistema.

Lo primero es mirar las direcciones. Cada sistema nombra sus interfaces a su manera, y eso ya descoloca a quien copia comandos de un tutorial: en Kali la interfaz es eth0, en Ubuntu es enp0s5.

Salida del comando ip a en Kali Linux con la interfaz eth0 y su dirección
En Kali la interfaz se llama eth0; en Ubuntu, enp0s5. Mismo hipervisor, nombres distintos.

Entre las dos máquinas Linux la comunicación sale a la primera:

$ ping -c 4 10.211.55.5
64 bytes from 10.211.55.5: icmp_seq=1 ttl=64 time=0.790 ms
64 bytes from 10.211.55.5: icmp_seq=2 ttl=64 time=0.346 ms
--- 10.211.55.5 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms

Contra la máquina Windows, con la misma configuración de red, no:

$ ping -c 4 10.211.55.4
PING 10.211.55.4 (10.211.55.4) 56(84) bytes of data.
--- 10.211.55.4 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3063ms

Fíjate en lo que no aparece: ningún mensaje de error. Ni Destination Host Unreachable, ni Network is unreachable. Silencio.

Si el problema fuera de rutas, algún equipo del camino habría contestado con un error. Que no conteste nadie apunta a otra cosa: los paquetes llegaron y no obtuvieron respuesta.

De momento eso es una hipótesis, no un diagnóstico.

La comprobación es inmediata. La tabla de vecinos de la máquina Kali, consultada justo después del intento fallido, tiene a la Windows con su dirección física:

$ ip neigh
10.211.55.4 dev eth0 lladdr 00:1c:42:42:e4:1d STALE
10.211.55.5 dev eth0 lladdr 00:1c:42:16:20:e7 STALE

Es decir: la máquina Windows sí respondió a la resolución de direcciones. Está viva y hablando. Y el ping en sentido contrario, desde Windows hacia Kali, funciona sin problema.

Salida de ip neigh con la dirección física del equipo que no respondía al ping
El equipo aparece con su dirección física: sí respondió a la resolución de direcciones.

El diagnóstico, entonces, no era de red. Windows no responde a las peticiones de eco entrantes con su configuración por defecto.

Se permiten desde PowerShell abierto como administrador, en la propia máquina Windows:

New-NetFirewallRule -DisplayName "ICMPv4 entrante lab" -Protocol ICMPv4 -IcmpType 8 -Direction Inbound -Action Allow

Se crea la regla por parámetros y no por su nombre predefinido porque en un Windows en español esos nombres están traducidos. Con la regla activa, el mismo comando de antes responde:

Regla de cortafuegos de Windows creada para permitir peticiones de eco entrantes
Enabled True y Profile Any: la regla se aplica en todos los perfiles de red.
$ ping -c 4 10.211.55.4
64 bytes from 10.211.55.4: icmp_seq=1 ttl=128 time=2.36 ms
64 bytes from 10.211.55.4: icmp_seq=2 ttl=128 time=0.646 ms

Compara este bloque con el primero. Las máquinas Linux respondían con ttl=64 y la Windows responde con ttl=128. El valor inicial de ese campo no es el mismo en los tres sistemas, y la diferencia viaja en cada respuesta.

Ping desde Kali a Windows respondiendo con ttl 128 tras habilitar la regla
Cuatro respuestas y cero pérdida, sin haber tocado la configuración de red.

“No hay conectividad” y “ese equipo no responde a este protocolo” son cosas distintas. Confundirlas cuesta horas.

El registro, y por qué ningún dato concluye por sí solo

Con las máquinas comunicándose, el segundo ejercicio: levanta el servidor SSH en una de ellas e intenta entrar desde la otra. Primero con un usuario que no exista, después con el tuyo.

En la máquina que hace de servidor:

sudo apt install -y openssh-server
sudo systemctl enable --now ssh

Tras los dos intentos, el registro de autenticación —/var/log/auth.log, o el diario del servicio si tu distribución ya no lo escribe— guarda esto:

sshd[12522]: Failed password for invalid user noexiste from 10.211.55.6 port 55158 ssh2
sshd[12522]: Failed password for invalid user noexiste from 10.211.55.6 port 55158 ssh2
sshd[12522]: Failed password for invalid user noexiste from 10.211.55.6 port 55158 ssh2
sshd[12922]: Failed password for parallels from 10.211.55.6 port 50716 ssh2
sshd[12922]: Accepted password for parallels from 10.211.55.6 port 50716 ssh2

Las tres primeras líneas son el usuario inventado. El servidor distingue una cuenta que no existe —invalid user— de una que sí existe y falla.

Registro de sshd con tres intentos fallidos, un fallo y un acceso correcto
Fíjate en el identificador de proceso y en el puerto de origen de las dos últimas líneas.

Las dos últimas son las interesantes: un intento fallido y, tres segundos después, un acceso correcto, con la misma cuenta y la misma dirección de origen.

Leído en frío, eso levanta una alerta.

No lo era en este caso. Era el operador escribiendo mal su propia contraseña.

La distinción está en la propia línea, en el campo que casi nadie lee. Las dos últimas comparten el identificador de proceso, 12922, y el puerto de origen, 50716. El servidor bifurca un proceso nuevo por cada conexión entrante, así que ese par apunta a una única sesión.

Los tres intentos del usuario inventado tienen otro identificador y otro puerto: 12522 y 55158. Otra conexión distinta.

Eso no demuestra por sí solo que no hubiera ataque: un intento automatizado y lento también cabe en una sola conexión. Lo que hace es cambiar la pregunta. Antes de clasificar el evento hay que ver si los intentos se reparten entre conexiones distintas, con qué ritmo llegan y desde dónde.

El identificador y el puerto no cierran el caso. Dicen dónde seguir mirando.

Ese es el trabajo de la fase 3, y no se parece nada a lo que se imagina quien busca “aprender hacking”: mirar lo mismo que todos, fijarse en el campo que nadie mira y decidir si hay incidente o no lo hay.

Cuando termines, escribe en un archivo qué hiciste, qué falló y cómo lo resolviste. Ese archivo es el primer elemento de tu portafolio, y vale más que cualquier certificado de asistencia.

Después, y solo después, abre el mapa de roles del NICE Framework o del ECSF y mira hacia dónde quieres ir. Con una máquina virtual funcionando delante, ese mapa se lee de otra manera.

Fuentes

Mi Carro Close (×)

Tu carrito está vacío
Ver tienda