martes, 14 de enero de 2014

Caso práctico de uso de un AP falso

En la pasada entrada vimos cómo instalar un punto de acceso falso (en adelante rogue AP) sin airbase. Aprovechando que ya lo tenemos montado, vamos a ver un caso práctico de cómo aprovechan estos ap para nuestra desgracia...

Imagina que estas en la universidad, una cafetería, la casa de tu madre y no dispones de una red inalámbrica "segura". O mejor, ¿cuántos amigos tienes que en dichos establecimientos urgan en su celular para encontrar una red abierta??. O para más inri, nuestro propio móvil nos avisa de que existen redes abiertas disponibles a nuestro alcance...

Claro está, que nos sentimos seguros puesto que disponemos de HTTPS que cifra todas nuestras comunicaciones importantes o, mejor dicho, desde hace un tiempo los protocolos que viajaban en texto plano como http, smtp, ftp, pop se les ha añadido una capa adicional de protección: SSL (Secure Sockets Layer) o protocolo de capa de conexión segura, un adicional al protocolo el cual trabaja con certificados y son utilizados en los protocolos que se mencionaron antes.

Vale, hasta aquí bien... ¿Qué nos puede pasar? ¿quién se va a poner a destripar nuestras conexiones, aparte cifradas (con el trabajo que eso puede suponer)? Acepto webstart como animal acuático....conectando.

Es justamente aquí donde el atacante (en este caso pasivo) hace uso de su Rogue AP y de otra herramienta llamada ssltrip.

Ssltrip no es ni más ni menos que un proxy transparente que reemplaza todas las peticiones HTTPS de una página web por HTTP.

Veamos como la complicación del ataque es desmesurada...

La víctima

Hemos quedado que hemos tenido la desgracia de conectarnos a una red que no conocemos, detrás de la cual hay un señor que se aburre mucho y, por ejemplo, nos disponemos a enviar un mail a nuestra novia...

Veamos qué pasa en la máquina del atacante cinco minutos antes:

Levantamos nuestro rogue AP con el script que confeccionamos en la entrada anterior.

Pasamos a la fase dos del ataque, la de "y se van a poner a descifrar mi conexión si tiene que ser complicadísimo" si en efecto "mu complicao"...

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000

sslstrip -l 10000 -a -w captura.cap


Ya está... complicadísimo llevar a cabo este ataque, incluso para más comodidad podemos implementar estas líneas en un script que llamaremos setupsslarip.sh... levantaremos nuestro falso AP y sslstrip al unísono:

  
Veamos cómo se desarrollan los acontecimientos:


 La víctima se conecta a nuestro AP y, como hemos mencionado antes, se conecta al servicio de Gmail y escribe un mensaje a su novia... ¡¡¡Bingo!!! Miramos el archivo captura.cap y entre muchísima información así a vote pronto nos llama la atención la siguiente línea:



Tras conectarse con su móvil Android 4.1.2 podemos ver toda su navegación e incluso el login en Gmail....

Si combinamos esta técnica "tan compleja" con otras que hemos visto estas semanas (que tampoco suponen un trabajo desmesurado) podemos reventar cualquier resquicio de privacidad de nuestra víctima...



Un saludo!!!! y portence bien :P 

viernes, 10 de enero de 2014

¿Se puede Dosear el WhatsApp de alguien?


Hace no demasiado tiempo se generó una buena polémica con el servicio de Apple iMessage al descubrirse que existían formas de fastidiar a los usuarios con diferentes ataques para hacer Spam y Denegación de Servicio. La ventaja para el atacante de Apple iMessage era que podrían utilizarse cuentas no necesariamente asociadas a números de teléfonos, y automatizar el ataque desde equipos Mac OS X con sencillos scripts. Los ataques para hacer un D.O.S. eran tan sencillos como hacer mensajes muy largos, o costosos de renderizar, haciendo uso de codificaciones complejas como Zalgo.


Figura 1: Mensajes D.O.S. para Apple iMessage enviado en Zalgo

Como Apple no tenía la opción de bloquear contactos en iOS 6 - fue introducida en iOS 7 -, decidió poner un sistema antispam bastante curioso: Enviar un correo electrónico a Apple para decir quién te estaba spameando o haciendo D.O.S. por Apple iMessage para que ellos lo comprobaran y tomaran medidas.


