Está en la página 1de 2

Captive Portal para la autenticacin de HotSpot

En algunas circunstancias, los protocolos para proteger el capa 2 de la red inalmbrica, como WPA o WPA2 no son aplicables porque no son fciles de configurar para los usuarios finales si el servicio de ayuda est disponible. Por otra parte, puede utilizar estos protocolos slo si el hardware (puntos de acceso y tarjetas de red) y los sistemas operativos de apoyo. En otros casos, es necesario proteger no slo los accesos mviles, pero los cables tambin. La solucin a estos problemas se pueden mover el control de los accesos de la Capa 2 (Capa de enlace de datos) y Capa 3 de la red, por ejemplo, mediante un Portal Cautivo. Con esta tcnica el usuario tiene que introducir sus credenciales (usuario y contrasea o certificado electrnico) en su navegador para ser autorizados a utilizar la red. Portal Cautivo consiste en una puerta de enlace que es el router por defecto para la subred de proteger. Tales bloques de puerta de enlace IP de los paquetes destinados hacia el exterior y captura las peticiones http y https en los puertos TCP 80 y 443 a volver a dirigir a un servidor web (denominado servidor de autenticacin) que muestran al usuario una pgina de autenticacin. Si el usuario introduzca las credenciales correctas, se comunica el servidor de autenticacin para la puerta de entrada que el host del usuario est autorizado y la puerta de entrada hacia delante los paquetes fuera de la red de proteccin. ZeroShell implementa un captive portal en forma nativa, sin necesidad de utilizar otros programas como NoCatAuth, NoCatSplash o Chillispot. Las principales caractersticas del portal cautivo de ZeroShell se describen a continuacin:

Que permite hacer una estructura multigateway en el que un nico servidor de autenticacin puede proporcionar autenticacin weblogin a ms de puerta de enlace. El servidor de autenticacin y la puerta de enlace pueden coexistir en el mismo equipo; La puerta de enlace pueden trabajar ya sea en modo enrutado o en el modo de bridge (o modo transparente): o En modo enrutado la puerta de enlace debe ser necesariamente el router por defecto para la subred protegida por el portal cautivo. De esta manera solo los paquetes IP pueden ser enviados desde una red a la otra si la autenticacin ocurre correctamente, mientras que los otros protocolos que se encapsulan directamente en la capa 2, como IPX, AppleTalk, NetBEUI y el nivel 2 de broadcast quedan aislados; o En modo Bridge en su lugar, la puerta de enlace en cautividad funciona como bridge entre dos o ms interfaces (tambin VPN sitio a sitio) de los cuales uno protegerse de weblogin. Con esta modalidad cualquier tipo de protocolo y de difusin de la lata se transmitir cuando la autenticacin se realiza correctamente. En el modo bridge (o modo transparente) de la red protegida se puede compartir con el resto de la LAN de la subred, el router por defecto y el servidor de DHCP que permite que un cliente tenga siempre la misma direccin IP en el rea protegida y en la red sin proteccin; El portal cautivo puede ser activado para proteger tambin 802.1Q VLAN vez que una interfaz de red completa; Todas las interacciones entre el navegador web del usuario y el servidor de autenticacin se cifran https utilizando para evitar que las credenciales se pueden capturar en la red; Los clientes son identificados por sus direcciones IP y MAC. Sin embargo, estos dos parmetros pueden ser fcilmente falsificados. Con el fin de resolver el problema ms tarde, la puerta de enlace en cautividad requiere que el navegador web del usuario tienen un autenticador , que es un mensaje cifrado generada por el servidor de autenticacin y que peridicamente tiene que ser renovado y se enva a la pasarela. El

autenticador se cifra utilizando el algoritmo de cifrado AES256 y no pueden ser fcilmente falsificados antes de su expiracin. La validez del autenticador se puede configurar por el administrador. Tenga en cuenta que la gestin del autenticador es transparente para el usuario final del portal cautivo que poda pasar por alto su presencia. La autenticacin del servidor es capaz de validar las credenciales de los usuarios que utilizan la base de datos local de Kerberos 5, un externo KDC Kerberos 5 y cruzar la autenticacin entre los dominios Kerberos V. Tenga en cuenta que, de dominio de Windows los usuarios de Active Directory se Kerberos 5 autenticado y por lo tanto se puede autorizar a utilizar la red con web de inicio de sesin autenticado con el KDC de Active Directory. El usuario tiene la posibilidad de elegir el dominio correcto (o reino) seleccionndolo de una lista en la pgina de acceso web, o usando un nombre de usuario de la forma usuario@dominio. Partir de la versin 1.0.beta6 de ZeroShell, el Portal Cautivo es capaz de autenticar a los usuarios mediante el uso de servidores RADIUS externos y certificados X.509. La ltima caracterstica permite utilizar las SmartCard para el inicio de sesin de red con Portal Cautivo. Es posible declarar una lista de clientes libres para los que no se requiere autenticacin; Es posible definir una lista de servicios gratuitos proporcionados por servidores externos que los clientes pueden utilizar sin necesidad de autenticacin; La pgina de acceso web y el lenguaje a utilizar durante la fase de autenticacin se puede configurar por el administrador; Despus de la autenticacin, aparece una ventana emergente al usuario para garantizar la renovacin del autenticador y le permitan obligar a una solicitud de desconexin haciendo clic en un botn. ZeroShell utiliza tcnicas especiales para evitar que los sistemas anti-popup, que estn presentes en la mayora de los navegadores, bloque de esta ventana que causa una desconexin prematura debido a la expiracin del autenticador;

En las prximas versiones de la contabilidad (accounting) ser administrado y permitir conocer la duracin y el trfico de la conexin de un usuario.

También podría gustarte