Windows Vista e Infraestructura Wireless I

¿Qué tal? Antes de iniciar esta serie sobre
redes WiFi y Windows Vista es de recibo que sepamos de qué estamos hablando. En
un breve pero intenso articulo haremos un repaso a como ha ido evolucionando la
seguridad de las redes inalámbricas y como podemos protegerlas ante los ataques
externos.

Al principio el IEEE diseño un estándar para
comunicaciones WiFi al que nombro 802.11. Para hacerlo tan seguro “como una conexión por cable
desarrollaron un protocolo de autentificación al que llamaron WEP (Wired Equivalent
Privacy) y que al principio pareció funcionar bien, pero claro, solo al
principio…

WEP usa un sistema de cifrado de tipo RC4,
con claves de 40 o 104 bits, que sumados a los 24 bits del vector de
inicialización (IV) dan unas longitudes de clave de 64 o 128 bits. Esto en los
años en los que se publico la especificación (1997) y con el hardware
disponible en aquella época, era considerado seguro, pero en la actualizad, y
usando técnicas para intensificar el envío de paquetes en la red, es posible
crackear una de estas claves en menos de 15 minutos, aunque con técnicas
recientes se ha conseguido reducir este tiempo a solamente 60 segundos. Es por
eso que no vamos a dedicarle mucho más tiempo al tema de la encriptación
mediante WEP, considerándola insegura, insuficiente y desfasada en comparación
con las actuales técnicas de encriptación como son WPA y WPA2.

Cuando la industria de fabricantes de
dispositivos WiFi se dio cuenta de los riesgos que presentaba para sus clientes
la debilidad de WEP se puso en marcha para desarrollar un sistema de
encriptación que permitiese asegurar las comunicaciones. Bajo el auspicio de la
Wi-Fi Alliance, que agrupa a empresas tan importantes como Cisco, AT&T o HP,
se desarrollo un nuevo sistema de seguridad al que llamaron WPA (Wi-Fi
Protected Access) que lanzaron en el 2003, adelantándose en un año al IEEE
802.11i (o WPA2).

¿Qué ventajas trae este nuevo protocolo de
encriptación frente a WEP? Pues para empezar nos proporciona dos maneras
distintas de autenticarnos, la primera como en WEP, con una clave compartida,
la segunda, contra un servidor de autentificación IEEE 802.1X, con encriptación
basada en EAP o, mediante un servidor RADIUS, con EAP-TLS.

En el caso de la autenticación por clave
compartida (o WPA-Personal), aunque siguen
haciendo uso del cifrado RC4 (con clave de 128 bits y IVs de 48 bits), se usa
un sistema de TKIP (Temporal Key Integrity Protocol) que nos permite asegurar
nuestra red de una forma mucho mas consistente, haciendo que cada paquete
enviado vaya encriptado de forma única. Por otro lado, la autenticación contra
el servidor de autenticación IEEE802.1X (WPA-Enterprise),
nos proporciona una clave única para cada usuario, haciendo más difícil si cabe
el crackeo de la red.

¿Y que diferencia hay con la WPA2? Pues
básicamente dos. La primera es que se modifica el sistema de protección de TKIP
por otro aun mas seguro, el CCMP, basado en el algoritmo de encriptación AES.
La segunda y no menos importante es que este ya si es un estándar de la IEEE y
que la Wi-Fi Alliance marca como requisito indispensable para los nuevos
dispositivos inalámbricos para lograr el reconocimiento de Wi-Fi Certified, con
lo que eso nos garantiza para una red de mediana o gran empresa.

