Vous êtes sur la page 1sur 179

Universidad de Mendoza

Facultad de Ingeniera
Tesis de Maestra en Teleinformtica
Arquitectura Unificada para Control de Acceso
en Redes Inalmbricas Seguras
Ing. Pablo idel !"mez #ergara
Directores de Tesis:
Magster Ing. Juan Jos Ciarlante
Ing. Osvaldo Rosso
Mendoza !gosto de "##$
Agradecimientos
Quiero agradecer en especial a Julia, mi esposa, quien con su continuo aliento, su
apoyo incondicional, su amor y su paciencia es el viento bajo mis alas, siempre.
A mis padres, Aldo y Marta, por darme los valores y herramientas para ser un hombre
de bien, y con su vida incansable me animaron a luchar para tratar de serlo.
A Juanjo por su gua y estmulo que me lanz a la aventura de conseguir aquello que
pareca imposible. ero sobre todo por su respeto y amistad.
A Al!redo, a "alvador, y a #ristina por hacer posible mi realizacin personal como
docente, por apoyarme en cada proyecto, alentarme a crecer y con!iar en m.
A $iego y a #arlos por su compa%erismo, amistad y aliento.
ablo &. 'mez (ergara
A.M.$.'.
I. Resumen....................................................................................................... .............3
II. Introduccin.................................................................................................. ...........4
1. Objetivos.............................................................................................. ..............6
III. Marco Terico................................................................................ ........................7
1. Redes de rea Local Inalmbricas............................................................. .......7
1. Licencias y Regulaciones.................................................... ........................9
2. Redes 802.11...................................................................... ........................11
2. Componentes de una Red Inalmbrica........................................................... ..13
1. Elementos de la Infraestructura de Red.............................................. .......13
2. Bloques lgicos de una Red Inalmbrica..................................... .............15
1. Conjunto de Servicios Bsicos (BSS).................................................15
2. Conjuntos de Servicio Extendido (ESS)............................................17
3. Servicios de Red............................................................................ ...................18
4. Servicios de Confidencialidad y Control de Acceso.......................................24
1. WEP (Wired Equivalent privacy)............................................... ..........26
2. 802.11i y WPA (Wireless Protected Access)........................................31
1. 802.1X y EAP........................................................ .........................32
1. EAP-TLS ............................................................. .....................38
2. EAP-TTLS y EAP-PEAP.................................................... .....39
3. Funcionamiento de 802.1X.............................................. .........40
2. Confidencialidad e Integridad en 802.11i......................................45
5. PPPoE................................................................................... ............................51
6. LDAP................................................................................................ ................54
7. RADIUS.......................................................................................................... ..58
IV. Desarrollo.................................................................................... .........................67
1. Planteo de Restricciones y Necesidades........................................................ ..67
2. Modelo y Entidades AAA............................................................... .................71
3. Bloques Funcionales...................................................................................... ...77
1. Mtodos de Acceso......................................................................... ............77
1. Mtodo PPPoE..................................................................... ................77
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
-./01
2. WPA/RSN HostapD............................................... ..........................80
3. Portal Cautivo (CAPTIVE PORTAL).................................... .............82
2. Direccionamiento General de Red...................................... .......................85
3. Servidor de Autenticacin............................................................. .............87
1. Servidor LDAP......................................................... ...........................87
2. Servidor RADIUS..................................................... ..........................93
3. Portal Cautivo (Captive Portal).................................................... ......110
4. Servidor WEB................................................................... .................117
5. Servidor PPPoE ....................................................................... ..........118
6. Servidor de Base de Datos............................................................... ..123
7. Herramientas para Aplicacin de Polticas.......................................124
8. Herramientas de Administracin............................................... ........132
V. Resultados........................................................................................ ....................136
VI. Conclusiones............................................................................ ..........................142
VII. Futuras Direcciones................................................................ ..........................143
VIII. Apndices e ndices............................................................................... ..........144
1. Apndice A: Compilacin de Freeradius para DEBIAN........................144
2. Apndice B: Creacin de CA y Certificados para EAP-TLS.................150
3. Apndice C: Compilacin de Chillispot.................................................154
4. Apndice D: Compilacin de rp-pppoe en Modo Kernel.......................157
5. Apndice E: Scripts para Aplicar Reglas de Conectividad....................159
6. Apndice F: Pruebas de PPPoE con Cifrado MPPE...............................166
7. Apndice G: Bibliografa.................................................................. .......168
8. Apndice H: ndice de ilustraciones..................................................... ...169
9. Apndice I: ndice de tablas................................................. ...................170
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
2./01
I. RESUMEN
3a popularizacin de las redes inal,mbricas y, en consecuencia, la
disminucin del costo del hard4are inal,mbrico han planteado nuevos
desa!os para los administradores de red. Actualmente es inconcebible un
dispositivo mvil sin comunicacin inal,mbrica.
3a implementacin de redes inal,mbricas en ,mbitos semi p5blicos
constituye uno de los desa!os no resueltos en la actualidad. Al contrario
de los ,mbitos puramente corporativos, en escenarios de este tipo, los
administradores no pueden de!inir las caractersticas de conectividad de
los dispositivos inal,mbricos que poseen los usuarios. Adicionalmente es
muy !recuente la necesidad de di!erenciar el tipo de servicios que se
brindan de acuerdo a las necesidades de distintos grupos de usuarios.
6stas necesidades plantean la conveniencia de solucionar una
problem,tica que no es cubierta por ninguno de los protocolos
inal,mbricos e7istentes en la actualidad. 6n e!ecto, en general cada
protocolo o m8todo de acceso resuelve una parte del problema, y
generalmente de manera e7cluyente9 por lo tanto no permite la integracin
de soluciones di!erentes sobre los mismos equipos en simult,neo.
6n este trabajo se aborda la problem,tica planteada de acceso
inal,mbrico en un ,mbito semi p5blico, y se presenta un modelo de
in!raestructura de base, cuya implementacin permite:
brindar puntos de acceso a redes inal,mbricas mediante
di!erentes m8todos de acceso,
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
;./01
tipi!icar los servicios que se brindar,n en la red de acuerdo a
los tipos de usuario que se conectar,n a dicha red,
implementar el !uncionamiento de diversos dispositivos clientes
con distintos sistemas operativos,
$e esta !orma satis!ace las necesidades planteadas anteriormente.
6n el desarrollo de este trabajo se abordar,n los di!erentes est,ndares
de cone7in para redes inal,mbricas de ,rea local, se analizar,n los
distintos m8todos de acceso y se presentar,n las herramientas con que
cuenta '<).3inu7 para administrar usuarios de estas cone7iones
inal,mbricas.
<ota: 3a presente tesis se completa con un cdrom que contiene los
scripts para aplicacin de polticas y los templates para phpldapadmin.
3os cuales no se han includo en la presente por razones de !ormato y
tama%o.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
=./01
II. INTRODUCCIN
3a popularizacin de las tecnologas de red inal,mbricas han
planteado nuevos desa!os de conectividad, en las que los
administradores de red requieren de nuevas herramientas que permitan
modelar soluciones para estas nuevas necesidades.
articularmente en ,mbitos donde es necesario implementar un
acceso del tipo semi p5blico, se generan escenarios de mayor
complejidad. $ado que en este tipo de ,mbitos en general resulta
necesaria una amplia cobertura de la red inal,mbrica, no es posible de!inir
las caractersticas de conectividad de los dispositivos que se conecten y
se requiere que la red brinde servicios di!erenciados a di!erentes grupos
de usuarios.
'eneralmente, al realizar la implementacin de puntos de acceso
inal,mbrico en la red de una organizacin de tipo corporativo, se opta por
un protocolo y un m8todo de acceso que cumpla con las polticas
de!inidas por dicha organizacin. "e de!inen tambi8n, en esta eleccin,
las caractersticas que deben cumplir los dispositivos de los usuarios,
e7cluyendo a todos los equipos que no cumplen con dichas
caractersticas.
6ste tipo de elecciones se torna di!cil en los escenarios con acceso
del tipo semi p5blico, ya que esta 5ltima de!inicin, sobre los equipos de
los usuarios, no puede llevarse a cabo. > por lo tanto la eleccin de un
5nico m8todo de acceso puede traer aparejada la imposibilidad de
conectarse a la red por parte de los usuarios cuyo equipamiento no
cumple con estas caractersticas.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
0./01
$esde el punto de vista de la seguridad global de la red de una
organizacin, una red inal,mbrica en un ,mbito semi p5blico debera
tratarse como una red separada de la red privada. 6n e!ecto, es
potencialmente insegura, por las caractersticas del medio de transmisin
y por el di!erente grado de con!iabilidad que pueden presentar los
distintos grupos de usuarios de dicha red. 6sto 5ltimo obliga a restringir
los servicios de acceso de acuerdo al grado de con!iabilidad que presenta
cada grupo de usuarios.
$e esto surge la necesidad de tipi!icar a los usuarios mediante
di!erentes per!iles de conectividad dentro de la red inal,mbrica y de
almacenar in!ormacin que permita auditar algunos par,metros de
comportamiento de cada usuario dentro de la red inal,mbrica.
or otro lado la proli!eracin de dispositivos con capacidades
inal,mbricas como las computadoras port,tiles, los $A
/
y los tel8!onos
mviles, marcan una !uerte tendencia al crecimiento en el uso de estos
dispositivos. Ante esto el modelo a plantear debe ser capaz de soportar
un crecimiento en cantidad de dispositivos, y por lo tanto en puntos de
acceso y en cantidad de usuarios, sin presentar mayores complejidades
en la implementacin.
1. OBJETIVOS
6l presente desarrollo propone:
lantear un ?modelo de in!raestructura de base@ para la
implementacin del acceso a redes inal,mbricas de tipo semi
p5blicas que permita:
1 Personal Digital Assistant, Asistente personal digital.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
A./01
+denti!icar el acceso de cada usuario a la red,
independientemente del dispositivo que utilice para realizar
dicho acceso.
$e!inir una poltica de uso del recurso inal,mbrico,
implementada a trav8s de per!iles de usuario y permisos sobre
cada usuario, que permita regular el acceso de los mismos a los
di!erentes servicios de conectividad.
Brindar di!erentes m8todos de acceso que permitan
la cone7in de un amplio espectro de equipamiento de
di!erentes plata!ormas a trav8s de protocolos abiertos, con
mnimas necesidades de intervencin por parte de los
administradores de red.
+mplementar un ?modelo de in!raestructura de base@ que
provea herramientas amigables para la administracin de usuarios,
la de!inicin de los per!iles de los mismos y los servicios que se
brinden a dichos usuarios.
)tilizar herramientas de so!t4are libre y '<) 3inu7 en la
implementacin de dicho modelo.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
1./01
III. MARCO TERICO
6n este captulo, se realiza una revisin de los conceptos necesarios
para la presentacin del modelo propuesto. "e comienza por los
conceptos de redes inal,mbricas y sus est,ndares. "e contin5a por los
m8todos de acceso, sus protocolos de autenticacin, y protocolos
gen8ricos para realizar AAA
1
. > se concluye con los conceptos de
servicios de directorio donde se almacenan los datos de los usuarios.
3uego se presenta el planteo del modelo y su implementacin.
1. REDES DE REA LOCAL INALMBRICAS
3as redes inal,mbricas C'A"DEEF est,n de!inidas en el est,ndar
AEG.// C+666AEG//F de la IEEE
2
. 6l est,ndar AEG.// es un miembro de la
!amilia AEG C+666AEGF, y consiste en una serie de especi!icaciones para
las tecnologas de redes de ,rea local HLAN
3
I. $ichas especi!icaciones
est,n en!ocadas en las dos capas in!eriores del modelo OSI [ISOOSI]
debido a que incorporan elementos tanto de la capa !sica HPHY
4
I como
de la capa de enlace.
Dodas la redes del tipo AEG poseen ambas capas, la capa de enlace
tiene por objeto determinar cmo se accede al medio de transmisin para
enviar o recibir los datos, pero los detalles de cmo esos datos son
transmitidos o recibidos es el objeto de la capa !sica.
1 del ingls Authentication, Authorization and Accounting, autenticacin, autorizacin y
contabilidad. Es un protocolo o sistema que permite a los usuarios proveer una identidad,
obtener acceso a recursos y recolectar estadsticas de utilizacin. El protocolo ms comn
para AAA es RADIUS.
2 Institute of Electronics and Electrical Engineers, Instituto de Ingenieros en Electrnica y
Electricidad.
3 Local Area Networks, redes de rea local.
4 Abreviatura del ingls de la palabra Physical, fsica.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/E./01
3as especi!icaciones individuales en la serie AEG se identi!ican por
segundo n5mero. or ejemplo, AEG.- C+666AEG-F. es la especi!icacin
para las redes denominados gen8ricamente Ethernet S!A"#
1
. AEG.;
es la especi!icacin para $%&en 'in(. AEG.G especi!ica una capa de enlace
com5n, la LL
2
que puede ser utilizada por cualquier tecnologa de LAN
de una capa in!erior. 6n la especi!icaciones AEG./ se de!inen las
caractersticas de administracin como AEG./$ H)rid(in(
3
I o AEG./Q
H*LANs
4
I.
1 del ingls Carrier Sense Multiple Access with Collision Detection, sensado de portadora con
acceso mltiple y deteccin de colisiones.
2 del ingls Logical Link Control, control del enlace lgico.
3 del ingls Bridge, especifica las conexiones de puente.
4 del ingls Virtual LANs, redes virtuales.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
//./01
Ilustracin III.1.: Familia de Protocolos IEEE802.
1. LICENCIAS Y REGULACIONES
6n las transmisiones de radio, evitar las inter!erencias es un problema
que debe ser contemplado en la legislacin. 6s por eso que una autoridad
debe imponer las reglas de utilizacin del espectro de radio!recuencia
H'+I. or ejemplo en los 66.)). esta tarea recae sobre la %misi,n
+ederal de %m-nicaci%nes H+I. 6n 6uropa la asignacin de '+ es
responsabilidad de la O.icina E-r%pea de 'adi%c%m-nicaci%nes HE'OI.
3a compatibilizacin de las normas de cada pas o regin es realizada por
la /ni,n Internaci%nal de $elec%m-nicaci%nes HI$/I.
$ebido a esto, quien desee transmitir en el espectro '+, deber,
poseer una licencia otorgada por los organismos reguladores. 3as
licencias pueden restringir la !recuencia asignada y la potencia de
transmisin, as como el ,rea geogr,!ica en que las se%ales de '+
pueden ser utilizadas. $e esta !orma el licenciatario de una !recuencia
tiene utilizacin e7clusiva de la !recuencia asignada, evitando la
inter!erencia en la uso de dicha !recuencia de *&.
ara eso, el radio espectro se divide en bandas dedicadas a un
propsito particular. )na banda es de!inida como el conjunto de
!recuencias de '+ que una aplicacin particular puede utilizar. 67isten
varias bandas de !recuencia destinadas a una utilizacin de dispositivos
hogare%os, por ejemplo, para los hornos de microondas, los tel8!onos
inal,mbricos y las 3A< inal,mbricas. 6stas !recuencias generalmente se
denominan )andas de +rec-encia IS!
1
, y la principal caracterstica es
que son de %peraci,n n% licenciada, y solamente presentan restricciones
en la potencia de transmisin Hver Dabla +++./I.
1 del ingls Industrial Scientific and Medical use, uso industrial, cientfico y mdico.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/G./01
Bandas de Frecenc!a Ran"# de Frecenc!as
)J& +"M 1EGK1GA MJz
Banda " G L 2 'Jz
Banda " +"M G.2 L G.; 'Jz
Banda # 2 KA 'Jz
Banda # para Bajada de "at8lite -.0 L 2.G 'Jz
Banda # de *adar ;.G; K;.1G; 'Jz
Banda # +"M ;.0G; L ;.A0; 'Jz
Banda # para subida a sat8lite ;.1G; L =.2G; 'Jz
Banda M A L /G 'Jz
Banda M Hpolica y radarI A.; L /E.;; 'Jz
Banda Nu /G L /A 'Jz
Banda Nu *adar HpolicaI /-.2 L /2 'Jz
/;.0 L /0.0 'Jz
Tabla III.1.: Bandas de frecuencia comunes en EEUU
1
.
$. REDES %&$.11
3a especi!icacin original AEG.//, que data de /110, incluye la capa
de enlace y dos capas !sicas posibles por transmisin de radio, +HSS
2
y
$"""
3
. 3as revisiones posteriores agregaron nuevas capas !sicas como
por ejemplo, AEG.//b que especi!ica H'"#SSS
4
, AEG.//a que agrega
O+#!
0
y AEG.//g que hace lo propio con E'P
1
.
1 Se puede descargar el mapa completo del uso del espectro electromagntico en EEUU de la
National Telecommunications and Information Administration en
http://www.ntia.doc.gov/osmhome/allochrt.pdf .
2 Frecuency Hopping Spread Spectrum, espectro ensanchado por salto de frecuencia
3 Direct Sequence Spread Spectrum, espectro ensanchado por secuencia directa
4 High Rate DSSS,
5 Orthogonal Frequency Division Multiplexing, multiplexacin por division de frecuencias
ortogonales.
6 Extended Rate PHY, interfaz fsica de rango extendido, utiliza varias especificaciones de
intefaz fsica en una sola definicin.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/-./01
6stas capas !sicas utilizan tecnologa Spread Spectr-m H6spectro
6nsanchadoI la cual es la base para aprovechar las bandas IS! para
transmitir datos. 6sta tecnologa utiliza !unciones matem,ticas para
distribuir la potencia de la se%al a transmitir a lo largo de un amplio rango
de !recuencias. #uando el receptor realiza la operacin inversa, la se%al
esparcida en el rango de !recuencias se reconstituye como una se%al
normal de banda angosta.
6l esparcir la transmisin en un amplio rango de !recuencias hace que
estas transmisiones sean vistas como ruido por los receptores de banda
angosta. "i bien esta tecnologa es robusta !rente a las inter!erencias, si
e7isten una gran cantidad de dispositivos se inter!erir,n
inde!ectiblemente. A !in de minimizar esta inter!erencia la + limita la
potencia de los transmisores SS a / Oatt y a 2 Oatts de potencia e!ectiva
irradiada 2E'PI. 3a utilizacin de tecnologas Spread Spectr-m es una
obligacin para los equipos que operan en las bandas no licenciadas.
3as capas !sicas basadas en '+ en AEG.// utilizan tres t8cnicas de
Spread Spectr-m di!erentes:
+re3-enc4 H%ppin( % Salt% de +rec-encia 2+H % +HSS56
6n esta t8cnica los sistemas saltan de una !recuencia a otra en un
patrn aleatorio, transmitiendo una corta r,!aga de datos en cada
una de estas !recuencias o canales. 6sta capa !sica esta de!inida
en la clausula /2 del est,ndar.
#irect Se3-ence % Sec-encia #irecta 2#S % #SSSI: 6n
esta t8cnica los sistemas esparcen la potencia de salida sobre una
amplia banda de !recuencias utilizando !unciones de codi!icacin
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/2./01
matem,tica. 6sta capa !sica tiene dos de!iniciones en el est,ndar:
en la clausula /; est, de!inida la #SSS a G Mbps original y en la
clausula /A est, de!inida la H'"#SSS utilizada en AEG.//b.
Orth%(%nal +re3-enc4 #i7isi%n !-ltiple8in( %
!-ltiple8aci,n p%r #i7isi,n de +rec-encias Ort%(%nales 2O+#!I:
6sta t8cnica divide cada canal disponible en varios subcanales y
codi!ica una porcin de la se%al en cada subcanal en paralelo. 3a
clausula /0 especi!ica O+#! para AEG.//a a ; 'Jz y la clausula
/A especi!ica E'P para AEG.//g que es b,sicamente lo mismo pero
para !recuencias de G.2 'hz.
3as LAN AEG.// no slo se di!erencian por las !recuencias de
transmisin y t8cnicas de codi!icacin, sino tambi8n por las velocidades
de transmisin que pueden alcanzar como se puede observar en la Dabla
+++.G.
Es'(ndar
IEEE
Ve)#c!dad de
Trans*!s!+n
Banda de
Frecenc!a
C#*en'ar!#
AEG.//
/ Mbps
G Mbps
G.2 'Jz
rimer est,ndar de capa !sica H/110I de!inido
para las t8cnicas de modulacin $""" y &J""
AEG.//a
hasta ;2
Mbps
; 'Jz
"egundo est,ndar de capa !sica H/111I. "in
productos en el mercado hasta !inales del GEEE.
AEG.//b
;.; Mbps
// Mbps
G.2 'Jz
Dercer est,ndar de capa !sica. osee la mayor
base instalada actualmente HGEE=I.
AEG.//g
hasta ;2
Mbps
G.2 'Jz
#uarto est,ndar de capa !sica HGEE-I. Aplica
t8cnicas de codi!icacin usadas en AEG.//a para
obtener mayor velocidad de transmisin en la
banda de G.2 'Jz y provee compatibilidad con
las redes AEG.//b. 6s la tecnologa m,s com5n
en notebooPs desde GEE;.
Tabla III.2.: Comparacin de las capas fsicas de 802.11
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/;./01
$. COM,ONENTES DE UNA RED INALMBRICA
1. ELEMENTOS DE LA INFRAESTRUCTURA DE RED
3os elementos que componen la in!raestructura de una red
inal,mbrica son cuatro:
Estaci%nes6 3as estaciones son dispositivos computacionales que
poseen una inter!az de red inal,mbrica. Dpicamente estos
dispositivos son N%te9%%&s: P#A: etc. pero pueden ser
computadoras normales en lugares en que se ha optado no realizar
un cableado de red y utilizar tecnologas inal,mbricas solamente.
Adicionalmente varios !abricantes de dispositivos electrnicos
est,n utilizando AEG.// para comunicar dispositivos no
computacionales.
Access P%ints % P-nt%s de Acces% 2AP5 6 3os AP
!undamentalmente cumplen la !uncin de 9rid(e entre una red
inal,mbrica y una red cableada, trans!ormando los marcos AEG.//
a otro tipos de marcos para poder enviarlos al resto de la red. 6sta
no es la 5nica !uncin que cumplen los AP, pero es la m,s
importante.
!edi% de $ransmisi,n Inal;m9ric%6 6s el medio de transmisin
utilizado por las estaciones para enviar y recibir marcos. "i bien
AEG.// de!ine varias capas !sicas di!erentes, las capas basadas en
'+ han sido mucho m,s populares que las capas basadas en
transmisin +n!rarroja HI'I. 6l hecho de que las se%ale no est,n
circunscriptas a un medio !sico, como por ejemplo un cable, tiene
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/=./01
como consecuencia que los lmites geogr,!icos de la red son
di!usos.
Sistema de #istri9-ci,n 6 6l sistema de distribucin es el
componente lgico de AEG.// que se utiliza para reenviar los
marcos a su destino. "i bien AEG.// no especi!ica ninguna
tecnologa en particular para implementar el sistema de
distribucin, generalmente solo se denomina 'ed de )ac&9%ne, y
est, !ormado por las cone7iones Ethernet que unen los distintos
AP.
$. BLO-UES LGICOS DE UNA RED INALMBRICA
1. CONJUNTO DE SERVICIOS BSICOS .BSS/
6l bloque de construccin b,sico en una red AEG.// es el )asic
Ser7ice Set % %n<-nt% de Ser7ici%s );sic%s 2)SS5 que simplemente es
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/0./01
Ilustracin III.2.: Componentes de la Infraestructura Inalmbrica.
un grupo de estaciones que se comunican entre s. 3a comunicacin
entre estas estaciones tiene lugar en un ,rea di!usa denominada )asic
Ser7ice Area % =rea de Ser7ici% );sic% 2)SA5 de!inida por las
caractersticas de propagacin del medio inal,mbrico. #uando una
estacin entra en la )SA: puede comunicarse con los otros miembros del
)SS. #omo se ve en la +lustracin +++.-, los )SS pueden ser de dos tipos
di!erentes: +ndependientes o de +n!raestructura.
6n los )SS +ndependientes HI)SS5: las estaciones se comunican
directamente entre ellas y para ello es necesario que se encuentren
dentro del alcance de radio. 3a red m,s peque%a posible es de dos
estaciones. Dpicamente este tipo de )SS se componen de un n5mero
peque%o de estaciones, que se con!iguran para un evento especial por un
corto periodo de tiempo, es por ello que usualmente se denominan ad h%c
)SS o 'edes ad h%c.
6n contraposicin, los )SS de In.raestr-ct-ra, tambi8n llamados
'edes de In.raestr-ct-ra, se distinguen por el uso de un Access P%int
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/A./01
Ilustracin III.3.: Comparacin entre BSS de Infraestructura y BSS Independiente
HAPI que es utilizado para realizar todas las comunicaciones dentro de
una )SA. #uando una estacin enva un marco a otra estacin, se la
enva al AP y este reenva el marco a la estacin destino. $e esta !orma
una )SA que corresponde a un )SS de In.raestr-ct-ra, se de!ine por
todos los puntos en que las transmisiones del AP pueden recibirse. A
pesar de que este tipo de transmisin consume m,s capacidad del medio
que una transmisin directa a la estacin destino, posee dos ventajas
importantes:
)n )SS de in.raestr-ct-ra se de!ine por la distancia al AP. "i bien
todas las estaciones deben estar en el rango de alcance del AP, no
e7isten restricciones para la distancia entre las estaciones. 6l
costo de usar un I)SS se determina por el incremento de la
complejidad de la capa !sica, porque las estaciones deben
mantener alcance con las estaciones vecinas dentro del )SA.
3os AP est,n en posicin de ayudar al ahorro de energa de las
estaciones mviles, ya que pueden actuar como 9-..ers de los
marcos. $ichas estaciones, en modo de ahorro de energa, pueden
apagar el transmisor y prenderlo slo para transmitir y recibir los
marcos almacenados en el AP.
6n una red de in!raestructura, las estaciones deben as%ciarse a un
AP para obtener servicios de red. 6sta operacin es equivalente a
enchu!ar un cable de red en una red cableada y es una accin e7clusiva
de las estaciones, que slo pueden asociarse a un AP . <o e7iste un
lmite de estaciones que pueden asociarse a un AP. "in embargo, en la
pr,ctica, el bajo ancho de banda que presenta el medio de transmisin
inal,mbrico limita la cantidad de estaciones para una red inal,mbrica.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/1./01
$. CONJUNTOS DE SERVICIO E0TENDIDO .ESS/
"i bien los )SS pueden cubrir ,reas de servicio peque%as, como
o!icinas o casas, no pueden proveer de cobertura a ,reas m,s grandes.
6s por esto que el est,ndar AEG.// permite, a !in de tener cobertura en
,reas e7tensas, de!inir un bloque mayor, denominado E8tended Ser7ice
Set % %n<-nt% de Ser7ici%s E8tendid%s 2ESS5. $icho bloque se crea al
conectar varios )SS mediante una red troncal y al con!igurar todos los AP
en el ESS con el mismo Ser7ice Set Identi.ier % Identi.icad%r de %n<-nt%
de Ser7ici%s 2SSI#5, que sirve como ?nombre de red@ para los usuarios del
servicio.
3as estaciones dentro del mismo ESS pueden comunicarse entre
ellas, a5n con las estaciones que est,n en un )SS di!erente. Danto el
medio inal,mbrico como el troncal act5an como un solo medio de capa de
enlace.
3as =reas de Ser7ici% E8tendid% % E8tended Ser7ice Areas 2ESAI son
el nivel de abstraccin m,s alto soportado por las redes AEG.//, los AP de
un ESS interoperan para permitir al resto de la red ubicar a una estacin
por su direcci,n .>sica % !A: independientemente del )SS en el que
esta estacin est8 ubicada. $e este modo, el router de la +lustracin +++.2
permanece ignorante de la localizacin !sica de la estacin y depende de
los AP para entregar el marco.
1. SERVICIOS DE RED
6l est,ndar AEG.// no especi!ica ninguna tecnologa en el troncal o
9ac&9%ne y slo requiere que el mismo provea un grupo especi!icado de
servicios. AEG.// provee nueve servicios. "lo tres de estos se utilizan
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
GE./01
para transportar datos. 3os seis restantes son operaciones de
administracin que permiten a la red trazar a las estaciones mviles y
entregar los marcos de red e!ectivamente.
#istri9-ci,n6 6ste servicio es utilizado por las
estaciones mviles en una red de in!raestructura cada vez que
envan datos. )na vez que un marco es aceptado por un AP, este
utiliza el servicio de distribucin para reenviar este marco a su
destino. Dodas las comunicaciones que utilizan a un AP viajan a
trav8s del sistema de distribucin, aun la comunicacin entre dos
estaciones asociadas al mismo AP.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
G/./01
Ilustracin III.4.: Esquema de un Extended Service Set (ESS).
Inte(raci,n6 6ste es un servicio provisto por el sistema
de distribucin que permite la cone7in de el sistema de
distribucin a una red no +666AEG.//. 6sta !uncin es espec!ica
del sistema de distribucin utilizado y no est, especi!icada en el
est,ndar AEG.//, salvo en t8rminos de descripcin del servicio que
se o!rece.
As%ciaci,n6 6ste servicio requiere que las estaciones se
registren o as%cien al AP que provee un )SS. 'racias a esta
asociacin, es posible la comunicacin. > a su vez, el sistema de
distribucin puede determinar a c5al AP est, asociada una
estacin. 3as estaciones no asociadas, no pertenecen a la red. 6l
est,ndar AEG.// especi!ica que esta !uncin debe ser provista por
el sistema de distribucin utilizando los datos de asociacin9 pero
no obliga a una implementacin particular. #uando se utilizan los
protocolos 'SN
1
: la asociacin es un precursor a la autenticacin,
es decir antes de completar la autenticacin, un AP, descarta todo
el tr,!ico de red de una estacin.
'eas%ciaci,n6 6ste servicio permite que, cuando una
estacin se mueve entre dos )SA dentro de una ESA, pueda
evaluar el nivel de la se%al recibido y quiz,s cambiar la asociacin
de un AP a otro. 3a 'eas%ciaci,n es iniciada por las estaciones
cuando las condiciones de la se%al le indican que este cambio
puede ser bene!icioso. <unca es iniciado por un AP, si bien e7isten
AP que desconectan a las estaciones para obligarlas a
reasociarse. )na vez que la reasociacin est, completada, el
1 Robust Security Network, Redes con seguridad robusta, ver 802.11i.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
GG./01
sistema de distribucin actualiza los registros de localizacin para
re!lejar la trazabilidad de la estacin en un AP di!erente.
#esas%ciaci,n6 6ste servicio permite terminar con una
asociacin e7istente y es tpicamente un servicio que utilizan las
estaciones. #uando una estacin invoca al servicio, todos los datos
de movilidad almacenados por el sistema de distribucin son
removidos. 6l uso de este servicio es ?educado@, pero de todas
maneras, la capa de enlace est, dise%ada para acomodarse a las
estaciones que dejan la red sin desasociarse !ormalmente.
A-tenticaci,n6 $ebido a que las redes inal,mbricas no
pueden o!recer la seguridad !sica que o!recen las redes
cableadas, dependen de rutinas de autenticacin adicionales que
aseguran que los usuarios que acceden a la red est,n autorizados
para hacerlo. 3a autenticacin es un prerrequisito necesario para
la asociacin porque slo los usuarios autenticados est,n
autorizados a utilizar la red. 3a autenticacin puede ocurrir varias
veces durante el tiempo que una estacin est, conectada a una
red inal,mbrica. Antes de asociarse a un AP, una estacin realiza
un intercambio b,sico de identidades con el AP que consiste en su
direccin !A. $icho intercambio es !recuentemente denominado
?autenticacin AEG.//@, y es distinto a la autenticacin de usuarios
con criptogra!a robusta que se ejecuta despu8s.
#esa-tenticaci,n6 6ste servicio termina con una relacin
de autenticacin y, como e!ecto, termina con la asociacin de la
estacin. 6n una red 'SN, la desautenticacin tambi8n borra la
in!ormacin re!erida a las claves.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
G-./01
%n.idencialidad6 6ste servicio tiene como !in el
prevenir los ataques contra la privacidad de los datos en las
comunicaciones. 6n las redes inal,mbricas, es mucho m,s
!recuente y di!cil de prevenir una ataque de este tipo que en las
redes cableadas. 6n e!ecto, el acceso no autorizado es
dependiente de la seguridad !sica. 6n las revisiones iniciales de
AEG.//, el servicio de c%n.idencialidad se denomin pri7acidad, y
!ue provisto por el protocolo Pri7acidad E3-i7alente al a9lead% %
?ired E3-i7alent Pri7ac4 2?EP5, ahora desacreditado. 6l est,ndar
AEG.//i, adem,s de nuevos esquemas de ci!rado, aumenta la
con!idencialidad dotando al servicio de autenticacin basada en
usuarios y servicios de administracin de claves, dos !actores
crticos de los que ?EP careca.
Entre(a de !S#/ 2!A Ser7ice #ata /nit56 6ste
servicio provee una de las capacidades vitales para una red: la de
entregar los datos al destinatario. 3as estaciones proveen el
servicio de entrega /nidades de #at%s de Ser7ici% !A 2!S#/I el
cual es responsable de entregar los datos al destinatario.
%ntr%l de P%tencia de $ransmisi,n: 6ste servicio !ue
de!inido por AEG.//h, ya que los est,ndares europeos para la
banda de ; 'Jz requieren que las estaciones controlen la potencia
de las transmisiones de radio para evitar las inter!erencias con
otros usuarios de esta banda de '+. 3a distancia m,7ima al AP
est, en !uncin de la potencia transmitida. #ontrolando esta
potencia, para emitir el mnimo necesario para transmitir, se evita la
inter!erencia a otros usuarios o dispositivos.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
G2./01
Selecci,n de +rec-encia #in;mica6 $ebido a que
algunos radares operan en la banda de '+ de ; 'hz, algunos
marcos regulatorios han de!inido que las redes inal,mbricas deben
detectar a los sistemas de radar y cambiar a las !recuencias no
utilizadas por el mismo. Qtras marcos regulatorios requieren de
una utilizacin uni!orme de la banda de ; 'Jz para redes, por lo
que los dispositivos deben tener la capacidad de reubicar los
canales de !orma que su uso es ecualizado.
Ser2!c!# T!3# de Ser2!c!# Descr!3c!+n
#istri9-ci,n $istribucin
"ervicio utilizado en el envo de marcos para
determinar la direccin de destino en redes
de in!raestructura.
Inte(raci,n $istribucin
"ervicio utilizado al reenviar marcos a una
red +666 AEG.- !uera de la red inal,mbrica.
As%ciaci,n $istribucin
"ervicio utilizado para establecer el AP que
servir, de (ate@a4 a una estacin mvil en
particular. Accin que obtiene como
resultado la cone7in de la estacin a la red
inal,mbrica.
'eas%ciaci,n $istribucin
"ervicio usado para cambiar el AP que o!icia
de (ate@a4 a una estacin mvil en
particular.
#esas%ciaci,n $istribucin
"ervicio utilizado para terminar una
cone7in entre una red inal,mbrica y una
estacin.
A-tenticaci,n 6stacin
"ervicio utilizado para establecer la
identidad de la estacin 2!A5 antes de
asociarse a la red. 3lamada tambi8n
?A-tenticaci,n AB2.11@. <o con!undir con la
autenticacin del servicio de
con!idencialidad.
#esa-tenticaci,n 6stacin
"ervicio utilizado para !inalizar una
autenticacin realizada y por lo tanto la
asociacin de una estacin a la red
inal,mbrica.
%n.idencialidad 6stacin "ervicio cuyo objetivo es proveer proteccin
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
G;./01
Ser2!c!# T!3# de Ser2!c!# Descr!3c!+n
contra la violacin de la privacidad de las
transmisiones.
En7>% de !S#/ 6stacin
"ervicio utilizado para enviar los marcos de
datos al destinatario !inal.
%ntr%l de
P%tencia de
$ransmisi,n 2$P5
6stacin .
Administracin de
6spectro '+
"ervicio usado para reducir la inter!erencia,
minimizando la potencia de transmisin.
HAEG.//hI.
Selecci,n de
+rec-encia
#in;mica 2#+S5
6stacin .
Administracin de
6spectro '+
"ervicio utilizado para evitar la inter!erencia
con radares que operan en la banda de '+
de ; 'Jz. HAEG.//hI.
Tabla III.3.: Resumen de los Servicios de Red Inalmbrica.
3os servicios de estacin deben !ormar parte de cualquier estacin
que cumpla con el est,ndar AEG.//. $ichos servicios son provistos tanto
por estaciones mviles como por las inter!aces inal,mbricas de los AP.
ara brindar algunos de estos servicios en posible que se requieran otros.
or ejemplo, las estaciones proveen el servicio de entre(a de !S#/ y
pueden necesitar utilizar el servicio de a-tenticaci,n para realizar una
asociacin.
3os servicios del sistema de distribucin conectan a los AP con el
sistema de distribucin. 6l rol principal de los AP es e7tender los servicios
de la red cableada a la red inal,mbrica. 6sto se logra a trav8s de los
servicios distri9-ci,n e inte(raci,n. Adem,s para mantener los datos de
asociacin y la in!ormacin de localizacin de la estaciones, el sistema de
distribucin brinda los servicios de as%ciaci,n: reas%ciaci,n: 4
desas%ciaci,n.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
G=./01
4. SERVICIOS DE CONFIDENCIALIDAD Y CONTROL DE ACCESO
%n.idencialidad: a veces denominada privacidad, es el t8rmino
utilizado para describir que los datos est,n protegidos contra la
intercepcin de personas no a-t%riCadas. Inte(ridad signi!ica que esos
datos no han sido modi!icados en tr,nsito. A-tenticaci,n es el proceso
mediante el cual se asegura la identidad del origen de los datos. 3a
a-t%riCaci,n 4 c%ntr%l de acces%: que gestionan el acceso a los recursos y
las operaciones permitidas por parte de los usuarios autenticados, se
implementan montados encima de la a-tenticaci,n.
Ambos, privacidad e integridad, dependen de las claves de ci!rado
compartidas Hshared cr4pt%(raphic &e4in(5. or lo tanto el servicio de
c%n.idencialidad depende necesariamente de otros servicios para proveer
de a-tenticaci,n 4 administraci,n de cla7es.
"e aprecian a continuacin los di!erentes bloques que entran en el
juego del servicio de con!idencialidad.
Administraci,n de cla7es 4 a-tenticaci,n 2AD!56 3a
integridad del ci!rado no tiene valor alguno si no evita que los
usuarios no autorizados tengan acceso a la red. 6l servicio de
con!idencialidad depende de la administracin de claves y de la
autenticacin. "u !uncin consiste en establecer la identidad de
cada usuario y las claves de ci!rado. 3a autenticacin puede ser
llevada a cabo por un protocolo e7terno, por ejemplo, AEG./M
C+666AEG/MF o claves preKcompartidas HpreEshared &e4s: PSD5.
Al(%ritm%s de i.rad%6 3a proteccin de los marcos
puede ser realizada por el algoritmo ?EP: utilizando claves de 2E o
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
G0./01
/E2 bits, por el rotocolo de +ntegridad de #laves Demporales %
$emp%ral De4 Inte(rit4 Pr%t%c%l 2DN+I, o por el rotocolo #B#K
MA# Modo #ontador % %-nter !%de )E!A Pr%t%c%l 2!P5.
A-tenticidad del Ori(en6 A !in de evitar ataques de
s-plantaci,n de identidad, DN+ y ##M permiten al receptor
validar la direccin !A del origen. $icha proteccin slo es
!actible para datos tipo /nicast
1
.
#etecci,n de 'epetici,n6 Danto DN+ como ##M,
protegen contra los ata3-es de repetici,n incorporando un
contador de secuencia que se valida una vez que se ha recibido el
marco. 3os marcos que son demasiado ?viejos@ para ser validados
se descartar,n.
Sistemas 4 Pr%t%c%l%s E8tern%s6 6l servicio de
con!idencialidad tiene una !uerte dependencia de protocolos
e7ternos para cumplir su objetivo. 3a administracin de claves es
proporcionada por el protocolo AEG./M que, junto con el protocolo
6A, transporta los datos de autenticacin. "i bien AEG.// no
posee restricciones en los protocolos que pueden utilizarse, las
elecciones m,s comunes en las implementaciones son los
protocolos 6A para la autenticacin y *A$+)" para comunicarse
con el servidor de autenticacin.
Ahora se describir, el !uncionamiento de las distintas
implementaciones del Ser7ici% de %n.idencialidad sobre redes AEG.//.
1 Unicast, forma de transmitir en la cual el marco enviado slo tiene un destinatario.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
GA./01
1. 5E, .5IRED E-UIVALENT ,RIVACY/
O6 !ue inicialmente el servicio de con!idencialidad de la
especi!icacin AEG.// original. )tiliza un conjunto preestablecido de claves
HPSDI para ci!rar cada marco AEG.// con el algoritmo para !lujo de datos
Hstreams cipher5 '4.
6n lneas generales ?EP requiere de los siguientes datos de entrada
para realizar el ci!rado:
3os datos que el marco deber, transportar como carga o
pa4l%ad. 6stos son provistos por la capa superior del stacP de
protocolos.
)na clave secreta, utilizada para ci!rar el marco.
$ependiendo de la implementacin, las claves pueden ser
especi!icadas como una cadena de bits o por el n5mero de clave,
ya que ?EP permite almacenar cuatro claves de !orma simult,nea.
)n *ect%r de InicialiCaci,n 2I*5: utilizado junto con la
clave secreta en la transmisin del marco.
3uego de realizar el proceso de ci!rado, ?EP o!rece como resultado:
)n marco ci!rado, listo para transmitir sobre redes no con!iables, con
su!iciente in!ormacin en la cabecera para permitir su desci!rado en el
receptor del marco.
#omo se ve en la +lustracin +++.;, el driver y la inter!az de hard4are
son responsables de procesar los datos y de enviar el marco ci!rado
utilizando la siguiente secuencia:
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
G1./01
/. 6l marco AEG.// entra en la cola de transmisin. 6ste
marco consiste en una cabecera y en el pa4l%ad. ?EP protege
solamente el pa4l%ad y deja la cabecera intacta.
G. "e calcula un (al%r de he3-e% de Inte(ridad 2I*5
sobre el pa4l%ad original. 63 he3-e% de Sec-encia del !arc%
2+S5 no ha sido calculado en este punto, por lo que no se incluye
en el c,lculo del I*. 6l I* es un '
1
, y por lo tanto es
predecible y cript%(r;.icamente inse(-r% para chequeos de
integridad.
1 Cyclic Redundancy Check, Chequeo de Redundancia Cclico.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
-E./01
Ilustracin III.5.: Operaciones que lleva a cabo WEP
-. 3a la7e de i.rad% del !arc% 2+ED5 % ?EP seed se
ensambla en este punto, esta consta de dos partes: la cla7e
secreta y el vect%r de inicialiCaci,n 2I*5. 3os stream ciphers
producen el mismo !lujo de salida para la misma clave, por lo que
el I* se utiliza para producir !lujos de salida distintos para cada
marco transmitido y se coloca como pre!ijo de la clave secreta. 6l
est,ndar AEG.// no establece ninguna restriccin para el algoritmo
usado para elegir los I*. Algunas implementaciones asignan los I*
de !orma secuencial, otras lo asignan a trav8s de un algoritmo
pseudoaleatorio. 3a seleccin del I* tiene algunas implicaciones de
seguridad, ya que una ?pobre@ seleccin en el I* puede
comprometer la clave.
2. 3a la7e de i.rad% del !arc% se usa como clave '4
para ci!rar el pa4l%ad del marco original del paso / y el I* del
paso G. 6l proceso de ci!rado casi siempre es realizado con
hard4are especializado para el algoritmo '4 en la placa
inal,mbrica.
;. #omo 5ltimo paso, se ensambla el marco a transmitir
!ormado por el pa4l%ad ci.rad%: la cabecera original, y una
cabecera ?EP: !ormada por el I* 4 nFmer% de cla7e. )na vez
ensamblado el nuevo marco se calcula el +S y se realiza la
transmisin. 6l desci!rado del marco se realiza en orden inverso.
?EP ha demostrado tener graves !alencias que lo hacen poco
con!iable como ser7ici% de con!idencialidad, algunas de estas !alencias
se describen continuacin C#JA<EEF:
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
-/./01
1. <o provee ning5n mecanismo para establecer claves
sobre un medio inseguro, por lo que las claves son compartidas por
todas las estaciones en un ))S y a veces entre varios ))S.
G. )tiliza un algoritmo de ci!rado sincrnico sobre un medio
en el que es muy di!cil asegurar la sincronizacin durante una
sesin completa.
-. )sa una clave por marco transmitido, concatenado el I*
directamente con la PSD para producir una clave para '4 para
resolver el problema anteriormente planteado. 6sto e7pone la clave
maestra a ataques del tipo +!S 2+l-hrerE!antinEShamir5.
2. 6s muy limitado el espacio de claves debido a que la
clave maestra es con!igurada de !orma manual y es est,tica, y a
que el I* slo tiene G2 bits de largo. A causa de esto en una red
con tr,!ico medio se produce repeticin de claves cada
apro7imadamente ; horas.
;. 3a reutilizacin de claves es altamente probable, debido
a que AEG.// especi!ica que el recambio del I* es opcional.
=. 6l I* se genera con un algoritmo #*#K-G que es lineal.
0. 6l I* no protege la integridad de la cabecera AEG.//,
permitiendo ataques de redireccin.
A. <o tiene proteccin contra ataques de repeticin.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
-G./01
1. <o posee soporte para que una estacin autentique a la
red.
6n general la principal de!iciencia de ?EP, es que su dise%o
intenta adaptar '4 a un ambiente para el cual no !ue dise%ado.
$. %&$.11! Y 5,A .5IRELESS ,ROTECTED ACCESS/
#uando los problemas en la seguridad de ?EP !ueron e7puestos, la
+666 !orm un grupo de tareas: AEG.//i con la tarea de mejorar la
seguridad en las redes AEG.//. 6ste grupo propuso las 'edes c%n
Se(-ridad '%9-sta % '%9-st Sec-rit4 Net@%r& 2'SN5: esto es una red
que implementa las propuestas de seguridad de AEG.//i y permite slo
dispositivos capaces de cumplir con estas propuestas.
$ebido a que la transicin a 'SN no siempre es !actible como un
proceso inmediato, AEG.//i permite la implementacin de 'edes c%n
Se(-ridad de $ransici,n % $ransiti%nal Sec-rit4 Net@%r&s 2$SN5, que
pueden aceptar la e7istencia de estaciones 'SN 4 ?EP en una red
AEG.//i. #omo su nombre lo indica estas redes deberan moverse
!inalmente, a un esquema de 'SN.
3a propuesta de seguridad especi!icada por el est,ndar, usa el
Est;ndar A7anCad% de i.rad% % Ad7anced Encr4pti%n Standard 2AES5
como algoritmo de ci!rado. 6l problema que se plantea es que AES no es
compatible con el hard4are e7istente, debido que requiere de un
poderoso soporte computacional en las placas de red. Ante a la presin
que esto gener en los !abricantes de equipos, la ?iE+i Alliance, entr en
el juego.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
--./01
3a ?iE+i Alliance, est, !ormada por !abricantes de AEG.// y tiene por
propsito asegurar la interoperabilidad entre los equipos de distintas
marcas. A !in de mejorar la seguridad en las redes inal,mbricas sin
obligar a un cambio en el hard4are inal,mbrico, esta asociacin pidi
como requisito para certi!icar los productos, que estos adoptaran como
est,ndar el protocolo $DIP. 6stas especi!icaciones, pre AEG.//i, se
conocen como ?iE+i Pr%tected Access 2?PA5.
?PA es b,sicamente un subconjunto de las normas AEG.//i, que
incluye las arquitecturas de autenticacin y administracin de claves
HAEG./MI especi!icadas en AEG.//i, tambi8n llamado ?PA2, para evitar
con!usiones. A di!erencia de AEG.//i, que utiliza AES para proveer
con!idencialidad e integridad, ?PA utiliza $DIP 4 !IHAEL,
respectivamente, para realizar estas !unciones.
)no de los logros de AEG.//i en la posibilidad de implementarlo en dos
ambientes totalmente di!erentes: una red SOHO
1
o una red empresarial.
6stos ambientes di!ieren tanto en los requerimientos de seguridad, como
en las capacidades de la in!raestructura que poseen para poder proveer la
seguridad.
ara las redes empresariales, se especi!ica el uso de IEEEAB2.1G
para intercambio de claves y autenticacin. 6sto requiere un servidor de
autenticacin separado. ara los ambientes SOHO, en los cuales no
siempre es posible contar con este tipo de in!raestructura, AEG.//i permite
el uso de PSD.
1 Small Office or Home Office, una oficina pequea o una oficina hogarea.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
-2./01
1. %&$.10 Y EA,
AEG./M C+666AEG/MF est, basado en el Pr%t%c%l% de A-tenticaci,n
E8tensi9le 2EAP5 [EAP]. EAP es una estructura de protocolo. Que, en
vez de especi!icar cmo autenticar a los usuarios, permite a los
dise%adores de protocolos construir sus pr%pi%s mHt%d%s EAP: que son
subprotocolos que ejecutan las transacciones de autenticacin. 3os
mHt%d%s EAP pueden tener di!erentes objetivos, y por lo tanto, pueden
utilizarse m8todos di!erentes dependiendo de las necesidades del caso.
EAP es una simple encapsulacin que puede montarse sobre cualquier
capa de enlace, si bien ha sido montada usualmente sobre vnculos PPP
[PPP]
1
.
3a +lustracin +++.= muestra los !ormatos gen8ricos de los paquetes
EAP transportados en vnculos PPP o en otro tipo de marco. #uando se
transporta EAP en un vnculo PPP: se utiliza el n5mero de protocolo
B8#GG0
G
. 3os campos en cada paquete son los que !iguran en la Dabla
+++.2.
N#*6re de) Ca*3# S!"n!7!cad# de) Ca*3#
,di(% 6ste campo tiene una longitud de / byte e
identi!ica el tipo de paquete EAP, se usa para
1 Point to Point Protocol, protocolo punto a punto.
2 Cada vez que se haga referencia a un nmero en base hexadecimal se usar el prefijo 0x.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
-;./01
Ilustracin III.6.: Formato genrico de los paquetes EAP.
N#*6re de) Ca*3# S!"n!7!cad# de) Ca*3#
interpretar el campo #at%s del paquete.
3os valores asignados son: / H"olicitudI, G
H*espuestaI, - HR7itoI, 2 H&allaI, otro valor
produce que el paquete sea descartado.
Identi.icad%r
6ste campo tiene una longitud de / byte y
contiene un dato de tipo entero sin signo. "e usa
para realizar las correspondencias entre las
peticiones y las respuestas. 3as retransmisiones
utilizan el mismo identi.icad%r, y las
transmisiones nuevas usan un n-e7%
identi.icad%r.
L%n(it-d
6ste campo posee una longitud de G bytes, y es
el n5mero de bytes de longitud de todo el
paquete, incluyendo la cabecera. "i bien en
algunos protocolos de enlace se puede requerir
el relleno, EAP asume que cualquier e7ceso a la
longitud declarada por este campo es relleno y
puede ignorarse.
#at%s
6ste campo posee longitud variable, y
dependiendo del tipo de paquete, puede tener
una longitud nula. 3a interpretacin de este
campo se basa en el valor del campo ,di(%.
Tabla III.4.: Descripcin de los campos del paquete EAP.
3as operaciones que se llevan a cabo con EAP est,n compuestas de
paquetes con solicitudes y respuestas, y en estos casos, el valor del
campo ,di(% tendr, valores / o G respectivamente. 6n esos paquetes
el campo #at%s se descompone en dos subcampos: $ip% 4 #at%s del
$ip%: como se ve en la +lustracin +++.0 y en la Dabla +++.;.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
-=./01
Ilustracin III.7.: Formato de Paquetes EAP: Solicitud y Respuesta.
N#*6re de)
S6ca*3#
S!"n!7!cad# de) S6ca*3#
$ip%
6ste campo tiene una longitud de / byte que
indica el tipo de solicitud o respuesta. "lo un
valor de tipo se usa en cada paquete, y el tipo
de una respuesta es el mismo que el de una
solicitud, a e7cepcin del caso en que una
solicitud es inaceptable y la respuesta puede
tener valor - HNAD5 para sugerir otro tipo
alternativo. 3os valores superiores a - indican
m8todos de autenticacin.
#at%s del $ip%
6ste campo tiene longitud variable y debe ser
interpretado de acuerdo a las reglas para cada
valor de tipo.
Tabla III.5.: Descripcin de los sub campos
$entro de los intercambios S%licit-d"'esp-esta, el campo $ip% de!ine
la estructura que tendr, un paquete EAP. 3os primeros tres valores
de!inidos para este campo se consideran c,di(%s de tip%s especiales. 6l
resto de los cdigos de!inidos de!inen el intercambio de autenticacin, es
decir, de!inen el mHt%d% EAP que se utilizar, en el proceso de
autenticacin.
Dodas la implementaciones de EAP de9en soportar los cdigos de / a
2, y deberan soportar el cdigo G;2. 6n la Dabla +++.= se puede observar
un listado de cdigos de uso com5n para el campo tipo.
C+d!"# T!3# Descr!3c!+n
/ Identidad
6ste cdigo se usa para consultar la identidad del
par a autenticar. )sualmente el autenticador enva
este cdigo en la solicitud inicial. "e recomienda
usar este cdigo con el propsito de seleccionar el
mHt%d% EAP. or ello, los m8todos deberan incluir
un mecanismo para determinar la identidad del par y
no con!iar en la respuesta a este cdigo.
G N%ti.icaci,n
6ste cdigo se usa para enviar un mensaje de
naturaleza imperativa al usuario. 6l par a autenticar,
debera mostrar este mensaje al usuario. <o cambia
el estado de la autenticacin y no es un indicador de
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
-0./01
C+d!"# T!3# Descr!3c!+n
error. or ejemplo puede usarse para noti!icar que
una clave est, a punto de e7pirar o la razn del
bloqueo de una cuenta. #om5nmente no son usados
en AEG./M.
- NAD
6ste cdigo slo puede usarse para 'esp-estas. "e
enva en el caso de que el tipo de autenticacin
deseada sea inaceptable. 3a respuesta contiene uno
o m,s tipos de autenticacin deseados por el par. 6n
caso de que el tipo sea E , se indica de que no hay
alternativas viables para realizar la autenticacin.
2 $esa!o M$;
Autenticacin al estilo #JA, pero con algoritmo
M$;.
; QD
6st, dise%ado para brindar soporte a contrase%as
de un slo uso a sistemas solamente. H*&#GGA1 y
*&#GG2-I.
= 'D#
Darjeta de smbolo gen8rico. M8todo originalmente
desarrollado para usar con tarjetas de smbolos
como la *"A "ecure+$.
/- 6AKD3"
Autenticacin mutua con certi!icados digitales. C6AK
D3"F
/A 6AK"+M
Autenticacin por tel8!ono celular a trav8s del
mdulo de +dentidad del suscriptor H"+MI
G/ 6AKDD3"
D3" por t5nel9 protege m8todos de autenticacin
m,s d8biles con ci!rado D3".
G; 6A
EAP Pr%te(id%I protege m8todos EAP m,s d8biles
con ci!rado D3".
G1 M"K#JAK(G
Autenticacin con contrase%a ci!rada de Microso!t9
compatible con dominios Oindo4s. 'eneralmente
se usa como m8todo de autenticacin interno a un
t5nel protegido protegido por otro m8todo, como
DD3", D3" o 6A.
G;2
Dipos
67pandidos
6ste cdigo se usa para permitir a los !abricantes la
utilizacin de sus propios cdigos de tipo que no son
adecuados para uso general. Dambi8n permite
e7pandir los m8todos a m,s de G;; cdigos. 6sto se
debe a que muchas de las implementaciones de
EAP son espec!icas de cada !abricante.
G;;
)so
67perimental
6ste cdigo no tiene !ormato o contenido espec!ico
y se debera usar para e7perimentar nuevos tipos de
EAP.
Tabla III.6.: Cdigos de tipo de uso comn en EAP.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
-A./01
#omo resultado de los intercambios EAP, el usuario ha sido
autenticado con 87ito o ha !allado la autenticacin. )na vez que el
autenticador determina que el intercambio est, completo, enva un
paquete con el cdigo - Hoperacin e7itosaI, o con el cdigo 2 Hoperacin
!allidaI. 6n ambos casos la longitud del paquete es de 2 bytes y tiene el
!ormato que ve en la +lustracin +++.A
3a capacidad de e8tender los m8todos del protocolo EAP, son los una
de las grandes !ortalezas de este protocolo, ya que permite dise%ar
nuevos m8todos para cumplir con nuevas necesidades.
Al seleccionar un m8todo EAP, se deben tener en cuenta las
capacidades del sistema que realizar, la autenticacin. "i bien los
primeros m8todos dise%ados tenan el !oco sobre todo en proporcionar un
canal de comunicaciones para contactar al servidor de autenticacin, los
m8todos dise%ados para autenticar a los usuarios de redes inal,mbricas
deben, adem,s, cumplir con tres importantes objetivos, como se e7presa
en la Dabla +++.0.
O68e'!2#s Descr!3c!+n
Pr%tecci,n de i.rad% +-erte
de las redenciales de
/s-ari%
or de!inicin, las redes inal,mbricas deberan
considerarse redes abiertas. 6l tr,!ico de datos
sobre estas redes debe protegerse mediante
ci!rado para poder considerarlas ?redes
seguras@. 3a mayora de los m8todos EAP
dise%ados para redes inal,mbricas usan $LS
para proveer proteccin de ci!rado de las
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
-1./01
Ilustracin III.8.: Formato del paquete EAP xito-Falla.
O68e'!2#s Descr!3c!+n
credenciales de usuario.
A-tenticaci,n !-t-a
6l primer protocolo AEG.// consideraba
a-tenticaci,n, a la realizada por el AP para
asociar a las estaciones. $ebido a la posibilidad
de su!rir un ataque de +alsi.icaci,n de AP
1
,
adicionalmente a la autenticacin de los
usuarios, los mismos deberan tener la
capacidad de autenticar o validar la identidad de
la red a la que se conectan.
#eri7aci,n de la7es
3as !unciones de deri7aci,n de claves, se usan
!recuentemente junto a par,metros no secretos
para derivar una o m,s claves desde un valor
secreto. 6sto permite que los protocolos que
utilizan ci!rado !uerte, usen claves din,micas
derivadas, que pueden distribuirse sin distribuir
la clave principal.
Tabla III.7.: Objetivos de los mtodos de autenticacin en redes inalmbricas.
A continuacin se presentan algunos de los m8todos 6A que se
utilizan com5nmente en ambientes inal,mbricos.
1. EA,9TLS
EAPE$LS [EAPE$LS] usa Se(-ridad de la apa de $ransp%rte %
$ransp%rt La4er Sec-rit4 2$LS5 como m8todo de ci!rado. $LS es
considerado el sucesor de SSL
2
y !ue dise%ado para ser usado enlaces
que pueden ser susceptibles de interceptacin. $LS provee a-tenticaci,n
m-t-a a trav8s de intercambio de certi!icados digitales. 3os clientes
deben enviar un certi!icado digital al servidor de autenticacin para
validarse y el servidor de autenticacin debe enviar un certi!icado al
cliente.
1 Falsificacin de AP: Ataque realizado por un AP externo a la infraestructura propia, que ha
configurado el mismo ESSID, para engaar a los usuarios y robar sus identidades cuando se
conectan a l pensando que se conecta a la red propia. Tambin son llamados Rogue AP.
2 Secure Socket Layer, Capa de Conexin Segura.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
2E./01
(alidando el certi!icado enviado por el servidor de autenticacin contra
una lista de autoridades de certi!icacin, el cliente asegura que su
cone7in es a una red autorizada por la autoridad certi!icante y viceversa.
6l m8todo EAPE$LS, !ue el primer m8todo de autenticacin que
cumpli con los tres objetivos mencionados anteriormente en la Dabla
+++.0. 3a a-tenticaci,n m-t-a evita los ataques de .alsi.icaci,n de AP y
$LS usa una clave maestra que puede ser utilizada para deri7ar cla7es
que usan los protocolos de seguridad de capa de enlace.
EAPE$LS no ha sido utilizado en !orma masiva debido a la gran
complicacin que signi!ica el montar una In.raestr-ct-ra de la7es
PF9licas 2PDI5, para las organizaciones que no la poseen. 6sto obliga a
la generacin y distribucin de certi!icados a todos los usuarios, es por
ello que muchas organizaciones utilizan m8todos alternativos.
3a mayora de las organizaciones pre!iere utilizar sistemas de
autenticacin e7istentes, por ejemplo directorios L#AP, Acti7e #irect%r4,
#%mini%s ?ind%@s: etc. $e esta !orma se evita crear un sistema de
autenticacin paralelo.
$. EA,9TTLS Y EA,9,EA,
Danto EAPE$$LS [EAPE$$LS] como EAPEPEAP [PEAP]: usan
certi.icad%s di(itales para autenticar la red
/
hacia al cliente9 pero, a
di!erencia de EAPE$LS: no usan certi.icad%s para autenticar al cliente
hacia la red. 6n lugar de certi.icad%s di(itales: los clientes se autentican
al servidor con m8todos basados en contrase%as. 6sto permite utilizar
1 La red o el servidor en este contexto se consideran sinnimos.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
2/./01
sistemas de autenticacin e7istentes en la organizacin y reduce
notablemente la cantidad de certi!icados que se necesita emitir.
Ambos m8todos trabajan de de !orma similar. rimero establecen un
tFnel D3" entre el cliente y el servidor de !orma similar a EAPE$LS. ara
ello utilizan el certi.icad% di(ital que autentica al servidor, antes de
proceder a la segunda !ase.
)na vez completada satis!actoriamente la primera !ase, usan el tFnel
$LS como canal de comunicaciones ci!rado para realizar el proceso de
autenticacin del usuario con un m8todo de autenticacin basado en
contrase%as. &recuentemente se llama a-tenticaci,n e8terna a la primera
!ase y a-tenticaci,n interna a la segunda !ase.
3a di!erencia entre EAPE$$LS y EAPEPEAP es la !orma en que se
realiza el proceso de a-tenticaci,n interna. EAPE$$LS usa el tFnel para
intercambiar pares de atributoKvalor, mientras que EAPEPEAP utiliza el
tFnel para iniciar otra sesin EAP. EAPE$$LS es m,s !le7ible porque al
usar pares atributoKvalor puede ejecutar m8todos de autenticacin que no
est,n implementados con EAP.
)na de las ventajas de utilizar EAPE$$LS % EAPEPEAP es que las
a-tenticaci%nes internas 4 e8ternas pueden usar di!erentes nombres de
usuario. 6sto evita revelar el nombre de usuario en los marcos enviados
sin ci!rado si se utiliza un nombre de usuario annimo para el proceso de
a-tenticaci,n e8terna. <o todos los clientes de so!t4are soportan este
comportamiento.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
2G./01
1. FUNCIONAMIENTO DE %&$.10
AB2.1G provee un marco para realizar autenticacin de usuarios sobre
cualquier tipo de 3A<. #ontrola el acceso a la red bas,ndose en habilitar
y deshabilitar un puerto !sico de red
/
, este tipo de autenticacin se
denomina p%rt 9ased. $e!ine tres componentes, el s-pplicant, el
a-tenticad%r 4 el ser7id%r de a-tenticaci,n: como se observa en la
+lustracin +++.1.
6l s-pplicant y el a-tenticad%r se consideran Entidades de
A-tenticaci,n p%r P-ert% 2PAEs5 dentro de la especi!icacin. AB2.1G evita
el acceso a la red solicitando al usuario iniciar el proceso de autenticacin
antes de permitir paso de tr,!ico de datos. 3os puertos no autorizados
1 Tpicamente se refiere a un puerto de un switch.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
2-./01
Ilustracin III.9.: Componentes de 802.1X
est,n restringidos a enviar slo marcos de autenticacin EAPOL 2EAP
%7er LAN5.
"e considera ?puertoJ AB2.1G en redes inal,mbricas a la asociacin
entre un dispositivo inal,mbrico y el AP. )na vez que se completa el
proceso de asociacin, se reporta a la m,quina de estados de AB2.1G y la
estacin puede iniciar el proceso de autenticacin. )na vez que este
proceso se lleva a cabo de !orma e7itosa, incluido el intercambio de
claves, la estacin puede iniciar el tr,!ico de datos.
3a principal di!erencia de un intercambio 6AQ3 con un intercambio
6A, es que los s-pplicants pueden enviar un marco EAPOLEStart para
disparar el proceso de intercambio y pueden enviar un marco EAPOLE
L%(%.. para desautorizar un puerto.
6n la +lustracin +++./E se puede observar el proceso de de un
intercambio EAPOL en IEEEAB2.11. 6n el mismo se lleva a cabo una
autenticacin e7itosa a trav8s de los siguientes pasos:
/. 6l s-pplicant se asocia a la red AEG.//, este proceso es un
simple intercambio de dos marcos.
G. 6l s-pplicant inicia el intercambio AB2.1G con un mensaje
EAPOLEStart. 6ste paso es opcional.
-. "e inicia un intercambio EAP. 6l A-tenticad%r enva un
mensaje EAPE'e3-est"Identit4. 6ste mensaje se puede enviar sin
necesidad de recibir primero un mensaje EAPOLEStart si el AP slo
permite reenvo de marcos autenticados.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
22./01
4. El s-pplicant responde con un mensaje EAPE
'esp%nse"Identit4: que el A-tenticad%r reenva al ser7id%r 'A#I/S
como solicitud de acceso.
;. 6l servidor *A$+)" determina el tipo de autenticacin que
se requiere y enva un mensaje EAPE'e3-est para el m8todo
requerido. or ejemplo si el m8todo requerido !uese EAPEPEAP, el
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
2;./01
Ilustracin III.10.: Intercambio 802.1X en 802.11. Proceso de Autenticacin.
mensaje sera EAPE'e3-est"PEAP. $icho mensaje se encapsula en
un mensaje 'A#I/SEAccessEhallen(e y se enva al AP: que a su vez
lo reenva al s-pplicant.
=. 6l s-pplicant toma las credenciales suministradas por el
usuario y devuelve un mensaje EAPE'esp%nse. 6l A-tenticad%r
traduce esta respuesta en un mensaje 'A#I/SEAccessE'e3-est con
la respuesta al desa!o del paso ; en el campo de datos. 3os pasos ;
y = pueden repetirse tantas veces como sea necesario para completar
el proceso de autenticacin. "i el mHt%d% EAP utiliza intercambio de
certi!icados es posible que se repitan entre /E y GE veces.
0. 6l "er7id%r de A-tenticaci,n concede acceso con un
mensaje 'A#I/SEAccessEAccept, que el A-tenticad%r traduce como
mensaje EAPES-ccess. 6n este punto del proceso, el A-tenticad%r
a-t%riCa el ?puerto@.
A. +nmediatamente despu8s de recibir el mensaje 'A#I/SE
AccessEAccept el AP distribuye las claves al s-pplicant utilizando
mensajes EAPOLEDe4.
1. 6l s-pplicant instala las claves y comienza a enviar marcos
de datos a la red. 6s en esta etapa donde se lleva a cabo la
con!iguracin #HP.
/E. #uando el s-pplicant !inaliza el acceso a la red, enva un
mensaje EAPEL%(%.. y el A-tenticad%r cambia el estado del puerto a
n%Ea-t%riCad%.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
2=./01
ara evitar el compromiso de las claves, los marcos de intercambio de
las mismas se envan slo si el proceso de autenticacin tiene 87ito. 3os
mensajes EAPOLEDe4 se utilizan para actualizar las claves de !orma
peridica.
$. CONFIDENCIALIDAD E INTEGRIDAD EN %&$.11I
3a mayor di!erencia entre ?PA y AB2.11i 2?PA25 es que mientras
?PA2 utiliza AES para proveer con!idencialidad e integridad, ?PA utiliza
$DIP y !IHAEL respectivamente.
?PA e7tiende los dos niveles de jerarqua de las claves utilizadas por
O6. 6n e!ecto: ?EP utiliza una cla7e maestra H!DI para autenticacin y
para calcular las claves de cada paquete, al concatenar la !D con el
7ect%r de inicialiCaci,n 2I*5.
AB2.11i utiliza la !D: tambi8n denominada PairE@ise !aster De4
2P!D5: proporcionada por el proceso de autenticacin realizado por
AB2.1G % por la con!iguracin manual de una Preshared Secret De4
2PSD5. A partir de la P!D, se derivan un grupo de claves transitorias o de
sesi,n, denominadas PairE@ise $ransient De4s 2P$D5 y a partir de las
P$D: a trav8s de una !uncin de mezcla de claves, se generan las claves
para cada paquete.
Adem,s, se utiliza un grupo de claves di!erentes para las
comunicaciones tipo 9r%adcast 4 m-lticast. 6l a-tenticad%r mantiene una
Kr%-p !aster De4 2K!D5 para derivar las claces transitorias de grupo o
Kr%-p $ransient De4s 2K$D5. <o se puede derivar K!D a partir de las
claves que utiliza cada estacin para el tr,!ico -nicast. 3as jerarquas de
claves se pueden apreciar en las +lustraciones +++.// y +++./G.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
20./01
6l algoritmo Pse-d%Ealeat%ri%2P'+5 que se utiliza para realizar la
derivacin de las claves transitorias desde la P!D necesita de cuatro
argumentos, las direcciones !A tanto de la estacin, como del
a-tenticad%r y dos valores denominados SN%nce 4 AN%nce: uno
suministrado por la estacin y otro suministrado por el a-tenticad%r.
<once, es un acrnimo de N-m9erEOnce 2NFmer% -na 7eCI, es un valor
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
2A./01
Ilustracin III.11.: Jerarqua de claves 802.11i comparada con WEP.
arbitrario que no puede repetirse nunca, y permite di!erenciar dos
sesiones di!erentes.
#omo la P!D y los argumentos necesarios del P'+ son compartidos
por la estacin y el AP: ambos realizar la derivacin de claves y obtener la
P$D.
6l proceso de $DIP 4 !IHAEL para derivar las claves de ci!rado de
cada paquete se puede observar en la +lustracin +++./-. 3os detalles
importantes de este proceso son:
/. "e utiliza un c%ntad%r de sec-encia % I* de 2A bits.
G. 6l tama%o de la clave de ci!rado es de /E2 bits para
mantener compatibilidad con el hard4are con soporte ?EP.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
21./01
Ilustracin III.12.: Jerarqua de claves de grupo de 802.11i.
-. ara disminuir la carga de proceso en la placa de red, se
divide el proceso de generacin de claves en dos !ases. 3a primera
!ase requiere de mayor potencia de c,lculo que la segunda.
2. Al involucrar los -G bits de mayor orden del c%ntad%r de
sec-encia, la primera !ase slo debe ejecutarse cuando cambian
estos bits, cada =;.;-= paquetes.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
;E./01
Ilustracin III.13.: Proceso de cifrado de cada paquete en WAP.
;. 3a !uncin de meCcla de cla7es hace muy di!cil para
quien intercepta el tr,!ico encontrar un correlato entre el n5mero de
secuencia y la clave de cada paquete.
6l proceso de che3-e% de inte(ridad del mensa<e 2!I5 en general
utiliza c,lculos intensivos que requieren el uso de hard4are acorde Hpor
ejemplo M$; o "JAK/I. 3a solucin de compromiso que se usa en ?PA:
debido a la restriccin de c,lculo que e7iste en el hard4are, es !IHAEL,
un nuevo protocolo !I, que utiliza operaciones de desplazamiento y
suma.
!IHAEL es una mejora sobre el algoritmo lineal '32 que utiliza
?EP. > como es una solucin de compromiso, $DIP implementa
contramedidas en caso de que !IHAEL sea comprometido, por ejemplo,
si $DIP detecta dos paquetes en que el !I calculado no coincide con el
!I del paquete en el lapso de un segundo, in!iere que la estacin est,
bajo un ataque y borra sus claves, desasocia la estacin y espera un
minuto para volver a asociarla nuevamente.
AB2.11i2?PA25 aborda el servicio de con!idencialidad e implementa un
algoritmo para ci!rado por bloques en lugar de un algoritmo de ci!rado de
streams. ara reemplazar a '4 utiliza A6" en modo contador,
combinando la seguridad de un algoritmo de ci!rado de bloques con la
!acilidad de uso de un algoritmo de ci!rado de streams.
ara proveer el servicio de integridad se utiliza !P 2%-nterEm%de
)E!A Pr%t%c%l5. 6ste opera realizando GO' de un bloque en ?te7to
plano@ con el bloque previo que usa el algoritmo de ci!rado antes de que
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
;/./01
el mismo sea ci!rado. 6l proceso se puede observar en la +lustracin
+++./2.
6n la Dabla +++.A se puede apreciar la comparacin de ?PA: ?PA2 4
?EP. 6sta comparacin tiene el !oco en las debilidades de los servicios
de con!idencialidad e integridad de ?EP listados en la p,gina -/.
5E, 5,A 5,A$
<o provee mecanismos para
establecimiento de claves
sobre medios inseguros. 3as
claves son compartidas en
todo el )SS y
!recuentemente en el ESS.
*ecomienda el uso de
AEG./M para autenticacin y
establecimiento de claves.
Dambi8n puede utilizar
preshared &e4s como ?EP.
+dem ?PA.
)tiliza un algoritmo de +dem ?EP. )tiliza un algoritmo !uerte de
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
;G./01
Ilustracin III.14.: Proceso de cifrado de cada paquete en 802.11i.
5E, 5,A 5,A$
ci!rado sincrnico para
streams, sobre un medio en
el que es muy di!cil
asegurar la sincrnizacin
sobre una sesin completa.
ci!rado por bloques HAESI.
)tiliza una clave porK
paquete que se construye
concatenando la !D c%n el
I* directamente. 6sto
e7pone la !D a ataques del
tipo +!S.
+ncorpora el concepto de
P$D en la jerarqua de
claves y utiliza una !uncin
de mezcla de claves, en vez
de la concatenacin directa
para generar las claves porK
paquete. *educe la
e7posicin de la !D.
+dem ?PA.
6spacio de claves limitado
debido a la !D con!igurada
manualmente y al I* de G2
bits.
Aumenta el tama%o del I* a
;= bits, usando slo 2A bits y
reservando A bits para
descartar claves d8biles.
*egenera las P$D en cada
nueva sesin, aumentando
el espacio de claves
+dem ?PA.
6l recambio de I* es
opcional, por lo que la
reutilizacin de claves es
altamente probable.
67plcitamente especi!ica
que se debe inicializar el I*
a E cada vez que se
establece una nueva P$D.
+dem ?PA.
6l algoritmo de !I usado
es #*#-G. 6s lineal y
provee una proteccin de
integridad muy d8bil.
)tiliza !IHAEL como
algoritmo de !I, que no es
lineal y tambi8n especi!ica
contramedidas de proteccin
en caso de que el mismo
sea comprometido.
rovee una !uerte proteccin
de integridad al utilizar
!P: 9asad% en AES.
6l I* no protege la
cabecera del paquete, por lo
que e7iste el peligro de un
ataque de redireccin.
67tiende la proteccin del
I* para incluir las
direcciones de origen y
destino. rotege de esta
!orma contra los ataques de
redireccin.
+dem ?PA.
<o tiene proteccin contra
los ataques de repeticin.
)tiliza I* como n5mero de
secuencia para proteger
contra los ataques de
repeticin.
+dem ?PA.
<o tiene soporte para que
las estaciones autentiquen a
la red.
<o provee de !orma e7plcita
una solucin a este
problema, pero, al
recomendar el uso de
AB2.1G: puede utilizarse el
+dem ?PA.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
;-./01
5E, 5,A 5,A$
mismo para que las
estaciones autentiquen a la
red HEAPE$LS:EAPE$$LS 4
EAPEPEAP5.
Tabla III.8.: Comparacin entre las falencias de WEP y las soluciones de
WPA/WPA2.
:. ,,,OE
PPP %7er Ethernet 2PPP%E5 [PPP%E] brinda la posibilidad de
encapsular una sesin PPP [PPP] en marcos Ethernet. 6l protocolo PPP
requiere de una cone7in punto a punto entre el concentrador de acceso
HAI y el cliente, por lo tanto no se ha dise%ado para las comunicaciones
tipo multipunto que e7isten en una red Ethernet.
6l principal uso de PPP%E son las tecnologas de acceso remoto a
trav8s de banda ancha, donde brinda la capacidad de de conectar un
cliente a un A a trav8s de un dispositivo de 9rid(in(.
6l protocolo hereda de PPP la posibilidad de mantener estadsticas de
tr,!ico, e!ectuar controles de integridad de los datos del marco, asignar
direcciones de red y, al ser un protocolo de capa de enlace, puede
transportar cualquier protocolo.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
;2./01
Ilustracin III.15.: Marco PPPoE.
6l principal problema que plantea la implementacin de PPP%E est,
relacionado con el tama%o m,7imo de la !$/
1
, el cual es in!erior al de un
marco ethernet debido a la encapsulacin. 6sto causa la !ragmentacin
del paquete con la consecuente reduccin del rendimiento.
6n la se puede apreciar la disposicin de los campos de un marco
PPP%E y en la Dabla +++.1 el signi!icado de los mismos.
Ca*3# S!"n!7!cad#
*ersi,n
6ste valor tiene 2 bits de longitud y debe ser E7/ para la versin
especi!icada en la '+2011.
$ip%
6ste valor tiene 2 bits de longitud y debe ser E7/ para la versin
especi!icada en la '+2011.
,di(%
6ste valor se usa para especi!icar la !ase del estado de
descubrimiento y de sesin PPP.
I#LSesi,n
6l valor es B8BBBB durante las !ase de descubrimiento para
marcos de tipo #isc%7er4 2e8cept% para marc%s PA#$ 4 PA#S5,
y una vez establecida la sesin PPP: se usa para identi!icar la
cone7in junto con las direcciones de %ri(en 4 destin%. 6l valor
E7&&&& se ha reservado para uso !uturo y no debe utilizarse.
L%n(it-d
6ste valor indica la longitud de la carga del marco PPP%E, no
incluye las cabeceras Ethernet % PPP%E.
#at%s
6l campo #at%s contiene las cabeceras del protocolo PPP y los
datos a transmitir.
Tabla III.9.: Significado de los campos del marco PPPoE.
6l proceso de #isc%7er4 % #esc-9rimient% que se lleva a cabo al
iniciar una sesin PPP%E consta de 2 !ases di!erentes. $urante este
proceso el campo $4pe del marco Ethernet tiene el valor B8AA13. 3a
sntesis del proceso se puede observar en la Dabla +++./E.
1 MTU, Maximum Transmition Unit. Unidad mxima de transmisin que especifica el mximo
tamao de paquete que se puede transmitir.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
;;./01
Fase Sen'!d# T!3# de Marc#
+ase 1 liente EEM Ser7id%r
,ADI; PPP%E Acti7e #isc%7er4 Initiati%n
*al%r camp% ,di(%6 B8BN
*al%r camp% I#LSesi%n6 B8BBBB
+ase 2 liente OEE Ser7id%res
,ADO; PPP%E Acti7e #isc%7er4 O..er
*al%r amp% ,di(%6 B8BP
*al%r camp% I#LSesi%n6 B8BBBB
+ase 3 liente EEM Ser7id%r
,ADR; PPP%E Acti7e #isc%7er4 'e3-est
*al%r amp% ,di(%6 B81N
*al%r camp% I#LSesi%n6 B8BBBB
+ase 4 liente OEE Ser7id%r
,ADS; PPP%E Acti7e #isc%7er4 Sessi%nE
%n.irmati%n.
*al%r amp% ,di(%6 B810
*al%r camp% I#LSesi%n6 NFmer% de sesi,n.
,ADT; PPP%E Acti7e #isc%7er4 $erminated
*al%r amp% ,di(%6 B8AP
*al%r camp% I#LSesi%n6 NFmer% de sesi,n.
Tabla III.10.: Fases de Descubrimiento de PPPoE.
/. 6l cliente enva un marco PA#I al 9r%adcast Ethernet para
descubrir los A# disponibles.
G. 6l A que recibe el marco responde con un marco -nicast PA#O
para in!ormar de su e7istencia. uede responder m,s de un A.
-. 6l cliente selecciona el A entre los marcos PA#O recibidos y
enva un marco -nicast PA#' al A seleccionado.
2. 6l A concede una sesin al cliente y enva un marco -nicast
PA#S que incluye el n5mero de sesin concedido. Dambi8n puede
enviar un marco -nicast PA#$ para terminar la comunicacin en
cualquier momento.
)na vez que la sesin PPP%E se establece, se inicia la sesin PPP
normalmente. 3os marcos Ethernet de esta !ase tienen el valor B8AA14 en
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
;=./01
el campo tip%, el valor del campo c,di(% de PPP%E debe tener el valor
E7EE y el campo I#LSesi,n no debe cambiar durante toda la sesin.
<. LDA,
Li(ht@ei(ht #irect%r4 Access Pr%t%c%l 2L#AP5 [L#AP1] [L#AP2] es un
protocolo de Internet para acceder a servicios de directorio distribuidos
que act5an en concordancia con los modelos de datos y servicios G.0BB
de!inidos por la ISO
1
.
"eg5n M.;E/ ?6l propsito del $irectorio es contener y proveer acceso
a objetos almacenados en 8l ... )n objeto puede ser cualquier entidad que
sea identi!icable. )na clase de objeto es una !amilia de objetos
identi!icados que comparten alguna caracterstica.@
3a unidad b,sica de in!ormacin que contiene el $irectorio es una
entrada de direct%ri%. 67isten m5ltiples clases de entradas de directorio.
6l conjunto de entradas de directorio que representan la )ase de
In.%rmaci,n del #irect%ri% 2#I)5 4 se organizan jer,rquicamente en una
estructura de ,rbol llamada =r9%l de In.%rmaci,n del #irect%ri% 2#I$5. 3as
ramas entre dos entradas de directorio de!inen las relaciones entre ellas,
y entre los objetos que dichas entradas representan.
)na entrada de direct%ri% consiste en un conjunto de atri9-t%s que
contienen in!ormacin acerca del %9<et% que la entrada representa. 3os
atri9-t%s que representan in!ormacin operativa o administrativa se
1 ISO, International Organization for Standarization. Organizacin Internacional para la
Estandarizacin.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
;0./01
llaman atri9-t%s %perati7%s. 6n las de!iniciones de cada clase de objeto se
de!inen los atributos que est,n relacionados con un objeto de dicha clase.
)n atributo est, compuesto por una descripcin del atributo Hun tipo y
ninguna o alguna opcinI y por uno o m,s valores asociados.
#ada entrada de directorio se nombra de !orma relativa a su inmediato
superior. 6ste nombre relativo se denomina 'elati7e #istin(-ished Name
2'#N5: y debe ser 5nico entre todos los subordinados de la entrada
superior inmediata. #ada *$< se compone de uno o m,s pares atri9-t%E
7al%r. or ejemplo: -idQ12340I %-Q7entas: etc.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
;A./01
......
attributetype ( 2.16.840.1.113730.3.1.4
NAME 'employeeType'
DESC 'RFC2798: type of employment for a person'
E!A"#T$ %ase#&noreMat%'
S!(STR %ase#&noreS)*str+n&sMat%'
S$NTA, -.../.-.0.-.-0//.--1.-2-.-.-1 2
.......
objectclass ( 2.16.840.1.113730.3.2.2
NAME '+net3r&4erson'
DESC 'RFC2798: #nternet 3r&an+5at+onal 4erson'
S!4 or&an+5at+onal4erson
STR!CT!RA"
MA$ (a)6+o 7 *)s+nessCate&ory 7 %ar"+%ense 7 6epartmentN)m*er
7 6+splayName 7 employeeN)m*er 7 employeeType 7 &+8enName
7 'ome4'one 7 'ome4ostalA66ress 7 +n+t+als 7 9pe&4'oto
7 la*ele6!R# 7 ma+l 7 mana&er 7 mo*+le 7 o 7 pa&er
7 p'oto 7 roomN)m*er 7 se%retary 7 )+6 7 )serCert+f+%ate
7 :1;;)n+<)e#6ent+f+er 7 preferre6"an&)a&e 7
)serSM#MECert+f+%ate 7 )ser4=CS-2 2
Texto III.1.: Ejemplo de schema en LDAP.
6l n%m9re t%talmente cali.icad% de una entrada es el #istin(-ished
Name 2#N5 y es la concatenacin de su '#N con el #N de su superior
inmediato. 6l #N identi!ica unvocamente una entrada en el #I$. or
ejemplo, un #N sera: NQR-an PereC:O/Q*entas:OQA!E S'L:
LQK%d%4 r-C: S$Q!end%Ca:QAr(entina.
Dodos los elementos que componen el #I$ est,n de!inidos en el
es3-ema % schema, usando la sinta7is que se puede observar en el
cuadro de De7to +++./.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
;1./01
6n: )+6>;;?a6m+ns@o)>prof+les@6%>)m@6%>e6)
o*9e%tClass: ra6+)s3*9e%t4rof+le
o*9e%tClass: ra6+)sprof+le
o*9e%tClass: top
ra6+)sFrame64roto%ol: 444
ra6+)sSer8+%eType: "o&+n
str)%t)ral3*9e%tClass: ra6+)s3*9e%t4rof+le
entry!!#D: 06a;%;7;?7/1.?-;2*?8-86?1.%6.ee9*8/*
%reatorsName: %n>a6m+n@6%>)m@6%>e6)
%reateT+mestamp: 2;;7;0;.-72;;.A
6+al)pA%%ess: yes
ra6+)sF+lter#6: 1;
)+6: ;;?a6m+ns
%n: ;;?a6m+ns
6es%r+pt+on: ?N mar%a?a6m+ns ?t man&le
6es%r+pt+on: ?A mar%a?a6m+ns ?t man&le ?9 MAR= ??set?marB 1;
6es%r+pt+on: ?A 4RER3!T#NC ?t man&le ?s -92.-/8.-7/.;D2/ ?m marB ??
marB ; ?9 mar%a?a6m+ns
6es%r+pt+on: ?N f+ltra?a6m+ns
6es%r+pt+on: ?A F3REARD ?m marB ??marB 1; ?9 f+ltra?a6m+ns

