Os dejo este snnifer para que lo probeis ;que veo que a la gente le gusta esto de los snnifer
Código: Seleccionar todo
Para Windows, la única herramienta que vale la pena, se llama NetWork Miner. Es una herramienta bastante interesante, ya que, además de la extracción de datos, es capaz de realizar tareas de fingerprinting sobre los paquetes de datos para averiguar, por ejemplo, el sistema operativo que envía o recibe paquetes. Su funcionamiento se basa en las bases de datos que utilizan diversas herramientas de auditoría, como por ejemplo, NMap
COsas que podeis visualizar con este programa:
* Permite la identificación de sistemas operativos y alguna información adicional sobre los hosts que detecta (OS Fingerprinting)
* Reconstrucción de archivos - Supongamos que tenemos un archivo capturado en wireshark (con extensión pcap) al abrirlo en NetworkMiner, reconstruira los archivos que se encuentren presentes en la captura.
* Extracción de imagenes - Como en el caso anterior, si tenemos una captura y la abrimos en NetworkMiner, reconstruira todas las imagenes presente que hay en la captura.
* Identificación de credenciales - Identificara usuarios y passwords dentro de una captura.Posdata : lo he analizado y esta libre de virus.
Hay masssssss pero yo aporto este
Otro a tener en cuenta es el Wireshark
Código: Seleccionar todo
Algo mas de informacion sobre fingerprinting
* Finderprinting.
El fingerprinting de un sistema operativo ya ha sido sacado con otros programas como queso o nmap. Estas utilidades operan con el principio de que todos las pilas IP de los sistemas operativos tienen sus propias indosincracias. Más concretamente, cada sistema operativo responde de forma diferente a los paquetes corruptos. Todo lo que tenemos que hacer es una base de datos de cómo responda cada sistema a los paquetes que acabamos de mencionar. Por lo tanto, para saber el sistema operativo de un determinado servidor le enviamos una serie de paquetes. Depende de cómo responda lo comparamos con la base de datos que tenemos. Nmap de Fyodor es un programa que esa este método. Él también ha escrito un documento detallado hablando sobre ello.
* Las firmas.
Hay cuatro partes en el TCP que deberemos revisar para determinar el fingerprinting de un sistema operativo (también podemos usar otras). Las firmas son:
1. TTL: ell tiempo de vida de un paquete que sale de la máquina seleccionado por el sistema operativo.
2. Window size: Qué tamaño selecciona el sistema para el paquete.
3. DF: Si el sistema usa el bit no fragmentado.
4. TOS: Si el sistema operativo ha seleccionado el tipo de servicio (TOS) y dónde.
Analizando estos factores de un paquete, debes ser capaz de saber el sistema operativo del servidor. Este sistema, no es 100% seguro y es más efectivo en unos sistemas que en otros. De todas formas, mirando más firmas y combinando la información aumentarán tus posibilidades de tener éxito identificando el sistema remoto. Un ejemplo sería la mejor forma de explicarlo. Más abajo tenéis una traza capturada por un sniffer de un sistema que ha enviado un paquete. Este sistema, está intenando ejecutar el exploit para mountd contra nuestro sistema, así que queremos saber más acerca de él. No queremos lanzar un finger o un nmap a la máquina porque no dejaría fuera. Por el contrario, vamos a estudiar esa información de forma pasiva. La firma ha sido capturada usando snort, nuestra herramienta pasiva en este ejemplo.
04/20-21:41:48.129662 129.142.224.3:659 -> 172.16.1.107:604
TCP TTL:45 TOS:0×0 ID:56257
***F**A* Seq: 0×9DD90553
Ack: 0xE3C65D7 Win: 0×7D78
Basándonos en nuestro criterio de las 4 de antes:
1. TTL: 45
2. Window size: 0×7D78 (ó 32120 en decimal)
3. DF: El bit para no fragmentar el paquete está activo.
4. TOS: 0×0
Entonces comparamos esta información con la base de datos de firmas. Primero, miramos el TTL usado por el host remoto. Por la traza del sniffer anterior puedes ver que el TTL está en 45. Esto nos dice que hay 19 saltos antes de llegar a nosotros. Así que el TTL original es de 64. Basándonos en esto, parece que este paquete se envió desde un GNU/Linux o FreeBSD (aunque se tienen que añadir más firmas a la base de datos). Hemos confirmado el TTL haciendo un traceroute al host. Si eres consciente de que el host remoto puede detectar el traceroute, puedes asignar el tiempo de vida de tu traceroute (por defecto 30 saltos) para que sean uno o dos menos que el host destino (opción -m). Por ejemplo, en este caso haremos un traceroute al host remoto usando solo 18 saltos (traceroute -m 18). Esto nos dará información del camino que sigue (incluyendo su proveedor) sin tocar al host remoto. Para más información sobre los TTL, revisa “ Research Paper on Default TTL values“.
El próximo paso es comprar el “window size”. Hemos visto que el “window size” es otro dato muy atractivo, especialmente en cómo se usa y cómo cámbian a lo largo de una comunicación. En la firma anterior, vimos que es 0×7D78 un “window size” por defecto únicamente usado por GNU/Linux. Además, GNU/Linux, FreeBSD y Solaris tienden a mantener el mismo en una comunicación (como este hizo). También, los routers Cisco (incluído mi 2514) y el “window size” de Microsoft Windows NT cámbian constantemente. Hemos descubierto que es más fácil en la fase inicial del 3-way-handshake (a causa del lento inicio de las conexiones TCP). Para más información acerca de “Window Size” revisa: Stevens, “TCP/IP Illustrated, Volume 1? Chapter 20.
La mayoría de los sistemas tienen activo el bit DF, de valor limitado. Sin embargo, esto hace más fácil identificar los sistemas que no esan este bit activo (como por ejemplo SCO y OpenBSD). Después de muchas pruebas, también determinamos que TOS también es un valor limitado. Esto parece estar más basado en las sesiones que en el sistema operativo. En otras palabras: no hay mucha información en el sistema operativo para determinar el TOS, salvo el usado por el protocolo. Definitivamente, TOS requiere más pruebas.Así que basándonos en la información anterior, más concretamente TTL y Window Size, puedes comparar la información con la tabla de firmas para determinar el sistema operativo (en nuestro caso GNU/Linux 2.2.X).
Ten siempre presente que, como en el fingerprinting activo, el pasivo tiene limitaciones. Primero, las aplicaciones que crean sus propios paquetes (como nmap, hunt, nemesis, etc) no usan las mismas firmas que el sistema operativo. Segundo, es relativamente simple para un host ajustar el TTL, el Window Size, o el TOS. Por ejemplo, para cambiar el valor por defecto del TTL:
Solaris: ndd -set /dev/ip ip_def_ttl ‘numero’
Linux: echo ‘numero’ > /proc/sys/net/ipv4/ip_default_ttl
NT: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
De todas formas, combinando un conjunto de paquetes y firmas, en este caso TTL y Window Size, puedes aproximarte mucho al host remoto.