Bueno, todo esto esta muy bien, pero ¿como
nos afecta esto a la red esa que queremos montar en nuestra empresa y por la
que van a viajar datos confidenciales de clientes? La respuesta es simple. Para
empezar hay que descartar de raíz la autentificación WEP, es insegura por
definición y no debe de ser usada en ningún tipo de entorno. Luego llegamos a
la disyuntiva entre WPA y WPA2. En este caso, aunque la diferencia no es tan
abismal como cuando hablamos de WEP, debemos decantarnos por WPA2 en la medida
de lo posible, pues la encriptación de los paquetes ofrece mayor seguridad.
Para terminar, la elección entre Personal o Enterprise va a venir definida por
el número de personas que se conectaran a nuestra red. En el caso de una red
domestica o una pequeña empresa, con una clave compartida no bastara, pero si
tenemos un gran grupo de usuarios con necesidad de conectarse a nuestra red lo
mejor será decantarse por un servidor RADIUS de autenticación y configurar los
ordenadores clientes para conectarse usando este.

Todas estas tecnologías vienen soportadas de base
por Windows Vista y en el próximo artículo veremos como configurar nuestro
ordenador para que se conecte a una red con autenticación WPA2-Enterprise.

¡Un saludo y hasta pronto!
 

Referencias Externas 

 —————————————————————-

 

Wifi

 

WPA Enterprise

 

Controla tus ActiveX en Windows Vista

Hola a tod@s!


Este post lo quiero dedicar a una característica de Internet Explorer que me ha llamado mucho la atención en Windows Vista. La capacidad para controlar los ActiveX en nuestra empresa.


Antiguamente no existían las amenazas que tenemos hoy en día, y los desktops en nuestra empresa podían trabajar sin la necesidad de una securización total. También es sabido que hoy en día casi toda la comunicación e iteración entre el usuario e Internet pasa por el navegador. Y todas las pistas nos llevan a deducir que esto irá a más.


Internet Explorer es el navegador por excelencia en el ámbito corporativo. Tiene multitud de funciones y características de seguridad que hacen a este navegador único en la empresa. Por un lado para estar totalmente integrado con la infraestructura de la empresa, y por otro lado, su capacidad para securizarlo y adaptarlo a las necesidades de la empresa, siempre y cuando no se navegue bajo una cuenta administrativa, y partiendo de la base de que el equipo cumple con el principio del mínimo privilegio.


En versiones Windows 2000 y Windows XP, lo teníamos todo, excepto la capacidad de controlar aquellos ActiveX que sí necesitamos en nuestra empresa.


Un control ActiveX no es más que código ejecutable empacado en un archivo (generalmente con extensión .cab) que el usuario puede invocar e instalar desde Internet Explorer. Es una gran característica que se inventó para hacernos la vida un poco más fácil, permitiendo a los desarrolladores poder distribuir más fácilmente sus herramientas, pero que ha terminado (en la mayoría de los casos), en volvernos locos a más de uno.


Os pongo un caso curioso y personal. No hace mucho me encomendaron la labor de migrar una plataforma de trabajo (poco menos de 1000 desktops), de sus privilegios actuales (la mayoría administradores), a una plataforma que cumpliese con el principio del mínimo privilegio.


La migración duró un tiempo, y salvo algún que otro problema (siempre los hay J), todo fue como la seda. Hasta que llegamos a los ActiveX.


Debido al gran auge de ataques bajo controles ActiveX, nos planteamos una seria duda. Un control ActiveX, en la mayoría de los casos (99%) ha de instalarse bajo una cuenta administrativa. Si estábamos realizando la labor de llevar a la empresa a cumplir con el principio del mínimo privilegio…. Qué hacer?


No todos los ActiveX son dañinos. Tenemos el ActiveX de Adobe, el de Windows Installer para las actualizaciones de Windows, y, a parte, la empresa disponía de un antivirus corporativo que era actualizable a través de la Intranet, pero para realizar este trabajo necesitaba la instalación en el cliente de un control ActiveX. También disponía de Terminal Services for Web, y éste también necesitaba controles ActiveX.


Así que dimos con una solución que, si bien no era la mejor, era la que más se adecuaba a las circunstancias. El departamento Help-Desk instalaba esos controles ActiveX cuando el equipo se montaba de 0, pero bajo ningún concepto se le daban permisos de Administrador al usuario (a no ser que fuese el jefe J).


