Hay una mentira muy extendida en el sector IT: auditar la seguridad de una infraestructura requiere licencias de miles de euros y un equipo de analistas en la sombra tecleando en verde sobre negro. La realidad es que el 80% de los incidentes graves en aplicaciones web no vienen de ataques de día cero (Zero-Days) indetectables, sino de copias de seguridad olvidadas en un directorio público, puertos de bases de datos expuestos por error o paneles de administración sin segundo factor de autenticación.
Si eres administrador de sistemas, responsable IT de una pyme o un desarrollador web, tienes la obligación (técnica y a veces legal) de saber qué nivel de exposición tiene tu sitio. Pero no necesitas matar moscas a cañonazos.
Para auditar tu propia casa no hace falta comprar un tanque; necesitas una linterna, una ganzúa y saber dónde mirar. Vamos a construir tu stack mínimo viable: una metodología en cuatro fases (cinco si queremos documentar el resultado) basada en herramientas modernas, gratuitas (open source) y quirúrgicas que puedes empezar a usar hoy mismo desde tu terminal.
Índice de contenidos
Por qué necesitas algo simple y rápido para auditar tu web
El error número uno al empezar en seguridad defensiva es descargar un escáner masivo (tipo Nessus, Acunetix o OpenVAS), apuntar a tu dominio, darle a un botón y rezar.
¿El resultado? Un PDF de 400 páginas lleno de falsos positivos, alertas de «riesgo bajo» por cabeceras HTTP que no importan y cero contexto real. Estos escáneres son ruidosos, pesados y, lo peor de todo, no te enseñan nada sobre cómo funciona tu infraestructura. En el peor de los casos es posible que ni seas capaz de hacerlo funcionar.
No te preocupes. de momento es importante que sepas que con una simple consola puedes realizar muchísimas acciones.
El enfoque moderno de auditoría (Red Teaming ágil o Bug Bounty) se basa en encadenar pequeñas herramientas especializadas que hacen una sola cosa, pero la hacen a la perfección. Este enfoque te da control absoluto, te obliga a entender qué estás testeando y te permite integrarlo fácilmente en tus rutinas de mantenimiento sin bloquear el servidor por exceso de tráfico.
Fase 1: Reconocimiento y Mapeo (Mirar antes de disparar)
Antes de lanzar un solo ataque simulado, necesitas entender qué forma tiene tu infraestructura desde los ojos de un atacante externo.
dig y whois: Trazando el mapa DNS
Lo primero es saber a qué IP le vas a pegar. Si tu web está detrás de Cloudflare o una CDN, escanear ese dominio es inútil (solo estarás auditando los servidores de Cloudflare).
- La herramienta:
dig(para extraer registros DNS, subdominios expuestos o servidores de correo) ywhois(para ver a nombre de quién está el bloque de red). También herramientas como ViewDNS.info son increíblemente sencillas y efectivas. - El objetivo: Confirmar si la IP que ves es la real (Origin IP) o si necesitas investigar más para saltarte el WAF. Si quieres profundizar, revisa nuestra guía sobre cómo usar dig en fases de reconocimiento.
WhatWeb / Wappalyzer: El arte del Fingerprinting
No puedes atacar a ciegas. Tienes que saber qué software corre por debajo.
- La herramienta: Puedes usar la extensión Wappalyzer en tu navegador, o
whatwebdesde la terminal. - El objetivo: Identificar si la web corre sobre un Nginx desactualizado, qué versión exacta de PHP está ejecutando, si usa un CMS como WordPress o Ghost, y qué librerías de JavaScript carga. Esta información es el filtro que usarás en la fase 3 para no lanzar ataques de Windows contra un servidor Linux.
Fase 2: Descubrimiento activo (Buscando puertas abiertas)
Una vez que sabes dónde está el servidor y de qué está hecho, toca buscar entradas que no deberían estar ahí.
⚠️ Recordatorio de seguridad: Ejecuta estas herramientas únicamente sobre dominios e infraestructuras de tu propiedad o sobre las que tengas una autorización escrita. La línea entre una auditoría y un ataque es el permiso.
nmap: Escaneo sigiloso de puertos
- La herramienta: El estándar indiscutible. Olvídate de los escaneos agresivos por defecto.
- El objetivo: Comprobar qué servicios están expuestos a Internet aparte del puerto 80 (HTTP) y 443 (HTTPS). Si
nmapencuentra un puerto 22 (SSH), un 3306 (MySQL) o un 3389 (RDP) abierto al público general en el servidor web, tienes un problema crítico de firewall que debes parchear antes de seguir con el pentest.
ffuf: Fuzzing ultrarrápido (Buscando la basura escondida)
A veces, el mayor riesgo no es una inyección SQL, sino un archivo llamado backup_2024.zip alojado en la raíz del servidor.
- La herramienta:
ffuf(Fuzz Faster U Fool). Está escrito en Go y ha dejado obsoletos a clásicos como DirBuster. - El objetivo: Cruzar tu dominio contra un diccionario de palabras comunes (te recomendamos descargar los diccionarios de SecLists) para descubrir rutas ocultas, paneles de administración secretos (
/admin-login), APIs no documentadas (/api/v1/users) o archivos de configuración (.env,.git/).
Fase 3: Análisis de vulnerabilidades quirúrgico
Sabiendo qué puertos y directorios existen, buscamos fallos conocidos en esas tecnologías específicas.
Nuclei: El escáner moderno y a medida
- La herramienta: Nuclei (de ProjectDiscovery). Funciona en base a plantillas YAML aportadas por la comunidad.
- El objetivo: En lugar de lanzar un escaneo a lo loco, le dices a Nuclei: «Ya sé que esto es un Apache con PHP; lánzame solo las plantillas que busquen CVEs críticos para esta tecnología». Es brutalmente rápido y genera cero falsos positivos si lo configuras bien. Ideal para detectar malas configuraciones en cabeceras de seguridad o vulnerabilidades que salieron en las noticias hace solo dos días.
WPScan: La parada obligatoria para WordPress
Si la Fase 1 te dijo que usas WordPress, no inventes la rueda.
- La herramienta:
wpscan. Es un escáner de caja negra específico para este CMS. - El objetivo: Enumerar a los usuarios reales del panel (lo que facilita la fuerza bruta), descubrir qué versión exacta de cada plugin tienes instalada y cruzarlos con su base de datos para decirte cuáles tienen vulnerabilidades públicas.
Fase 4: Manipulación manual (El trabajo artesano)
Ninguna herramienta automática va a descubrir que, si cambias el ID de usuario id=5 por id=6 en la URL de tu perfil, puedes ver la factura de otro cliente (un fallo conocido como IDOR). Eso requiere cerebro humano.
Burp Suite Community o Caido: Interceptando el tráfico
- La herramienta: Un proxy de interceptación. Burp Suite (en su versión Community gratuita) es el rey, aunque alternativas modernas en Rust como Caido están pisando fuerte.
- El objetivo: Lo colocas entre tu navegador y tu web. Cada vez que inicias sesión, envías un formulario o compras algo, el proxy detiene la petición HTTP. Esto te permite modificar los datos «al vuelo» antes de que lleguen al servidor. Aquí es donde buscas vulnerabilidades lógicas del OWASP Top 10: intentar inyectar comillas (
') para provocar un error SQL, o meter código JavaScript en un cajón de comentarios para probar un ataque XSS.
Fase 5: El informe accionable (Cómo documentar sin morir de aburrimiento)
Una auditoría que termina sin un informe claro no es un pentest, es simplemente hacer el gamberro en la terminal. De nada sirve encontrar un directorio oculto o un fallo lógico si luego no sabes explicarle al equipo de desarrollo (o a ti mismo dentro de tres meses) dónde está y cómo arreglarlo.
Y no, exportar un PDF automático de Nessus o Acunetix con 400 páginas llenas de «Riesgos Bajos» por cabeceras HTTP faltantes no cuenta como informe. Tu objetivo al auditar tu propia casa es crear un documento ejecutivo, directo y, sobre todo, accionable.
La regla de oro: Evidencia, Impacto y Remediación
Para que un hallazgo sea útil, olvídate de la literatura y redáctalo siempre siguiendo esta estructura de tres bloques:
- La Evidencia (El cómo): No digas simplemente «El panel de login es vulnerable». Pon el comando
curlexacto o la captura de pantalla de Burp Suite que permite reproducir el fallo. Si otra persona copia y pega tu evidencia, debería ver el mismo error que tú. - El Impacto real (El qué): A la dirección de la empresa no le importan las puntuaciones CVSS. Traduce el hallazgo a impacto de negocio. En lugar de «Falta validación de parámetros (Riesgo Alto)», escribe: «Cualquier usuario puede interceptar la petición y descargar las facturas de otros clientes cambiando el parámetro ID».
- La Remediación (La solución): El objetivo final. Proporciona el parche o la acción exacta. Ejemplos: «Cerrar el puerto 3306 en
ufw«, «Actualizar el plugin X a la versión 3.4», o «Añadir autenticación multifactor (MFA) en la ruta/admin«.
Herramientas para no perder el tiempo
Huye de los procesadores de texto tradicionales tipo Word; al pegar código o comandos, el formato se rompe y es una pesadilla.
Los profesionales de la ciberseguridad documentan en texto plano. Utiliza Markdown en herramientas como Obsidian para tomar notas ágiles durante la Fase 2 y 3. Si quieres darle un aspecto más profesional o estandarizado, herramientas open source como SysReptor (diseñada específicamente para informes de pentesting) te permiten crear reportes técnicos brutales en minutos sin pelearte con el diseño.
Ejemplo de auditoria web express: comandos por consola
A continuación, encontrarás el bloque de código con los comandos exactos para ejecutar cada fase de la auditoría que hemos visto. Estos comandos están optimizados para ser rápidos, precisos y lo más silenciosos posible, permitiéndote obtener un mapa real de tu superficie de exposición sin saturar tus propios servidores.
# ==========================================
# FASE 1: RECONOCIMIENTO Y MAPEO
# ==========================================
# 1. dig: Obtener la IP real del dominio (registro A) para saber a dónde apuntar
# Salida esperada: Una o varias direcciones IPv4 planas (ej. 192.168.1.10)
dig +short misitio.com
# 2. whois: Consultar el propietario del bloque de red
# Salida esperada: Bloque de texto con datos del ASN, CIDR y empresa responsable (útil para detectar si la IP es de Cloudflare/AWS o del cliente final)
whois misitio.com
# 3. whatweb: Fingerprinting web pasivo para identificar tecnologías y CMS
# Salida esperada: Línea con las tecnologías detectadas, cabeceras y versiones (ej. [ Apache/2.4.41 ][ PHP/7.4.3 ][ WordPress/5.8 ])
whatweb https://misitio.com
# ==========================================
# FASE 2: DESCUBRIMIENTO ACTIVO
# ==========================================
# 4. nmap: Escaneo sigiloso (SYN) de todos los puertos, extrayendo versiones de servicios
# Salida esperada: Tabla detallada con puertos abiertos, estado y servicio/versión (ej. 22/tcp open ssh OpenSSH 8.2p1 Ubuntu)
nmap -sS -sV -p- --min-rate 5000 IP_OBJETIVO
# 5. ffuf: Descubrir directorios y archivos ocultos ignorando los errores 404
# Salida esperada: Lista de rutas encontradas con su código de estado y tamaño (ej. /admin [Status: 200, Size: 1542, Words: 120])
ffuf -w /usr/share/seclists/Discovery/Web-Content/raft-small-directories.txt -u https://misitio.com/FUZZ -fc 404
# ==========================================
# FASE 3: ANÁLISIS DE VULNERABILIDADES
# ==========================================
# 6. nuclei: Escaneo quirúrgico filtrando solo por CVEs críticos/altos y paneles expuestos
# Salida esperada: Líneas formateadas con la vulnerabilidad exacta y severidad (ej. [CVE-2021-41773] [http] [critical] https://misitio.com/cgi-bin/.%2e)
nuclei -u https://misitio.com -t cves,exposed-panels -s critical,high
# 7. wpscan: Escaneo furtivo en WordPress enumerando usuarios y plugins vulnerables
# Salida esperada: Reporte en texto con usuarios válidos encontrados y tablas de plugins desactualizados cruzados con la base de datos de WPScan
wpscan --url https://misitio.com -e vp,u --api-token TU_TOKEN_AQUI --random-user-agent --stealthy
Checklist: El flujo de trabajo en 5 pasos
Para que no te pierdas, este es el orden exacto de ejecución si fueras a auditar tu sitio esta misma tarde:
- Mapea la red: Ejecuta
digywhois. Confirma tu IP real. - Identifica el software: Pásale
whatwebo revisa Wappalyzer. Anota tecnologías y versiones. - Busca puertas y ventanas: Lanza
nmap(solo a la IP confirmada) yffuf(con un buen diccionario). Anota puertos extraños y directorios ocultos. - Busca fallos conocidos: Dispara
Nucleicon plantillas específicas para las tecnologías que encontraste en el paso 2. - Prueba la lógica de negocio: Abre Burp Suite, navega por tu web como un usuario normal e intenta engañar a los formularios y parámetros de la URL.
Los límites de auditarte a ti mismo
Hay que ser honestos: pasarte este stack de herramientas te va a limpiar el 80% del ruido y evitará que caigas víctima de ataques automatizados o script kiddies. Es un ejercicio técnico de higiene innegociable.
Pero… (y es un gran pero…) no reemplaza a un equipo de Red Team profesional ni a una auditoría externa de caja blanca. Al auditar tu propio código o tu propia infraestructura, sufres un sesgo cognitivo brutal (el síndrome del «esto ya sé cómo funciona, no lo voy a mirar»).
Además, un auditor experto encadenará vulnerabilidades de riesgo bajo para conseguir impacto crítico, algo que requiere años de experiencia (o una IA muy avanzada que aún tengo que descubrir por mi mismo).
Estoy seguro de que alguien con ganas podría tirar esta web, tengo que vivir con ello y por suerte no es lo que me paga las facturas. Pero las puertas no están abiertas.
Úsalo como tu primera línea de defensa, no como un sello definitivo de «100% seguro».
Conclusión
La ciberseguridad ofensiva intimida desde fuera, pero se vuelve extremadamente lógica cuando la divides en fases. Construir un stack mínimo viable con dig, ffuf, nmap, Nuclei y Burp Suite te da el poder de ver tu infraestructura sin la capa de maquillaje del navegador.
No esperes a tener presupuesto para licencias de miles de euros. Levanta una terminal, apunta las herramientas contra un entorno de staging o preproducción que controles (¡nunca audites sin permiso plataformas de terceros!) y empieza a mancharte las manos.
Descubrir tu primer panel de administración expuesto con ffuf es una cura de humildad que te convertirá en un profesional IT mucho más completo.
