Seguridad en Redes 802.11x

Volver arriba

Tipos de Ataques.

Como no empezamos con los ataques al WEP:

Ataque de fuerza bruta : Este ataque, aunque funciona, dado a las limitaciones de WEP (indicadas anteriormente), no se suele hacer dado que tardaríamos unos 3 meses en obtener la clave con un ordenador mas o menos potente.

Ataque con diccionario: Igual que el anterior, pero mas rápido, gracias a la utilización de diccionarios :)

Ataque Inductivo Arbaugh: Se basa en explotar la vulnerabilidad de MIC independiente de la llave aprovechando también la redundancia de información producida por el CRC.EL funcionamiento visto muy por encima trata mas o menos el que sigue:

Para realizar el ataque hay que conocer parte del plaintext que viaja encriptado en una
trama, que podemos obtener por ejemplo identificando mensajes “DHCPDISCOVER”
de los que conocemos que la cabecera IP tendrá como origen 0.0.0.0 y como destino
255.255.255.255 y tienen longitud fija. Una vez identificada la trama con el mensaje
“DHCPDISCOVER” realizamos una XOR del plaintext conocido con el cyphertext que
hemos recibido, obteniendo así 24 bytes del keystream para el IV concreto del paquete. Lo siguiente será modificar el paquete, pero de forma engañosa, es decir, debemos meterlo en un arp o un ping, para así obtener respuesta, Una vez lanzado, si tenemos respuesta, Bingo!, era el último byte del vector, en caso contrario tendremos que probar con los 255 posibilidades restantes, modificando el último byte :(

El atacante tiene que volver a generar un paquete del cual se le devuelva una respuesta,
(lo mejor es enviar broadcast pings, así recibimos múltiples respuestas por cada paquete que enviamos). El atacante conoce el plaintext de la respuesta y el que responde cada vez enviará el paquete con un IV diferente, así es posible construir una tabla de keystreams completos para cada IV que el atacante puede utilizar para descifrar el tráfico encriptado con WEP en tiempo real.Decir que tendríamos que capturar, teoricamente unos 24GB :)

Debilidades en el algoritmo key RC4 :Esto es el funcionamiento de programas como airsnort o wepcrack, El funcionamiento, es realmente complicado, así que nos quedamos con que es una de las formas mas rápidas para obtener la WEP.

Ataques a ACL’s basados en MAC : Para llevar a cabo el ataque basta con esnifar durante un momento el tráfico y fijarnos en la MAC de cualquiera de los clientes, sólo hace falta que nos pongamos su misma MAC y ya habremos saltado la restricción.Hay que tener en cuenta que si hay dos máquinas en la red con la misma dirección
MAC podemos tener problemas, aunque generalmente en las redes wireless esto no
suele ser un problema muy grave ya que el Punto de Acceso no puede distinguir que
verdaderamente hay dos máquinas con la misma MAC. De todas formas, si queremos
podemos “anular” a la máquina que le hemos “robado” la dirección MAC. Para hacer
esto, debemos implementar un ataque de Denegación de Servicio.

Ataque de Denegación de Servicio (DoS) : Para realizar este ataque basta con esnifar durante un momento la red y ver cual es la dirección MAC del Punto de Acceso. Una vez conocemos su MAC, nos la ponemos y actuamos como si fuéramos nosotros mismos el AP. Lo único que tenemos que hacer para denegarle el servicio a un cliente es mandarle continuamente notificaciones (management frames) de desasociación o desautenticación. Si en lugar de a un solo cliente queremos denegar el servicio a todos los clientes de la WLAN, mandamos estas tramas a la dirección MAC de broadcast.Para esto tenemos herramientas como wlan-jack o dassoc (desarrollada por @stake), ambas de linux.

ESSID ocultados : Aunque no es meramente un ataque, veamos como podemos descubrid AP´S ocultos:

AL estar oculto, significa que el AP no emite beacom, por tanto no sabemos el essid,en este caso, para descubrir el ESSID deberíamos esnifar y esperar a que un cliente se
conectara, y veríamos el ESSID en la trama PROVE REQUEST del cliente (en el caso
de que no se manden BEACON FRAMES), o en la trama PROVE RESPONSE del AP.
Pero también podemos “provocar” la desconexión de un cliente, utilizando el mismo
método que en el ataque DoS, pero mandando sólo una trama de desasociación o de
desautentificación en lugar de mandarlas repetidamente, es decir, nos ponemos la
dirección física del AP y mandamos una trama DEAUTH o DISASSOC a la dirección
MAC del cliente (o a la de broadcast), entonces el cliente intentará volver a asociarse o
autentificarse, con lo que podremos ver el ESSID en los management frames. Para este fin podemos usar una herramienta muy popular como es essid-jack, tambien para linux.

Ataque Man in the middle:Tambien conocido como "Mono en medio", consiste en convencer al cliente (la víctima) de que el host que hay en el medio (el atacante) es el AP, y hacer lo contrario con el AP, es decir, hacerle creer al AP que el atacante es el cliente.

Para realizar este ataque, primero debemos esnifar para obtener:
- El ESSID de la red (si esta ocultado, usaremos el método anterior)
- La dirección MAC del AP
- La dirección MAC de la victima

Una vez conocemos estos datos, utilizamos el mismo método que en el ataque DoS,
para desautentificar a la víctima del AP real, es decir, el atacante spoofea su MAC
haciéndose pasar por el AP y manda tramas DEAUTH a la victima. La tarjeta wi-fi de la
victima empezará entonces a escanear canales en busca de un AP para poderse
autenticar, y ahí es donde entra en juego el atacante.
El atacante hace creer a la victima que él es el AP real, utilizando la misma MAC y el
mismo ESSID que el AP al que la victima estaba autenticada anteriormente, pero
operando por un canal distinto. Para realizar esto la tarjeta wi-fi del atacante debe estar en modo master, mas adelante veremos que tarjetas pueden estarlo y como hacerlo:)

Por otra parte, el atacante debe asociarse con el AP real, utilizando la dirección MAC de
la víctima.De esta manera hemos conseguido insertar al atacante entre la victima y el AP, veamos como quedaría la WLAN después de realizar el ataque.

Quedaría por tanto así:

Es muy fácil implementar este tipo de ataques utilizando el driver air-jack con la
herramienta monkey-jack.

Ataque ARP Poisoning : El ARP cache poisoning es un ataque que sólo se puede llevar a cabo cuando el atacante está conectado a la misma LAN lógica que las victimas, limitando su efectividad a redes conectadas con switches (aunque curiosamente, no todos), hubs y bridges, pero no routers. La mayoría de los Puntos de Acceso 802.11b,g actúan como bridges transparentes de capa 2, lo que permite que los paquetes ARP pasen de la red wireless hacia la LAN donde está conectado el AP y viceversa. Esto permite que se ejecuten ataques de ARP cache poisoning contra sistemas que están situados detrás del Punto de Acceso, como por ejemplo servidores conectados a un switch en una LAN a los que se pueda acceder a través de la WLAN.

No hace falta comentar las posibles soluciones a este ataque, se ven evidentes?

Veamos un ejemplo:

El servidor PC 1 se comunica con PC 3 a través del switch, si un atacante desde la
WLAN envenena la tabla de ARP’s de PC 1 y de PC 3 podrá realizar un ataque del tipo
"Mono en medio"(visto anteriormente) situándose entre los dos hosts de la red con cables.

Una vez realizado el ataque, veríamos algo así:

El atacante manda paquetes ARP REPLY a PC 2 diciendo que la dirección IP de PC 1 la tiene la MAC del atacante, de esta manera consigue “envenenar” la caché de ARP’s de
PC 2. Luego realiza la misma operación atacando a PC 1 y haciéndole creer que la dirección IP de PC 2 la tiene también su propia MAC. Por como funciona el ARP, ambos pc´s actualizaran sus caches de acuerdo con la información inyectada, en este caso por el individuo piratilla.
Como el switch y el AP forman parte del mismo dominio de broadcast, los paquetes
ARP pasan de la red wireless a la red con cables sin ningún problema. Para realizar el ataque ARP Poisoning, existen múltiples herramientas , ya que este ataque no es específico de las redes wireless, la más famosa es el sniffer
Ettercap (lo hace todo solo:).Podríamos frenar este ataque creando dos VLAN’s en el switch, una para la boca a la que está conectado el AP y la otra para el resto de máquinas. Otra forma de frenarlo sería utilizando tablas de ARP estáticas (La solución mas rápida).

**Existen más tipos de ataques que no se comentan aquí, dado que el principio de funcionamiento está basado en los detallados anteriormente.

Volver arriba

Buscando soluciones.....

Vamos a intentar buscar soluciones a cada uno de estos ataques.

La mejor solución a los ataques del WEP, aunque suene algo ..., es NO Usarlo :), existen más y mejores protocolos que lo pueden sustituir.

Para evitar los ataques de ACL’s basados en MAC , nuevamente lo mas fácil es no autentificar a los usuarios con este método, se puede optar por alguno de los comentados anteriormente.

Los ataques Dos, son bastante mas difícil de evitar, puesto que si se trata de un ataque DOS a nivel de radio, la única solución es cambiar el canal de trabajo, o lacalizar el AP´s que nos está fastidiando, pero no podemos prevenirlo, Los de tipo Dos de toda la vida, algo se puede hacer, basicamente con reglas, IDS,etc.

Una solución para los ataques "Man in the middle", dado la característica principal de este ataque, el ARP, no hay una forma segura al 100% , se pueden emplear monitores ARP, como Arp watch, para intentar localizar operaciones inusules; Igualmente podemos usar IDS(sistemas detectores de intrusos), como snort:). Lo mejor sería emplear soluciones criptográficas que permitan evitar modificaciones en el arp, pero no siempre es factible, como método un tanto paranoico, apuntar a que existen diversas empresas que comercializan hardware de monitorización ARP.

