Kali Linux añade la opción de usar una contraseña de autodestrucción de los datos

Ayer se lanzó la versión 1.0.6 de Kali Linux y una de las características nuevas más interesantes es la 'Autodestrucción de emergencia de LUKS'.

La configuración de cifrado de disco completo con Kali es un proceso simple. El instalador de Kali incluye un proceso sencillo para crear particiones cifradas con LVM y LUKS. Una vez cifradas, el sistema operativo Kali requiere una contraseña en el arranque para que el sistema operativo pueda arrancar y descifrar la unidad, protegiendo así estos datos en caso de que el ordenador sea robado. La gestión de claves de descifrado y particiones se realiza mediante la utilidad cryptsetup.

Hace unos días pensaron añadir una opción "nuke" (o arma nuclear) para tener además una contraseña de arranque que destruiría, en vez de descifrar, los datos de la unidad. Para ello se ha adaptado un viejo parche de Juergen Pabel para cryptsetup que hace justamente eso, añade una contraseña de autodestrucción para cryptsetup, que cuando se utiliza, se eliminan todos los keyslots y hace que los datos de la unidad sean inaccesibles...

Ahora la opción luksAddNuke está disponible por defecto en la versión 1.0.6 de Kali. Si tenemos ya una instalación de Kali con LVM cifrado y una contraseña de descifrado, podemos añadir una adicional de autodestrucción con el siguiente comando:

root@kali:~# cryptsetup luksAddNuke /dev/sda5
Enter any existing passphrase:      (existing password)
Enter new passphrase for key slot:  (set the nuke password)

A partir de ese momento si confiscan tu equipo y te piden la contraseña para acceder a tus datos tienes un as en la manga...

Para más detalles echa un vistazo a http://www.kali.org/how-to/emergency-self-destruction-luks-kali

View the original article here

This post was made using the Auto Blogging Software from WebMagnates.org This line will not appear when posts are made after activating the software to full version.

Concurso Internacional de Código C Ofuscado (IOCCC): Ganadores de 2013

El Concurso Internacional de Código C Ofuscado o IOCCC - en inglés International Obfuscated C Code Contest - es un concurso que nació en 1984 y que, en cada una de sus hasta ahora 22 ediciones, ha premiado a los programas más llamativos (útiles y a veces poco útiles) cuyo código es ilegible, es decir, está ofuscado u oscurecido intencionadamente.

Aunque las reglas no son demasiado claras al respecto, para participar "basta" con presentar un programa completo y propio de menos de 4096 bytes con el objetivo de:

- Escribir el programa C más oscuro/ofuscado.
- Mostrar la importancia del estilo de programación, de una manera irónica.
- Forzar los compiladores de C con código inusual.
- Ilustrar algunas de las sutilezas del lenguaje C.
- Proporcionar un foro seguro para el código C más pobre :-)
 
Recientemente se han publicado los ganadores del 2013 por lo que os recomendamos echar un vistazo a su originalidad, donde encontraréis algunos tan curiosos como por ejemplo uno de una sóla línea capaz de reproducir sonidos con notación musical ABC, o un pequeño PC emulador/máquina virtual 8086 escrito en solo 4043 bytes de código:

2013 birken    use Tetris to paint a picture
2013 cable1    1-liner party of a US President
2013 cable2    OCR in quick brown fox ASCII art
2013 cable3    IBM PC emulator
2013 dlowe    ASCII spark line graph
2013 endoh1    SKI Combinator Calculus tool
2013 endoh2    JPEG quine that expands and inverts
2013 endoh3    play music with ABC notation
2013 endoh4    ASCII solid rotation
2013 hou    ray tracer
2013 mills    HTTP server ray tracing a timestamp
2013 misaka    horizontal or vertical file concat
2013 morgan1    X11 based Solar system simulator
2013 morgan2    X11 & ASCII domino matching game
2013 robison    multi-precision arithmetic

Página IOCCC: http://www.ioccc.org/index.html

View the original article here

