Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Control de Cuentas de Usuario (I de VI)
************************************************************************************************
- Control de Cuentas de Usuario (I de VI)
- Control de Cuentas de Usuario (II de VI)
- Control de Cuentas de Usuario (III de VI)
- Control de Cuentas de Usuario (IV de VI)
- Control de Cuentas de Usuario (V de VI)
- Control de Cuentas de Usuario (VI de VI)
************************************************************************************************
El User Account Control [UAC] o Control de Cuentas de Usuario, es una de las mejores funcionalidades que trae Windows para proteger los privilegios de los administradores y, sin embargo, es de las que más pena me da escuchar a hablar. Informáticos de pro hablando mal de esta característica, técnicos de sistemas malentendiendo su funcionamiento, cayendo en el chascarrillo fácil y la simplificación de la tecnología. Me apena y me entristece. Durante esta gira de Lanzamiento de Windows 7 he tenido la suerte de poder explicar un poco en detalle cómo funciona el UAC en Windows Vista y en Windows 7 y, tras haber sido la sesión mejor valorada de toda la gira, creo que por lo menos me llevo la satisfacción de haber explicado un poco más esta funcionalidad.
Sin embargo, durante la ejecución de la gira, mi amigo “Pajarraco” de los Santos decidió, tras llevar alrededor de cuatro meses usando Windows, escribir los que para mí son los peores artículos que ha escrito él en mucho tiempo en Una-al-día, sobre todo cuando él mismo tiene una visión favorable a UAC que no veo bien reflejada en sus artículos.
Vaya por delante que Una-al-día ha sido mi mentora y tutora en el mundo de la seguridad informática, y que, tras alrededor de 10 años suscrito a la newsletter soy capaz, casi con total éxito de reconocer un texto de Bernardo Quintero, Antonio Ropero, Laboratorioman y “Pajarraco” de los Santos solo con leer el primer párrafo, algunas hasta con el título.
Sin embargo, los artículos del UAC escritos por “Pajarraco” reflejan un punto de vista con respecto al UAC totalmente desprovisto de los tecnicismos y las arduas explicaciones técnicas. Los dos primeros me parecen directamente mal explicados, mal comparados con las tecnologías de otros sistemas operativos e incluso menospreciantes en los conceptos novedosos que en sí que aporta UAC.
El tercero, tras largas conversaciones telefónicas entre él y yo, “Pajarraco” sabe perfectamente que le voy a llamar después de escribir algo así, publicó una tercera parte en la que intentaba matizar algunos detalles para aquellos que como yo no lo veíamos tan claro, como la aplicación del principio del Mínimo Privilegio Posible, algo, que guía la construcción de UAC desde su inicio y que intentar explicar esta tecnología sin hablar de él es imposible o erróneo.
- Mitos y leyendas: UAC, ese gran incomprendido I (Introducción)
- Mitos y leyendas: UAC, ese gran incomprendido II (UAC de forma útil)
- Mitos y leyendas: UAC, ese gran incomprendido III (UAC y la ley del mínimo privilegio)
Sin más preámbulo, y si ya te has leído la serie de artículos sobre UAC que escribió mi amigo “Pajarraco” de los Santos, vamos a empezar con esta serie.
Fortificar u Optimizar
Siempre que intento explicar este concepto me gusta hablar de la diferencia entre Optimizar y Fortificar un sistema. Son dos procesos que muchas veces nos caen a los consultores informáticos y que tienen dos aproximaciones de trabajo totalmente diferentes.
La optimización no es un proceso que se pueda hacer de fábrica, no es algo que pueda venir out-of-the-box. El método de optimización debe generar los mejores parámetros de configuración de un sistema para conseguir el máximo rendimiento pero éstos siempre van a depender de la carga y uso que se le dé al sistema. Es por eso que de fábrica los equipos vienen con unos parámetros por defectos pensados para ser los que mejor funcionan en la mayoría de los casos. Nada más instalar un Windows Vista o un Windows 7 ponerse a tocar servicios y valores va en contra de su rendimiento y muchos de los que intentan tunearlo al igual que se hacía con Windows XP suelen cepillarse el rendimiento del sistema más que arreglarlo. Sólo se puede optimizar un sistema después de un análisis de la carga de trabajo del mismo y para ello Windows Vista y Windows 7 ya traen sus mecanismos.
La fortificación, por el contrario, es un proceso que depende del rol del sistema. El rol a un sistema se le asigna antes de ponerlo en producción por lo que la Fortificación sí es un proceso que puede hacerse antes. Así, los sistemas Microsoft, por defecto, desde la TCI, aplican la fortificación por defecto y es labor del administrador del sistema configurar los roles y bajar los controles de seguridad lo justo y necesario para que funcione el rol que va a recibir este sistema.
Decía Andrew S. Tanenbaum que la única manera de tener un sistema seguro es metiéndolo dentro de una caja fuerte y tirando la llave dentro y esa es más o menos la idea de la fortificación, sólo que hemos de abrir la caja fuerte un poco, pincharle un cable de red y dejar que entre y salga el tráfico justo para que cumpla con sus funciones.
Principios de la Foritificación de Sistemas
Para ello se aplican tres principios fundamentales:
- Defensa en Profundidad [DP]: Este axioma dice que un sistema debe aplicar tantas medidas de seguridad como sea posible teniendo en cuenta que las medidas de seguridad de las capas adyacentes pueden haber sido comprometidas siempre y cuando la aplicación de una medida no anule la aplicación de otra y que el sistema siga ofertando su servicio. Si pones un IDS de red y luego cifras con IPSEC una medida de seguridad ha sido anulada y sería un mal diseño de defensa en profundidad. Si pones muchas medidas de seguridad y resulta que no se cumplen los objetivos del servicio, es decir, el servicio se ve deteriorado en sus principios básicos, tampoco será una opción viable. Por último, en un mundo ideal no hay dinero o este es del monopoli, pero en la realidad la aplicación de la regla de Defensa en profundidad se verá afectada también por la pasta que se tenga.
- Mínimo Punto de Exposición [MPE]: Un sistema debe ejecutar sólo y exclusivamente los componentes necesarios para el cumplimiento funcional de su rol. Es decir, es de cajón que un servidor, si no necesita dar servicio de Webdav no tiene porque tener este servicio en ejecución, ni publicado a internet y ni aceptar peticiones. Así, cuando se pone en producción una máquina hay que ver cuáles son sus roles y cuáles los componentes que se necesitan. Desde Windows Server 2003 R2 todos los servidores de Microsoft son role-oriented.
- Mínimo Privilegio Posible [MPP]: Cada uno de los componentes necesarios para la ejecución de un rol debe ejecutarse con el número de privilegios justos para ello. No menos, porque entonces no funcionaría el sistema, no más porque entonces se está subiendo el riesgo. Esto en sistemas Windows XP fue una crítica constante, y con razón, de porque un servicio de red debía correr con una cuenta tan privilegiada en el sistema que pudiera hacer mil cosas. La pregunta es, ¿debería el bloc de notas correr con privilegios de administración? ¿incluso cuando lo ejecute el administrador? La respuesta, lógicamente, es que no, no debería. ¿Y si se necesitan de forma muy concreta para un caso muy concreto? Entonces que se haga de forma explícita en esta excepción.
Fortificar un sistema es aplicar DP, MPE y MPP a todos, absolutamente todos los componentes y procedimientos del sistema. Vamos a ver como lo aplica Windows 7 Windows Vista.
Mínimo Privilegio en Windows Vista y Windows 7
Este principio, dirigido desde la TCI [Trustworthy Computing Initiative] mediante el SDL [Secure Development Lifecycle] es aplicado en Windows Vista, y por tanto en Windows 7, desde la concepción del sistema operativo. Recordad que la reconstrucción del kernel de Longhorn bajo este nuevo prisma, impuesto por la TCI en el año 2002, obligó a rehacer los diseños y retrasar el lanzamiento de NT 6.0 un año.
Con esta nueva arquitectura del sistema llegaron los Niveles de Integridad aplicados por el MIC [Mandatory Integrity Control]. Esto se había demandado tiempo ha, ya que no todos los componentes tienen la misma importancia dentro del sistema operativo y, por tanto, parece lógico crear una serie de anillos de seguridad de tal manera que un componente que se ejecute en un nivel menos privilegiado no pueda manipular componentes corriendo en niveles más privilegiados.
Pero con este diseño también llegó UAC, nuestro querido amigo UAC, cuyo objetivo es que los privilegios de una cuenta estén protegidos directamente por el sistema operativo. Que sea el propio Windows quien haga un uso responsable de los privilegios que tiene una cuenta. Es decir, que por muchos privilegios que tena una cuenta, la ejecución de un comando desde una de esas cuentas sea aplicando el principio del MPP.
Así, el administrador de un sistema que ejecuta el bloc de notas podrá tener la seguridad de que su bloc de notas no le va a crear un usuario dentro del sistema operativo, le va a modificar el firewall, le va a lanzar un Shell fuera del sistema.
La diferencia es brutal y maravillosa en comparación con otras soluciones. Si en cualquier otro sistema entras como administrador y se hace un doble clic sobre un editor de texto, sólo con Windows Vista/Windows 7 y UAC estás seguro de que ese editor de textos no te va a crear un usuario en el sistema. En el resto de soluciones no tienes esa garantía.
************************************************************************************************
- Control de Cuentas de Usuario (I de VI)
- Control de Cuentas de Usuario (II de VI)
- Control de Cuentas de Usuario (III de VI)
- Control de Cuentas de Usuario (IV de VI)
- Control de Cuentas de Usuario (V de VI)
- Control de Cuentas de Usuario (VI de VI)
************************************************************************************************
- Control de Cuentas de Usuario (I de VI)
- Control de Cuentas de Usuario (II de VI)
- Control de Cuentas de Usuario (III de VI)
- Control de Cuentas de Usuario (IV de VI)
- Control de Cuentas de Usuario (V de VI)
- Control de Cuentas de Usuario (VI de VI)
************************************************************************************************
El User Account Control [UAC] o Control de Cuentas de Usuario, es una de las mejores funcionalidades que trae Windows para proteger los privilegios de los administradores y, sin embargo, es de las que más pena me da escuchar a hablar. Informáticos de pro hablando mal de esta característica, técnicos de sistemas malentendiendo su funcionamiento, cayendo en el chascarrillo fácil y la simplificación de la tecnología. Me apena y me entristece. Durante esta gira de Lanzamiento de Windows 7 he tenido la suerte de poder explicar un poco en detalle cómo funciona el UAC en Windows Vista y en Windows 7 y, tras haber sido la sesión mejor valorada de toda la gira, creo que por lo menos me llevo la satisfacción de haber explicado un poco más esta funcionalidad.
Sin embargo, durante la ejecución de la gira, mi amigo “Pajarraco” de los Santos decidió, tras llevar alrededor de cuatro meses usando Windows, escribir los que para mí son los peores artículos que ha escrito él en mucho tiempo en Una-al-día, sobre todo cuando él mismo tiene una visión favorable a UAC que no veo bien reflejada en sus artículos.
Vaya por delante que Una-al-día ha sido mi mentora y tutora en el mundo de la seguridad informática, y que, tras alrededor de 10 años suscrito a la newsletter soy capaz, casi con total éxito de reconocer un texto de Bernardo Quintero, Antonio Ropero, Laboratorioman y “Pajarraco” de los Santos solo con leer el primer párrafo, algunas hasta con el título.
Sin embargo, los artículos del UAC escritos por “Pajarraco” reflejan un punto de vista con respecto al UAC totalmente desprovisto de los tecnicismos y las arduas explicaciones técnicas. Los dos primeros me parecen directamente mal explicados, mal comparados con las tecnologías de otros sistemas operativos e incluso menospreciantes en los conceptos novedosos que en sí que aporta UAC.
El tercero, tras largas conversaciones telefónicas entre él y yo, “Pajarraco” sabe perfectamente que le voy a llamar después de escribir algo así, publicó una tercera parte en la que intentaba matizar algunos detalles para aquellos que como yo no lo veíamos tan claro, como la aplicación del principio del Mínimo Privilegio Posible, algo, que guía la construcción de UAC desde su inicio y que intentar explicar esta tecnología sin hablar de él es imposible o erróneo.
- Mitos y leyendas: UAC, ese gran incomprendido I (Introducción)
- Mitos y leyendas: UAC, ese gran incomprendido II (UAC de forma útil)
- Mitos y leyendas: UAC, ese gran incomprendido III (UAC y la ley del mínimo privilegio)
Sin más preámbulo, y si ya te has leído la serie de artículos sobre UAC que escribió mi amigo “Pajarraco” de los Santos, vamos a empezar con esta serie.
Fortificar u Optimizar
Siempre que intento explicar este concepto me gusta hablar de la diferencia entre Optimizar y Fortificar un sistema. Son dos procesos que muchas veces nos caen a los consultores informáticos y que tienen dos aproximaciones de trabajo totalmente diferentes.
La optimización no es un proceso que se pueda hacer de fábrica, no es algo que pueda venir out-of-the-box. El método de optimización debe generar los mejores parámetros de configuración de un sistema para conseguir el máximo rendimiento pero éstos siempre van a depender de la carga y uso que se le dé al sistema. Es por eso que de fábrica los equipos vienen con unos parámetros por defectos pensados para ser los que mejor funcionan en la mayoría de los casos. Nada más instalar un Windows Vista o un Windows 7 ponerse a tocar servicios y valores va en contra de su rendimiento y muchos de los que intentan tunearlo al igual que se hacía con Windows XP suelen cepillarse el rendimiento del sistema más que arreglarlo. Sólo se puede optimizar un sistema después de un análisis de la carga de trabajo del mismo y para ello Windows Vista y Windows 7 ya traen sus mecanismos.
La fortificación, por el contrario, es un proceso que depende del rol del sistema. El rol a un sistema se le asigna antes de ponerlo en producción por lo que la Fortificación sí es un proceso que puede hacerse antes. Así, los sistemas Microsoft, por defecto, desde la TCI, aplican la fortificación por defecto y es labor del administrador del sistema configurar los roles y bajar los controles de seguridad lo justo y necesario para que funcione el rol que va a recibir este sistema.
Decía Andrew S. Tanenbaum que la única manera de tener un sistema seguro es metiéndolo dentro de una caja fuerte y tirando la llave dentro y esa es más o menos la idea de la fortificación, sólo que hemos de abrir la caja fuerte un poco, pincharle un cable de red y dejar que entre y salga el tráfico justo para que cumpla con sus funciones.
Principios de la Foritificación de Sistemas
Para ello se aplican tres principios fundamentales:
- Defensa en Profundidad [DP]: Este axioma dice que un sistema debe aplicar tantas medidas de seguridad como sea posible teniendo en cuenta que las medidas de seguridad de las capas adyacentes pueden haber sido comprometidas siempre y cuando la aplicación de una medida no anule la aplicación de otra y que el sistema siga ofertando su servicio. Si pones un IDS de red y luego cifras con IPSEC una medida de seguridad ha sido anulada y sería un mal diseño de defensa en profundidad. Si pones muchas medidas de seguridad y resulta que no se cumplen los objetivos del servicio, es decir, el servicio se ve deteriorado en sus principios básicos, tampoco será una opción viable. Por último, en un mundo ideal no hay dinero o este es del monopoli, pero en la realidad la aplicación de la regla de Defensa en profundidad se verá afectada también por la pasta que se tenga.
- Mínimo Punto de Exposición [MPE]: Un sistema debe ejecutar sólo y exclusivamente los componentes necesarios para el cumplimiento funcional de su rol. Es decir, es de cajón que un servidor, si no necesita dar servicio de Webdav no tiene porque tener este servicio en ejecución, ni publicado a internet y ni aceptar peticiones. Así, cuando se pone en producción una máquina hay que ver cuáles son sus roles y cuáles los componentes que se necesitan. Desde Windows Server 2003 R2 todos los servidores de Microsoft son role-oriented.
- Mínimo Privilegio Posible [MPP]: Cada uno de los componentes necesarios para la ejecución de un rol debe ejecutarse con el número de privilegios justos para ello. No menos, porque entonces no funcionaría el sistema, no más porque entonces se está subiendo el riesgo. Esto en sistemas Windows XP fue una crítica constante, y con razón, de porque un servicio de red debía correr con una cuenta tan privilegiada en el sistema que pudiera hacer mil cosas. La pregunta es, ¿debería el bloc de notas correr con privilegios de administración? ¿incluso cuando lo ejecute el administrador? La respuesta, lógicamente, es que no, no debería. ¿Y si se necesitan de forma muy concreta para un caso muy concreto? Entonces que se haga de forma explícita en esta excepción.
Fortificar un sistema es aplicar DP, MPE y MPP a todos, absolutamente todos los componentes y procedimientos del sistema. Vamos a ver como lo aplica Windows 7 Windows Vista.
Mínimo Privilegio en Windows Vista y Windows 7
Este principio, dirigido desde la TCI [Trustworthy Computing Initiative] mediante el SDL [Secure Development Lifecycle] es aplicado en Windows Vista, y por tanto en Windows 7, desde la concepción del sistema operativo. Recordad que la reconstrucción del kernel de Longhorn bajo este nuevo prisma, impuesto por la TCI en el año 2002, obligó a rehacer los diseños y retrasar el lanzamiento de NT 6.0 un año.
Con esta nueva arquitectura del sistema llegaron los Niveles de Integridad aplicados por el MIC [Mandatory Integrity Control]. Esto se había demandado tiempo ha, ya que no todos los componentes tienen la misma importancia dentro del sistema operativo y, por tanto, parece lógico crear una serie de anillos de seguridad de tal manera que un componente que se ejecute en un nivel menos privilegiado no pueda manipular componentes corriendo en niveles más privilegiados.
Pero con este diseño también llegó UAC, nuestro querido amigo UAC, cuyo objetivo es que los privilegios de una cuenta estén protegidos directamente por el sistema operativo. Que sea el propio Windows quien haga un uso responsable de los privilegios que tiene una cuenta. Es decir, que por muchos privilegios que tena una cuenta, la ejecución de un comando desde una de esas cuentas sea aplicando el principio del MPP.
Así, el administrador de un sistema que ejecuta el bloc de notas podrá tener la seguridad de que su bloc de notas no le va a crear un usuario dentro del sistema operativo, le va a modificar el firewall, le va a lanzar un Shell fuera del sistema.
La diferencia es brutal y maravillosa en comparación con otras soluciones. Si en cualquier otro sistema entras como administrador y se hace un doble clic sobre un editor de texto, sólo con Windows Vista/Windows 7 y UAC estás seguro de que ese editor de textos no te va a crear un usuario en el sistema. En el resto de soluciones no tienes esa garantía.
************************************************************************************************
- Control de Cuentas de Usuario (I de VI)
- Control de Cuentas de Usuario (II de VI)
- Control de Cuentas de Usuario (III de VI)
- Control de Cuentas de Usuario (IV de VI)
- Control de Cuentas de Usuario (V de VI)
- Control de Cuentas de Usuario (VI de VI)
************************************************************************************************
