Ciberseguridad OpenSource Tecnología Vulnerabilidades

8 de mayo de 2026 • 6 min lectura

Cómo funcionan los plugins de OpenVAS: NASL, NVTs y creación de comprobaciones personalizadas

h3st4k3r

Después de instalar OpenVAS o, más correctamente, Greenbone Community Edition, una de las partes más interesantes es entender qué ocurre realmente por debajo cuando lanzamos un escaneo.

La mayoría de gente se queda en la interfaz web, pulsa “Start Scan” y revisa resultados. Pero el verdadero núcleo del sistema son los plugins de detección, conocidos como NVTs (Network Vulnerability Tests).

En este artículo vamos a ver cómo funcionan esos plugins, dónde se almacenan, qué lenguaje utilizan y cómo crear nuestras propias comprobaciones personalizadas.

No vamos a centrarnos en explotación agresiva ni en modificar el feed oficial directamente. La idea es entender la arquitectura y construir plugins privados de forma limpia y mantenible.

Qué es realmente un plugin en OpenVAS

Cuando OpenVAS lanza un escaneo, no ejecuta una “inteligencia mágica”. Lo que realmente hace es ejecutar cientos o miles de pequeños scripts especializados.

Cada uno de esos scripts es un NVT. Algunos detectan versiones vulnerables, otros revisan banners, otros hacen peticiones HTTP, otros intentan autenticarse por SSH o SMB y otros buscan configuraciones inseguras.

Es decir: OpenVAS es, en gran parte, un enorme motor que ejecuta scripts NASL de forma organizada.

Qué es NASL

NASL significa Nessus Attack Scripting Language. Es un lenguaje diseñado específicamente para comprobaciones de seguridad y escaneo de vulnerabilidades.

Aunque nació ligado históricamente a Nessus, OpenVAS heredó esa filosofía y sigue usando NASL como lenguaje principal para sus plugins.

No es un lenguaje generalista como Python o Go. Está pensado para tareas muy concretas:

Enviar peticiones HTTP.
Leer banners.
Consultar puertos.
Analizar respuestas.
Trabajar con sockets.
Usar una base de conocimiento interna.
Generar hallazgos.

Eso hace que escribir comprobaciones simples sea bastante rápido.

Dónde están los plugins de OpenVAS

La ubicación depende de cómo se haya instalado Greenbone.

En muchas instalaciones modernas suele ser:

/var/lib/openvas/plugins/

En instalaciones desde código fuente usando /usr/local, también es habitual ver algo como:

/usr/local/var/lib/openvas/plugins/

La forma correcta de comprobarlo es revisar la configuración:

cat /etc/openvas/openvas.conf | grep plugins

O directamente:

grep plugins_folder /etc/openvas/openvas.conf

Cómo están organizados los plugins

Dentro del directorio de plugins veremos miles de archivos .nasl.

Ejemplos reales:

apache_tomcat_detect.nasl
ssl_drown.nasl
http_trace.nasl
smb_nt_ms17_010.nasl

También existen librerías auxiliares llamadas normalmente .inc, que contienen funciones reutilizables.

Por ejemplo:

http_func.inc
http_keepalive.inc
smb_func.inc

Los plugins suelen incluir estas librerías para no reinventar constantemente funciones básicas.

No modifiques el feed oficial directamente

Esto es importante.

Modificar directamente plugins oficiales del feed suele ser mala idea porque:

las actualizaciones pueden sobrescribir cambios
puedes romper dependencias
dificulta troubleshooting
pierdes trazabilidad

Lo razonable es mantener plugins personalizados en una zona separada.

Por ejemplo:

/var/lib/openvas/plugins/private/

o cualquier estructura organizada por categorías internas.

Anatomía básica de un plugin NASL

Un plugin NASL suele tener dos partes:

bloque de descripción y metadatos
lógica de comprobación

Ejemplo mínimo:

if(description)
{
  script_oid("1.3.6.1.4.1.99999.1.1");
  script_version("2026-05-08");
  script_name("Detección personalizada de Apache");
  script_category(ACT_GATHER_INFO);
  script_family("Custom");
  script_copyright("Copyright (C) 2026 h3st4k3r");

  script_dependencies("find_service.nasl");
  script_require_ports("Services/www", 80);

  exit(0);
}

La parte if(description) no ejecuta la comprobación. Solo define información que OpenVAS usa internamente.

Qué significan estos campos

Campo	Función
`script_oid`	Identificador único del plugin
`script_version`	Versión interna
`script_name`	Nombre visible en OpenVAS
`script_family`	Categoría del plugin
`script_dependencies`	Plugins que deben ejecutarse antes
`script_require_ports`	Puertos necesarios para ejecutar el test

