Son las dos de la madrugada de un martes y en la oficina de la auditoría solo está encendido tu flexo. El encargo de hoy es la Clínica Sonrisa, la de la noche de las copias: quieren saber qué servicios se les ven desde Internet antes de la revisión del seguro. La ventana va de las 02:00 a las 06:00, porque a las ocho abren la consulta y la agenda de citas no se puede tocar.
El tema 1 ya enseñó lo importante de antes: el contrato, lo que se hace con un equipo que no estaba en el alcance y los tres estados de un puerto. Nada de eso se repite aquí: se da por sabido.
Lo de hoy es otra cosa, y es la lección que hace que este tema vaya el segundo: un barrido rápido no ve toda la superficie. Vas a ver, en la misma máquina y con la misma herramienta, cómo cambia la lista de servicios según lo que le pidas; vas a mirar un protocolo que el barrido normal ni toca; vas a leer lo que cada servicio cuenta de sí mismo sin que nadie le pregunte; y vas a cotejar una versión con una ficha de fallos conocidos sin tocar el servicio, que es exactamente donde acaba una auditoría de enumeración y empieza otro encargo.
Los mil de siempre no son los mil primeros
Cuando nmap se lanza sin decirle qué puertos mirar, no mira los 65.535 que hay: mira mil. Esto
es lo que da, contra una máquina de pruebas con varios servicios puestos:
auditor@pc-auditoria:~$ nmap 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-16 03:29 UTC Nmap scan report for srv-servicios.auditoria (203.0.113.10) Host is up (0.0000090s latency). Not shown: 993 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 199/tcp open smux 443/tcp open https 3306/tcp open mysql 8080/tcp open http-proxy 49152/tcp open unknown MAC Address: 8A:DD:A7:BF:D5:3A (Unknown) Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
Haz la cuenta de la línea del resumen: 993 cerrados más los 7 de la tabla son mil. Esos mil
son los que nmap lleva elegidos en su propia lista, y la trampa está en el nombre con el que casi
todo el mundo los menciona: no son «los mil primeros». Son los mil más comunes, repartidos por
todo el rango. Mira el 49152 de la última fila: está ahí sin que nadie lo pidiera, y es un puerto
muy alto.
Ahora la misma máquina, con -p-, que es «todos»:
auditor@pc-auditoria:~$ nmap -p- -T4 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-16 03:30 UTC Nmap scan report for srv-servicios.auditoria (203.0.113.10) Host is up (0.0000090s latency). Not shown: 65525 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 199/tcp open smux 443/tcp open https 3306/tcp open mysql 8080/tcp open http-proxy 47623/tcp open unknown 49152/tcp open unknown 51337/tcp open unknown 60911/tcp open unknown MAC Address: 8A:DD:A7:BF:D5:3A (Unknown) Nmap done: 1 IP address (1 host up) scanned in 1.06 seconds
Diez en vez de siete. La cuenta vuelve a cerrar: 65.525 cerrados más 10 son 65.535. Y los tres que aparecen de nuevas —el 47623, el 51337 y el 60911— no estaban en la lista de los mil, así que el primer barrido no los vio. No es que estuvieran filtrados, ni escondidos, ni protegidos: nadie preguntó por ellos.
Que eso no es una rareza de la máquina se ve desde el otro lado. Esto es lo que el servidor tenía escuchando de verdad mientras se le barría:
root@srv-servicios:~# ss -ltunp Netid State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess udp UNCONN 0 0 0.0.0.0:161 0.0.0.0:* users:(("snmpd",pid=4729,fd=6)) udp UNCONN 0 0 127.0.0.11:33213 0.0.0.0:* tcp LISTEN 0 511 0.0.0.0:8080 0.0.0.0:* users:(("nginx",pid=4718,fd=9)) tcp LISTEN 0 5 0.0.0.0:60911 0.0.0.0:* users:(("python3",pid=4736,fd=3)) tcp LISTEN 0 4096 127.0.0.11:43791 0.0.0.0:* tcp LISTEN 0 80 0.0.0.0:3306 0.0.0.0:* tcp LISTEN 0 5 0.0.0.0:47623 0.0.0.0:* users:(("python3",pid=4740,fd=3)) tcp LISTEN 0 5 0.0.0.0:51337 0.0.0.0:* users:(("python3",pid=4733,fd=3)) tcp LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=4718,fd=7)) tcp LISTEN 0 5 0.0.0.0:49152 0.0.0.0:* users:(("python3",pid=4731,fd=3)) tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=4716,fd=3)) tcp LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=4718,fd=6)) tcp LISTEN 0 4096 0.0.0.0:199 0.0.0.0:* users:(("snmpd",pid=4729,fd=8)) tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=4716,fd=4)) tcp LISTEN 0 511 [::]:80 [::]:* users:(("nginx",pid=4718,fd=8))
Diez puertos TCP escuchando en 0.0.0.0 (los dos de 127.0.0.11 son del DNS interno del
contenedor y no salen a ningún sitio), y uno UDP. El -p- encontró los diez; el barrido normal,
siete. De paso, ahí está de dónde salía el 199: el smux de la tabla de nombres es el compañero
TCP del snmpd, que también escucha en el 161 por UDP. Y los cuatro puertos altos son cuatro
python3 distintos, de esos que alguien levantó «un momento» y se quedaron.
Ejercicio
La misma máquina, dos listas de puertos
El servidor de la clínica es 198.51.100.34. Bárrelo como lo haría cualquiera, sin decirle qué puertos quieres, y después pídele TODOS. Fíjate en lo que cambia: la máquina es la misma.
Preparando la máquina…
UDP es otro mundo
Todo lo de arriba era TCP. Y TCP es cómodo de barrer porque contesta: si hay alguien escuchando
manda un syn-ack, y si no hay nadie manda un reset. En UDP no hay conexión que abrir ni saludo:
se manda un paquete y, con suerte, el servicio contesta algo.
El «no» también existe, pero no lo dice el servicio: lo dice el sistema, con un aviso de ICMP («ahí no hay puerto»). Y ese aviso es justo lo que se pierde con facilidad: los sistemas limitan cuántos mandan por segundo y cualquier cortafuegos por el camino lo descarta. Cuando no llega ni ese aviso, puede ser que no haya nadie, que haya alguien callado o que un cortafuegos se lo haya comido, y desde fuera las tres cosas son el mismo silencio.
Por eso un barrido de UDP se pide aparte, con -sU:
auditor@pc-auditoria:~$ sudo nmap -sU -T4 -p 53,123,161 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-16 03:30 UTC Nmap scan report for srv-servicios.auditoria (203.0.113.10) Host is up (0.000054s latency). PORT STATE SERVICE 53/udp closed domain 123/udp closed ntp 161/udp open snmp MAC Address: 8A:DD:A7:BF:D5:3A (Unknown) Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds
Aquí hay un abierto y dos cerrados, y los dos cerrados lo son porque el sistema contestó: cuando
llega un paquete a un puerto UDP donde no escucha nadie, el propio sistema operativo devuelve un
aviso de ICMP diciendo que ahí no hay puerto. Ese aviso es lo que nmap lee como closed.
Lo interesante es cuando no llega ni eso. Entonces nmap no puede decidir, y lo dice tal cual:
escribe el estado open|filtered, que no es un estado a medias por pereza, es la verdad —puede
estar abierto y callado, o puede haber un cortafuegos delante—. Para quien audita, un
open|filtered no se apunta como hallazgo: se apunta como «hay que mirarlo de otra manera».
Así se ven los dos juntos, con una regla que descarta los paquetes del 53 y el 137 sin nada
escuchando. Y con --reason, que es lo que de verdad explica la diferencia:
auditor@pc-auditoria:~$ sudo nmap -sU --reason -p 53,137 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-16 12:09 UTC Nmap scan report for srv-objetivo.auditoria (203.0.113.10) Host is up, received arp-response (0.000029s latency). PORT STATE SERVICE REASON 53/udp open|filtered domain no-response 137/udp closed netbios-ns port-unreach ttl 64 MAC Address: 6E:BA:B5:3A:A7:60 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 1.25 seconds
Lee la columna REASON, que es toda la lección en dos palabras. El 137 es closed porque llegó un
port-unreach: el sistema contestó que ahí no hay nadie. El 53 es open|filtered porque llegó
no-response: nadie dijo nada. Son dos situaciones distintas con la misma apariencia desde fuera —un
puerto callado—, y nmap no las mezcla.
También es lento, y mucho. TCP se puede barrer en paralelo a toda velocidad porque cada puerto
contesta algo; en UDP, cada puerto que calla hay que esperarlo hasta rendirse, y encima los sistemas
limitan cuántos avisos de ICMP mandan por segundo, así que al apretar se pierden respuestas y
nmap tiene que reintentar. Barrer los mil puertos de siempre en UDP no se parece en nada a
barrerlos en TCP: es de los trabajos que se dejan corriendo y se miran un rato después. Esto no es
un detalle de rendimiento; en una auditoría con ventana horaria es la razón por la que el UDP se
pide con -p y con los puertos elegidos a mano.
¿Y qué se busca ahí? Justo lo que no está en TCP. En esta máquina, el 161: SNMP, el protocolo con el que se vigilan equipos de red e impresoras. Si se le pregunta la versión, no solo dice qué es:
auditor@pc-auditoria:~$ sudo nmap -sU -sV -T4 -p 161 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-16 03:30 UTC Nmap scan report for srv-servicios.auditoria (203.0.113.10) Host is up (0.000055s latency). PORT STATE SERVICE VERSION 161/udp open snmp SNMPv1 server; net-snmp SNMPv3 server (public) MAC Address: 8A:DD:A7:BF:D5:3A (Unknown) Service Info: Host: srv-clinica Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 0.35 seconds
Lee la fila del 161 y la línea de debajo despacio, porque ahí hay dos hallazgos por el precio de uno.
En la columna VERSION, (public) entre paréntesis: eso es la comunidad con la que el SNMP
acepta que se le pregunte, y public es la de fábrica. Un SNMP que contesta a public desde
Internet es un equipo que cuenta de sí mismo lo que le pidan —interfaces, direcciones, procesos, a
veces la configuración entera— a cualquiera que pase.
Y en Service Info: Host: está el regalo: srv-clinica, el nombre interno de la máquina. Eso
no lo dijo el DNS ni se lo sacó nmap de la dirección; lo contó el propio servicio, porque un SNMP
guarda el nombre del equipo entre las cosas que publica. En una enumeración eso vale su peso en oro:
te da la forma en la que el cliente nombra sus máquinas, y con ella adivinas cómo se llaman las
demás.
Se pueden pedir los dos protocolos de una vez, poniendo delante de cada lista a quién va:
auditor@pc-auditoria:~$ sudo nmap -sS -sU -T4 -p T:22,80,U:161 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-16 03:30 UTC Nmap scan report for srv-servicios.auditoria (203.0.113.10) Host is up (0.000058s latency). PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 161/udp open snmp MAC Address: 8A:DD:A7:BF:D5:3A (Unknown) Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
T: para los TCP y U: para los UDP, y la columna PORT lleva el protocolo de cada uno. Los dos
números pueden repetirse sin problema: el 161 de TCP y el 161 de UDP son dos puertos distintos, y
uno puede estar abierto con el otro cerrado.
Ejercicio
UDP: lo que el barrido normal ni toca
Un barrido de TCP no mira un solo puerto de UDP. Pregúntale al 198.51.100.34 por el 161 (SNMP) en UDP y después pídele la versión: el servicio cuenta de sí mismo más de lo que debería.
Preparando la máquina…
Los banners y las versiones que cantan
Hasta ahora las tablas decían qué puertos están abiertos. Con -sV, nmap habla con cada uno y
añade la columna VERSION, que es otra cosa: ahí no hay suposición ninguna, está lo que contestó el
servicio.
auditor@pc-auditoria:~$ nmap -sV 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-16 03:29 UTC Nmap scan report for srv-servicios.auditoria (203.0.113.10) Host is up (0.0000090s latency). Not shown: 993 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.18 (Ubuntu Linux; protocol 2.0) 80/tcp open http nginx 1.18.0 (Ubuntu) 199/tcp open smux Linux SNMP multiplexer 443/tcp open ssl/http nginx 1.18.0 (Ubuntu) 3306/tcp open mysql MariaDB (unauthorized) 8080/tcp open http nginx 1.18.0 (Ubuntu) 49152/tcp open http SimpleHTTPServer 0.6 (Python 3.10.12) MAC Address: 8A:DD:A7:BF:D5:3A (Unknown) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.32 seconds
Compara esta tabla con la primera del tema, la del barrido sin -sV. Son los mismos siete puertos,
y sin embargo ahora sabes mucho más: dos de los nombres cambiaron al identificarlos. El 8080
decía http-proxy y dice http; el 49152 decía unknown y dice http, con el programa que lo
sirve. Lo que la tabla de nombres pone en la columna SERVICE es una suposición por el número de
puerto, como ya contaba
el tema 1; lo
que -sV escribe es una respuesta.
Un banner es eso que el servicio suelta por su cuenta. Algunos lo cantan antes de que les
preguntes nada, y sshd es el campeón:
auditor@pc-auditoria:~$ nc -nv -w 5 203.0.113.10 22 </dev/null Connection to 203.0.113.10 22 port [tcp/*] succeeded! SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.18
Una conexión, sin escribir nada, y ya tienes el programa, su versión exacta y el número de paquete
de Ubuntu. Esto es lo mismo que leyó -sV, visto en crudo, y conviene saber hacerlo a mano por dos
razones: para confirmar una versión sin fiarte de la herramienta, y para leer un servicio que
nmap no sepa identificar.
Ahora el caso bonito del tema, el 3306:
auditor@pc-auditoria:~$ nmap -sV -p 3306 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-16 03:30 UTC Nmap scan report for srv-servicios.auditoria (203.0.113.10) Host is up (0.000040s latency). PORT STATE SERVICE VERSION 3306/tcp open mysql MariaDB (unauthorized) MAC Address: 8A:DD:A7:BF:D5:3A (Unknown) Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 0.28 seconds
MariaDB (unauthorized). Las dos palabras cuentan historias distintas y las dos son del
informe. MariaDB es qué hay ahí: una base de datos, alcanzable desde Internet, en el puerto de
siempre. Y (unauthorized) es que la base no dejó entrar: le dijo a quien llamaba que esa
máquina no está en su lista de permitidos. O sea, que el servicio no está mal configurado del todo
—tiene su control de acceso—, pero está escuchando donde no debería, y eso se ha demostrado sin
intentar entrar, sin probar una contraseña y sin tocarle un solo dato.
Ese es el patrón del tema entero: el servicio te dice qué es y qué versión tiene antes de pedirte permiso para nada. No hace falta pasar de ahí para escribir un hallazgo bueno.
Ejercicio
Leer una versión con nmap y confirmarla a mano
Pregúntale la versión al 22 y al 3306 del 198.51.100.34. Uno canta el programa y el parche exacto; el otro dice qué es aunque no te deje entrar. Después confirma el del 22 sin usar nmap.
Preparando la máquina…
La copia de pruebas y sus cabeceras
Un servidor web no habla primero: espera una petición. Su banner son las cabeceras de la respuesta,
y se leen con curl -D - (las cabeceras a la pantalla) y -o /dev/null (el cuerpo a la basura).
Mira el 8080 de esta máquina:
auditor@pc-auditoria:~$ curl -sS -D - -o /dev/null http://203.0.113.10:8080/ HTTP/1.1 200 OK Server: nginx/1.18.0 (Ubuntu) Date: Fri, 16 Oct 2026 03:30:52 GMT Content-Type: text/html Content-Length: 138 Last-Modified: Fri, 16 Oct 2026 03:29:23 GMT Connection: keep-alive ETag: "6ad19a13-8a" Accept-Ranges: bytes
La cabecera Server: dice el programa, la versión y hasta la distribución: nginx/1.18.0 (Ubuntu).
Es lo mismo que contestó a -sV, en crudo. Y hay un detalle que se pasa por alto: el
Content-Length es 138, mientras que la web del 80 de esta misma máquina devolvía 612. No son
la misma página. Son dos sitios distintos servidos por el mismo nginx, y eso ya es una pregunta
que hacerle al cliente.
La respuesta está en el título, y pedir la página de portada entera es lo más suave que se puede hacer: es exactamente lo que hace un navegador.
auditor@pc-auditoria:~$ curl -sS http://203.0.113.10:8080/ <!DOCTYPE html><html><head><title>Agenda (copia de pruebas)</title></head><body><h1>Agenda de citas - copia de pruebas</h1></body></html>
«Agenda (copia de pruebas)». Eso es un entorno de pruebas de la aplicación de citas, servido a todo Internet en un puerto alternativo. Una copia de pruebas suele tener los datos de verdad del día que se copió, las contraseñas sin cambiar y los avisos de error puestos a contarlo todo, porque para eso es de pruebas. No hay que entrar en ella para que sea un hallazgo crítico: con la cabecera, el título y el puerto está demostrada.
Ejercicio
Las cabeceras de la web, y lo que hay en el 8080
En el servidor hay dos webs: la del 80 y otra en el 8080. Lee las cabeceras del 8080 sin bajarte la página y después mira qué sitio es. Con eso basta: no se entra.
Preparando la máquina…
Los fallos conocidos, sin tocar nada
Ya tienes versiones. El paso siguiente es el que convierte una lista de servicios en un informe que sirve: cotejar cada versión con los fallos que se le conocen. Y se hace exactamente así, sin tocar el servicio:
auditor@pc-auditoria:~$ nmap -sV -p 22 203.0.113.10 Starting Nmap 7.80 ( https://nmap.org ) at 2026-10-16 03:30 UTC Nmap scan report for srv-servicios.auditoria (203.0.113.10) Host is up (0.000040s latency). PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.18 (Ubuntu Linux; protocol 2.0) MAC Address: 8A:DD:A7:BF:D5:3A (Unknown) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 0.28 seconds
- Se lee la versión de lo que contestó el servicio:
OpenSSH 8.9p1 Ubuntu 3ubuntu0.18. Nada más; esta línea es la evidencia y va al informe tal cual. - Se busca esa versión en la ficha de fallos conocidos, que es una lista de qué le pasa a qué
versiones de qué programas. En la sala tienes la ficha en tu propio puesto, en
~/encargo/fallos-conocidos.txt. - Se escribe el hallazgo: qué servicio es, qué versión, qué fallo conocido le corresponde con su identificador, qué gravedad tiene y qué hay que hacer —que casi siempre es «actualizar el paquete de la distribución»—.
- Y se para ahí. No se comprueba si el fallo se puede aprovechar de verdad.
Ese punto cuarto es el que separa dos trabajos distintos, y merece explicarse bien, porque es la parte que más gente se salta.
Una auditoría de enumeración identifica y documenta. Dice: «este servicio es la versión tal, y a esa versión se le conoce este fallo, de esta gravedad; actualícese». Eso ya es un informe accionable: el cliente sabe qué parchear y en qué orden. Comprobar si el fallo de verdad se puede explotar en esa máquina, con esa configuración, es otra cosa: se llama prueba de explotación, puede tumbar el servicio, puede dejar rastros en los datos del cliente y va en un contrato distinto, con una cláusula que lo autorice expresamente y una ventana de mantenimiento acordada. Si tu contrato dice «revisión externa, solo reconocimiento y lectura» —como el de la clínica— y tú pruebas un exploit, te has salido del alcance aunque no rompas nada, y el cliente tiene razón al quejarse.
Hay además una razón práctica, no solo legal: una versión con un fallo conocido no significa que
el fallo esté ahí. Las distribuciones parchean sin cambiar el número que el banner enseña (mira
ese 3ubuntu0.18: es justo el número del parche de Ubuntu), hay fallos que solo se dan con una
opción concreta en la configuración, y hay otros que necesitan una cuenta que a lo mejor no existe.
Por eso un hallazgo de versión bien escrito dice «esta versión figura con este fallo conocido» y
no «este servidor es vulnerable»: lo primero es verdad y es útil; lo segundo es una afirmación
que no has comprobado.
Ejercicio
Cotejar la versión con la ficha, y apuntarlo
Ya sabes que el 22 es OpenSSH 8.9p1. Búscalo en la ficha de fallos conocidos del puesto (~/encargo/fallos-conocidos.txt) y apunta el hallazgo en el cuaderno (~/encargo/hallazgos.txt) con su identificador. Y se para ahí: no se prueba nada.
Preparando la máquina…
Lo que cuesta enumerar
El tema 1 enseñó que la prisa se paga en ruido. Aquí hay que añadirle una cosa: enumerar es más caro que barrer. Estos son los tiempos de la propia captura, sobre la misma máquina:
| Lo que se pidió | Lo que tardó |
|---|---|
nmap (los mil de siempre) |
0,07 s |
nmap -p- -T4 (los 65.535) |
1,06 s |
nmap -sV (los mil, con versiones) |
12,32 s |
nmap -sV -p- -T4 (todos, con versiones) |
13,34 s |
sudo nmap -sU -T4 -p 161 |
0,05 s |
sudo nmap -sU -sV -T4 -p 161 |
0,35 s |
Los segundos en sí no dicen nada —un contenedor en la misma máquina no se parece a Internet—: lo que
se compara es entre filas. Mirar los 65.535 puertos cuesta quince veces lo que mirar mil;
preguntarles la versión a siete cuesta más de ciento setenta veces lo que mirar los mil sin
preguntar nada. El caro es -sV, porque habla con cada servicio y espera su respuesta; añadirle
-p- encima casi no suma, porque el trabajo estaba en los que contestan.
Y hablar con un servicio deja huella. De las 72 líneas que este barrido dejó en el registro del servidor, mira estas tres:
root@srv-servicios:~# cat /var/log/nginx/access.log 203.0.113.5 - - [16/Oct/2026:03:29:58 +0000] "GET / HTTP/1.0" 200 612 "-" "-" 203.0.113.5 - - [16/Oct/2026:03:29:58 +0000] "GET / HTTP/1.0" 200 138 "-" "-" 203.0.113.5 - - [16/Oct/2026:03:30:04 +0000] "GET /nmaplowercheck1792121404 HTTP/1.1" 404 162 "-" "Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)"
Las dos primeras son el mismo -sV pidiendo la portada a las dos webs en el mismo segundo: la
de 612 bytes y la copia de pruebas de 138. Preguntar la versión es visitar el sitio, y quien
defienda lo ve. La tercera ya es el motor de scripts, que se presenta por su nombre en el agente de
usuario.
En la sala del tema
Estás en el mismo puesto de la auditoría que en el tema 1, pero de madrugada: la ventana del
encargo va de las 02:00 a las 06:00 de un martes, y a las ocho abre la clínica. El alcance es
el servidor, 198.51.100.34, y de su bloque público 198.51.100.32/29 solo se puede barrer
para ver quién vive. Excluido, como en la gestoría, el router del proveedor (198.51.100.33),
que está dentro del bloque y aun así no se toca; fuera también la red interna de la clínica. En el
.36 hay un equipo viejo que en la clínica creen apagado: lo mismo de siempre —se documenta, se
llama, no se toca—.
En el puesto, además del cuaderno, tienes la ficha de fallos conocidos
(~/encargo/fallos-conocidos.txt): la lista con la que se cotejan las versiones que vayas leyendo.
Cada hallazgo va al tablero con su evidencia (la salida que lo prueba), su gravedad y su
recomendación, y al final entregas el informe de pentest y te llevas la nota en estrellas. Lo que el
tema mide es si viste toda la superficie: el que solo barre los mil de siempre y no mira el UDP
entrega un informe que se queda corto justo en los dos sitios donde estaba lo gordo.