Estos ataques, son los peores a la hora de prevenir y por si fuera poco, existen multitud de ataques que se basan en este, por ejemplo : dnsspoffing, etc.

Volver arriba

Manos a la obra.

Vamos a ver unos ejemplos prácticos de los ataques comentados anteriormente .

1.activamos en modo monitor :

# airmon.sh start ath0
Interface Chipset Driver
ath0 Atheros madwifi (monitor mode enabled)

**Veremos mas adelante las necesidades y configuraciones.

2. Descubrimos algún vecino:)

# airodump ath0 wep-crk 0
BSSID PWR Beacons # Data CH MB ENC ESSID
00:13:10:1F:9A:72 62 305 16 1 48 WEP Compos
BSSID STATION PWR Packets ESSID
00:13:10:1F:9A:72 00:0C:F1:19:77:5C 56 1 Compos

Volver arriba

3.- Crackeando una WEP

Es recomendable tener una partición en FAT32 (Por ser legible con Windows y Linux, ¡quien sabe!) para guardar todos los datos que obtengamos, de unos 3 a 3.5 Gb.

Se ha usado una ZCOM XI-325HP+ .

Preparación de nuestra interfaz WiFi:

(1) Abrimos una consola y escribimos: airmon.sh para detectar las los nombres de las interfaces WiFi de las cuales disponemos.

(2) Selecionamos con la que queremos trabajar y escribimos: airmon.sh start nombredelinterfaz , nos volverá a aparecer la pantalla que nos apareció en (1) pero ésta vez al lado del interfaz que seleccionamos nos aparece (modo monitor activado).

Utilizando Airodump:

(3) Abrimos la consola y nos colocamos en el directorio donde queramos que se guarde la información.

(4) Escribimos en la consola: airodump nombredelinterfaz nombreficherodesalida 0 1 , El primer 0 es para escanear en todos los canales, para uno determinado se pone el número del canal determinado; el 1 es para crear un fichero específico y con la información justa para obtener la clave WEP (se puede omitir el 1).
Cuanto mas paquetes IVs=DATA tengamos mejor.
En cuanto empiecen a llenarse los IVs =DATA en el campo ENC nos dirá el tipo de red que es: WEP, WPA, OPN.
Para detener la captura y guardar pulsamos Ctrl+C.

Inyectamos paquetes para acelerar el tráfico y estimular el envío de IVs con Aireplay:

FAKE AUTENTIFICATION
Intentamos hacer una autentificación falsa haciéndonos pasar por 11:22:33:44:55:66 ésto lo hacemos cuando no hay clientes asociados al equipo.

Abrimos otra consola en la misma ventana y mismo directorio que donde ejecutamos airodump. Los parámetros son: aireplay -1 0 -e Essid -a -b (Bssid del AP ) -h ( Bssid de la estación)( interfaz ) ejemplo: aireplay -1 0 -e Essid Objetivo –a Bssid Objetivo -b Bssid Objetivo -h 11:22:33:44:55:66 ath0.

Algunos puntos de acceso requieren de reautenticación cada 30 segundos, si no nuestro cliente falso será considerado desconectado. En este caso utiliza el retardo de re-asociación periódica: aireplay -1 30 -e "el ssid" -a 00:13:10:30:24:9C -h 11:22:33:44:55:66 ath0

Advertencia: Si sólo coges las beacon frames porque no hay tráfico, es decir con el airodump no detectas nada asociado a tu punto de acceso objetivo y tampoco coges ningún IVs, puedes empezar a olvidarte de desencriptar:)


Si todo ha salido bien aparecerá el mensaje : successsful :-;.
Si ha salido mal te da pistas (y el problema sea la MAC seguramente pero eso con el Ethereal se arregla), tendrías que cambiar la 11:22:33:44:55:66 por una válida.
El (-1 0) indica que es una ataque por fake autentification.
Si no te has asociado no podrás acelerar el proceso y para pasar al paso siguiente (AIRCRACK) debes esperar mas tiempo a que crezcan los paquetes buenos.

INYECCIÓN DE PAQUETES
Si nos ha fallado el punto (5) pero con airodump ves que hay clientes asociados al punto de acceso, después de "-h" pones la dirección MAC del cliente asociado (recuerda que si no hay tráfico estas perdido).

(6) Mismo comando que para el (5) pero con excepciones:
ejemplo: aireplay - 3 – b Bssid Objetivo -h 11:22:33:44:55:66 ath0 x 600 nombrefichero_de_salida.cap
Hay que añadir el parámetro – x ordenado, de un valor que se corresponde al total de paquetes por segundo que el aireplay vaya a injectar. Aquí 600. Ponga más o menos siguiendo si la potencia (fuerza) de la señal del AP es más o menos fuerte.

Verás como los IVs=DATA y ARP van subiendo, como máximo aireplay guarda a 1024 tipos de ARP.

Utilizando Aircrack

Ten en cuenta que cuanto mas tráfico tenga la red mejor, es mas como has podido comprobar con aireplay lo que se genera es tráfico.


(7) Abre otra consola en la misma ventana y colocate en el mismo directorio donde hiciste lo del airodump y lo de aireplay.
El comando es el siguiente: aircrack - x - 0 - f 3 nombreficherodesalida.cap , el aircrack puede usar *.cap y *.ivs, el parámtero – x obia los dos últimos bits al aplicar fuerza bruta para ser mas rápido.
Seleccionas el número de la red a desencriptar pulsar intro y comienza la búsqueda, cuando acabe si la ha encontrado aparecerá en rojo en hexadecimal y si no te dice porqué ha podido fallar, durante este proceso airodump continúa añadiendo paquete que aircrack usa, si no has conseguido la clave deja corriendo airodump y ejecuta un par de veces mas aireplay.

Si tenemos varios archivos generados por el aireplay hacemos lo siguiente: aircrack -x -0 nombrearchivosalidaaireplay1.cap nombrearchivosalidaaireplay2.cap y así sucesivamente

Utilizando el Ethereal

Por si la red tiene desactivado el dhcp y tiene activo un filtrado de MAC.
En la inmensa mayoría se trata de 192.168.1.xxx
De todas formas estos son los pasos a seguir:
(8) Abrimos el Ethereal. Edit -> Preferences -> protocols -> IEEE802.11
Metemos en WEP key #1: La clave obtenida y seleccionas la pestaña: Assume packets have FCS. OK.

(9) Vamos a Capture -> Options
Escogemos la interfaz (ath0).
Seleccionamos el compartimiento (captura paquetes in promiscuous modo).
Seleccionamos el compartimiento (enable network name resolución).

(10) Para fijarnos sólo a los que interesan aplicamos un filtro en el compartimiento (filter).
Un filtro de tipo (wlan.bssid == bssid del ap) ** (TCP)

Tan solo 12 minutos y bingo !

Para ver como se explota esta vulnerabilidad con un pentest(Auditor), pincha Aquí.

Por aquí otra con más salero :)

Volver arriba

Deautentificación, haciendo enemigos:)

Este ataque puede ser usado para recuperar un SSID oculto (por ejemplo, uno que no sea broadcast), capturar un WPA o forzar una Denegación del Servicio. El objetivo del ataque es forzar al cliente a reautentificarse, lo que unido a la falta de autentificación hace posible que el atacante consiga hacer spoof de las direcciones MAC.

Un cliente wireless puede ser deautentificado usando el siguiente comando, que hace que se envíen paquetes de deautenticación desde el BSSID al cliente MAC haciendo spoofing del BSSID:

# aireplay -0 5
-a 00:13:10:1F:9A:72
-c 00:0C:F1:19:77:5C
ath0

Se puede lograr una deautentificación masiva, aunque no siempre es fiable, haciendo que el atacante esté haciendo spoofing constante del BSSID y reenviando el paquete de deautentificación a la dirección broadcast:

# aireplay -0 0
-a 00:13:10:1F:9A:72
ath0

Volver arriba

Como Desencriptamos paquetes de datos WEP sin conocer la clave:

Este ataque está basado en la herramienta llamada chopchop, que puede desencriptar paquetes encriptados con WEP sin conocer la clave. El chequeo de integridad implementado en el protocolo WEP permite que el atacante pueda modificar tanto un paquete encriptado como su correspondienteCRC.

Veamos como podemos llevar a la práctica esto :