This post was made using the Auto Blogging Software from WebMagnates.org This line will not appear when posts are made after activating the software to full version.

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

View the original article here

This post was made using the Auto Blogging Software from WebMagnates.org This line will not appear when posts are made after activating the software to full version.

Ataques homógrafos usando nombres de dominio internacionalizados

Incluso desde antes de Internet, en los más primitivos editores de texto ya había cierta confusión para diferenciar entre "l" (letra minúscula "ele") / "1" (el número "uno") y "O" (letra mayúscula para vocal "o") / "0" (el número "cero"). Por ejemplo G00GLE.COM se parece mucho a GOOGLE.COM en algunas fuentes.
Eso es porque hasta ASCII tiene caracteres parecidos u homógrafos que pueden aprovecharse para realizar diversos tipos de ataques de phishing y conseguir redireccionar a un usuario a otra página web distinta de la que cree que va a visitar...

El tema se pone más divertido aún si tenemos en cuenta que existen caracteres visualmente idénticos de diferentes alfabetos que naturalmente tienen asignado distintos códigos Unicode. Es decir, por ejemplo a vista de un humano una "O" será igual en latín, griego o cirílico, pero sin embargo un ordenador los tratará de manera diferente cuando la procese.

Por otro lado y como si el Diablo invitara a pecar, en 2003 el Sistema de Nombres de Dominio de Internet se liberó de la restricción del uso único de caracteres en ASCII mediante el IDNA (Internationalizing Domain Names in Applications), un mecanismo que permite el uso de caracteres latinos diacríticos (ñ, é) o que no utilizan el alfabeto latino como el árabe, Hangul, Hiragana, Kanji, etc...

¡Bingo! un atacante podría registrar un nombre de dominio que se parezca al de un sitio web legítimo, pero en el que algunos de los caracteres han sido sustituidos por homógrafos en otro alfabeto. Por ejemplo, la letra "a" en latín se parece mucho a la cirílica "?", por lo que alguien podría registrar http://eb?y.com (http://xn--eby-7cd.com/), lo que fácilmente podría confundirse con http://ebay.com. Esto se conoce como un ataque homógrafo usando nombres de dominio internacionalizados, y es más crítico en navegadores como Safari muestran los caracteres diacríticos incluso en la barra de la URL (prueba http://¦????????????????????????????.ws o apple?.com).

Fuentes:
Wikipedia: Internationalized domain name Wikipedia: IDN homograph attack
Artem Dinaburg's Blog: Stupid IDN Tricks: Unicode Combining Characters (or http://¦????????????????????????????.ws)

View the original article here

This post was made using the Auto Blogging Software from WebMagnates.org This line will not appear when posts are made after activating the software to full version.

Rogue AP sin airbase

Este post lo hago en respuesta de esa gente de Twitter que me ha preguntado algunas veces cómo hacer un rogue ap (un punto de acceso falso) y los he mandado a Google diciéndoles que hay 30 mil posts con ese contenido... 

Hasta que me hicieron buscar y, en efecto, casi todos los posts toman como herramienta airbase-ng, no sé por qué (lo estoy investigando)... 

Airbase no funciona del todo bien con algunas distribuciones  sobretodo en DEBIAN jessie, es por esto que vamos a ver una alternativa que nos viene de la mano de hostapd de la que tenéis toda su información en la página del autor así como en linux wireless además de los detalles para cada una de sus configuraciones (puesto que aquí apenas lo vamos a abordar).

¿Para qué vale un Rogue ap?

Pues para un montón de cosas, desde improvisar un punto de acceso inalámbrico por el que lanzar nuestra conexión a otros equipos wi-fi, hasta para ser algo malvados... y utilizar nuestro recién creado punto de acceso con el objetivo de que su/sus víctima/s se conecten a él, para monitorear su trafico, o conseguir la clave de su verdadero ap (Cafe Latte Attack).
Para esto podemos configurar de tres maneras el AP, la más común es como un AP abierto, configurando el AP de modo que responda a cualquier nombre de ESSID. O configurando el AP como el Ap que normalmente utiliza la víctima.