Como Apple iMessage y WhatsApp son similares, decidí comprobar si esto era posible hacerlo también de alguna forma en la popular app de mensajería. Sí, sé que todo el mundo quiere saber cómo espiar WhatsApp, pero supongo que el poder hacer un D.O.S. como broma a algún amigo pesado de esos que se pasa todo el día enviándote chorradas podría ser un buen escarmiento, así que perdí un poco de tiempo revisando estas cosas.


Figura 2: ¿Mensajes de tamaño ilimitado en WhatsApp? 

 
Lo primero fue mirar en Internet a ver si se conocían los límites de los mensajes de WhatsApp, y no resulta fácil encontrarlos, ya que todo el mundo parece pensar que son ilimitados. Evidentemente, el término ilimitado cuando hablamos con tecnología no parece demasiado científico, ya que al final siempre acaba apareciendo un límite.


 
Si miramos la estructura de una base de datos de WhatsApp con SQLite Data Browser, por ejemplo, se puede ver que los campos que almacenan el contenido de los mensajes son de tipo BLOB y TEXT, así que sólo hay que mirar el tamaño de estos tipos de datos en SQLite, que pueden consultarse en SQLite Limits.


Figura 3: Estructura de la tabla messages de WhatsApp

 
Como se puede ver, el tamaño de mensaje, salvo que la app haya establecido algún límite por el GUI puede ser mucho más grande que lo que un terminal pueda soportar con soltura, así que decidí probar a crear unos mensajes de gran tamaño a ver cómo se comportaban un iPhone, una Blackberry de las antiguas, y unos terminales con Android con los que contaba a mano.


Figura 4: Máximo tamaño para un BLOB. Para un TEXT el límite lo pone SQLITE_ MAX_SQL_LENGHT 

 
Para hacer el ataque se podría haber creado algún script un poco más elaborado haciendo uso de Yowsup, pero como la idea se me ocurrió mientras andaba tirado en el sofá, lo único que tuve que hacer es crear un mensaje copiando en el portapapeles una frase muy larga y pengándola sucesivas veces durante 10 minutos hasta que construí un mensaje lo suficientemente largo - por supuesto muy lejos de los límites de SQLite -.


BlackBerry con Whatsapp 2.11.528

Tras enviárselo a mi pobre Blackberry e intentar abrir la app de WhatsApp, el terminal se quedó bloqueado totalmente y tuve que reiniciarlo y borrar todos los datos antes de poder volver a abrir WhatsApp. La versión exacta de WhatsApp para BlackBerry que tengo instalada en este terminal, por si alguien quiere probar más, es la 2.11.528.

Android con WhatsApp 2.11.152

En los terminales Android, mi Nexus 4, mi HTC Desire y mi HTC One soportaron que la app de WhatsApp, versión 2.11.152, se quedara en un estado de thrashing que hace imposible su manejo. Es necesario esperar durante varios minutos a hacer cada nueva acción y conseguir eliminar el mensaje envenenado, o por supuesto, desinstalar la app y volver a instalarla.

La "gracia" de este mensaje es enviarlo a una lista de amigos que tengan Android, ya que cuando se visualiza la lista de conversaciones intenta hacer una previsualización de 20 caracteres y parece que para ello carga todo el mensaje en memoria del tirón sin hacer alguna lectura con RTRIM o similares. Aún así, la app entra en thrashing pero no cae, aunque los destinatarios con los que he probado han acabado todos desinstalando y volviendo a instalar la app.

iPhone 5 con iOS 7

El que mejor resultado obtuvo fue el terminal iPhone 5, que aunque iba a tirones, podía manejarse con relativa facilidad y conseguir borrar el mensaje, lo que hace suponer que la app de iOS esté mejor diseñada y cuente con algún control a la hora de manejar límites en mensajes de gran tamaño. 

La app de iOS es la que mejor parada sale, bloqueándose durante unos instantes al recibir, pero luego al hacer scroll la app - aunque da algún tirón - consigue moverse sin bloquearse demasiado. Creo que WhatsApp para iOS tiene algún limite de mensaje a la hora de manejarlos por el GUI que Android y Blackberry no tienen.

