Detección de 802.11 tarjetas y puntos de acceso desautorizados
La primera meta es detección. ¿Podemos decir cuando alguien las energías en una tarjeta dentro de la gama de la red local? Esto se puede hacer con los componentes disponibles y el software libre. El conductor del Cisco Aironet incluido con los núcleos más recientes de Linux apoya "el modo del monitor del RF", que permite la supervisión promiscua de 802.11 paquetes - específicamente, supervisando 802.11 marcos crudos para detectar si hay algunos marcos indicadores difunden por un punto o una tarjeta de acceso del granuja. Conforme a la especificación original 802.11, hay tres clases de 802.11 bastidores. Con la meta de detectar puntos de acceso del granuja y tarjetas sin hilos desautorizadas de Ethernet, estamos sobre todo interesados en marcos de la clase 1 y 2. Los marcos de la clase 1 son los únicos marcos permitidos en el estado 1, unauthenticated el estado, y son en gran parte marcos de la gerencia usados para la autentificación, los faros, y las peticiones de la punta de prueba. Los marcos de la clase 2 se permiten en ambos estados 1 y 2, y se utilizan para la asociación y la reasociación. De puntos de acceso, esperábamos ver una gran cantidad de marcos del faro (clase 1). De unassociated a clientes ad hoc que exploraban en modo activo, nosotros esperaba ver una gran cantidad de peticiones de la punta de prueba (también clase 1). Probar esta hipótesis, un método de supervisar los 802.11 marcos de la gerencia es necesario, que la tarjeta del Cisco y el conductor de Linux son capaces en "de modo del monitor del RF." Setup para poner la tarjeta en el modo del monitor del RF, cualquier modo de BSS (uso ": r "para el modo llano del monitor del RF): # modo del eco ": y "> /proc/driver/aironet/eth0/Config # Entonces, paquetes de registración del comienzo con el tcpdump, ahorrándolos a un archivo para un análisis más último con etéreo: # tcpdump - i eth0 - s 0 - W capturefile # La red ad hoc desautorizada la primera prueba era confirmar la capacidad de detectar una tarjeta de WLAN que era accionada encendido. Una tarjeta de Lucent Orinoco fue configurada en modo ad hoc en una computadora portátil de Win2k, y girado a descubra si había algunos marcos característicos enviados por la tarjeta de Orinoco cuando fue puesta en modo ad hoc. Después de la tarjeta inicializada, el tcpdump fue parado, haber comenzado etéreo, y el archivo de la captura fueron abiertos. Una gran cantidad de peticiones de la punta de prueba de la tarjeta de Orinoco fueron encontradas, confirmando que era de hecho posible detectar cuando alguien dentro de gama cercana había accionado encima de una tarjeta sin hilos de Ethernet en modo ad hoc. El marco disecado era como sigue:
De hecho, es posible decir si alguien comienza una tarjeta activamente de exploración en modo ad hoc, y la información útil bastante se puede espigar de un solo marco. Los más relevantes son los SSID y el MAC address, puesto que pueden ser utilizados para seguir abajo a una tarjeta y/o a una persona particulares. El punto de acceso desautorizado la prueba siguiente era confirmar la posibilidad de detectar un punto de acceso del granuja. Una sesión del tcpdump fue comenzada, y entonces un punto de acceso del Cisco Aironet 340 fue girado. Después de que el punto de acceso hubiera acabado patear, la descarga fue examinada con etéreo, y una gran cantidad de marcos del faro enviados por el punto de acceso fueron encontrados. Lo que sigue es un tal marco, disecado otra vez por etéreo:
El cliente desautorizado la condición probada final era clientes desautorizados. El primer panorama considerado (el panorama más probable), es que alguien trae una tarjeta extranjera y energías él para arriba con el SSID incorrecto. Si la tarjeta explorara activamente, las peticiones de la punta de prueba serían consideradas de esta tarjeta mientras que procuró encontrar un punto de acceso. El segundo panorama es que alguien trae una tarjeta extranjera y energías él para arriba con el SSID correcto. Éste resulta ser poco un más problemático a detectar, en eso habrá solamente algunos marcos de 802.11 gerencias para accionar una alarma, y entonces más tráfico "normal". Esto es problemático sobre todo debido a la manera que el modo de RFMON_ANYBSS en la tarjeta del Cisco trabaja - a pesar de su nombre, la tarjeta no puede recibir los paquetes simultáneamente de todo el BSS en gama, especialmente si esas frecuencias del uso de BSS diversas. La consecuencia es que lleva una cierta intervención manual el tráfico de la aspiración de un BSS particular - vea la sección abajo en "problemas y complicaciones" para más detalles en este problema y cómo trabajar alrededor de él. Este problema fue no hecho caso y en lugar de otro el foco estaba en los pocos marcos de 802.11 gerencias que demuestran para arriba fácilmente en el succionador - ambos panoramas resultados para producir peticiones similares de la punta de prueba, así que ambos panoramas se tratan como idénticos. La petición disecada de la punta de prueba enviada por esta tarjeta:
Los problemas y las complicaciones algunos problemas vinieron encenderse con la tarjeta y el conductor del Cisco que necesitan ser mencionados. El primer problema es que la tarjeta del Cisco, por el defecto, uniforme en modos de RFMON y de RFMON_ANYBSS, no explora activamente para el tráfico en todos los canales siempre. Los siguientes son las condiciones bajo las cuales pre-explorará para BSS:
Todas estas condiciones quieren "retroceso" la tarjeta en la pre-exploración. Para construir un dispositivo práctico de la detección, la tarjeta se debe golpear con el pie en los intervalos regulares, quizás cada minuto. Una escritura simple para tocar el archivo de BSSList cada minuto hará el truco. Segundo problema: No todo el BSS en gama demostró para arriba confiablemente en el archivo /proc/driver/aironet/eth0/BSSList. Cuando la tarjeta se pone en modo de RFMON, el transmitir es lisiado, así que la tarjeta no puede explorar activamente para BSS enviando peticiones de la punta de prueba. Por lo tanto, la tarjeta debe utilizar la exploración pasiva. En vez de enviar peticiones de la punta de prueba, la tarjeta escucha faros. Las exploraciones pasivas utilizan un contador de tiempo que—la tarjeta esperará a escuchar marcos del faro hasta que expira el contador de tiempo y después que se mueve a otro canal. El problema con la tarjeta del Cisco es que este contador de tiempo está fijado demasiado bajo. El valor prefijado es 40ms, que era escaso en nuestra red de la prueba para notar todo el BSS, sin importar la gama o la fuerza relativa de la señal de los puntos de acceso. La solución era agregar esta línea a la rutina de inicialización de la tarjeta, setup_card, en airo.c: cfg.beaconListenTimeout = 120; Triplicar este descanso hizo el trabajo de la detección de BSS confiablemente. Por lo tanto, todos nuestros puntos de acceso demostraron para arriba en BSSList, toda la hora. Tercer problema: A pesar de su conocido, incluso poner la tarjeta en modo de RFMON_ANYBSS no hizo la tarjeta recibir tráfico de todos nuestros puntos de acceso, que eran todos que usaban diversas frecuencias y fueron sincronizados probablemente diferentemente. La tarjeta sí mismo eligió un BSS para sincronizar para basar en su propio algoritmo (probablemente en su gravamen de la fuerza relativa de la señal). El problema con esto es que deseamos ver tráfico de todo el BSSs en gama, no apenas los que sucedan tener las señales más fuertes. Una manera no se podría encontrar para inhabilitar esta característica en la tarjeta del Cisco, pero hay un workaround - el conductor de Linux proporciona un interfaz de /proc para fijar un AP preferido. La lista de BSSs en la gama del explorador se encuentra (/proc/driver/aironet/eth0/BSSList), elige una vez el para supervisar y para incorporar el MAC address al archivo /proc/driver/aironet/eth0/APList. Esto forzará la tarjeta para sincronizar con ése BSS y para cambiar a ese canal, después de lo cual el tráfico de ése BSS se puede recibir y utilizar para los gravámenes de la fuerza de la señal o supervisar para la actividad sospechosa. Las conclusiones estas pruebas simples confirman que hay 802.11 marcos que son característicos de puntos de acceso típicos del granuja y de redes ad hoc desautorizadas, y que estos marcos se pueden detectar y analizar usando componentes disponibles y software libre. Usar estos conceptos junto con una base de datos de los puntos y de las tarjetas confiados en de acceso y las huellas digitales de bastidores sospechosos, etéreas se podía utilizar como bloque de edificio fundamental en un verdadero sistema de la detección de 802.11 intrusiones. esto es un artículo agregado por Kim Sulloway
|
|||||
|