En la actualidad cuando se habla de “Administración de vulnerabilidades” casi siempre se asocia a una herramienta tecnológica que ejecuta pruebas de vulnerabilidades a nuestra infra estructura tecnológica. Este podría ser un buen primer acercamiento, sin embargo es una visión incompleta, como lo dices John P. Pironti en el articulo Elements of an information Security Program la administración de incidentes y vulnerabilidades debe contener los elementos tanto reactivos como proactivos para entender que vulnerabilidades existen así como el riesgo de las mismas

Para poder cumplir con una administración completa se deben tener en cuentas al menos los rubros que se muestran la siguiente figura:

Administración de activos: Este rubro se relaciona en tener identificados y clasificados los activos tecnológicos de la organización. No se basa en tener un inventario simplemente, es llegar a tener el valor de pérdida o nos disponibilidad del activo (BIA).

• Conocer y tener definido que activo representa más valor para la organización basado en criticidad y sensibilidad. Con esto se le da un peso mayor al momento de proteger el activo.
• También se relaciona con el hecho darle la preferencia a un activo sobre otros al momento de remediar una vulnerabilidad.· 
• Análisis de vulnerabilidades a nivel de red: Este procedimiento debe bridar el descubrimiento de las vulnerabilidades de la infra estructura a nivel de red de datos y voz.
• Análisis de vulnerabilidades de nivel de equipo: Este procedimiento debe brindar el descubrimiento de las vulnerabilidades y configuraciones por defecto en nivel de dispositivo.
• Análisis de configuraciones: Debe permitirnos evaluar la configuración y optimización de nuestra infra estructura.
• Pruebas de penetración: Este procedimiento nos permite probar la robustez de nuestros controles de seguridad ya que no solamente descubre vulnerabilidad, también las explota para obtener la mayor penetración en un sistema.
• Análisis de código: Estudios de análisis de código nos permiten evaluar y conocer vulnerabilidades en aplicaciones hechas en casa, antes de que estén en producción.
• Alertas de fabricantes y sitios de seguridad: El mantenernos informados respecto a nuevos ataques y vulnerabilidades que pudieran afectar a nuestra infra estructura debe ser un punto crucial.
• Determina el nivel de protección requerido para los sistemas de información y está muy relacionada con el priorización.
• Determina el impacto de una vulnerabilidad descubierta en nuestra organización. Este es importante recalcar que no es lo mismo que para un fabricante una vulnerabilidad es de nivel Medio, cuando esta permitirá que la CIA de la información pueda ser comprometida y esta vulnerabilidad exista en el 95% de la nuestra infra estructura tecnológica; el trato que se le deba dar a esta vulnerabilidad debería ser de carácter crítico y no medio. Este procedimiento deberá permitirnos conocer el riesgo de la vulnerabilidad aplicado a la organización, con esto es posible definir la estrategia de remediación.

El poder contar con un programa integral de administración de vulnerabilidades involucra varias dentro y fuera de la organización. Algunos de los procesos incluso deben ser realizados por un tercero para lograr una verdadera imparcialidad de las cosas.

Como último punto es importante recalcar que la información es y sirve a la organización y que la seguridad informática es una herramienta más para cumplir los objetivos del negocio y esta debe alinearse a estos objetivos sin perder la visión de los mismos.

Darkslaker

http://www.schneier.com/blog/archives/2007/05/is_penetration.html

http://www.ranum.com/security/computer_security/editorials/point-counterpoint/pentesting.html

Miren mi opinión es esta.

Primero hacer el ROI para un PT es muy complicado. Aun que Securityfocus tiene un artículo por ahí interesante, aun así es difícil.

Muchas personas creen que un PT es buena idea para ver una radiografía de cómo están las cosas. Los análisis de brechas y la auditoria de dominios del BS o el ISO una de sus entradas son los famosos PT y los AV. Estándares como SoX dicen que se deben hacer PT dos veces por años pero he aquí algunas implicaciones.

Miren mi opinión es esta.

Primero hacer el ROI para un PT es muy complicado. Aun que Securityfocus tiene un artículo por ahí interesante, aun así es difícil.

Muchas personas creen que un PT es buena idea para ver una radiografía de cómo están las cosas. Los análisis de brechas y la auditoria de dominios del BS o el ISO una de sus entradas son los famosos PT y los AV. Estándares como SoX dicen que se deben hacer PT dos veces por años pero he aquí algunas implicaciones.

1) A quien contrato. Un black Hat, un ISS que cobra miles y miles de dólares, o alguna otra empresa que cobra bien tiene buen personal.

Si yo llegara a contratar a cualquiera de los tres cuál de ellos me daría más. Después de unas semanas de trabajo recibo su reporte y resulta que todos ingresaron a mis sistemas pero cada uno por un camino diferente que pasó aquí.

Es importante recordar que un PT o un Hackeo Ético, no te da todas las brechas ni caminos posibles para ingresar al sistema y que existen muchos aspectos importantes para que esto se logre.

Aun que tengas personal capacitado y certificado en lo que quieras, mucho de esto tiene que ver con el feeling y experiencia del equipo involucrado en el proyecto.

2) Que busca un PT huecos de seguridad vulnerabilidades? NO.

Un PT busca por cualquier medio ingresar a un sistema y no siempre es por vulnerabilidades, muchas veces son debilidades (ojo y es muy diferente a una vulnerabilidad), o descuidos. Pero no busca encontrar todos los caminos posibles, más bien busca ingresar a un sistema. Si lo que buscas es mas todos los caminos creo que un AV y un análisis de brechas te acerca más a eso.

3) Ya mucho se ha dicho, un PT es como parchar una llanta, a veces ya se requiere una cámara o incluso cambiar la llanta completa. El modelo de encuentra y parchar es más cara, a tira lo que hay y ponlo seguro desde un principio.

PD. Seguimos explotando vulnerabilidades del siglo paso que triste NO.

Darkslaker

1.- Como cuanto te quieres gastar para saber que tan vulnerable eres!? Porque si me das 2 pesos eso es lo que vas a obtener en el resultado, pero si quieres una prueba donde los alcances lleguen a la definición de los 6 ámbitos de la seguridad según la OSSTMM, pues te va a costar más! Y continuando con la misma metodología dice que se basa en la experiencia y feeling del tester. Entonces por consiguiente no te vas con una empresa patito, para que puedas desmitificar los resultados de tu PT, te informas antes con un experto. Y de acuerdo a tus necesidades decides si lo haces o no! O mejor aún, si estás obligado a ser compliance con SOX , ISO, GWAN , que se yo, es tu perro tu lo bañas!.