Con estas sencillas pruebas se puede ver que sí que parece posible hacer un DOS a WhatsApp y molestar a los usuarios normales de este sistema, y que tanto los detalles sutiles de la implementación de las apps en las diferentes arquitecturas, como los sistemas operativos y la calidad del hardware en el que corran, tienen importancia a la hora de diseñar un sistema robusto. De todas formas, si te toda un amigo "guasón" que te hace estas cosas, lo más fácil es que le bloquees en WhatsApp, que se puede hacer fácilmente.


Saludos y.... ¡Buen año! ...


Autor: Pau González

miércoles, 8 de enero de 2014

Un Redirect en Facebook para hacer Phishing a Facebook


A través de Twitter pude ver un mensaje de Jonathan Funes (@xfunex) que aludía a un No-Bug de Facebook. Es decir, a algo que él consideraba un bug pero que tras haber contactado con el equipo de seguridad de la red social por excelencia, le habían dicho que eso no era un bug, algo similar a lo que le pasó a otro investigador de seguridad con una "característica" que le permitió cambiar un estado del propio Mark Zuckerberg.

Como me interesaba el tema le pedí más información, y me pasó una pequeña explicación en vídeo que os paso describir. En este caso se trata de algo bastante sencillo de reproducir, así que puedes probarlo tú mismo con tu cuenta de Facebook. La idea es aprovechar un Open-Redirect de Facebook para hacer un ataque de Phishing bastante convincente a la propia Facebook.

Paso 1: Créate una mensaje privado que solo puedas ver tú con un enlace a cualquier web que quieras usando el enlace al link de redirección que puedes ver en la imagen. Lo único que necesitas es poner la dirección al final de la URL. En este caso, cuando alguien haga clic en ese enlace irá a la página de Google.com

Figura 1: Creando un estado que publique el link de redirección a Google.
El dominio del enlace de publicación aparece como www.facebook.com


Como se puede ver, automáticamente aparece que el dominio al que apunta ese enlace es a www.facebook.com, pero realmente es un hiperenlace que lleva a Google.com sin mostrar ningún mensaje de alerta.

Paso 2: Edita el título de la web para poner algo significativo, en este caso yo no me he complicado y he puesto que es un enlace de www.facebook.com, para que coincida con el dominio de publicación del enlace que Facebook creó antes.

Figura 2: Cambiando el título del enlace publicado

Paso 3: Borra el enlace original y pon textos sugerentes que inciten a los que lo vean a pulsar sobre él. Aquí llega la parte de ingeniería social necesaria para conseguir el call-to-action de las personas que lo vean.

Figura 3: Poniendo textos sugerentes en la publicación del phishing

Paso 4: Publica el estado. Como se puede ver, queda bastante aparente y parece que es un enlace a una web de Facebook.

Figura 4: El enlace publicado parece una página de Facebook

Paso 5: Sin embargo, como se puede ver en el enlace, el hipervínculo es a Google.com y navegará a esa dirección sin mostrar ninguna alerta.

Figura 5: El enlace llevará a Google.com sin dar ninguna alerta

En este ejemplo yo he utilizado un destino que llama mucho la atención, como es Google.com, pero si alguien quisiera hacer un ataque dirigido a uno de sus seguidores podría elegir un dominio en el que se simulara la página de Facebook y pidiera el usuario y la contraseña de Facebook para robársela.

En el vídeo de la demostración, Jonathan Funes usa un BeeF para infectar con un JavaScript malicioso la sesión del usuario - algo similar a lo que hicimos con la JavaScript Botnet -, pero lo más recomendable sería utilizar SET con Metasploit para conseguir un efecto de Phishing perfecto que pudiera ponerse en cualquier dominio o subdominio que pueda engañar a la víctima.



Figura 6: Explotación del Open-Redirection en Facebook 


Ten cuidado con estas cosas, porque parece que de momento Facebook no piensa corregir o añadir alguna protección extra a esta característica de compartición de enlaces y uso del Open-Redirect que tienen implementado, así que atento para no caer en esquemas de phishing porque te hayas fiado en el dominio de publicación del enlace.



Fuente

Cicada 3301: quizás el puzzle más misterioso y elaborado de Internet


Las cigarras desaparecen totalmente durante largos períodos, para volver a aparecer en gran número - increíblemente - sólo en los años que contienen números primos...

Cicada 3301 (en español Cigarra 3301) es el nombre de la misteriosa organización que el 5 de enero de 2012 publicó en el foro de 4chan una imagen con el siguiente texto sobre fondo negro:


“Hola. Estamos buscando a individuos sumamente inteligentes. Para encontrarlos hemos concebido una prueba. Hay un mensaje oculto en esta imagen. Encuéntralo y te llevará por el camino hacia nosotros. Esperamos con ansias conocer a los pocos que llegarán al final del camino. Buena suerte.”

Así dio comienzo lo que muchos consideran el "más elaborado y misterioso puzzle de la edad de Internet", una maratoniana serie de pruebas y retos virtuales sobre seguridad, criptografía y esteganografía que han llevado a sus participantes a compartir pistas y verse inmersos en referencias a poemas, sitios en la deep web, numerología maya, música clásica, ingeniería inversa, etc... además de pistas físicas dejadas en coordenadas rastreables vía GPS de 10 ciudades distribuidas por todo el mundo que hacen que Cicada 3301 parezca tratarse de una organización compleja y con medios...


¿Quiénes son realmente? Algunos suponen que se trata de la mismísima NSA o la agencia de espionaje británica MI6. 

Otros dicen que detrás está Google o Microsoft. Otros piensan que podría ser un colectivo hacker o algún grupo con fines nefastos.....


¿Cuáles son realmente sus intenciones? ¿De verdad están buscando a los mejores para reclutarlos? 


Sólo los que consigan resolver todos los puzzles podrán averiguarlo... o no, quién sabe.

En 5 de enero de 2013, justo un año después, hubo una segunda ronda. ¿Habrá una tercera ronda también este domingo? Pronto lo sabremos...


Referencias:

- Cicada 3301 Wikipedia

- Uncovering Cicada Wiki  

- Cicada 3301: The most elaborate puzzle of the internet age
 
- Cicada 3301: ¿el secreto mejor guardado del Internet? 

- Online puzzle has world’s codebreakers baffled
 
- Cicada 3301: the mystery keeping cryptologists awake at night 


Fuente

miércoles, 25 de diciembre de 2013

¡Feliz navidad!

perl -e '$n="\e[0;40;32m";for(1..10){print"\ec$n\n".$"x(15)."\e[1;35mY$n" .$"x15;for(1..8){print$/.$"x($a=16-$_);$c=int rand($d=2*$_);for(2..$d){$f=31+int rand(3);print($_-$c?"X":"\e[$f;1m*$n")}print$"x$a}print $/.$"x(31)."\e[0m\n".$"." Merry Xmas !!!".$/x2;select$q,$q,$q,0.5}'

Latch está integrado en Recover Messages


Actualmente Recover Messages, el servicio en cloud de recuperación de mensajes borrados de WhatsApp, se encuentra integrado con Latch. A partir de ahora, cualquier usuario podrá añadir una protección extra a los ficheros de WhatsApp que suba y esté analizando, protegiendo con un Latch el acceso a su cuenta del servicio.

Figura 1: Latch en el perfil de usuario de Recover Messages

Para configurarlo basta con ir a la zona de Account y seleccionar el botón de Latch para que aparezca el lugar donde se introduce el Token Temporal de Pareado. El resto, es ir a la app de Latch para iPhone o para Android, solicitar un Token Temporal de Pareado en la app y ponerlo ahí.

Figura 2: Cuenta de Recover Messages en la app de Latch para iPhone 

Cuando la app esté pareada se podrá restringir el acceso a la cuenta e incluso configurar un modo nocturno o un acceso controlado por OTP seleccionando que la cuenta esté Unlock pero con OTP. El funcionamiento del sistema está descrito en el artículo de "Latch: Cómo proteger las identidades digitales".

Figura 3: Configuración de Latch en un servidor FTP con comandos Site

En el caso de Recover Messages la integración se ha hecho con el SDK de Latch para .NET que puedes encontrar y utilizar de forma gratuita desde el área de developer de Latch. Allí hay SDKs para .NET, Java, PHP, Python, Ruby o C. Algo similar a lo que hemos hecho en Recover Messages hizo Alejandro Ramos "dab" (@aramosf) en Security By Default para integrar Latch en un servidor FTP haciendo las conexiones con unos sencillos scripts en Bash.

Figura 4: Area developer de Latch que da acceso a SDKs y Plugins

