Hace ya un mes desde la última entrada... me temo que he estado más liado de lo que me hubiese gustado (bueno, y una escapadita a Asturias, pero eso no cuenta :P ) y no he podido escribir antes a pesar de que tengo bastantes cosas pendientes por publicar... vamos a ver si poco a poco se normaliza todo y puedo volver a publicar varias entradas a la semana.
En más de una ocasión he acabado hablando con compañeros o amigos acerca de cómo montar un "laboratorio de pentest" con el que poder practicar distintas técnicas, hacer perrerías de todo tipo y demás; la verdad que actualmente es bastante fácil montarse uno gracias a las máquinas virtuales, además de que ya hay disponibles varias máquinas virtuales ideadas para hacer prácticas de seguridad y aprender en el camino.
Las primeras que voy a comentar son las máquinas virtuales disponibles en http://www.de-ice.net/, varias creadas por Thomas Wilhelm y otra creada por un miembro del foro, bond00.
Entre las creadas por Thomas tenemos tres grupos por así decirlo, un primer nivel compuesto por dos máquinas virtuales, un segundo nivel compuesto por una única máquina virtual y otro correspondiente a unos artículos que Thomas está publicando en la revista hakin9 (si no la conocéis os la recomiendo encarecidamente, podéis suscribiros y recibirla gratuitamente en el correo desde hace unos meses).
De-Ice Level 1:
Bajo mi punto de vista no tienen mucho a nivel técnico puesto que casi todo se basa en técnicas de fuerza bruta (por supuesto es una opción más a tener en cuenta a la hora de realizar una prueba de pentest), básicamente realizar una enumeración de posibles usuarios con los datos de la web, comprobarlos con el correo y conseguir una credencial básica para poder realizar una escalada de privilegios posteriormente.
Aunque no me gusten tanto como otras opciones también conviene practicar dichas técnicas y llevará darle al coco un buen rato para resolver alguna que otra cosa.
De-Ice Level 2:
Aún no he podido jugar mucho con él, pero por lo que he podido ver (por Internet circulan distintos vídeos de cómo resolverlo) tiene mejor pinta que los anteriores (al menos bajo mi punto de vista, claro). Siento no poder decir mucho más, pero sin haberlo resuelto tampoco me voy a mojar demasiado, jeje.
VM Hakin9:
La verdad que hasta donde he podido ver con dichas máquinas virtuales me ha gustado mucho (en los números de hakin9 va publicando las "soluciones"). Entre las cosas que más me ha gustado es la implementación de una backdoor que abre una shell de root mediante una técnica simple de "port-knocking", realmente original el implementarlo y realmente fácil de encontrar en un servidor que ha sido comprometido.
También ha incluido la segunda máquina virtual para que se ataque desde la primera, aprovechándonos de lo que se conoce como "abuso de confianza", algo que es fácil que se nos pase por alto en un momento dado, pero conviene tener en cuenta que muchas máquinas tienen un firewall de host que permite ciertas conexiones sólo desde ciertas máquinas "seguras y administradas".
Realmente recomendables...
pwnOS:
Además del trabajo realizado por Thomas nos encontramos con una máquina virtual creada por bond00 llamada pwnOS.
Dicha máquina virtual está pensada para ser atacada con exploits encontrados en, la ya difunta, milw0rm; estuvo mucho tiempo en la brecha, aunque finalmente str0ke decidió no continuar el trabajo y tras un tiempo de incertidumbre de si alguien cogería el relevo decidió cerrar.
Los chicos de Offensive Security (la gente de Backtrack) crearon www.exploit-db.com e importaron todo el material ya existente en milw0rm, además de que diariamente se añaden cosas nuevas, también os recomiendo que os deis una vuelta por la web.
Pero bueno, que me voy por los cerros de Úbeda... volviendo al tema de la máquina virtual, podéis encontrar los exploit en exploit-db e incluso en Metasploit.
Lo que me gustó de dicha máquina es que tiene varias formas de resolverse, algunas más técnicas y otras menos. Por ejemplo, podemos aprovecharnos de la predictibilidad, digo aleatoriedad, de la que sufrió Debian para poder conectarnos por ssh y después escalar privilegios con exploit local...
Espero que os haya gustado la entrada y ya estéis descargando las máquinas para probarlas... (si tenéis cualquier duda pregutad).
En las próximas entradas mostraré otras máquinas pensadas también para ser atacadas y practicar cosillas de seguridad (además de explicar cómo montar un pequeño laboratorio de red para realizar ataques a protocolos de red)
Un saludo, gente
PD: Si véis que con este tipo de máquinas virtuales no sabéis por donde tirar probad a escanearlas con Nessus y OpenVAS ;)
domingo, 17 de octubre de 2010
viernes, 10 de septiembre de 2010
Information Gathering - DNS Cache Snooping
Como ya hemos visto en alguna ocasión, a la hora de realizar una auditoría o una prueba de pentest lo primero y más importante es reunir cuanta información sea posible acerca del objetivo, es la fase que se denomina "information gathering".
Probablemente nos interese saber qué clase de webs visitan los usuarios de dicha empresa, quizá para realizar un ataque de ingeniería social relacionado con alguno de los dominios cacheados, o realizar un ataque de evilgrade para comprometer equipos. La mejor manera de saber los dominios visitados es comprobar si se puede realizar un "snooping" sobre la caché del servidor DNS.
¿Y cómo sabemos si se puede realizar? Muy fácil, debido al funcionamiento jerárquico del protocolo DNS si nosotros realizamos una consulta DNS e indicamos al servidor que es una consulta no recursiva (el servidor DNS no intentará escalar la consuta) y se nos devuelve la entrada de dicha consulta querrá decir que el servidor permite realizar consultas a la caché y que dicho dominio ya se ha solicitado con anterioridad.
Hace un tiempo cree un pequeño script en python para poder realizar dicho trabajo de una forma sencilla. Para obtener una lista de dominios que probar lo más fácil es acudir a Alexa y extraer los dominios que nos interesen, incluso tienen un csv con el top 1 millón de webs en el ránking. Dependiendo de la finalidad buscada se pueden usar distintas categorías:
El script al ejecutarse sin parámetros y la ayuda del mismo
El script al ejecutarlo con el parámetro -c que comprueba si los servidores DNS correspondientes a un dominio permiten resolución no recursiva.
La forma en la que comprueba si un servidor es susceptible de dicha enumeración es pidiendo primero unas direcciones muy comunes como puedan ser google, youtube, facebook, etc.
(He quitado el dominio por si acaso a alguien se le ocurre tirarle la lista de Alexa entera o algo así...)
Aquí el programa con el parámetro -s y los primeros resultados de la lista de Alexa
Bueno, aquí os dejo el código, espero que os sirva.
Un saludo a todos y hasta la próxima!
Probablemente nos interese saber qué clase de webs visitan los usuarios de dicha empresa, quizá para realizar un ataque de ingeniería social relacionado con alguno de los dominios cacheados, o realizar un ataque de evilgrade para comprometer equipos. La mejor manera de saber los dominios visitados es comprobar si se puede realizar un "snooping" sobre la caché del servidor DNS.
¿Y cómo sabemos si se puede realizar? Muy fácil, debido al funcionamiento jerárquico del protocolo DNS si nosotros realizamos una consulta DNS e indicamos al servidor que es una consulta no recursiva (el servidor DNS no intentará escalar la consuta) y se nos devuelve la entrada de dicha consulta querrá decir que el servidor permite realizar consultas a la caché y que dicho dominio ya se ha solicitado con anterioridad.
Hace un tiempo cree un pequeño script en python para poder realizar dicho trabajo de una forma sencilla. Para obtener una lista de dominios que probar lo más fácil es acudir a Alexa y extraer los dominios que nos interesen, incluso tienen un csv con el top 1 millón de webs en el ránking. Dependiendo de la finalidad buscada se pueden usar distintas categorías:
- Direcciones de actualización para realizar ataques de evilgrade
- Dominios de malware para saber si algún equipo está contactando con un servidor de malware (existen multitud de dominios de malware, pero puede ser útil para comprobar algunos en concreto)
- Un atacante con fines lucrativos podría buscar ciertos dominios "para adultos" con el fin de chantajear
- Búsqueda de redes sociales y profesionales. Por ejemplo, para buscar en ellas más información acerca de los empleados.
- Para buscar tus propios dominios y saber si la empresa se ha interesado por tí. Por ejemplo, una entidad de gestión visitando páginas p2p o de detectives privados :)
- Y un sinfín de posibilidades, os animo a comentar más posibilidades.
El script al ejecutarse sin parámetros y la ayuda del mismo
El script al ejecutarlo con el parámetro -c que comprueba si los servidores DNS correspondientes a un dominio permiten resolución no recursiva.
(He quitado el dominio por si acaso a alguien se le ocurre tirarle la lista de Alexa entera o algo así...)
Aquí el programa con el parámetro -s y los primeros resultados de la lista de Alexa
Bueno, aquí os dejo el código, espero que os sirva.
Un saludo a todos y hasta la próxima!
martes, 7 de septiembre de 2010
Atacando SNMP (II)
Sacando las cadenas de comunidad
Cargamos metasploit, el módulo necesario y lo configuramos:
root@bt:~# msfconsole
msf > use auxiliary/scanner/snmp/community
Vemos las opciones de configuración:
Pasamos a configurarlo:
msf auxiliary(community) > set RHOSTS 192.168.1.1, 192.168.1.51, 192.168.1.230
RHOSTS => 192.168.1.1, 192.168.1.51, 192.168.1.230
msf auxiliary(community) > set THREADS 3
THREADS => 3
Y lo ejecutamos:
Como se puede ver hemos obtenido las comunidades SNMP gracias a Metasploit.
Leyendo la configuración con snmpenum
Probamos a extrare la configuración del router cisco (el segundo argumento es la cadena y el tercero el fichero de texto con los OID):
root@bt:/pentest/enumeration/snmpenum# ./snmpenum.pl 192.168.1.51 private cisco.txt
Entre toda la información conseguida se encuentra la siguiente:
----------------------------------------
PROCESSES
----------------------------------------
Chunk Manager
Load Meter
[...]
SNMP ENGINE
----------------------------------------
IP ADDRESSES
----------------------------------------
192.168.1.51
192.168.2.51
----------------------------------------
HARDWARE
----------------------------------------
2691 chassis
3620 Chassis Slot
c2691 Motherboard with Fast Ethernet
Y ahora probamos a extraer la información del router de Vyatta, pero esta vez usando los OID de Linux:
root@bt:/pentest/enumeration/snmpenum# ./snmpenum.pl 192.168.1.230 write linux.txt
----------------------------------------
RUNNING PROCESSES
----------------------------------------
init
kthreadd
migration/0
ksoftirqd/0
watchdog/0
----------------------------------------
LISTENING UDP PORTS
----------------------------------------
123
161
520
----------------------------------------
LISTENING TCP PORTS
----------------------------------------
22
443
Leyendo la configuración con snmpcheck
Probamos a leer la configuración con snmpcheck del router cisco (el segundo parámetro es la comunidad y el tercero indica que se compruebe si se puede escribir):
root@bt:/pentest/enumeration/snmpcheck# ./snmpcheck.pl -t 192.168.1.51 -c private -w
snmpcheck.pl v1.7 - snmp enumerator
Copyright (c) 2005-2008 by Matteo Cantoni (nothink.org)
[*] try to connect to 192.168.1.51...
[x] Connected to 192.168.1.51! Starting check at Mon Sep 6 17:05:05 2010
[!] Write access enabled!
[*] Network interfaces
-----------------------------------------------------------------------------------------------
IP Forwarding Enabled : 1
Interface : [ up ] FastEthernet0/0
Hardware Address : 0xc0002bd10000
Interface Speed : 10 Mbps
IP Address : 192.168.1.51
Netmask : 255.255.255.0
MTU : 1500
Bytes In : 7397380 (7.1M)
Bytes Out : 181463 (178K)
Interface : [ up ] FastEthernet0/1
Hardware Address : 0xc0002bd10001
Interface Speed : 10 Mbps
IP Address : 192.168.2.51
Netmask : 255.255.255.0
MTU : 1500
Bytes In : 58722 (58K)
Bytes Out : 82403 (81K)
Interface : [ up ] Null0
Interface Speed : 4294.967295 Mbps
MTU : 1500
Y ahora probamos a extraer la configuración del router Vyatta:
root@bt:/pentest/enumeration/snmpcheck# ./snmpcheck.pl -t 192.168.1.230 -c write -w
snmpcheck.pl v1.7 - snmp enumerator
Copyright (c) 2005-2008 by Matteo Cantoni (nothink.org)
[*] try to connect to 192.168.1.230...
[x] Connected to 192.168.1.230! Starting check at Mon Sep 6 17:07:16 2010
[!] Write access enabled!
Hostname : vyatta
Description : Vyatta VC6.0-2010.06.01
Uptime (snmpd) : 39 minutes, 38.57
[*] Devices
-----------------------------------------------------------------------------------------------
Status Name
running network interface lo
running network interface eth0
running SCSI disk (/dev/sda)
unknown Guessing that there's a floating point co-processor
unknown GenuineIntel: Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz
Se extrae bastante más información, pero pongo sólo una parte.
Leyendo la información con snmpwalk
También es posible utilizar el programa snmpwalk para recorrer toda la MIB (Base de Información de Administración )e ir mostrando cada OID (ID de Objeto).
root@bt:/# snmpwalk -c private -v1 192.168.1.51
Y veremos toda la información:
[...]
IP-FORWARD-MIB::ipCidrRouteDest.192.168.1.0.255.255.255.0.0.0.0.0.0 = IpAddress: 192.168.1.0
IP-FORWARD-MIB::ipCidrRouteDest.192.168.2.0.255.255.255.0.0.0.0.0.0 = IpAddress: 192.168.2.0
IP-FORWARD-MIB::ipCidrRouteMask.192.168.1.0.255.255.255.0.0.0.0.0.0 = IpAddress: 255.255.255.0
[...]
Además de leer la configuración como comentamos en el primer post es posible escribir en la misma utilizando SNMP, si no utilizamos ninguna herramienta gráfica es un proceso bastante engorroso y nada intuitivo (salvo que te aprendas de memoria los OID...) en cualquier caso aquí dejo un ejemplo de la web de Cisco para crear una VLAN por SNMP.
Como hemos visto en las dos últimas entradas el uso del protocolo SNMP es algo que se debe estudiar con cuidado y plantearse la necesidad del mismo, sobretodo si no se usa la versión 3.
Un saludo a todos
Cargamos metasploit, el módulo necesario y lo configuramos:
root@bt:~# msfconsole
msf > use auxiliary/scanner/snmp/community
Vemos las opciones de configuración:
Pasamos a configurarlo:
msf auxiliary(community) > set RHOSTS 192.168.1.1, 192.168.1.51, 192.168.1.230
RHOSTS => 192.168.1.1, 192.168.1.51, 192.168.1.230
msf auxiliary(community) > set THREADS 3
THREADS => 3
Y lo ejecutamos:
Como se puede ver hemos obtenido las comunidades SNMP gracias a Metasploit.
Leyendo la configuración con snmpenum
Probamos a extrare la configuración del router cisco (el segundo argumento es la cadena y el tercero el fichero de texto con los OID):
root@bt:/pentest/enumeration/snmpenum# ./snmpenum.pl 192.168.1.51 private cisco.txt
Entre toda la información conseguida se encuentra la siguiente:
----------------------------------------
PROCESSES
----------------------------------------
Chunk Manager
Load Meter
[...]
SNMP ENGINE
----------------------------------------
IP ADDRESSES
----------------------------------------
192.168.1.51
192.168.2.51
----------------------------------------
HARDWARE
----------------------------------------
2691 chassis
3620 Chassis Slot
c2691 Motherboard with Fast Ethernet
Y ahora probamos a extraer la información del router de Vyatta, pero esta vez usando los OID de Linux:
root@bt:/pentest/enumeration/snmpenum# ./snmpenum.pl 192.168.1.230 write linux.txt
----------------------------------------
RUNNING PROCESSES
----------------------------------------
init
kthreadd
migration/0
ksoftirqd/0
watchdog/0
----------------------------------------
LISTENING UDP PORTS
----------------------------------------
123
161
520
----------------------------------------
LISTENING TCP PORTS
----------------------------------------
22
443
Leyendo la configuración con snmpcheck
Probamos a leer la configuración con snmpcheck del router cisco (el segundo parámetro es la comunidad y el tercero indica que se compruebe si se puede escribir):
root@bt:/pentest/enumeration/snmpcheck# ./snmpcheck.pl -t 192.168.1.51 -c private -w
snmpcheck.pl v1.7 - snmp enumerator
Copyright (c) 2005-2008 by Matteo Cantoni (nothink.org)
[*] try to connect to 192.168.1.51...
[x] Connected to 192.168.1.51! Starting check at Mon Sep 6 17:05:05 2010
[!] Write access enabled!
[*] Network interfaces
-----------------------------------------------------------------------------------------------
IP Forwarding Enabled : 1
Interface : [ up ] FastEthernet0/0
Hardware Address : 0xc0002bd10000
Interface Speed : 10 Mbps
IP Address : 192.168.1.51
Netmask : 255.255.255.0
MTU : 1500
Bytes In : 7397380 (7.1M)
Bytes Out : 181463 (178K)
Interface : [ up ] FastEthernet0/1
Hardware Address : 0xc0002bd10001
Interface Speed : 10 Mbps
IP Address : 192.168.2.51
Netmask : 255.255.255.0
MTU : 1500
Bytes In : 58722 (58K)
Bytes Out : 82403 (81K)
Interface : [ up ] Null0
Interface Speed : 4294.967295 Mbps
MTU : 1500
Y ahora probamos a extraer la configuración del router Vyatta:
root@bt:/pentest/enumeration/snmpcheck# ./snmpcheck.pl -t 192.168.1.230 -c write -w
snmpcheck.pl v1.7 - snmp enumerator
Copyright (c) 2005-2008 by Matteo Cantoni (nothink.org)
[*] try to connect to 192.168.1.230...
[x] Connected to 192.168.1.230! Starting check at Mon Sep 6 17:07:16 2010
[!] Write access enabled!
Hostname : vyatta
Description : Vyatta VC6.0-2010.06.01
Uptime (snmpd) : 39 minutes, 38.57
[*] Devices
-----------------------------------------------------------------------------------------------
Status Name
running network interface lo
running network interface eth0
running SCSI disk (/dev/sda)
unknown Guessing that there's a floating point co-processor
unknown GenuineIntel: Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz
Se extrae bastante más información, pero pongo sólo una parte.
Leyendo la información con snmpwalk
También es posible utilizar el programa snmpwalk para recorrer toda la MIB (Base de Información de Administración )e ir mostrando cada OID (ID de Objeto).
root@bt:/# snmpwalk -c private -v1 192.168.1.51
Y veremos toda la información:
[...]
IP-FORWARD-MIB::ipCidrRouteDest.192.168.1.0.255.255.255.0.0.0.0.0.0 = IpAddress: 192.168.1.0
IP-FORWARD-MIB::ipCidrRouteDest.192.168.2.0.255.255.255.0.0.0.0.0.0 = IpAddress: 192.168.2.0
IP-FORWARD-MIB::ipCidrRouteMask.192.168.1.0.255.255.255.0.0.0.0.0.0 = IpAddress: 255.255.255.0
[...]
Además de leer la configuración como comentamos en el primer post es posible escribir en la misma utilizando SNMP, si no utilizamos ninguna herramienta gráfica es un proceso bastante engorroso y nada intuitivo (salvo que te aprendas de memoria los OID...) en cualquier caso aquí dejo un ejemplo de la web de Cisco para crear una VLAN por SNMP.
Como hemos visto en las dos últimas entradas el uso del protocolo SNMP es algo que se debe estudiar con cuidado y plantearse la necesidad del mismo, sobretodo si no se usa la versión 3.
Un saludo a todos
lunes, 6 de septiembre de 2010
Atacando SNMP (I)
Es común encontrar dispositivos de red y servidores monitorizados mediante SNMP para obtener estadísticas acerca del tráfico, procesos corriendo en memoria, estado de las interfaces, etc.
El principal problema de seguridad que encontramos en el protocolo SNMP es que, en sus versiones 1 y 2, el campo "comunidad" (usado para la autenticación) va sin cifrar, por lo que cualquier ataque de eavesdropping, como un man in the middle, permitirá leer en claro la cadena y usarla para prácticamente cualquier tipo de fin.
En SNMP se utilizan dos cadenas de comunidad, normalmente una denominada "public" que permite leer la configuración del dispositivo y una denominada "private" que permite leer y grabar la configuración.
Para poder realizar las prácticas vamos a usar Vyatta por un lado (software basado en Linux que permite montar routers de forma gratuita además de poder usarse como IPS,VPN y content filtering) y por otro routers Cisco 2691, en mi caso emulados con GNS3.
Instalación y configuración de Vyatta
Una vez hemos creado una máquina virtual y arrancado desde la iso bastará con que ejecutemos los siguientes comandos para tenerlo todo listo:
vyatta@vyatta# install image
Seguimos los pasos del asistente pero dejándolo todo por defecto no tardaremos más de un par de minutos en instalarlo.
vyatta@vyatta# configure
vyatta@vyatta# set interfaces ethernet eth0 address 192.168.1.230/24
vyatta@vyatta# set service https
vyatta@vyatta# set service ssh
vyatta@vyatta# commit
Con ello conseguiremos activar la interfaz, darle una dirección IP y activar los servicios ssh y https por comodidad.
Para activar SNMP:
vyatta@vyatta# set service snmp community read
vyatta@vyatta# edit service snmp community read
vyatta@vyatta# set authorization ro
vyatta@vyatta# commit
vyatta@vyatta# top
vyatta@vyatta# set service snmp community write
vyatta@vyatta# edit service snmp community write
vyatta@vyatta# set authorization rw
vyatta@vyatta# commit
vyatta@vyatta# top
Configuración Cisco
Router> enable
Router#configure terminal
Router(config)#interface fastEthernet 0/0 (en este caso es la que tengo conectada a la tarjeta de red)
Router(config-if)#ip address 192.168.1.51 255.255.255.0
Router(config-if)#no shutdown
Router(config)#snmp-server community public RORouter(config)#snmp-server community private RW
Localizando dispositivos que utilizan SNMP
Una de las formas más fáciles y rápidas es lanzar un escaneo de puertos con nmap, como sabemos que SNMP utiliza el puerto UDP 161:
root@bt:~# nmap -sU -p161 --open --reason 192.168.1.0/24
Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-09-06 16:33 EDT
Nmap scan report for 192.168.1.1
Host is up, received arp-response (0.0013s latency).
PORT STATE SERVICE REASON
161/udp open|filtered snmp no-response
MAC Address: 00:02:CF:6D:23:DF (ZyGate Communications)
Nmap scan report for 192.168.1.51
Host is up, received arp-response (0.0073s latency).
PORT STATE SERVICE REASON
161/udp open snmp udp-response
MAC Address: C0:00:2B:D1:00:00 (Unknown)
Nmap scan report for 192.168.1.230
Host is up, received arp-response (0.00045s latency).
PORT STATE SERVICE REASON
161/udp open snmp udp-response
MAC Address: 00:0C:29:C1:2E:EE (VMware)
Nmap done: 256 IP addresses (5 hosts up) scanned in 3.29 seconds
La opción --open es para que nmap sólo muestre los host con el puerto categorizado como abierto y --reason nos indica el por qué de dicha categorización.
Una vez que sabemos las direcciones ips debemos "adivinar" las cadenas de comunidad que utilizan los dispositivos.
El principal problema de seguridad que encontramos en el protocolo SNMP es que, en sus versiones 1 y 2, el campo "comunidad" (usado para la autenticación) va sin cifrar, por lo que cualquier ataque de eavesdropping, como un man in the middle, permitirá leer en claro la cadena y usarla para prácticamente cualquier tipo de fin.
En SNMP se utilizan dos cadenas de comunidad, normalmente una denominada "public" que permite leer la configuración del dispositivo y una denominada "private" que permite leer y grabar la configuración.
Para poder realizar las prácticas vamos a usar Vyatta por un lado (software basado en Linux que permite montar routers de forma gratuita además de poder usarse como IPS,VPN y content filtering) y por otro routers Cisco 2691, en mi caso emulados con GNS3.
Instalación y configuración de Vyatta
Una vez hemos creado una máquina virtual y arrancado desde la iso bastará con que ejecutemos los siguientes comandos para tenerlo todo listo:
vyatta@vyatta# install image
Seguimos los pasos del asistente pero dejándolo todo por defecto no tardaremos más de un par de minutos en instalarlo.
vyatta@vyatta# configure
vyatta@vyatta# set interfaces ethernet eth0 address 192.168.1.230/24
vyatta@vyatta# set service https
vyatta@vyatta# set service ssh
vyatta@vyatta# commit
Con ello conseguiremos activar la interfaz, darle una dirección IP y activar los servicios ssh y https por comodidad.
Para activar SNMP:
vyatta@vyatta# set service snmp community read
vyatta@vyatta# edit service snmp community read
vyatta@vyatta# set authorization ro
vyatta@vyatta# commit
vyatta@vyatta# top
vyatta@vyatta# set service snmp community write
vyatta@vyatta# edit service snmp community write
vyatta@vyatta# set authorization rw
vyatta@vyatta# commit
vyatta@vyatta# top
Configuración Cisco
Router> enable
Router#configure terminal
Router(config)#interface fastEthernet 0/0 (en este caso es la que tengo conectada a la tarjeta de red)
Router(config-if)#ip address 192.168.1.51 255.255.255.0
Router(config-if)#no shutdown
Router(config)#snmp-server community public RORouter(config)#snmp-server community private RW
Localizando dispositivos que utilizan SNMP
Una de las formas más fáciles y rápidas es lanzar un escaneo de puertos con nmap, como sabemos que SNMP utiliza el puerto UDP 161:
root@bt:~# nmap -sU -p161 --open --reason 192.168.1.0/24
Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-09-06 16:33 EDT
Nmap scan report for 192.168.1.1
Host is up, received arp-response (0.0013s latency).
PORT STATE SERVICE REASON
161/udp open|filtered snmp no-response
MAC Address: 00:02:CF:6D:23:DF (ZyGate Communications)
Nmap scan report for 192.168.1.51
Host is up, received arp-response (0.0073s latency).
PORT STATE SERVICE REASON
161/udp open snmp udp-response
MAC Address: C0:00:2B:D1:00:00 (Unknown)
Nmap scan report for 192.168.1.230
Host is up, received arp-response (0.00045s latency).
PORT STATE SERVICE REASON
161/udp open snmp udp-response
MAC Address: 00:0C:29:C1:2E:EE (VMware)
Nmap done: 256 IP addresses (5 hosts up) scanned in 3.29 seconds
La opción --open es para que nmap sólo muestre los host con el puerto categorizado como abierto y --reason nos indica el por qué de dicha categorización.
Una vez que sabemos las direcciones ips debemos "adivinar" las cadenas de comunidad que utilizan los dispositivos.
Suscribirse a:
Entradas (Atom)