2.- Es una pérdida de tiempo, claro si los entregables son ilegibles y no sabes por dónde comenzar atacar el problema, sino eres técnico y solo sabes de números bonitos de finanzas pues requieres al menos de dos reportes por separado.

Si al contrario sabes que tienes bien definidos y difundidos tus procesos y procedimientos, planes de recuperación de desastres, planes de contingencia y de administración de parches, ya tienes al menos un poco menos de que preocuparte. Porque tan solo hablar de actualización de parches es muy tedioso y en estos momentos no sabemos si esta liberándose uno nuevo.

La seguridad física, controles y políticas son ya muy conocidas y enriquecidas con el usuario final, perfecto tienes todavía menos de que preocuparte. Solo que el nuevo elemento de la policía empresarial que te da servicio es muy amigable o mejor aún muy confiado y peor, no conoce como seguir el procedimiento. ¿Qué vas a hacer para remediarlo?

3.- Si en México no se ha registrado un incidente de seguridad grave, es porque los que lo han sufrido no quieren que se sepa, y ya contrataron los servicios outsourcing de expertos.

Falta malicia o decisión en la gente para llevar a cabo un ataque cyber-terrorista, pero de que se puede se puede.

Al menos se de más de uno.

No bastan los dispositivos de seguridad perimetral (IDS; firewall, etc, etc), no basta con dormir sabiendo que hoy no te paso nada. No sabes si despertaras mañana solicitando un Forense para tu sitio web.

Tienes a los mejores administradores de redes y telecomunicaciones, pero no sabes que están descontentos con el mísero sueldo y planean mandarte a la chin..a e irse con la competencia, ahhh y al menos darle unos cuantos de tus secretos o metodologías.

Jajaja, no sabes cuándo va a cambiar tu contraseña! Y no tendrás acceso a tu disco duro cifrado.

Mmm, piensalo. Es necesario un PT? Contratame!

Saludos.

Byte byte

P4r4n01ds.

En general, hacer ROI para seguridad es un terreno pantanoso, ¿Cómo puedes comprobar costos si estamos partiendo de riesgos y no fenómenos determinanticos?, creo que en este sentido la industria de la seguridad de información se parece más a la de las aseguradoras, sin embargo hay diferencias fundamentales que no viene al caso discutir ahora, eso es un tema que se cuece aparte.

Existe un “método” para hacer pen test que me gusta porque sirve para dar un panorama más amplio en cuanto a las vulnerabilidades (y debilidades por qué no?), se denomina “Attack tree” y en él vas construyendo tu vector de ataque PERO también documentas las otras ramas que pudiste haber tomado y se quedaron sin desarrollar por las restricciones de la tarea; a lo mejor un mapa así podría ser de mayor utilidad para un cliente *con idea*.

Me detengo un poco en el asunto del cliente *con idea* porque hay que aceptar la realidad de nuestro mercado -inclusive debemos sacar ventaja de ello, sin dejar de apuntalar el cómo vamos a tratar a un cliente que tenga mucha mayor idea, quizá un cliente extranjero-; en México no se ha evolucionado lo suficiente como para distinguir si un PT sirve o no, es la moda y hay que hacerlos, o es la única manera en que les puedes abrir los ojos en cuanto a qué tan patética es su seguridad – no que realmente vayan a hacer algo al respecto, pero ya tendrán a quién señalar y echar culpas-; en ese sentido los PT’s están que ni mandados a hacer en el contexto particular en el que estamos ahora, México 2007.

David Guitierrez

2) Que busca un PT huecos de seguridad vulnerabilidades? NO.
Tal vez lo que debo buscar es más que tipo de vulnerabilidades, debilidades, o descuidos tengo.

Entiendo que hay más de una forma de entrar a un servicio.
Pero si a todos los servicios entro por que faltan parches.
Me dice que como compañía debo concentrarme más en actualizar mis sistemas.

Si muchos de mis servicios son comprometidos por descuidos. Me dice que debo mejorar mi control de Calidad.

Si muchos son por Ingeniería Social, tal vez debería concentrarme más en capacitación.

Y me da un norte, de por donde se necesita invertir más respecto a la seguridad de la compañía.

Eso también se puede hacer con auditoría de procesos?
Si, pero ahí estas en operación normal.

En un Pen-Test, estas estresando al sistema.
Estresando al sistema salen más detalles que, en la operación normal, parecían correctos o normales.

Ahora que, si en el PT, solo damos un diagnostico de: “apestas ó tal vez apestas” pues como comenta el documento, no te sirve de mucho.

Lo que para mí es claro es, que es sólo una herramienta más de diagnostico, junto con la consultoría y auditoría. Después del diagnosticó debería de haber un plan de mejoría y remediación.

Extrapolando a medicina:
Puedes tener un check up normal (entrevistas),
Puedes hacer una prueba de esfuerzo para estresar el sistema (pen-test) para que salga algo que a simple vista no vez.
Te dice que andas mal necesitas dieta, hacer ejercicio y tomarte una pastillas carísimas. (Diagnostico y plan de mejoría/remediación)
Y te vale ma…s o menos un cacahuate y no haces nada. (No sigues los
quickhits)

Entonces sale la duda: ¿para que Jingados te hiciste el Buto checkup con “Pen-Testing” y todo?

Mhh.. Creo que lo que podemos hacer, es ver como cerrar el vendiendo la remediación.

O como hacer un plan de mejoría remediación.

Fernando Cajeme

Servicios públicos ofrecidos.

Ahora que conocemos los segmentos de red de una organización podemos conocer los servicios públicos ofrecidos. Lo primero que debemos hacer es echar una mirada a los nombres de los equipos que pudimos identificar en la fase anterior. Muchos administradores de red, ponen nombres significativos a sus equipos, estos nombres van relacionados con la función que desempeñan, algunos ejemplos son:

ns.dominio.com = Servidor DNS
dns.dominio.com = Servidor DNS
www.dominio.com = Servidor http
smtp.dominio.com = Servidor de correo.
Mail.dominio.com = Servidor de correo.
fw.dominio.com = firewall

