4 votos

Wireshark solo captura tramas de balizas

Estoy tratando de analizar mi propia red para capturar el tráfico http. En airodump la seguridad de mi red muestra "WPA - TKIP - PSK", así que fui a Wireshark > Editar > Preferencias > Protocolos > IEEE 802.11 > Habilitado el cifrado. Y en los campos de clave ingresé:

wpa-psk: la clave que obtuve de http://www.wireshark.org/tools/wpa-psk.html al ingresar mi contraseña y ssid en texto plano
wpa-pwd: mipassword: mi ssid
wpa-pwd: mipassword

Luego configuré mi adaptador inalámbrico (awus036h) en modo monitor con airmon-ng start wlan0, lo cual crea una nueva interfaz (mon0).

Luego inicié Wireshark y comencé una nueva captura en la interfaz mon0, pero todo lo que obtengo son tramas de beacon. Intenté los filtros wlan.addr == "la MAC de mi router" y solo veo lo que se muestra en esta imagen:

Los paquetes de deautenticación capturados provienen de un ataque de aireplay que ejecuté en mi propia red para ver si los capturaría. Incluso probé con el filtro simplemente "http", y entonces no veo ningún paquete en absoluto. Además, estoy conectado en mi laptop al mismo router y navegando por internet al mismo tiempo que estoy analizando.

¿Qué estoy haciendo mal?

2voto

Simon Puntos 165

Aquí hay algunas posibles razones, en orden aproximado de probabilidad:

  • Una razón común por la cual no ver los paquetes unicast de otros dispositivos en una traza de paquetes en modo monitor es que olvidaste también configurar el modo promiscuo.

  • Otra razón común es que el tráfico que estabas buscando no estaba en el canal que estabas analizando. Esto puede ocurrir si tienes un AP dual-band concurrente y estabas analizando en su canal de 2.4GHz pero no en su canal de 5GHz. O si tu red está compuesta por más de un AP, y estabas analizando en el canal de un AP, mientras que tu cliente objetivo estaba conectándose a un AP diferente en un canal diferente.

  • Otra razón podría ser que esos otros dispositivos están comunicándose utilizando un sabor diferente de 802.11 al que soporta tu tarjeta de sniffer. Por ejemplo, si tu tarjeta de sniffer es solo 2x2:2 (2 flujos espaciales), no podrá capturar paquetes enviados usando 3 flujos espaciales. O si solo es capaz de utilizar canales de 20MHz, no podrá capturar paquetes enviados usando canales de 40 o 80MHz. Si tu tarjeta es solo 802.11n, no podrá capturar 802.11ac.

  • Otra razón sería si tu máquina de sniffer no está dentro del alcance de los otros dispositivos cuyo tráfico esperabas capturar. "Dentro del alcance" es complicado porque tecnologías modernas como beamforming optimizan la señal para la posición donde se encuentra el destinatario intencionado; no hay garantía de que un receptor no intencionado cercano recibirá suficiente fuerza de señal para demodular (es decir, recibir con éxito, mucho menos descifrar) las señales.

0voto

MariusMatutiae Puntos 20077

No he presenciado este comportamiento, así que de alguna manera podrías decir que no sé de lo que estoy hablando.

Sin embargo, tengo la misma tarjeta de red, y la he visto comportarse de forma errática en muchas ocasiones. En particular, funcionó satisfactoriamente en BT, pero muy erráticamente en Kali. Extraño, podrías decir, dado que los controladores están conectados al kernel, no a la distribución, sin embargo, esta es exactamente mi experiencia.

Lo que puedo sugerir es primero usar aircrack-ng antes de intentar wireshark, porque proporciona mensajes de error más informativos. Luego, matar los programas de los que airmon-ng se queja cuando colocas la tarjeta en modo monitor (típicamente, network-manager, dhclient, avahi-daemon). Por último, realizar la prueba de inyección habitual,

aireplay-ng -9 wlan0

porque por supuesto esta es la prueba definitiva de la adecuación del controlador.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X