Luego entraremos en la manera de hacer que el cliente se conecte a el, por el momento vamos a crearlo.

Lo que vamos a necesitar es bien poco , nuestra tarjeta wi-fi (con los drivers de inyección), hostapd y un servidor DHCP.

El proceso es muy similar a montar nuestro HOTSPOT con airbase, casi no difiere en  nada. Podríamos dividir ambos procesos  en tres partes: levantar y configurar nuestra tarjeta wifi en modo monitor, configurar el dhcp que dará ip a los "clientes" y compartir Internet con los "clientes".

Instalando lo necesario

Comenzaremos por instalar hostapd y el servidor dhcp. Podemos instalar hostapd desde los repositorios o bien bajarlo y compilarlo desde su pagina web.

apt-get install hostapd
apt-get install isc-dhcp-server

Una vez bajado hostapd deberemos configurarlo. Para ello crearemos un fichero "hostapd.conf" con el siguiente contenido (luego veremos otro tipo de configuraciones):

#configuración Hostapd
interface=wlan0
driver=nl80211
ssid=Rogue
channel=1

En esta configuración mínima estamos diciéndole que nuestra interfaz es wlan0, su driver, el nombre del punto de acceso "Rogue" y que emita por el canal uno.

Por ahora sencillo ¿no?

Configurando el DHCP server

Es una parte muy importante antes de levantar el servicio DHCP tener claro qué tarjeta va a ser la encargada de repartir las IP en nuestra máquina, y la subnet en que va a estar. En nuestro caso le daremos la ip 10.0.0.1 con la máscara de red 255.255.255.0 y así lo declararemos en el fichero de configuración de nuestro dhcp.

Para decirle al dhcp que tarjeta va a ser la encargada de repartir las ip deberemos editar el fichero /etc/default/isc-dhcp-server (este paso sera diferente según que distribución utilices y que versión de servidor dhcp) por ejemplo:

Fedora / RedHat / CentOS: 
# File: /etc/sysconfig/dhcpd
DHCPDARGS=wlan0

Debian squezze / Ubuntu: 
# File: /etc/default/dhcp3-server
INTERFACES="eth0"

Debian jessie
#file: /etc/default/isc-dhcp-server

El fichero de configuracion de dhcp /etc/dhcpd/dhcpd.conf quedaría tal que así:

ddns-update-style none;
ignore client-updates;
authoritative;
option local-wpad code 252 = text;
subnet
10.0.0.0 netmask 255.255.255.0 {
# --- default gateway
option routers 10.0.0.1;
# --- Netmask
option subnet-mask 255.255.255.0;
# --- Broadcast Address
option broadcast-address
10.0.0.255;
# --- Domain name servers, tells the clients which DNS servers to use.
option domain-name-servers 10.0.0.1, 8.8.8.8, 8.8.4.4;
option time-offset 0;
range 10.0.0.3 10.0.0.13;
default-lease-time 1209600;
max-lease-time 1814400;
}

Bueno ya tenemos configurada la mayor parte ahora vamos con la interface. En primer lugar pararemos "networ manager" para que no nos de la lata:

/etc/init.d/network-manager stop

Luego bajaremos la wlan0 para cambiarle la ip:

ifconfig wlan0 down
ifconfig wlan0 10.0.0.1 netmask 255.255.255.0
ifconfig wlan0 up

después levantaremos el servicio dhcp:

/etc/init.d/isc-dhcp-server restart

y levantaremos nuestro falso AP:

hostapd hostapd.conf

Hasta aquí sencillo tan solo nos falta compartir nuestra conexión para que los clientes tengan alcance la inet...

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -i wlan0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Y con esto y bizcocho!! 

Lo que podemos hacer también es un pequeño script para que a la hora de levantar nuestro AP sea todo mas rápido:

Llevando el cliente hacia nuestro Rogue AP

