Saltar al contenido
Volver al Blog

noticias · 3 min de lectura

Vendiendo humo: RUSTSCAN vs NMAP

Análisis crítico de RustScan, la herramienta que prometía escanear puertos mucho más rápido que Nmap. ¿Es realmente revolucionaria o solo un wrapper agresivo? Comparativa real con configuraciones avanzadas de Nmap que logran resultados más precisos y rápidos.

· Manuel López Pérez · noticias

Análisis crítico de RustScan, la herramienta que prometía escanear puertos mucho más rápido que Nmap. ¿Es realmente revolucionaria o solo un wrapper agresivo? Comparativa real con configuraciones avanzadas de Nmap que logran resultados más precisos y rápidos.

En este post analizaremos la nueva moda de publicar códigos “vendehumo” de dudosa calidad para ganar unas cuantas interacciones, demostrar que su nivel no es muy alto o que no saben leer la documentación de otras herramientas que ya existen ;) Por esta moda nos encontramos publicaciones en Twitter, Linkedin o incluso Twitch que pueden llegar a confundir a gente que está empezando en esto o que simplemente no tiene mucho nivel técnico.

Esta semana se hizo bastante viral el siguiente Tweet de @AsensiFj: https://twitter.com/AsensiFj/status/1285635854032089090

No voy a unirme a los comentarios que ha recibido este Tweet, pero os animo a leerlos. Hay otros que directamente no se cortan y copian repositorios tal cual y dicen que son suyos: https://web.archive.org/web/20200724121252/https://github.com/Marduky/Facial_recognition - https://github.com/MProx/Facial_recognition

En este post hablaremos de Rustscan, la nueva herramienta “revolucionaria” que promete scanners de puerto mucho más rápidos que Nmap. https://twitter.com/TheHackersNews/status/1286178618133983232

Si repasamos el código fuente de la herramienta nos damos cuenta de que el autor no ha leído la documentación de Nmap, una herramienta que él mismo usa en su script. La herramienta sólo intenta conectarse a los 65 mil puertos en baches. Este enfoque provoca mucho más ruido y puede que resultados erróneos. Pero aun que provocara más tráfico, ¿no está mal si es mucho más rápido no?

Lo gracioso es que puede hacer exactamente lo mismo con NMAP. Los parámetros por defecto en RustScan son 4500 conexiones simultáneas y 1500 ms de rtt timeout. Si buscamos en la documentación de NMAP:

—min-rtt-timeout time, —max-rtt-timeout time, —initial-rtt-timeout time (Adjust probe timeouts): Nmap mantiene un valor de expiración en ejecución para saber cuánto tiempo debe esperar para recibir la respuesta a una sonda o para retransmitir la sonda. Se pueden recortar los tiempos de análisis de forma apreciable. Sin embargo, no se debería establecer a valores muy agresivos.

—min-rate number; —max-rate number (Controla directamente la tasa de exploración)

Por tanto, una configuración similar a la de Rustscan sería:

 nmap --min-rate 4500 --max-rtt-timeout 1500ms -p- IP

RUSTSCAN vs NMAP

Rustscan

Con Rustscan se encuentran 10 puertos abiertos: 88, 135, 139, 445, 53, 389, 5985, 49155, 49154, 49157 en 21.67 segundos.

NMAP 1

 nmap --min-rate 4500 --max-rtt-timeout 1500ms -p- 10.10.10.182

Utilizando la configuración que dijimos anteriormente, se encuentran 15 puertos abiertos: 53, 88, 135, 139, 389, 445, 636, 3268, 3269, 49154, 49155, 49157, 49158 y 49165 en 44.07 segundos. Por tanto el scan anterior de Rustscan no ha detectado los puertos 636, 3268 y 3269, entre otros, aun que ha tardado la mitad que Nmap.

NMAP 2

Pero puestos a ser rápidos y ruidosos, podemos utilizar otra configuración de Nmap más agresiva:

 nmap -sS -n -Pn -p- --max-rtt-timeout 100ms --min-parallelism 1000 10.10.10.182

Como veis esta configuración nos avisa (“Your —min-parallelism option is pretty high! This can hurt reliability.”) y los resultados han sido bastante mejores que Rustscan pues se han encontrado todos los puertos y ha tardado 14.73 segundos.

No debemos fiarnos de twitter :O

Volver al Blog

Posts Relacionados

Ver Todos los Posts »
Boletín — mayo 2026

noticias · 15 min

Boletín — mayo 2026

El Digital Omnibus cierra acuerdo provisional el 7 de mayo: Anexo III se mueve a diciembre de 2027. España aprueba su Ley de gobernanza de IA el 26 de mayo. Pwn2Own Berlin reparte 1,3 M$ por 47 zero-days con Codex y Claude Code en el menú. Patch Tuesday sin un solo zero-day por primera vez desde junio de 2024. OpenAI lanza Daybreak y Anthropic mueve Mythos hacia GA. Verizon DBIR 2026 corona la explotación de vulnerabilidades como vector número uno. GitHub pierde 3.800 repos internos por una extensión de VS Code.

· Manuel López Pérez

Boletín — agosto 2026 (primera quincena)

noticias · 16 min

Boletín — agosto 2026 (primera quincena)

Los diez primeros días de agosto cierran lo que julio dejó abierto. Tailscale reconstruye la intrusión de Hugging Face: un agente escapado enroló 181 nodos en la tailnet con una clave reutilizable, y el premio era el almacén de credenciales. Truffle encuentra 221.303 secretos vivos en los datasets públicos de Hugging Face. La UK AISI pilla a Mythos 5 y GPT-5.6 Sol inventando identidades falsas de GitHub para colar código. El agua de EE. UU. bajo ataque real: 4.400 PLCs Rockwell expuestos. La OSAA propone SAFE y la Casa Blanca dice, en Black Hat, que no habrá reglas nuevas. Vuelven los gusanos de npm, cinco CVEs entran al KEV con tres días de plazo, y el 2 de agosto del AI Act llega vacío.

· Manuel López Pérez

Boletín — julio 2026

noticias · 20 min

Boletín — julio 2026

Hugging Face publica el 16 de julio una intrusión en su infraestructura de producción ejecutada por un agente autónomo. El 21, OpenAI reconoce que el agente era suyo: dos modelos en evaluación se escaparon del sandbox. El 30, Anthropic disclosa tres incidentes propios del mismo tipo. Los guardrails de los modelos comerciales bloquearon la forensia y Hugging Face tuvo que analizar sus logs con un open-weights. Patch Tuesday cierra 622 CVEs, el triple del récord de junio; el kernel de Linux publica 432 en dos días y Oracle más de 1.400. El Omnibus se publica en el DOUE como Reglamento (UE) 2026/1744 y España acaba en el Tribunal de Justicia por NIS2.

· Manuel López Pérez