# aireplay -4 -h 00:0C:F1:19:77:5C ath0
Read 413 packets...
Size: 124, FromDS: 0, ToDS: 1 (WEP)
BSSID = 00:13:10:1F:9A:72
Dest. MAC = 00:13:10:1F:9A:70
Source MAC = 00:0C:F1:19:77:5C
0x0000: 0841 d500 0013 101f 9a72 000c f119 775c .A.......r....w\
0x0010: 0013 101f 9a70 c040 c3ec e100 b1e1 062c .....p.@.......,
0x0020: 5cf9 2783 0c89 68a0 23f5 0b47 5abd 5b76 \.'...h.#..GZ.[v
0x0030: 0078 91c8 adfe bf30 d98c 1668 56bf 536c .x.....0...hV.Sl
0x0040: 7046 5fd2 d44b c6a0 a3e2 6ae1 3477 74b4 pF_..K....j.4wt.
0x0050: fb13 c1ad b8b8 e735 239a 55c2 ea9f 5be6 .......5#.U...[.
0x0060: 862b 3ec1 5b1a a1a7 223b 0844 37d1 e6e1 .+>.[...";.D7...
0x0070: 3b88 c5b1 0843 0289 1bff 5160 ;....C....Q`
Use this packet ? y
Saving chosen packet in replay_src-0916-113713.cap
Offset 123 ( 0% done) | xor = 07 | pt = 67 | 373 frames written in 1120ms
Offset 122 ( 1% done) | xor = 7D | pt = 2C | 671 frames written in 2013ms
(...)
Offset 35 (97% done) | xor = 83 | pt = 00 | 691 frames written in 2072ms
Offset 34 (98% done) | xor = 2F | pt = 08 | 692 frames written in 2076ms
Saving plaintext in replay_dec-0916-114019.cap
Saving keystream in replay_dec-0916-114019.xor
Completed in 183s (0.47 bytes/s)

La tarjeta wireless debe estar situada en modo monitor, en el canal adecuado. Aireplay pedirá al atacante que acepte los paquetes encriptados (como vemos arriba). Se crean dos ficheros pcap: uno para los paquetes desencriptados, y otro para su flujo de datos correspondiente. El archivo resultante puede ser legible usando tcpdump, como sigue:

Leyendo el fichero ...

# tcpdump -s 0 -n -e -r replay_dec-0916-114019.cap
reading from file replay_dec-0916-114019.cap, link-type IEEE802_11 (802.11)
11:40:19.642112 BSSID:00:13:10:1f:9a:72
SA:00:0c:f1:19:77:5c DA:00:13:10:1f:9a:70
LLC, dsap SNAP (0xaa), ssap SNAP (0xaa), cmd 0x03: oui Ethernet (0x000000),
ethertype IPv4 (0x0800): 192.168.2.103 > 192.168.2.254:
ICMP echo request, id 23046, seq 1, length 64

Una vez capturado el flujo de clave, es posible imitar cualquier paquete.
Aquí tenemos una petición ARP enviada desde 192.168.2.123 (00:0C:F1:19:77:5C) a 192.168.2.103:

# arpforge \
replay_dec-0916-114019.xor \
1 \
00:13:10:1F:9A:72 \
00:0C:F1:19:77:5C \
192.168.2.123 \
192.168.2.103 \
forge-arp.cap

Finalmente aireplay se usa para volver a ejecutar este paquete:

Ejecutanto el paquete falso:)

# aireplay -2 -r forge-arp.cap ath0
Size: 68, FromDS: 0, ToDS: 1 (WEP)
BSSID = 00:13:10:1F:9A:72
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:0C:F1:19:77:5C
0x0000: 0841 0201 0013 101f 9a72 000c f119 775c .A.......r....w\
0x0010: ffff ffff ffff 8001 c3ec e100 b1e1 062c ...............,
0x0020: 5cf9 2785 4988 60f4 25f1 4b46 1ab0 199c \.'.I.`.%.KF....
0x0030: b78c 5307 6f2d bdce d18c 8d33 cc11 510a ..S.o-.....3..Q.
0x0040: 49b7 52da I.R.
Use this packet ? y
Saving chosen packet in replay_src-0916-124231.cap
You must also start airodump to capture replies.
Sent 1029 packets...

Volver arriba

Autentificación Falsa, Disfrazandonos:)

El método de crackeado de la clave WEP descrito anteriormente requiere un cliente , asociado con el punto de acceso para asegurarse de que el punto de acceso no rechace los paquetes por una dirección de destino no asociada. Si se utiliza autentificación abierta, cualquier cliente podrá ser autentificado y asociado con el punto de acceso, pero el punto de acceso rechazará los paquetes no encriptados con la clave WEP correcta. Utilizamos Aireplay para imitar una petición de autentificación y asociación para el SSID Compos (BSSID: 00:13:10:1F:9A:72) con la dirección MAC falseada 0:1:2:3:4:5.

# aireplay -1 0 -e Compos-a 00:13:10:1F:9A:72 -h 0:1:2:3:4:5 ath0
18:30:00 Sending Authentication Request
18:30:00 Authentication successful
18:30:00 Sending Association Request
18:30:00 Association successful

Volver arriba

Metiendo mano a WPA.

Ninguna de las vulnerabilidades es peligrosa si se siguen unas mínimas recomendaciones de seguridad. La vulnerabilidad más práctica es el ataque contra la clave PSK de WPA/WPA2. La PSK proporciona una alternativa a la generación de 802.1X usando un servidor de autentificación, pero queda en evidencia que es mejor solución emplear un servidor radius.

Vamos a ver quien hay ....

# airodump ath0 wpa-crk 0
BSSID PWR Beacons # Data CH MB ENC ESSID
00:13:10:1F:9A:72 56 112 16 1 48 WPA Compos
BSSID STATION PWR Packets ESSID
00:13:10:1F:9A:72 00:0C:F1:19:77:5C 34 1 Compos

Debemos entonces deautentificar los clientes

Así forzándolos a iniciar un nuevo proceso de autenticación y permitiéndonos capturar los mensajes llamados 4-Way Handshake. Aireplay se usa para este ataque, y deautentificará al cliente deseado con la BSSID especificada enviándole una petición de desautentificación falsa:

# aireplay -0 1 -a <BSSID>
-c <client_mac> ath0

Lanzamos un ataque de diccionario

$ aircrack -a 2 -w some_dictionnary_file -0 wpa-psk.cap
Opening wpa-psk.cap
Read 541 packets.
BSSID ESSID Encryption
00:13:10:1F:9A:72 Compos WPA

Vemos como una clave WPA débil ha sido encontrada .

Otro tipo de ataque a WPA

Esta vulnerabilidad, quizas sea la más importante en WPA.

La otra debilidad WPA es una posibilidad de Negación del Servicio
durante el 4-Way Handshake.El primer mensaje del 4-Way Handshake no está autentificado, y cada cliente tiene que guardar cada primer mensaje hasta que reciban un tercer mensaje válido (firmado), dejando al cliente potencialmente vulnerable. Haciendo un spoofing del primer mensaje enviado por el punto de acceso, un atacante podría realizar un ataque DoS.

Veamos un ejemplo de configuración del archivo Wpa_supplicant para WPA2:

ap_scan=1 # Analiza frecuencias de Radio y selecciona punto § de acceso apropiado
network={ # Primera red inalámbrica
ssid="some_ssid" # SSID de la red
scan_ssid=1 # Envía petición de prueba para encontrar SSID ocultos
proto=RSN # RSN para WPA2/IEEE 802.11i
key_mgmt=WPA-PSK # Autenticación de la clave pre-compartida
pairwise=CCMP # Protocolo CCMP(encriptación AES)
psk=1232813c587da145ce647fd43e5908abb45as4a1258fd5e410385ab4e5f435ac
}

El lugar por defecto de la configuración de wpa_supplicant es /etc/wpa_supplicant.conf

El daemon wpa_supplicant debería primero lanzarse con privilegios
de root en modo debug (opción -dd), con el controlador adecuado (en nuestro ejemplo es -D madwifi para soportar el chipset Atheros), el nombre de la interfaz (opción -i, en nuestro caso ath0) y la ruta del fichero de configuración (opción -c):

# wpa_supplicant
-D madWi-Fi
-dd -c /etc/wpa_supplicant.conf
-i ath0

Pese a esto, WPA2 es bastante seguro, y seguramente será empleado como estandar definitivo en el 802.11i.

Si quieres ver como se hace un ataque WPA con un pentest(distro linux especializada n wireless), pincha Aquí .

Volver arriba

Ataque DOS a lo Bestia.Que hacer con ->

Para realizar una denegación de servicio de radio, existen basicamente dos drivers:

wlan-jack y Dassoc

El primero pertenece a la colección de programas de air-jack. Sirve para las tarjetas Prism II (HFA384x), y es posible cambiar la dirección Mac, así como hacer FakeAP, que es lo que vamos a ver a continuación:

Interfaz del programilla:)

Comprobamos con AiroPeek lo que se está cociendo --->

Podemos observar claramente lo siguiente:

Vamos a ver, solo por curiosidad, como es una trama de desasociación:

Antes del ataque, estábamos conectados, pasando en rato:

Ejecutamos el ataque y !!

sin comentarios:)

Volver arriba

Ataque DOS Mas Elegante.

Podemos usar esta misma técnica para realizar un ataque de tipo "Man in the middle", veamos pues:

Volver arriba

Rompiendo ACL´S Basados en Mac

Primero cambiaremos la Mac de nuestra tarjeta por una que esté en dicha lista del AP, luego hechamos al replicante y listo.

Empezamos capturando tráfico en modo promiscuo con Ethereal :

Para ello configuramos minimamente el ethereal, basicamente ponemos un filtro "arp".

Aquí vemos la captura de las peticiones Arp:

Para conseguir la Mac de un modo fácil, basta con hacer un ping a la dirección elegida, luego un arp-a, cambiamos y listo:

veamos que Dirección física tiene el 172.26.0.100 :

La dirección Mac la podemos cambiar facilmente con algún software tipo etherchange,etc: esto en linux se haría de forma nativa :)

No necesitamos "tirar" al replicante, dado que el AP, no detecta que hay dos clientes con la misma Mac, aun así si lo queremos hacer, solo tendríamos que desasociarlo del AP.Para ello podemos usar mismamente un programa de linux como Void11:)

Que más podemos hacer con Void--->Aquí

Volver arriba

Descubriendo Essid Ocultos

Para este fin, emplearemos essid-jack, como solución más rápida, aunque tambien se puede hacer con un simple sniffer, tipo Ethereal, eso si con un poco mas de paciencia:)

En realidad con el sniffer, deberíamos capturar las tramas PROVE REQUEST, pero he comprobado personalmente, que capturando con el filtro que sigue, va como la seda:

Podemos apreciar en la misma imagen, que el ethereal tambien contiene filtros para el vector de inicializacion , etc.

Una solución más rápida, consiste en usar Essid-Jack :

Como podemos apreciar a continuación, el Essid salta a la vista:)

Volver arriba

Arp Poisoning, haciendo de jefe