Si quieres probar estas navidades Latch a nivel de usuario puedes hacerlo también con 0xWord siguiente este tutorial, con Nevele Bank o animarte y proteger tu cuenta de Acens. Actualmente hay más de 100 sitios ya conectados con Latch, y tu puedes conectar tu sitio web si tienes un WordPress, un Joomla, un Drupal, un DotNetNuke o un PrestaShop con unos cuantos clics.

martes, 24 de diciembre de 2013

Qué deberíamos saber sobre Tcpdump (parte I)

En una entrada anterior un lector anónimo comentaba: "Muy interesante sería una entrada para desvelar los misterios de tcpdump. En muchos tutoriales solo se araña la superficie de esta herramienta"... lo intentaremos.


La verdad es muy difícil decir algo de esta herramienta que no esté ya dicho, pero voy a intentar hacer un artículo en varias entregas con lo que creo que se debería saber sobre este magnifico sniffer. 

En esta serie de entradas (creo que serán unas 3) intentaremos abarcar todos los aspectos de esta herramienta, por favor si me dejo algo decirlo.
 
Para quien no sepa lo que es Tcpdump echaremos mano de Wikipedia... a modo de introducción: Tcpdump es un herramienta en línea de comandos cuya utilidad principal es analizar el tráfico que circula por la red.

Permite al usuario capturar y mostrar a tiempo real los paquetes transmitidos y recibidos en la red a la cual el ordenador está conectado.
Tcpdump funciona en la mayoría de los sistemas operativos UNIX: Linux, Solaris, BSD, Mac OS X, HP-UX y AIX entre otros. En esos sistemas, tcpdump hace uso de la biblioteca libpcap para capturar los paquetes que circulan por la red. 


Existe una adaptación de T
cpdump para los sistemas Windows que se llama WinDump y que hace uso de la biblioteca Winpcap.


Tcpdump fue escrito originalmente en 1987 por Van Jacobson, Craig Leres y Steven McCanne. A día de hoy va por la versión: 4.5.1 / 1.5.2 release date: Nov 20, 2013/Dec 3, 2013.


Utiliza libpcap al igual que wireshark, snort, nmap, kismet, iftop, xplico y un largo etc...t ambién creada por estos tres "elementos", TCPdump puede ser a día de hoy unos de los sniffer mas usado en todo el mundo, por su versatilidad y potencia.

Dicho esto entramos en harina...
 

 
Instalación

Lo podemos descargar de la pagina oficial y compilarlo, aunque sería muy raro que no estuviese en los repositorios como paquete ya
precompilado para cualquier distribución. Debian, Ubuntu y derivadas lo pueden instalar con Apt,  Centos, Redhat con Yum, Opensuse con Yast,etc, etc.


Para mí, la mejor característica que tiene
Tcpdump es que esta diseñado para correr en la linea de comandos, esto nos ofrece posibilidades que otros sniffers igual de potentes no tienen, sacrificamos a priori vistosidad y intuición de manejo por versatilidad...


Tcpdump básico

Antes de comenzar conviene echarle un ojo a las opciones de esta herramienta un poco por encima. Más adelante las iremos viendo todas:
Con esto ya estamos preparados para nuestro primer comando:
  
tcpdump -i wlan0 -n   
 
Lo que le estamos diciendo a tcpdump es que capture el trafico con la tarjeta de red Wlan0 y que no resuelva los nombres de las interfaces de manera que nos saldrían las ip:

   
En realidad de momento esto no tiene ningún misterio: nosotros ordenamos y tcpdump obedece.

Vamos a ver otro ejemplo:
 
tcpdump -i wlan0 -n -c 1 -t -A 
  
En cristiano sería: -i captura el trafico por wlan0, -n no resuelvas los nombres, -c1 cuando hayas capturado 1 paquetes para, -t no muestres la hora, -A muestra los paquetes en ascII:

 
Otras opción que interesa ver sería -s len, donde "len" es la longitud que nos interesa. 

Por defecto Tcpdump sólo captura los primeros 68 bytes, lo cual es útil si lo único que se quiere son las cabeceras IP, TCP o UDP.  Sin embargo, en caso de estar esnifando protocolos como NFS se truncan los datos. En ese caso podemos ajustar la longitud de la captura a la MTU del medio que estamos usando con esta opción. Por ejemplo para capturar toda la trama ethernet podemos usar -s 1500 o -s 0.
  
