Posted by Star | Posted in | Posted on 21:53
Ya sí… os prometía “descanso”, continuar con WEP, etc…pero…. Como quiero que empecemos a “tocar bola” cuanto antes vamos a seguir y no precisamente con lo “prometido” (bueno casi sí)
En este post vamos a “ sentar” los principios de “los desafíos” que han de sortear las estaciones WiFi para acceder al medio.
Gracias a esta información vamos a entender algunos de los “ataques” de Denegación de Servicio (DoS).
Lo que voy a contar es algo que pocas veces se toma en cuenta y que desgraciadamente, ni siquiera se comenta en otros sitios (incluidos muy prestigiosos libros y documentos) o si se hace, lo explican de forma muy somera y con poca claridad.
En las comunicaciones por cable (léase Ethernet que a todos nos suena mas) es razonable pensar que cuando una trama se transmite el receptor la recibe correctamente.
Vale, sabemos que no siempre es así, que pueden existir “ colisiones” sobretodo cuando usamos Hub’s en lugar de switches, aún con switches podemos tener colisiones en la red, especialmente lo que se denomina colisiones tardías, difíciles de diagnosticar.
Una colisión no es otra cosa que el envío simultáneo de información por dos o mas estaciones en la red. Cuando eso ocurre, y volviendo al ejemplo de la red de cable Ethernet, los paquetes se destruyen y se hace “un silencio” para que se vuelva a retransmitir. De esto se ocupa un protocolo llamado CSMA/CD que si recordáis el Taller TCP/IP, era lo que llamaba el “policía de la red”, que pone orden en el tráfico, etc…
Las comunicaciones por Radio Frecuencia no están libres de colisiones , ni mucho menos, sobretodo estas que llamamos WiFi.
Además, el protocolo 802.11 trabaja de una forma “ especial”, 802.11 incorpora un mecanismo de “asentimiento positivo” de forma que TODAS las tramas enviadas deben “confirmadas” con un ACK positivo por el receptor, de otra forma la trama se considera perdida.
Bueno, veremos mas adelante (muuuchooo mas) pero ya os lo adelanto, que hay un caso especial: QoS.
Ciertamente me sorprendió que en el hilo del tkiptun:
http://www.wadalbertia.org/phpBB2/viewt ... highlight=
Cuando dije:
En este post vamos a “ sentar” los principios de “los desafíos” que han de sortear las estaciones WiFi para acceder al medio.
Gracias a esta información vamos a entender algunos de los “ataques” de Denegación de Servicio (DoS).
Lo que voy a contar es algo que pocas veces se toma en cuenta y que desgraciadamente, ni siquiera se comenta en otros sitios (incluidos muy prestigiosos libros y documentos) o si se hace, lo explican de forma muy somera y con poca claridad.
En las comunicaciones por cable (léase Ethernet que a todos nos suena mas) es razonable pensar que cuando una trama se transmite el receptor la recibe correctamente.
Vale, sabemos que no siempre es así, que pueden existir “ colisiones” sobretodo cuando usamos Hub’s en lugar de switches, aún con switches podemos tener colisiones en la red, especialmente lo que se denomina colisiones tardías, difíciles de diagnosticar.
Una colisión no es otra cosa que el envío simultáneo de información por dos o mas estaciones en la red. Cuando eso ocurre, y volviendo al ejemplo de la red de cable Ethernet, los paquetes se destruyen y se hace “un silencio” para que se vuelva a retransmitir. De esto se ocupa un protocolo llamado CSMA/CD que si recordáis el Taller TCP/IP, era lo que llamaba el “policía de la red”, que pone orden en el tráfico, etc…
Las comunicaciones por Radio Frecuencia no están libres de colisiones , ni mucho menos, sobretodo estas que llamamos WiFi.
Además, el protocolo 802.11 trabaja de una forma “ especial”, 802.11 incorpora un mecanismo de “asentimiento positivo” de forma que TODAS las tramas enviadas deben “confirmadas” con un ACK positivo por el receptor, de otra forma la trama se considera perdida.
Bueno, veremos mas adelante (muuuchooo mas) pero ya os lo adelanto, que hay un caso especial: QoS.
Ciertamente me sorprendió que en el hilo del tkiptun:
http://www.wadalbertia.org/phpBB2/viewt ... highlight=
Cuando dije:
Otra cosa!!! que me olvidé al hablar de "las ventajas" de usar QoS en este tipo de ataques...
Si está habilitado QoS, se pueden inyectar unos 15 tramas por cada paquete "descifrado"
Nadie preguntó por qué con QoS se pueden enviar hasta 15 paquetes y sin QoS solamente uno!!!! Claro, que a lo mejor ya lo sabíais y por eso no se preguntó nada… Bueno, para los que no lo supieran:
La razón de ello viene por esto que comentamos de los ACK positivos… determinadas comunicaciones QoS usan una “ráfaga” y precisamente por ello, podemos enviar 15 tramas sin necesidad de recibir un ACK por cada una de ellas, bastará un ACK positivo para las 15… bueno, que me estoy saliendo del tema…
El caso es que cada trama de datos enviada debe ser respondida con su correspondiente ACK
Y las preguntas con “trampa” de rigor…
1.- Y Si se “pierde” la primera trama transmitida??
2.- Y si lo que se pierde es el ACK???
Con “perder” me refiero a interferencias, problemas de comunicación, etc…vamos que no llegan al destino...
Pues en estos dos casos, la trama debe ser retransmitida (acabamos de descubrir el significado de uno de los bits de la FC que no comentamos nada en absoluto, el bit 11 (Reintentar o retransmitir) se activa cuando una trama lo está siendo.
Pero volvamos a lo que nos ocupa… las colisiones.
Ethernet cuenta con CSMA/CD para el tratamiento de colisiones, 802.11 cuenta con CSMA/CA.
Sin embargo no es suficiente por sí sólo… y te pongo un ejemplo (una imagen)
Equipo 1 y equipo 2 están “al alcance”
Equipo 2 y Equipo 3, también lo están
Sin embargo, equipo 3 no se puede comunicar directamente con Equipo 1 porque “no están al alcance”
Además, es perfectamente posible que equipo 1 y equipo 3 transmitan datos al mismo tiempo, y eso… en la zona amarilla es una colisión.
Esto es el equivalente de las colisiones tardías en Ethernet, aquí los llamamos “Nodos ocultos”, es decir, estaciones que pertenecen al medio pero que están tan alejadas unas de otras que la comunicación directa entre ellas no es posible.
Por si fuese poco, la mayoría de las tarjetas inalámbricas operan en “half-duplex”, esto es, no pueden enviar y recibir al mismo tiempo (realmente son los transceptores de las tarjetas)
Si juntamos todo esto… el equipo 1 y el equipo 3 pueden “no percatarse” de que existe colisión!!!
¿Cómo solucionar esto?
Pues con algo de lo que seguro que has oído hablar (o seguro que leer o ver en las configuraciones de tarjetas y puntos de acceso): Enviar tramas ce control RTS y CTS.
RTS es Request to Send, también hay quien lo llama ready to send o si lo prefieres preparado para trnasmitir
CTS es Clear to Send o Listo para transmitir o permiso para transmirir
Ambos aseguran que el canal “está limpio y preparado para transmitir” de tal forma que otras estaciones “se callan” hasta que el medio esté libre para poder enviar sus tramas.
Luego la imagen correcta de acceso sería:
Y si existiese un “nodo oculto” como en el ejemplo anterior, quedaría así:
Como ves en la figura anterior, el nodo oculto recibe un CTS de aquél equipo que sí es accesible y “se calla”.
Ni que decir tiene que todo esto tiene una temporización (Timing) y un “umbral” (threshold).
El timing se puede “controlar” mediante ajustes DCF, PCF o HCF que no son otra cosa que cómo va a funcionar el protocolo CSMA/CA.
El umbral también se puede ajustar en cada tarjeta, así por ejemplo las tramas “cortas” pueden ser enviadas inmediatamente mientras que las “largas” utilizarán RTS y CTS antes de ser enviadas.
¿Cortas y largas? ¿cómo de cortas o cómo de largas?
Pues como ya he dicho, el umbral. Aquellas que sean mas cortas que el umbral se transmitirán inmediatamente y las que sean mas largas que el umbral, usarán los métodos RTS y CTS.
DCF es el modo “por defecto” del estándar 802.11 y funciona igual que ethernet: Escuchar antes de hablar… y si hay silencio… se envía. Si hay colisión, se entrega un tiempo aleatorio de espera a cada estación y vuelta a empezar.
PCF utiliza lo que se llama “Puntos de Coordinación” que son los propios puntos de acceso y difiere en el método anterior en que permite emitir a las estaciones tras un corto periodo de tiempo exista o no colisiones.
HCF Permite a las estaciones “balancear” el tráfico en función de la mejor calidad de los servicios, encola los paquetes dependiendo del tipo de aplicación… es.. QoS.
Tanto RTS/CTS. Como el Timming, como el umbral existen para garantizar una transmisión sin interrupciones y con el mínimo de sobrecarga.
Y si piensas que aquí está todo dicho… pues falta otra cosa: NAV.
NAV es un Vector de Localización de Red, lo utiliza CSMA/CA y la pareja CTS/RTS… pero también se inicializa con el campo Duración de la Cabecera MAC:
Recordemos como era una cabecera MAC de una trama de datos:
Como ves, existen 2 bytes después del Frame Control que representan la duración.
La duración de que???
Pues el tiempo estimado que debe estar el canal disponible para trasmitir la trama.
Es un valor de 16 bits (2 bytes) de tal forma que si el bit 15 (el más significativo) está a cero el valor del resto de bits será el valor con el que se inicializa NAV.
Es decir, NAV como mucho puede valer 2^15 = 32.768
O dicho de otra forma, el tiempo máximo que se puede reservar para la retransmisión de una trama es de 32.768 ¿qué? Microsegundos.
Todas las estaciones de la red monitorizan las tramas y las cabeceras MAC’s, de tal forma que durante la transmisión de la trama de otro equipo, “leen” la duración de la misma y añaden ese tiempo extra como tiempo de contención antes de enviar sus datos.
Además puede haber más información en el campo Duración, por ejemplo, si los bits 15 y 14 están a uno indica un modo especial llamado PS-Poll que se usa en combinación de otros valores para la administración de energía y “despertar” a las estaciones que lo implementan, para nuestro taller, sin utilidad por el momento.
Vale… y ahora que??
Pues como vamos a empezar con las Denegaciones de Servicio… porqué no usar alguna de estas “características” para ello.
Por ejemplo, enviar tramas con una duración de 32.768 que dijimos que eran una treintavo de segundo… bueno pues menudo DoS, no?? Jajaja,
Y si enviamos unos cientos (o miles) de paquetes de “esos” ?? Qué pasará?? Lo imaginas, no???
Y si inundamos la red con CTS/RTS???
Pues eso mismo, son ejemplos… no todo consiste en Disociar o Des-autenticar a los clientes, pueden existir y existen “otras formas de fastidiar” sin necesidad de echar a la gente a patadas
Después de esta explicación pasaremos a la práctica ;)
Comments (0)
Publicar un comentario