Este tipo de ataque es muy común, es por ello que exiten muchas versiones diferentes del mismo, un ataque típico consiste en hacer lo siguiente:

Usamos para ello otra herramienta de air-Jack, en concreto el Kracker- Jack.

Este ataque incluso puede funcionar si tenemos implementada un VPN con Ipsec, de forma poco ortodoxa.

Este ataque no lo llevaremos a la práctica, por ser bastante más complicado, pues requiere determinados elementos hardware, si vamos a ver a continuación un ataque bastante curioso.

Volver arriba

Ataque teórico a EAP-TLS

Requiere la posesión de certificados por parte del cliente y del servidor de autentificación, el proceso de autentificación comienza con el envío de su identificación (nombre de usuario) por parte del solicitante hacia el servidor, tras esto es servidor envía su certificado al solicitante, tras validarlo, responde con el suyo propio.Si el certificado del usuario es válido, el servidor responde con el nombre de usuario antes enviado y se comienza la generación de la clave de cifrado, la cual es enviada al AP por el servidor, comienza así la comunicación segura:)

Estructura de dicha red.

En la fase de indentificación, el cliente envía el mensaje sin cifrar, permitiendo a un posible atacante, usar un sniffer y capturar la identidad del que trata de conectarse.

De la misma forma el envío de la aceptación de la conexión se realiza sin cifrar, con lo que podemos reenviar este tráfico, causando así un ataque DOS.

Volver arriba

Molestando con Rogue AP

Este tipo de "ataque", aunque realmente no es un ataque, consiste en colocar un AP bajo nuestro control, cerca de las instalaciones de la victima, de forma que los cliente asociados a éste se conecten a nuestro AP, en lugar del que debería ser, debido a la mayor señal de nuestro Ap.

Una ilustración para entenderlo mejor:)

Una vez conseguida la asociación al rogue AP, el atacante puede provocar un ataque DOs, robar datos, etc.

Se suele emplear esta ataque para: crear puertas traseras, espiar, etc

Para montar un Rogue AP, podemos usar un AP modificado, o simplemente nuestro portátil, para ello necesitamos que la tarjeta soporte modo master, dado que tiene que poder funcionar como AP, usaremos la herramienta airsnaf,pues ella sola lo automatiza todo, sino, tendríamos que poner el portátil para que funcionase como servidor http, servidor DNS, servidor dhcp y configurar un portal cautivo, pero airsnaf lo hace todo y mas:)

Una vez el usuario introduce la contraseña en el portal cautivo, el atacante ya la tiene en su poder.El usuario no se da cuenta, puesto que se modifica previamente la apariencia del portal cautivo, para que sea igual a la legítima.

Este método tiene muchas vertientes, se usa el famoso Radius-Radius, basicamente, se añade un servidor radius.

Volver arriba

Érase un Fake-AP .........

Si existe gente, y apropósito, existe!!, que tenga ganas de tocar los...., pueden hacernos templar con Fake-Ap, veamos como va esto.

Apreciamos la pantalla principal.

En funcionamiento.......................

Vemos el resultado........................

La verdad es que no tiene mucho mas que comentar :(

Volver arriba

Breves conceptos sobre chipset y configuraciones

Chipset:

Las tarjetas Wi-Fi utilizan un chipset u otro según fabricante. Es posible que el mismo fabricante comercialice tarjetas con chipsets distintos, para hacernos una idea
estos son los chipsets más comunes:

• Hermes (Lucent)
– Lucent / Agere / Orinoco

• Orinoco, Avaya, Compaq, Lucent

• Prism 2 / 2.5 / 3 (Intersil)

• D-Link, Linksys, Netgear, SMC, USR, Conceptronic

Nota: El firmware tiene propiedades de AP, por tanto es posible configurar la
tarjeta para que trabaje como si fuera un Punto de Acceso (modo Master).

• Airo (Aironet)
– Cisco

• TI ACX100 (Texas Instruments)
– 3Com / USR, D-Link, Wisecom, Eusso, Linksys (WAP11 v2.2)

Modos: Los modos más comunes que aceptan las tarjetas wi-fi son Ad-Hoc, Managed, Master, y monitor.

• Ad-Hoc: conectar dos PC’s sin AP

• Managed: Tarjeta asociada con un AP

• Master: La tarjeta trabaja como un AP , se necesita el hostAP y *SÓLO FUNCIONA CON CHIPSET PRISM*

• Monitor: Permite capturar paquetes sin asociarse a un AP o a una red ad-hoc.
– Monitoriza un canal especifico sin transmitir paquetes
– No es lo mismo que el modo promiscuo

Chipset PRISM: Sin problemas
Chipset Orinoco: Parche http://airsnort.shmoo.com/orinocoinfo.html

Nota: Es importante darse cuenta, de que las tarjetas que traen los portatil integrada, normalmente BG2200, BG2100,ABG2915 (En toshiba sobre todo), estas tarjetas no pueden (de momento), inyectar paquetes, con lo que tienes ciertas limitaciones, Igualmente no admiten Mod Master, etc.

Volver arriba

QOS (Calidad de Servicio), El que no tenga prisa, que espere.

Aunque no tienes mucho que ver con la seguridad, si voy a hablar un poco de QOS, porque merece la pena:)

Consiste en un conjunto de técnicas utilizadas para aumentar la eficiencia
de las comunicaciones.Es bastante molesto cuando en una red , la gente utiliza programas p2p,etc, entonces todo se relentiza :(

Entre las diferentes técnicas conocidas de QoS destacan por su simplicidad
y eficiencia los “Traffic Shapper” y la utilización de proxys (Squid) para
diferentes tipos de servicios.

NocatAuth: es muy restrictivo, diferencia basicamente 4 tipos de usuarios: propietario, usuarios con Login, invitados, sin login.

Como práctica, mas adelante implementaremos un un NocatAuth bajo linux.

Volver arriba

Instalación NocatAuth Gracias a OlotWireless.

En primer lugar debemos tener claro que es lo que vamos a hacer y para que sirve. Un "gateway" se utiliza para "dejar pasar" a través de nuestra máquina o servidor a determinados usuarios de nuestra red local hacia internet o hacia otra subred.

Lo que vamos a intentar resolver, es el problema de que la gente p2p sature la conexión a internet, para ello, podremos asignar prioridades, y hacer una lista negra de usuarios saturadores:)

Graficamente es algo así.

Empezamos instalando una distro de linux, aquí usaremos el Fedora Core, una vez instalado, configuramos la red, esto es:

Es importante activar la opcion de "Activar el dispositivo cuando el ordenador se inicie" para que cuando reiniciemos nuestro PC active directamente la tarjeta de Red (posteriormente haremos lo propio con eth1). Configuramos ahora la tarjeta con una IP libre del mismo rango que la LAN de nuestro router ADSL, la submascara y la puerta de enlace (generalmente la IP de nuestro router). Aunque en nuestro router tengamos habilitado el DHCP no es aconsejable usarlo ya que necesitamos usar siempre una misma IP.

Vamos ahora a configurar el servidor de DNS y el nombre del host.

En nuestro caso, en la imagen utilizamos la IP del propio router como servidor de DNS pero solo por conveniencia de nuestra configuracion ya que disponemos de otros servicios ubicados en nuestra subred.

Configuramos ahora eth1 con la IP con la que queramos trabajar.Es importante NO DEFINIR la puerta de enlace.

Estamos ya en disposicion de comprobar si disponemos de conexion a internet. Tras reiniciar nuestro PC para asegurarnos que los cambios han surgido efecto, Comprobamos.....

Una vez asegurada la conexion a internet y definida cual es la tarjeta eth0. Podemos ya conectar el cable de nuestra red interna (Punto de Acceso) a la tarjeta libre, en este caso eth1 y reiniciar nuestro ordenador.

El siguiente paso va a ser configurar y poner en marcha un servidor DHCP para que nuestro servidor "gateway" proporcione los datos de conexión (IP,Mascara de Red,Puerta de enlace,Servidor DNS etc...) necesarios para nuestros "clientes" de forma automatica. Para ello lo primero que deberemos hacer sera ir a buscar el fichero de ejemplo de configuración dhcpd.conf.sample en /usr/share/doc/dhcp-3.1.0.1/ .

Una vez localizado, lo pegamos en /etc/

posteriormente lo editamos :

Cambiando IP y mascara.....

Ahora le definimos el nombre de dominio que utilizamos en nuestro servidor y la IP del servidor de DNS.

El siguiente paso consiste en establecer el rango de IP que nuestro servidor "ofrecera" a nuestros clientes. En este caso cualquier IP entre 10.34.122.201 y 10.34.122.254.

Y ahora una opción muy interesante en el caso de que queramos dar IP "fijas" a determinados clientes. Con lo configurado hasta ahora nuestro servidor "ofrece" IP aleatorias a nuestros "clientes" y que, al cabo de determinado tiempo de inactividad quedan "liberadas" y pueden ser usadas por otro cliente. En esta opción podemos determinar que, basandonos en la MAC del cliente en cuestion, los clientes que aparezcan en esa lista tengan SIEMPRE la misma IP. Con lo cual podemos establecer determinados servicios "estables" en distintas máquinas dentro de nuestra red interna como veremos en capitulos posteriores.Decir que este método no es muy seguro, pero...

Una vez modificado , guardamos y vamos a activar el servicio en Inicio/Configuraciones del Sistema/Configuraciones del Servidor/Servicios

Activamos el servidor DHCP.

Si no nos ha dado ningun error tenemos ya funcionando nuestro servidor DHCP. Para verificarlo bastara con que desde un ordenador "cliente" intentemos la conexion "Automatica" con nuestro Punto de Acceso y observemos si nos ha asignado la IP, Puerta de enlace, Mascara de Red, Servidor DNS etc... correspondientes. Algo parecido a esto:

Nota: la imagen es meramente orientativa

Una vez realizada la prueba, vamos de nuevo a Inicio/Configuraciones del Sistema/Configuraciones del Servidor/Servicios y activamos (si es que no lo estan ya) los siguientes:

httpd: El servidor web Apache

iptables: Tablas de enrutamiento de IP

mysqld: Servidor MySQL

Una vez activados guardamos la configuración y, desde nuestro ordenador cliente, vamos a comprobar si funciona el servidor Web (httpd). Los servicios de IPtables y MySQL los verificaremos posteriormente ya que, de momento, no son imprescindibles para lo que nos interesa hacer en este momento.

Abrimos pues la ventana de nuestro navegador en nuestro ordenador cliente y en la barra de navegacion escribimos:

http://10.34.122.1

y nos aparcera algo parecido a esto:

Por tanto, Todo correcto:)

Vamos ahora a configurar nuestro puente de red. Hasta aquí hemos configurado la parte básica de lo que va a ser nuestro "gateway" y ahora vamos ya a empezar la parte "importante", es decir, la parte que nos permitirá que nuestros "clientes" pasen a través de nuestra máquina y que es esencial para que luego, al instalar NoCatAuth nos funcione todo correctamente.

Lo primero que vamos a hacer va a ser decirle a nuestra máquina que cualquier petición que llegue a eth1 de nuestra máquina la enrute hacia eth0.

Para ello vamos a /etc/rc.d/ y en el fichero rc.local añadimos la linea siguiente:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Guardamosy seguimos.Ahora en /etc/ buscamos sysctl.conf y modificamos la siguiente linea:

net.ipv4_ipforward = 0 por net.ipv4_ipforward = 1

A continuación en /etc/ buscamos named.conf e incluimos la siguiente linea en el final de la rama Options para que quede mas o menos asi:

options{

//otras lineas y opciones//

forward only;

forwarders{195.235.113.3; 195.235.96.90;};

};

en este caso corresponden a las IP de los servidores de DNS de Telefónica, aunque ahí podeis poner las IP de los servidores de DNS que vayais a usar.

Vamos ahora a deshabilitar todas las opciones de seguridad. NoCatAuth nos proporcionara las que necesitamos.

Ir a Inicio/Configuraciones del sistema/Nivel de Seguridad

Ahora paso IMPORTANTE en /etc/sysconfig/ borrar los ficheros de configuracion iptables , iptables.save y iptables-config .

El siguiente paso deberemos de hacerlo desde una ventana del Terminal para limpiar y comprobar que nuestro IPtables esta "limpio". Abrir una ventana del Terminal yendo a Inicio/Herramientas del sistema/Terminal y ejecutar:

/etc/init.d/iptables restart

Os dira algo parecido a esto:

Comprobar si la tabla de IP esta ya limpia escribiendo en la misma ventana del terminal:

iptables -L -n

deberia de aparecer algo parecido a esto:

Con esto nos aseguramos que tenemos nuestra tabla de IP "limpia" para que, cuando posteriormente reiniciemos nuestro ordenador, aplique solamente el contenido definido para nuestro puente de red, es decir, la linea iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE que hemos definido en /etc/rc.d/rc.local .

La cosa va de Paquetes:)

Vamos ahora a comprobar si tenemos instalados los paquetes DBI, Perl y GnuPGP. En caso de no tenerlos los instalamos . Para saberlo utilizaremos el comando "locate" desde la ventana del terminal haciendo, por ejemplo, locate DBI. Si es la primera vez que lo usamos nos pedira que creemos la base de datos de todos los paquetes que tengamos en nuestra máquina. Esto se hace tecleando: locate -u .Esto tardara unos 5 minutos en hacerlo pero habra valido la pena ya que posteriormente nos ahorrara mucho tiempo en localizar paquetes en nuestra máquina.

Una vez que tengamos esto instalado, para hacer funcionar correctamente nuestro NocatAuth básico necesitaremos instalar 2 paquetes adicionales de Perl que no vienen habitualmente en las instalaciones de Fedora : Digest::MD5 y Net::Netmask

Para instalar el paquete Net::Netmask podemos hacerlo de forma facil utilizando el yum la herramienta de instalacion y actualizacion de paquetes que usa Fedora. Bastara con escribir en una ventana del terminal: yum install perl-Net-Netmask y el paquete se instalara automaticamente:)

Para instalar el paquete Digest::MD5 tendremos que hacerlo desde CPAN que es, de hecho, la herramienta de Perl para la instalacion de nuevos paquetes de Perl.

Para ello, desde la ventana del terminal tecleamos:

perl -MCPAN -e 'install Digest::MD5'

Esto, al ser la primera vez que se usa, tendremos que configurarlo, se hace largo :(

Una vez instalados y configurados los anteriores pasos ya tenemos instalado todo lo necesario a excepción de NoCatAuth y estamos ya en disposicion de reiniciar el ordenador y comprobar si desde el Punto de Acceso tenemos conexión a Internet a través del puente de red que hemos instalado entre las dos tarjetas.

Comprobamos pues.......

Todo ----->OK

Nos bajamos la ultima version de NocatAuth desde http://nocat.net/downloads/NoCatAuth/NoCatAuth-nightly.tgz y lo instalamos.

Debemos editar el fichero detect-fw.sh y cambiar en la linea 12 "Linux 2.4" por "Linux 2.6", a no ser que ya tengas la 2.6.

así....

Una vez modificada la linea, guardamos el fichero y volvemos al directorio principal de NoCatAuth-nightly

Ahora debemos ir a /usr/local/ y crear una carpeta con el nombre nocat.Una vez hecho esto estamos ya en disposicion de iniciar la instalacion propiamente dicha de nuestro NoCatAuth. Para ello ejecutaremos desde la ventana del Terminal (siempre desde /root/NoCatAut-nightly) :

make PREFIX=/usr/local/nocat/gw gateway

Ahora repetimos tecleando:

make PREFIX=/usr/local/nocat/authserv authserv

Ahora vamos a borrar trustedkeys.gpg , que es la key que lleva por defecto NoCatAuth, de /usr/local/nocat/authserv/pgp/ y de /usr/local/nocat/gw/pgp/

Apropósito :) ahora crearemos nuestra key personalizada. Para ello desde /root/NoCatAuth-nigtly/ teclearemos:

make PREFIX=/usr/local/nocat/authserv pgpkey

Nos preguntara que tipo de key queremos. Elegimos la primera opcion: DSA i ElGamal, El tamaño de la Key, mismamente el valor por defecto.Confirmamos y ahora nos preguntara por la validez de la key, le marcamos 0 (cero), es decir, que no caduque.Nos pregunta por el nombre y apellidos. Aqui podeis poner cualquier cosa ya que solo hara con este dato y los dos siguientes una combinacion para generar la key.

Lo siguiente que nos pregunta es la direccion de correo. Lo mismo que antes...cualquiera sirve.

Ahora nos pide un comentario. Al igual que en los dos casos anteriores podeis poner lo que os plazca.

Una vez le dais al enter os preguntara si estais de acuerdo con los datos de entrada. Aqui es un poco lioso el responder, asi que debeis de teclear:

ixO

Le dais a enter y el programa se tomara su tiempo para generar vuestra key.Finalmente ya teneis la nueva key en /usr/local/nocat/authserv/

Ahora vamos a copiar vuestra key y colocarla en /usr/local/nocat/gw/pgp/ y en /usr/local/nocat/authserv/pgp/ sustituyendo a la de origen que hemos borrado previamente.

Una vez copiada en las carpetas correspondientes vamos a darles los permisos para que posteriormente el servidor Apache pueda acceder a ella para verificar la autenticidad de las conexiones. Esto podemos hacerlo de dos formas. Desde la ventana del Terminal tecleando:

chown -R apache:apache /usr/local/nocat/authserv/pgp

chown -R apache:apache /usr/local/nocat/gw/pgp

Procedemos a configurar nuestro querido NoCatAuth....

Para ello vamos a crear nuestra base de datos mysql donde quedaran registrados todos los datos y permisos de nuestros usuarios.

Abrimos la ventana del Terminal y nos ubicamos en /root/NoCatAuth-nigthly tecleando cd /root/NoCatAuth-nightly

Una vez en el directorio lo primero que vamos a hacer va a ser crear un password para acceder a mysqladmin que es el encargado de crear las bases de datos en mysql . De esta forma, aunque en principio os parezca un engorro, os asegurais de que nadie os pueda modificar vuestras bases de datos. Asi pues tecleamos:

mysqladmin password fifafa

una vez creado tecleamos:

mysqladmin create nocat -p

nos pedira el password que hayamos configurado en el paso anterior.Se lo damos y ahora tecleamos:

mysql nocat <etc/nocat.schema -p

nuevamente nos pedira el password. Una vez se lo demos veremos como es copiada la estructura de la base de datos de NoCatAuth en la base de datos mysql.

Ahora tecleamos:

mysql -u root -p

para entrar en la base de datos :

grant all on nocat.* to nocat@localhost identified by 'nocatauth';

Permitimos el aceso al usuario nocat de nuestra máquina (localhost) siempre y cuando se identifique como nocatauth. Este parámetro puede ser cambiado (y de hecho es aconsejable hacerlo) y tiene su origen en la configuración que haremos posteriormente al nocat.conf o fichero de configuracion de NoCatAuth.

Finalmente podemos ya salir de mysql no sin antes cancelar los privilegios en mysqladmin tecleando:

flush privileges;

y finalizamos saliendo de MySQL con:

quit

Vamos ahora a comprobar que realmente funciona:)

Para ello accederemos a nuestra base de datos tecleando desde el terminal:

mysql -u nocat -pnocatauth

Una vez dentro de MySQL entramos en la base de datos de nocat con:

use nocat;

y una vez dentro le pedimos que nos muestre las tablas creadas a partir de nocat.schema

show tables;

Nos sale algo como esto:

Salimos y continuamos la configuración.

Vamos ahora a configurar propiamente NoCatAuth en base a la configuración que queramos dar a nuestro "gateway". Para ello iremos a Inicio y desde ahi a /usr/local/nocat/authserv .Vamos a editar este fichero.

Lo primero que vamos a cambiar es la url de la página por defecto a donde nuestro nuestro NoCatAuth va a redirigir a los usuarios que intenten acceder a los servicios (p. ej internet) de nuestra red.

Lo siguiente a definir es la IP del "gateway" de nuestra red externa, es decir, la parte que sera "inaccesible" desde la red local a menos que los usuarios de la red local se autentifiquen. Añadiremos también (aunque no es esencial) el rango.

El siguiente paso sera verificar la base de datos definida. Debe de ser DBI

y, seguidamente verificar el nombre de la base de datos, el usuario y el password que dimos anteriormente al crear la base de datos MySQL, en este caso nocatauth . Por eso os comentabamos la necesidad de cambiarlo ya que, de lo contrario, cualquiera puede deducir que tengais el password :)

Finalmente solo nos queda, si así lo queremos, traducir las frases de respuesta automática al castellano o al idioma que queramos.

A continuación vamos a modificar el nocat.conf de /usr/local/nocat/gw . Igual que hicimos anteriormente nos vamos a la ubicacion desde Inicio /usr/local/nocat/gw

Editamos por tanto el nombre que le queramos dar al "Gateway", lo siguiente sera el modo en que queramos que trabaje nuestro Gateway. En principio vamos a configurarlo como "Passive" .

Editamos ahora la IP interna del servidor, es decir la IP correspondiente a la tarjeta de red de nuestra red interna (eth1):

Lo siguiente va a ser definirle que tarjeta va a realizar las funciones de red interna y cual las de red externa. De hecho podriamos omitir la configuracion para que la detectara automaticamente pero, en la práctica, sobretodo en máquinas algo antiguas, la detección automática da algunos problemas y ralentiza el arranque de nuestro sistema. Asi pues, para no dejar nada al azar, las definimos nosotros:

ahora toca definir el rango de nuestra red local:

El siguiente paso sera definir la IP de nuestro servidor de DNS. En nuestro caso utilizamos el servidor DNS de nuestro router pero, posteriormente, si habilitamos el servidor de DNS interno de nuestra maquina (la que sea) deberemos definir la IP interna de nuestro servidor, en nuestro ejemplo 10.34.122.1

Ahora definiremos los puertos que queramos habilitar a nuestros usuarios. En nuestro ejemplo lo "cerramos" todo excepto los puertos 22, 80 y 443.

Si quisieramos hacerlo al revés, es decir, permitir "todo" menos los puertos que definamos deberiamos descomentar la siguiente linea. Pero ojo, solo podemos utilizar una de las opciones, es decir, si habilitamos "dejar pasar todo menos..." debemos desabilitar la linea anterior "cortar todo menos..."

Una vez aquí guardamos nuestro nocat.conf

Vamos ahora a configurar el servidor Apache para que redirija las llamadas entrantes hacia nuestro "gateway".El fichero de configuración, httpd.conf, lo encontraremos en /etc/httpd/conf.

Lo siguiente a configurar es la direccion de correo del administrador.

Ahora definimos la IP de la tarjeta de red interna.

Seguidamente definimos el path de "DocumentRoot".

siguiente paso definir nuevamente el mismo path para DocumentRoot para fijarlo como principal.

El siguiente paso consiste en comentar la linea referente al path del ScriptAlias que por defecto Apache ubica en /var/www/cgi-bin/ puesto que posteriormente le definiremos que vaya a buscarlo a las carpetas de NoCatAuth.

Le definimos ahora donde debe ir a buscar el cgi-bin dentro de nocat. En nuestro caso el path sera /usr/local/nocat/authserv/cgi-bin

Una vez modificadas las lineas indicadas podemos ya guardar el httpd.conf .

Vamos ahora a modificar el fichero de configuracion de seguridad SSL para que nos permita el acceso al certificado que nos proporcionara el https. Para ello nos ubicamos en /etc/httpd/conf.d/

Lo editamos como siempre y le indicamos el path de nuestro cgi-bin, en este caso tal y como hicimos antes en el httpd.conf en /usr/local/nocat/authserv/cgi-bin

Guardamos el ssl.conf y apache configurado.

Arrancando NoCatAuth

Vamos ahora a configurar lo que sera el arranque automatico de NoCatAuth cuando reiniciemos nuestro servidor. Para ello nos situaremos en /root/NoCatAuth-nigthly/etc

Copiamos el fichero nocat.rc y lo "pegamos" en /etc/rc.d/

Ahora lo editamos para señalarle el path donde esta el ejecutable de NoCatAuth

Ahora vamos a editar el fichero de arranque rc.local que, si recordais, es el último fichero que "lee" Fedora una vez cargada la configuracion propia .Aquí comentaremos o borraremos la linea que habiamos puesto anteriormente para comprobar el funcionamiento del "puente" entre las dos tarjetas de red.

Y ahora incluimos una linea para que ejecute el fichero rc.nocat y arranque NoCatAuth

Guardamos y ya estamos en disposicion de reiniciar nuestro servidor y comprobar que nuestro "gateway" funcione correctamente.

Vamos ahora a comprobar si realmente lo hemos hecho todo bien y nuestro "gateway" funciona. Tras reiniciar nuestro servidor es interesante observar el arranque del mismo en modo terminal en lugar de en modo gráfico. esto nos servira para que, en caso de algun error, podamos intuir por donde van los "tiros" y donde ubicar el posible error.

Nos aseguramos de que arranca sin darnos ningún tipo de error y podemos ya ir a nuestro "portatil" o PC remoto e intentar la conexión. Asociamos nuestra maquina al SSID de nuestro AP y verificamos que nuestro servidor nos da la IP correspondiente al rango que hayamos definido en el dhcpd.conf .

Ahora abrimos nuestro navegador con nuestra página favorita. Lo primero que debe aparecernos para constatar que vamos por el buen camino es el "Certificado"

Aceptamos pulsando sobre "Si"

Lo siguiente que nos debe aparecer es una ventana pidiendonos el "login" y el "password"

Vamos por el buen camino!. Ahora nos registraremos clicando sobre el "Register here"

Rellenamos los campos E-mail con nuestra dirección de correo electrónico (este sera luego el login para autentificarnos), el campo Nombre y los campos Password y Password Again (6 caracteres o mas)... el resto de campos, si quereis, podeis dejarlos en blanco

Una vez rellenados los campos le damos a "Register" y os aparecera algo parecido a esto.

Pasados unos segundos os devolverá a la página de inicio para que os autentifiqueis. Rellenais los campos con los datos con los que os habeis registrado anteriormente...

Y se os abrira en primer lugar una ventana "miniatura" que sera vuestro "tiquet" de conexión. Es decir, mientras mantengais esta ventana abierta (o minimizada) seguireis estando autentificados todo el tiempo que querais (recordad que hemos configurado nuestro "gateway" en modo "Passive"). Si, por contra, la cerrais, al cabo de un tiempo "x" ,definido en los ficheros de configuracion (en este caso 2700 segundos), os cortara el acceso y debereis volver a autentificaros si deseais seguir utilizando los "servicios" de la red externa. Posteriormente, cuando veamos los distintos tipos de configuración, desarrollaremos todas las posibilidades del sistema.

Casi simultaneamente a la apertura de la ventana anterior se nos abrira una pagina parecida a esta anunciandonos que se nos redirigira a nuestro destino en 5 segundos...

y lo mas importante :)

Y seguimos con la configuración.

Antes de seguir hacia adelante con las configuraciones de NoCatAuth para vuestro gateway vamos a hacer un alto en el camino para presentaros a un amigo que os va a ser de suma utilidad a la hora de administrar vuestro servidor. Webmin es una herramienta muy útil para estos menesteres y que trabaja sobre un entorno Web con paquetes para la gran mayoría de aplicaciones usadas habitualmente, con lo que nos sera mucho mas amigable nuestra relacion con Linux. De ahí que antes de seguir con NoCatAuth hemos querido hacer esta "casi" obligada parada e instalar Webmin en nuestro servidor.

Una vez instalado, y aprovechando para instalar notcat(el módulo).Vamos a acceder por primera vez a Webmin. Para ello abrimos nuestro navegador y tecleamos http://localhost:10000 , es decir, accedemos a Webmin a traves del puerto 10000

Inmediatamente nos aparecera una ventana similar a esta:

Introducimos el login del administrador, es decir "root" y el password habitual

y le damos a "Login". Nos preguntara si queremos que Linux recuerde el "password" las proximas veces que accedamos.. por seguridad es recomendable decirle que NO

Y ya finalmente nos aparece por primera vez el menu de entrada de Webmin.Amor a primera vista:)

Realmente, aunque nosotros nos limitaremos a su utilidad con NoCatAuth y a poco mas seguro que en el futuro os sera una herramienta indispensable para administrar cualquier maquina bajo Linux.

Vamos ahora a cambiarle el idioma clicando en "Change Language and Theme" y nos aparece la ventana de configuración:

Escogemos nuestro idioma y aceptamos:

Vamos ahora a instalar el modulo de Nocat que nos hemos bajado previamente.Para ello vamos a "Configuracion de Webmin"

y desde aqui a "Modulos de Webmin"

Escogemos la ubicacion donde previamente hemos guardado nuestro modulo de Nocat

y lo instalamos

Comprobamos ahora que la instalacion ha funcionado clicando en el icono "Servidores"...