Texto III.2.: Ejemplo archivo LDIF.
6n la de!inicin del cuadro de De7to +++./, tambi8n se puede observar
un n5mero resaltado, este n5mero identi!ica a cada tipo de elemento y se
denomina OI# H%9<ect Identi.ierI. El OI# es global y 5nico en el esquema.
"i bien el #I$ almacena los datos en !orma binaria, se puede observar
en el cuadro de De7to +++.G una entrada de directorio en !ormato L#I+
1
,
donde aparece el #N: las clases a las 3-e pertenece 4 l%s atri9-t%s de un
objeto.
=. RADIUS
'A#I/S
2
['A#I/S]
3
C*A$+)"A##F
2
es un protocolo de control de
acceso que autentica usuarios a trav8s de un m8todo muy com5n
denominado gen8ricamente desa.>%"resp-esta. 6l proceso que lleva a
cabo se denomina AAA
0
.
6l proceso de AAA se puede sintetizar en las siguientes preguntas que
realiza el servidor de acceso al cliente:
SQui8n eresT
SQu8 servicios estoy autorizado a darteT
SQu8 hiciste con los servicios mientras los usabasT
1 LDAP Data Interchange Format, definido en las RFC2849 y modificado en la RFC 4525.
2 Remote Authentication Dial In User Service. Servicio de Autenticacin de Usuarios
Remotos.
3 La RFC2865 ha sido actualizada por las RFC2868 y RFC3575. Y deja obsoleta a la
RFC2138.
4 La RFC2866 ha sido actualizada por la RFC2867 y deja obsoleta a la RFC2139.
5 Autherntication, Authorization and Accounting. Autenticacin, Autorizacin y Registro.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
=E./01
3a A-tenticaci,n es el proceso de veri!icar la identidad que ha
declarado un cliente Hm,quina o personaI. )no de los m8todos m,s
comunes para realizar esta tarea es utilizar un nombre de usuario y una
contrase%a. 6l objetivo principal de este proceso es !ormar una relaci,n
de c%n.ianCa entre el cliente y el servidor.
6l proceso de A-t%riCaci,n consta de un conjunto de reglas para
decidir qu8 puede hacer un usuario autenticado en el sistema. 3as reglas
son de!inidas por los administradores del sistema.
6l 'e(istr% es el proceso que documenta el uso de los recursos
hecho por los usuarios que acceden al sistema. 3os datos recabados por
el proceso de 'e(istr% se pueden utilizar para controlar autorizaciones
realizadas, cobrar la utilizacin de recursos, medir tendencias en el uso
de recursos, y para realizar actividades relacionadas con la plani!icacin
del crecimiento.
3as caractersticas generales del protocolo, de!inidas en la '+2A10,
son:
)sa un modelo liente""ervidor, donde el modelo de
seguridad que se utiliza se denomina h%pE94Eh%p: y se basa en un
secreto compartido entre el NAS
1
4 el Ser7id%r que no se transmite
en la red.
)tiliza /#P"IP para las cone7iones.
6s un protocolo stateless, es decir sin estado.
1 Network Access Server. Servidor de acceso a la red, usualmente es la entidad que recibe la
peticin de acceso del usuario y solicita al servidor RADIUS la autenticacin del mismo.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
=/./01
"oporta una gran variedad de m8todos de autenticacin,
que otorgan una gran !le7ibilidad. "oporta PAP: HAP: EAP: /ni8:
entre otros.
6l protocolo es e8tensi9le. Dodas las transacciones
utilizan un tro de valores Atri9-t%EL%n(it-dE*al%r, y permite agregar
de!iniciones de valores sin comprometer el !uncionamiento de las
implementaciones e7istentes.
6l protocolo se comunica a trav8s de los puertos )$./A/G y
)$./A/-. 6n la +lustracin +++./= se puede apreciar la estructura del
paquete 'A#I/S. 6n la Dabla +++.// se puede observar el signi!icado de
los campos del paquete 'A#I/S.
Ca*3# Descr!3c!+n
,di(%
6ste campo es el que distingue el tipo de mensaje 'A#I/S. 3os
paquetes con cdigo inv,lido se descartan.
3os cdigos permitidos son: AccessE'e3-est 215: AccessEAccept 225:
AccessE'e<ect 235: Acc%-ntin(E'e3-est 245: Acc%-ntin(E'esp%nse
205: AccessEhallen(e 2115: Stat-sESer7er 2125: Stat-sElient 2135:
'eser7ad% 22005.
Identi.icad%r
6ste valor se utiliza para relacionar una respuesta a una solicitud.
Dambi8n permite que el servidor 'A#I/S detecte las solicitudes
duplicadas que se realizan en un corto perodo de tiempo,
comparando la direccin IP y el puerto /#P origen, junto con el
identi!icador.
L%n(it-d
+ndica la longitud Hincluye ,di(%: Identi.icad%r: L%n(it-d:
A-tenticad%r 4 #at%s5 y si el paquete es m,s largo se descarta el
e7cedente y si el paquete es m,s corto se descarta. 3as longitudes
v,lidas oscilan entre GE 94tes 4 4BN1 94tes.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
=G./01
Ilustracin III.16.: Estructura del paquete RADIUS.
Ca*3# Descr!3c!+n
A-tenticad%r
#on este valor se veri!ica la integridad de los datos. 67isten dos
tipos di!erentes de valores: S%licit-d 4 'esp-esta. 6l primer valor se
calcula de !orma aleatoria. 6l segundo valor se calcula con el
algoritmo !#0 en !uncin de los siguientes par,metros: ,di(%:
Identi.icad%r: L%n(it-d: A-tenticad%r de la s%licit-d: #at%s: Secret%5.
Atri9-t%s 4 *al%res
6ste campo de longitud variable es el contiene los pares atri9-t%E
7al%r que intercambia el servidor con el NAS.
Tabla III.11.: Descripcin de los campos de un paquete RADIUS.
6n los procesos de A-tenticaci,n 4 A-t%riCaci,n son relevantes cuatro
tipos de paquetes: AccessE'e3-est: AccessEAccept: AccessE'e<ect: 4
AccessEhallen(e. 6l primer paso del proceso de autenticacin lo ejecuta
el usuario.
6l cliente solicita acceso a un servicio particular al enviar al Ser7id%r
'A#I/S un paquete del tipo AccessE'e3-est. 6l paquete debe contener
ciertos atributos que son signi!icativos para el proceso de autenticacin.
or ejemplo, debe contener atributos que identi!iquen al NAS 2NASEIPE
Address 4"% NASEIdenti.ierI, la contrase%a del usuario 2/serEPass@%rd %
HAPEPass@%rd5 y debera contener nombre de usuario 2/serEName5 y el
puerto de cone7in 2NASEP%rt 4"% NASEP%rtE$4peI. 6l paquete AccessE
'e3-est puede contener atributos adicionales. "i el atri9-t% /serE
Pass@%rd est, presente, no debe transmitirse en te7to plano, sino
utilizando un hash !#0. Al recibir el paquete, el servidor debe determinar
y comunicar si el usuario tiene permitido el acceso a trav8s del NAS y al
tipo de servicio que ha solicitado. Dodos los paquetes v,lidos de este
tipo deben ser contestados por el servidor, ya sea con un paquete del tipo
AccessEAccept: del tipo AccessE*eject o del tipo AccessEhallen(e.
)na vez que el servidor ha procesado un paquete tipo AccessE
'e3-est y ha determinado que todos los atributos son aceptables y se
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
=-./01
puede conceder acceso al usuario, enva un paquete del tipo AccessE
Accept. 6ste paquete debe proveer la in!ormacin necesaria para realizar
con!iguracin espec!ica a !in de comenzar con la utilizacin del servicio.
6l campo A-tenticad%r debe contener la respuesta correcta para el campo
A-tenticad%r de paquete tipo AccessE'e3-est que ha recibido
previamente.
6l servidor puede enviar al usuario un desa!o que requiera de una
respuesta para disminuir el riesgo de una autenticacin !raudulenta. "i
este es el caso se enva al cliente un paquete del tipo AccessEhallen(e
al que el cliente debe responder con un paquete del tipo AccessE'e3-est
que incluya los atributos apropiados. 6n el paquete AccessEhallen(e se
pueden incluir uno o m,s atributos 'epl4E!essa(e y un atributo State.
Adicionalmente slo se puede incluir alguno de los siguientes atributos:
Espec>.ic%sEdelE+a9ricante, IdleE$ime%-t: Sessi%nE$ime%-t % Pr%84EState.
"i el servidor determina, al procesar el paquete AccessE'e3-est, que
debe negar el acceso porque alguno de los atributos recibidos no es
aceptable Hpor poltica de sistema, privilegios insu!icientes u otro criterioI,
debe enviar un paquete del tipo AccessE'e<ect. 6ste tipo de paquete
puede incluir uno o m,s atributos 'epl4E!essa(e con el te7to que el NAS
debe mostrar al usuario y uno o m,s atributos Pr%84EState. <o se
permiten otro tipo de atributos. 3os paquetes del tipo AccessE'e<ect
pueden ser enviados en cualquier instancia de una sesin, por lo que son
muy 5tiles para aplicar lmites de tiempo en la duracin de la sesin.
)na vez que se lleva a cabo el proceso de autenticacin puede
empezar el proceso de Acc%-ntin( % *egistro, para esto usa el puerto
/A/-./#P. 6l cliente HNAS % Pr%84 Ser7er5 enva un paquete del tipo
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
=2./01
Acc%-ntin(E'e3-est al Ser7id%r de Acc%-ntin( 'A#I/S. 6ste servidor
puede ser el mismo servidor *A$+)" utilizado para los procesos de
A-tenticaci,n 4 A-t%riCaci,n u otro servidor con!igurado para tal propsito.
6ste paquete de tipo Acc%-ntin(E*equest, den%minad% Acc%-ntin(E
Start: transmite la in!ormacin que se registrar, como utilizacin del
servicio por parte del usuario. Al recibir este paquete el servidor debe
transmitir un paquete del tipo Acc%-ntin(E'esp%nse si puede almacenar
satis!actoriamente el contenido del paquete y no debe transmitir ninguna
respuesta si e7iste alg5n tipo de !alla en el proceso de almacenamiento. A
e7cepcin de los atributos /serEPass@%rd: HAPEPass@%rd: 'epl4E
!essa(e 4 State: se pueden enviar todos los atributos que pueden estar
en un paquete AccessE'e3-est % AccessEAccept. 6l paquete Acc%-ntin(E
'e3-est debe contener el atributo NASEIPEAddress 4"% NASEIdenti.ier. "i
est, presente en el paquete o si estuvo presente en el paquete AccessE
Accept, el atributo +ramedEIPEAddress debe contener la direccin IP
realmente asignada al usuario.
#uando el cliente !inaliza una sesin enva un paquete Acc%-ntin(E
*equest, denominado Acc%-ntin(ESt%p, que incluye las estadsticas de
uso Hduracin de la sesin, volumen de datos trans!eridos, etc.I. 6l
servidor debe con!irmar que pudo almacenar esta in!ormacin con 87ito
enviando un paquete tipo Acc%-ntin(E'esp%nse. 6l cliente debera
reenviar el paquete Acc%-ntin(E'esp%se hasta que el servidor con!irme la
operacin de almacenamiento.
#omo se puede apreciar en los procesos AAA, 'A#I/S transporta
toda la in!ormacin necesaria para llevar a cabo estos procesos en
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
=;./01
Atri9-t%s. 3os atributos se transmiten con el !ormato que se observa en la
+lustracin +++./0 y en la Dabla +++./G.
Ca*3# Descr!3c!+n
$ip%
6ste valor especi!ica el ?n5mero de atributo@ que lo de!ine,
estos n5meros est,n de!inidos en las *&#GA=; y *&#GA==. 6l
n5mero G= est, designado para *end%r Speci.ic Attri9-tes
2*SA5. 3os valores /1GKGG- est,n reservados para uso
e7perimental, los valores GG2KG2E est,n reservados para uso
de cada implementacin espec!ica y los valores G2/KG;; est,n
reservados para uso !uturo.
L%n(it-d
6ste valor indica la longitud del atributo transmitido, incluyendo
los campos tipo, longitud y valor.
*al%r
6ste valor puede ser de longitud cero y puede tener los
siguientes tipos de dato: te8t%: cadena: direcci,n IP: nFmer%
enter% 4 tiemp%.
Tabla III.12.: Descripcin del formato de transmisin de los atributos RADIUS.
6n la descripcin del campo 7al%r se especi!ican cinco tipos de dato
soportados cuyo !ormato es:
$e8t%: de / a G;- 94tes que deben contener caracteres con
codi!icacin /$+EA. 6n lugar de enviarse con longitud cero debe
omitirse el atributo.
adena6 de / a G;- 94tes que deben contener dat%s 9inari%s. 6n
lugar de enviarse con longitud cero debe omitirse el atributo.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
==./01
Ilustracin III.17.: Formato de Transmisin de
Atributo RADIUS.
#irecci,n IP6 valor de -G bits con el 94te m,s signi!icativo en
primer lugar.
NFmer% Enter%6 valor de -G bits sin signo con el 94te m,s
signi!icativo en primer lugar.
$iemp%6 valor de -G bits sin signo con el 94te m,s signi!icativo en
primer lugar. "e debe codi!icar como el n5mero de segundos desde
el E/.E/./10E a las EE:EE:EE )D#.
Muchas de las de!iniciones de atributos establecen un conjunto de
valores posibles por en-meraci,n para dicho atributo, el tipo de dato
utilizado en esos casos es nFmer% enter%.
6l $ip% 21 est, reservado para uso de *end%r Speci.ic Attri9-tes
2*SA: Atributos espec!icos del !abricanteI, y debe usar un !ormato
especial para encapsular las de!iniciones de los atributos *SA dentro del
campo 7al%r.
3os subKcampos son similares a los campos de un atributo normal,
salvo el subKcampo I# +a9ricante. 6ste campo es un cdigo de -G bits
que representa al !abricante y que est, de!inido en el documento
'+1PBB como SNFmer%s Asi(nad%sJ. 6ste cdigo se denomina Net@%r&
!ana(ement Pri7ate Enterprise %de 2N!PE5.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
=0./01
Ilustracin III.18.: Formato de atributos VSA.
ara relacionar los atributos con su cdigo y tipo o para de!inir los
atributos *SA es necesario el uso de #icci%nari%s. 6n ellos se especi!ican
los atributos est,ndar y sus propiedades, as como los atributos *SA
necesarios, como se puede observar en el cuadro de De7to +++.-.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
=A./01
# NOMBRE !R"B#!O !"$O
#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
ATTR#(!TE !ser?Name - str+n&
ATTR#(!TE !ser?4assFor6 2 str+n& en%rypt>-
ATTR#(!TE CGA4?4assFor6 . o%tets
ATTR#(!TE NAS?#4?A66ress 0 +pa66r
ATTR#(!TE NAS?4ort 1 +nte&er
ATTR#(!TE Ser8+%e?Type / +nte&er
.......
H Ser8+%e types
IA"!E Ser8+%e?Type "o&+n?!ser -
IA"!E Ser8+%e?Type Frame6?!ser 2
IA"!E Ser8+%e?Type Call*a%B?"o&+n?!ser .
IA"!E Ser8+%e?Type Call*a%B?Frame6?!ser 0
IA"!E Ser8+%e?Type 3)t*o)n6?!ser 1
IA"!E Ser8+%e?Type A6m+n+strat+8e?!ser /
IA"!E Ser8+%e?Type NAS?4rompt?!ser 7
IA"!E Ser8+%e?Type A)t'ent+%ate?3nly 8
IA"!E Ser8+%e?Type Call*a%B?NAS?4rompt 9
IA"!E Ser8+%e?Type Call?C'e%B -;
IA"!E Ser8+%e?Type Call*a%B?A6m+n+strat+8e --
Texto III.3.: Ejemplo de diccionario RADIUS.
IV. DESARROLLO
1. ,LANTEO DE RESTRICCIONES Y NECESIDADES
3a problem,tica de dise%o de una red inal,mbrica en un ambiente
semi p5blico presenta necesidades y restricciones que no est,n presentes
en otro tipo de implementaciones. recisamente por tratarse de un
ambiente semi p5blico, se plantea la necesidad brindar servicios
di!erentes a grupos de usuarios distintos. or lo menos, surge la
necesidad de di!erenciar dos grandes grupos, un grupo de usuarios como
si !uesen usuarios pri7ad%s % intern%s: y a otro grupo como si !uesen
usuarios de una red p5blica, es decir con ciertas restricciones en el
acceso.
6n general siempre se cumple que, A ma4%r se(-ridad: men%r
.acilidad de -s%. $e esta premisa se puede in!erir que, si los
administradores de red pudieran elegir sin restricci%nes, es evidente que
elegiran el modelo que brindara la mayor seguridad posible en los
accesos de red.
6l problema parte de la e7istencia de restricciones importantes,
principalmente de compatibilidad, en la implementacin de los modelos de
seguridad e7istentes. 6n e!ecto, estas restricciones permiten imaginar un
modelo en el que la p%l>tica de c%ne8i,n requiere de di!erentes niveles de
seguridad en la cone7in inal,mbrica, en !uncin a los permisos de
acceso del per!il cada usuario.
6l planteo de un modelo de in!raestructura para el acceso inal,mbrico
en un ,mbito semiKp5blico presenta, por lo tanto, la necesidad de llegar a
una solucin de compromiso entre la seguridad de los puntos de acceso
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
=1./01
brindados, la compatibilidad de los dispositivos cliente y la necesidad de
brindar di!erentes servicios o niveles de servicio a di!erentes grupos de
usuarios.
"e plantea a continuacin una lista de elementos que componen la
problem,tica general de los accesos semiKp5blicos. #ada uno de los
elementos plantea objetivos a resolver, algunos de ellos contrapuestos:
1. C#*3a'!6!)!dad de) e>!3a*!en'#; 6sta es una !uerte
restriccin a la hora de de!inir la poltica de seguridad de acceso
para los dispositivos inal,mbricos. #omo se vio, el modelo 'SN
que plantea AB2.11i no es compatible con los dispositivos ?EP. >
no puede ser salvado por una actualizacin del !irm4are de los
dispositivos inal,mbricos, porque el soporte de ci!rado est, en el
hard4are y el algoritmo AES es mucho m,s intensivo en el uso de
capacidad de c,lculo que el algoritmo '4. #omo consecuencia,
de!inir una poltica de seguridad 'SN implica desechar los
dispositivos e7istentes, tanto a nivel de in!raestructura de acceso,
como en los dispositivos cliente. 3a decisin de desechar los
dispositivos cliente en un ,mbito semiKp5blico, implica negar
conectividad a una porcin de usuarios. 3a opcin por un modelo
de seguridad basado en $SN, disminuye signi!icativamente la
porcin de usuarios a los que se le negara conectividad
inal,mbrica, pero todava no contempla todo el universo posible de
dispositivos. Adem,s de tener en cuenta la compatibilidad del
equipamiento a nivel de seguridad, en un segundo plano, hay que
tener en cuenta la compatibilidad del equipamiento en cuanto a
modo de transmisin, AB2.11 a: 9: % g. 6l est,ndar AB2.11( es
compatible con AB2.119, y alcanza mayores velocidades de
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
0E./01
transmisin, por lo que es recomendable para las
implementaciones nuevas. Muchos de los dispositivos P#A tienen
capacidad slo para transmitir en AB2.119: lo que re!uerza la
eleccin de AB2.11( como est,ndar para la in!raestructura.
$. C#*3a'!6!)!dad de )#s s!s'e*as #3era'!2#s; <o todos
los sistemas operativos soportan 'SN % $SN, a5n si el hard4are
del cliente lo soporta. or ejemplo, en la !amilia de sistemas
operativos Microso!t Oindo4s el soporte nativo se puede ver en la
Dabla +(./:
S!s'e*a O3era'!2# S#3#r'e Na'!2# de WPA S#3#r'e Na'!2# de WPA2
!S ?ind%@s *ista
" "
!S ?ind%@s GP
#on "ervice acP G o
"ervice acP / y Oireless
)pdate *ollup acPage !or
Oindo4s M
#on "ervice acP G y
Oireless #lient )pdate !or
Oindo4s M 4ith "ervice
acP G
!S ?ind%@s 2BBB
<oU
/
<oU
/
!S ?ind%@s !e
<oU <oU
!S ?ind%@s NA
<oU <oU
!S ?ind%@s N$ 4.B
<oU <oU
!S ?ind%@s Ser7er
L%n(h%rn
" "
!S ?ind%@s Ser7er 2BB3
#on "ervice acP / o
"ervice acP G
#on "ervice acP G
Tabla IV.1.: Soporte Nativo de WPA y WPA2 de los Sistemas Operativos Microsoft
* el fabricante del dispositivo puede proveer software para dar soporte a WPA o WPA2.
1
Slo
provee soporte para 802.1X (fuente:
http://www.microsoft.com/technet/network/wifi/wififaq.mspx#EGAAE Actualizado a Abril 2007.)
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
0/./01
$e este limitado ejemplo, que no contempla dispositivos $A u
otros sistemas operativos H3inu7, Q"M, etc.I, se desprende que al
de!inir una poltica de seguridad, las restricciones no slo son por
el hard4are de los dispositivos inal,mbricos. #omo consecuencia,
el de!inir una poltica de seguridad rgida basada en AB2.11i implica
negar conectividad a una porcin de usuarios o brindar una
alternativa adicional de conectividad !uera de los modelos 'SN %
$SN.
1. ,er*!s#s 3ara Usar!#s ? ,er7!)es de Usar!#s; 3a
implementacin de validacin de usuarios y la asignacin de
permisos a los mismos sobre lo que pueden hacer o no, una vez
conectados a la red, presenta una gran complejidad. 6n necesario
de!inir varios requisitos para que este objetivo sea completado:
1. 67istencia de un listado o base de datos de
usuarios que contenga los requisitos necesarios para a-tenticar
a los usuarios y para almacenar sus vinculaciones con los
permisos del grupo al que pertenecen, adem,s de permisos
espec!icos del usuario. $icha base de datos deber, ser
c%mpati9le con los m8todos de acceso seleccionados para
autenticar a los usuarios y con los sistemas operativos de los
nodos cliente.
$. $e!inicin de un protocolo com5n a todos los
m8todos de acceso y sistemas operativos que permita realizar
las tareas de AAA necesarias para validar el acceso a los
recursos por parte de los usuarios de la red, accediendo a la
base de datos de usuarios y permisos. 6ste protocolo debe
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
0G./01
actuar de ne7o entre los mecanismos de autenticacin de los
nodos cliente y la base de datos.
-. $e!inicin de la !orma en que se implementar,n las
restricciones que su!rir,n los usuarios una vez que est8n
autenticados y conectados a la red inal,mbrica. 6stas
restricciones deber,n ejecutarse en el punto de cone7in con la
red interna, y no en los nodos clientes de la red, a !in de
presentar un 5nico punto de control y de evitar el costo de
desarrollar una implementacin para cada combinacin de
hard4are.sistema operativo.
2. $e!inicin de la !orma en que se generar,n los
registros de las operaciones que llevan a cabo los usuarios. 3a
e7istencia de estos registros permitir, auditar tanto las
operaciones llevadas a cabo por los usuarios, como los
patrones de tr,!ico generado por los mismos y validar que el
comportamiento de la red inal,mbrica es el deseado.
2. @erra*!en'as de Ad*!n!s'rac!+n de Usar!#s ?
,er7!)es; 6s necesario brindar herramientas amigables que
permitan una !,cil administracin tanto de los permisos de los
per!iles de usuario, como de los usuarios. $e !orma que el
crecimiento en el n5mero de usuarios o per!iles de usuario, no
represente un problema para los administradores de la red.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
0-./01
$. MODELO Y ENTIDADES AAA
6l modelo de in!raestructura que se plantea en este trabajo brinda un
camino de solucin a cada uno de los problemas planteados. "e puede
observar el modelo que se propone en el diagrama de bloques de la
+lustracin +(./. #ada bloque representa una !uncin espec!ica que debe
ser cubierta por la implementacin.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
02./01
Ilustracin IV.1.: Modelo funcional propuesto.
"e puede visualizar un esquema general de la topologa !sica del
modelo planteado en la +lustracin +(.G. 6n la ilustracin se puede
apreciar el tratamiento de la red inal,mbrica como una red hostil,
separada de la red interna o privada de la organizacin a trav8s de un
.ire@all.
3a red semi p5blica est, compuesta por dos redes di!erentes, una es
la red inal;m9rica pr%piamente dicha, y la otra es la red de distri9-ci,n de
ser7ici%s inal;m9ric%s, esta 5ltima es una red generalmente cableada que
interconecta todos los dispositivos que brindan servicios a la red
inal,mbrica. #omo medio de transmisin de esta 5ltima red se puede
utilizar un cableado dedicado, una *LAN espec!ica dentro de la red
cableada privada o ?#S
1
.
1 Wireless Distribution System , Sistema de Distribucin Inalmbrica.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
0;./01
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
0=./01
Ilustracin IV.2.: Modelo de Infraestructura general propuesto.
#omo puede verse en la +lustracin +(.G, todo el tr,!ico de la red
inal,mbrica con!luye en el ser7id%r de a-tenticaci,n. $icho servidor
!unciona como un punto de control por el que obligatoriamente debe pasar
todo el tr,!ico de la red inal,mbrica. 6s por ello que este punto es donde
se realizan los controles de los permisos que poseen los usuarios dentro
de su per!il de conectividad, y adem,s se realiza el r%-tin( de los
paquetes.
3a red de distribucin, desde el punto de vista del usuario inal,mbrico,
es totalmente transparente, ya que slo ?ve@ el AP que le brinda acceso al
ESS. 3os dispositivos que con!orman la in!raestructura de esta red tienen
un direccionamiento IP totalmente di!erente al de las redes privadas e
inal,mbrica.
6n la ilustracin tambi8n !iguran dispositivos denominados AP Lin-8,
estos dispositivos son computadores con sistema operativo Lin-8, y dos
inter!aces de red, una inter!az ethernet ca9leada 4 -na inter.aC
inal;m9rica AB2.11 a"9"( .
A !in de poder presentar de !orma ordenada cada una de las !unciones
que cumplen los dispositivos que componen este modelo, se procede a
analizar cada uno de los bloques !uncionales por separado, haciendo
re!erencia a su aporte !uncional a la solucin completa.
6n la +lustracin +(.- se puede apreciar el sistema de distri9-ci,n
inal;m9ric%, con los bloques !uncionales ampliados que muestran las
!uncionalidades de cada componente de in!raestructura.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
00./01
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
0A./01
Ilustracin IV.3.: Bloques Funcionales Implementados del Modelo de Infraestructura.
1. BLO-UES FUNCIONALES
6l modelo de in!raestructura se puede dividir en tres grandes bloques
de in!raestructura. $os de estos son el Ser7id%r de A-tenticaci,n y los
AP. 6stos bloques son atravesados transversalmente por los !Ht%d%s de
Acces%: que de!inen el comportamiento de estos bloques !uncionales. 3a
implementacin de los bloques de este modelo se llev a cabo con
sistema operativo '<) 3inu7, distribucin $ebian -./ "arge
/
.
1. MATODOS DE ACCESO
3os !Ht%d%s de Acces%, de!inen la !orma en que se conectar,n los
nodos cliente, y por lo tanto los requerimientos tanto en el hard4are como
en el sistema operativo de los mismos. Dodos los m8todos de acceso
propuestos permiten realizar el proceso de autenticacin por usuario, para
asignar los permisos de conectividad por usuario o por per!iles de usuario.
"i bien pueden implementarse slo algunos de los !Ht%d%s de Acces%
que se va a describir, la !ortaleza del modelo radica en soportar varios
!Ht%d%s de Acces% de !orma simult,nea. 6sto tiende a poder brindar al
menos una !orma de conectarse a los nodos cliente, independientemente
de las capacidades de cone7in de los mismos, salvando de este modo
las incompatibilidades e7istentes, e7presadas al principio de este captulo.
1. MATODO ,,,OE
6ste m8todo permite, como es tradicional para la !amilia de protocolos
, la autenticacin por usuario. *equiere que en el Ser7id%r de
A-tenticaci,n se ejecute un servidor o6 y en el AP Lin-8 se ejecute
1 http://www.debian.org.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
01./01
un servicio de 'ela4 de PPP%E, que se encarga de reenviar las tramas
o6 que se reciban a trav8s de la inter!az inal,mbrica al servidor de
o6 que se ejecuta en el Ser7id%r de A-tenticaci,n.
3a eleccin de este m8todo se debe a la gran popularidad alcanzada
por o6, debido principalmente a la utilizacin por parte de los
roveedores de "ervicios de +nternet como m8todo para brindar acceso
por usuario. #omo consecuencia, e7isten clientes o6 para la mayora
de las plata!ormas, incluidas las P#A. +nclusive e7iste un borrador de la
+6D& denominado ?/sin( PPPE%7erEEthernet 2PPP%E5 in ?ireless LANs@
C$*A&DK'AD6*<QF, que sugiere la implementacin de o6 para
realizar accesos a redes inal,mbricas.
Algunas de las ventajas brinda PPP%E son9
A trav8s de los pl-(ins de radi-s.s% 4 radattr.s%, el
servidor PPP%E puede autenticar a los usuarios contra un Ser7id%r
'A#I/S, y con!igurar la sesin con los par,metros que enve dicho
servidor.
PPP%E aporta el concepto de sesi,n s%9re Ethernet: por
lo que se puede realizar un seguimiento de los tiempos de
cone7in de un usuario en particular, que son registrados en el
Ser7id%r 'A#I/S.
$ado que las sesiones PPP%E son slo sesiones PPP
encapsuladas sobre Ethernet: el servidor se ocupa de asignar la
direccin IP al nodo cliente, por lo que no se requiere la utilizacin
de un servidor #HP separado. or otro lado, esta asignacin de
direccin puede controlarse a trav8s de los par,metros de
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
AE./01
con!iguracin, siendo posible asignar un p%%l de direcciones
din,micas, o asignando una direccin espec!ica para cada
usuario, a trav8s de los par,metros que enva el Ser7id%r 'A#I/S.
6l protocolo PPP%E, al ser un protocolo de capa de
enlace, puede encapsular protocolos distintos al protocolo IP.
6l servidor PPP%E, soporta la autenticacin de usuarios a trav8s de:
A Hass4ord Autentication rotocolI
#JA H#hallenge JandshaPe Authentication rotocolI
M"K#JA H#hallenge JandshaPe Authentication rotocolI
M"K#JA (G H#hallenge JandshaPe Authentication rotocol (ersion GI
"e elige realizar la autenticacin de los usuarios a trav8s de M"K
#JAK(G, debido a que es la opcin m,s segura de las soportadas. "i
bien PPP#, soporta un desa!o EAPE!#0 como m8todo de autenticacin,
la implementacin actual no permite usar el mismo con un servidor
'A#I/S, slo permite utilizar el desa!o contenido en un archivo local por
lo que se descarta su utilizacin en este modelo.
"i bien el protocolo soporta ci!rado !PPE
1
[!PPE] para el !lujo de
datos, la implementacin del servidor sobre sistema operativo KN/"3inu7
presenta !allas al utilizarlo con clientes con sistema operativo !SE
?ind%@s. 3as pruebas realizadas se pueden encontrar en el Ap8ndice &.
1 Microsoft Point-to-Point Encryption Protocol
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
A/./01
6s por ello que, a pesar de que este m8todo de acceso permite la
utilizacin de varios tipos de nodo cliente y est, dotado de una relativa
seguridad en el momento de la autenticacin al utilizar !SEHAPE*2:
posee una gran desventaja al no poder ci!rar el tr,!ico entre el nodo y el
servidor de autenticacin, por ello no se recomienda su uso en
estaciones que realicen operaciones de administracin en la red.
6ste m8todo se implementa a trav8s de dos componentes, en el
Ser7id%r de A-tenticaci,n se ejecuta el servidor PPP%E, y en los AP
Lin-8, se ejecuta el 'ela4 de PPP%E. 3os nodos cliente que acceden por
este m8todo deben con!igurarse con un cliente de PPP%E.
$. 5,ABRSN C @OSTA,D
6ste m8todo puede implementarse tanto con un AP Lin-8 como con
AP convencionales que soporten ?PA"?PA2KEnterprise. *equiere de un
servidor *A$+)", para realizar las tareas de AAA, y de un servidor
#HP para entregar las direcciones IP a los nodos cliente.
Danto en los AP convencionales, como en los AP 3inu7, el AP cumple
con los roles de AP y de A-tenticad%r: a trav8s del uso del protocolo
IEEEAB2.1G. 6n los AP Lin-8, el A-tenticad%r, est, implementado con el
so!t4are libre h%stapdEB.0.0
1
. $icha implementacin de so!t4are soporta
la autenticacin IEEEAB2.1G a trav8s de la suite de protocolos EAP: 4
soporta las siguientes variantes del protocolo:
6AKD3"
6AKDD3" H6AKM$;, 6AK'D#, 6AKM"#JA(G,
M"#JAvG, M"#JA, A, #JAI.
6AK6A HM"#JAvG, 'D#, M$;I
1 http://hostap.epitest.fi/hostapd/
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
AG./01
6"K"+M
6AKANA
6AKAM
6AK"N
6AK"AN6
6AK&A"D
6AKM$;
6AKM"#JAvG
6AK'D#
$ebido a la gran cantidad de m8todos que proporciona el protocolo
EAP, al elegir los m8todos que se usaran, se tuvo en cuenta los
siguientes puntos:
<ivel de seguridad proporcionada.
#ompatibilidad con los dispositivos cliente.
(iabilidad de implementacin H"oporte en Ser7id%r de
A-tenticaci,n y AP c%n7enci%nalesI
&acilidad de administracin.
or estas razones, la eleccin recay en dos implementaciones EAPE
$$LS 4 EAPEPEAP. 6stos m8todos proporcionan un nivel de seguridad
aceptable, son ampliamente soportados en los clientes, tanto nativamente
en los sistemas operativos, como a trav8s de implementaciones de
so!t4are libre9 y son soportados en los AP convencionales. "i bien
tambi8n es !actible y puede ser deseable usar EAPE$LS: el mismo
requiere una compleja administracin de In.raestr-ct-ra de la7es
PF9licas HPDI5. 6n e!ecto, requiere la emisin de certi!icados para cada
cliente, no slo para el servidor, de !orma de que los clientes validen la
red a la que se conectan y el servidor valide los cliente que se conectan a
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
A-./01
a la red. 6s por ello que se deja la decisin de utilizarlo a los
administradores de red que implementen este modelo.
6ste !Ht%d% de Acces% aparte de la in!raestructura para autenticar a
los usuarios y ci!rar la transmisin de datos, requiere de ciertos
componentes adicionales, como mnimo un servidor #HP: para
establecer la conectividad de los clientes. "i bien se puede recurrir a la
utilizacin de un servidor $J# est,ndar implementado en so!t4are libre
o de un servidor $J# embebido en los AP convencionales, en este
modelo se recurre a la integracin con una implementacin espec!ica de
un P%rtal a-ti7% debido a ciertas ventajas que se plantean en la seccin
siguiente.
1. ,ORTAL CAUTIVO .CAPTIVE PORTAL/
)n P%rtal a-ti7% es una t8cnica que !uerza a un cliente H$$P
/
a ver
una p,gina 4eb en especial, que usualmente se usa para autenticar al
cliente. )na vez que el cliente se ha autenticado, puede usar el servicio
de !orma normal.
6ste comportamiento se logra interceptando todos los paquetes,
independientemente del destino de los mismos Hdireccin +, puerto
D#.)$I, negando de esta !orma conectividad al cliente. )na vez que el
cliente abre el navegador, se redirige el mismo a una p,gina 4eb que
puede presentar di!erentes mensajes, desde una p,gina que pide la
aceptacin de las polticas de uso, hasta una p,gina que requiera la
autenticacin o el pago para usar el servicio.
1 Hyper Text Transfer Protocol (HTTP), es un protocolo de comunicaciones usado para
transferir informacin en la World Wide Web.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
A2./01
3a utilizacin de un P%rtal a-ti7% permite la identi!icacin del usuario
y posibilita el brindar conectividad a un rango amplio de dispositivos que
pueden ejecutar un navegador9 sin embargo, no son capaces de
conectarse va ?PA % ?PA2.
ara este m8todo se eligi la implementacin de hillisp%tE71.1
1
. 6ste
so!t4are libre presenta las siguientes caractersticas:
ermite la autenticacin a trav8s de un Ser7id%r 'A#I/S,
usando dos m8todos, /A! 2/ni7ersal Access !eth%d5 que
es el m8todo tradicional de los P%rtales a-ti7%s: y permite
el uso de ?PA a trav8s del AP.
ermite el uso de los atri9-t%s 'A#I/S ?ISPr de!inidos por
la ?i+i Alliance.
osee servicio de #HP.
uede actuar como Pr%84E'A#I/S para otros m8todos de
autenticacin y, si se combina con el m8todo ?PAE
HOS$AP#, permite al servidor #HP entregar una direccin
+ prede!inida para un cliente en los atri9-t%s 'A#I/S.
osee soporte de atributos *A$+)" espec!icos que
permiten control de Ancho de Banda y la de!inicin de una
cantidad m,7ima de tr,!ico utilizable por cada cliente.
<o posee requerimientos a nivel de AP: salvo el soporte de
?PA % ?PA2: si desea usarse.
1 http://www.chillispot.org/
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
A;./01
uede utilizarse para autenticar usuarios en redes
cableadas.
3a implementacin de este m8todo se realiza en el Ser7id%r de
A-tenticaci,n de la red inal,mbrica y adicionalmente slo requiere de un
servidor 4eb con soporte de H$$PS
1
para realizar la autenticacin de
usuarios al Ser7id%r 'A#I/S.
hillisp%t tiene dos componentes principales,
una aplicacin de en espacio de usuario denominada chilli que es
el P%rtal a-ti7% en s mismo, y cumple las !unciones de Ser7id%r
#HP: liente 'A#I/S: Pr%84E'A#I/S: 4 'edirect%r9
un archivo KI
2
en el servidor 4eb, denominado h%tsp%tl%(in.c(i:
el cual es un script, programado en perl: que se encarga de enviar
los datos de autenticacin a chilli. 6ste script, genera un desa.>%E
HAP para validar el usuario y la clave de acceso, que ha recibido
del cliente, a trav8s del servidor 4eb ci!rado con JDD", y enva el
mismo a chilli.
3as !unciones que cumple dentro del modelo propuesto esta
aplicacin, est,n ligadas a dos de los m8todos de autenticacin, P%rtal
a-ti7% 4 ?PA"'SNEH%stapd. 6sto se debe principalmente a las
caractersticas que que posee ya que adem,s de P%rtal a-ti7% cumple
las siguientes !unciones:
1 Hyper Text Transfer Protocol Secure, Protocolo de Transferencia de Hyper Texto Seguro,
usado para transportar el servicio usualmente denominado WEB Segura, cifra el trfico a
travs de SSL Secure Socket Layer.
2 Common Gateway Interface, Interface de Gateway Comn, uno de las primeras formas de
ejecutar un script en un servidor web.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
A=./01
Pr%84E'A#I/S para el mHt%d% ?PA"'SNEH%stapd que, al
interceptar los paquetes *A$+)", puede modi!icar el
comportamiento de algunos servicios que c-mple hillisp%t.
Ser7id%r #HP para el mHt%d% ?PA"'SNEH%stapd: con entrega
din,mica y !ija a trav8s de un atri9-t% 'A#I/S.
Kenerad%r de 'e(istr% 2Acc%-ntin(5. "i bien H%stapd puede
generar la in!ormacin de registro que debe enviarse al servidor
*A$+)", hillisp%t lo hace autom,ticamente tanto para clientes
del P%rtal a-ti7% como para clientes ?PA"'SN.
%ntr%lad%r de Anch% de )anda a trav8s de atri9-t%s 'A#I/S:
tanto para clientes del P%rtal a-ti7% como para clientes
?PA"'SN.
%ntr%lad%r de antidad de $r;.ic% a trav8s de atri9-t%s 'A#I/S.:
tanto para clientes del P%rtal a-ti7% como para clientes
?PA"'SN.
$. DIRECCIONAMIENTO GENERAL DE RED
1
)no de los puntos a de!inir, dentro de la implementacin del modelo de
in!raestructura, es el direccionamiento + de la red inal,mbrica.
"i bien este tema puede adaptarse a las necesidades particulares de
una implementacin, se propone lo siguiente:
1 Esta breve seccin tiene por objeto presentar un ejemplo del direccionamiento de red, por
motivos didcticos, a fin de mejorar la compresin de las secciones subsiguientes.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
A0./01
$e!inir un direccionamiento de red distinto al
direccionamiento de la red privada para la red inal,mbrica. 6sto
permite mantener separados los mecanismos de asignacin de
direcciones + entre las dos redes y por lo tanto mantener la
independencia casi completa entre las redes.
Mantener en el (ate@a4 de la red privada visibilidad
completa de capa de red de los paquetes que atraviesan dicho
(ate@a4. 6sto signi!ica que el gate4ay de la red inal,mbrica
enruta los paquetes a su destino sin modi!icarlos, es decir sin
realizar NA$
1
. #omo consecuencia de esto, en el (ate@a4 a
Internet de la red privada se puede !iltrar el tr,!ico, controlar ancho
de banda, etc. 6sto requiere modi!icar las tablas de r%-tin( del
(ate@a4 de la red privada para e7tender el alcance a la red
inal,mbrica.
$e!inir un direccionamiento + totalmente di!erente para
los dispositivos que componen la red de distribucin. 6sta
separacin tiene sentido dado que dicha red es una red con
.-nci%nes administrati7as. <o debe debera tener alcance desde la
red inal,mbrica ni desde la red privada, salvo para los
administradores de red.
$ividir el direccionamiento + de la red inal,mbrica en
dos partes, una para asignacin de direcciones + din,micas y otra
para asignacin de direcciones + est,ticas por usuario a trav8s del
atributo +ramedEIPEAddress de 'A#I/S.
1 Network Address Translation, Traduccin de direcciones de red.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
AA./01
#omo resultado en el prototipo se propondr, el siguiente
direccionamiento +:
Redes D!recc!#na*!en'# I,
'ed Administrati7a
Sistema de #istri9-ci,n
1&.1&.1&.&B$4
'ed Inal;m9rica
1D$.1<%.1=<.&B$1
$irecciones
Asignadas por
)suario
$irecciones Asignadas
$in,micamente
/1G./=A./0=.E.GG
/1G./=A./AE.E.GG
P%%l PPP%E
ool ortal
#autivo
/1G./=A./AE.E.G- /1G./=A./AG.E.G-
Tabla IV.2.: Esquema de direccionamiento IP propuesto para prototipo.
1. SERVIDOR DE AUTENTICACIN
6ste es el componente principal del modelo propuesto, ya que
independientemente de los m8todos de acceso que se implementen, se
encarga de aplicar los permisos de conectividad a los usuarios.
1. SERVIDOR LDA,
6l Ser7id%r L#AP ser, el soporte de almacenamiento de la base de
datos de usuarios, permisos de!inidos por poltica de acceso y atributos o
datos del ser7id%r 'A#I/S. 6n este prototipo se utiliz la implementacin
de so!t4are libre OpenL#APE72.3.20
1
. 6n el ,rbol L#AP no se
almacenar,n los datos de 'e(istr% % Acc%-ntin( del Ser7id%r 'A#I/S,
debido a que representan un gran volumen de datos a almacenar, por lo
que estos datos se almacenar,n en otro soporte.
1 http://www.openldap.org
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
A1./01
3a eleccin de almacenar todos los datos en un ,rbol L#AP, permite
que todos los datos necesarios para la operacin de este modelo est8n
autoKcontenidos e inclusive puedan utilizarse para validar a los mismos
usuarios en otras aplicaciones.
6s por ello que en este prototipo se han implementado los es3-emas
necesarios para que tambi8n un servidor de correo HTmailEL#AP
1
I pueda
obtener los datos necesarios para operar, demostrando que se puede
simpli!icar tanto la administracin de la base de datos de usuarios, como
la operacin para los usuarios, que deber,n recordar slo un nombre de
usuario y una clave, para operar en varios ,mbitos di!erentes.
3os esquemas implementados son los siguientes, como se puede ver
en el archivo de con!iguracin "etc"ldap"slapd.c%n.6
Junto a los es3-emas 9;sic%s: necesarios para el !uncionamiento, se
pueden observar tres es3-emas de -s% espec>.ic%6
1 http://www.qmail.org
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
1E./01
......
# &c'e(a a)* object+lass *e,i)itio)s
i)clu*e -etc-l*ap-sc'e(a-core.sc'e(a
i)clu*e -etc-l*ap-sc'e(a-cosi)e.sc'e(a
i)clu*e -etc-l*ap-sc'e(a-)is.sc'e(a
i)clu*e -etc-l*ap-sc'e(a-i)etor.perso).sc'e(a
i)clu*e -etc-l*ap-sc'e(a-sa(ba.sc'e(a
i)clu*e -etc-l*ap-sc'e(a-ra*ius.sc'e(a
i)clu*e -etc-l*ap-sc'e(a-/(ail.sc'e(a
.......
Texto IV.1.: Esquemas utilizados en Servidor LDAP
Sam9a.schema6 rovee del atributo Sam9aN$Pass@%rd
necesario para poder realizar la autenticacin va !SHAP72.
'adi-s.schema6 rovee de los atributos donde se
almacenar,n todos los datos necesarios para que !uncione el
Ser7id%r 'A#I/S. 6ste esquema se provee a trav8s del paquete
.reeradi-sE1.1.3E3.
Tmail.schema 2Opci%nal56 rovee los atributos
necesarios para el !uncionamiento de un servidor de correo
electrnico TmailEL#AP. "lo se muestra como ejemplo.
ara contener los datos necesarios para el !uncionamiento del modelo,
es necesario crear la unidad organizativa Pr%.iles 2%-Qpr%.iles5, donde se
almacenar,n los objetos que representan un per!il de conectividad. #ada
uno de los objetos dentro de la %-Qpr%.iles: representa la aplicacin de
una p%l>tica de c%necti7idad espec!ica para un grupo de usuarios.
3os objetos que representan un per!il de usuario pertenecen a las
siguientes clases:
Rad!sO68ec',r#7!)e
Q+$: /.-.=./.2./.--/0.2.-.G.G
Dipo: 6structural
$escripcin: 6s una clase de objeto contenedor que se utiliza
para crear objetos radiuspro!ile.
rad!s3r#7!)e
Q+$: /.-.=./.2./.--/0.2.-.G./
Dipo: Au7iliar.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
1/./01
$escripcin: 6s una clase de objeto que posee los atributos
necesarios para de!inir un per!il est,ndar de 'A#I/S.
'#3
Q+$: G.;.=.E
Dipo: Abstracto
6stos objetos poseen los atributos para almacenar un per!il 'A#I/S
b,sico.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
1G./01
Ilustracin IV.4.: rbol LDAP Parcial, Unidad
Organizativa Profiles.
ara almacenar los datos re!erentes a los permisos de cada per!il de
usuarios se sobrecarg el atributo #escripti%n 2OI#6 2.0.4.13I. 6ste
atributo soporta valores m5ltiples y soporta una longitud m,7ima de /EG2
caracteres. 3os valores de los permisos se almacenan en !orma de reglas,
de!iniendo una regla para cada valor del atributo. $ichas reglas deben
usar el !ormato de la sinta7is del comando ipta9les de net.ilter
1
.
3os nombres de los per!iles de usuarios tienen la !orma nnE
n%mp%l>tica, dnde nn es un n5mero que de!inir, el orden de aplicacin
del conjunto de reglas y n%mp%l>tica hace re!erencia al nombre del grupo
1 http://www.netfilter.org
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
1-./01
........
*)0 ui*100%a*(i)s2ou1pro,iles2*c1u(2*c1e*u
object+lass0 ra*iusObject$ro,ile
object+lass0 ra*iuspro,ile
object+lass0 top
ra*ius3ra(e*M!#0 1460
ra*ius3ra(e*$rotocol0 $$$
ra*ius&er4ice!ype0 5o.i)
*ialupccess0 yes
ra*ius3ilter"*0 60
ui*0 00%a*(i)s
c)0 00%a*(i)s
description: -N marca-admins -t mangle
description: -A marca-admins -t mangle -j MARK --set-mark 50
description: -A PREROUTN! -t mangle -s "#$%"&'%"(&%0)$& -m mark --mark
0 -j marca-admins
description: -N *iltra-admins
description: -A +OR,AR- -m mark --mark 50 -j *iltra-admins
description: -A *iltra-admins -j A..EPT
Texto IV.2.: Ejemplo de definicin de Perfil de Usuario
de usuarios al que se le aplicar,n las politicas de acceso. 6l signi!icado de
los atributos 'A#I/S, se ver, en la seccin Ser7id%r 'A#I/S.
6n el cuadro de De7to +(.G se puede observar un ejemplo de la
de!inicin de uno de los Per.iles de /s-ari%: en donde se ve un ejemplo
claro de la sobrecarga del atributo #escripti%n.
3a vinculacin de un usuario con un per!il de usuario se realiza a
trav8s del atributo 'adi-sPr%.ile#n en el objeto del usuario, que debe
contener el dn del per.il de -s-ari%.
3os usuarios deben poseer el atributo sam9aN$Pass@%rd para poder
autenticarse a trav8s de !SHAP72, que es utilizado por el m8todo de
acceso PPP%E.
6l atri9-t% dial-pAccess es un atributo especial espec!icamente
de!inido en la clase radiuspro!ile para usarse con soporte 3$A. <o e7iste
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
12./01
*)0 c)1test user22ou1u(.e*u.ar2*c1u(2*c1e*u
c)0 test user2
ui*0 test.user2
sa(ba&"70 22308883
user$ass9or*00 e0N&:;B#,;*<e!R!e#8=R2ptR1E1
radi/sPro*ile-n: /id00"-pro*esores1o/0pro*iles1dc0/m1dc0ed/
*ialupccess0 yes
object+lass0 perso)
object+lass0 ra*iuspro,ile
object+lass0 sa(ba&a(ccou)t
object+lass0 top
ra*ius&er4ice!ype0 3ra(e*%#ser
sa(baN!$ass9or*0 0+B68488063787B3282807873B88637
Texto IV.3.: Ejemplo de vinculacin del Perfil de Usuario a un usuario.
como atributo *A$+)" cuando se utiliza otro soporte de almacenamiento.
3a e7istencia de este atributo en un usuario con valor 4es
1
, signi!ica que
dicho usuario tiene autorizacin para conectarse. 6n caso de que el
mismo no e7ista, o e7ista y posea el valor +ALSE, el servidor *A$+)" no
contin5a con el proceso de autenticacin y se deniega el acceso remoto.
$. SERVIDOR RADIUS
3a operacin de este servidor se lleva a cabo a trav8s de +reeradi-sE
1.1.3E3
2
el cual es la implementacin de un servidor 'A#I/S en so!t4are
libre, que posee un amplio soporte del protocolo 'A#I/S y que permite
usar di!erentes soportes de almacenamiento, entre ellos L#AP 4 !4STL.
A !in de usar como soporte de almacenamiento el direct%ri% L#AP:
.reeradi-s provee un esquema para L#AP 7ersi,n 3 denominado
%penldap.schema y un mdulo denominado rlmVldap que se encarga de
realizar las tareas de a-t%riCaci,n 4 a-tenticaci,n contra el directorio
L#AP.
3os atributos del diccionario 'A#I/S son e7tensibles a trav8s de los
dicci%nari%s de atri9-t%s de l%s .a9ricantes y los atributos de!inidos en el
esquema L#AP provisto por .reeradi-s contempla slo los atributos
est,ndar del protocolo. or estas razones, .reeradi-s proporciona una
manera de almacenar los valores de diccionarios adicionales en un ,rbol
L#AP: a trav8s del archivo "etc".reeradi-s"ldap.attrmap.
6ste archivo es un ?mapa@ de las correspondencias entre los atributos
del diccionario 'A#I/S y los atributos del directorio L#AP: permitiendo de
1 En base a pruebas realizadas, si el atributo posee cualquier valor, excepto FALSE, el usuario
puede autenticarse correctamente.
2 http://www.freeradius.org/.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
1;./01
esta !orma ?rede!inir@ el signi!icado de algunos atributos del directorio
L#AP.
)n ejemplo del uso de esta caracterstica se puede ver en el cuadro
de De7to +(.2. 6n 8l aparece un ejemplo de algunos atributos rede!inidos,
que son necesarios para la implementacin de este modelo, junto con las
de!iniciones est,ndar para el esquema provisto p%r .reeradi-s. 6l archivo
ldap.attrmap, es usado por el mdulo rlmVldap.
3a con!iguracin del servidor se encuentra en el direct%ri%
"etc".reeradi-s, y consta de di!erentes archivos de con!iguracin. 3as
directivas principales de con!iguracin se encuentran en el archivo
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
1=./01
......
"!EM%!>$E R7"#&%ttribute%Na(e 57$%ttribute%Na(e
......
reply"te( $ort%5i(it ra*ius$ort5i(it
reply"te( 5o.i)%5!%$ort ra*ius5o.i)5!$ort
reply"te( Reply%Messa.e ra*iusReplyMessa.e
#tributos Re*e,i)i*os
# para :$ ?No estaba) *e,i)i*os e) el l*ap.attr(ap@
repl2tem T/nnel-T2pe radi/sT/nnelT2pe
repl2tem T/nnel-Medi/m-T2pe radi/sT/nnelMedi/mT2pe
repl2tem T/nnel-Pri3ate-!ro/p-d radi/sT/nnelPri3ate!ro/pd
# para +'illispot y :$ ?7e,i)i*os sobre atributos /ue )o se #
usa) e) esta i(ple(e)tacio) e) particular@.
# ")ter4alo *e tie(po *e *e accou)ti). e) se.u)*os
repl2tem Acct-nterim-nter3al radi/sArap+eat/res
#tributos *e :"&$r 7ictio)ary para co)trol *e )c'o *e Ba)*a
repl2tem ,4Pr-5and6idt7-Ma8-Up radi/sArap4ec/rit2
repl2tem ,4Pr-5and6idt7-Ma8--o6n radi/sArap9oneAccess
Texto IV.4.: Atributos LDAP redefinidos para uso con RADIUS.
"etc".reeradi-s"radi-sd.c%n.. 3a estructura general de este archivo se
puede en ver en el cuadro de De7to +(.;.
6n la seccin m%d-les se de!inen cada uno de los mdulos que se
utilizar,n indistintamente para realizar las tareas de AAA. 3as secciones
a-th%riCe: a-thenticate 4 acc%-ntin(, se completan con el nombre de los
mdulos que se utilizar,n para realizar esa tarea en particular y que se
han de!inido previamente .
ara que el servidor pueda realizar las tareas de AAA con los m8todos
de acceso que !orman parte del modelo de in!raestructura propuesto, es
necesario con!igurar los siguientes mdulos:
3$A
M"#JA
A
6A HD3", DD3" y 6AI
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
10./01
AOpcio)es Blobales *e +o),i.uraciC)D
(o*ules E ...
F
aut'ori=e E ...
F
aut'e)ticate E ...
F
accou)ti). E ...
F
Texto IV.5.: Estructura General del archivo /etc/freeradius/radiusd.conf.
3a con!iguracin del mdulo L#AP es la que permite realizar la
autenticacin contra el directorio 3$A. "e puede observar la
con!iguracin de este mdulo en el cuadro de De7to +(.=:
6n la con!iguracin de este mdulo se especi!ican las siguientes
directivas de con!iguracin:
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
1A./01
.....
l6ap J
ser8er > Klo%al'ostK
+6ent+ty > K%n>a6m+n@6%>)m@6%>e6)K
passFor6 > 340'8C982p-7;
*ase6n > Ko)>)m.e6).ar@6%>)m@6%>e6)K
f+lter > K()+6>LJStr+ppe6?!ser?Name:?LJ!ser?NameMM2K
*aseNf+lter > K(o*9e%t%lass>ra6+)sprof+le2K
startNtls > no
prof+leNattr+*)te > Kra6+)s4rof+leDnK
a%%essNattr > K6+al)pA%%essK
6+%t+onaryNmapp+n& > 7Jra66*6+rMDl6ap.attrmap
l6apN%onne%t+onsNn)m*er > -;
passFor6N'ea6er > KJCR$4TMK
passFor6Nattr+*)te > )ser4assFor6
t+meo)t > 0
t+mel+m+t > .
netNt+meo)t > -
%ompareN%'e%BN+tems > no
M
.....
Texto IV.6.: Configuracin del mdulo LDAP en el archivo
/etc/freeradius/radiusd.conf.
N#*6re S!"n!7!cad#
Ser7er: identit4: 4 pass@%rd
6stos son los datos de cone7in necesarios para acceder
al directorio L#AP.
9asedn
Wmbito a partir del cual se realizar,n las b5squedas en el
directorio L#AP.
.ilter
&iltro de b5squeda 3$A, para localizar un objeto de
usuario utilizando el nombre suministrado por el cliente
durante la autenticacin 'A#I/S. 2por de!ecto X
?HuidXYuI@ I
9aseL.ilter
&iltro de b5squeda L#AP usado como ,mbito de b5squeda
b,sico. Hpor de!ecto X ?HobjectclassXradiuspro!ileI@ I
startLtls
#uando el valor de esta opcin es 4es, se inicia una
cone7in ci!rada con $LS al directorio L#AP. *equiere de
la con!iguracin adicional de par,metros de claves y
certi!icados.
pr%.ileLattri9-te 4
de.a-ltLpr%.ile
6l valor de pr%.ileLattri9-te de!ine el nombre del atributo
en el objeto de usuario que contiene el $< de un objeto
radiuspro!ile que contiene el per!il al que pertenece dicho
usuario.
6l valor de.a-ltLpr%.ile contiene $< del per!il por de!ecto
para los usuarios. Hpor de!ectoX <)33I.
accessLattr 4
accessLattrL-sedL.%rLall%@
6l valor accessLattrL-sedL.%rLall%@ de!ine si el valor
accessLattr es usado para permitir H4es5 o denegar Hn%5 el
acceso, por de!ecto el valor es 4es.
"i el valor accesLattr es usado para permitir el acceso:
"i no e7iste o el valor es +ALSE: no permite el
acceso remoto.
"i el valor es 4es 2% c-al3-ier %tr% distint% de
+ALSE5: permite el acceso remoto.
"i el valor accesLattr es usado para denegar el acceso:
"i e7iste el usuario tiene denegado el acceso.
"i no e7iste el usuario tiene permitido el acceso.
dicti%nar4Lmappin(
*e!erencia al archivo que contiene las correspondencias
entre los atributos L#AP y los atributos 'A#I/S. or
de!ecto el valor es UVradd9dirW"ldap.attrmap
pass@%rdLheader 4
pass@%rdLattri9-te
6stos valores de!inen el atributo L#AP que contiene la
contrase%a del usuario por de!ecto y cual es el ci!rado del
mismo, esto se utiliza para validar por HAP .
c%mpareLchec&Litems
6ste valor determina si se deben comparar los valores
e7trados del directorio L#AP con los que enva el cliente
en el pedido entrante. or de!ecto el valor es n%.
time%-t: timelimit:
netLtime%-t 4
ldapLc%nnecti%nsLn-m9er
6stos valores determinan los tiempos de espera para el
servidor L#AP, los tiempos lmite que se puede demorar
en procesar un pedido y el n5mero de cone7iones abiertas
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
11./01
N#*6re S!"n!7!cad#
contra el directorio L#AP. 6stos par,metros han de
establecerse en !uncin de la carga de proceso que tiene
una implementacin particular.
Tabla IV.3.: Parmetros de configuracin del mdulo LDAP.
3os par,metros antes mencionados de!inen el comportamiento del
servidor 'A#I/S: con almacenamiento en un directorio L#AP.
6l mdulo !SHAP soporta la autenticacin M"K#JA y M"K#JAK
vG, y es utilizado por los m8todos de acceso PPP%E 4 ?PA c%n EAPE
PEAP. 6l cuadro de De7to +(.0 muestra la con!iguracin requerida.
3as directivas de con!iguracin de este mdulo son las siguientes:
N#*6re S!"n!7!cad#
-seLmppe
ermite la utilzacin de !PPE, en la
autenticacin
re3-ireLencr4pti%n
"i -seLmppe tiene por valor 4es, realiza un
ci!rado moderado.
re3-ireLstr%n(
"i -seLmppe tiene por valor 4es, siempre
requiere claves de /GA bits.
@ithLntd%mainLhac& "i este par,metro tiene valor yes, en caso
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/EE./01
.....
ms%'ap J
a)t'type > MS?CGA4
)seNmppe > yes
re<)+reNen%rypt+on > yes
re<)+reNstron& > yes
F+t'Nnt6oma+nN'a%B > no
M
.....
Texto IV.7.: Configuracin del mdulo MSCHAP en el archivo
/etc/freeradius/radiusd.conf.
N#*6re S!"n!7!cad#
de que un cliente M" Oindo4s se conecte
envando el usuario en la !orma
#%mini%"n%m9reLdeL-s-ari% y el desa.>%
tomando la porcin del nombre del usuario
solamente, corrige el comportamiento
incorrecto.
Tabla IV.4.: Directivas de configuracin de mdulo MSChap en freeradius.
6l mdulo A requiere una con!iguracin muy simple y solamente es
necesario de!inir el esquema de ci!rado que se utilizar,, como se puede
observar en el cuadro de De7to +(.A.
.....
H %lear: Clear te:t
H %rypt: !n+: %rypt
H m61: MD1 e%nrypt+on
H s'a-: SGA- en%rypt+on.
H DEFA!"T: %rypt
pap J
en%rypt+onNs%'eme > %rypt
M
.....
Texto IV.8.: Configuracin del mdulo PAP en el archivo
/etc/freeradius/radiusd.conf.
3a seccin de con!iguracin EAP del archivo radi-sd.c%n., se
colocar,n todas las directivas de con!iguracin para las variantes
soportadas de dicho protocolo. 6n este caso, en que se ha elegido usar
EAPE$$LS 4 EAPEPEAP, ser, necesario con!igurar tambi8n la seccin de
EAPE$LS: ya que ambos protocolos elegidos realizan el intercambio de
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/E/./01
paquetes dentro de un t5nel D3" y requieren certi!icados slo por parte
del servidor.
Ambos protocolos se usan en el m8todo de acceso OA para
autenticar los usuarios. 6l protocolo EAPE$$LS se utiliza junto con PAP y
el protocolo EAPEPEAP se usa junto con !SHAP72.
3os mdulos de .reeradi-s necesarios para utilizar estas variantes del
protocolo EAP son rlmLeapLpeap: rlmLeapLttls 4 rlmLeapLtls. 6stos
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/EG./01
.....
eap J 6efa)ltNeapNtype > peap
t+merNe:p+re > /;
+&noreN)nBnoFnNeapNtypes > no
%+s%oNa%%o)nt+n&N)sernameN*)& > no
H T+pos soporta6os 6e EA4
HEA4?MD1
m61 J M
HEA4?T"S
tls J 6efa)ltNeapNtype > tls
pr+8ateNBeyNpassFor6 > A65p-;$G.9BsB9;2
pr+8ateNBeyNf+le > 7Jra66*6+rMD%ertsD%ert?sr8.pem
%ert+f+%ateNf+le > 7Jra66*6+rMD%ertsD%ert?sr8.pem
CANf+le > 7Jra66*6+rMD%ertsDroot.pem
6'Nf+le > 7Jra66*6+rMD%ertsD6'
ran6omNf+le > 7Jra66*6+rMD%ertsDran6om
fra&mentNs+5e > -;20
+n%l)6eNlen&t' > yes M
HCont+n)an los t+pos soporta6os 6e EA4
M
.....
Texto IV.9.: Configuracin parcial del mdulo EAP en el archivo
/etc/freeradius/radiusd.conf.
mdulos no est,n compilados con el paquete .reeradi-sE1.1.3 para la
distribucin #e9ian Sar(e 3.1, lo que requiere descargar el archivo !uente
y compilarlo CAp8ndice AF .
3a seccin de directivas de con!iguracin del mdulo 6A se divide
en una seccin de con!iguracin com5n y di!erentes subsecciones para
cada una de las con!iguraciones espec!icas del protocolo EAP. ara
realizar la con!iguracin de EAPE$LS: es necesario crear previamente
una A-t%ridad de erti.icaci,n 2A5 y generar las claves y certi!icados
para el servidor CAp8ndice BF.
6n el cuadro de De7to +(.1 se puede apreciar un !ragmento de la
seccin del archivo de con!iguracin radi-sd.c%n.: relativa a EAP: en el
que se pueden observar los par,metros generales para este protocolo y
las subsecciones para EAPE!#0 y EAPE$LS.
6l signi!icado de las directivas que se observan es e7presado en la
siguiente tabla:
N#*6re S!"n!7!cad#
S6secc!+n Genera) EA,
de.a-ltLeapLt4pe
#omo los pedidos EAP pueden no contener
el tipo de EAP utilizado, este valor se utiliza
para determinar qu8 tipo de EAP elegir a !in
de realizar la autenticacin. "i otro mdulo
EAP !ija el atributo EAPE$4pe, 8ste tendr,
precedencia sobre el valor por de!ecto.
timerLe8pire
6l servidor mantiene una lista que relaciona
los paquetes EAPE'e3-est"'esp%nse. 6ste
valor determina el tiempo que se debe
esperar para borrar una entrada en la lista.
i(n%reL-n&n%@nLeapLt4pes
$ebido a que el servidor tiene soporte para
una cantidad limitada de variantes del
protocolo EAP, si recibe un tipo que no
soporta, deniega el acceso. "i esta directiva
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/E-./01
N#*6re S!"n!7!cad#
tiene por valor 4es y se ha de!inido otro
mdulo con un pro7y que soporte el tipo, se
reenva la peticin al pro7y.
cisc%Lacc%-ntin(L-sernameL9-(
"oluciona el bug de #isco A/G-EB
!4./G.GH/-IJA/, que agrega un byte m,s al
atributo -serEname en la aceptacin a la
peticin de acceso.
S6secc!+n EA,9MD:
!#0
"lo con colocar el nombre, sin par,metros,
se con!igura el uso de este mdulo EAP.
S6secc!+n EA,9TLS
de.a-ltLeapLt4pe 6ste valor !ija el tipo EAP a EAPE$LS.
pri7ateL&e4Lpass@%rd
6ste valor es la contrase%a de la clave
privada del servidor.
pri7ateL&e4L.ile
6ste valor es la ubicacin del archivo de
clave privada del servidor.
certi.icateL.ile
6ste valor es la ubicacin del archivo del
certi!icado del servidor.
AL.ile
6ste valor es la ubicacin del archivo del
certi!icado de la Autoridad #erti!icante, que
!irma los certi!icados emitidos.
dhL.ile
6ste valor es la ubicacin del archivo de
clave $i!!ieKJellman, denominado dh.
rand%mL.ile
6ste valor es la ubicacin de un archivo con
valores aleatorios denominado rand%m.
.ra(mentLsiCe
6ste valor no debe e7ceder los 2E1= bytes
de un paquete 'A#I/S: en la mayora de
los A la m,7ima longitud de un paquete es
de /;EEK/=EE bytes, por lo que el tama%o
de un !ragmento debera ser de /EG2 bytes
o menor.
incl-deLlen(th
"i esta directiva tiene por valor 4es: se
incluye en cada paquete el tama%o total del
mensaje Hvalor por de!ectoI. "i el valor es
n%, slo se incluye el tama%o total del
mensaje en el primer paquete.
Tabla IV.5.: Directivas de configuracin del mdulo EAP, EAP-MD5 y EAP-TLS.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/E2./01
)na vez de!inidas las directivas de EAPE$LS, se deben con!igurar las
directivas para EAPE$$LS 4 EAPEPEAP: como se observa en el cuadro de
De7to +(./E, el signi!icado de cada directiva puede observarse en la tabla
subsiguiente.
.....
eap J
.....
ttls { 6efa)ltNeapNtype > m61
%opyNre<)estNtoNt)nnel > yes
)seNt)nnele6Nreply > yes M
peap J 6efa)ltNeapNtype > ms%'ap82
%opyNre<)estNtoNt)nnel > yes
)seNt)nnele6Nreplay > yes
pro:yNt)nnele6Nre<)estNasNeap > yes M
ms%'ap82 J M
M
...
Texto IV.10.: Configuracin parcial del mdulo EAP de freeradius.
N#*6re S!"n!7!cad#
S6secc!+n EAP-TTLS
de.a-ltLeapLt4pe 3a sesin EAP dentro del t5nel D3"
necesita tener de!inido un tipo de EAP de
!orma separada a la sesin e7terna al
t5nel. H*ecordar que 6AKDD3" puede
describirse como una sesin EAP: dentro de
una sesin $iameter, dentro de un t5nel
D3", dentro de una sesin EAP, dentro de
una solicitud 'A#I/S5.
c%p4Lre3-estLt%Lt-nnel 3a solicitud de a-tenticaci,n dentro del
t5nel D3" no contiene todos los atributos
'A#I/S, slo los necesarios para realizar
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/E;./01
N#*6re S!"n!7!cad#
la a-tenticaci,n, si este par,metro tiene por
valor 4es, los atributos que no est,n
presentes en la solicitud interna al t5nel y si
lo est,n !uera de 8l, se copian en la solicitud
interna.
-seLt-nneledLrepl4 3os atributos enviados en la respuesta al
NAS est,n basados en el nombre de
usuario e7terno al t5nel. 'eneralmente el
valor es an%n4m%-s. ara que se enven al
NAS los atributos basados en la sesin
EAP interna al t5nel, este par,metro debe
tener valor 4es.
S6secc!+n EAP-PEAP
de.a-ltLeapLt4pe Idem EAPE$$LS. or de!ecto debe tener el
valor mschap72 soportado por los clientes
con sistema operativo M" Oindo4s.
c%p4Lre3-estLt%Lt-nnel +dem EAPE$$LS.
-seLt-nneledLrepl4 +dem EAPE$$LS.
pr%84Lt-nneledLre3-estLasLeap "i la sesin dentro del t5nel, utiliza un pro7y
de 'A#I/S, el servidor que realiza la
autenticacin, puede no soportar EAPE
!SHAP*2. "i el par,metro tiene por valor
n%, el pro7y de 'A#I/S reenva los
paquetes como si !uese una sesin normal
de M"#JAvG.
S6secc!+n EAP-MSCHAPV2
!SHAP72 "lo con colocar el nombre, sin par,metros,
se con!igura el uso de este mdulo EAPE
!SHAP72. *equiere que se haya
con!igurado el mdulo mschap.
Tabla IV.6.: Directivas de configuracin del mdulo EAP-TTLS, EAP-PEAP y EAP-
MSCHAPv2
6l registro % acc%-ntin( de uso de los recursos utiliza como soporte
de almacenamiento un servidor de bases de dat%s My"Q3. or esto es
necesario completar las directivas de con!iguracin para el mdulo
rlmLs3lLm4s3l que utiliza el servidor 'A#I/S para acceder al motor de
bases de datos.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/E=./01
3a seccin de con!iguracin de este mdulo se encuentra en el archivo
"etc".reeradi-s"s3l.c%n., que se incluye en el archi7% radiusd.con!. 6n
dicha seccin hay que modi!icar los par,metros de cone7in al motor de
bases de datos. or de!ecto est,n de!inidas las consultas que realizan las
tareas de registro.
Dambi8n se realiza la con!iguracin de un par,metro que esta
relacionado con la poltica de uso de!inida. 6ste par,metro utiliza los
registros de utilizacin, para chequear en el proceso de a-tenticaci,n si
e7iste una sesin activa para la cuenta de usuario.
Adem,s se realiza un chequeo de la e7istencia y el valor del atributo
Sim-ltane%-sE/se, y dependiendo del valor del mismo, se permite o no un
n5mero prede!inido de sesiones simult,neas.
Qtra posibilidad de realizar el chequeo para utilizacin simult,nea es
utilizar un mdulo denominado rad-tmp, que realiza el mismo chequeo
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/E0./01
.....
s<l J
6r+8er > KrlmNs<lNmys<lK
ser4er 1 Glocal'ostG
lo.i) 1 Gra*iusG
pass9or* 1 Gra*iusG
......
# Eli(i)ar co(e)tario *e la si.uie)te lH)ea
si(ulIcou)tI/uery 1 G&E5E+! +O#N!?J@ 3ROM KEacctItable1F
:LERE #serNa(e1MNE&O5%#ser%Na(eFM N7 cct&top!i(e 1 0G
M
...
Texto IV.11.: Configuracin parcial del mdulo rlm_sql_mysql de freeradius.
pero utilizando un archivo tipo -tmp donde registra los inicios de sesin y
las terminaciones de sesin. $e esta !orma obtiene la in!ormacin de que
usuarios tienen una sesin iniciada en el sistema. 3a con!iguracin del
mismo es bastante sencilla, como se puede observar en el cuadro de
De7to +(./G. "e recomienda realizar esta tarea a trav8s del motor !4s3l
por razones de rendimiento.
3a seccin a-th%riCe del archivo radi-sd.c%n. se con!igura colocando
los nombres de los mdulos de!inidos en las secciones anteriores. 6s
importante el orden en que se colocan los mdulos.
6l mdulo eap debe ser el primer mdulo de autorizacin, luego de los
mdulos prepr%cess 4 a-thLl%( que realizan los procesos para evitar las
ambigZedades en los nombre de usuario y el registro de los pedidos de
autorizacin. uede observarse la con!iguracin de esta seccin en el
cuadro de De7to +(./-.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/EA./01
...
ra6)tmp J f+lename > 7Jlo&6+rMDra6)tmp
)sername > LJ!ser?NameM
%aseNsens+t+8e > yes
%'e%BNF+t'Nnas > yes
perm > ;/;;
%aller+6 > KyesK
M.......
Texto IV.12.: Configuracin opcional del mdulo radutmp, para chequeo uso
simultneo.
3a seccin a-theticate se con!igura listando los mdulos disponibles
para realizar el proceso de autenticacin. $icho proceso no intenta
autenticar probando con cada mdulo listado, sino que el mdulo usado
en la seccin a-th%riCe agrega un atributo de con!iguracin denominado
A-thE$4pe. 6se tipo de autenticacin se utiliza para elegir el mdulo
apropiado de la lista de!inida. 6n un caso particular se puede de!inir en el
archivo de con!iguracin el atributo A-thE$4pe, a !in de !orzar un tipo de
autenticacin prede!inida, pero es posible que dejen de !uncionar algunos
de los mdulos de autenticacin.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/E1./01
...
a)t'or+5e J
prepro%ess
a)t'Nlo&
eap
ms%'ap
l6ap
M.......
Texto IV.13.: Seccin de autorizacin.
...
a)t'ent+%ate J
pap
A)t'?Type MS?CGA4 J
ms%'ap M
A)t'?Type "DA4 J
l6ap M
eap
M.......
Texto IV.14.: Seccin de autorizacin.
uede observarse la con!iguracin de esta seccin requerida para el
!uncionamiento del modelo de in!raestructura planteado. 6n dicha
con!iguracin se han !ijado dos valores de A-thE$4pe prede!inidos, ya que
para que se complete el proceso de autenticacin del m8todo de acceso
PPP%E result necesario de!inir al mdulo M"K#JA como m8todo de
autenticacin por de!ecto.
3as secciones a continuacin est,n relacionadas en la instanciacin
de algunos mdulos. $ichas secciones son acc%-ntin( 4 sessi%n. 3a
seccin acc%-ntin( se encarga de instanciar los mdulos que realizar,n
el almacenamiento de los registros de utilizacin, y la seccin sessi%n se
encarga de instanciar los mdulos que realizar,n el control sobre el uso
simult,neo de una cuenta de usuario, descripto anteriormente.
Derminada la con!iguracin principal del servidor 'A#I/S, se deben
modi!icar dos archivos adicionales que de!inen los NAS que pueden
comunicarse al servidor y los diccionarios de atributos a utilizar por el
servidor.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
//E./01
...
a%%o)nt+n& J s<l
M
sess+on J s<l
Hra6)tmp
M
.......
Texto IV.15.: Secciones de registro y control de sesin.
6l archivo que de!ine los NAS es "etc".reeradi-s"clients.c%n., en dicho
archivo se deber, consignar desde donde se podr, acceder al servidor y
con que contrase%a, como se puede observar en el cuadro de De7to +(./=,
se puede consignar una red completa. 6n este caso se deber, con!igurar
la red del sistema de distri9-ci,n y al propio ser7id%r de a-tenticaci,n.
6l archivo "etc".reeradi-s"dicti%nar4 es el diccionario de atributos
principal. 6n 8l deben realizarse todas las modi!icaciones de los atributos
y las inclusiones de los archivos de diccionarios e7ternos. ara un
correcto !uncionamiento del modelo de in!raestructura, deben estar
presentes los diccionarios que !iguran en el cuadro de De7to +(./0.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
///./01
%l+ent -;.-;.-;.;D20 J se%ret > S<a0.9fC
s'ortname > Re6?S+stema?D+str+*)%+on
nastype > ot'erM
%l+ent -27.;.;.- J se%ret > S<a0.9fC
s'ortname > lo%al'ost
nastype > ot'er M
.......
Texto IV.16.: Configuracin del archivo clients.conf de freeradius.
....
7#NC"!DE D)srDs'areDfreera6+)sD6+%t+onary
7#NC"!DE D)srDs'areDfreera6+)sD6+%t+onary.%'+ll+spot
7#NC"!DE D)srDs'areDfreera6+)sD6+%t+onary.F+spr
7#NC"!DE D)srDs'areDfreera6+)sD6+%t+onary.mer+t
7#NC"!DE D)srDs'areDfreera6+)sD6+%t+onary.m+%rosoft
....
Texto IV.17.: Configuracin del diccionario de atributos principal.
#ada uno de los diccionarios tiene las de!iniciones de los atributos y el
tipo de los mismos, para atributos de un !abricante dado. 6l diccionario
ubicado en "-sr"share".reeradi-s"dicti%nar4 incluye la mayora de los
diccionarios de los !abricantes.
)na vez realizada la con!iguracin del servidor 'A#I/S, se deber,
con!igurar un cliente 'A#I/S, cuya implementacin en 3inu7 se llama
radi-sclient1. 6ste cliente 'A#I/S permite que los di!erentes servidores
de los m8todos de acceso, por ejemplo el servidor PPP%E, puedan
realizar la autenticacin, de los usuarios usando el servidor 'A#I/S.
3os archivos de con!iguracin de dicho cliente se encuentran en el
directorio "etc"radi-sclient. Jay que editar al menos dos de ellos, ser7ers
4 dicti%nar4.
6l primero de ellos de!ine la direccin del servidor 'A#I/S y la
contrase%a para acceder al mismo, como se puede observar en el cuadro
de De7to +(./A.
6l segundo es el diccionario de atributos que utiliza el cliente 'A#I/S.
Rste es similar al archivo de diccionario principal del servidor y la principal
di!erencia con el mismo es la sinta7is para incluir un diccionario e7terno.
6n el diccionario de radi-sclient debe utilizarse la directiva INL/#E
en vez de U+<#3)$6, tal como se observa en el cuadro de De7to +(./1.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
//G./01
HSer8er Name or Cl+entDSer8er pa+r =ey
H???????????????? ???????????????
lo%al'ostDlo%al'ost S<a0.9fC
Texto IV.18.: Configuracin del archivo servers de radiusclient.
6n dicho cuadro tambi8n pueden observarse los diccionarios necesarios
para la operacin del servidor PPP%E en el modelo de in!raestructura
propuesto.
1. ,ORTAL CAUTIVO .CA,TIVE ,ORTAL/
3a implementacin del portal cautivo bajo KPL
1
que se eligi se llama
hillisp%t
2
. hillisp%t posee una implementacin sencilla y autoKcontenida,
es decir, depende de muy pocos servicios e7ternos para !uncionar. 3as
principales caractersticas de hillisp%t son las siguientes:
"oporta dos m8todos de autenticacin distintos /A!
2/ni7ersal Access !eth%d5 4 ?PA"'SN 2?ireless Pr%tected
Access5.
"oporta Autenticacin, Autorizacin y *egistro HAAAI
contra un ser7id%r 'A#I/S.
osee un servicio de #HP propio para ambos m8todos
de autenticacin. #on ?PA"'SN soporta asignacin de direcciones
IP a trav8s de atributos *A$+)", !uncionando como pro7y.
1 GNU GPL, General Public License. ver http://www.gnu.org.
2 http://www.chillispot.org
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
//-./01
.......
#NC"!DE Det%Dra6+)s%l+entD6+%t+onary.mer+t
#NC"!DE Det%Dra6+)s%l+entD6+%t+onary.m+%rosoft
#NC"!DE D)srDs'areDfreera6+)sD6+%t+onary.%'+ll+spot
Texto IV.19.: Configuracin del archivo dictionary de radiusclient.
3a autenticacin con /A! soporta SSL.
"oporta cualquier AP.
"oporta scripts de inicio y !inal de cone7in para cada
cliente.
&unciona utilizando <AD o *outing.
*ealiza di!erentes controles a trav8s de los valores de
los atributos 'A#I/S de los diccionarios @ispr 4 chillisp%t. 6sto
permite controlar los vol5menes de tr,!ico entrante.saliente de un
usuario en particular, realizar controles de ancho de banda, etc.
hillisp%t necesita de un servidor ?E) c%n s%p%rte SSL y de un
servidor 'A#I/S.
#uando utiliza el m8todo de autenticacin /A!, entrega una direccin
+ a trav8s del protocolo #HP: pero cuando el cliente intenta conectarse,
redirecciona el tr,!ico hacia el servidor ?E).
6sto sucede hasta que el cliente inicia un navegador, y al intentar
realizar un acceso se redirecciona a una p,gina segura espec!ica del
servidor ?E) que posee un lin& hacia la p,gina de autenticacin. )na
vez que el cliente ha ingresado su usuario y contrase%a, un script en el
servidor ?E), ci!ra la contrase%a y la enva a programa hilli, que realiza
la autenticacin contra el servidor 'A#I/S. )na vez que el usuario se ha
autenticado correctamente se deja de redireccionar el tr,!ico del cliente,
que !unciona normalmente.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
//2./01
6n caso de usar el m8todo de autenticacin ?PA"'SN, el AP o!icia de
a-tenticad%r ?PA"'SN: el cliente entabla una sesin a trav8s de EAPOL
con el AP: que tiene con!igurado como servidor 'A#I/S a hillisp%t.
hillisp%t en este caso o!icia de Pr%84 'A#I/S: reenviando el pedido
de acceso al servidor 'A#I/S, quien ejecuta el proceso de autenticacin.
6n caso de que la autenticacin sea satis!actoria, cuando hillisp%t recibe
el mensaje de acceso aceptado, si dicho mensaje contiene el atributo
+ramedEIPEAddress, asigna al cliente dicha direccin + a trav8s del
servidor #HP intern%.
hillisp%t actualmente tiene dos versiones, la versin estable /.E y un
a versin de desarrollo /./. )na de las di!erencias entre las versiones
son los par,metros que permiten instanciar un script cada vez que un
cliente inicia o !inaliza una cone7in. 6sta es una caracterstica que se
utiliza junto con el script @i.iEp%lic4, para aplicar permisos, como se ve en
dicha seccin. 3a distribucin para #E)IAN solo brinda la versin estable
hillisp%tE1.B.B, por lo que se debe compilar una versin posterior,
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
//;./01
.......
HRe6 a la <)e se 6a ser8+%+o
)et 182.168.176.0-21
HRe6 <)e se )t+l+5a para 6+re%%+onam+ento 6+nOm+%o.
*y)ip 182.168.182.0-23
HRe6 <)e se )t+l+5a para 6+re%%+onam+ento estOt+%o
statip 182.168.176.0-22
H#nterfa5 DGC4
*'cpi, et'1
.......
Texto IV.20.: Fragmento de chilli.conf -Configuracin de redes.
proceso en el que se han presentado algunas particularidades y se
desarrolla en el Ap8ndice #.
)na vez que se ha instalado chillisp%t en la versin requerida, se debe
proceder a con!igurar la aplicacin para que !uncione con los par,metros
que se usan en el modelo de in!raestructura, editando el archivo
"etc"chilli.c%n..
3os primeros par,metros a de!inir son los par,metros de la red,
incluyendo cu,l es la red a la que chillisp%t brinda servicio 2net5: y qu8
porcin de la misma utiliza direccionamiento din,mico Hd4nipI y !ijo HstatipI
respectivamente. "e debe de!inir la inter!az en que escucha el servidor
#HP intern% 2dhcpi.5. Adicionalmente se pueden de!inir los servidores
#NS: si !uesen di!erentes a los que tiene con!igurada el propio servidor.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
//=./01
.......
H 4arOmetros 6el Ser8+6or RAD#!S
ra6+)sl+sten -92.-/8.;.-;;
ra6+)sser8er- -27.;.;.-
Hra6+)sser8er2 -27.;.;.-
ra6+)sa)t'port -8-2
ra6+)sa%%tport -8-.
ra6+)sse%ret S<a0.9fC
ra6+)snas+6 mt+?ser8er
H4arOmetros para 4ro:y RAD#!S
pro:yl+sten -;.-;.-;.-
pro:yport -/01
pro:y%l+ent -;.-;.-;.;D20
pro:yse%ret S<a0.9fC
......
Texto IV.21.: Fragmento de chilli.conf -Configuracin de RADIUS
6n el archivo de con!iguracin tambi8n se de!inen los par,metros
relacionados con el servidor 'A#I/S al que se debe consultar, como se
observa en el cuadro de De7to +(.G/, en la tabla subsiguiente se
encuentran las de!iniciones de cada par,metro usado.
N#*6re S!"n!7!cad#
,ar(*e'r#s 3ara c#*n!carse c#n e) servidor RADIS
radi-slisten
$ireccin + por la cual se comunica el servidor 'A#I/S. 6n
este caso es la inter!az que pertenece a la red privada del
"ervidor de Autenticacin.
radi-sser7er1
radi-sser7er2
$ireccin + del servidor 'A#I/S: primario y secundario, en
este caso ese valor es l%calh%st /G0.E.E./
radi-sa-thp%rt
<5mero de puerto )$ donde el servidor 'A#I/S recibe los
paquetes destinados a procesos de autenticacin. or
de!ecto es el puerto /A/G.
radi-sacctp%rt
<5mero de puerto )$ donde el servidor 'A#I/S recibe los
paquetes destinados a procesos de registro. or de!ecto es
el puerto /A/-.
radi-ssecret
#ontrase%a para acceder al servidor 'A#I/S. $ebe ser la
misma que se ha con!igurado en el archivo clients.c%n. del
servidor.
radi-snasid
6s el nombre que se ha elegido para que el servidor
chillisp%t se identi!ique !rente al servidor 'A#I/S.
,ar(*e'r#s 3ara ac'ar c#*# Pro!" RADIS
pr%84listen
$ireccin + en la que se espera recibir los pedidos de
autenticacin cuando el servidor chillisp%t o!icia como Pr%84
'A#I/S.
pr%84p%rt
<5mero de puerto )$ donde se espera recibir los pedidos
de autenticacin. $ebe ser di!erente al puerto de!inido en
radi-sa-thp%rt.
pr%84client
$ebe ser la red desde la que se permite el acceso para
pedidos de autenticacin. 6n este caso el la red del sistema
de distribucin. /E./E./E.E.G2.
pr%84secret
#ontrase%a que se compartir, con los clientes que
contactar,n a chillisp%t como si !uera un servidor 'A#I/S.
Tabla IV.7.: Directivas de configuracin RADIUS en Chillispot.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
//0./01
ara con!igurar el m8todo de acceso /A!, es necesario de!inir
previamente la con!iguracin del servidor ?E) donde se aloja la p,gina
inicial de bienvenida y es necesario copiar al servidor 4eb el script KI
que se encuentra en "-sr"li9"c(iE9in"h%tsp%tl%(in.c(i.
.......
)amser8er 'ttps:DD-92.-/8.-7/.-D%&+?*+nD'otspotlo&+n.%&+
ua('o(epa.e 'ttps0--182.168.176.1-c'illi-i)*e<.'t(l
)amse%ret ASDFC-2.0;987
#ua(liste) 182.168.182.1
H)amport .99;
#ua(allo9e* 182.168.0.100
H)amany6ns
.......
Texto IV.22.: Fragmento de chilli.conf -Configuracin UAM.
N#*6re S!"n!7!cad#
-amser7er
)*3 del script del servidor ?E) que realiza el manejo de
la autenticacin de usuarios.
-amh%mepa(e
)*3 de la p,gina de inicio o bienvenida a la que se
redireccionar,n los clientes no autenticados.
-amsecret
6ste par,metro tiene que de!inirse tambi8n en el script
h%tsp%tl%(in.c(i del servidor ?E). "e utiliza para ci!rar la
contrase%a del usuario cuando se enva desde el servidor
?E) hacia chillisp%t.
-amlisten
6ste par,metro permite de!inir la direccin + donde se
escuchar,n las solicitudes de autenticacin. or de!ecto
es la primera direccin + del segmento de!inido en el
par,metro net. 6n la con!iguracin propuesta no debe
estar activado.
-amp%rt
6ste par,metro establece el puerto D# donde se
escuchar,n las solicitudes de autenticacin. or de!ecto
es el puerto -11E. 6n la con!iguracin propuesta no debe
estar activado.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
//A./01
N#*6re S!"n!7!cad#
-amall%@ed
6sta directiva permite m5ltiples valores, y los par,metros
pueden ser direcciones +, segmentos de red o nombres
de dominio. "i se ha de!inido los usuarios no autenticados
podr,n acceder libremente a las direcciones establecidas.
6n la con!iguracin propuesta debe estar desactivado.
-aman4dns
"i este par,metro no est, comentado, todos los clientes,
a5n los no autenticados podr,n acceder a cualquier
servidor #NS e7terno. <o es recomendable activarlo, ya
que puede ser una vulnerabilidad de seguridad.
Tabla IV.8.: Directivas de configuracin UAM en Chillispot
Adem,s se deber, con!igurar dos par,metros adicionales, c%n-p 4
c%nd%@n, cada uno de estos par,metros apunta a un script di!erente.
#uando un usuario sea autenticado satis!actoriamente se ejecuta el script
del par,metro c%n-p: y cuando el usuario se desconecte se ejecuta el
script del par,metro c%nd%@n. 3as !unciones que cumplen los scripts se
ven m,s adelante en la seccin Jerramientas para Aplicacin de
olticas.
or 5ltimo se debe editar el archivo h%tsp%tl%(in.c(i, dicho script est,
programado en Perl, y su !uncin principal es solicitar el nombre de
usuario y la contrase%a al cliente, ci!rar la contrase%a y enviar estos datos
al servidor chilli.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
//1./01
HPD)srD*+nDperl
.......
7)amse%ret > Q&73B12340887QR
7)serpassFor6 > 1R
.......
Texto IV.23.: Fragmento de hotspotlogin.cgi -Configuracin chillispot.
6l par,metro U-amsecret debe ser el mismo que se con!igur en
chilli.c%n.. 6l par,metro U-serpass@%rd debe con!igurarse con el valor /, y
esto signi!ica que se realiza la autenticacin usando el atributo /serE
Pass@%rd de un servidor 'A#I/S.
6ste script puede personalizase o sustituirse por otro que cumpla las
mismas !unciones.
4. SERVIDOR 5EB
3a instalacin de un servidor ?E) en el Ser7id%r de A-tenticaci,n,
obedece a que es necesario tanto para la implementacin de un P%rtal
#autivo, como para la implementacin de herramientas de administraci,n.
3os requerimientos b,sicos para la instalacin de este servidor son el
soporte de ci!rado SSL y el soporte de PHP. 3o primero es requisito de
chillisp%t y lo segundo es necesario para poder ejecutar herramientas de
administracin como PhpL#APadmin.
"i bien es posible con!igurar chillisp%t para que se conecte a otro
servidor ?E) e7terno, e instalar tambi8n las herramientas de
administracin en otro servidor, el criterio que se ha seguido es el de
mantener el n5cleo de herramientas y servicios necesario para la
operacin del modelo de in!raestructura, contenido dentro del mismo
modelo.
$e esta !orma se minimiza la cantidad de equipos que interact5an y se
evita que la in!ormacin sensible viaje a trav8s de varios equipos por la
red. #omo consecuencia de ello, disminuyen los puntos de !alla, es m,s
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/GE./01
di!cil que la in!ormacin sea interceptada a trav8s de un sni..er de red, y
se logra una peque%a ganancia en rendimiento.
:. SERVIDOR ,,,OE
ara implementar el m8todo de acceso PPP%E, es necesario instalar
un servidor PPP, el servidor PPP%E y con!igurar ambos para que la
autenticacin se e!ect5e contra el servidor 'A#I/S.
ara autenticar a los usuarios de este m8todo de acceso usando el
protocolo 'A#I/S, es necesario utilizar un pl-(in denominado radi-s.s%.
ara poder aplicar las polticas de uso, como se detalla en la seccin
Jerramientas para Aplicacin de olticas, es necesario conocer los
valores de los atributos 'A#I/S que enva el servidor al aceptar el
acceso remoto del cliente. ara ello se necesita utilizar otro pl-(in
denominado radattr.s%. $icho pl-(in genera un archivo
"7ar"r-n"radattr.ppp8, donde ppp8, hace re!erencia al nombre de la inter.aC
ppp donde est, conectado el cliente Hej pppE, ppp/, ppp7I. 6n el archivo
se especi!ican pares de atributoKvalor, e7trados del mensaje de
aceptacin de acceso que enva el servidor 'A#I/S.
Ambos pl-(ins son provistos por la aplicacin pppd, y permiten que el
servidor PPP%E e!ect5e la autenticacin de usuarios a trav8s de PAP:
HAP: !SHAP 4 !SHAP72, contra un servidor 'A#I/S usando la
aplicacin radi-sclient1. 3os detalles de con!iguracin de esta aplicacin
pueden observarse en la seccin "ervidor *A$+)".
6l m8todo de autenticacin de usuarios elegido es !SHAP72, debido
a que posee el nivel de seguridad m,s alto dentro de los m8todos de
autenticacin soportados por el pl-(in radi-s.s%.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/G/./01
3a utilizacin de !SHAP72, requiere que en el direct%ri% L#AP se
almacene el hash !#4 de la clave del usuario, para esto se utiliza el
atri9-t% L#AP sam9aN$pass@%rd: vinculado al atributo *A$+)" N$E
Pass@%rd.
)no de los problemas que se presenta al combinar PPP%E con otro de
los m8todos de acceso, es que el servidor PPP%E utiliza un p%%l de
direcciones + propio para la asignacin din,mica de direcciones. ara
evitar la duplicacin de direcciones +, se ha dividido el rango din,mico de
direcciones a entregar en dos partes, una parte administrada por PPP%E y
otra parte administrada por los otros m8todos de acceso. "i el usuario
posee el atributo 'A#I/S +ramedEIPEAddress, se entrega al cliente el
valor de dicho atributo como direccin +, independientemente de que
pertenezca al p%%l de direcci%nes din,micas o no.
6l servidor PPP%E se encarga de enviar al servidor 'A#I/S los datos
necesarios para el registro de utilizacin o acc%-ntin(.
ara la implementacin del servidor PPP se utiliz pppE2.4.4relA, y
para la implementacin del servidor PPP%E se us el rpEppp%eE3.A de
'%arin( Pen(-in
1
. 6n los &ernels de 3inu7 posteriores al G.2.E, rpEppp%e
soporta modo Pernel, pero tambi8n soporta correr en espacio de usuario.
6n general hay que compilar la aplicacin especialmente para poder
ejecutarla en espacio de &ernel: como se observa en el Ap8ndice $.
1 Roaring Penguin PPPoE:
http://www.roaringpenguin.com/penguin/openSourceProducts/rpPppoe
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/GG./01
3a aplicacin ppp%eEser7er usualmente se instancia en la lnea de
comandos, si bien se recomienda generar un script con ese !in. "e debe
ejecutar una instancia
G
el servidor PPP%E con los siguientes par,metros:
H D)srDs*+nDpppoe?ser8er %P ?s ?T /; ?# et'- %N 608 ?C
444oE?!M?;- %R 182.168.180.1 %5 182.168.176.1 ?S !M?F+reless
Texto IV.24.: Ejecucin de una instamcia del servidor PPPoE.
3os par,metros resaltados en el cuadro de De7to +(.G2 se e7plican en
la Dabla +(.1.
N#*6re S!"n!7!cad#
E&
6sta opcin especi!ica que el servidor debe usar m%d%
&ernel, por de!ecto se utiliza el espacio de usuario.
*equiere que el Pernel se haya compilado con soporte
para PPP%E.
EN nFmer%
6speci!ica el n5mero m,7imo de sesiones concurrentes,
por de!ecto es de =2 sesiones. "e debe tener en cuenta
el direccionamiento + que se desea utilizar.
E' direcci,n IP
6sta opcin con!igura la primera direccin din,mica que
asigna el servidor a un cliente remoto. 6l servidor
autom,ticamente registra las direcciones entregadas y
enva una direccin v,lida al cliente. "i no se especi!ica,
se usa por de!ecto la direccin /E.=0./;./. 6ste valor
debe relacionarse con el par,metro K< para obtener la
red + a la que el servidor le entregar, direcciones
din,micas.
EL direcci,n IP
6sta opcin con!igura la direccin IP local, si no se
de!ine, por de!ecto es /E.E.E./.
Tabla IV.9.: Parmetros relevantes para iniciar servidor PPPoE.
Al instanciar el servidor desde la lnea de comandos, el proceso se
bi!urca
G
y se ejecuta como dem%ni%.
2 Es posible ejecutar mltiples instancias del servidor PPPoE con configuraciones diferentes.
2 Traduccin del ingls de to fork. Este verbo se utiliza para indicar cuando un proceso crea
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/G-./01
#uando un cliente inicia sesin, el servidor inicia una instancia de
pppd que se encarga de la comunicacin dentro de la sesi,n PPP%E.
3a con!iguracin de pppd se encuentra en el archivo "etc"ppp"%pti%ns y
se puede observar en el cuadro de De7to +(.G;.
6l servidor PPP%E utiliza un archivo de con!iguracin propio. 6l mismo
se ubica en "etc"ppp"ppp%eEser7erE%pti%ns. 6n el archivo es necesario !ijar
los par,metros de !$/
1
y !'/
2
, debido al %7erhead de PPP%E que no
permite aprovechar los /;EE bytes de carga m,7ima que proporciona un
marco ethernet. "e puede observar el archivo de con!iguracin en el
cuadro de De7to +(.G=.
una copia de si mismo, denominada hijo del proceso original, que se denomina padre.
1 MTU, Maximum Transmit Unit. Unidad mxima de transmisin en bytes.
2 MRU, Maximum Receive Unit. Unidad mxima de recepcin en bytes.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/G2./01
(s%*)s 182.168.0.100
(s%*)s 182.168.0.264
syn%
a)t'
lo%B
+p%p?a%%ept?lo%al
+p%p?a%%ept?remote
lo%al
norepla%e6efa)ltro)te
plu.i) ra*ius.so
plu.i) ra*attr.so
re,use%pap
re,use%c'ap
re,use%(sc'ap
re/uire%(sc'ap%42
Texto IV.25.: Configuracin de pppd, archivo /etc/ppp/options.
6l signi!icado de las opciones resaltadas en el cuadro de De7to +(.G;
es desarrollado en la Dabla +(./E.
O3c!#nes S!"n!7!cad#
msEdns
6sta directiva permite !ijar las direcciones + de los
servidores #NS que enva el servidor PPP al cliente a trav8s
del protocolo IPP.
pl-(in
6sta directiva indica los pl-(ins que se deben utilizar. 6n
particular se deben usar radi-s.s% 4 radattr.s%.
re.-seEpap
6sta directiva indica que el servidor debe rechazar cualquier
intento de autenticacin a trav8s del m8todo de autenticacin
PAP.
re.-seEchap
6sta directiva indica que el servidor debe rechazar cualquier
intento de autenticacin a trav8s del m8todo de autenticacin
!SHAP.
re.-seEmschap
6sta directiva indica que el servidor debe rechazar cualquier
intento de autenticacin a trav8s del m8todo de autenticacin
!SHAP.
re3-ireEmschapE72
6sta directiva indica que el servidor debe requerir a
cualquier cliente que se conecta el uso del m8todo de
autenticacin !SHAP72.
Tabla IV.10.: Directivas de configuracin relevantes de pppd. (/etc/ppp/options)
ara utilizar este m8todo los clientes deber,n crear una cone7in
PPP%E en el sistema operativo !ijando par,metros de autenticacin
id8nticos a los desarrollados en el ser7id%r PPP%E.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/G;./01
H 444 opt+ons for 444oE Ser8er
mt) -0/;
mr) -0/;
Texto IV.26.: Configuracin de pppoe, archivo /etc/ppp/pppoe-server-options.
<. SERVIDOR DE BASE DE DATOS
3a instalacin de un motor de bases de datos en el Ser7id%r de
Autenticacin, obedece a la necesidad de almacenar los datos de registro
o acc%-ntin( del servidor 'A#I/S.
3a eleccin de !4STL se sustenta en que:
uede usarse bajo licencia '3 si se utiliza para
desarrollar bajo la misma licencia.
6s compatible con los mdulos del modelo de
in!raestructura que necesitan de un motor de bases de datos.
Adem,s e7isten aplicaciones de administracin @e9 como
phpm4admin: que simpli!ican la administracin del motor.
Al igual que el servidor ?E): si bien es posible con!igurar un motor de
bases de datos e7terno al servidor de autenticacin, se ha utilizado el
criterio mantener el n5cleo de herramientas y servicios necesario para la
operacin del modelo de in!raestructura, contenido dentro del mismo
modelo.
$e esta manera se minimiza la cantidad de equipos que interact5an y
se evita que la in!ormacin sensible viaje a trav8s de varios equipos por la
red. 6sto genera menor cantidad de puntos de !alla, mayor di!icultad para
interceptar la in!ormacin y una peque%a mejora de rendimiento.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/G=./01
=. @ERRAMIENTAS ,ARA A,LICACIN DE ,OLETICAS
6ste mdulo es uno de los pilares del modelo de in!raestructura que se
propone. 6l objetivo es aplicar polticas de uso de la red inal,mbrica a
trav8s de la aplicacin de per.iles de c%necti7idad a distintos grupos de
usuarios.
"e pueden de!inir tantos per.iles de c%necti7idad como se requiera
para implementar las polticas de uso.
ara aplicar estas herramientas es necesario de!inir los di!erentes
grupos de usuarios, de!inir las polticas de uso que se desea implementar
y modelar los per.iles de c%necti7idad que las re!lejan y se deben aplicar a
los grupos de usuarios.
6stos per.iles de c%necti7idad se ubican en la ouQpr%.iles del
directorio L#AP.
6l -id de cada objeto que de!ine un per.il de c%necti7idad tiene la
!orma 77EN%m9re, donde 88 es un n5mero que puede repetirse e indica el
orden en que se procesan las reglas de conectividad.
3os objetos que con!orman cada per.il de c%necti7idad deben
pertenecer a dos clases: radi-sO9<ectPr%.ile 4 radi-spr%.ile. Ambas
clases son provistas por radi-s.schema.
uede observarse la de!inicin de un per!il de ejemplo en el cuadro de
De7to +(.G0.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/G0./01
3os usuarios se vinculan a un per.il de c%necti7idad a trav8s del
atributo L#AP radi-sPr%.ile#n. 6l valor de este atributo debe ser el #N
del objeto de la clase radi-sO9<ectPr%.ile que contiene la de!inicin del
per.il de c%necti7idad.
3os per.iles de c%necti7idad se de!inen en el #irect%ri% L#AP y se
componen de dos tipos de directivas:
Atri9-t%s 'A#I/S6 6stos atributos cumplen dos roles,
de!inir el ?comportamiento@ de una cone7in e identi!icar el per.il de
c%necti7idad. $e!inen el ?comportamiento@ a trav8s de par,metros
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/GA./01
6n: )+6>;;?a6m+ns@o)>prof+les@6%>)m@6%>e6)
o*9e%tClass: ra*iusObject$ro,ile
o*9e%tClass: ra*iuspro,ile
o*9e%tClass: top
ra6+)sFrame6MT!: -0/;
ra6+)sFrame64roto%ol: 444
ra6+)sSer8+%eType: "o&+n
ra6+)sF+lter#6: 1;
)+6: 00%a*(i)s
%n: ;;?a6m+ns
6es%r+pt+on: ?N mar%a?a6m+ns ?t man&le
6es%r+pt+on: ?A mar%a?a6m+ns ?t man&le ?9 MAR= ??set?marB 1;
6es%r+pt+on: ?A 4RER3!T#NC ?t man&le ?s -92.-/8.-7/.;D2/ ?m marB
??marB ; ?9 mar%a?a6m+ns
6es%r+pt+on: ?N f+ltra?a6m+ns
6es%r+pt+on: ?A F3REARD ?m marB ??marB 1; ?9 f+ltra?a6m+ns
6es%r+pt+on: ?A f+ltra?a6m+ns ?9 ACCE4T
Texto IV.27.: Definicin de un perfil de conectividad en el directorio LDAP.
generales que, por ejemplo, permiten !ijar tiempos m,7imos de
cone7in en una sesin o tiempos lmite de inactividad. 3os atributos
tambi8n identi!ican el per.il de conectividad a trav8s del valor del
atributo +ilterEId. Rste es utilizado por las re(las de c%necti7idad para
?marcarJ e identi!icar el tr,!ico de los usuarios que pertenecen a un
per!il determinado. 3os valores de estos atributos no siempre son
interpretados de la misma manera por los servidores que componen
los mHt%d%s de acces%. or esta razn, las polticas de uso deben
contemplar a los mHt%d%s de acces% como parte integral de las
mismas.
'e(las de %necti7idad6 3as reglas de conectividad
permiten modelar los permisos que posee cada grupo de usuarios.
or ejemplo, si pueden acceder o no a un servicio que brinda un
h%st particular de la red interna, los servicios de +nternet a los que
pueden acceder, etc. ara !ormular dichas reglas se opt por utilizar
un metaElenguaje que coincide con la sinta7is del comando ipta9les
de KN/ Lin-8. #omo consecuencia, el metaElen(-a<e permite
utilizar la riqueza sem,ntica que posee dicho comando para de!inir
situaciones de capa de red. Adem,s no requiere de capacitacin
adicional para los administradores de red que est,n !amiliarizados
con el uso de esta herramienta. ara almacenar las re(las de
c%necti7idad se realiza una sobrecarga del atributo descripti%n que
brinda el objeto radi-sO9<ectpr%.ile 2OI#Q2.0.4.135. 6ste atributo
L#AP soporta m5ltiples valores con una longitud m,7ima de /EG2
caracteres. 6sto permite almacenar una re(la por cada 7al%r de
dicho atributo, !acilitando de esta !orma la lectura del conjunto de
reglas.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/G1./01
3a implementacin del conjunto de re(las de c%necti7idad depende del
direccionamiento + particular de cada implementacin, ya que las reglas
se aplican en la capa de red.
A partir del direccionamiento de red, que se plante con !ines
did,cticos en la seccin $ireccionamiento 'eneral de *ed, se desarrollan
algunos ejemplos de subdivisin del direccionamiento + para los per!iles
de conectividad.
,er7!) de C#nec'!2!dad Red I,
MF'#d# de As!"nac!+n I,
,er*!'!d# 3ara e) ,er7!)
BBEadministrad%r 1N2.11A.1P1.B"21 S,l% p%r -s-ari%
1BEpr%.es%r
1N2.11A.1P1.B"23
%
1N2.11A.1AB.B"22
P%r -s-ari% % din;micamente
2BEal-mn%
1N2.11A.1PA.B"23
%
1N2.11A.1AB.B"22
P%r -s-ari% % dn;micamente
NNEin7itad% 1N2.11A.1AB.B"22 S,l% din;micamente
BBEdirsEdin;micas 1N2.11A.1AB.B"22 Per.il administrati7%
Tabla IV.11.: Ejemplo de asignacin de direcciones IP a perfiles de conectividad.
#omo se observa en la Dabla +(.// , donde se han de!inido di!erentes
redes + para utilizar en cada per!il de conectividad. "e ha de!inido
adem,s, un per!il denominado BBEdirsEdin;micas con !ines administrativos
que se usar, para aplicar ?marcas@ al tr,!ico de las direcciones asignadas
de !orma din,mica.
3a aplicacin de los per.iles de c%necti7idad se ejecuta en dos partes:
la primera parte corresponde a las re(las de c%necti7idad y la segunda
parte corresponde a los atri9-t%s 'A#I/S.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/-E./01
6l "ervidor de Autenticacin tambi8n cumple el rol de (ate@a4 de la
red inal,mbrica. 6n e!ecto, act5a como r%-ter " .ire@all y aplica las re(las
de c%necti7idad al tr,!ico de red que lo atraviesa. 6stas re(las se aplican
a trav8s del ent%n% de .iltrad% de pa3-etes
1
que posee el nFcle% de
Lin-8. ara modi!icar el conjunto de reglas se usa el comando ipta9les.
6l proceso que aplica las re(las de c%necti7idad al tr,!ico de red tiene
dos !ases di!erentes. 3a primera !ase ?marca@ cada paquete, de acuerdo
al per.il de c%necti7idad que tienen asignado el usuario que origina dicho
tr,!ico. 6sta tarea se ejecuta a5n antes de que el (ate@a4 tome
decisiones sobre la suerte Hsi se reenva o no, ruta que se asigna, etcI del
paquete. ara decidir que ?marca@ le corresponde a cada paquete, se
eval5a la direccin de origen del mismo. A !in de simpli!icar este proceso
se vinculan ciertas redes + a per!iles de conectividad, para asignar las
mismas por usuario, como se puede observar en la Dabla +(.//. 6l
atri9-t% +ilterEId se usa como ?marca@ de tr,!ico, y de esta manera si un
paquete pertenece a una red espec!ica, se marca con el valor de dicho
atributo.
3as direcciones + asignadas de !orma din,mica no se conocen a
priori, e inclusive el servidor PPP%E y el servidor de P%rtal a-ti7%
administran p%%ls de direcciones din,micas di!erentes.
or esta razn, e7iste el per!il de administrativo BBEdirsEdin;micas.
6ste per!il de conectividad, crea una s-9cadena espec!ica dentro de la
cadena P'E'O/$INK en la ta9la !ANKLE. 6n esta s-9cadena: los
servidores que administran los p%%ls de direcciones din,micas e insertan
las reglas que relacionan una direccin + origen con una ?marca@ de
1 http://www.netfilter.org
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/-/./01
tr,!ico espec!ica. 6ste comportamiento se logra a trav8s de scripts que
se instancian al iniciar una cone7in y al concluir la misma.
"i bien este comportamiento se podra e7tender a todas las
direcciones +, incluidas las que se asignan por usuario, se implementa
slo para las direcciones + din,micas por razones de rendimiento. $e
esta manera se evita el crecimiento desmedido de la ta9la !ANKLE y las
operaciones de b5squeda en la misma.
3a segunda !ase ?aplica los permisos@, es decir !iltra el tr,!ico, de
acuerdo a la marca que posee cada paquete. 6stos procesos se pueden
observar en la +lustracin +(.;. #ada conjunto de permisos que contiene
el per!il de conectividad se vuelcan en una s-9cadena di!erente dentro de
la cadena +O'?A'# de la ta9la +IL$E'. 6l proceso de .iltrad% de
pa3-etes no se realiza en !uncin de las direcciones + de origen, sino de
acuerdo a la ?marca@ que tiene el paquete, y de esta !orma se deriva a la
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/-G./01
Ilustracin IV.5.: Proceso de aplicacin de Reglas de Conectividad.
cadena correspondiente. 6l orden en que se procesa el conjunto de
reglas es importante y determina el comportamiento de cada per!il. 6s por
esto que los nombres de los per!iles contienen un n5mero que permite
determinar el orden de procesamiento de las reglas.
ara aplicar las re(las de c%necti7idad almacenadas en los atributos
L#AP de cada %9<et% per.il de c%necti7idad: se desarroll un script que
lee el directorio 3$A y crea los conjuntos de reglas de marcado y !iltrado
de paquetes. 6ste script se denomina @i.iEp%lic4 y se le pueden enviar los
siguientes par,metros:
Start6 este par,metro indica a @i.iEp%lic4 que debe leer las reglas
del directorio 3$A y crear las cadenas correspondientes para
?marcar@ y ?!iltrar@ el tr,!ico. (eri!ica si !ue instanciado previamente
y crea en "7ar"r-n"@i.i dos archivos. 6l primero, denominado
@i.i.ar(s: cuya !uncin re!lejar el estado de start y que contiene una
copia de las reglas creadas y orden de creacin de las mismas. 6l
segundo contiene el listado de reglas en orden inverso, y se llama
@i.iEre7.ar(s.
St%p6 6ste par,metro indica a @i.iEp%lic4 que debe borrar las reglas.
Rstas deben borrarse en orden inverso, para lo que se procesa el
archivo "7ar"r-n"@i.iEre7.ar(s. 3uego se borran los archivos que
re!lejan el estado.
Stat-s6 6ste par,metro usa los archivos de estado para in!ormar si
las reglas se han cargado o no. 6n caso de que las reglas se
hayan cargado, las muestra.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/--./01
*estart: 6ste par,metro permite actualizar las reglas con!iguradas
en memoria cuando se han realizado modi!icaciones en el
direct%ri% L#AP.
6l script @i.iEp%lic4 se encuentra en "etc"init.d" y se instancia desde la
lnea de comandos. ara que el mismo se ejecute al momento de inicio,
en #e9ian, se debe utilizar el comando -pdateErc. ?i.iEp%lic4 se puede
observar en el Ap8ndice 6.
3os Atri9-t%s 'A#I/S que componen un per!il de conectividad se
envan, junto con los atributos del usuario, cuando el servidor 'A#I/S
enva un mensaje Access Accept.
6l conjunto de atributos es recibido e interpretado por el NAS en
!uncin de sus caractersticas. 6s por eso que no todos los servidores
interpretan el conjunto de atributos e7tendidos de!inidos por los
diccionarios adicionales de los !abricantes.
3a siguiente tabla Dabla +(./G, lista un conjunto tentativo de atributos
que pueden usarse para modelar el servicio que recibe un per!il
determinado. 6n dicha tabla se muestra tambi8n la compatibilidad con los
servidores utilizados.
A'r!6'# RADIUS
Ser2!d#r
,,,#E
Ser2!d#r
CG!))!s3#'
S!"n!7!cad#
Sessi%nE$ime%-t G G
6l valor en segundos de este par,metro
determina el lmite de tiempo m,7imo
que puede alcanzar una sesin antes
de que el NAS desconecte la misma.
IdleE$ime%-t G G
6l valor en segundos de este par,metro
determina el lmite de tiempo m,7imo
de inactividad que puede alcanzar una
sesin antes de que el NAS desconecte
la misma.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/-2./01
A'r!6'# RADIUS
Ser2!d#r
,,,#E
Ser2!d#r
CG!))!s3#'
S!"n!7!cad#
Sim-ltane%-sE/se G G
6l valor num8rico de este par,metro
determina el n5mero de sesiones
simult,neas que se permite para una
cuenta de usuario.
?ISPrE)and@idthE!a8E
/p
G
6l valor en 9its p%r se(-nd% de este
par,metro es el lmite m,7imo de
ancho de banda para -pl%ad.
?ISPrE)and@idthE!a8E
#%@n
G
6l valor en 9its p%r se(-nd% de este
par,metro es el lmite m,7imo de
ancho de banda para d%@nl%ad.
?ISPrESessi%nE
$erminateE$ime
G
6l valor de este par,metro en !ormato
+"Q A=E/, determina el momento en
que se desconectar, a un usuario. Hej:
GEE0K/GKGED/1:EE:EE[EE:EEI
hillisp%tE!a8EInp-tE
Octects
G
6l valor en 94tes de este par,metro
determina que una vez alcanzado ese
lmite de transmisin se desconecta al
usuario.
hillisp%tE!a8EO-tp-tE
Octects
G
6l valor en 94tes de este par,metro
determina que una vez alcanzado ese
lmite de recepcin se desconecta al
usuario.
hillisp%tE!a8E$%talE
Octects
G
6l valor en 94tes de este par,metro
determina que una vez alcanzado ese
lmite, suma de transmisin y de
recepcin, se desconecta al usuario.
Tabla IV.12.: Atributos RADIUS sugeridos para modelar perfiles de conectividad.
%. @ERRAMIENTAS DE ADMINISTRACIN
ara realizar la administracin b,sica del modelo se usan aplicaciones
4eb desarrolladas en lenguaje PHP y de cdigo abierto. 3as dos
aplicaciones que se usan son phpL#APadmin
1
4 dial-p Admin.
1 http://phpldapadmin.sourceforge.net/
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/-;./01
PhpL#APadmin es un navegador L#AP con inter!az 4eb y permite
realizar tareas de administracin sobre un directorio L#AP. )na de las
razones por las que se elige esta herramienta es la capacidad de utilizar
templates o m%ldes de!inidos por el usuario. 6sto permite de!inir m%ldes
que contienen los atributos necesarios para llevar a cabo una tarea
administrativa. $e esta !orma, se simpli!ica la utilizacin y se evitan
errores de carga. or este motivo, se desarrollaron tres m%ldes, uno para
crear los objetos que contienen los per.iles de c%necti7idad: otro para
crear los objetos que de!inen a los usuarios, y uno adicional que permite
de!inir objetos que contienen usuarios de la red inal,mbrica que a su vez
son usuarios de un servidor de correo electrnico.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/-=./01
Ilustracin IV.6.: Molde para crear perfiles de conectividad en phpLDAPadmin.
6n caso necesitarlo, los administradores pueden generar m%ldes
propios que se adapten a las necesidades particulares.
"e puede observar en las +lustraciones +(.= y +(.0 las capturas de
pantalla de dos de los moldes creados. 6n el m%lde para la creacin de
usuarios se puede observar un control c%m9% desplegado que permite
elegir el per.il de c%necti7idad deseado dentro de los e7istentes en el
directorio L#AP.
3a herramienta dial-p admin se distribuye con la aplicacin .reeradi-s
y est, dise%ada para administrar servidores 'A#I/S. rincipalmente se
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/-0./01
Ilustracin IV.7.: Molde para crear usuarios en phpLDAPadmin.
puede usar para obtener reportes sobre el acc%-ntin( o registro de uso y
para administrar a los usuarios que se encuentran conectados.
3as principales limitaciones se encuentran en el hecho de que est,
dise%ada para trabajar con servidores PPP principalmente y que no
di!erencia los atributos obtenidos desde el per!il de conectividad al que
pertenece el usuario de los atributos propios de dicho usuario, lo que
puede resultar en un error, al momento de modi!icar los atributos del
usuario.
"in embargo, se complementa con phpL#APadmin si se utiliza slo
para administrar los registros de uso o acc%-ntin( y obtener in!ormacin
de los usuarios conectados.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/-A./01
Ilustracin IV.8.: Ejemplo de accounting de un usuario con dialup admin.
6n la +lustracin +(.A se puede observar el acc%-ntin( de un usuario en
un perodo de tiempo determinado a trav8s de dial-p admin. 3a di!erencia
en los datos entre los primeros registros y los subsiguientes, obedece a
que dicho usuario se ha conectado a trav8s de mHt%d%s de acces%
di!erentes.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/-1./01
V. RESULTADOS
"e implement un prototipo del modelo de in!raestructura con el objeto
de veri!icar el comportamiento !uncional y el rendimiento comparativo del
mismo.
ara la implementacin del Ser7id%r de A-tenticaci,n se utilizaron
herramientas de virtualizacin
/
, a !in de minimizar los costos de
implementacin del prototipo. ara realizar las pruebas se usaron
di!erentes AP: incluyendo un AP con sistema operativo 3inu7. 3os
modelos de los AP usados son:
6dima7 6OK0GE=AgK&irm4are (=./.
3inPsys O*D"3;2'"K&irm4are 3inu7 M4rt.
A 3inu7 !-lti)SS K +nter!az inal,mbrica Drendnet D6OK
22-+.
Dodos los AP utilizados en el prototipo cumplen con la norma
IEEEAB2.119(.
)na vez que se veri!ic el desempe%o !uncional del prototipo, se
procede con las pruebas de rendimiento. 3as pruebas de rendimiento se
ejecutaron de la siguiente !orma:
"e mont un servidor @e9 en la red interna con un
archivo de imagen ISO de A/ MB.
1 En este caso particular se utiliz VMWare Server. http;//www.vmware.com
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/2E./01
3os clientes de la red inal,mbrica usaron sistema
operativo 3inu7 )buntu 0.E2, M"KOindo4s M, M"KOindo4s (ista
)ltimate, almQ" ;.E2. ara realizar la descarga del archivo
ima(en.is%, en todas las plata!ormas, e7cepto almQ", se us la
aplicacin @(et.
3os valores que se utilizan en la comparacin son
valores promedio de, al menos, tres descargas.
Al virtualizar el ser7id%r de A-tenticaci,n, la velocidad
m,7ima de las inter!aces de red virtuales queda limitada a /E
Mbits, por lo que las pruebas se realizaron en !uncin de este valor.
"e tomaron valores de re!erencia usando las redes
cableadas, tanto para la red interna, como para el Sistema de
#istri9-ci,n.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/2/./01
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/2G./01
Ilustracin V.1.: Sntesis de Resultados de Rendimiento.
6n la +lustracin (./ se puede observar una tabla que ilustra la sntesis
de los resultados obtenidos. $icha tabla est, dividida en tres partes, los
valores de re!erencia obtenidos, los valores obtenidos para las pruebas
realizadas con la norma IEEEAB2.119 y con la norma IEEEAB2.11(. 3as
re!erencias a ?PA en este conte7to, se re!ieren a la implementacin del
modelo propuesto, por lo que deben interpretarse como ?PAEhillisp%t.
"e observa en los valores de re!erencia, tomados a trav8s de una
cone7in 1B)aseE$E+-ll #-ple8, que la in!raestructura propuesta penaliza
la velocidad obtenida en ;; Nb.s .
"e observa tambi8n, que utilizando un acceso inal,mbrico, la menor
velocidad obtenida es el ;-,-EY de la velocidad de re!erencia G,
velocidad m,7ima del Sistema de #istri9-ci,n.
6sto se debe principalmente a que el medio inal,mbrico es
intrnsecamente un medio compartido o hal.Ed-ple8.
6l aumento de la velocidad que se aprecia en las pruebas realizadas
con la norma AB2.11(: con respecto a las pruebas realizadas con la norma
AB2.119: se deben a la incidencia de la velocidad interaccin del
segmento que utiliza el medio compartido inal,mbrico. "i bien la
velocidad de este medio se aumenta un 21EY, se puede observar que la
mejora de velocidad en promedio es del G/,/;Y Hver Dabla (./I.
MF'#d# de Acces# %&$.116 %&$.11" D!7erenc!a
hillisp%t E AP ;1,E2Y A2,0EY $:H<<I
hillisp%t E APLIN/G =1,;2 Y A0,;-Y 1=HDDI
?PA X AP ;-,-EY 0A,=EY $:H1I
?PA X APLIN/G =1,AEY 1E,-2Y $&H:4I
PPP%E X AP ;;,==Y 0=,G-Y $&H:=I
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/2-./01
MF'#d# de Acces# %&$.116 %&$.11" D!7erenc!a
PPP%E X APLIN/G =-,==Y AE,;/Y 1<H%:I
Promedio <1H%1I %$HDDI $1H1:I
Tabla V.1.: Porcentajes comparativos de velocidad entre normas inalmbricas con
respecto a la velocidad mxima del Sistema de Distribucin.
"e aprecia tambi8n, en la Dabla (.G, una di!erencia de velocidad entre
las pruebas realizadas con un AP c%n7enci%nal !rente a un AP
implementad% c%n sistema %perati7% KN/"LIN/G. "i bien esto se debe a
la potencia del hard4are de una computadora !rente al hard4are de un
A, muestra la e!iciencia del sistema operativo respecto a las operaciones
en red, ya que la ganancia de velocidad es en promedio el A,10Y. 3as
principales desventajas de un A3+<)M !rente a un AP c%n7enci%nal: son
mayor costo del hard4are y mayor costo de administracin.
MF'#d# de Acces# A, C#n2enc!#na) A, L!nJ D!7erenc!a
hillisp%t X AB2.119 ;1,E2Y =1,;2Y 1&H:&I
hillisp%t X AB2.11( A2,0EY A0,;-Y $H%1I
?PA X AB2.119 ;-,-EY =1,AEY 1<H:&I
?PA X AB2.11( 0A,=EY 1E,-2Y 11H=4I
PPP%E X AB2.119 ;;,==Y =-,==Y %H&&I
PPP%E X AB2.11( 0=,G0Y AE,;/Y 4H$4I
,r#*ed!# <=HD1I =<HD&I %HD=I
Tabla V.2.: Porcentajes comparativos de velocidad entre AP con respecto a la
velocidad mxima del Sistema de Distribucin.
Al comparar los mHt%d%s de acces% se observa la mayor velocidad del
m8todo que utiliza a hillisp%t: seguido por el m8todo ?PA, !rente al
m8todo PPP%E.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/22./01
%&$.116
CG!))!s3#' 5,A ,,,#E
romedio entre A =2,G1Y =/,;;Y ;1,==Y
%&$.11"
romedio entre A A=,/GY A2,20Y 0A,-1Y
Tabla V.3.: Porcentajes comparativos de velocidad entre mtodos de acceso con
respecto a la velocidad mxima del Sistema de Distribucin.
3os resultados e7puestos en la Dabla (.-, muestran que el m8todo
PPP%E es el m,s lento de los tres propuestos, esto principalmente se
debe a la limitacin de !$/ que surge al encapsular un protocolo de capa
de enlace dentro de otro protocolo de la misma capa.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/2;./01
VI. CONCLUSIONES
)tilizando herramientas de so!t4are libre !ue posible construir un
prototipo del modelo de in!raestructura propuesto. $icho prototipo, brinda
a los administradores de red, un conjunto de herramientas que permiten
representar, aplicar y controlar di!erentes 3#)K'!cas de s# de la red
inal,mbrica. A su vez o!rece a los usuarios m5ltiples !ormas de
conectarse, a trav8s las mismas credenciales.
6l dise%o del modelo de in!raestructura ha mostrado su !le7ibilidad
para poder implementarse tambi8n en ,mbitos privados o p5blicos como
casos particulares y los resultados obtenidos en las mediciones
demuestran un balance entre el rendimiento y la implementacin de
polticas de seguridad, probando la !actibilidad de uso en los escenarios
tpicos de una red inal,mbrica.
6l uso de protocolos libres permite que la in!raestructura que se utiliza
para la implementacin, pueda ser usada simult,neamente por otros
servicios que requieren de autenticacin, disminuyendo el costo total de
propiedad de la in!raestructura de red al no duplicar servicios de
autenticacin.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/2=./01
VII. FUTURAS DIRECCIONES
$esarrollar un metaKlenguaje m,s completo y espec!ico para
los per!iles de conectividad y modi!icar las herramientas para aplicacin
de polticas para implementar el uso de p%lic4 r%-tin(.
Modi!icar el servidor pppd para que ejecute el proceso de
autenticacin con protocolo EAP utilizando un servidor 'A#I/S.
Modi!icar el servidor hillisp%t para usar AB2.11i de !orma
nativa.
Ampliar el soporte de las herramientas de administracin.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/20./01
VIII. A,ANDICES E ENDICES
1. A,ANDICE A; COM,ILACIN DE FREERADIUS ,ARA DEBIAN
ara compilar del paquete .reeradi-sE1.1.3E3 para la distribucin
$ebian "arge -./, es necesario contar con el entorno de compilacin y
descargar el archivo !uente con los parches para $ebian.
$e esta !orma se instalan las dependencias necesarias para poder
compilar el paquete .reeradi-s para $ebian, y se descargan los archivos
!uente de la aplicacin. 3os mismos deber,n ubicarse en el siguiente
directorio "-sr"l%cal"src"de9Esrc".reeradi-s".
)na vez posicionados en el directorio mencionado, se edita el archivo
de9ian"r-les y se comentan las lneas G= y G0:
"e debe eliminar la marca de comentario en lneas GA y G1:
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/2A./01
H apt?&et *)+l6?6ep freera6+)s
H apt?&et +nstall faBeroot l+*ssl?6e8 l+*p<?6e8
H apt?&et so)r%e freera6+)s
Texto VIII.1.: Apndice de compilacin de freeradius.
#*)+l6ssl>??F+t'o)t?rlmNeapNpeap ??F+t'o)t?rlmNeapNtls SF+t'o)t?
rlmNeapNttls ??F+t'o)t?rlmNotp ??F+t'o)t?rlmNs<lNpost&res<l ??
F+t'o)t?snmp
#mo6)lel+st>Br*1 l6ap s<lNmys<l s<lN+o6*%
Texto VIII.3.: Apndice de compilacin de freeradius.
*)+l6ssl>??F+t'?rlmNs<lNpost&res<lNl+*N6+r>Tp&N%onf+& ??l+*6+rT
??F+t'?rlmNs<lNpost&res<lN+n%l)6eN6+r>Tp&N%onf+& ??+n%l)6e6+rT
mo6)lel+st>Br*1 l6ap s<lNmys<l s<lN+o6*% s<lNpost&res<l
Texto VIII.2.: Apndice de compilacin de freeradius.
6n los par,metros con que llama al archivo c%n.i(-re a partir la lnea
;1, se agregan las siguientes opciones :
3uego se edita el archivo de9ian"c%ntr%l y en la seccin )-ildE
#epends6 se agrega li9sslEde7 y li9p(Ede7 y se borra en la secci,n )-ildE
%n.licts6 %n li9sslEde7.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/21./01
.D%onf+&)re U
7(%onffla&s2 U
??pref+:>D)sr U
??e:e%?pref+:>D)sr U
??man6+r>7(man6+r2 U
??sys%onf6+r>Det% U
??l+*6+r>7(l+*6+r2 U
??6ata6+r>D)srDs'are U
??lo%alstate6+r>D8ar U
??F+t'?ra66*6+r>7(ra66*6+r2 U
??F+t'?lo&6+r>D8arDlo&D7(pa%Ba&e2 U
??ena*le?lt6l?+nstall>no ??ena*le?str+%t?6epen6en%+es U
??F+t'?lar&e?f+les ??F+t'?)6pfromto ??F+t'?e6+r U
??ena*le?6e8eloper U
??%onf+&?%a%'e U
7J*)+l6sslM U
??F+t'?system?l+*tool U
%%9it'%ope)ssl%libraries1-usr-lib Q
%%9it'%ope)ssl%i)clu*es1-usr-i)clu*e-ope)ssl
Texto VIII.4.: Apndice de compilacin de freeradius.
()+l6?Depen6s: 6e*'elper (V> 12@ l+*lt6l.?6e8@ l+*pam;&?6e8@
l+*mys<l%l+ent-1?6e8 W l+*mys<l%l+ent?6e8@ l+*&6*m?6e8@
l+*l6ap2?6e8@ l+*sasl2?6e8@ l+*+o6*%2?6e8@ l+*Br*1?6e8@ snmp@
a)totools?6e8@ 6pat%' (V> 22@ l+*perl?6e8@ l+*tool@ 6pB&?6e8 (V>
-.-..-92@ libssl%*e42 libp/%*e4
Texto VIII.5.: Apndice de compilacin de freeradius.
)na vez que se han completado estas tareas se procede a la
creacin del paquete $ebian:
)na vez creados, se puede realizar la instalacin de dichos paquetes y
de los mdulos que se usan con el comando dp&( Ei n%m9reLpa3-ete.
3os paquetes creados contienen los mdulos rlmLeapLGGG
necesarios para usar los protocolos EAPL$LS: EAPL$$LS 4 EAPLPEAP.
C#*3!)ac!+n de 7reerad!s 1.1.<94 c#n De6!an E'cG 4.&
"e incluye esta actualizacin para compilar .reeradi-sV1.1.1E4 en
#e9ian Etch 4.B. Actualmente esta es la 5ltima versin de .reeradi-s, y
para compilarla al estilo $ebian con soporte para 6AKD3", 6AKDD3" y
6AK6A, se deben seguir los pasos que se detallan a continuacin.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/;E./01
# 6pB&?*)+l6pa%Ba&e ?r faBeroot ?)% ?)s
........
Hls ?F ?-
freera6+)s?-.-..D
freera6+)sN-.-..?..6+ff.&5
freera6+)sN-.-..?..6s%
freera6+)sN-.-..?.N+.8/.%'an&es
freera6+)sN-.-..?.N+.8/.6e*
freera6+)sN-.-...or+&.tar.&5
freera6+)s?6+al)pa6m+nN-.-..?.Nall.6e*
freera6+)s?+o6*%N-.-..?.N+.8/.6e*
freera6+)s?Br*1N-.-..?.N+.8/.6e*
freera6+)s?l6apN-.-..?.N+.8/.6e*
freera6+)s?mys<lN-.-..?.N+.8/.6e*
freera6+)s?post&res<lN-.-..?.N+.8/.6e*
Texto VIII.6.: Apndice de compilacin de freeradius.
3os pasos anteriores habr,n desempaquetado los !uentes, aplicado
los parches espec!icos de $ebian y descargado las dependencias
necesarias para compilar esta aplicacin.
"e edita el archivo .reeradi-sE1.1.1"de9ian"r-les 4 alrededor de la lnea
;/, donde se listan los par,metros para ejecutar el archivo c%n.i(-re, se
deber,n borrar las siguientes lneas :
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/;/./01
H%6 D)srDlo%alDsr%D
HF&et
'ttp:DD'ttp.)s.6e*+an.or&D6e*+anDpoolDma+nDfDfreera6+)sDfreera6
+)sN-.-./.or+&.tar.&5
HF&et
'ttp:DD'ttp.)s.6e*+an.or&D6e*+anDpoolDma+nDfDfreera6+)sDfreera6
+)sN-.-./?0.6s%
HF&et
'ttp:DD'ttp.)s.6e*+an.or&D6e*+anDpoolDma+nDfDfreera6+)sDfreera6
+)sN-.-./?0.6+ff.&5
6pB&?so)r%e ?: freera6+)sN-.-./?0.6s%
apt?&et *)+l6?6ep freera6+)s
apt?&et +nstall &%% *+5p2 faBeroot l+*ssl?6e8
Texto VIII.7.: Compilacin freeradius-1.1.6 en Debian 4.0
.D%onf+&)re U
7(%onffla&s2U
....H(orrar las s+&)+entes0
--6it7o/t-rlm:eap:tls ;
--6it7o/t-rlm:eap:ttls ;
--6it7o/t-rlm:eap:peap ;
--6it7o/t-openssl ;
......
Texto VIII.8.: Compilacin freeradius-1.1.6 en Debian 4.0
> en el mismo lugar para reemplazar las lneas borradas se deber,n
colocar las opciones para Qpen""3, como !igura a continuacin:
3as opciones que se han agregado con!iguran las bibliotecas de
OpenSSL necesarias para $LS. 3as opciones que se borran son las que
e7plcitamente en #e9ian desactivan en la compilacin las opciones que
requieren enlazar las bibliotecas de OpenSSL.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/;G./01
.D%onf+&)re U
7(%onffla&s2 U
??pref+:>D)sr U
??e:e%?pref+:>D)sr U
??man6+r>7(man6+r2 U
??sys%onf6+r>Det% U
??l+*6+r>7(l+*6+r2 U
??6ata6+r>D)srDs'are U
??lo%alstate6+r>D8ar U
??F+t'?ra66*6+r>7(ra66*6+r2 U
??F+t'?lo&6+r>D8arDlo&D7(pa%Ba&e2 U
??ena*le?lt6l?+nstall>no ??ena*le?str+%t?6epen6en%+es U
??F+t'?lar&e?f+les ??F+t'?)6pfromto ??F+t'?e6+r U
??ena*le?6e8eloper U
??%onf+&?%a%'e U
??F+t'?system?l+*tool U
??F+t'?rlmNotp U
??F+t'?rlmNs<lNpost&res<lNl+*N6+r>Tp&N%onf+& ??l+*6+rT U
??F+t'?rlmNs<lNpost&res<lN+n%l)6eN6+r>Tp&N%onf+& ??+n%l)6e6+rT
U
HA&re&ar las s+&)+entes op%+ones:
--6it7-openssl ;
--6it7-openssl-li<raries0)/sr)li< ;
--6it7-openssl-incl/des0)/sr)incl/de)openssl
Texto VIII.9.: Compilacin freeradius-1.1.6 en Debian 4.0
3uego de editar estas opciones, se deben comentar algunas lneas
alrededor de la lnea /A0, que veri!ican si se ha realizado la compilacin
enlazando las bibliotecas de Qpen""3, y si es as, lo in!orman y abortan
el proceso.
)na vez salvado el archivo .de9ian"r-les, se debe editar el archivo
de9ian"c%ntr%l y en la seccin )-ilE#epends: se debe a(re(ar: li9sslEde76
*ealizados estos cambios, se procede a la creacin del paquete como
en la versin .reeradi-sE1.1.3.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/;-./01
.....
6'Ns'l+*6eps ?a
=*or pkg in >?s7ell grep @Package de<ian)control A a6k BCprint
>>$DBE F do ;
= i* d7:s7li<deps -p >>pkg -- -O A grep -G li<sslF t7en ;
= ec7o H>>pkg links to opensslH F;
= e8it " F;
= *i F;
=done
6'N+nstall6e* ?a
....
Texto VIII.10.: Compilacin freeradius-1.1.6 en Debian 4.0
So)r%e: freera6+)s
()+l6?Depen6s: 6e*'elper (V> 12@ l+*lt6l.?6e8@ l+*pam;&?6e8@
l+*mys<l%l+ent-1?6e8 W l+*mys<l%l+ent?6e8@ l+*&6*m?6e8@
l+*l6ap2?6e8@ l+*sasl2?6e8@ l+*+o6*%2?6e8@ l+*Br*1?6e8@ snmp@
a)totools?6e8@ 6pat%' (V> 22@ l+*perl?6e8@ l+*tool@ 6pB&?6e8
(V> -.-..-92@ l+*p<?6e8@ l+*snmp?6e8@ li<ssl-de3
Texto VIII.11.: Apndice de compilacin de freeradius.
$. A,ANDICE B; CREACIN DE CA Y CERTIFICADOS ,ARA EA,9
TLS
ara poder utilizar EAPE$LS: a !in de implementar EAPE$$LS % EAPE
PEAP: es necesario crear una A-t%ridad de erti.icaci,n 2A5 y los
certi!icados para el servidor, adicionalmente para utilizar EAPE$LS
solamente se deben crear certi!icados para todos los clientes. Adem,s la
creacin de certi!icados para el servidor ser, necesaria para implementar
un servidor 4eb con soporte SSL.
6s necesario que est8 instalada en el sistema la aplicacin OpenSSL
que brinda las herramientas para realizar estas tareas.
"e empieza realizando las siguientes tareas:
6ste archivo contiene las de!iniciones necesarias para poder crear lso
certi!icados en !ormato PDS12 necesario para M" Oindo4s M y M"
Oindo4s GEE-.
3uego hay que editar el archivo "etc"ssl"%penssl.cn. que contiene los
par,metros de con!iguracin por de!ecto para OpenSSL. 6s conveniente
modi!icar el directorio por de!ecto donde se almacenan los certi!icados y
los datos por de!ecto necesarios para la creacin de los mismos.
Alrededor de la lnea -2, se encuentra una re!erencia al directorio
."dem%A que se reemplaza por ..masterA: y alrededor de la lnea /G-
se encuentra la seccin con los datos por de!ecto para los certi!icados,
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/;2./01
H%6 Det%DsslD
H%p D)srDs'areD6o%Dfreera6+)sDe:amplesD:pe:tens+ons .
Texto VIII.12.: Apndice de OpenSSL
donde en las opciones por de!ecto se deben ingresar los datos de la
organizacin.
)na vez salvado este archivo, se edita "-sr"li9"ssl"misc"A.sh para,
alrededor de la lnea 2G, reemplazar ."dem%A por ."masterA, a !in de
establecer el directorio donde el script crea los archivos de claves y
certi!icados.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/;;./01
........
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
X CAN6efa)lt Y
6+r > .-(aster+ H E'ere e8eryt'+n& +s Bept
%erts > 76+rD%erts H E'ere t'e +ss)e6 %erts are Bept
.......
X re<N6+st+n&)+s'e6Nname Y
%o)ntryName > Co)ntry Name (2 letter %o6e2
%o)ntryNameN6efa)lt > R
%o)ntryNameNm+n > 2
%o)ntryNameNma: > 2
state3r4ro8+n%eName > State or 4ro8+n%e Name (f)ll name2
state3r4ro8+n%eNameN6efa)lt > Me)*o=a
lo%al+tyName > "o%al+ty Name (e&@ %+ty2
;.or&an+5at+onName > 3r&an+5at+on Name (e&@ %ompany2
;.or&an+5at+onNameN6efa)lt > #)i4ersi*a* *e Me)*o=a
H Fe %an 6o t'+s *)t +t +s not nee6e6 normally :?2
H-.or&an+5at+onName > Se%on6 3r&an+5at+on Name (e&@ %ompany2
..........
Texto VIII.13.: Apndice de OpenSSL
)na vez realizadas estas tareas de con!iguracin, se procede a crear
la A y a crear la solicitud de .irma del certi.icad% 2S'5 para el servidor:
> se procede a !irmar y emitir el certi!icado para el servidor con el
siguiente comando:
6n este punto se ha creado el certi!icado ser7erLcert.pem, que se
copia al servidor 'A#I/S.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/;=./01
....
+!O$1.-(aster+
....
Texto VIII.14.: Apndice de OpenSSL
Det%DsslH-usr-lib-ssl-(isc-+.s' %)e9ca
CA %ert+f+%ate f+lename (or enter to %reate2
MaB+n& CA %ert+f+%ate ...
Cenerat+n& a -;20 *+t RSA pr+8ate Bey
.........................................ZZZZZZ
..........ZZZZZZ
Fr+t+n& neF pr+8ate Bey to '.DmasterCADpr+8ateD.D%aBey.pem'
Enter 4EM pass p'rase:
...............
Det%DsslH ope)ssl re/ %)e9 %)o*es %Peyout s er4erIPey.pe( %out
ser4erre/.pe(
Texto VIII.15.: Apndice de OpenSSL
Det%DsslHope)ssl ca %out ser4erIcert.pe( %*ays 1826 %e<te)sio)s
<pser4erIe<t %e<t,ile <pe<te)sio)s %i),iles .-ser4erre/.pe(
Texto VIII.16.: Apndice de OpenSSL
"i bien en este documento slo se tratar,n los requerimientos de
con!iguracin de EAPE$LS mnimos, para -sar EAPEPEAP 4 EAPE$$LS.
"i requiere el uso de certi!icados para los clientes: se pueden generar los
certi!icados para los clientes y e7portarlos a !ormato PDS12 a trav8s del
siguiente script6
3a con!iguracin en las computadoras cliente depender, del sistema
operativo de las mismas, pero en todas se debe importar el certi!icado de
la A: cacert.pem: y la clave del cliente clientL&e4.pem.
ara completar las necesidades de con!iguracin del servidor
'A#I/S, se crean dos archivos adici%nales: dh 4 rand%m6
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/;0./01
HPD*+nD*as'
%6 Det%Dssl
34ENSS">D)srD*+nDopenssl
DA$S>./1
H Sol+%+t)6 6e f+rma 6e %ert+f+%a6o
734ENSS" re< ?neF ?no6es ?Beyo)t 7-NBey.pem ?o)t 7-re<.pem
H F+rma y em+s+[n 6el %ert+f+%a6o
734ENSS" %a ?o)t 7-N%ert.pem ?6ays 7DA$S ?e:tens+ons
:pser8erNe:t ?e:tf+le :pe:tens+ons ?+nf+les .D7-re<.pem
H E:porta%+[n a formato 4=CS-2
734ENSS" pB%s-2 ?no6es ?e:port ?+n 7-N%ert.pem ?+nBey
7-NBey.pem ?o)t 7-N%ert.p-2 ?%l%erts
Texto VIII.17.: Apndice de OpenSSL
Det%DsslH ope)ssl .e)*' RR *'
Det%DsslH ** i,1-*e4-ura)*o( o,1ra)*o( cou)t12
Texto VIII.18.: Apndice de OpenSSL
#omo resultado de estas tareas se obtienen los archivos necesarios
para con!igurar el servidor 'A#I/S con soporte EAPE$$LS 4 EAPEPEAP.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/;A./01
1. A,ANDICE C; COM,ILACIN DE C@ILLIS,OT
3a distribucin estable para #e9ian de hillisp%t es la versin /.E.E,
e7iste una versin de desarrollo, chillisp%tE1.1.B: que agrega las siguientes
opciones de con!iguracin:
radi-snasip6 esta opcin permite especi!icar el valor para
el atributo NASEIPEAddress.
radi-scalled6 esta opcin permite especi!icar el valor del
atributo alledEStati%nEI#, colocando un nombre en vez de la
direccin !A de la inter!az inal,mbrica.
c%n.-sername 4 c%n.pass@%rd6 6stas opciones permiten
que a intervalos regulares se chequee el servidor 'A#I/S, y si en
los atributos devueltos por el servidor e7isten los valores para
-amall%@ed: macall%@ed % inter7al, reemplazan los valores
con!igurados en el archivo de con!iguracin de chillisp%t.
c%n-p 4 c%nd%@n6 6stas opciones permiten especi!icar
dos scripts que se ejecutar,n cuando un cliente se autentique o se
desconecte. A los scripts especi!icados se le envan como
par,metros los valores de varios atributos 'A#I/S.
#omo se necesita utilizar la 5ltima de las opciones nombradas, se
realiza la compilacin al modo #e9ian de la versin /./.E.
$urante el proceso de prueba en la implementacin del prototipo, se
encontr que el dem%ni% chilli: al usar el m8todo de autenticacin ?PA,
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/;1./01
causa una !alla de segmento. 6ste error no se pudo solucionar
modi!icando la con!iguracin.
#omo conclusin, a !in de poder utilizar chillisp%t con ?PA y con las
directivas de con!iguracin c%n-p"c%nd%@n de la versin /./.E, hay que
compilar una versin intermedia.
"e requiere descargar la siguiente versin chillisp%tE2BB1B214.tar.(C.
"e debe editar el archivo de9ian"r-les alrededor de la lnea =;, ya que
e7iste un error de sinta7is, dice nstall en vez de install.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/=E./01
%6 D)srDlo%alDsr%D
F&et 'ttp0--999.c'illispot.or.-c4s-c'illispotI20060214.tar..=
tar ?:85f %'+ll+spotN2;;/;2-0.tar.&5
%6 %'+ll+spot
Texto VIII.19.: Apndice de compilacin de chillispot.
+nstall: *)+l6
6'Ntest6+r
6'Ntestroot
6'N%lean ?B
6'N+nstall6+rs
H A66 'ere %omman6s to +nstall t'e pa%Ba&e +nto
6e*+anD%'+ll+spot.
7(MA=E2 +nstall pref+:>7(C!RD#R2D6e*+anD%'+ll+spotD)sr
# 7ebajo *e esta lH)ea a.re.ar la letra i?e) a=ul@ a )stall.
install ?m /00 ?o root ?& root 6o%D%'+ll+.%onf
7(C!RD#R2D6e*+anD%'+ll+spotDet%D
H ()+l6 ar%'+te%t)re?+n6epen6ent f+les 'ere
Texto VIII.20.: Apndice de compilacin de chillispot.
ara realizar la compilacin del paquete y el empaquetado en !ormato
de9ian se ejecuta el siguiente comando:
#omo resultado se obtiene el archivo instalable en debian
chillisp%tL1.1.BLi3A1.de9. 6sta versin de chillisp%t permite usar el
m8todo de autenticacin ?PA y las directivas de con!iguracin
c%n-p"c%nd%@n, y no causa la !alla de segmento de la versin /./.E. 6n
caso de que se necesite compilar dicha versin, que se puede descargar
desde http6""@@@.chillisp%t.%r("d%@nl%ad"chillisp%tE1.1.B.tar.(C: el
procedimiento a seguir es el mismo.
)na vez que se ha instalado chillisp%t se deber, veri!icar la e7istencia
de un dispositivo tun.tap, que utiliza chillispot.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/=/./01
6pB&?*)+l6pa%Ba&e ?rfaBeroot ?)s ?)%
....
%6 ..
6pB& ?+ %'+ll+spotN-.-.;N+.8/.6e*
Texto VIII.21.: Apndice de compilacin de chillispot.
H ls ?l D6e8DnetD
total ;
%rF?rF?rF? - root root -;@ 2;; 2;;/?;9?-0 22:.1 t)n
Texto VIII.22.: Apndice de compilacin de chillispot.
"i el mismo no e7istiese, se deber, crear de la siguiente !orma:
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/=G./01
H mB6+r D6e8DnetD
H mBno6 D6e8DnetDt)n % -; 2;;
Texto VIII.23.: Apndice de compilacin de chillispot.
4. A,ANDICE D; COM,ILACIN DE R,9,,,OE EN MODO
LERNEL
ara poder compilar el servidor PPP%E con soporte para la opcin E&:
que permite operar en espacio de &ernel, se requiere que el &ernel de
3inu7 se haya compilado con soporte para %E. 3a mayora de los
&ernel nuevos H\G.=.AI est,n compilados con esta opcin. 3os paquetes
#e9ian est,ndar no est,n compilados con esta opcin, por lo que slo se
pueden ejecutar en espacio de usuario.
6s necesario descargar las cabeceras de pppd y los !uentes de rpE
ppp%e6
6n este punto se han descargado los !uentes de rpEppp%eE3.A y los
parches necesarios para compilarlo estilo #e9ian. 6s necesario modi!icar
el archivo de9ian"r-les para indicar la opcin para modo &ernel. Alrededor
de la lnea /E se deber, agregar la siguiente opcin6
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/=-./01
H apt?&et +nstall ppp?6e8
H %6 D)srDlo%alDsr%
H apt?&et so)r%e pppoe
H %6 rp?pppoe?..8D
Texto VIII.24.: Apndice de compilacin de rp-pppoe modo kernel.
*)+l6?stamp:
6'Ntest6+r
H test ?f %onf+&)re WW (a%lo%alR a)to%onf2
test ?f sr%DMaBef+le WW (%6 sr% \\ 444D>D)srDs*+nDppp6
.D%onf+&)re Se)able%plu.i)1-usr-i)clu*e-ppp*2
7(MA=E2 ?C sr%
Texto VIII.25.: Apndice de compilacin de rp-pppoe modo kernel.
6l te7to resaltado indica la ubicacin de las cabeceras pppd
descargadas anteriormente.
)na vez que el archivo se ha salvado, se realiza la compilacin del
mismo y la instalacin:
6s necesario un paso adicional para habilitar el plugin rpEppp%e.s% de
pppd.
#omo resultado de este procedimiento la aplicacin ppp%eKser7er
soporta la opcin E&: para trabajar en espacio de &ernel.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/=2./01
H 6pB&?*)+l6pa%Ba&e ?rfaBeroot ?)% ?)s
.....
H %6 ..
H 6pB& ?+ pppoeN..8?-.-N+.8/.6e*
Texto VIII.26.: Apndice de compilacin de rp-pppoe modo kernel.
H %6 Det%DpppD
H mB6+r pl)&+ns
H %p D)srDl+*Dppp6D2.0.0Drp?pppoe.so Det%DpppDpl)&+nsD
Texto VIII.27.: Apndice de compilacin de rp-pppoe modo kernel.
:. A,ANDICE E; SCRIPTS ,ARA A,LICAR REGLAS DE
CONECTIVIDAD.
A continuacin se detallan los scripts que se utilizan para aplicar las
re(las de cada per.il de c%necti7idad.
6l script @i.iEp%lic4 se observa a continuacin y su !uncin es buscar
en el direct%ri% L#AP las re(las de c%necti7idad asociadas a cada per!il y
con!igurar las tablas de net.ilter a trav8s del comando ipta9les.
HPD*+nD*as'
H F+f+?pol+%y s%r+pt
H
H 6es%r+pt+on: StartDstopDstat)s
H of prof+le r)les of E+f+?4ol+%y
H
H A)t'or: 4a*lo F. Come5 ? pa*lo.&ome5])m.e6).ar
H
H Iers+on -.. ? ;-?;1?;7 ? C'an&es +n start f)n%t+on@
H +n &enerat+on of F+f+?re8.ar&s
H????????????????????????????????????????????????????????
HIers+on -.2 ? .;?;0?;7 ? Some %'an&es +n pop)lat+on
H of 7"#STA@ *e%a)se l6apsear%' %)ts l+nes 8; %'ara%ter
H or more
H????????????????????????????????????????????????????????
H Iers+on -.- ? .;?;0?;7 ? a66e6 l6apsear%' parameter ?S
H????????????????????????????????????????????????????????
H
e:port 4ATG>Ds*+n:D)srDs*+n:D*+n:D)srD*+n
#4TA("ES>Ds*+nD+pta*les
C3NFD#R>D8arDr)nDF+f+
TEM4>KK
REI>KK
SE4>7'U:;A'7'U:2;'
X T+6 ?)T ?e< ; Y WW S!D3>s)6o
6oNstart(2 J
H Sear%' +n "DA4 6+re%tory for f+reFall
H r)les of prof+les
H ()s%o las entra6as en l6ap <)e %ont+enen
H las re&las 6e %a6a prof+le
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/=;./01
"#STATEM4>Tl6apsear%' ?: ?""" ?S %n ?*
o)>4rof+les@6%>)m@6%>e6) 6es%r+pt+on %nT
"#STA>Te%'o K7J"#STATEM4DD7SE4DMK W aFB ?F :
'D^6es%r+pt+on:D J pr+nt 72 M 'T
+f X ?5 7JH"#STAM Y
t'en e%'o KCan't %onta%t "DA4 Ser8er or 4rof+les
r)les are emptyK
ret)rn -
f+
H C'an&e (as' #nternal F+el6 Separator for neFl+ne@
H an6 store t'e or+&+nal 8al)e +n 73"DN#FS
H Cam*+o el #nternal F+el6 Separator 6e (as'@
H &)ar6an6o en 73"DN#FS el 8alor or+&+nal
3"DN#FS>7#FS
#FS>7'U:;A'
H F+f+.ar&s store t'e f+reFall r)les for lo& p)rpose
H F+f+?re8.ar&s store +n8erse ar&)ments for stop
H f)n%t+on )se
H
H
H F+f+.ar&s &)ar6a los ar&)mentos para propos+tos 6e lo&
H F+f+?re8.ar&s &)ar6a los ar&)mentos para re8ert+r
H en el stop
+f X P ?e 7JC3NFD#RM Y
t'en mB6+r 7JC3NFD#RM
f+
+f X P ?e 7JC3NFD#RMDF+f+.ar&s Y
t'en to)%' 7JC3NFD#RMDF+f+.ar&s
else e%'o KM)st stop *efore to start@ try restartK
ret)rn -
f+
+f X P ?e 7JC3NFD#RMDF+f+?re8.ar&s Y
t'en to)%' 7JC3NFD#RMDF+f+?re8.ar&s
else e%'o KM)st stop *efore to start@ try restartK
ret)rn -
f+
e%'o KStart+n& 4rof+les r)les.....K
for f +n Tpr+ntf K7"#STAKTR 6o
e%'o K7fK VV 7JC3NFD#RMDF+f+.ar&s
#FS>73"DN#FS
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/==./01
7S!D3 7#4TA("ES 7f
#FS>7'U:;A'
6one
ta% 7JC3NFD#RMDF+f+.ar&s W se6 ?e 'sD?ND?,D' ?e 'sD?AD?DD' V
7JC3NFD#RMDF+f+?re8.ar&s
#FS>73"DN#FS
ret)rn ;
M
H???????????????????????????????????????????????????????????
?
6oNstop(2 J
+f X P ?e 7JC3NFD#RMDF+f+?re8.ar&s Y
t'en e%'o KM)st start *efore to stopK
ret)rn -
f+
e%'o KStopp+n& 4rof+les R)les...K

