Reconocimiento web con Nikto: ejecutar, filtrar y verificar resultados

1. Nikto propone candidatos; tú decides qué está demostrado

Nikto compara respuestas de un servidor web con una base de pruebas. Puede señalar archivos por defecto, configuración, cabeceras, productos y versiones. No comprende por sí solo la arquitectura, los backports del proveedor ni el riesgo de negocio. Al terminar tendrás tres colas: confirmado, descartado y pendiente, cada una con el motivo de la decisión.

Empieza con una línea base negativa: solicita una ruta aleatoria inexistente y registra código, Location, longitud, tipo y un fragmento no sensible. Si una regla recibe la misma respuesta, probablemente ha encontrado el error genérico del sitio, no el recurso que describe.

2. Instala una versión conocida y registra su procedencia

Esta guía está contrastada con Nikto 2.6.0. Kali mantiene un paquete propio. En macOS y Windows, la imagen oficial fijada evita depender de una instalación local de Perl; requiere Docker ya instalado y deja los informes en una carpeta montada del host. No uses latest en un ejercicio que deba repetirse.

-Version debe mostrar la versión del programa, plugins y bases. En Kali, una configuración antigua en /etc/nikto.conf puede cambiar el comportamiento; la documentación del proyecto recomienda contrastar problemas con una instalación portable limpia antes de atribuirlos al objetivo.

3. Ejecuta una primera pasada acotada y reproducible

El tuning 23b incluye únicamente 2 —configuración y archivos por defecto—, 3 —divulgación de información— y b —identificación de software—. Excluye categorías de inyección, recuperación de archivos, ejecución, bypass y carga. -Cgidirs none evita ampliar el barrido a directorios CGI; -Pause 0.2 introduce 200 ms entre pruebas y -maxtime 10m limita el tiempo por host.

La URL completa fija esquema, nombre y puerto implícito. No sigas redirecciones automáticamente en esta pasada: primero necesitas comprobar que cada Location permanece dentro del alcance. -nocheckimpide la consulta de versión al arrancar; no desactiva pruebas contra el laboratorio.

El resumen indica volumen, errores y candidatos, no severidad. Un banner, un robots.txt y una cabecera ausente son clases de observación diferentes; no las mezcles en una puntuación automática.

4. Reduce ruido en tres capas y conserva el original

Filtra primero el alcance de pruebas, después la respuesta negativa y al final lavista del informe. Guarda siempre nikto-base.txt intacto y escribe cada repetición en otro archivo. Así puedes explicar qué desapareció y por qué.

Si tres rutas inexistentes devuelven el mismo cuerpo con la frase ficticia «Recurso no encontrado», puedes hacer una segunda pasada con -404string. Usa una firma específica y estable; un término amplio puede ocultar contenido real. Si todas las respuestas son 302, compara antes sus destinos: ignorar el código de forma global también eliminaría redirecciones legítimas.

5. Reproduce cada candidato con la mínima solicitud

Copia URL, mensaje y referencia de Nikto a una tabla. Repite la solicitud con curl sin cookies ni autenticación, conserva cabeceras y descarta el cuerpo cuando no sea necesario. Compara con raíz y línea base; cambia solo una variable cada vez.

Marca confirmado cuando reproduces la condición y entiendes su contexto; descartadocuando coincide con la línea base o la premisa es falsa; pendiente cuando falta información del propietario. No conviertas «pendiente» en vulnerabilidad por prudencia estadística.

6. Diagnostica fallos sin aumentar agresividad

-maxtime limita duración, no número exacto de solicitudes. -Pause reduce frecuencia, pero no sustituye una tasa acordada y observada. Si el riesgo de disponibilidad es alto, el propietario debe proporcionar un clon o entorno de staging representativo.

7. Entrega un informe breve, reproducible y saneado

Para cada candidato conserva: hora UTC, versión de Nikto, URL y virtual host, tuning, test o referencia, solicitud mínima, código, cabeceras relevantes, comparación con la línea base, estado de triage, impacto contextual y acción recomendada. No adjuntes cookies, tokens, cuerpos con datos personales ni informes HTML completos sin revisar.

• □La autorización nombra host, puerto, virtual host, ventana y uso de escáner automatizado
• □La raíz y varias rutas inexistentes forman la línea base antes de filtrar
• □La versión de Nikto, plugins y bases queda registrada
• □El primer escaneo usa Tuning 23b, CGI desactivado, pausa, timeout y tiempo máximo
• □El informe base se conserva intacto y cada repetición usa otro archivo
• □Los filtros 404 están justificados por respuestas negativas estables
• □Cada candidato se verifica con una solicitud manual mínima y sin credenciales
• □Banners, versiones y CVE se tratan como hipótesis hasta confirmar parche y componente
• □429, 5xx sostenidos, latencia o salida de alcance provocan parada
• □La entrega separa confirmado, descartado y pendiente y elimina información sensible

Para defender, retira páginas y archivos por defecto, reduce banners innecesarios, configura cabeceras según el contenido, protege rutas con autorización server-side y revisa parches desde el inventario real. Ejecuta el mismo perfil controlado después de corregir y compara únicamente los candidatos anteriores; que Nikto deje de alertar es una señal útil, no la única prueba de remediación.

Glosario