y vemos que, efectivamente, nuestro modulo "NoCat Authentication Gateway" esta ahi. Ahora clicamos sobre el icono del NoCat..

y observamos que nos dice que parece que NoCat no esta instalado. No os preocupeis. Esto es porque el modulo de NoCat esta diseñado por defecto para una instalacion distinta a la que hemos realizado nosotros por motivos de seguridad. Asi pues vamos a cambiar la configuracion para que Webmin "encuentre" nuestro NoCat. Clicamos sobre la pestaña "Configuración del Modulo"

y vereis que los "path" que os aparecen son distintos a los que tenemos nosotros, asi que bastara que los cambieis y los dejeis como los que aparecen en la imagen superior y le deis a "Salvar". En este momento os aparecera ya la ventana de control de NoCat

Le damos un "vistazo" a NoCat Users y vemos como aparecen los usuarios que hemos "registrado" anteriormente probando nuestro NoCatAuth.Y además tedremos la posibilidad de añadir usuarios manualmente clicando sobre "Add User".

IMPORTANTE!!. De momento, excepto entrar o borrar nuevos usuarios no toqueis ningun otro parametro de configuracion desde Webmin ya que nos falta aun cambiar algunos permisos y configuraciones para que podamos controlar absolutamente todas las configuraciones de NoCatAuth desde aqui. En el caso de querer cacharrear por vuestra cuenta y riesgo es aconsejable realizar una copia de seguridad previa de los ficheros nocat.conf ubicados en /usr/local/nocat/gw y de /usr/local/nocat/authserv para , en caso de problemas, volver a la configuración original.

Volvemos al "Indice del Modulo"

y clicamos sobre "Gateway Configuration".

o sobre "Authentication Service Configuration"

y nos daremos cuenta que, mas adelante, podremos configurar comodamente cualquier parametro de NoCatAuth. De todas formas y esto es importante, de momento, excepto entrar usuarios manualmente, no hagais nada desde aqui puesto que es necesario cambiar aun algunos permisos y funciones de NoCatAuth antes de meterse a modificar otros campos, so pena de que querais que NoCatAuth deje de funcionar. Para los mas inquietos (que los hay) es recomendable antes de tocar nada desde aqui y meterse a experimentar hacer una copia de seguridad de los ficheros nocat.conf que hay en /usr/local/nocat/gw y de /usr/local/nocat/authserv para , en caso de problemas, volver a la configuración original.

Aunque un poco tedioso, el proceso es bastante lógico.Ya tenemos nuestro NotCatAuth.

Volver arriba

Configurando un servidor Radius

Intetamos hacer algo como lo que sigue:

La idea general es la autentificación de usuarios Wireless usando Windows XP contra un servidor IAS como RADIUS.

La instalación conlleva varias etapas, como instalar el servicio de IAS en un servidor Windows 2000/2003 Server (Controlador de dominio),  configurar el/los AP que en nuestro caso será un Cisco serie 1200 para que interactue con el servidor RADIUS, y la configuración del cliente windows XP para que funcione con el protocolo WPA (EAP-TLS)

El protococolo EAP-TLS funciona con certificado que se deben instalar tanto en el servidor RADIUS (IAS) como en los clientes XP. Por ende necesitamos tener un CA que nos proporcione el ceritficado.

En nuestro caso instalaremos un servidor CA y un IAS de Microsoft.

Tendremos que configurar los puntos de Acceso para que funcionen con Radius, dado que será este último el que se encargará de la autentificación, igualmente existen otras soluciones integradas, pero aquí partimos de la idea de que poseemos un servidor Radius.

La configuración basicamente se encuentra en los siguientes puntos:

radiusd.conf -Archivo general de configuración de FreeRADIUS.

Eap.conf–Archivo de configuración de las directivas EAP a utilizar.

Clients.conf– Descripción y credenciales de los diferentes dispositivos que consultan al RADIUS.

Users –Archivo donde se especifican las credenciales de los
usuarios de la red. Se usa este archivo si no existe otro para almacenar los usuarios.

Secret - es usada para cifrar la comunicación entre el cliente
RADIUS (AP) y el servidor RADIUS .

Igualmente Veremos los certificados:

CA.root – Creación de la CA.

CA.server– Creación de certificados para el servidor (fqdn).

CA.client– Creación de certificados para cada usuario. No
confundir con clients.conf de RADIUS.

xpextensions – OID para EAP-TLS.

Empecemos la configuración:

Instalamos el certificado.

Se agrega el componente de Certificate Services

Importante: EL CA luego de ser instalado no puede ser retirado

Al ser el 1º CA en el dominio, nos da la opcion de ser un Enterprise Root CA.

Le damos un nombre .....

A partir de aqui, Next,next, finish:)--->Instalado

Para la instalación  del servicio de internet authentication services (IAS) se debe hacer desde el Agregar o quitar programas En la seccion de los componentes de Windows.

Igualmente Ok,Next,Next, Finish:)

Veamos que más necesitamos..............

Una vez instalado el IAS, lo debemos configurar para que establezca la comunicación con los AP´s. Pero existe un paso adicional donde debemos bajar el certificado digital desde el CA .
El certificado se baja desde el servidor CA, hasta el equipo donde tenemos instalado el servicio  IAS, de la siguiente manera.

La instalación del certificado en el Servidor IAS solo se hace una vez, después en cada cliente XP se debe repetir el mismo proceso de instalación del certificado

Instalado:)

Una vez instalado el certificado digital en el servidore IAS, ahora lo configuramos para que interactue con los AP´s, que en nuestro caso son Cisco, serie 1200.

Dentro de Herraminetas Administrativas en el panel de control, está el snap Internet Authentication Services que debes abrir y configurar lo siguiente.

Configurar un nuevo cliente, debes hacerlo para todos los AP´s de la red.

El protocolo ha de ser Radius:

La dirección IP, es la que corresponde al punto de Acceso en cuestión:

Una vez configurados todos los AP´s. Agregamos un New Remote Access Policy.

Se abre un asistente para la configuración de la política de acceso remoto

Añadimos, en nuestro caso, NAS-Port-Type

Dentro de NAS-Port-Type se elige Wireless-IEEE 802.11

Generamos los permisos de acceso

Usamos Edit Profile , llegados aquí debemos tener algo como esto:

Vamos a configure....

Certificado que debe aparece al hacer click en "Configure". Si no aparece esta pantallita quiere decir que no está instalado el certificado o que está mal instalado

Todo Correcto, al final debe quedar como en la figura. El orden de las políticas deben ser 1 para "Remote Access Policy " .

LLegados a este punto, pasamos a la configuración del Punto de Acceso:

Teniendo instalado el Servidor IAS y configurado cada uno de los clientes Access Point, estamos listos para configurar los Access Point 1200. Cada Access Point debe apuntar a la IP del Servidor IAS, para enviar los requerimientos de Authentication al servicio de RADIUS.

La configuración del AP puede hacerse tanto del browser o por linea de comandos (o CLI).
En este caso lo haremos por CLI como sigue:

Esto continua, es bastante largo, pero lo cortamos por aquí:)

Luego de tener los AP configurados, ahora podemos configurar los equipos XP o windows 2000 . Para la configuración EAP-TLS debemos bajar el mismo certificado que bajamos al Servidor IAS a cada uno de los clientes XP. La forma en que se hace es igual.

Con el certificado ya instalado en el cliente, debemos configurar el ssid que se configuró en los AP, en nuestro caso "myssid" .

Configuramos el "myssid" haciendo click en "Configure"

El Essid debe ser el mismo que el del AP, la autentificación es WPa y la encriptación Tkip:

Hace click en Propiedades y marca el certificado digital que bajaste del Servidor de CA

Tenemos todo listo, solo queda probar que funciona nuestro radius.

Volver arriba

IPSEC, nuestro cerrojo

IPSec , a diferencia de las soluciones anteriores, representa un estándar. El protocolo consta de dos partes, una parte se encarga de la codificación de los datos y la otra parte de asegurar su integridad y autenticidad. El primer componente de la IPSec es ESP (Carga de Seguridad Encapsulada) que se encarga de la codificación, para la que se pueden emplear distintos procedimientos de encriptación. El segundo componente se denomina AH (Cabecera de autentificación) que impide la manipulación de los datos.
El protocolo IKE (Intercambio de claves de internet) no es un componente de las IPSec; sin embargo, está estrechamente vinculado a él, es el encargado de la gestión de claves.

Es una opción muy implementada en wireless, dado que también se puede configurar para conectar una red completa (tal como una LAN o una WAN) a una red remota a través de una conexión red-a-red. Una conexión de red-a-red requiere la configuración de enrutadores IPsec en cada lado de las redes conectantes para procesar y enrutar la información de forma transparente desde un nodo en una LAN a otro nodo en una LAN remota. Veamos una figura:

Se llama a menudo conexión en tunel Con IP-SEC.

El diagrama muestra dos LANs separadas por la Internet. Estas LANs utilizan enrutadores IPsec para autentificar e iniciar una conexión usando un túnel seguro a través de la Internet. Los paquetes que son interceptados en tránsito requerirán un descifrado de fuerza bruta para poder descifrar el código protegiendo los paquetes entre las LANs. El proceso de comunicación desde un nodo en el intervalo IP 192.168.1.0/24 al otro en 192.168.2.0/24 es completamente transparente a los nodos puesto que el procesamiento, encriptación/descifrado y el enrutamiento de los paquetes IPsec es manejado completamente por el enrutador IPsec.

La información necesaria para la conexión red-a-red incluye:

• Las direcciones IP accesibles externamente de los enrutadores IPsec dedicados

• Los intervalos de direcciones de red de las LAN/WAN servidas por los enrutadores IPsec (tales como 192.168.0.0/24 o 10.0.1.0/24)