Filtrado básico

A veces no nos interesa ver todos todos los paquetes que pasan por nuestra red y queremos ver los que salen de una determinada ip, o los de un puerto en concreto, etc.

Para esto Tcpdump viene bien armado, los modificadores básicos son 3:

Tipo:

Puede ser host, net o port, portrange indican respectivamente una máquina, por ejemplo host 192.168.1.1, una red completa, por ejemplo net 192.168,  un puerto concreto o un rango de puertos.

Veamos unos ejemplos:
 
Captura el tráfico que entre o salga del host 192.168.1.1 por el puerto 22:

tcpdump -i wlan0 host 192.168.1.11 port 22

Captura el tráfico con destino 192.168.1.11 por el rango de puertos del 22 al 25 pero no el 23:

tcpdump -i wlan0 host 192.168.1.11 and  portrange 22-25 and not 23
 
Dirección:

Especifica desde o hacia donde se va a mirar el flujo de datos. Tenemos src  (source) o dst (destination) y podemos combinarlos con or, and y not. Para el caso de de protocolos punto a punto podemos sustituir por inbound o outbound.

Más ejemplos:

Captura los paquetes que vienen de 192.168.1.11:

tcpdump -i wlan0 src 192.168.1.11 

Captura los paquetes que van hacia 192.168.1.11:

tcpdump -i wlano dst 192.168.1.11

Captura los paquetes con el origen 192.168.1.11 y destinado a 192.168.1.35:
 
tcpdump -i wlan0  src 192.168.1.11 and dst 192.168.1.35  
 
Por supuesto se pueden combinar con los modificadores anteriores:

tcpdump -i wlan0 -n -S src 192.168.1.11 and dst 192.168.1.35 and dst  port 25
  
Captura los paquetes de origen 192.168.1.11 con destino 192.168.1.35 con el puerto de destino 25.

Proto:

En este caso es el protocolo que queremos capturar: tcp, udp, icmp, rarp, ip, ip6, igrp, icmp6, igmp, etc, etc...

tcpdump -i wlan0 icmp and host 192.168.1.1
   
Seguro que me dejo infinidad de expresiones y combinaciones, todo lo anterior lo podemos escribir tanto con nombres de servidor, direcciones ip o direcciones mac... Como veis cuando hablé de versatilidad iba en serio.

Siguiendo con el tema del filtrado ....todavía podemos filtrar aun más y ser mucho mas quirúrgicos...

Filtrado (no tan básico) de FLAGS 
 
Imaginemos que queremos filtrar todos los paquetes que lleguen de una máquina a otra por un puerto determinado, que tengan el flag activo ACK (así dicho tan en frío casi suena a rollazo pero en el próximo tutorial veremos un par de ejemplos muy divertidos). 

Esto lo podríamos filtrar del siguiente modo (es un poco largo pero luego veremos como abreviarlo todo):

tcpdump -i wlan0  src host 192.168.1.10 and dst host 192.168.1.30 and port 22 and  -S -n  " tcp[13] & 16 == 16 "

Fijémonos ahora en la parte resaltada del filtro y veamos de dónde sale y qué significa.

Para ello debemos ver como es una cabecera tcp y dónde se sitúa la bandera ACK (esto mismo se puede hacer con otros protocolos como icmp, luego veremos cuanto puede dar de sí ésto...)


 
 
Como podemos ver, la bandera ACK está situada en el octeto número 13. De ahí sale el principio del filtro tcp[13].

Ahora miremos más de cerca... el octeto sería 0001000 si tuviese el flag ACK activo. Si pasamos esa situación de binario a decimal nos da 16 con lo cual podemos decirle a tcpdump que mire en la cabecera en el octeto 13 y si es igual a dieciséis que nos muestre esos paquetes ..." tcp[13] & 16 == 16 " 

¿Sencillo no?, imaginad... ¿qué no podéis filtrar con tcpdump?, ¿se puede ser mas quirúrgico?...

Otro ejemplo. Si queremos visualizar los paquetes  con  el syn ack activo el estado del octeto 13 sería 00010010 = 18 con lo cual el filtro es " tcp[13] & 18 == 18.

Bueno por hoy lo dejamos aquí, espero no haber aburrido y hasta la segunda entrada sobre Tcpdump...




Fuente