Nmap Scripting Engine

En mayor o menor medida,  todos hemos oído hablar de NMAP, esa herramienta creada por Fyodor  y con la que podremos, entre otras cosas, detectar equipos activos, sistemas operativos, servicios, versiones, etc. ¿Sus finalidades? Bueno, de lo más variopinta, desde la exploración de redes y sistemas,  auditorias de seguridad, procesos de pentesting, etc. Es una herramienta multiplataforma, de la que existe además una buena y abundante información. Su interfaz tanto por línea de comandos como una GUI denominada Zenmap la hacen asequible para todos los gustos de quien la utilice.

Pero  en este caso quiero habla de una de sus funcionalidades. La forma más común de emplear sería:

nmap dominioencuestion.com

Nmap tiene establecidas unas configuraciones por defecto, las cuales podremos ajustar con las distintas opciones que nos ofrece. Por ejemplo el rango de puertos a escanear, protocolos (TCP, UDP, etc.), técnicas para detección de cortafuegos con o sin estado, resolución DNS de los objetivos, cantidad de sondas enviadas, spoof de direcciones, etc.

Sin embargo una de las opciones más potentes de NMAP es lo que se denomina NSE (Nmap Scripting Engine). NSE es una funcionalidad que nos permite  por medio de scripts automatizar ciertas tareas según el script en cuestión. Estos scripts se dividen en varias categorías, como son:

auth: Scripts que gestionan procesos de autenticación.

broadcast: Orientado a la obtención de información por medioo de peticiones Broadcast.

brute: Scripts destinados a la auditoria a de contraseñas por medio de fuerza bruta.

default: Ejecución de scripts “by default”. Se ejecuta por medio de la oción –sC.

discovery: Scripts para el descubrimiento de equipos.

dos: Scripts relacionados con ataques tipo DoS.

exploit: Scripts que explotan vulnerabilidades.

external: Scripts que utilizan servicios externos o de terceros.

fuzzer: Scripts orientados a tareas de fuzzing, por ejemplo envío de datos malformados o inesperados.

intrusive: Scripts que podrían colapsar algunos sistemas o generar una gran cantidad de tráfico.

malware: Scripts relacionados con la detección de malware diverso.

safe: Scripts que pueden considerarse como “seguros” a diferencia por ejemplo de los catalogados como “intrusive”

version: Scripts para consultas avanzadas de distintos tiposd e versiones

vuln: Scripts que notifican si existe, o no, vulnerabilidades conocidas.

Una de las primeras tareas que deberemos hacer es actualizar nuestra base de datos.

nmap –script-updatedb 

Cada Script está catalogado dentro de cada una de las categorías según sea su utilidad. SI quisiéramos lanzar todos los scripts de una categoría concreta, deberíamos  utilizar:

nmap –sV –script auth <OBJETIVO> 

O sin queremnos más de una categoría:

nmap -sV –script=»version,discovery» <OBJETIVO>

Según sea nuestra distribución podremos encontrarlos en,

Kali:

/usr/share/nmap/scripts

Bugtraq:

/usr/local/share/nmap/scripts

Estos scripts no son “cerrados”, soportan la inclusión de argumentos, o variables que serán utilizadas para su ejecución. Por ejemplo quisiéramos realizar un ataque por fuerza bruta empleando HTTP y proporcionando un listado de usuarios y contraseñas concretos deberíamos utilizar:

nmap -p80 –script http-brute –script-args userdb=/var/usernames.

txt,passdb=/var/passwords.txt <OBJETIVO>

 Dado que son tareas automatizadas tenemos que tener en cuenta que su actividad podría ser detectada por IDS/IPS o firewalls que loguen el tráfico generado.

Como hemos dicho, Nmap cuenta con una interfaz gráfica denominada Zenmap, en la que también encontraremos estas funcionalidades.

 

Deberemos crear un “Profile”, por lo que pincharemos sobre él y una vez allí sobre “New Profile or Command”.

Allí en “Scripting” encontraremos todos los scripts disponibles.

 

Además podremos definir otros valores y sus respectivos valores y variantes para luego presionando “Scan” lanzarlo.

Como digo, esto es sólo el comienzo de Namp Scripting Engine, como todas las cosas luego nos toca a nosotros meter horas y horas para sacarle todo el provecho.

Un saludo.

 

Liberada Guía avanzada de nmap 6

El pasado día 13 de diciembre se liberó una guía sobre el uso de la archiconocida herramienta para el descubrimiento y análisis de equipos, servicios, S.O. etc. en una red para propósitos de auditoría o pentesting; NMAP. La misma no sólo abarca su funcionamiento sino además las técnicas más empleadas en su uso y sus  características más avanzadas como el motor de scripting NSE. Fruto de la colaboración del Centro Criptológico Nacional (CCN) y el Centro de Seguridad TIC de la comunidad Valenciana (CSIRT-CV) ve la luz un excelente documento que hay que dedicarle su tiempo para sacarle todo lo que nos ofrece en sus 112 hojas.

Para su descarga pincha aquí.

Switching Multicapa y SVI

Aquí estamos  de nuevo. Esta vez nos vamos a meter con una característica de los switches multicapa.