ns.dominio.com = Servidor DNS
dns.dominio.com = Servidor DNS
www.dominio.com = Servidor http
smtp.dominio.com = Servidor de correo.
Mail.dominio.com = Servidor de correo.
fw.dominio.com = firewall

Si queremos no ser detectados (o hacer más difícil el rastreo) por administradores de red debemos tener mucho cuidado en esta parte, la clave para investigar los servicios públicos está en no simplemente enviar miles de paquetes generados con la herramienta nmap a todos los puertos y a todos los segmentos de red; mas bien podemos buscar por equipos y guiarnos por la información que tenemos actualmente para tratar de identificar que servicios ofrecen públicamente y únicamente lanzar el escaneo a esos puertos.

Los servicios públicos más comunes con los que cuentan la mayoría de las organizaciones se listan a continuación:

Por ejemplo, mediante la resolución de dominios encontré el siguiente dominio

portal2www.itesm.mx.

¿Que puedo hacer ahora? lanzar un escaneo a los puertos mas comunes y ver su respuesta.
Esto se puede hacer con n cantidad de escaners, en mi opinión nmap y unicornscaner son los mejores:

El nombre del host tiene www, por lo que es de suponerse que debe tener habilitado http y posiblemente https. Con el siguiente comando lanzaremos un escaneo utilizando la herramienta unicornscan al sitio portal2www.itesm.mx pero únicamente a los puertos 80 (http) y 443 (https):

# unicornscan -mT portal2www.itesm.mx.:80,443 -v
TCP open http[ 80] from 200.34.200.27 ttl 54
TCP open https[ 443] from 200.34.200.27 ttl 54

Como ya lo suponíamos, basados en el nombre del equipo, comprobamos que ambos puertos se encuentran abiertos. Si queremos lanzar un escaneo a los puertos más comunes mencionados en la lista anterior, con unicornscaner se haría de la siguiente forma:

# unicornscan -mT portal2www.itesm.mx.:q
TCP open ssh[ 22] from 200.34.200.27 ttl 54
TCP open http[ 80] from 200.34.200.27 ttl 54
TCP open https[ 443] from 200.34.200.27 ttl 54

De esta manera podemos comenzar a reconocer los servicios públicos que ofrece una organización. Pero no solo nos interesa conocer los servicios públicos que ofrece una organización, sino también las versiones de servidores que tienen, esto para realizar un análisis más específico y poder reconocer vulnerabilidades en los equipos:

Nmap nos permite hacer esto de una manera transparente:

La sintaxis seria: ‘nmap –sV –P0 –p Puerto IP’

# nmap -sV -P0 -p 80,443 www.eluniversal.com.mx

