[MUSIC] Hola, ¿qué tal? Bienvenida o bienvenido a este entrenamiento de Aruba Network Secure Essential. Mi nombre es Ricardo Cobos, y en este vÃdeo hablaré de métodos de autenticación para acceder a la red. Sin embargo, debemos partir de entender por qué se requiere autenticar a los usuarios cuando se conectan a la red. La razón por la cual esto se requiere, es porque queremos tener la certeza de que la red, sus recursos y los servicios. Están siendo utilizados para actividades autorizadas. Y que bajo ninguna causa o razón los usuarios están haciendo actividades maliciosas. Es obviamente uno de los primeros puntos y factores que debemos considerar cuando hablamos de seguridad en la red. Eso nos lleva a algo conocido como zero trust network. Nosotros debemos asumir implicitamente que no se confÃa en los clientes que se conectan a la red hasta que su identidad es validada. Y esto es precisamente el proceso de autenticación. Una vez que los clientes se autentiquen, nosotros estamos realmente validando su identidad. Y no es solamente con nombres de usuario y contraseña. Hay otros factores que pueden ser considerados para tener una autenticación satisfactoria. Por ejemplo, conectarse con un dispositivo adecuado. Y hay otros factores adicionales, como la hora del dÃa, la ubicación, el método de acceso, inalámbrico versus cableado. Los atributos de la cuenta con la cual el usuario se está autenticando, etc. Una vez que todos estos factores han sido considerados, y la autenticación fue satisfactoria. Entonces podemos pasar al siguiente paso, que es autorización. Donde nosotros podemos controlar la actividad de estos usuarios. No solamente validar sus credenciales y saber que se están conectando con el dispositivo adecuado. Sino también colocar filtros que solamente permitan el tráfico que este usuario requiere generar para poder realizar sus actividades diarias. En otras palabras, habrá cierto tráfico que es autorizado, cierto tráfico que no; y el que no será implicitamente denegado. Para poder poner esto en práctica, se requieren varios elementos. El primero, obviamente, es una infraestructura capaz de soportar autenticación, you sea switches y mobility controllers. Después, requerimos una base de datos donde se encuentren las cuentas del usuario. Y donde se puedan también procesar atributos adicionales o información contextual de la cual dependa si vamos a permitir o no el acceso. Y finalmente, necesitamos controles y filtros que, en el caso de la solución y la infraestructura de Aruba, se va a hacer con roles de usuario o user roles. Estos user roles contienen polÃticas que son nada más que un conjunto de reglas que dice qué tráfico está y no permitido. Basado en varios aspectos, no solamente dirección IP de origen y destino, o puertos TCP y UDP de origen y destino. Sino también el protocolo mismo de la capa de aplicación. Y esto se puede realizar a través del firewall de los mobility controllers basados en ArubaOS. Estos controles de movilidad, como tú you sabes, tienen un firewall interno que pueden realmente analizar ese tráfico. Juntando esos tres elementos, ahora sà podemos implementar autenticación y control de acceso adecuado en la red. El primer método de autenticación del cual hablaré será portal cautivo. Portal cautivo es un método muy conveniente, porque le permite a usuarios ajenos a la red. Que no tienen relación de confianza alguna con tus servidores o con la red misma, autenticarse y validar sus credenciales. Esto es algo que normalmente usamos para invitados, para contratistas. Y la manera en la que funciona es, en el momento en que ellos se conectan a la red, you sea a través de un cable o a través de una red Wi-Fi abierta. Automáticamente se les dará un estado no autenticado.. Y con este estado ellos podrán obtener direcciones IPs, realizar resoluciones de DNS, y posiblemente generar tráfico web. Sin embargo, el tráfico web que ellos generen va a ser redirigido para una solución de guest, a una solución de autenticación de portal cautivo. En el caso de Aruba, nosotros tenemos Clearpass que viene con el módulo del mismo nombre, módulo guest. Y ese módulo permite la presentación de portales cautivos para que los usuarios se autentiquen. También les permite a ellos generar sus propias cuentas. Podemos utilizar branding, podemos utilizar o hacer marketing, ahà hay varias funcionalidades, social networking, etc. El punto es que la redirección del tráfico web va a ir hacia este portal. Y en ese momento, cuando el usuario escriba las credenciales con las cuales se quiere autenticar o genera su cuenta. De alguna manera este portal web le dirá a su navegador que vuelva a envÃar las credenciales. Pero ahora que se las envÃe o facilite al dispositivo de red, en este caso el mobility controller. Las credenciales van a ir hacia ese mobility controller sin que el mismo usuario lo sepa. Es una actividad que va a ser realizada por el navegador. Y después el mobility controller enviará la solicitud de autentificación oficial hacia la base de datos, o especÃficamente el servidor RADIUS. El servidor RADIUS va a analizar estas credenciales, y finalmente dirá al mobility controller, bueno, el usuario fue aprobado. Su autentificación fue satisfactoria. Y nosotros podemos, a través de ese mensaje, enviar vendor specific attributes. Que le indiquen al mobility controller cuál es la VLAN, cuál es la lista de control de acceso. O mejor aún, y muy conveniente en el caso de las soluciones y productos Aruba, cuál es el rol de usuario que se le debe asignar. El cual, obviamente, en este caso será un rol de invitados. Que le permitirá el acceso libre de tráfico web a Internet, correo, resoluciones de DNS, algunos aplicativos como Skype, Facebook, etc. Muy bien, you con eso, el usuario tendrá libre acceso y nosotros podremos en todo momento validar cuál es la actividad del usuario. Cuánto tráfico ha generado, saber si sigue conectado o no a la red, y poner restricciones adicionales en un futuro si asà lo deseamos. Eso es para usuarios invitados. Sin embargo, ¿qué ocurre, por ejemplo, con dispositivos IoT o impresoras, o dispositivos viejos que a los cuales nosotros también debemos autenticar? Sin embargo, ellos no tienen la capacidad de ofrecer credenciales de ningún modo. Ellos no soportan autenticación web y tampoco soportan autenticación via 802.1X. En ese caso, lo que podemos hacer es una autenticación via MAC. Eso quiere decir que el dispositivo simplemente enviará tráfico, y este tráfico contendrá una dirección MAC de origen. La cual le pertenece al adaptador de red del equipo. Esa dirección MAC de origen, que you está siendo identificada, va a ser ocupada como el nombre de usuario y contraseña para un RADIUS Access-Request. Un mensaje de solicitud de autenticación de RADIUS que va hacia el servidor, y el servidor validará esa dirección MAC. Y después, si esta fue una dirección que se encuentra en una base de datos. Entonces el servidor contestará con RADIUS Access-Accept y posiblemente algún atributo. Para colocar el dispositivo en algún rol de usuario en especÃfico. Este método de autenticación no se ocupa, generalmente, para equipos de cómputo, como están mostrando aquÃ. Es algo que nosotros utilizamos para impresoras, cámaras de vigilancia, sensores, IoT en general. Sin embargo, bueno, la ventaja es obviamente que no se requiere un setup inicial en ese equipo. Pero las desventajas, es que, obviamente, la dirección MAC puede ser fácilmente copiada y utilizada por otro usuario malicioso. Es por eso que este método de autenticación lo combinamos con profiling. Donde se realiza un análisis del tráfico que este dispositivo está generando. Con lo cual podemos categorizarlo dentro de diferentes tipos. Por ejemplo, impresoras, cámaras, sensores, IoT, no lo sé, access points mismos, etc. Cualquier tipo de dispositivo que no pudiera autenticarse por sà solo, le podrÃamos hacer profiling. Y utilizando la validación de su dirección MAC junto con la categorización en una clasificación en especÃfico, nosotros podrÃamos tener certeza. Bueno, la impresora con esta dirección MAC, que me pertenece, realmente se está comportando como impresora. Con lo cual es poco probable que alguien haya robado esta dirección MAC y la esté utilizando para autentificarse. Y por consecuencia, puedo tener la certeza de que el equipo le permitiré el acceso a la red. Muy bien, este es el segundo método, y el tercer método, y el último, es 802.1X. Esto es algo de lo cual se ha platicado you en algunas ocasiones, o lo hemos mencionado en algunos videos de esta serie. El método de autenticación 802.1X es más bien un framework. Es un framework que utiliza varios componentes, algoritmos de cifrado, métodos de autenticación o protocolos de autenticación. Estado inicial de bloqueo en la red hasta que el usuario se autentique. Entonces, son varios componentes que vamos a englobar, y los cuales nos ofrecerán la seguridad que nosotros requerimos. Requiere que el cliente se autentique utilizando algo que nosotros llamamos supplicant. El cliente va a tener un supplicant, que es prácticamente un software instalado. Esos you vienen hoy en dÃa como parte del sistema operativo. Y en este supplicant nosotros vamos a preconfigurar cuáles son las credenciales con las cuales queremos que el cliente se autentique. Entonces, este es el primer dispositivo. El segundo dispositivo o el segundo rol que 802.1X utiliza es el authenticator. Que es el dispositivo de red que va a bloquear el acceso hasta que las credenciales hayan sido validadas. Y por último, tenemos un tercer elemento, un tercer rol, que es el authentiction server, que en este caso serÃa el servidor de RADIUS. Lo que ocurre, en este caso, es que cuando el cliente se conectan a la red y la conexión levanta en capa 2. El authenticator va a bloquear todo tipo de acceso excepto una forma especÃfica de frames. Frames de capa 2 que contengan EAP como el payload. ¿Que es EAP? EAP significa Extensible Authentication Protocol, y es básicamente el protocolo de autenticación que 802.1X va a utilizar. Cuando el cliente se conecta, va a enviar un mensaje de EAP start para decirle al authenticator, comencemos con la autenticación. El authenticator va a enviar un challenge, donde básicamente se le pregunta al supplicant, okay, ofréceme tu nombre de usuario. Él envÃa ese mensaje o ese nombre de usuario, y el nombre de usuario no es realmente procesado por el authenticator, el switch o el mobility controller. Sino que es reenviado al servidor de RADIUS en forma de un RADIUS Access-Request, sÃ, aquà tenemos realmente el username. Como mencioné hace un momento, lo voy a colocar aquÃ, tendrÃamos el EAP start y después el EAP challenge. ¿Vale? Y cuando el usuario manda su username, este se incluye en el RADIUS Access-Request hacia el servidor de RADIUS. Y después hay un intercambio de mensajes entre los dos, entre el supplicant y el authentification server, de 14 a 18 mensajes en total. Donde you de alguna manera se genera un túnel seguro utilizando certificados digitales por parte del servidor de RADIUS, por lo menos. Y después el usuario enviará su certificado digital o nombre de usuario y contraseña. Al final, la validación se completará en este tipo de comunicación o en este flujo de mensajes. Y el servidor de RADIUS finalizará con un RADIUS Access-Accept o un reject. Y si envÃa un accept hacia el authenticator, este accept obviamente contendrá vendor-specific atributes con, por ejemplo, información sobre el user role. aruba-user-role = empleado. Básicamente, esto es la manera en la que 802.1X funciona, y cómo funciona en especÃfico utilizando atributos de Aruba. Este es un mensaje que irÃa hacia el authenticator. Y al final, el servidor de RADIUS también le notificará al cliente con algo que nosotros llamamos EAP success. Muy bien, entonces este es básicamente el proceso que se realiza con 802.1X. Autentica al cliente con credenciales individuales, soporta una gran variedad de credenciales, como you mencioné. El cliente puede autenticarse con nombre de usuario y contraseña, certificados digitales, etc., y es la opción más segura. Pero obviamente requiere que el cliente esté preconfigurado. En cuanto a los métodos de EAP que se pueden ocupar, o sea, el protocolo de autenticación mismo. Bueno, hay diferentes variantes, diferentes sabores, tenemos EAP-TLS, Protected EAP, EAP TTLS, EAP-Tunneled EAP. Existen varias opciones, todas ellas requieren que por lo menos el servidor de autenticación tenga un certificado digital. Eso es importante mencionarlo, ¿sÃ? El servidor requiere un certificado digital en cada uno de esos casos. Y después, dependiendo del método de EAP. Esto you nos dirá si el cliente también necesita un certificado o solamente utilizar nombre de usuario y contraseña, etc. Entre todas estas, uno de los métodos más recomendados es EAP-TLS.. Porque requiere certificados digitales en los dos, tanto cliente como el servidor de autenticación. La razón por la cual el servidor de autenticación tiene que dar su certificado. Es porque, primero, el cliente quiere tener la certeza de que está hablando con un servidor de autenticación autorizado. Es, por ejemplo, cuando vas manejando en carretera y te detiene un oficial de tránsito, y el te pide tus credenciales. Tú, muy firmemente, también le puedes decir a él, primero muéstreme usted su identificación y pruebe que usted es un oficial de tránsito autorizado. Y después yo le daré mi licencia. Es básicamente algo similar. El servidor de autenticación ofrece su certificado primero, y una vez que el cliente o el supplicant lo recibe lo puede validar. Y si todo está en orden, si está firmado por una autoridad certificador de confianza. Si tiene el common name o el subject authority name que tú esperabas. Se encuentra dentro de un perÃodo de tiempo válido, etc., etc., etc. Entonces, you el cliente podrÃa empezar a ofrecer su certificado o su nombre de usuario y contraseña, etc. Muy bien, hay otros detalles relacionados con 802.1X. Sin embargo, esta explicación, de manera general, transmite los conceptos y explica cómo funciona. Asà como muestra cuáles son las ventajas sobre los otros métodos. En este caso, primero vamos a validar las credenciales del usuario antes de darle cualquier tipo de acceso. Opuesto a portal cautivo, por ejemplo, donde el cliente primero debe recibir una dirección IP y poder realizar resoluciones de DNS. Eso quiere decir que, mientras que con portal cautivo al cliente se le permite generar cierto tráfico, en el caso de 802.1X esto no sucede. El supplicant no puede obtener una dirección IP y tampoco puede generar otro tipo de tráfico que no sea el de la autenticación. Y bueno, si comparamos 802.1X con MAC authentication, las ventajas son evidentes. Mientras que con MAC authentication solamente tenemos una dirección MAC. Que podrÃa ser maliciosamente utilizada, a través del proceso de spoofing, por otro usuario malicioso. Con 802.1X esto no es posible porque lo que estamos haciendo es autenticando al cliente. Con información que un usuario malicioso no podrÃa obtener fácilmente. Los cuales son certificados y nombre de usuario y contraseña. Y bueno, con esto termino el video, espero qué haya sido de tu agrado, te veo en el siguiente. [MUSIC]