Una vez tenemos nuestro Rogue AP podemos utilizar varias técnicas para engañar al cliente dependiendo de cual es nuestro objetivo, para que al fin y al cabo todo acabe como muestra la imagen de la izquierda.

Una vez conectado el cliente a nuestro pícaro punto de acceso somos dueños y señores de sus paquetes y podemos hacer de el lo que nos plazca...

Para ver su tráfico por ejemplo solo tendríamos que arrancar nuestro sniffer preferido:

tcpdump por ejemplo:
tcpdump -i wlan0
Un saludo....y espero haber ayudado!!

View the original article here

This post was made using the Auto Blogging Software from WebMagnates.org This line will not appear when posts are made after activating the software to full version.

Latch: una aplicacion para dominarlas a todas

Me gustaría despedir el año con lo que a mí me ha parecido la mejor idea de este 2013, os presento a Latch...
 
A primeros de junio Telefónica lanzaba Eleven Paths, una filial de seguridad a la cabeza de la cual colocaba a Chema Alonso (el de la foto ;D).

El pasado 13 de diciembre Alonso presentaba en sociedad Latch, una propuesta con la que Telefónica quiere proteger la identidad digital de los usuarios.

Latch  se basa en la idea de que los diferentes servicios online a los que accede el usuario no tienen por qué estar “encendidos” de manera constante.

Poder “encender y apagar” esos servicios de la misma manera que se echa el pestillo a una puerta es, según Chema Alonso, una manera de garantizar la seguridad digital de los usuarios en una época “en la que se hackea todo”.

Del lado del usuario Latch es una aplicación que el usuario se instala en el móvil con un manejo sencillo y no necesita ningún tipo de conocimiento experto...

La idea es que cuando el usuario “apaga” el acceso a uno de sus servicios, pongamos su cuenta de Facebook, nadie podrá acceder a esa cuenta y si lo hace, el usuario recibirá una alerta. De esta forma no sólo ese está añadiendo una capa extra se seguridad, se está reduciendo la ventana de oportunidades para seres malignos...

Por el momento el servicio está disponible para iOS, Android y Windows Phone y ya está implementada en algunos servicios del Grupo Telefónica (Tuenti, por ejemplo), Wordpress, el panel de control del ISP Acens y, según comentan, Telefónica está negociando la integración de otros servicios de terceros..

Durante la presentación, Chema Alonso recalcó que una de las ventajas de Latch es que con una sola aplicación “protegemos todas las identidades”. Además, como el proveedor de la identidad, es decir, el proveedor del servicio, no sabe quién está detrás, ante una posible brecha de seguridad no se sabe qué identidad pertenece a qué usuario, lo que ha llevado a Chema Alonso asegurar que la propuesta de su compañía “está diseñada a prueba de privacidad”.

Estoy más que seguro de que oiremos hablar mucho de Latch este 2014...desde aqui les deseamos lo mejor !!

View the original article here

This post was made using the Auto Blogging Software from WebMagnates.org This line will not appear when posts are made after activating the software to full version.

Cómo acceder a un terminal SSH desde el navegador web

Normalmente en las empresas los firewalls perimetrales sólo permiten el tráfico HTTP(s) hacia Internet. Hoy vamos a ver otra herramienta para poder evadir esta restricción y poder ejecutar un terminal SSH a través del navegador: Shell In A Box (o ShellInABox).

ShellInABox es un emulador de terminal web basado en ajax para cualquier navegador que soporte Javascript y CSS sin necesidad de disponer de ningún plugin adicional.
Existen otros emuladores para navegador mediante complementos como NaCl o FireSSH, si bien necesitarás acceso al exterior por el puerto 22/TCP.  Con ShellInABox accederás directamente al puerto 443/TCP de HTTPS.

Ahora bien, ¿por qué no cambiar el puerto del demonio SSH del 22/TCP al 443/TCP y dejarnos de tanta historia? Pues principalmente porque no tendrás necesidad de utilizar otro cliente como Putty y porque muchos firewalls con inspección de paquetes detectarían el intercambio de claves al menos que lo ofuscemos con ossh y Potty. 