Starting Nmap 4.03 ( http://www.insecure.org/nmap/ ) at 2006-08-08 00:04 GMT
Interesting ports on na-148-243-168-46.na.avantel.net.mx (148.243.168.46):
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.0.54 ((Unix) PHP/5.0.5)
443/tcp filtered https

Nmap finished: 1 IP address (1 host up) scanned in 8.164 seconds

Si deseamos hacer esta búsqueda de banner y encontrar posibles versiones de servicios, lo podemos hacer simplemente con aplicaciones como netcat o telnet y conectarnos al puerto que necesitemos. Es importante mencionar que los banners no son una garantía que realmente este corriendo en el servidor tal versión de un software, muchas veces, por seguridad, los administradores del sistema pueden modificar el contenido del banner de sus equipos.

A continuación muestro un ejemplo de obtener un banner de https con openssl que es una herramienta de código abierto para establecer conexiones de ssl y tls.

# openssl s_client -quiet -connect www.banamex.com.mx:443
depth=2 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Mon, 14 Aug 2006 00:23:02 GMT
Content-length: 0
Content-type: text/html
Connection: close

El siguiente es un ejemplo de una obtención de banner de SMTP con netcat.

#nc mail.rosenblueth.mx 25
220 mail.rosenblueth.mx ESMTP Sendmail 8.11.6/8.11.6; Wed, 13 Dec 2006 10:36:31 -0600

La siguiente es una obtención de banner de telnet con un telnet (XD).

# telnet 200.39.31.1
ÿûÿûÿýÿýC
______________________________________________________________

|| ||
|| ||
|||| ||||
..:||||||:..:||||||:..
C i s c o S y s t e m s
Router de Acceso
______________________________________________________________
**************************************************************
* *
* TELEFONICA DATA MEXICO S.A DE C.V. *
* *
* ” GESTION DE RED ” *
* *
* EL ACCESO A ESTE EQUIPO ESTA RESTRINGIDO AL *
* PERSONAL AUTORIZADO DE LA EMPRESA *
* SI TIENES DUDAS PONTE EN CONTACTO CON NOSOTROS AL TEL. *
* (52) 3093-6904 *
* (52) 5249-9949 *
* *
* gestion.red@telefonica-data.com.mx *
* *
**************************************************************

User Access Verification

Username:

Arquitectura de los sistemas visibles.

¿Que representa tener la arquitectura?, con toda la información que tenemos actualmente, ya podemos generar un mapa de la red objetivo: contamos con el direccionamiento, los servicios públicos y la mayoría de las versiones de las aplicaciones que se encuentren en el sistema. Con la información que se ha recabado es posible definir si se cuenta con balanceadores de carga, diferentes ISP, que servicios están forwardeados (enviados a diferentes equipos en la DMZ o red interna con la misma IP pública), así como la alta disponibilidad de algunos servicios.

Con la información obtenida en fuentes publicas, como ofertas de empleo, podemos notar que tipo de tecnologías piden al personal para contratar y al identificar banners de equipos podemos saber el tipo y arquitectura de las plataformas que manejan en la red de la compañía objetivo.

¿Como identificamos que servicios están reenviados a otros equipos?, esto puede ser verificado por el TTL (http://es.wikipedia.org/wiki/Tiempo_de_Vida ) al enviar paquetes a ellos.

El siguiente un escaneo a los puertos 80 y 443

# unicornscan -mT www.banamex.com.mx:80,443
TCP open http[ 80] from 192.193.230.100 ttl 49
TCP open https[ 443] from 192.193.230.100 ttl 51

Los diferentes TTL nos indican que el Puerto 80 esta a dos saltos mas que el puerto 443, esto quiere decir que físicamente los servicios no se encuentran en el mismo equipo.

Para identificar diferentes proveedores de servicios para enlaces redundantes podemos trazar las rutas de los paquetes tanto por TCP, UDP como ICMP.

Las trazas de los paquetes también debemos hacerlas desde diferente partes del mundo para esto podemos ir a la pagina http://www.traceroute.org/ .

El siguiente es una trace de puerto 53 UDP con traceroute

# traceroute -p 53 -v -n 4.2.2.2 -p 1
traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 38 byte packets
1 192.168.244.1 36 bytes to 192.168.244.121 14.416 ms 7.792 ms 3.866 ms
2 192.168.244.20 46 bytes to 192.168.244.121 2.578 ms 3.484 ms 5.509 ms
3 200.36. bytes to 192.168.244.121 3.777 ms 3.717 ms 7.381 ms
4 200.36. bytes to 192.168.244.121 8.536 ms 5.027 ms 5.316 ms
5 200.38. bytes to 192.168.244.121 36.470 ms 31.229 ms 16.789 ms
6 201.125.72.210 36 bytes to 192.168.244.121 19.668 ms 33.953 ms *
7 200.38.132.85 36 bytes to 192.168.244.121 67.067 ms 75.708 ms 131.794 ms
8 12.119.9.13 36 bytes to 192.168.244.121 69.091 ms 88.645 ms 117.376 ms
9 12.123.222.102 148 bytes to 192.168.244.121 90.758 ms 86.053 ms 88.856 ms
10 12.123.222.29 36 bytes to 192.168.244.121 61.226 ms 155.555 ms 66.113 ms
11 4.68.111.189 36 bytes to 192.168.244.121 68.052 ms * 104.762 ms
12 4.68.102.135 36 bytes to 192.168.244.121 130.495 ms 155.040 ms 139.991 ms
13 4.2.2.2 46 bytes to 192.168.244.121 44.472 ms 89.933 ms 156.602 ms

El siguiente es una trace de puerto 53 TCP con tctrace

# tctrace -i eth0 -d 4.2.2.2 -p 53
1(2) [192.168.244.1]
2(1) [192.168.244.20]
3(1) [200.36.]
4(1) [200.36.]
5(1) [200.38.]
6(1) [201.125.72.210]
7(1) [200.38.132.85]
8(1) [12.119.9.13]
9(1) [12.123.222.102]
10(1) [12.123.222.29]
11(1) [4.68.111.189]
12(1) [4.68.102.7]
13(1) [4.2.2.2] (reached; closed)

Si comparamos los saltos hasta el 11 podemos ver que son iguales, después del equipo 4.68.11.189 siguen por diferentes caminos.

Enviando paquetes ICMP para ver estadísticas podemos reconocer otra ruta diferente:

C:Documents and Settingsdarkslaker>pathping 4.2.2.2

Tracing route to vnsc-bak.sys.gtei.net [4.2.2.2] over a maximum of 30 hops:
0 narc [192.168.244.120]
1 192.168.244.1
2 192.168.244.20
3 200.36.
4 200.36.
5 200.38.
6 201.125.72.210
7 200.38.132.85
8 12.119.9.13
9 12.123.222.102
10 12.123.222.29
11 4.68.111.189
12 4.68.102.71
13 4.2.2.2

Computing statistics for 325 seconds…
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 narc [192.168.244.120]
1/ 100 = 1% |
1 9ms 6/ 100 = 6% 5/ 100 = 5% 192.168.244.1
0/ 100 = 0% |
2 14ms 7/ 100 = 7% 6/ 100 = 6% 192.168.244.20
0/ 100 = 0% |
3 13ms 1/ 100 = 1% 0/ 100 = 0% 200.36.
0/ 100 = 0% |
4 11ms 8/ 100 = 8% 7/ 100 = 7% 200.36.
0/ 100 = 0% |
5 — 100/ 100 =100% 99/ 100 = 99% 200.38.193.226
0/ 100 = 0% |
6 — 100/ 100 =100% 99/ 100 = 99% 201.125.72.210
0/ 100 = 0% |
7 — 100/ 100 =100% 99/ 100 = 99% 200.38.132.85
0/ 100 = 0% |
8 107ms 3/ 100 = 3% 2/ 100 = 2% 12.119.9.13
0/ 100 = 0% |
9 — 100/ 100 =100% 99/ 100 = 99% 12.123.222.102
0/ 100 = 0% |
10 — 100/ 100 =100% 99/ 100 = 99% 12.123.222.29
0/ 100 = 0% |
11 104ms 6/ 100 = 6% 5/ 100 = 5% 4.68.111.189
0/ 100 = 0% |
12 111ms 6/ 100 = 6% 5/ 100 = 5% 4.68.102.71
0/ 100 = 0% |
13 119ms 1/ 100 = 1% 0/ 100 = 0% 4.2.2.2

Trace complete.

Se identifico en el salto 12 un nuevo equipo.

El identificar y seguir los caminos que nuestros paquetes tienen que viajar hasta llegar a su destino nos brinda mucha información valiosa. Por lo que es importante siempre verificar los caminos de paquetes TCP, UDP e ICMP.

Existen también algunas otras cosas que podemos verificar para realizar un mapa mas completo de la tecnología que usa una organización, por ejemplo, se pueden intentar técnicas de rebote de correo electrónico, que consisten en enviar un correo electrónico a un destinatario que no existe y con la respuesta automática del sistema se puede encontrar información como el tipo de servidor de SMTP y la versión del software antivirus etc.

Para identificar si un equipo se encuentra detrás de un loadbalancer (balanceador de carga) en aplicaciones Web, podemos usar el siguiente script:

#!/usr/bin/perl
# Enumerate web servers behind a load balancer
# 20020125 Mike Shema
$url = “/scripts”;
$n = 10;
if ($#ARGV print “Usage: $0 [URL] [repetitions]n”;
exit;
}
$host = $ARGV[0];
$url = $ARGV[1] if ($ARGV[1]);
$n = $ARGV[2] if ($ARGV[2] !~ /D+/);
$cmd = “echo -e “GET $url HTTP/1.0nn” | nc $host 80″;
for($i=0; $i $res = `$cmd`;
$res =~ /(.*http://)(.*)(/w+)/g;
print “$2n” if ($2);
}

# perl load_balancer.pl www.microsoft.com /mexico 5
207.46.19.30
207.46.225.60
207.46.198.60
207.46.20.30
207.46.20.60

Simplemente necesitamos conocer un directorio del portal, para utilizar este script.

El reto de seguir el rastro a una organización es muy grande y esta fue simplemente una pequeña mirada a lo que se puede realizar. Ahora depende de cada persona; su feeling y su experiencia le permitirán obtener diferentes datos o encontrar maneras más óptimas y refinadas de búsqueda.

Cualquier comentario favor de hacérmelo llegar:

rienzi@nimrod.com.mx

Nombres de Dominio de la organización:
Para un hacker, el conocer la mayor información relacionada con la organización antes de lanzar un ataque es indispensable. Dentro de la información que es necesaria recopilar encontramos:

• Nombres de dominio de la organización.
• Bloques de red y direccionamiento IP de la organización.
• Proveedores de servicio de Internet de la organización.

A continuación se muestran algunas maneras de localizar dicha información.
Primeramente es importante mencionar que el ICANN es responsable de la coordinación y de la administración de los elementos técnicos de DNS’s para garantizar una resolución unívoca de los nombres, de manera que los usuarios de Internet puedan encontrar todas las direcciones válidas. Para ello, se encarga de supervisar la distribución de los identificadores técnicos únicos usados en las operaciones de Internet, y delegar los nombres de dominios de primer nivel (como .com, .info, etc.).
ICANN se encarga de administrar los nombres de dominio y direccionamiento IP mediante organizaciones alrededor de mundo. Las siguientes ligas corresponden a la representación de ICANN por regiones:

• Europa y África http://www.ripe.net
• Norte y Sur América http://www.arin.net
• Asia Pacifico http://www.apnic.net
• http://www.ripe.net

Ahora debemos buscar todos los dominios y subdominios que podamos encontrar. Podemos buscar tanto en Google como en la base de datos de whois para localizar los dominios así como el servidor de nombres al que esta asociado.

Lo primero que podemos hacer es identificar el responsable del dominio y su servidor de nombres asociado, esto nos sirve para comenzar a identificar segmentos de red, proveedores de servicios externos, redundancia en equipos, etc.

Desde una Terminal de un sistema *NIX podemos ejecutar la siguiente búsqueda:

slax ~ # whois itam.mx

DOMINIO: itam.mx

FECHA DE CREACION: 02-JAN-95
FECHA DE ULTIMA MODIFICACION: 05-JAN-05

ORGANIZACION: ITAM [itam1]
DOMICILIO: Mexico, D.F., Mexico

CONTACTO ADMINISTRATIVO: Uciel Fragoso Rodriguez [uciel]
DOMICILIO: Mexico, D.F., Mexico

CONTACTO TECNICO: Uciel Fragoso Rodriguez [uciel]
DOMICILIO: Mexico, D.F., Mexico

CONTACTO DE PAGO: Uciel Fragoso Rodriguez [uciel]
DOMICILIO: Mexico, D.F., Mexico

SERVIDOR PRIMARIO: turing2.itam.mx
IP PRIMARIO: 148.205.228.11

SERVIDOR SECUNDARIO: remo.itam.mx
IP SECUNDARIO: 148.205.228.17

SERVIDOR SECUNDARIO: name.roc.gblx.net

SERVIDOR SECUNDARIO: name.phx.gblx.net

Con la información obtenida en el ejemplo anterior, podemos apreciar lo siguiente:

• Nombre del contacto.
• Fecha de creación de dominio.
• DNS, de los cuales 2 son administrados por la organización y 2 por externos.

Cuando ya contamos con los servidores DNS de la organización podemos realizar peticiones directas a los mismos. A continuación muestro las diferentes tipos de consultas que podemos realizar:

• SOA (State of authority)- Muestra quien es el servidor DNS primario.
• NS (Name Server) Muestra quienes son los servidores DNS de un dominio.
• MX (Mail Exchanger) Muestra quien se encarga de entregar correo para un dominio.
• ANY (Any Query) Busca cualquier registro contenido en la zona.
• TXT (Text Query) Busca registros de texto.
• AXFR- (Zone transfer) Trae todos los registros almacenados en una zona DNS.
• A (Address). Muestra el registro para traducir nombre de host a direcciones IP.
• CNAME (Canonical Name). Se usa para crear nombres de hosts adicionales, o alias, para los hosts de un dominio.

Existen dos consultas claves que debemos realizar siempre, la ANY y la AXFR. Es importante mencionar que no todos los servidores DNS permiten búsquedas del tipo AXFR ya que es considerada una mala practica, este tipo de búsquedas deben ser restringidas solamente entre un servidor primario y uno secundario. ¿Que herramientas nos permiten realizar estas búsquedas?

• SamSpace
• Dig
• Host
• Nslookup
• Dsnwalk
• Etc.

En este caso utilizaremos dig para realizar las búsquedas.

- La búsqueda any nos permite conocer todos los equipos NS,MX,SOA, A de un dominio:

slax ~ # dig any @148.205.228.11 itam.mx

; <<>> DiG 9.3.1 <<>> any @148.205.228.11 itam.mx
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59063
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 7

;; QUESTION SECTION:
;itam.mx. IN ANY

;; ANSWER SECTION:
itam.mx. 600 IN A 148.205.228.219
itam.mx. 3600 IN A 148.205.148.5
itam.mx. 600 IN A 148.205.36.229
itam.mx. 600 IN A 148.205.133.22
itam.mx. 600 IN A 148.205.228.17
itam.mx. 600 IN A 148.205.52.10
itam.mx. 600 IN A 148.205.228.11
itam.mx. 600 IN A 148.205.40.4
itam.mx. 600 IN A 148.205.40.11
itam.mx. 600 IN A 148.205.228.27
itam.mx. 3600 IN NS artemisa2.itam.mx.
itam.mx. 3600 IN NS turing2.itam.mx.
itam.mx. 3600 IN NS remo.itam.mx.
itam.mx. 3600 IN NS name.phx.gblx.net.
itam.mx. 3600 IN NS name.roc.gblx.net.
itam.mx. 3600 IN SOA turing2.itam.mx. uciel.itam.mx. 2002068227 3600 600 1209600 3600
itam.mx. 3600 IN MX 10 stockton.itam.mx.
itam.mx. 3600 IN MX 10 malone.itam.mx.

;; ADDITIONAL SECTION:
artemisa2.itam.mx. 3600 IN A 148.205.40.11
turing2.itam.mx. 3600 IN A 148.205.228.11
remo.itam.mx. 3600 IN A 148.205.228.17
name.phx.gblx.net. 39355 IN A 206.165.6.10
name.roc.gblx.net. 56775 IN A 209.130.187.10
stockton.itam.mx. 3600 IN A 148.205.228.32
malone.itam.mx. 3600 IN A 148.205.228.6

;; Query time: 193 msec
;; SERVER: 148.205.228.11#53(148.205.228.11)
;; WHEN: Mon Aug 7 14:28:11 2006
;; MSG SIZE rcvd: 506

- La búsqueda axfr es un poco diferente a la any ya que no permite hacer un intercambio de Zonas de transferencia. Esto quiere decir que nos enviara toda su zona con la cual podremos tener todos los nombres de los equipos registrados en el dominio.

slax ~ # dig axfr @148.205.228.11 itam.mx

; <<>> DiG 9.3.1 <<>> axfr @148.205.228.11 itam.mx
; (1 server found)
;; global options: printcmd
itam.mx. 3600 IN SOA turing2.itam.mx. uciel.itam.mx. 2002068242 3600 600 1209600 3600
itam.mx. 3600 IN NS artemisa2.itam.mx.
itam.mx. 3600 IN NS turing2.itam.mx.
itam.mx. 3600 IN NS remo.itam.mx.
itam.mx. 3600 IN NS name.phx.gblx.net.
itam.mx. 3600 IN NS name.roc.gblx.net.
itam.mx. 3600 IN MX 10 stockton.itam.mx.
itam.mx. 3600 IN MX 10 malone.itam.mx.
0r3dac14d.itam.mx. 1200 IN A 148.205.197.15
eventos.itam.mx. 3600 IN CNAME ddip.itam.mx.
www.eventos.itam.mx. 3600 IN CNAME ddip.itam.mx.
exalumnos.itam.mx. 3600 IN CNAME ddip.itam.mx.
www.exalumnos.itam.mx. 3600 IN CNAME ddip.itam.mx.
exalumnos_conta.itam.mx. 3600 IN CNAME phobos.itam.mx.
executivemba.itam.mx. 3600 IN CNAME phobos.itam.mx.
www.executivemba.itam.mx. 3600 IN CNAME phobos.itam.mx.
expo-itam.itam.mx. 1200 IN A 148.205.220.21
extension.itam.mx. 3600 IN CNAME titan2.itam.mx.
edit.extension.itam.mx. 3600 IN CNAME titan2.itam.mx.
etc
etc
etc

Los resultados anteriores nos permiten determinar muchas cosas relativas al direccionamiento así como los subdominios de la organización de quien estamos recopilando información.

En el caso del dominio ITAM, se puede determinar que su bloque de red es 148.205.228.X y además la identificación del tipo de nombres que utilizan para sus equipos.

Otra forma es hacer la búsqueda es mediante google:

inurl:itam.mx

La búsqueda anterior nos permite conocer subdominios del itam.mx

Bloques de red

Con la información encontrada anteriormente ya es posible determinar los bloques de red que tiene una organización, y conocer si algunos servicios están hosteados.

Sigamos el rastro del dominio iss.net

slax ~ # whois iss.net

Registrant:
Internet Security Systems, Inc.
6303 Barfield Rd
Atlanta, GA 30328
US

Domain Name: ISS.NET

Administrative Contact, Technical Contact:
Internet Security Systems Inc. iss-dnsadmin@ISS.NET
6303 BARFIELD RD NE
ATLANTA, GA 30328-4233
US
(404) 236-2600 fax: (404) 236-2614

Record expires on 29-Jun-2012.
Record created on 30-Jun-1994.
Database last updated on 10-Aug-2006 12:17:24 EDT.

Domain servers in listed order:

EHECATL.ISS.NET 209.134.161.10
SFLD-NS1.NETREX.COM 207.231.129.132

Con la información anterior podemos determinar que el servidor primario de DNS es administrado por la organización. Ahora realizaremos una búsqueda ANY.

slax ~ # dig any @209.134.161.10 iss.net

; <<>> DiG 9.3.1 <<>> any @209.134.161.10 iss.net
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65516
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;iss.net. IN ANY

;; ANSWER SECTION:
iss.net. 60 IN SOA ehecatl.iss.net. iss-dnsadmin.is s.net. 2006080802 3600 1800 604800 3600
iss.net. 60 IN NS sfld-ns1.netrex.com.
iss.net. 60 IN NS ehecatl.iss.net.
iss.net. 60 IN MX 10 colo-mx1.iss.net.
iss.net. 60 IN MX 10 sfld-mx1.iss.net.
iss.net. 60 IN MX 5 atla-mx1.iss.net.
iss.net. 60 IN A 209.134.161.35

;; ADDITIONAL SECTION:
ehecatl.iss.net. 60 IN A 209.134.161.10
sfld-ns1.netrex.com. 3600 IN A 207.231.129.132
atla-mx1.iss.net. 60 IN A 209.134.161.6
colo-mx1.iss.net. 60 IN A 12.129.100.18
sfld-mx1.iss.net. 60 IN A 207.231.129.133

;; Query time: 353 msec
;; SERVER: 209.134.161.10#53(209.134.161.10)
;; WHEN: Mon Aug 7 15:55:37 2006
;; MSG SIZE rcvd: 300

De la información de la búsqueda podemos determinar que existen dos bloques diferentes de red que responden a equipos tipo A del dominio principal los cuales son:

• 209.134.161.X
• 207.231.129.X

Cada uno de ellos de diferentes ISP, con lo cual podemos comenzar a realizar un mapa de la arquitectura de Red de la organización.

Lo que se hará a continuación es resolver cada unos de los equipos en los diferentes bloques de red, para de esta manera identificar los equipos de la organización.

¿Qué herramientas pueden ayudarnos a esto?

• Nmap
• Host
• Nslookup
• Etc.

Si deseamos realizar la tarea con nmap, el comando que se sugiere utilizar es el siguiente:

‘nmap -sL -P0 –dns-server DNS Red –R’

>>nmap -sL -P0 –dns-servers 209.134.161.10 209.134.161.1/24

Starting Nmap 4.01 ( http://www.insecure.org/nmap ) at 2006-12-04 16
Failed to resolve given hostname/IP: ûR. Note that you can’t use ‘/
e IP ranges
Host 209.134.161.0 not scanned
Host 209.134.161.1 not scanned
Host atla-ngw5-a-ext.iss.net (209.134.161.2) not scanned
Host atla-ngw5-b-ext.iss.net (209.134.161.3) not scanned
Host 209.134.161.4 not scanned
Host 209.134.161.5 not scanned
Host atla-mx1.iss.net (209.134.161.6) not scanned
Host lists.it-isac.org (209.134.161.7) not scanned

También es posible realizar la resolución de nombres utilizando ‘host’ y ‘perl’:

perl -e ‘for ($x=1;$x<=254;$x++){system “host 209.134.161.$x 209.134.161.10″}’

Using domain server:
Name: 209.134.161.10
Address: 209.134.161.10#53
Aliases:

Host 1.161.134.209.in-addr.arpa not found: 3(NXDOMAIN)
Using domain server:
Name: 209.134.161.10
Address: 209.134.161.10#53
Aliases:

2.161.134.209.in-addr.arpa domain name pointer atla-ngw5-a-ext.iss.net.
Using domain server:
Name: 209.134.161.10
Address: 209.134.161.10#53
Aliases:

3.161.134.209.in-addr.arpa domain name pointer atla-ngw5-b-ext.iss.net.
Using domain server:
Name: 209.134.161.10
Address: 209.134.161.10#53
Aliases:

6.161.134.209.in-addr.arpa domain name pointer atla-mx1.iss.net.
Using domain server:
Name: 209.134.161.10
Address: 209.134.161.10#53
Aliases:

Realizando la misma búsqueda sobre el otro servidor de dominio y el otro segmento de red nos da el siguiente resultado:

perl -e ‘for ($x=1;$x<=254;$x++){system “host 207.231.129.$x 207.231.129.132″}’ | grep iss.net

5.129.231.207.in-addr.arpa domain name pointer sfld-ngw1a.iss.net.
6.129.231.207.in-addr.arpa domain name pointer sfld-ngw1.iss.net.
7.129.231.207.in-addr.arpa domain name pointer sfld-ngw1b.iss.net.
9.129.231.207.in-addr.arpa domain name pointer sfld-mss-fw1.iss.net.
11.129.231.207.in-addr.arpa domain name pointer sfld-mss-fw1.mss.iss.net.
12.129.231.207.in-addr.arpa domain name pointer sfld-mss-fw2.mss.iss.net.
18.129.231.207.in-addr.arpa domain name pointer sfld-perim1.iss.net.
19.129.231.207.in-addr.arpa domain name pointer sfld-perim2.iss.net.
24.129.231.207.in-addr.arpa domain name pointer sfld-raw1.iss.net.
25.129.231.207.in-addr.arpa domain name pointer sfld-raw2.iss.net.
68.129.231.207.in-addr.arpa domain name pointer sfld-netrwww.mss.iss.net.129.231.207.in-addr.arpa.
133.129.231.207.in-addr.arpa domain name pointer sfld-mx1.iss.net.
134.129.231.207.in-addr.arpa domain name pointer sfld-mx2.iss.net.
196.129.231.207.in-addr.arpa domain name pointer soudom001.iss.net.
197.129.231.207.in-addr.arpa domain name pointer soumaiexcp01.iss.net.
198.129.231.207.in-addr.arpa domain name pointer soumaiwebp01.iss.net.
199.129.231.207.in-addr.arpa domain name pointer bkup-sfld01.iss.net.
200.129.231.207.in-addr.arpa domain name pointer soufil002.iss.net.
201.129.231.207.in-addr.arpa domain name pointer souprn001.iss.net.
202.129.231.207.in-addr.arpa domain name pointer soubacnbup01.iss.net.
203.129.231.207.in-addr.arpa domain name pointer sfld-rad2.iss.net.
204.129.231.207.in-addr.arpa domain name pointer sfld-remedy1.mss.iss.net.
205.129.231.207.in-addr.arpa domain name pointer sfld-fax1.iss.net.
211.129.231.207.in-addr.arpa domain name pointer sfld-ccur.iss.net.
212.129.231.207.in-addr.arpa domain name pointer soudom002.iss.net.
213.129.231.207.in-addr.arpa domain name pointer soumaipmfp01.iss.net.

De esta manera podemos identificar los segmentos de red de una organización así como los equipos que cuentan con un registro en el servidor de dominio.

Para aquellas personas a las que no les guste trabajar en línea de comandos, BiDiBlAH de Sensepost es una herramienta que nos permite realizar estas búsquedas de manera automatizada. A continuación se muestran una serie de pantallas utilizando la herramienta mencionada anteriormente.

La información de nombres de dominio y bloques de red brinda a los hackers (o penetrations testers) mucha información para la creación de la arquitectura de red de la organización, además de que constituye el preámbulo para la detección de servicios públicos de la misma.

La siguiente parte del artículo, se enfocara a la detección ser servicios Públicos donde se trataran cosas desde nombres de host hasta escaneos de puertos, así como la obtención de versiones de servicios.

En la vida cotidiana de hacker o un penetration tester la obtención de la mayor cantidad de información del objetivo (u cliente) es una tarea sumamente necesaria para poder definir el ámbito en que será analizado (atacado) el objetivo, las condiciones de las pruebas a realizar y la medición de los tiempos que tomaran los ataques. Esto nos da un perfil completo de las políticas de seguridad del objetivo a atacar. Seguir el rastro es, con frecuencia, la tarea mas ardua a la hora de determinar la filosofía de seguridad de una empresa, sin embargo, es una de las tareas más importantes.

Entre la información que debemos recolectar se encuentra:

• Información descubierta en fuentes publicas.
• Nombres de dominio.
• Segmentos de red
• Servicios públicos ofrecidos.
• Arquitectura de los sistemas visibles.

Aunque muchas técnicas de rastreo de información son muy parecidas resulta muy difícil dar una guía paso a paso para efectuar el seguimiento a esta información. El objetivo en este artículo es enumerar los pasos básicos que se pueden utilizar en la mayoría de los casos. Es importante mencionar que los pasos no son consecutivos, ni lineales, ni únicos; la información recabada en cada punto a tratar puede ser utilizada o necesaria para otros. No se darán ejemplos de todas las técnicas ni tipo de información buscada, pero si se dejaran las bases para dejar volar la imaginación y crear otros caminos.

La mayoría de las pruebas o tareas a realizar son casi indetectables por los administradores de red ya que muchas son búsquedas de información sin tocar la infraestructura del objetivo. Es importante mencionar que algunas de las técnicas mostradas a continuación (como escaneos de puertos) son ilegales en muchas partes del mundo a menos que se cuente con permiso explicito de la organización.

El articulo fue pensado para salir en una sola entrega pero por le tamaño del mismo sera liberado en diferentes articulos mas pequeños.

Información descubierta en fuentes publicas ( Inteligencia competitiva).

Toda organización moderna tiene presencia en Internet, la gran cantidad de información que puede ser obtenida en Internet es increíble. ¿Que tipo de información es posible encontrar?:

• Ubicaciones físicas y logias.
• Compañías o entidades relacionadas.
• Noticias.
• Números telefónicos.
• Contactos de la compañía.
• Información mal intencionada o de desprestigio.
• Directivas de seguridad.
• Archivos de configuración.
• Currículos de personal.
• Arquitecturas de red.
• Tecnologías utilizadas.
• Etc…Todo es posible solo imagínate y buscaló.

Lo primero que debemos recordar es que Google es nuestro amigo, y en muchas ocasiones todo lo sabe, sin embargo no es la única fuente donde buscar información. A continuación listo algunos de los sitios que pueden contener información valiosa para nuestro objetivo:

• Google
• Usenet
• Groups.google
• http://archives.neohapsis.com
• NIC ( O su representante dependiendo la localidad donde nos encontremos)
  • Europa y África http://www.ripe.net
  • Norte y Sur América http://www.arin.net
  • Asia Pacifico http://www.apnic.net
  • http://www.ripe.net
• Edgar Database
• La pagina de la compañía.
• Paginas que hablen mal de compañías:
  • www.apestan.com
  • www.f u c k edcompany.com
  • www.dotcomtod.de
• Buscar en base de datos de ofertas de trabajo en línea:
  • OCC Mundial
  • Lucas5
  • Laborum
• Fuentes P2P como kazaa,Gnutella así como sitios warez

Casi siempre nuestras búsquedas de información comienzan con Google, por su versatilidad y gran poder de búsqueda. Google cuenta con palabras claves que nos permiten realizar búsquedas mas especializadas de información a continuación mencionare algunas de ellas:

• intitle ( Nos permite realizar búsquedas en los títulos de las paginas web)
• inurl ( Nos permite realizar búsquedas en los URL de las paginas)
• filetype ( Nos permite definir las búsquedas de ciertos tipos de archivos)
• site ( Nos permite definir la búsqueda en sitios concretos)
• cache ( Realizamos búsquedas en e cache de google y aun que las paginas ya no existan mas podremos encontrar información valiosa)
• info ( Información relacionada con nuestra búsqueda)
• autor ( Buscar información que ha publicado un autor en especifico)
• group( Búsqueda en grupos de google)
• insubject ( Búsqueda de mensajes en su Asunto)

La manera de usarlo es: ‘operador avanzado:lo que buscamos’. Un buen ejemplo para mostrar es el siguiente:

intitle:”index of” + ebooks +”Google Hacking”

La combinación anterior nos permitirá buscar el Libro Google Hacking donde podemos aprender mas de como utilizar google para nuestros propósitos. ( Recuerda siempre comprar los libros que utilices)

Otro buscador donde podemos encontrar mucha información es : http://www.kartoo.com/

kartoo es un innovador buscador que nos permite generar mapas de la información que buscamos. A que me refiero con mapas, ver de una manera gráfica donde se menciona la información de la busqueda realiza a continuación muestro una imagen de una búsqueda de la palabra darkslaker

Como se puede notar la palabra se relaciona con listas de seguridad informática, asi como otros seudonimos como Rienzi.

Con este tipo de búsquedas podemos encontrar la relaciones de organizaciones, con personas.

Otro buen lugar para buscar información de organizaciones es la busqueda de Curriculums o vacantes en las organizaciones a continuación muestro un ejemplo de una vacante:

Nivel de Estudios: Ingeniero en Sistemas Computacionales, enfocado a telecomunicaciones
Experiencia: Mínima de 2 - 3 años comprobables en puesto similar
Amplio dominio de Sistemas Operativos
Alto nivel en Administración y configuración de redes
Alto nivel en Redes de Voz/Datos (TCP/IP, routing, firewall, QoS, DNS)
Alto nivel de conocimiento en Hardware orientado a Telecomunicaciones
Análisis, diseño e implementación de esquemas de alta seguridad
Amplio dominio de Sistemas Operativos Windows NT, 200X Server
Amplio dominio de Conmutadores y PBX
Alto grado de resposabilidad y compromiso
Trabajo bajo presión y metas Disponibilidad de horario Disponibilidad Inmediata
Alta capacidad de aprendizaje rápido
Inglés técnico mínimo: 80% Conocimientos de Citrix y Cisco Indispensable
EstabilidadAgradable ambiente laboral 

La información que se muestra en color rojo, nos puede brindar un mapa de las tecnologías que utiliza la organización.

Un par de lugares mas que nos puede ayudar a conocer las tecnologías de una organización es :

http://www.archive.org La cual nos brinca un histórico de como eran las paginas web, a medida del tiempo, con esto podemos crear un mapa de las tecnologías en sitios web.

http://www.netcraft.com Nos permite una mirada de un historico de las técnologias en servidores Web y provedores de servicios en una organización, la siguiente imagen nos muestra un historico de www.nimrod.com.mx

La información que podemos encontrar me manera publica es inmensa y las posibilidades se extiende con tiempo y deseos de encontrarla.

En la siguiente entrega del articulo se mostrara como identificar nombres de dominio de una organización así como los segmentos de red públicos de la misma y sus ISP.