Como podréis observar, a día de hoy necesitábamos una solución mejor para la distribución de Desktops corporativos, ya que algún día, vamos a necesitar que sea nuestro usuario el que pueda instalarse esos ActiveX sin necesidad de ser Administrador. Eso reduciría la carga administrativa, y a la vez dotaría de dinamismo la actividad laboral entre usuario y departamento Help-Desk. Hoy en día hay aplicaciones de Intranet que necesitan esos controles ActiveX, aparte de las aplicaciones mencionadas antes.


En Windows Vista han pensado en esto (y muchas otras cosas más) y han lanzado un servicio llamado AXIS (Servicio Instalador ActiveX), el cual no es más que un servicio a nivel de políticas de grupo, que habilita esta función precisamente. El tener una White List o lista blanca en donde podamos poner las direcciones Web en las que sabemos con certeza que sus ActiveX no contienen código dañino.


La política tiene un funcionamiento muy sencillo y práctico. Para activar la política, nos dirigiremos a Panel de Control à Programas à Activar o desactivar características de Windows.


Una vez aceptado el aviso de UAC, activaremos la opción Servicio de instalador de ActiveX, el cual preparará nuestro Vista para este tipo de acciones. Una vez activada la característica, procederemos a crear nuestra White List o lista blanca de aplicaciones Web que necesiten instalar ActiveX en nuestros Desktops corporativos.


El segundo paso a realizar, consiste en iniciar la herramienta de políticas de grupo gpedit.msc.


Una vez allí, procederemos a ir a la ruta siguiente:

Configuración de equipo à Plantillas administrativas à Componentes de Windows à Servicio del instalador de ActiveX

Como podréis comprobar, la directiva aún no está aplicada, por lo que cualquier usuario con privilegios administrativos podría instalar cualquier ActiveX, venga firmado o no.


Una cosa que me gustaría remarcar, es que habilitando esta característica correctamente, habilitaremos a un usuario sin ningún tipo de privilegios, instalar controles ActiveX autorizados por nosotros, los administradores. Como podréis comprobar, la directiva se va a aplicar desde configuración de equipo, y no de usuario, así que será la cuenta de equipo quien instalará estos ActiveX permitidos.

 ActiveXWhiteList   Una vez habilitada la directiva, tendremos que introducir en una lista, las direcciones Web  que queremos permitir.   WhiteList 

 

Necesitaremos ambos valores y/o campos para establecer la directiva. En el primer campo estableceremos cual es la aplicación Web que va a necesitar de ese privilegio de instalación para su correcto funcionamiento.El segundo parámetro son una serie de controles para los diferentes estados de un ActiveX, que nos ayudarán a establecer cómo se va a comportar ese ActiveX, a la hora de descarga e instalación. Por defecto tendremos estos estados de ActiveX y por este orden se asignará la directiva: 


  • TPSControlFirmado


  • Control Firmado


  • Control sin firmar


  • Política de Certificado
Y para estos campos, tendremos unos valores, los cuales son los siguientes:0.- El control ActiveX no se instalará1.- Se pedirá confirmación del usuario (tal y como hasta ahora)2.- El control ActiveX se instalará en modo silenciosoPor motivos de seguridad, para los controles sin firmar no existe el valor 2. Tan sólo está disponible el valor 0 y 1.

 


WhiteList


 


Gracias a esta nueva manera de instalación de controles ActiveX en Windows Vista, podemos mantener el mínimo privilegio posible en nuestros Desktops, sin despreciar para nada la potencia de un ActiveX.


Me dejo en el tintero la referencia a los logs que deja este tipo de configuraciones, pero lo dejo para un par de post que tengo en mente sobre Logs en Windows Vista, que sé que a los que le gustan los análisis forenses como a mí les va a resultar entretenido.  


Espero que os haya molado!

Saludos!