Al instalar certificados SSL/TTL, ShellInABox cifrará todas las comunicaciones cliente-servidor y también hará más difícil la labor de detección de los firewalls/NIDS más "inteligentes".

En esta entrada vamos a probar a instalar ShellInABox en un máquina virtual con Kali Linux:

root@kali:~# apt-get install openssl shellinabox

Por defecto, el servidor web shellinboxd escuchará en el puerto 4200/TCP. Para modificarlo simplemente lo cambiaremos en el fichero de configuración:

root@kali:~# vi /etc/default/shellinabox# Should shellinaboxd start automaticallySHELLINABOX_DAEMON_START=1# TCP port that shellinboxd's webserver listens onSHELLINABOX_PORT=443# Parameters that are managed by the system and usually should not need# changing:# SHELLINABOX_DATADIR=/var/lib/shellinabox# SHELLINABOX_USER=shellinabox# SHELLINABOX_GROUP=shellinabox# Any optional arguments (e.g. extra service definitions).  Make sure# that that argument is quoted.##   Beeps are disabled because of reports of the VLC plugin crashing#   Firefox on Linux/x86_64.SHELLINABOX_ARGS="--no-beep"
Durante la instalación, si no encuentra un certificado adecuado, shellinaboxd intenta crear uno nuevo autofirmado (certificate.pem) mediante openssl. En ese caso el certificado creado se ubica en /var/lib/shellinabox. Si por lo que sea no se ha creado correctamente podéis crearlo vosotros mismos.

Para empezar a utilizarlo, simplemente iniciaremos los servicios:

root@kali:~# service ssh start
[ ok ] Starting OpenBSD Secure Shell server: sshd.

root@kali:~# service shellinabox start
root@kali:~# service shellinabox status
Shell In A Box Daemon is running

Y comprobamos el acceso a través de nuestro navegador: Fuentes y referencias:
- shellinabox - Web based AJAX terminal emulator 
- How to access ssh terminal in web browser on Linux
- Shell In A Box – A Web-Based SSH Terminal to Access Remote Linux Servers
- Crea un tunel TCP a través de HTTP mediante Tunna
- Evadir un portal cautivo mediante un túnel DNS
- Cómo crear un túnel SSH entre un servidor Linux y un cliente Windows

View the original article here

This post was made using the Auto Blogging Software from WebMagnates.org This line will not appear when posts are made after activating the software to full version.

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

Es aquí donde el viejo y sabio maestro de Kungfu diría "donde ves tú la debilidad veo yo la fortaleza" si piensas que Tcpdump ha quedado obsoleto por la aparición de herramientas con interfaz gráfica como Wireshark.
Tómate un tiempo y piénsatelo de nuevo...

En esta entrada vamos a ver como una herramienta (la cual suponíamos que conocíamos) puede darnos con poco esfuerzo gratos momentos dejando atrás la idea que teníamos de ella, y veremos como el inconveniente que algunos creen que tiene se convierte en su mayor ventaja... no está de más decir que hay herramientas más preparadas para lo que vamos a hacer...

Dónde colocar nuestro sniffer

Tenemos que colocar el sniffer en algún sitio por el que pase todo el tráfico que nos interese. Esto lo podemos hacer con algunas capacidades de los switches como el Port Mirroring (puertos espejo) o cualquier electrónica de red por la que pase todo el tráfico (Firewalls, TAP, Apliances).

Desde luego estamos hablando de una red nuestra....para los "otros casos " siempre nos quedara el envenenamiento Arp.

Aclaro esto puesto que no sé cuántas veces he tenido que oír : "no puedo capturar el tráfico de mi red" incluso de gente que no es tan profana en la materia....
 
Qué queremos capturar
 
Ya hemos visto varios ejemplos de cómo dar con el "paquete adecuado"... creo que no cabe más mención respecto a este tema...
Bueno al grano....

Vamos a imaginar que estamos a cargo de una red, o mejor que estamos dentro de una red en la cual sospechamos que alguien hace uso del email para contactar con sus secuaces.....(XD mola poner casos inverosímiles) y sospechamos que van a poner una BOMBA...