El OID es especialmente importante. No debe reutilizarse arbitrariamente.

Crear un plugin sencillo

Vamos a crear una comprobación simple que detecte un servidor Apache mediante la respuesta HTTP.

Primero creamos el archivo:

sudo nano /var/lib/openvas/plugins/private/apache_detect_custom.nasl

Contenido:

if(description)
{
  script_oid("1.3.6.1.4.1.99999.1.2");
  script_version("2026-05-08");
  script_name("Custom Apache Detection");
  script_category(ACT_GATHER_INFO);
  script_family("Custom");
  script_copyright("Copyright (C) 2026 h3st4k3r");

  script_dependencies("find_service.nasl");
  script_require_ports("Services/www", 80);

  exit(0);
}

include("http_func.inc");
include("http_keepalive.inc");

port = get_http_port(default:80);

if(!get_port_state(port))
  exit(0);

banner = http_get_cache(item:"/", port:port);

if("Apache" >< banner)
{
  security_message(
    port:port,
    data:"Servidor Apache detectado mediante respuesta HTTP."
  );
}

Qué hace este plugin

usa funciones HTTP internas
detecta el puerto HTTP
comprueba si el puerto está abierto
obtiene contenido cacheado HTTP
busca la cadena “Apache”
genera un hallazgo informativo

No explota nada. Solo detecta.

Probar plugins manualmente

Antes de integrarlo en OpenVAS, conviene probarlo manualmente.

Herramienta típica:

openvas-nasl

Ejemplo:

openvas-nasl -t 192.168.1.10 apache_detect_custom.nasl

También puedes activar trazas:

openvas-nasl -d -t 192.168.1.10 apache_detect_custom.nasl

Recargar plugins

Después de añadir nuevos plugins, OpenVAS necesita recargar información.

Dependiendo de la versión, normalmente bastará con reiniciar servicios:

sudo systemctl restart ospd-openvas
sudo systemctl restart gvmd

En algunas instalaciones también puede ser útil reconstruir la caché:

sudo openvas --update-vt-info

Cómo aparecen en Greenbone

Una vez cargado correctamente, el plugin aparecerá como cualquier otro NVT dentro de la interfaz.

Podrás verlo:

en resultados de escaneo
en familias de plugins
en reportes
en filtros por OID

Uso de la Knowledge Base (KB)

OpenVAS mantiene una especie de base de conocimiento interna entre plugins.

Eso permite que unos plugins aprovechen información descubierta por otros.

Ejemplo típico:

version = get_kb_item("Apache/Version");

Eso evita repetir comprobaciones constantemente.

Categorías de plugins

NASL usa distintas categorías internas.

Categoría	Uso
`ACT_GATHER_INFO`	Detección e información
`ACT_ATTACK`	Comprobaciones activas
`ACT_DENIAL`	Tests potencialmente peligrosos
`ACT_SETTINGS`	Configuraciones internas

Para plugins propios, normalmente tiene sentido empezar por ACT_GATHER_INFO.

Buenas prácticas

No modificar directamente plugins oficiales.
Usar OIDs privados consistentes.
Documentar versiones internas.
Separar plugins personalizados por carpetas.
Probar siempre con openvas-nasl.
No lanzar comprobaciones destructivas innecesarias.
Reutilizar librerías .inc siempre que sea posible.

Errores típicos

El plugin no aparece

Suele deberse a:

OID duplicado
error de sintaxis
plugin fuera del directorio correcto
servicios sin reiniciar

El plugin no genera resultados

Comprueba:

si el puerto realmente está abierto
si la dependencia previa funciona
si el banner esperado existe
si el plugin sale demasiado pronto con exit(0)

Errores NASL

Usa depuración:

openvas-nasl -d -t TARGET plugin.nasl

Y revisa logs:

sudo tail -f /var/log/gvm/ospd-openvas.log

Ideas útiles para plugins personalizados

detección de cabeceras inseguras
banners corporativos internos
servicios legacy propios
detección de software interno
comprobaciones específicas de laboratorio
validación de configuraciones internas

Conclusión

Entender NASL y los plugins de OpenVAS cambia bastante la percepción de la herramienta. Deja de ser simplemente una interfaz web para convertirse en un motor enorme de comprobaciones automatizadas.

La capacidad de crear plugins personalizados permite adaptar OpenVAS a entornos internos, laboratorios, servicios propios o validaciones muy específicas que normalmente no aparecen en feeds públicos.

Además, entender cómo funcionan los NVTs ayuda muchísimo a interpretar resultados, reducir falsos positivos y comprender qué está haciendo realmente el escáner durante una auditoría.