H C'an&e (as' #nternal F+el6 Separator for neFl+ne@
H an6 store t'e or+&+nal 8al)e +n 73"DN#FS
H Cam*+o el #nternal F+el6 Separator 6e (as'@ &)ar6an6o
H en 73"DN#FS el 8alor or+&+nal
3"DN#FS>7#FS
#FS>7'U:;A'
"#STA>T%at 7JC3NFD#RMDF+f+?re8.ar&sT
for f +n Tpr+ntf K7"#STAKTR 6o
#FS>73"DN#FS
7S!D3 7#4TA("ES 7f
#FS>7'U:;A'
6one
rm 7JC3NFD#RMDF+f+.ar&s
rm 7JC3NFD#RMDF+f+?re8.ar&s
#FS>73"DN#FS
ret)rn ;
M
H???????????????????????????????????????????????????????????
?
6oNstat)s(2 J
+f X P ?e 7JC3NFD#RMDF+f+.ar&s Y
t'en e%'o K4rof+le R)les Stoppe6K
ret)rn ;
else e%'o K4rof+les R)les Starte6.....K
e%'o KR)les are: K
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/=0./01
%at 7JC3NFD#RMDF+f+.ar&s
f+
ret)rn ;
M
HHH Ma+n
????????????????????????????????????????????????????????????
?
%ase K7-K +n
stop2
6oNstop
RR
start2
6oNstart
RR
restart2
6oNstop
6oNstart
RR
stat)s2
6oNstat)s
RR
_2
e%'o K!sa&e: Det%D+n+t.6DF+f+ JstartWstopW
restartWstat)sMK
RR
esa%
3os servidores que administran los p%%ls de direcciones + din,micas,
cada vez que un cliente se conecta, ejecutan un script que inserta una
regla que vincula la direcin + entregada con el per!il de conectividad de
dicho usuario. $e igual !orma, cuando el cliente se desconecta se borra
la regla correspondiente, a trav8s del mismo mecanismo.
6stas reglas se insertan en la subcadena de!inida por el per!il BBEdirsE
din;micas. $icha s-9cadena est, en la cadena P'E'O/$INK de la tabla
!ANKLE. 3as reglas ?marcan@ los paquetes, de acuerdo al per.il de
c%necti7idad al que pertenece un usuario dado, pero no ?!iltran@ el tr,!ico.
3as reglas que se encargan de ?!iltrar@ el tr,!ico se encuentran en la
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/=A./01
de!inicin de cada per.il de c%necti7idad y se insertan con el script @i.iE
p%lic4.
3os scripts que se observan a continuacin insertan las reglas
correspondientes a las direcciones + din,micas entregadas por el P%rtal
a-ti7%. 6stos se ejecutan al iniciar y !inalizar una cone7in y se
denominan chilli.c%n-p.sh y chilli.c%nd%@n.sh respectivamente. Ambos
se ubican en el directorio "etc"chilli".
Script chilli.c%n-p.sh6
#!/bin/bash
############################################################
# chilli.conup.sh
#
# Script para configurar el parmetro CONUP de Chillispot.
# Especificamente marca cada pauete con el !alor
# del atributo "adius #$%&E"'$( ue determina el
# perfil del usuario
# En s)lo para los (*CP leases ue Chillispot asigna
############################################################
#
# En este caso+ Net,or-+ ./0..12....31.4/0.
# Static Net,or-+ ./0..12..31.4/00
# (5namic Net,or-+ ./0..12..24.4/00
# Chillispot (5namic Net,or-+ ./0..12..20.4/06
############################################################
# 7ersion ... 0284980443
############################################################
$P&:;%ES<=/sbin/iptables=
case =>#":?E('$P':(("ESS= in
./0..12..20@A >$P&:;%ES 8: marca8dinamicas 8t mangle 8s
>#":?E('$P':(("ESS/60 8B ?:"C 88set8mar- >#$%&E"'$(
DD
./0..12..26@A >$P&:;%ES 8: marca8dinamicas 8t mangle 8s
>#":?E('$P':(("ESS/60 8B ?:"C 88set8mar- >#$%&E"'$(
DD
esac
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/=1./01
Script chilli.c%nd%@n.sh6
HPD*+nD*as'
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
H %'+ll+.%on6oFn.s'
HHHHHHHH
H S%r+pt para %onf+&)rar el parOmetro C3ND3EN
H Espe%+f+%amente (3RRA la re&la <)e mar%a %a6a pa<)ete %on
H el atr+*)to Ra6+)s F#"TERN#D <)e 6eterm+na el perf+l 6el
H )s)ar+o
H En s[lo para los DGC4 leases <)e C'+ll+spot as+&na
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
H
H En este %aso: NetForB: -92.-/8.-.-7/.;D2-
H Stat+% NetForB: -92.-/8.-7/.;D22
H Dynam+% NetForB: -92.-/8.-8;.;D22
H C'+ll+spot Dynam+% NetForB: -92.-/8.-82.;D2.
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
H
H Iers+on I.-.- 28?;0?2;;7
HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
H
#4TA("ES>KDs*+nD+pta*lesK
%ase K7FRAMEDN#4NADDRESSK +n
-92.-/8.-82_2 7#4TA("ES ?D mar%a?6+nam+%as ?t man&le ?s
7FRAMEDN#4NADDRESSD.2 ?9 MAR= ??set?marB 7F#"TERN#D
RR
-92.-/8.-8._2 7#4TA("ES ?D mar%a?6+nam+%as ?t man&le ?s
7FRAMEDN#4NADDRESSD.2 ?9 MAR= ??set?marB 7F#"TERN#D
RR
esa%
3os scripts que se observan a continuacin insertan las reglas
correspondientes a las direcciones + din,micas entregadas por el
Ser7id%r PPP%E. 3os mismos se ejecutan al iniciar y !inalizar una
cone7in y se denominan ppp%eEc%n-p y ppp%eEc%nd%@n
respectivamente.
Script "etc"ppp"ipE-p.d"ppp%eEc%n-p6
#!/bin/bash
############################################################
#Script para configurar Politicas de :cceso en PPPoEE
# Especificamente marca cada pauete con el atributo
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/0E./01
# "adius #$%&E"'$( ue determina el perfil del usuario
# En s)lo para los (*CP leases ue PPPoE asigna
############################################################
# En este caso+ Net,or-+ ./0..12....31.4/0.
# Static Net,or-+ ./0..12..31.4/00
# (5namic Net,or-+ ./0..12..24.4/00
# PPPoE (5namic Net,or-+ ./0..12..24.4/06
# Chillispot (5namic Net,or-+ ./0..12..20.4/06
# "euiere de radattr.so plugin
############################################################
# 7ersion ... 0F84380443
############################################################
#
$P&:;%ES<=/sbin/iptables=
#$%&E"'$(<Gcat /!ar/run/radattr.>PPP'$#:CE H a,- I/J#ilter8
$d/ K print >0L IG
case =>PPP'"E?O&E= in
./0..12..24@A >$P&:;%ES 8: marca8dinamicas 8t mangle 8s
>PPP'"E?O&E/60 8B ?:"C 88set8mar- >#$%&E"'$( DD
./0..12..2.@A >$P&:;%ES 8: marca8dinamicas 8t mangle 8s
>PPP'"E?O&E/60 8B ?:"C 88set8mar- >#$%&E"'$( DD
esac
Script "etc"ppp"ipE-p.d"ppp%eEc%nd%@n6
#!/bin/bash
############################################################
# Script para configurar Politicas de :cceso en PPPoEE
# Especificamente marca cada pauete con el atributo
# "adius #$%&E"'$(
# ue determina el perfil del usuario
# En s)lo para los (*CP leases ue PPPoE asigna
############################################################
# En este caso+ Net,or-+ ./0..12....31.4/0.
# Static Net,or-+ ./0..12..31.4/00
# (5namic Net,or-+ ./0..12..24.4/00
# PPPoE (5namic Net,or-+ ./0..12..24.4/06
# Chillispot (5namic Net,or-+ ./0..12..20.4/06
# "euiere de radattr.so plugin
############################################################
# 7ersion ... 0F84380443
############################################################
$P&:;%ES<=/sbin/iptables=
#$%&E"'$(<Gcat /!ar/run/radattr.>PPP'$#:CE H a,- I/J#ilter8
$d/ K print >0L IG
case =>PPP'"E?O&E= in
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/0/./01
./0..12..24@A >$P&:;%ES 8( marca8dinamicas 8t mangle 8s
>PPP'"E?O&E/60 8B ?:"C 88set8mar- >#$%&E"'$( DD
./0..12..2.@A >$P&:;%ES 8( marca8dinamicas 8t mangle 8s
>PPP'"E?O&E/60 8B ?:"C 88set8mar- >#$%&E"'$( DD
esac
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/0G./01
<. A,ANDICE F; ,RUEBAS DE ,,,OE CON CIFRADO M,,E
"i bien es deseable utilizar ci!rado de datos en el m8todo de accesos
PPP%E, se encuentran dos problemas relacionados a la hora de
implementar el ci!rado.
3as pruebas de ci!rado con !PPE 2!icr%s%.t P%intE$%EP%int Encr4pti%n
Pr%t%c%l5CM6F se llevaron a cabo usando en el prototipo del ser7id%r
de a-tenticaci,n el demonio pppdE2.4.4 y clientes con sistema operativo
M"KOindo4s M"G, !SE?ind%@s 2BBB SP4 4 !SE*ista /ltimate.
6n los clientes se desactivo la compresin del tr,!ico, ya que la misma
utiliza el algoritmo !PP 2!icr%s%.t P%intEt%EP%int %mpressi%n Pr%t%c%lI
CM#F, el cual se encuentra protegido con una licencia que impide la
implementacin en so!t4are libre.
"e observo que en la negociacin previa al establecimiento de la
cone7in PPP: en e!ecto, no se utiliza !PP y se acuerda el uso de
!PPE entre el servidor y los clientes.
3a cone7in se establece correctamente, pero cuando el servidor
recibe un paquete, responde con un mensaje /ns-pp%rted pr%t%c%l B8nnn
recei7ed y enva al cliente un mensaje LP Pr%t%c%l 'e<ect. 6l n5mero de
protocolo vara de !orma aleatoria como se ve en el cuadro de De7to
(+++.GA.
"e realiz una prueba recompilando el &ernel del ser7id%r de
a-tenticaci,n aplicando un parche que implementa el al(%ritm% !PP.
$icho parche slo puede aplicarse hasta la versin de Pernel G.=./- y
puede encontrarse en http6""mppeEmppc.alphacr%n.de" .
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/0-./01
6n las pruebas realizadas con Pernel G.=./- y el parche !PP: .ue
posible usar ci.rad% !PPE 4 c%mpresi,n !PP satis!actoriamente.
6l comportamiento observado en las primeras pruebas Hsin usar el
parche !PP5 se podra atribuir a un des!asaje de las cabeceras del
protocolo.
"e decide no usar el parche !PP debido a que impide cumplir con
el objetivo propuesto de usar so!t4are libre y protocolos abiertos en la
implementacin del modelo de in!raestructura. Adem,s, no permite
actualizar el Pernel de KN/"Lin-8 mas all, de la versin G.=./-.
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/02./01
........
r%86 XCC4 ConfNaB +6>;:- `mppe ?G ?M ?S Z" ?D ?CVY
sent XCC4 ConfRe< +6>;:2 `mppe ?G ?M ?S Z" ?D ?CVY
r%86 XCC4 ConfRe< +6>;:7 `mppe ?G ?M ?S Z" ?D ?CVY
sent XCC4 +o),cP +6>;:7 `mppe ?G ?M ?S T5 ?D ?CVY
r%86 XCC4 +o),cP +6>;:2 `mppe ?G ?M ?S T5 ?D ?CVY
M44E 0;?*+t statef)l %ompress+on ena*le6
........
r%86 Xproto>;:09Y .- 8; 6/ *f /9 .2 81 -1 -6 11 2- 0; ;0 67 e7
f* *7 /. e% .9 87 .9 96 1e .- 7- *2 9a .8 e9 7e e- ...
#)supporte* protocol M&erial 7ata !ra)sport $rotocol ?$$$%
&7!$@M ?0<48@ recei4e*
sent X"C4 4rotRe9 +6>;:2 ;; 09 .- 8; 6/ *f /9 .2 81 -1 -6 11 2-
0; ;0 67 e7 f* *7 /. e% .9 87 .9 96 1e .- 7- *2 9a .8 e9 ...Y
r%86 Xproto>;:/a.1Y .* /; 9. 0/ a- f8 /a /e %% *e /% 09 1/ 6.
%/ 8e -% .. f. a2 ae ;a 9a 9. 0f .8 %* ;; a/ *2 ee .% ...
#)supporte* protocol 0<6a36 recei4e*
sent X"C4 4rotRe9 +6>;:. /a .1 .* /; 9. 0/ a- f8 /a /e %% *e /%
09 1/ 6. %/ 8e -% .. f. a2 ae ;a 9a 9. 0f .8 %* ;; a/ *2 ...Y
..........
Texto VIII.28.: Fragmento del log de conexin PPPoE.
$. A,ANDICE G; BIBLIOGRAFEA
GAST00: Matthew Gast; 802.11 Wireless Networks The Definitive Guide, 2005,
ISBN: 0-596-10052-3 .
IEEE80211: IEEE Computer Society; Wireless LAN MAC and PHY specifications,
Junio 2001, www.ieee.org .
IEEE802: IEEE Computer Society; IEEE Standard for Local and Metropolitan Area
Networks: Overview and Arch., Marzo 2002, www.ieee.org .
ISOOSI: ISO; IT-Open Systems Interconnection - Basic Reference Model ISO/IEC
7498-1, Junio 1996, www.iso.org .
IEEE8023: IEEE Computer Society; Carrier sense multiple access with collision
detection access method., Diciembre-2005, www.ieee.org .
IEEE8021X: IEEE Computer Society; IEEE Standards 802.1X Port based Network
Access Control, Junio 2001, .
CHAN00: Praphul Chandra; Bulletproof Wireless Security GSM, UMTS, 802.11
and Ad Hoc Security, 2005, ISBN:0-7506-7746-5 .
EAP: Aboba, B., Blunk, L., Vollbrechtand, J., Carlson, J., y H. Levkowetz;
"Extensible Authentication Protocol (EAP)" - RFC 3748, Junio 2004, www.ietf.org .
PPP: W. Simpson; "The Point-to-Point Protocol (PPP)" - RFC1661, Julio 1994, .
EAP-TLS: B. Aboba, D. Simon; "PPP EAP TLS Authentication Protocol" - RFC
2716, Octubre 1999, www.ietf.org .
EAP-TTLS: Paul Funk, Simon Blake-Wilson; "EAP Tunneled TLS Authentication
Protocol (EAP-TTLS)" Internet-Draft, Julio 2004, www.ietf.org .
PEAP: V.Kamath, A. Palekar, M. Wodrich; "Microsoft's PEAP version 0
(Implementation in Win XPSP1)"- Internet Draft, Octubre 2002, www.ietf.org .
PPPoE: L. Mamakos, K. Lidl, J. Evans, d. Carrel, D. Simone, R. Wheeler; "A
Method for Transmitting PPP Over Ethernet (PPPoE)" - RFC2516, Febrero 1999,
www.ietf.org .
LDAP1: J. Sermersheim; "Lightweight Directory Access Protocol (LDAP): The
Protocol" - RFC4511, Junio 2006, www.ietf.org .
LDAP2: K. Zeilenga; "LDAP : Directory Information Models"-RFC 4512, Junio
2006, www.ietf.org .
RADIUS: C. Rigney, S. Willens, A. Rubens, W.Simpson; "Remote Authentication
Dial In User Service (RADIUS)" - RFC2865, Junio 2000, www.ietf.org .
RADIUSACC: C.Rigney; "RADIUS Accounting" - RFC2866, Junio 2000,
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/0;./01
www.ietf.org .
DRAFT-GPATERNO: Giuseppe Paterno; "Using PPP-over-Ethernet (PPPoE) in
Wireless LANs", Noviembre 2003, www.ietf.org .
MPPE: G. Pall, G. Zorn.; "Microsoft Point-To-Point Encryption (MPPE) Protocol" -
RFC 3078, Marzo 2001, www.ietf.org .
MPPC: G. Pall; "Microsoft Point-To-Point Compression (MPPC) Protocol" - RFC
2118, Marzo 1997, www.ietf.org .
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/0=./01
1. A,ANDICE @; ENDICE DE ILUSTRACIONES
Ilustracin III.1.: Familia de Protocolos IEEE802................................. ...................10
Ilustracin III.2.: Componentes de la Infraestructura Inalmbrica............................16
Ilustracin III.3.: Comparacin entre BSS de Infraestructura y BSS Independiente17
Ilustracin III.4.: Esquema de un Extended Service Set (ESS).................................20
Ilustracin III.5.: Operaciones que lleva a cabo WEP................................... ...........29
Ilustracin III.6.: Formato genrico de los paquetes EAP.........................................34
Ilustracin III.7.: Formato de Paquetes EAP: Solicitud y Respuesta........................35
Ilustracin III.8.: Formato del paquete EAP xito-Falla.................................... .......38
Ilustracin III.9.: Componentes de 802.1X....................................................... .........42
Ilustracin III.10.: Intercambio 802.1X en 802.11. Proceso de Autenticacin..........44
Ilustracin III.11.: Jerarqua de claves 802.11i comparada con WEP.........................47
Ilustracin III.12.: Jerarqua de claves de grupo de 802.11i..................................... ..48
Ilustracin III.13.: Proceso de cifrado de cada paquete en WAP...............................49
Ilustracin III.14.: Proceso de cifrado de cada paquete en 802.11i............................51
Ilustracin III.15.: Marco PPPoE...................................................... .........................53
Ilustracin III.16.: Estructura del paquete RADIUS..................................................61
Ilustracin III.17.: Formato de Transmisin de Atributo RADIUS...........................64
Ilustracin III.18.: Formato de atributos VSA....................................................... .....66
Ilustracin IV.1.: Modelo funcional propuesto................................................. ..........74
Ilustracin IV.2.: Modelo de Infraestructura general propuesto................................75
Ilustracin IV.3.: Bloques Funcionales Implementados del Modelo de
Infraestructura................................................................................ ............................77
Ilustracin IV.4.: rbol LDAP Parcial, Unidad Organizativa Profiles......................91
Ilustracin IV.5.: Proceso de aplicacin de Reglas de Conectividad......................129
Ilustracin IV.6.: Molde para crear perfiles de conectividad en phpLDAPadmin.. 134
Ilustracin IV.7.: Molde para crear usuarios en phpLDAPadmin............................135
Ilustracin IV.8.: Ejemplo de accounting de un usuario con dialup admin.............136
Ilustracin V.1.: Sntesis de Resultados de Rendimiento.........................................139
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/00./01
$. A,ANDICE I; ENDICE DE TABLAS
Tabla III.1.: Bandas de frecuencia comunes en EEUU. ............................................11
Tabla III.2.: Comparacin de las capas fsicas de 802.11..........................................14
Tabla III.3.: Resumen de los Servicios de Red Inalmbrica..................................... .25
Tabla III.4.: Descripcin de los campos del paquete EAP.................................... .....35
Tabla III.5.: Descripcin de los sub campos .................................................... .........36
Tabla III.6.: Cdigos de tipo de uso comn en EAP........................................ ..........37
Tabla III.7.: Objetivos de los mtodos de autenticacin en redes inalmbricas........39
Tabla III.8.: Comparacin entre las falencias de WEP y las soluciones de
WPA/WPA2...................................................................................................... ..........52
Tabla III.9.: Significado de los campos del marco PPPoE........................................54
Tabla III.10.: Fases de Descubrimiento de PPPoE........................................... ..........54
Tabla III.11.: Descripcin de los campos de un paquete RADIUS............................61
Tabla III.12.: Descripcin del formato de transmisin de los atributos RADIUS.. . .65
Tabla IV.1.: Soporte Nativo de WPA y WPA2 de los Sistemas Operativos Microsoft
* el fabricante del dispositivo puede proveer software para dar soporte a WPA o
WPA2. 1 Slo provee soporte para 802.1X (fuente:
http://www.microsoft.com/technet/network/wifi/wififaq.mspx#EGAAE Actualizado
a Abril 2007.) ............................................................................................... .............71
Tabla IV.2.: Esquema de direccionamiento IP propuesto para prototipo..................88
Tabla IV.3.: Parmetros de configuracin del mdulo LDAP...................................98
Tabla IV.4.: Directivas de configuracin de mdulo MSChap en freeradius............99
Tabla IV.5.: Directivas de configuracin del mdulo EAP, EAP-MD5 y EAP-TLS.
..................................................................................................... .............................103
Tabla IV.6.: Directivas de configuracin del mdulo EAP-TTLS, EAP-PEAP y
EAP-MSCHAPv2......................................................................................... ............105
Tabla IV.7.: Directivas de configuracin RADIUS en Chillispot............................116
Tabla IV.8.: Directivas de configuracin UAM en Chillispot.................................117
Tabla IV.9.: Parmetros relevantes para iniciar servidor PPPoE.............................122
Tabla IV.10.: Directivas de configuracin relevantes de pppd. (/etc/ppp/options). .123
Tabla IV.11.: Ejemplo de asignacin de direcciones IP a perfiles de conectividad.128
Tabla IV.12.: Atributos RADIUS sugeridos para modelar perfiles de conectividad.
....................................................................................................... ...........................133
Tabla V.1.: Porcentajes comparativos de velocidad entre normas inalmbricas con
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/0A./01
respecto a la velocidad mxima del Sistema de Distribucin..................................140
Tabla V.2.: Porcentajes comparativos de velocidad entre AP con respecto a la
velocidad mxima del Sistema de Distribucin.................................. .....................141
Tabla V.3.: Porcentajes comparativos de velocidad entre mtodos de acceso con
respecto a la velocidad mxima del Sistema de Distribucin..................................141
Arquitectura )ni!icada para #ontrol de Acceso en *edes +nal,mbricas "eguras
ablo &. 'mez (ergara
/01./01

Vous aimerez peut-être aussi