Paso de estar registrando largas capturas o perder los ojos en el Wireshark voy a dejar a Tcpdump que se lo curre un poquito... puff pero no sé programar...O_o ....chachan!!! pero se hacer filtros!!!

tcpdump -i wlan0  -n -X -s 1500 port 25 | grep  -A 30 -B 5 BOMBA

Con este ejemplo tan tonto lo que hemos querido dejar patente es que gracias a que Tcpdump está hecho expresamente para funcionar en la línea de comandos, es facilísimo implementarlo directamente en un script, y con poquísimos medios y conocimientos hemos sido capaces de escudriñar hasta dar con nuestro objetivo.

Podríamos haber sido más precisos a la hora de hacer el filtro (jeje y más técnicos)  pero el objetivo es ver la simpleza...

Y si lo llevamos más lejos de grep....

Lo que haremos con el siguiente ejemplo es identificar quien nos está haciendo ping y si nos da la gana lo bloquearemos:

Nótese que la simpleza del script es crítica , pero si desarrollamos la idea, nos puede quedar un bonito firewall interactivo; o podríamos automatizar medidas de defensa o ataque...

Un poco más...

Para este ejemplo nos vamos a valer de Mausezahn ya hemos hablado del aquí un par de veces es más este ejemplo ya lo vimos también... 

Lo que haremos es secuestra una sesión tcpip y cortarla con un paquete rst. Para esto debemos dar con un número de secuencia válido e inyectar nuestro paquete a tiempo:

CÓDIGO EN PASTEBIN

Mediante envenenamiento de Arp colocamos a Tcpdump en disposición de capturar los paquetes de nuestra víctima la cual está conectando por SSH a una máquina remota.  

Con  tcpdump -S recogemos los números absolutos de la secuencia del flujo de paquetes, con MZ montamos un paquete valido para secuestrar la sesión y cerrar la conexión...

Espero que este artículo haya despertado tu interés por Tcpdump y os haya dado algunas ideas nuevas. 

Además de sus muchas características y opciones integradas, como he mostrado en varios ejemplos, Tcpdump puede ser utilizado como un conducto de paquetes de datos dirigiendo su salida a la entrada de otros comandos para expandir aún más las posibilidades.

Las formas de usar tcpdump sólo están limitadas por tu imaginación. 

Tcpdump también es una increíble herramienta de aprendizaje. No hay mejor manera de aprender cómo trabajan las redes y los protocolos que observando sus paquetes reales. 

El legado de Tcpdump

Tcpdump ha sido la herramienta de captura de paquetes de facto durante los últimos 25 años. Esta realmente generó todo una categoría de utilidades de redes basadas en sniffing y análisis de paquetes. 

Antes de Tcpdump, la captura de paquetes demandaba demasiado procesamiento lo que la hacía muy poco práctica. Tcpdump introdujo algunas innovaciones y optimizaciones clave que ayudaron a hacer que la captura de paquetes fuera más viable, tanto para los sistemas regulares como para las redes con mucho tráfico. 

Las utilidades que llegaron después no sólo siguieron el ejemplo de Tcpdump, sino que también incorporaron directamente sus funcionalidades de captura de paquetes. Esto fue posible porque desde muy temprano, los autores Tcpdump decidieron separar el código de captura en una librería portable llamada libpcap.

Wireshark, ntop, snort, iftop, ngrep y cientos de otras aplicaciones y utilidades disponibles en la actualidad se basan en libpcap. Incluso la mayoría de aplicaciones de captura de paquetes para Windows se basan en un "port" de libpcap llamado WinPcap.

Bueno un saludo y sed buenos (que vienen los reyes)... 

Serie de artículos: Qué deberíamos saber sobre Tcpdump (parte 1, parte 2, parte 3).

View the original article here

This post was made using the Auto Blogging Software from WebMagnates.org This line will not appear when posts are made after activating the software to full version.