• Las direcciones IP de los dispositivos de puertas de enlace que enrutan los datos desde un nodo de la red a la Internet.

• Un nombre único para identificar la conexión IPsec y distinguirla de los otros dispositivos o conexiones (por ejemplo, ipsec0 )

• Una llave encriptada fija o una generada automáticamente por racoon

• Una llave pre-compartida que inicia la conexión e intercambia las llaves de encriptación durante la sesión

Por ejemplo, suponga una LAN A (lana.example.com) y una LAN B (lanb.example.com) que desean conectarse entre ellas a través de un túnel IPsec. La dirección de red para la LAN A están en el intervalo 192.168.1.0/24, mientras que LAN B utiliza el intervalo 192.168.2.0/24. La dirección IP de la puerta de enlace es 192.168.1.254 para la LAN A y 192.168.2.254 para la LAN B. Los enrutadores IPsec están separados de cada puerta de enlace de las LANs y utilizan dos dispositivos de redes: eth0 está asignado a una dirección IP estática accesible externamente la cual accesa a Internet, mientras que eth1 actúa como un punto de enrutamiento para procesar y transmitir paquetes LAN desde un nodo de la red a los nodos de redes remotos.

La conexión IPsec entre cada red utiliza una llave pre-compartida con el valor de r3dh4tl1nux , y los administradores de A y B acuerdan dejar que genere automáticamente y comparta una llave de autentificación entre cada enrutador IPsec. El administrador de la LAN A decide nombrar la conexión IPsec ipsec0 , mientras que el administrador de la LAN B llama a su conexión IPsec ipsec1 .

Lo siguiente son los contenidos del archivo ifcfg para una conexión IPsec de red-a-red para la LAN A. El nombre único para identificar la conexión en este ejemplo es ipsec1 , por lo que el archivo resultante es llamado /etc/sysconfig/network-scripts/ifcfg-ipsec.

Los parámetros son estos:

TYPE=IPSEC

ONBOOT=yes

IKE_METHOD=PSK

SRCGW=192.168.1.254

DSTGW=192.168.2.254

SRCNET=192.168.1.0/24

DSTNET=192.168.2.0/24

DST= X.X.X.X

La conexión se configura para iniciarse en el arranque ( ONBOOT=yes ) y utiliza un método de autentificación de llave pre-compartida ( IKE_METHOD=PSK ). El administrador para la LAN A ingresa la puerta de enlace destino, la cual es la puerta de enlace para la LAN B ( DSTGW=192.168.2.254 ) así como también la puerta de enlace fuente, la cual es la dirección IP de la puerta de enlace para la LAN A ( SRCGW=192.168.1.254 ). El administrador luego introduce la red destino, la cual es el intervalo de red para la LAN B ( DSTNET=192.168.2.0/24 ) así como también la red fuente ( SRCNET=192.168.1.0/24 ). Finalmente, el administrador ingresa la dirección IP destino, la cual es la dirección IP accesible externamente para la LAN B ( X.X.X.X ).

Lo siguiente es el contenido del archivo de la llave pre-compartida llamado /etc/sysconfig/network-scripts/keys-ipsec X (donde X es 0 para la LAN A y 1 para la LAN B) que ambas redes utilizan para autenticarse mutuamente. Los contenidos de este archivo deberían ser idénticos y solamente el usuario root debería tener acceso a leer o escribir en este archivo.

IKE_PSK=r3dh4tl1nux

Igualmente solo el Root puede cambiar chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1.

Lo siguiente son los contenidos del archivo de configuración /etc/racoon/racoon.conf para la conexión IPsec. Observe que la línea include al final del archivo es generado automáticamente y solamente aparece si el tunel IPsec se está ejecutando.

A continuación se muestra el archivo específico para la conexión a la red remota. El archivo es llamado X.X.X.X .conf (reemplace X.X.X.X con la dirección IP del enrutador IPsec remoto). Observe que este archivo es generado automáticamente una vez que el túnel IPsec es activado y no se debería modificar directamente. Veamos el archivo

Antes de iniciar la conexión IPsec, se debería activar el reenvío IP en el kernel. Como usuario root en el intérprete de comandos, activamos el reenvío IP.

• Modifique /etc/sysctl.conf y configure net.ipv4.ip_forward a 1 .

• Ejecute el comando siguiente para activar el cambio: sysctl -p /etc/sysctl.conf

Para iniciar la conexión IPsec, reinicie los enrutadores IPsec o ejecute el comando siguiente en cada enrutador como usuario root: /sbin/ifup ipsec0

Las conexiones son activadas y ambas LAN A y LAN B son capaces de comunicarse entre ellas. Los enrutadores se crean automáticamente a través del script de inicialización que se llama ejecutando ifup en la conexión IPsec. Para mostrar una lista de rutas para la red, ejecute el comando siguiente: /sbin/ip route list

Para evaluar la conexión IPsec, ejecute la utilidad tcpdump en el dispositivo enrutable externamente (eth0 en este ejemplo) para así ver los paquetes de red que están siendo transmitidos entre los hosts (o redes) y verificar que están encriptados a través de IPsec. Por ejemplo, para verificar la conectividad IPsec de la LAN A, escriba lo siguiente:

tcpdump -n -i eth0 host lana.example.com

WDS [Wireless Distribution System]

El WDS se usa habitualmente para enlazar dos puntos de acceso, punto a punto, es decir, sin que ningún cliente pueda usar dicha conexión, se suele emplear para hacer repetidores,etc

Ambos AP´s deben estar en el mismo canal, entra en juego el solapamiento.......Esto creo que ya se dijo :)

Vamos a ver unos conceptos un poco más avanzados.

Drivers soportados por WDS

HostAP: Es el driver mas conocido por ser el primero que se desarrollo para poner las
tarjetas en modo master

HermesAP: Este driver no se puede utilizar con una simple orinoco (se ha hecho ingeniería inversa) para que fuera legal habría que utilizar la tarjeta interna de algún AP comercial de Lucent, entonces tendríamos licencia del driver.

PrimsGT: Poco usado

Etc.

Lo Bueno del WDS -->Difícil de rastrear al trabajar con 4 direcciones Mac .

Lo malo ---> Porque se anuncia todo a toda la red y posible Denegación de servicio sobre un canal (se tira nube WDS entera).

Sobre una misma máquina montar 3 tarjetas Wireless en modo master en 3 canales
distintos, (más de tres generan ruido entre ellas) sobre estas 3 tarjetas se montan túneles WDS a nivel interno.

Los beneficios de esto son: Alta Disponibilidad, Mas usuarios sobre un punto de acceso, Balanceo de carga sobre el punto de acceso, esta última, especialmente interesante:)

Esto es lo que se pretende.Con esto obtendríamos:

Dificultad a la hora de realizar una denegación. Para conseguir una DoS tendríamos que hacer un ataque distribuido a nivel radio.
El seguimiento de las tramas de red capturando tráfico conlleva un análisis muy
complejo llegando incluso a bloquear las herramientas de captura (usando este sistema AirTraf resistió tan solo 2 minutos!!).
Balanceo de carga entre nodos, posible gracias al cambio de canales en los túneles WDS entre nodos.

Parece que WDS, sirve para algo más que usar modo cliente en plan chapuza:)

Volver arriba

Enlaces y documentación

CompostelaWireless
CarballoWireless
ArteixoWireless
MadridWireless
CanariasWireless
AcoruñaWireless
Airdefense
Air-Jack
MataroWireless
Blyx
RemoteExploit
OlotWireless
Alfha How to FreeRadius
Wifisafe Espana
INsecure
hackinthebox

Agradecimientos personales a:

Daniel Martínez Ponce
Pau Oliva Fora
Alejando Corletti Estrada
Administrador CompostelaWireless

Volver arriba

Recomendaciones de CompostelaWireless

Estas pueden ser unas buenas medidas para uso doméstico, y que no deberían ser prácticas recomendadas para los negocios (se debería poner algo más seguro).

• Seguridad de la Red. Pon tu punto de acceso en una subred separada físicamente si es posible, con un firewall separando los usuarios Wíreless y los internos.
• Cambia los parámetros por defecto en tu AP. Parámetros por defecto (SSID, password admin., canal) son bien conocidos incluso como parte de algunas herramientas de ataque WLAN.
• Usa WPA2 con clave “fuerte”. WPA2 es una mejora definitiva sobre WEP y WPA suministrando seguridad inalámbrica. Siendo precavidos incluso puedes hacer un servidor Radius y autentifacarte contra él.
• Actualiza tu firmware. Esto es de ayuda si tu AP o cliente no soporta actualmente WPA. Muchos fabricantes tienen firmwares más recientes para productos 802.11g que añaden soporte WPA2. Tu también puedes encontrar esto para 802.11b, pero no es tan común.
• Apaga la WLAN cuando no esté en uso. La manera fácil sería poniendo un temporizador al AP pero a lo mejor en un apagado se te va la configuración.

Importante destacar que son recomendaciones para uso doméstico , para implementar una red corporativa, se podrían usar alguna de las medidas vistas en este documento.

Volver arriba

Conclusiones Y Desenlace.

Las redes wireless, están ya muy desarrolladas e implementadas, es por ello que en breve con 802.11i, disfrutaremos de una mayor seguridad, sin que para ello sean necesarios unos conocimientos técnicos apropiados, aun así; Nada es seguro al 100%, este documento tiene como fin, mostrar las distintas configuraciones que podemos realizar según nuestras necesidades, igualmente conocer los ataques que se usan comunmente en las redes inalámbricas, enfocados desde ambos puntos de vista:)

Se autoriza la copia o distribución por cualquier medio, siempre que se cumpla la licencia establecida.

Para cualquier sugerencia o comentario, pentronic@gmail.com

Volver arriba

Esta obra está baixo unha licenza de Creative Commons