Español | English
rss facebook linkedin Twitter

Protección de nuestro AP

Una de las labores de un WIDS (Wireless Intrusion Detection System) puede consistir en proteger tu propio punto de acceso, para lo que puedes controlar que no cambie de SSID, que no cambie de canal (si es que no debe) o que no utilices cifrado WEP, pero lo divertido llega cuando alguien pretende suplantar tu punto de acceso y se molesta en ponerse la misma dirección MAC, mismo SSID y mismo canal. ¿Qué hacemos ahora?

Como previamente hemos diseccionado todos los paquetes que vemos en el canal de nuestro AP, podemos realizar una comprobación de cualquier campo del mismo, y una manera más que interesante de detectar este tipo de suplantaciones consiste en comprobar la secuencia de timestamp de los paquetes correspondientes a la dirección MAC de tu AP, que deberá ser ascendente hasta que se resetee. Esto puede ser representado así:


Además, se puede mantener una comprobación adicional de la potencia de señal recibido desde dicha MAC y, dado un margen de +-10 dB, podremos indicar que nos encontramos en una situación "normal" (supongo emisor y receptor inmóviles).

En el caso de encontrar algún paquete fuera de lugar, nos podemos encontrar una situación como esta, que nos indicará que algo no marcha bien.


Esta ruptura de linealidad la podemos tratar de encontrar vigilando únicamente los últimos 3 paquetes recibidos, secuenciales en el tiempo, que llamaremos previous, last y current.


Manteniendo la información de los últimos 3 paquetes, si vemos que...

previus > last y previous < current

...llegamos a la conclusión de que algo no está bien, ya que ha habido una bajada antes de haber llegado al valor máximo del timestamp. Es mejor guardar los máximos durante un tiempo para que esta comprobación sea más efectiva, pero no es estrictamente necesario para obtener resultados.

Es un tema interesante al que merece la pena dedicarle unos minutos de "pensada".

Siguiendo con el ejemplo de los 3 paquetes puede pasar que, por ejemplo, la secuencia de timestamp del atacante sea inferior a nuestra. En este caso, en el momento en que se cuele un paquete de esa secuencia y quede situado entre dos paquetes de la secuencia original (bien instantáneamente o al desplazarlo por obtención de un paquete "bueno" más) quede rodeado por dos paquetes de nuestra secuencia, saltando así la alarma.

Para simplificar, el caso en el que la secuencia "mala" sea mayor que la "buena" puede quedar reducida al mismo ejemplo, ya que al crecer al mismo ritmo, en algún momento pasará a estar por debajo, aunque esta simplificación nos supone una pérdida de tiempo en la detección.

Técnicamente, no es infalible, ya que si consigues controlar el timestamp (muy difícil) y consigues sincronizarlo (muy difícil)... También depende del tiempo de envío de paquetes y el orden de recepción, pero las pruebas de laboratorio (con el código que se muestra a continuación) ha resultado satisfactorias.


Existen más estrategias, como controlar la tasa de beacons por segundo, que si es incrementada quiere decir que otro RogueAP está enviando beacons. El RogueAP, por supuesto, podría no enviar beacons y únicamente responder al cliente, pasando a la detección por el caso anterior.

Esto está implementado en el sistema de Protección y Vigilancia en redes inalámbricas, de la que pretendemos liberar en breve una versión de la sonda bajo licencia GPL, para que quien quiera pueda trastear con ella. ;)

Antes de terminar, quiero agradecer a mi compañero en este viaje por el mundo wireless a mi compañero Patxi por toda la labor realizada en el proyecto.

Mikel Gastesi
S21sec e-crime

1 comentario:

Anónimo dijo...

Interesante trabajo, espero con interés la publicación del cuaderno para trastear. Gracias.


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login