Para empezar definiremos qué es esto de los switches multicapa cuando, es posible, que hasta la fecha nos hayan contado que los switches son equipos de Capa 2 dentro del modelo OSI.  En origen, los switches sí que lo eran, pero como todo en esta vida, las cosas cambian y evolucionan. A veces a mejor, a veces a peor, pero en nuestro caso, y como no podía ser de otra manera, a mejor J. Como ya sabemos, los switches en el sentido tradicional de la palabra, efectúan los envíos de tramas considerando las direcciones MAC de los equipos que tiene conectados a cada una de sus bocas, permitiendo así las comunicaciones de la misma red, subred o VLAN. En el momento que queramos hacerlo contra otros fuera de éstas, por ejemplo una granja de servidores, con otro direccionamiento IP y VLAN (es lo suyo), necesitamos, entonces, un equipo de Capa 3 como puede ser un router o un switch multicapa. En un switch multicapa, la principal diferencia con los de Capa 2, es que ahora ya no se va a considerar la dirección MAC del equipo final sino la IP. Es decir, el direccionamiento de Capa 3; o sea, como lo hace un router. Y claro alguien preguntará ¿y en qué más se diferencian un router y un switch multicapa? Una de ellas es el rendimiento. Un switch multicapa está orientado a entornos LAN, pudiendo ofrecer rendimientos a la velocidad del medio que tengan conectado, ya sea 100 Mbps, 1Gbps o 10 Gbps. Esto se consigue gracias a una electrónica especializada denominada ASIC en lugar de un microprocesador que es lo que emplea un router.  Además como buen switch poseen una densidad de puertos mayor pudiendo ser de 12, 24, 48, puertos con medios de transmisión como cable UTP o Fibra Óptica dependiendo de fabricante, gama, modelo, etc. Y ni qué decir que puesto que son equipos que operan en capa 3 también dispondrán de funciones de enrutamiento, tanto estático como dinámico (OSPF, EIGRP, RIP, etc.).

Ahora bien, si tenemos un switch de estas características ¿cómo los echamos a andar? Esta vez tiraré de Packettracer, simulador de redes de Cisco, y tomaré el de capa de capa 3, el 3560.

Aquí tendremos un par de opciones.

Una de ellas es asignar a cada interfaz física del switch una dirección IP. Para ello deberemos configurar dicho puerto como uno de capa 3 en lugar de capa 2 que es como suelen venir por defecto. Para ello:

Switch>enable

Switch#conf t

Enter configuration commands, one per line.  End with CNTL/Z.

Switch(config)#interface fastEthernet 0/1

Switch(config-if)#no switchport

Switch(config-if)#ip address 192.168.1.1 255.255.255.0

Switch(config-if)#exit

Switch(config)#ip routing 

Una vez que entramos en el modo de configuración de la interfaz con “no switchport” indicamos que ese puerto (fastethernet 0/1) no tendrá capacidades L2 (Layer 2, Capa 2) sino L3. Luego con “ip address 192.168.1.1 255.255.255.0” le asignamos la IP y finalmente con “ip routing” habilitamos la capacidad de enrutamiento entre las distintas interfaces que tenga.

Esta es una opción, pero no la única. La otra es definir interfaces virtuales, lo que se denomina como SVI (Switch Virtual Interface). Una SVI es una interfaz definida en el quipo y asociada a una VLAN concreta. Uno de los requisitos es que tiene que haber un puerto activo en esa VLAN para que la SVI correspondiente se habilite. Un enlace troncal también vale. Aunque sea virtual podremos configurar en ella los mismos protocolos y funcionalidades que a una interfaz física como pueden ser HSRP, VRRP, GLBP, ACL´s, etc.

Para ponerlo en funcionamiento, tenemos que definir las VLANs, crear las SVI correspondientes a cada VLAN y asignar una IP, configurar las interfaces físicas bien en modo troncal o de acceso asociada a una VLAN, y habilitar el enrutamiento como en el paso anterior

Esto es:

Entramos en modo configuración:

Switch>ena

Switch>enable

Switch#conf t

Definimos las VLAN 10 y 20:

Switch(config)#vlan 10

Switch(config-vlan)#name VLAN_10

Switch(config-vlan)#exit

Switch(config)#vlan 20

Switch(config-vlan)#name VLAN_20

Switch(config-vlan)#exit

Configuramos las interfaces físicas:

Switch(config)#interface fastEthernet 0/1

Switch(config-if)#switchport mode access

Switch(config-if)#switchport access vlan 10

Switch(config-if)#exit

Switch(config)#interface fastEthernet 0/2

Switch(config-if)#switchport mode access

Switch(config-if)#switchport access vlan 20

Switch(config-if)#exit

Definimos las SVIs:

Switch(config)#interface vlan 10

Switch(config-if)#

Switch(config-if)#ip address 192.168.10.1 255.255.255.0

Switch(config-if)#exit

Switch(config)#interface vlan 20

Switch(config-if)#ip address 192.168.20.1 255.255.255.0

Switch(config-if)#exit

Habilitamos el enrutamiento:

Switch(config)#ip routing

Otra funcionalidad aparte de la comunicación entre redes,  es utilizarlas para la gestión de los propios equipos mediante protocolos como SSH, Telnet, monitorización, etc. para lo cual deberemos definir también una puerta de enlace para la comunicación con otras redes. No nos debemos olvidar que aún en este caso nuestros equipos de red al estar dotados con una IP aunque sea la de gestión, también puede ser objeto de escaneos de red con objeto de recolectar información, y realizar a posteriori algún tipo de explotación contra alguno de los servicios que puedan correr en ellos.

A continuación os dejo una captura de un escaneo sencillo contra un switch Catalyst 6509 dotado con sistema operativo CatOS.

Como se puede ver nmap lo ha detectado sin problemas. Para evitarlo es aconsejable definir algún tipo de ACL donde se permita algún tipo de tráfico desde una estación central de gestión. Pero eso lo dejamos para otro rato, por hoy lo dejamos.

Seguiremos informando…