Lo que pasó después cambió la clase
Por Jaider Enrique Reyes Herazo — Docente de Ingeniería en Sistemas
Hay clases que uno planea con cuidado durante días. Hay otras que simplemente ocurren solas. Y esas, casi siempre, son las más memorables.
Esta es la historia de una de esas clases.
El contexto: laboratorio de Sistemas Operativos
Estábamos en la unidad de operación y protección de servidores. El laboratorio de ese día tenía un objetivo claro: el estudiante configurara correctamente el firewall de su máquina usando ufw o nftables, levantara un servicio web básico con Apache, y demostrara que sabía qué puertos estaban abiertos y cuáles cerrados usando herramientas como ss, curl y nc.
Nada fuera de lo ordinario. Una práctica técnica de la clase , estructurada, evaluable.
Hasta que …
El reto
«Profe, ya terminé. Tengo el firewall configurado, el servidor corriendo y bloqueé todas las entradas. Nadie puede acceder a mi máquina.«
Lo dijo con esa seguridad particular que tienen los estudiantes cuando creen que han cerrado todas las puertas. Con orgullo legítimo, además había hecho bien su trabajo.
Y entonces, casi como provocación amistosa, agregó:
«Les reto a que intenten entrar. Tengo una página web de memes de la carrera corriendo en el puerto 80. A ver quién llega.«
El salón despertó. Ese tipo de reto no se rechaza.
Yo miré mi celular. Tenía Termux corriendo. Tenía acceso a mi Kali Linux desde ahí mismo. Y tenía una oportunidad pedagógica que ninguna diapositiva hubiera podido crear.
«Bueno«, dije. «Veamos.«
Primer movimiento: lo más directo primero
Lo primero que hice fue intentar conectarme por SSH directamente como root. Sin rodeos:
bash
ssh -p 22 root@10.10.10.156
Permission denied, please try again.Permission denied, please try again.Permission denied
Tres intentos. Tres rechazos. El estudiante sonrió desde su puesto.
Pero eso no era un fracaso era información. El servidor existía, respondía, y tenía SSH activo pero protegido. Primer dato confirmado.
Le expliqué al grupo lo que acababa de pasar: «El firewall no me dijo ‘no existo’. Me dijo ‘no puedes entrar por aquí’. Eso es diferente. Significa que hay algo adentro.»
Segundo movimiento: el firewall bloquea Nmap
El siguiente paso era un escaneo con Nmap para ver qué puertos estaban realmente expuestos:
bash
nmap -sV -sC 10.10.10.156
Y aquí llegó la primera lección no planeada del día:
route_dst_netlink: cannot bind AF_NETLINK socket: Permission denied
Nmap fallaba. El entorno desde el que operaba no tenía los privilegios de red necesarios para hacer escaneos de bajo nivel — exactamente el tipo de restricción que un firewall bien configurado puede imponer sobre el tráfico de red raw.
El estudiante celebró desde su silla.
Pero yo sabía que el juego no había terminado.
«Esto es lo que pasa en el mundo real», le dije al grupo. «Los firewalls no siempre te bloquean completamente. A veces solo te complican el camino. Un ingeniero se adapta.»
Tercer movimiento: pensar diferente
Nmap tiene múltiples modos de operación. El escaneo SYN estándar (-sS) requiere privilegios de red de bajo nivel — raw sockets. El TCP Connect Scan (-sT) no los necesita. Usa las llamadas normales del sistema operativo y funciona incluso bajo restricciones:
bash
nmap -sT -sV 10.10.10.156
Esta vez, el resultado apareció:
22/tcp open ssh OpenSSH (Ubuntu)80/tcp open http Apache/2.4.58 (Ubuntu)
Dos puertos. Dos puertas visibles.
El puerto 22 ya lo conocíamos — SSH, con acceso root bloqueado. El puerto 80 era el interesante. HTTP. El servidor web del reto.
Proyecté la pantalla del celular para que todos vieran en tiempo real.
El descubrimiento: la página de memes
Usé curl para inspeccionar el servidor. Sin navegador, sin interfaz gráfica — solo el protocolo HTTP en su forma más pura, desde la terminal:
bash
curl -I http://10.10.10.156
http
HTTP/1.1 200 OKServer: Apache/2.4.58 (Ubuntu)Last-Modified: Mon, 27 Apr 2026 19:38:17 GMTContent-Length: 1897Content-Type: text/html
El servidor respondía perfectamente. Luego fui por el contenido completo:
bash
curl -s http://10.10.10.156
Y apareció en pantalla:
html
<title>Memes Ingeniería en Sistemas</title>
El salón estalló en carcajadas.
Ahí estaba — la página de memes, completamente accesible desde el puerto 80. El estudiante había bloqueado SSH, había configurado reglas de firewall, había hecho bien gran parte del laboratorio. Pero había dejado el puerto 80 abierto al mundo porque ese era, precisamente, el propósito del reto.
Y ese puerto abierto era todo lo que necesitábamos.
La enumeración: buscar lo que no está a la vista
Con acceso confirmado al servidor web, continué la demostración con Gobuster — una herramienta que realiza fuerza bruta de rutas web, preguntando al servidor por miles de direcciones posibles hasta encontrar las que realmente existen:
bash
gobuster dir \ -u http://10.10.10.156 \ -w /usr/share/wordlists/dirb/common.txt \ -x php,html,txt,zip,bak \ -t 50
Y en paralelo, Nikto, que analiza el servidor buscando configuraciones inseguras, archivos expuestos y cabeceras de seguridad faltantes:
bash
nikto -h http://10.10.10.156
Mientras las herramientas corrían, aproveché para lanzar una pregunta al grupo:
«¿Qué creen que le ha pasado a ese servidor?»
Las respuestas fueron reveladoras. Algunos dijeron «nada, si el estudiante solo subió la página de memes». Otros, los más curiosos, empezaron a especular: «¿Y si tiene un /admin sin contraseña? ¿Y si dejó un archivo de configuración expuesto?»
Esa conversación espontánea valía más que cualquier diapositiva sobre seguridad web que yo hubiera podido preparar.
La lección que no estaba en el plan de clase
Cuando los primeros resultados comenzaron a aparecer, hice una pausa.
No para mostrar qué habíamos encontrado sino para hablar de lo que significaba todo el proceso.
Le pregunté directamente al estudiante que había lanzado el reto: «¿Qué aprendiste hoy sobre tu propio servidor?»
Se quedó pensando un momento. Luego respondió:
«Que configurar el firewall no es suficiente si no sé qué está corriendo adentro.»
Exactamente.
Un firewall es una herramienta. Puede bloquear puertos, filtrar IPs, rechazar conexiones. Pero si el servicio que corre detrás de ese firewall tiene vulnerabilidades — archivos expuestos, contraseñas débiles, configuraciones por defecto sin cambiar — el atacante no necesita «romper» el firewall. Solo necesita encontrar la puerta que quedó entreabierta.
En este caso: el puerto 80, abierto por diseño, pero sin considerar todo lo que podía hacerse desde él.
Lo que esta clase me recordó sobre enseñar
Soy docente de Ingeniería en Sistemas. Trabajo con ufw, nftables, ss, curl, nc las mismas herramientas de la rúbrica de ese laboratorio. Las enseño porque las uso. Porque sé que un egresado que no entiende cómo funciona un firewall desde adentro y desde afuera, está a medias en su formación profesional.
Pero lo que más valoro de ese día no fue el comando que funcionó, ni haber accedido al servidor desde el celular con Termux.
Fue la pregunta que un estudiante se hizo a sí mismo cuando vio su propio servidor desde el otro lado.
Esa pregunta «¿qué dejé mal configurado?» es exactamente la misma que se hace un profesional de seguridad cada vez que audita un sistema. Aprenderla en el aula, con un servidor de memes de la carrera como campo de práctica, es el tipo de aprendizaje que no se olvida.
Reflexión final: la ética no es opcional
Todo lo que hicimos ese día ocurrió en un entorno controlado, con autorización explícita. El estudiante mismo lanzó el reto públicamente frente al grupo, ante mí como docente. Eso no es un detalle menor — es el detalle que lo hace todo válido.
En Colombia, la Ley 1273 de 2009 tipifica como delito el acceso abusivo a sistemas informáticos, la interceptación de datos y el daño a la integridad de sistemas. Las mismas herramientas que usamos ese día — Nmap, Gobuster, Nikto — son ilegales cuando se usan sin autorización.
La diferencia entre un hacker ético y un atacante no está en las herramientas. Está en el consentimiento, la transparencia y el propósito.
Enseñar seguridad informática sin enseñar ética no es enseñar seguridad. Es enseñar a romper cosas.
Ese día, creo, enseñamos las dos.
Guía técnica completa del laboratorio
Si eres docente o estudiante y quieres replicar este ejercicio en tu propio entorno, preparé una guía técnica detallada con todos los comandos, explicaciones paso a paso y el flujo metodológico completo:
📄 Descargar Guía — Lab Ethical Hacking en Red Local
La guía incluye:
- Reconocimiento con Nmap con y sin restricciones de firewall
- Inspección de servidores web con curl
- Enumeración de directorios con Gobuster
- Análisis de vulnerabilidades con Nikto
- Técnicas de acceso SSH y hardening del servidor objetivo
- Template de reporte de hallazgos para usar en clase
Jaider Enrique Reyes Herazo Docente — Ingeniería en Sistemas | Sincelejo, Colombia
#SeguridadInformática #EthicalHacking #IngenieríaEnSistemas #SistemasOperativos #Docencia #KaliLinux #Termux #Laboratorio
