¿Dónde implementaremos Bitlocker? Uno de los problemas que se nos plantea cuando decidamos implementar Bitlocker, es cual es el escenario previsible en el que podemos implementarlo y como será la forma idónea para realizarlo. Evidentemente cuando decidimos por la implementación de un mecanismo de seguridad como el cifrado deberemos tener presente si es necesario el mismo o para que lo vamos a hacer, si esta es una máquina convencional usada solamente como soporte de aplicaciones pero no almacenamos en ella ningún dato de interés. Supongamos los equipos estándar de una empresa. Estos por regla general son utilizados solo como soporte para la ejecución de las aplicaciones, ya que los datos importantes de la empresa se encuentran almacenados en un servidor bien resguardado en el CPD (o así debería ser…) Habrá que tener presente también los elementos adicionales que pudieran quedar almacenados en la máquina que por comodidad pudiéramos dejar almacenados, tales como contraseñas de navegación, de aplicaciones enmascaradas por los dichosos asteriscos, los correos, etc. Cual importante es esta información en manos de alguien que busca datos de nuestra empresa, implicaría prever la opción para el cifrado de estos discos. Una de las mejoras que nos reporta el sistema de Bitlocker en máquinas coexistiendo en un Dominio, es que los mecanismos para la recuperación de las contraseñas, obtienen ventaja de las funcionalidades aportadas por el Directorio Activo. Si la circunstancia la evaluamos desde el punto de vista de una persona que viaja muy a menudo, con un portátil que parece ya una extensión más de su propio cuerpo (alguno se sentirá identificado seguramente), el hecho de tenerlo cifrado sería una opción más que interesante, máxime cuando puedan llevar informes de clientes, datos de la empresa, etc. Un eventual robo o pérdida, solo significaría precisamente eso: el robo o la pérdida, pero pasaría a un significativo segundo plano los datos que portaran. La implementación dependerá fundamentalmente si el dispositivo presenta o no Chip TPM. Si no lo lleva la única opción posible es el uso del almacenamiento de la clave en un USB (cuidado donde lo llevamos no sea que se rían de nosotros). ¿Y el usuario doméstico? Salvo para algunos casos significativos, resulta evidente que este método no será el empleado en los hogares, principalmente porque la orientación de los sistemas operativos de índole doméstico no portan esta funcionalidad. Un elemento previsible aunque negativo, es que este sistema pudiera dificultar elementos para el análisis de un equipo donde es requerido determinar si desde él, se ha cometido un posible delito. Y en todos estos posibles escenarios, ¿tengo que equiparme con un nuevo PC, para soportar la infraestructura de Bitlocker? La respuesta es NO, aunque podremos obtener mejoras significativas si optamos por utilizar un equipo que cuente con el Chip TPM. Para todos aquellos que desean utilizar el cifrado y no poseen el Chip, encontramos una directiva de seguridad bajo la cual podemos condicionar el uso de Bitlocker sin el citado Chip. Por defecto el sistema solo admite la configuración de Bitlocker si el equipo cuenta con el Chip. Configuración de Bitlocker sin TPM en Vista Para utilizar Bitlocker sin TPM Imagen 2: Configuración Bitlocker sin TPM Referencias Externas —————————————————————- – Bitlocker I: Seguro más allá de su uso – Bitlocker II: La Concienciáción para la seguridad de los discos
Mes: febrero 2007
La protección contra Desbordamientos de Buffer en Windows Vista (III de IV)
Tercera Protección: No ejecución de Datos
—————————————————————-
DEP (Data Execution Prevention) Bit NX (Non Execute)
—————————————————————-
La tecnología DEP está disponible en Windows XP SP2, Windows Server SP1, Windows Server 2003 R2 y además viene incluida también en Windows Vista y puede aplicarse tanto por Software como por Hardware. ¿Qué quiere decir que puede aplicarse por Hardware o por Software? ¿Funcionan igual?
DEP por Hardware
Para activar DEP por hardware es necesario que el microprocesador que estemos utilizando venga con esta característica, ya que éste es un avance tecnológico de la industria de microprocesadores que es aprovechada por los sistemas operativos. El objetivo es evitar que un programa pueda ser inyectado en un sistema por medio de un desbordamiento de buffer. Para ello se dividen, en tiempo de ejecución, las páginas de la memoria en dos clases: Paginas de ejecución en las que se cargarán los procesos o páginas de NO ejecución donde se van a almacenar datos y/o parámetros de llamada a procedimientos. Para realizar esto las páginas de memoria llevan asociadas un NX (Non eXecute) que indica si se puede ejecutar lo que esté allí o sí por el contrario, nada que esté almacenado en esa zona de memoria puede ser ejecutado.
El realizar esta división y marcado de las páginas permite, que, aunque se produzca un desbordamiento de buffer, este nunca podrá ser utilizado para inyectar un código a través de un parámetro, con lo cual estamos garantizando que el sistema no ejecuta nada que no esté ya introducido previamente.
Imagen 1: Desbordamiento de Buffer
Aplicar DEP por hardware previene que se pueda introducir código inyectado, si el contador de programa se quedara apuntando a una zona de memoria marcada como NX el sistema intentaría recuperarse y si no pudiera se produciría una parada. Debido a esto, es posible que ciertas aplicaciones, que utilicen la inyección de código como forma normal de trabajar dejen de funcionar correctamente No es una práctica correcta de desarrollo pero en algunos casos se utiliza. Para intentar garantizar la compatibilidad de aplicaciones de este tipo se pueden crear listas blancas en Windows Vista.
DEP por Software
Como protección adicional, DEP en Windows Vista, tiene una versión basada solo en software que vino ya en XP SP2 y cuyo objetivo es garantizar la integridad de las funciones que son invocadas en el tratamiento de los mensajes de excepciones que deben ser gestionados por el sistema operativo. Para ello se comprueba la integridad de los binarios del sistema que se encargan del tratamiento de los mensajes de error.
—————————————————————-
/SafeSEH (Safe Exception Handler)
—————————————————————-
Esta es una opción del linkador que se puede usar en Visual C++ para poder comprobar, de forma segura, que las funciones de tratamiento de excepciones de un determinado programa son las correctas. Para ello el ejecutable lleva almacenada la tabla de las funciones con las referencias a las funciones que deben procesar cada uno de los mensajes de excepción. El sistema operativo comprobará si el manejador de esa excepción corresponde con el que marca el programa en la tabla de manejadores y si no es así, matará el proceso. Estas opciones son utilizadas en conjunción de la protección DEP por software.
Configuración en Vista
Para configurar las opciones de DEP en Windows Vista deberemos acceder a la opción de configuración en:
- Panel de Control
- Sistema y Mantenimiento
- Sistema
- Configuración Avanzada
- Avanzadas
- Opciones de Rendimiento
- Data Execution Prevention
Tras una petición de Microsoft y en concreto de Michael Howard, todos los equipos que vendrán con Windows Vista en versión OEM vendrán por defecto con DEP Activado.
Imagen 2: Prevención de Ejecución de Datos
Referencias Externas
—————————————————————-
– DEP en Windows XP SP2 en Technet
– Data Excution Prevention en
Bueno, ya sólo queda un post más para terminar esta serie en el que veremos las técnicas de Ofuscación de Punteros a Funciones y la tecnología ASLR (Address Space Layout Randomization).
La protección contra Desbordamientos de Buffer en Windows Vista (II de IV)
¿Como podemos proteger Windows Vista contra los desbordamiento de buffers? Esto es algo que se lleva estudiando largo tiempo, por ello existen diferentes aproximaciones. La primera de ellas es una respuesta bastante sencilla. Utilizar técnicas de prevención.
Primera protección: Prevención
——————————————————————————————-
Herramientas de Análisis Estático de Código. FxCod
El objetivo es que si todos los parámetros están bien controlados y no se pasan a la pila de memoria sin haber comprobado correctamente su longitud no tendríamos desbordamientos de buffer, luego intentemos que no salga ningún programa sin haber sido correctamente evaluado. Para ello se utilizan desde hace tiempo las herramientas de Análisis Estático de Código realizan un chequeo del código del programa mientras este no se está ejecutando, buscando patrones de fallos de seguridad (incluidos los desbordamientos de buffer) en códigos en ensamblador, código fuente o código manejado. FxCod es una herramienta de análisis de estático de código manejado que se puede utilizar en todos los desarrollos que se realizan con Visual Studio 2005. Es una herramienta que permite detectar, no solo desbordamientos de buffer, si no un amplio abanico de fallos de seguridad en las aplicaciones. Todo programa debe estar comprobado para evitar desbordamiento de buffers. Una de las características importantes es que estas herramientas se pueden usar para validar la fiabilidad y seguridad de un software. Microsoft, para las versiones de Windows Vista de 64 bits ya para Longhorn obliga a que los drivers que se instalen en el sistema operativo vayan firmados por Microsoft o una compañía autorizada. Para conseguir la firma del driver es necesario pasar unos test de seguridad que evalúan con herramientas de análisis estático el código del driver.
Imagen: Opciones de Análisis de Código en Visual Studio.
Segunda Protección: Detección
Los Canarios y la opción /GS
Una de las ideas, propuesta por uno de los grandes expertos de la seguridad, Crispin Cowan, fue utilizar lo que el denomina canarios. Los canarios son utilizados en las minas y en las cocinas de gas, para detectar gases nocivos, si el canario muere, algo malo sucede. En el caso de los desbordamientos de Buffer esta es una idea similar. Consiste en apilar unos determinados valores en la pila de llamada al procedimiento justo después de apilar la dirección de retorno. Cuando se va a pasar el control a esa dirección de retorno, se comprueba previamente si los valores en los canarios son los correctos. Si no lo son, hemos de asumir que se ha producido una violación de la zona de memoria. Se llama Stack-Smashing Protecction. El uso de estas tecnologías no garantiza que los parámetros no sufran de desbordamiento de buffer, pues se pueden sobrescribir, no la dirección de retorno, pero sí, el resto de estructuras y, si el atacante puede descubrir el valor de la dirección de memoria o del canario, puede intentar simular un canario correcto. Para ello, se usan canarios no predecibles.
En Visual Studio la opción del compilador de comprobación de seguridad del búfer de Visual C++ se llama /GS. El funcionamiento de la opción /GS consiste en establecer un valor cifrado (a veces denominado «chivato») al final de un búfer. Este valor se comprueba durante la ejecución del código y si ha cambiado, se detiene la ejecución del programa y se genera una excepción de seguridad. La opción /GS no evita la saturación del búfer, pero protege contra el posible secuestro del código al detener la ejecución del programa.
Bueno, continuaremos la semana que viene, con DEP.
Referencias
– Herramientas de Análisis de Código Estático
– Mejoras de Seguridad en Visual Studio 2005
Vista y hardware antiguo
Bueno ahora si, aquí estamos, uniéndonos al blog. Después de unas semanas de intenso trabajo por fin he conseguido tener unos minutos libres en fin de semana (aquí se curra hasta los fines de semana, jeje) para empezar mi serie de artículos sobre Windows Vista.
Pues me gustaría comenzar con dos experiencias que he podido realizar durante la última semana. La primera es que el otro día instalé Vista Ultimate en mi viejo portátil. Un Compaq Presario 512 MB RAM PIV 2.0 Ghz y disco duro de 40 GB. Pues bien, os tengo que confesar que va como un tiro. Increíble, casi mejor que con el Windows XP que traía originalmente y que el fabricante carga con mil programas que nunca se usan. Ahora tengo a mi niña (así llamo a mi mujer) usando Windows Vista en su portátil (ha pasado a su propiedad, no sé cómo ni cuándo pero ahora es suyo). Es la primera de sus amigas en usarlo y dice que no le ha costado nada aprender la nueva interfaz y menús (siempre es bueno contar con la opinión de un usuario no informático).
Por supuesto, no están habilitadas las funcionalidades de Aero, pero el sistema operativo se ha adaptado muy bien a las limitaciones de hardware y realmente no sientes un menor rendimiento con respecto a Windows XP. Si he notado que hay un mayor uso de memoria, alrededor de un 60 %, comparado con un 35 % que habitualmente utilizaba XP. Pero esto no ha provocado una carga más lenta de las aplicaciones. Parece que superfech está haciendo su trabajo.
Me gustaría destacar la mejora sustancial de tiempo de recuperación del sistema después de una hibernación. Yo soy usuario habitual de la hibernación, me permite reiniciar mi trabajo en el punto en donde lo dejé y además de una forma muy rápida. Pero Windows Vista en este equipo que os comento tarda menos en iniciar el sistema desde la hibernación que mi actual portátil con 2 GB de RAM y procesador de doble núcleo. Para dar datos exactos, XP presenta la pantalla de inicio de sesión en 65 seg. mientras que Vista lo hace en 22 seg.
Con respecto a los dispositivos, Windows Vista reconoció todos menos el audio, pero no fue problema porque desde Windows Update se descargó los controladores necesarios una vez se inició el equipo por primera vez. Y todo esto con un portátil que tiene más de 4 años.
Así que quien os diga que Vista no va a correr en equipos de más de dos años, enviadlos hacia este blog.
Mi segunda experiencia fue el despliegue de Vista en 16 equipos simultáneamente desde una máquina virtual Windows Server 2003 R2 con 300 MB de RAM, utilizando BDD 2007 y WDS. En menos de una hora estaban los 16 equipos instalados y personalizados.
Pero esto os lo comento en mi próximo post….
SuperFetch (I de IV)
El motivo de este BLOG es desgranar Windows Vista, dar a conocer sus nuevas
características, funcionalidades y tecnologías de manera que como profesional
dedicado al tema no he podido evitar poner mi granito de arena y mis
conocimientos técnicos ante este proyecto al servicio de todos aquellos que
deseen leernos y aprender más acerca del nuevo sistema operativo de Microsoft.
Por todo ello quizás la mejor manera de empezar este POST es daros las gracias a
todos por dedicarnos algo de vuestro tiempo.
Cuando tuve que decidir el tema a tratar en este BLOG pensé en un principio
algún tema de seguridad, sin embargo teniendo en el equipo a dos expertos MVP
en seguridad hubiera sido un error privar a dichos expertos (Chema y Juan Luís)
de atender dichos temas con el valor añadido de toda su experiencia, amplios
conocimientos y por qué no, repertorio de anécdotas. Así que he decidido probar
suerte con otro de los pilares de Windows Vista junto con la seguridad: el
rendimiento. Concretamente en estos días hablaré sobre el nuevo gestor de
memoria de Windows Vista: SuperFetch.
Mucha gente le tiene miedo al uso o consumo de la memoria: es un recurso
caro, limitado y en ocasiones con una capacidad de expansión escasa, y además,
y quizás el elemento más importante de esta ecuación, se encuentra una de las
leyendas urbanas más difundidas en el mundo de la informática: “cuanto más
consumo de memoria, peor rendimiento”, algo que como veremos no siempre es
cierto, y menos aun si hablamos de Windows Vista. La polémica está servida por
tanto cuando Windows Vista recomienda como mínimo 1GB de RAM, nuestra mente nos
engaña surcada por la siguiente deducción: “Si Sistema Operativo recomienda 1GB
de RAM como mínimo significa que dispondremos de menos espacio en memoria para
nuestras aplicaciones con la consiguiente reducción del rendimiento, aumento
del uso de la memoria virtual, lectura del disco duro etc.”. Por supuesto mucho
técnico no informado y sin conocimiento de causa se echa las manos a la cabeza
y alardea de la poca memoria que consume su distribución de linux, un ejemplo
de este debate lo encontramos en el siguiente POST del Blog de elladodelmal:
http://elladodelmal.blogspot.com/2006/11/expertos-no-tecnico-less.html
Pero la respuesta es fácil: si la principal ventaja de
lectura/escritura es muy superior a la de un disco duro, ¿no es lógico pensar
que cuanta más información de los programas que vayamos a utilizar tengamos en
memoria mejor será el rendimiento? ¿Y si además de lo anterior añadimos que
algo fuera capaz de predecir qué vamos a ejecutar en cada momento y cargará
previamente la información de esos programas en memoria? Bien, pues ese algo es
SuperFetch, un proceso de bajo consumo que gracias a sus capacidades
predictivas mejora el rendimiento de nuestro sistema y el tiempo que tardan en
abrirse nuestras aplicaciones basándose en nuestras propias pautas de
comportamiento (a veces es de agradecer que el ser humano sea un animal de
costumbres).
En próximos POST iremos desgranando esta tecnología y otras relacionadas
con el fin de obtener una visión general de las mejoras de rendimiento de
Windows Vista y para desterrar para siempre aquellos falsos rumores que
pudieran circular sobre los requisitos y la optimización de este nuevo sistema
operativo, mientras tanto y si queréis ir alimentando vuestra curiosidad os
dejo el enlace oficial de Microsoft sobre las nuevas características de rendimiento
de Vista.
Control de Cuentas de Usuario
UAC – Control de cuentas de usuario es la tecnología que Microsoft ha incorporado en su nuevo sistema operativo Windows Vista. Es una tecnología revolucionaria que nos va a ayudar a mejorar la seguridad de nuestros sistemas. Esta nueva tecnología proporciona al sistema el complemento que le faltaba para cumplir con el principio del menor número de privilegios posibles. Ahora solo falta esperar y ponerlo a prueba, para comprobar si al final aporta tantos beneficios como está empezando a demostrar. El objetivo principal de UAC es minimizar el número de ataques que cada día más sufren nuestros sistemas y proteger el equipo ante los usuarios (amenaza en ocasiones más peligrosa que cualquier malware). Para proteger el sistema y la información almacenada en el mismo, esta nueva tecnología realiza una reducción automática de los privilegios de todos los usuarios, convirtiéndolos en usuarios estándar por defecto. ¿Pero que ocurre cuando el sistema necesita de permisos superiores? El sistema notificará al usuario que la tarea que desea realizar (ya sea ejecutar una aplicación o realizar cambios sobre la configuración del sistema) necesita de privilegios superiores y requiere de su aceptación. Si el usuario acepta el incremento de permisos la tarea podrá realizarse, en caso contrario, la tarea se finalizará. De este modo conseguimos que cualquier ejecución de las aplicaciones se haga de forma segura para el sistema. En definitiva, consigue que el trabajo diario de los usuarios, incluidos los administradores, no supongan un riesgo para nuestros equipos. Para aquellos pocos administradores que tenían dos cuentas de usuario en el sistema, una con privilegios y otra sin ellos (que digo pocos………… casi ninguno), se acabo la tortura de tener que estar lanzando las tareas administrativas mediante el comando runas. En definitiva, UAC sustituye a runas, con el fin de hacerlo más sencillo para el usuario y mejorandolo hacia los nuevos avances que requiere cualquier sistema operativo en la actualidad. En los siguientes post iremos ahondando cada vez en esta fascinante tecnología que nos va a proporcionar un gran control de lo que realizan nuestras aplicaciones en el sistema.
.jpg)