Actualizaciones Zona Horarias

El día de hoy (15/12/2011) se publicó el boletín 2633952, que hace referencia a la actualización de las zonas horarias para los diferentes S.O Microsoft. Esta actualización sustituye y reemplaza actualización 2570791 (http://support.microsoft.com/KB/2570791) , que se lanzó en agosto de 2011.

Importante
Antes de aplicar la actualización que se describe en este artículo, tenga en cuenta los posibles problemas que pueden afectar a Microsoft Outlook. Para obtener más información acerca de estos problemas, verlo en Microsoft Knowledge Base: 931667 (http://support.microsoft.com/kb/931667) Cómo abordar los cambios de zona horaria con la herramienta de actualización de datos de zona horaria para Microsoft Office Outlook .

Si está ejecutando Microsoft Exchange Server en un entorno de tecnología de información (IT), debe tomar medidas adicionales para garantizar el correcto funcionamiento de Exchange Server. Para obtener más información acerca de la actualización del horario de verano (DST) de Exchange, verlo en Microsoft Knowledge Base: 941018 (http://support.microsoft.com/kb/941018) Cómo abordar el horario de verano con la herramienta de actualizar calendario de Exchange.

Las actualizaciones acumulativas de zonas horarias sólo contienen datos que han cambiado para una región específica o que se ha agregado para mantener la paridad con otras versiones de sistema operativo. Por lo tanto, si se elimina una clave de la zona horaria, algunos de los valores originales no se restaura después de aplicar la actualización acumulativa de zonas.No se recomienda que elimine las claves del Registro relacionadas con las zonas horarias. En un equipo que tenga claves de zona horaria incompletas, restaure primero las claves de zona horaria desde una copia de seguridad buena conocida.

Las actualizaciones pueden ser bajadas accediendo a este boletín aqui.

Lea atentamente el boletín y verifique las KB que se recomiendan, ya que puede provocar desfasajes en el servidor de correo y dispositivos móviles.

Hasta la próxima.
Saludos

Fuente: Microsoft

Actualizaciones plataforma Microsoft - DICIEMBRE 2011

Este mes, para terminar un año intenso, Microsoft publicó los siguientes boletines de seguridad. Recomendamos aplicar las mismas, por que incluyen la protección del gusano DUQU.

Ellos son:

1) MS11-087: Una vulnerabilidad en los controladores en modo kernel de Windows podría permitir la ejecución remota de código (2639417) Esta actualización de seguridad resuelve una vulnerabilidad que se ha divulgado públicamente en Microsoft Windows. La vulnerabilidad podría permitir la ejecución remota de código si un usuario abre un documento especialmente diseñado o visita una página web malintencionada que inserta archivos de fuentes TrueType.

2) MS11-090: Actualización de seguridad acumulativa de bits de interrupción de ActiveX (2618451) Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma privada en el software de Microsoft. La vulnerabilidad podría permitir la ejecución remota de código si un usuario visita una página web especialmente diseñada que use un comportamiento binario específico en Internet Explorer. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos. Esta actualización también incluye bits de interrupción para cuatro controles ActiveX de terceros.

3) MS11-092: Una vulnerabilidad en Windows Media podría permitir la ejecución remota de código (2648048) Esta actualización de seguridad resuelve una vulnerabilidad en Reproductor de Windows Media y Windows Media Center de la que se ha informado de forma privada. La vulnerabilidad podría permitir la ejecución remota de código si un usuario abre un archivo de grabación de vídeo digital de Microsoft (.dvr-ms) especialmente diseñado. En todos los casos, no se puede obligar al usuario a que abra el archivo; para que el ataque se lleve a cabo, se debe convencer al usuario de que lo abra.

4) MS11-088: Una vulnerabilidad en Microsoft Office IME (chino) podría permitir la elevación de privilegios (2652016) Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft Office IME (chino). La vulnerabilidad podría permitir la elevación de privilegios si un usuario con la sesión iniciada realizara acciones específicas en un sistema donde esté instalada una versión afectada del editor de métodos de entrada (IME) de Microsoft Pinyin (MSPY) para chino simplificado. Un atacante que consiguiera aprovechar esta vulnerabilidad podría ejecutar código arbitrario en modo kernel. De esta forma, un intruso podría instalar programas; ver, cambiar o eliminar datos; o crear cuentas nuevas con todos los derechos administrativos. Solo las implementaciones de Microsoft Pinyin IME 2010 están afectadas por esta vulnerabilidad. Otras versiones de IME de chino simplificado y otras implementaciones de IME no están afectadas.

5) MS11-089 : Una vulnerabilidad en Microsoft Office podría permitir la ejecución remota de código (2590602) Esta actualización de seguridad crítica resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft Office. La vulnerabilidad podría permitir la ejecución remota de código si un usuario abre un archivo de Word especialmente diseñado. Un intruso que aprovechara esta vulnerabilidad podría conseguir el mismo nivel de derechos de usuario que el usuario que ha iniciado sesión. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos.

6) MS11-091: Vulnerabilidades en Microsoft Publisher podrían permitir la ejecución remota de código (2607702) Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma pública y tres vulnerabilidades de las que se ha informado de forma privada en Microsoft Office. Las vulnerabilidades más graves podrían permitir la ejecución remota de código si un usuario abre un archivo de Publisher especialmente diseñado. Un atacante que aprovechara cualquiera de estas vulnerabilidades podría lograr el control total de un sistema afectado. De esta forma, un intruso podría instalar programas; ver, cambiar o eliminar datos; o crear cuentas nuevas con todos los derechos de usuario. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos.

7) MS11-093: Una vulnerabilidad en OLE podría permitir la ejecución remota de código (2624667) Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma privada en todas las ediciones compatibles de Windows XP y Windows Server 2003. Esta actualización de seguridad se considera importante para todas las ediciones compatibles de Windows XP y Windows Server 2003. Windows Vista, Windows Server 2008, Windows 7 y Windows Server 2008 R2 no están afectados por la vulnerabilidad.

8) MS11-094: Vulnerabilidades en Microsoft PowerPoint podrían permitir la ejecución remota de código (2639142) Esta actualización de seguridad resuelve dosvulnerabilidades de las que se ha informado de forma privada en Microsoft Office. Las vulnerabilidades podrían permitir la ejecución remota de código si un usuario abre un archivo de PowerPoint especialmente diseñado. Un atacante que aprovechara cualquiera de las vulnerabilidades podría lograr el control total de un sistema afectado. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos.

9) MS11-095: Una vulnerabilidad en Active Directory podría permitir la ejecución remota de código (2640045) Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma privada en Active Directory, Active Directory Application Mode (ADAM) y servicio de directorio ligero de Active Directory (AD LDS). La vulnerabilidad podría permitir la ejecución remota de código si un atacante inicia sesión en un dominio de Active Directory y ejecuta una aplicación especialmente diseñada. Para aprovechar esta vulnerabilidad, el atacante primero debe adquirir las credenciales para iniciar sesión en un directorio de Active Directory.

10) MS11-096: Una vulnerabilidad en Microsoft Excel podría permitir la ejecución remota de código (2640241) Esta actualización de seguridad crítica resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft Office. La vulnerabilidad podría permitir la ejecución remota de código si un usuario abre un archivo de Excel especialmente diseñado. Un intruso que aprovechara esta vulnerabilidad podría conseguir el mismo nivel de derechos de usuario que el usuario que ha iniciado sesión. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos. La instalación y configuración de Validación de documento de Office (OFV) para prevenir la apertura de archivos sospechosos bloquea las vías de ataque para aprovechar las vulnerabilidades descritas en CVE-2011-3403.

11) MS11-097: Una vulnerabilidad en el subsistema de tiempo de ejecución de cliente-servidor de Windows podría permitir la elevación de privilegios (2620712) Esta actualización de seguridad crítica resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft Windows. La vulnerabilidad podría permitir la elevación de privilegios si un atacante inicia sesión en un sistema afectado y ejecuta una aplicación especialmente diseñada para enviar un mensaje de evento de dispositivo a un proceso de mayor integridad. Para aprovechar esta vulnerabilidad, un atacante debe de tener unas credenciales de inicio de sesión válidas y ser capaz de iniciar una sesión local.

12) MS11-098: Una vulnerabilidad en el kernel de Windows podría permitir la elevación de privilegios (2633171) Esta actualización de seguridad crítica resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft Windows. La vulnerabilidad podría permitir la elevación de privilegios si un atacante inicia sesión en un sistema afectado y ejecuta una aplicación especialmente diseñada para aprovechar la vulnerabilidad. Para aprovechar esta vulnerabilidad, un atacante debe de tener unas credenciales de inicio de sesión válidas y ser capaz de iniciar una sesión local. Los usuarios anónimos o los usuarios remotos no pueden aprovechar esta vulnerabilidad.

13) MS11-099: Actualización de seguridad acumulativa para Internet Explorer (2618444 ) Esta actualización de seguridad resuelve tres vulnerabilidades de las que se ha informado de forma privada en Internet Explorer. La vulnerabilidad más grave podría permitir la ejecución remota de código si un usuario abre un archivo de lenguaje de marcado de hipertexto (HTML) legítimo que se encuentre en el mismo directorio que un archivo de biblioteca de vínculos dinámicos (DLL) especialmente diseñado.

Se recomienda aplicar los mismos en su plataforma, ya que resuelven problemas de seguridad, en donde la ausencia de muchos de ellos pueden provocar la ejecución remota de código malicioso.

Hasta la próxima.

Saludos

PD: Fuente Microsoft.

Actualizaciones plataforma Microsoft - NOVIEMBRE 2011

Buenas, los boletines de este mes fueron cuatri únicamente:

1) MS11-083: Una vulnerabilidad en TCP/IP podría permitir la ejecución remota de código (2588516) Esta actualización de seguridad crítica resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft Windows. La vulnerabilidad podría permitir la ejecución remota de código si un atacante envía un flujo continuo de paquetes UDP especialmente diseñados a un puerto cerrado en un sistema de destino.

2) MS11-085: Una vulnerabilidad en Windows Mail y Windows Meeting Space podría permitir la ejecución remota de código (2620704) Esta actualización de seguridad crítica resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft Windows. La vulnerabilidad podría permitir la ejecución remota de código si un usuario abre un archivo legítimo (como un archivo .eml o .wcinv) que se encuentre en el mismo directorio de red que un archivo de biblioteca de vínculos dinámicos (DLL) especialmente diseñado. Después, al abrir el archivo legítimo, Windows Mail o Windows Meeting Space podría intentar cargar el archivo DLL y ejecutar el código que contenga. Para que un ataque tenga éxito, un usuario debe visitar una ubicación de sistema de archivos o recurso compartido WebDAV remoto que no sea de confianza y abrir un archivo legítimo (como un arc .eml o .wcinv) de dicha ubicación que será cargado por una aplicación vulnerable.

3) MS11-086: Una vulnerabilidad en Active Directory podría permitir la elevación de privilegios (2630837) Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma privada en Active Directory, Active Directory Application Mode (ADAM) y servicio de directorio ligero de Active Directory (AD LDS). La vulnerabilidad podría permitir la elevación de privilegios si Active Directory se configura para usar LDAP sobre SSL (LDAPS) y un atacante adquiere un certificado revocado que está asociado a una cuenta de dominio válida y, a continuación, usa dicho certificado para autenticarse en el dominio de Active Directory. De forma predeterminada, Active Directory no está configurado para usar LDAP sobre SSL.

4) MS11-084: Una vulnerabilidad en los controladores del modo kernel de Windows podría permitir la denegación de servicio (2617657) Esta actualización de seguridad crítica resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft Windows. La vulnerabilidad podría permitir la denegación de servicio si un usuario abre un archivo de fuente TrueType especialmente diseñado como datos adjuntos de correo electrónico o navega a una ubicación de recurso de red o WebDAV que contenga un archivo de fuente TrueType especialmente diseñado. Para que se lleve a cabo un ataque, un usuario debe visitar la ubicación de sistema de archivo o recurso compartido WebDAV remoto que no sea de confianza que contenga el archivo de fuente TrueType especialmente diseñado o abra el archivo como datos adjuntos de correo electrónico. Sin embargo, el atacante no podría en ningún caso obligar a los usuarios a realizar estas acciones. Por lo tanto, tendría que atraerlos; por lo general, convenciéndoles para que hagan clic en un vínculo de un mensaje de correo electrónico o de Instant Messenger.

Sabes como actualizar tu PC? Si no sabes, visita este sitio que te explica todo sobre Windows Update

Hasta la próxima.

Fuenta: Microsoft.

DUQU : Resolviendo vulnerabilidad de Word

En las últimas semanas, el malware DUQU ha dado que hablar. Si bien no es un gusano que ocasione mayores problemas, se ha detectado que los equipos infectados intentan acceder a Internet para enviar información del equipo en donde esta alojado, además de abrir una puerta trasera. El equipo de Symantec ha detectado que el transporte de este código malicioso es mediante el uso de archivos de Word.
Microsoft hace unos días ha publicado un boletín (el Kb 2639658) en donde podrán encontrar como resolver el problema manualmente por ahora.
Si bien esta solución permite resolver parcialmente el problema, debe hacerse de manera manual bajando el Fix It. Pueden hacerlo desde AQUI.
Por otro lado recomendamos

1) Avisar a los usuarios que si reciben correos de personas desconocidad con archivos de Word, que no han sido solicitados, que no abran los mismos.
2) Mantener los equipos que poseen Ms Office actualizados, con los fixes y parches que recomienda Microsoft.
3) Mantener los S.O actualizados.
4) En los servidores que se ejecute el servicio de Terminal Server y poseen Ms Office, aplicar el artículo técnico KB 2639658.
5) Analizar el Dossier de Symantec y restringir conexiones en el proxy a las direcciones IP que figuran en el mismo.
6) Recomendar a los usuarios un manejo discrecional en el correo con archivos de Word, que para ello utilicen un file server o una Intrantet.
7) Mantener los antivirus actualizados.
8) Aplicar la KB 2639658 en la plataforma.
9) Revisar artículo anterior publicado en este blog sobre DUQU (Leer Aquí).

Seguramente subamos más información de este malware cuando esté disponible.
Hasta la próxima.

Evento de Seguridad en Perú

Estimados
Los esperamos el día 14/11 en donde disertaremos sobre Seguridad en la Nube. El evento es organizado por Common Perú (http://www.commonperu.com/). A las 18:30 comenzaremos con la conferencia "Seguridad en la Nube".

Hasta la próxima

Stuxnet V 2.0 = DUQU

Si recuerdan, en octubre del 2010, hicimos un artículo sobre un malware denominado Stuxnet (ver Aquí). Si bien el gusano no logró del todo su objetivo, hace unos días apareció un código malicioso que intenta reunir datos de la plataforma e información sobre los proveedores de sistemas de control industrial. El objetivo es recolectar dicha información para preparar nuevamente un ataque y lograr el objetivo (parar la planta o bien lograr un daño, recuerden que el objetivo original era parar las Centrales Nucleares de Irán).
El mismo ha sido denominado DUQU, debido a que genera archivos con prefijo "~DQ". El gusano no es dañino, ya que el objetivo es recolectar informacion de la plataforma.
Por el código y en base al comportamiento aseguran que los autores de DUQU son los mismos que elaboraron el malware Stuxnet o bien por desarrolladores que han accedido al código del mismo (Si recuerdan, Stuxnet está publicado en Internet y pueden bajar el código para analizar su comportamiento).

Cómo funciona?
Una vez infectado el sistema, por 36 días recolecta información y luego se remueve de la plataforma. Mientras está funcionando, utiliza los protocolos HTTP y HTTPS para conectarse con un servidor externo (alojado en la India, cuya dirección IP es la 206.183.111.97) y enviar la informacion recolectada.
Los atacantes utilizaron Duqu para instalar un software Infostealer (pariente del keylogger), que puede grabar las pulsaciones de teclado, y recopilar información del sistema. Los atacantes estaban en busca de activos de información que pueda ser utilizado en un ataque futuro. Según Symantec, en su dossier, detalla que encontró dos variantes, una de ellas fue recuperadas con binarios cuya fecha era el 1 de septiembre de 2011. La otra variante, con fecha del 17 de Octubre de 2011.

Según informa Symantec, el gusano consiste en un archivo de controlador, una DLL (que posee varios archivos incrustados), y un archivo de configuración. Estos archivos deben ser instalados por otro ejecutable (el instalador), que según Symantec aún no ha recuperado. El instalador registra el archivo del controlador como un servicio para que comience en la inicialización del sistema. El conductor entonces le inyecta la DLL principal en services.exe. A partir de aquí, el archivo DLL principal se inicia la extracción de otros componentes y estos componentes se inyectan en otros procesos.

Archivos
En las dos versiones se pueden identificar los archivos alojados en el equipo.

Primera Versión:
- jminet7.sys
-netp191.PNF
- 302 resource
- netp192.pnf

Segunda Versión:
-cmi4432.sys
-cmi4432.pnf
- 302 resource
- cmi4464.PNF

En ambos el InfoStealer está en [TEMP FILE NAME].

Recomendaciones
Para evitarlo, sugerimos, dentro de los equipos de la red industrial:

1) Habilitar un firewall en su ordenador.
2) Evitar accesos a Internet y uso de pendrives desde esos equipos.
3) Obtenga las últimas actualizaciones de equipo para todo el software instalado.
4) Mantenga el software antivirus actualizado tanto le sea posible
5) Limitar los privilegios de usuario en el equipo, para que no se pueda instalar las DLL.
6) Tenga cuidado al abrir archivos adjuntos y aceptar transferencias de archivos.
7) Tenga cuidado al hacer clic en enlaces a páginas web.
8) Evitar la descarga de software pirateado, sobre todo aquel que es utilizado en este tipo de redes.
9) Utilice contraseñas seguras.

Más información.
Para obtener información más detallada, les recomendamos bajar el dossier de Symantec para DUQU, puede hacerlo desde aquí.
Por otro lado Microsoft lo tiene identificado, si desea acceder a la Enciclopedia de malware de Microsoft para tener más detalle del gusano, visite este sitio.

Por último, recomendamos estar atentos, si bien esta variante solo recolecta información, pueden aparecer otras ya con fines malicioso por contar con parte de la informacion de vuestra infraestructura o bien con un patrón de desarrollo de la misma, ya que observamos en muchas compañías ausencias de seguridad en los equipos que están asociados a las plantas industriales. Ya no sirve más el "funciona, no se toca más".

Fuentes: Symantec y Microsoft.

Hasta la próxima!

Se viene el CODECAMP

Buenas, se viene el evento más esperado, el CODECAMP!!!
CodeCamp es un evento que reune a Estudiantes, Profesionales y Empresas del área de Informática, realizado por diferentes miembros y empresas de la comunidad, y Universidades desde el año 2007.
Quien dirá tantas sesiones de Tecnología para vos!!.

No faltes, la cita es el 15 de Octubre en la Universidad Abierta Interamericana.

Cuál es mi sesión?
Yo los espero a las 11:50 con la sesión "Un usuario nuevo en la red, un dolor de cabeza (Administración de Identidades)"

Dónde es?
En la Universidad Abierta Interamericana, Av. San Juan 951 (Capital Federal).
Buenos Aires-Ciudad de Buenos Aires-Argentina.

No podes faltar!!!
Registrate AQUI

Actualizaciones plataforma Microsoft - OCTUBRE 2011

Aquí estamos otro mes, presentando los boletines de seguridad de Octubre:

- MS11-078: Una vulnerabilidad en .NET Framework y Microsoft Silverlight podría permitir la ejecución remota de código (2604930): Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma privada en Microsoft .NET Framework y Microsoft Silverlight. La vulnerabilidad podría permitir la ejecución remota de código en un sistema cliente si un usuario visita una página web especialmente diseñada mediante un explorador web que pueda ejecutar aplicaciones XAML del explorador (XBAP) o aplicaciones Silverlight. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos. La vulnerabilidad también podría permitir la ejecución remota de código en un sistema de servidor que ejecute IIS si dicho servidor permite el procesamiento de páginas ASP.NET y un atacante consigue cargar una página ASP.NET especialmente diseñada en el servidor y la ejecuta, como puede ser el caso de un escenario de hospedaje web. Esta vulnerabilidad también la podrían usar aplicaciones Windows .NET para omitir las restricciones de seguridad de acceso del código (CAS).

- MS11-081: Actualización de seguridad acumulativa para Internet Explorer (2586448): Esta actualización de seguridad resuelve ocho vulnerabilidades de las que se ha informado de forma privada en Internet Explorer. La más grave de las vulnerabilidades podría permitir la ejecución remota de código si un usuario, mediante Internet Explorer, visita una página web especialmente diseñada. Un intruso que aprovechara cualquiera de estas vulnerabilidades podría conseguir el mismo nivel de derechos de usuario que el usuario local. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos.

- MS11-075: Una vulnerabilidad en Microsoft Active Accessibility podría permitir la ejecución remota de código (2623699): Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma privada en el componente Microsoft Active Accessibility. La vulnerabilidad podría permitir la ejecución remota de código si un atacante convence a un usuario de que abra un archivo legítimo que se encuentre en el mismo directorio de red que un archivo de biblioteca de vínculos dinámicos (DLL) especialmente diseñado. Después, al abrir el archivo legítimo, el componente Microsoft Active Accessibility puede intentar cargar el archivo DLL y ejecutar el código que contiene. Para que un ataque tenga éxito, un usuario debe visitar una ubicación de sistema de archivos o recurso compartido WebDAV remoto que no sea de confianza y abrir un documento de dicha ubicación que será cargado por una aplicación vulnerable.

- MS11-076: Una vulnerabilidad en Windows Media Center podría permitir la ejecución remota de código (2604926): sta actualización de seguridad resuelve una vulnerabilidad que se ha divulgado públicamente en Windows Media Center. La vulnerabilidad podría permitir la ejecución remota de código si un atacante convence a un usuario de que abra un archivo legítimo que se encuentre en el mismo directorio de red que un archivo de biblioteca de vínculos dinámicos (DLL) especialmente diseñado. Después, al abrir el archivo legítimo, Windows Media Center podría intentar cargar el archivo DLL y ejecutar el código que contenga. Para que un ataque tenga éxito, un usuario debe visitar una ubicación de sistema de archivos o recurso compartido WebDAV remoto que no sea de confianza y abrir un archivo legítimo.

- MS11-077: Vulnerabilidades en los controladores en modo kernel de Windows podrían permitir la ejecución remota de código (2567053): Esta actualización de seguridad resuelve cuatro vulnerabilidades de las que se ha informado de forma privada en Microsoft Windows. La más grave de estas vulnerabilidades podría permitir la ejecución remota de código si un usuario abre un archivo de fuente especialmente diseñado (como un archivo .fon) en un recurso compartido de red, una ubicación UNC o WebDAV, o en datos adjuntos de correo electrónico. Para que un ataque remoto se lleve a cabo, el usuario debe visitar una ubicación de sistema de archivo o recurso compartido WebDAV remoto que no sea de confianza y abrir el archivo de fuente especialmente diseñado, o bien abrir el archivo como datos adjuntos de correo electrónico.

- MS11-079: Vulnerabilidades en Microsoft Forefront Unified Access Gateway podrían provocar la ejecución remota de código (2544641): Esta actualización de seguridad resuelve cinco vulnerabilidades de las que se ha informado de forma privada en Forefront Unified Access Gateway (UAG). La más grave de estas vulnerabilidades podría permitir la ejecución remota de código si un usuario visita un sitio web afectado mediante una URL especialmente diseñada. No obstante, el atacante no podría obligar a los usuarios a visitar un sitio web. Por lo tanto, tendría que atraerlos al sitio web; por lo general, convenciéndoles para que hagan clic en un vínculo de un mensaje de correo electrónico o de Instant Messenger que lleve a los usuarios al sitio web del atacante.

- MS11-080: Una vulnerabilidad en el controlador de función auxiliar podría permitir la elevación de privilegios (2592799): Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma privada en el controlador de función auxiliar de Microsoft Windows (AFD.SYS). La vulnerabilidad podría permitir la elevación de privilegios si un atacante inicia sesión en el sistema del usuario y ejecuta una aplicación especialmente diseñada. Para aprovechar la vulnerabilidad, un atacante debe tener unas credenciales de inicio de sesión válidas y ser capaz de iniciar una sesión local.

- MS11-082: Vulnerabilidades en Host Integration Server podrían permitir la denegación de servicio (2607670): Esta actualización de seguridad resuelve dos vulnerabilidades de las que se ha informado de forma pública en Host Integration Server. Las vulnerabilidades podrían permitir la denegación de servicio si un atacante remoto envía paquetes de red especialmente diseñados a un servidor Host Integration Server que escuche en el puerto UDP 1478 o en los puertos TCP 1477 y 1478. Los procedimientos recomendados para firewall y las configuraciones de firewall predeterminadas estándar pueden proteger a las redes de los ataques procedentes del exterior del perímetro de la empresa. Se recomienda que los sistemas conectados a Internet tengan expuesta la cantidad mínima de puertos. En este caso, los puertos de Host Integration Server de salida deben bloquearse desde Internet.

Para más información o bajar alguna de las actualizaciones, visite ESTE SITIO.
Fuente: Microsoft Corp.

Hasta la próxima.

Si no ajustas las contraseñas, estas "Morto"- Gusano Morto

Introducción
Hace unos días que estamos haciendo seguimiento al comportamiento de algunas alertas de los IPS (Intrusion Prevention Service) que poseen algunas compañías, que por cuestiones de negocio, han publicado los servicios de RDP (Remote Desktop Protocol) ha Internet.
Los IPS han evidenciado intentos de conexión masiva de direcciones IP (Internet Protocol) de diferentes lugares siendo muy masivos los intentos de conexión.
Analizando,los intentos de conexión, se corresponde al comportamiento de un nuevo gusano llamado Morto que ha comenzado a circular en Internet en los último días, que intenta infectar máquinas a través de RDP. El comportamiento del gusano se evidencia por que el mismo genera una gran cantidad de tráfico RDP de salida en redes que tienen las máquinas infectadas, y Morto es capaz de poner en peligro tanto a los servidores y estaciones de trabajo Windows que poseen este protocolo habilitado.

Escenarios WAN
Si el escenario es por la publicación a Internet del RDP, vamos a ver en los IPS una cantidad importante de intentos de conexión con direcciones de IP falsificadas (Spoofing). Una manera de mitigar este tipo de intentos de conexión es cambiando la configuración del escenario WAN:

1) No publicar el servicio de RDP, permitiendo el acceso al mismo mediante conexiones de VPN (IPSec, SSL o PPTP).
2) Ajustar y mantener actualizado su plataforma de IPS, con generación de alertas al referente de seguridad de la compañía.
3) Definir de donde pueden acceder al RDP.
4) Administrar usuarios con contraseñas complejas, definiendo horarios de acceso por parte del usuario.

Escenario LAN
Normalmente este tipo de protocolo, en la red LAN está diposnible tanto para acceder a un servidor como para tomar control remoto de una PC o Desktop. La manera de evitar un problema en la red es:

1) Ajustar muy bien los antimalware para que detecten y denieguen este tipo de conexiones masivas. Es importante que el software detecte el gusano en el desktop.
2) Configurar los firewall de los servidores, permitiendo que solo los equipos autorizados utilicen el puerto RDP, siempre que sea necesario por el desktop cliente. Esto significa, no permitir conexiones masivas de todas las PC de la red, es más bien, definir quienes deben acceder a este protocolo y permitir el acceso.
3) Utilizar una solución de NAC que permita mandar a cuarentena un equipo con comportamiento anómalo.
4) Utilizar contraseñas complejas en los usuarios que necesitan acceder a un servicio de Terminal Server.

Estadísticas y Comportamiento
Según el MMPC (Microsoft Malware Protection Center), el gusano ya está en mas de 87 paises y el sistema operativo más afectado es XP.También hemos descubierto que Morto intenta vulnerar la cuenta administrador mediante la fuerza bruta a conexiones RDP con su ataque de diccionario simple.
Inicialmente las pruebas de conectividad de la máquina afectada Internet, tratando de conectarse a una dirección IP 74.125.71.104. Si este intento no tiene éxito, entonces los reintentos a través de direcciones IP en la subred del ordenador afectado, y tratando de conectarse a las máquinas que se hayan empleado los siguientes nombres de usuario:

1
actuser
adm
admin
admin2
administrator
aspnet
backup
computer
console
david
guest
john
owner
root
server
sql
support
support_388945a0
sys
test2
test3
user
user1
user5

Es importante recordar que este malware no se aprovecha de una vulnerabilidad en Remote Desktop Protocol, sino que se basa en contraseñas débiles (se puede ver las contraseñas utilizadas por Morto en la enciclopedia de Microsoft). Si no lo ha hecho, verificar si estos nombres de usuario se están utilizando en su entorno y cambiar las contraseñas asociadas a las que son fuertes (y definitivamente no en la lista de contraseñas). Incluso los ordenadores que han sido limpiados de esta amenaza puede ser afectados si las contraseñas no se cambian y el equipo sigue sin protección.

Cuando el gusano detecta una clave (protocolo RDP permite el acceso), se conecta al sistema remoto y empieza el proceso de intento de reproducirse. El malware se compone de un instalador y una biblioteca de enlace dinámico (DLL). El archivo DLL tiene el mismo nombre que uno utilizado por el Regedit y contiene información de configuración cifrada para descargar y ejecutar al menos tres componentes adicionales.

Moraleja
El secreto es cumplir con las buenas prácticas. En este caso, la utilización de una buena contraseña (definimos buena contraseña cuando cumple con los niveles de fortaleza recomendados) fortalezerá el sistema.
Si tiene dudas si la contraseña que Usted utiliza es compleja o cumple con dicha característica, puede visitar este sitio y al transcribir la contraseña, le indicará el nivel de fortaleza.
Si no ajustas las contraseñas, estas "Morto".

Resumiendo
Este gusano lo que intenta es robar la contraseña de usuarios, utilizando el viejo y conocido sistema de Fuerza Bruta. No es una vulnerabilidad del protocolo RDP, es más bien, un mal seteo de las contraseñas de usuarios de la red. Ovbiamente, si Usted publica su RDP a Internet, los ajustes deben ser inmediatos, ya que allí un desconocido puede lograr el acceso a su red.

Hasta la próxima.
Fuente: Microsoft

Actualizaciones plataforma Microsoft - SEPTIEMBRE 2011

Este mes contamos con los siguientes boletines:

1) MS11-070: Una vulnerabilidad en WINS podría permitir la elevación de privilegios (2571621)
Esta actualización de seguridad resuelve una vulnerabilidad de la que se ha informado de forma privada en Servicio de nombres Internet de Windows (WINS). La vulnerabilidad podría permitir la elevación de privilegios si un usuario recibe un paquete de réplica de WINS especialmente diseñado en un sistema afectado que ejecuta el servicio WINS. Para aprovechar esta vulnerabilidad, un atacante debe de tener unas credenciales de inicio de sesión válidas y ser capaz de iniciar una sesión local.

2) MS11-071: Una vulnerabilidad en los componentes de Windows podría permitir la ejecución remota de código (2570947)
Esta actualización de seguridad resuelve una vulnerabilidad que se ha divulgado públicamente en Microsoft Windows. La vulnerabilidad podría permitir la ejecución remota de código si un usuario abre un archivo de formato de texto enriquecido (.rtf), un archivo de texto (.txt) o un documento de Word (.doc) legítimo que se encuentre en el mismo directorio de red que un archivo de biblioteca de vínculos dinámicos (DLL) especialmente diseñado. Un intruso que aprovechara esta vulnerabilidad podría conseguir el mismo nivel de derechos de usuario que el usuario local. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos.

3) MS11-072: Vulnerabilidades en Microsoft Excel podrían permitir la ejecución remota de código (2587505)
Esta actualización de seguridad resuelve cinco vulnerabilidades de las que se ha informado de forma privada en Microsoft Office. Las vulnerabilidades podrían permitir la ejecución remota de código si un usuario abre un archivo de Excel especialmente diseñado. Un intruso que aprovechara cualquiera de estas vulnerabilidades podría conseguir el mismo nivel de derechos de usuario que el usuario que ha iniciado sesión. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos. La instalación y configuración de Validación de documento de Office (OFV) para prevenir la apertura de archivos sospechosos bloquea las vías de ataque para aprovechar las vulnerabilidades descritas en CVE-2011-1986 y CVE-2011-1987.

4) MS11-073: Vulnerabilidades en Microsoft Office podrían permitir la ejecución remota de código (2587634)
Esta actualización de seguridad resuelve dos vulnerabilidades de las que se ha informado de forma privada en Microsoft Office Visio. Las vulnerabilidades podrían permitir la ejecución remota de código si un usuario abre un archivo de Office especialmente diseñado o si un usuario abre un archivo de Office legítimo que se encuentre en el mismo directorio de red que un archivo de biblioteca especialmente diseñado. Un intruso que aprovechara cualquiera de las vulnerabilidades podría conseguir el mismo nivel de derechos de usuario que el usuario que ha iniciado sesión. Los usuarios cuyas cuentas estén configuradas con menos derechos de usuario en el sistema correrían un riesgo menor que los que cuenten con derechos de usuario administrativos.

5) MS11-074: Vulnerabilidades en Microsoft SharePoint podrían permitir la elevación de privilegios (2451858)
Esta actualización de seguridad resuelve cinco vulnerabilidades de las que se ha informado de forma privada y una vulnerabilidad de la que se ha informado de forma pública en Microsoft SharePoint y Windows SharePoint Services. Las vulnerabilidades más graves podrían permitir la elevación de privilegios si un usuario hace clic en una dirección URL especialmente diseñada o visita un sitio web especialmente diseñado. En las vulnerabilidades más graves, los usuarios de Internet Explorer 8 e Internet Explorer 9 que exploren un sitio de SharePoint en la zona Internet están menos expuestos porque, de forma predeterminada, el filtro XSS en Internet Explorer 8 e Internet Explorer 9 contribuye a bloquear los ataques en la zona Internet. No obstante, el filtro XSS en Internet Explorer 8 e Internet Explorer 9 no está habilitado de forma predeterminada en la zona Intranet.

Hasta la próxima.
Fuente: Microsoft

WINDOWS AZURE™ INTRODUCCIÓN A LA SEGURIDAD

Información General
Windows Azure es una plataforma de informática en nube que ha sido diseñada para proporcionar un host escalable y confiable para aplicaciones de Windows en funcionamiento en la nube.

El entorno de nube por diseño proporciona escalabilidad, confiabilidad y disponibilidad –pero al mismo tiempo, también debe proporcionar garantías de que hospedar aplicaciones y guardar datos en la nube es seguro.

Dudas acerca de la seguridad, la privacidad, la confiabilidad y el control operacional encabezan la lista de barreras potenciales al uso de soluciones de informática en nube. Por consiguiente, Windows Azure usa una matriz de controles de seguridad y de directivas de privacidad para asegurar la máxima seguridad para datos y aplicaciones.

La seguridad es un sujeto multidimensional, que comprende la seguridad física, la seguridad de la red, la seguridad del host, la seguridad de las aplicaciones, y la seguridad de los datos. Para establecer una solución segura, se deben tener en cuenta todas estas dimensiones.

Así como el proveedor de nube es responsable de la máquina y del sistema operativo, también responde por la seguridad, lo cual significa que el proveedor de nube debe manejar los dominios de la seguridad física, la seguridad de la red y la seguridad del host.

Windows Azure es una plataforma PaaS, que se utiliza para el hospedaje de aplicaciones. Así, se libera al cliente de la necesidad de hacerle mantenimiento a la máquina, a la red y a l sistema operativo. El cliente es responsable únicamente de la aplicación.

Este documento describe cómo Windows Azure utiliza una amplia gama de controles de seguridad para cumplir con sus responsabilidades como un proveedor PaaS y para proporcionar tecnologías de seguridad que ayuden a sus clientes a asegurar sus aplicaciones y datos en la nube.

¿Qué es la seguridad?
La seguridad es la habilidad de proteger algo (por ejemplo, el software), de cualquier peligro o amenaza.

Es imposible lograr la seguridad total; solo se puede procurar hacer lo mejor posible para obtener una seguridad máxima. El aspecto más importante de la seguridad es que es un tema de todo o nada: si un dominio de seguridad permanence desprotegido, todos los controles de seguridad que se implementaron en otros dominios pierden valor.

En el campo del software, el problema de seguridad comúnmente se divide en los siguientes dominios:

• Seguridad física: Quién tiene acceso físico a los servidores? Quién puede implementar revisiones e instrumentos en los servidores? Si una persona no autorizada puede accede a los servidores e implementar instrumentos en él, esa persona es dueña y la seguridad ha fallado.
• Seguridad de red: Qué tan protegida está la comunicación entre el servidor y la aplicación? Si una persona no autorizada pude olfatear los datos o ejecutar un ataque de tipo “Man in the middle” o algún otro ataque de redes (como DDoS), esa persona se ha adueñado del servidor y la seguridad ha fallado.
• Seguridad de host: Qué tan protegido y actualizado está el sistema operativo? Revisiones de seguridad proporcionan una mitigación de riesgos para brechas a la seguridad descubiertas recientemente. Si el sistema operativo no es revisado con regularidad, aún es susceptible a este tipo de ataques. Qué tan aislado está el host? Un host puede tener influencia sobre otro? Si una persona no autorizada posee un host vecino y puede usarlo para ejercer influencia sobre un host, esa persona es dueña del servidor y la seguridad ha fallado. El host tiene funciones y/o instrumentos innecesarios que pueden ser utilizados por una persona no autorizada para montar un ataque? En la medida en que se instale un mayor número de funciones y herramientas en el host, asimismo se amplía la superficie expuesta a ataques.
• Seguridad de aplicaciones: Cómo maneja una aplicación los temas de Por seguridad? Sólo la aplicación conoce sus asuntos y los escenarios de uso; es por consiguiente la aplicación la que está al mando, y nadie debería tener la facultad de usar las capacidades legítimas de la aplicación para montar un ataque. Por ejemplo, si una persona no autorizada puede usar la aplicación para tener acceso a la base de datos, esa persona es dueña del servidor y la seguridad ha fallado.
• Seguridad de datos: ¿Qué tan bien protegidos están los datos de un acceso no autorizado? Los datos están cifrados? Qué tan aislada está la base de datos? Si una persona no autorizada puede tener acceso a los datos, esa persona es dueña del servidor y la seguridad ha fallado.
• Seguridad humana y organizacional: Las personas deben usar la aplicación; de lo contrario, la aplicación es inútil. Por consiguiente, por diseño, estas personas deben tener acceso a los datos y tener la posibilidad de ejecutar los escenarios de uso.
Si una persona no autorizada puede manipular a las personas para obtener acceso a los datos o para ejecutar escenarios de uso maliciosos, esa persona es dueña del servidor y la seguridad ha fallado. ISO 27002 (previamente 17799) es un ejemplo de estándar que maneja los aspectos humanos y organizacionales de seguridad de IT.

La Plataforma como un Modelo de seguridad de servicio
Las soluciones de informática en nube se pueden dividir en tres categorías principales:

Infraestructura como servicio (IaaS):
El proveedor de servicios proporciona máquinas virtuales que funcionan en un centro de datos compartido como un servicio. Los clientes instalan y ejecutan sus aplicaciones en estos equipos como si estuvieran ubicados en el centro de datos del cliente.

Plataforma como servicio (PaaS):
El proveedor de servicios proporciona un entorno en el que puede ejecutar aplicaciones.

Software como servicio (SaaS):
El proveedor de servicios proporciona una aplicación en funcionamiento en la nube que ejecuta las transacciones de negocios del cliente.

En el caso de software local tradicional, toda la responsabilidad recae sobre el dueño del software. En Infraestructura como servicio (IaaS), el proveedor es responsable por la infraestructura física, pero todo, desde el sistema operativo en adelante, está bajo la responsabilidad del dueño. En Plataforma como servicio (PaaS), el dueño es responsable únicamente de la aplicación. En Software como servicio (SaaS), el cliente únicamente usa la aplicación y no tiene ninguna responsabilidad. Ver la Figura 1.

Estas responsabilidades incluyen problemas de seguridad. En PaaS, el proveedor en nube tiene que proporcionar los controles de seguridad en todos los casos, incluyendo el dominio de las aplicaciones. La seguridad de aplicaciones representa la frontera entre la responsabilidad del cliente y la responsabilidad del proveedor.

Windows Azure es una clásica solución tipo PaaS. Este document describe cómo Microsoft cumple con sus obligaciones como proveedor PaaS.

Asegurar el Centro de datos
La seguridad física es el dominio más fundamental de la seguridad. Si el servidor en el que la aplicación se encuentra no está protegido físicamente, obviamente no está seguro.

Windows Azure se ejecuta en centros de datos distribuidos geográficamente, que comparten espacio y utilidades con otros Servicios de Microsoft en Línea. Los centros de data de Microsoft están asegurados “24/7” (veinticuatro horas al día, siete días a la semana), y emplean varias medidas para proteger las operaciones de fallas de energía, de intrusiones físicas y de interrupciones de la red. Estos centros de datos cumplen con estándares de la industria para la seguridad física y para la confiabilidad, y son manejados, supervisados y administrados por personal de operaciones de Microsoft.

Microsoft utiliza mecanismos de acceso estándares en la industria para proteger tanto la infraestructura física de Windows Azure como las instalaciones de los centros de datos. El acceso se limita a un muy reducido número de personal de operaciones y se autentica usando sistemas de acceso de última generación, con control biométrico.

La importancia del cumplimiento de los reglamentos ha aumentado dramáticamente con la proliferación de estándares globales tales como ISO 27001 y Safe Harbor, entre muchos otros. Certificaciones confiables de terceros proporciona un mecanismo bien establecido para demostrar la protección de los datos del cliente sin por ello conceder excesivo acceso a equipos de auditores independientes que podrían amenazar la integridad de la plataforma global.

Windows Azure opera en la infraestructura de Microsoft Global Foundation Services (GFS), partes de la cual están certificadas por ISO 27001. ISO 27001 es reconocido a nivel mundial como uno de los mejores estándares internacionales de manejo de seguridad de la información. Adicionalmente, Microsoft Corporation es signatario de Safe Harbor y está comprometido con cumplir con todas sus obligaciones bajo los reglamentos estipulados por el Safe Harbor Framework.

Aunque la responsabilidad del cumplimiento de las leyes, los reglamentos, y los requerimientos de la industria permanece como responsabilidad de los clientes de Windows Azure, Microsoft está comprometido a ayudar a sus clientes a lograr el cumplimiento con todos los otros estándares requeridos.

Para más información sobre la seguridad que proporciona Microsoft Global Foundation Services (GVS), por favor visite:

http://www.globalfoundationservices.com

Asegurar la red
El segundo dominio de seguridad que está bajo la responsabilidad del proveedor de nube es el de la red. Las redes de Windows Azure están diseñadas para mitigar el riesgo tanto de ataques que se originen del internet como de aquellos ataques provenientes del interior del centro de datos por nodos maliciosos implementados como roles de Azure.

Cada Rol de Azure se implementa en un equipo virtual separado (por ejemplo, un invitado VM), aislado del Internet y de otras partes de la infraestructura de Windows Azure con el uso de VLANS. Los VLANs dividen la red de tal manera que no es posible la comunicación entre VLANs sin pasar por un enrutador (router), lo cual previene que un nodo comprometido pueda falsificar tráfico por fuera de su VLAn excepto a otros nodos en su VLAN, además de que le prohíbe “escuchar” tráfico que no va desde o hacia su VLAN.

Hay tres VLANs en funcionamiento. Los Azure Role VMs se implementan al VLAN principal, mientras que los nodos de Fabric Controller (FC) responsables de implementar nuevos roles y de supervisar los nodos existentes funcionan en un VLAN separado. Un dispositivo VLAN contiene la red confiable y otros dispositivos de infraestructura. La comunicación es permitida del FC VLAN al VLAN principal, pero esta comunicación se debe iniciar desde el FC VLAN y no se podrá iniciar desde el VLAN principal. La comunicación también está bloqueada desde el VLAN al dispositivo VLAN. Esto asegura que aún si un nodo implementando código del cliente está comprometido, no podrá atacar nodos en el FC o en dispositivos VLAN.

La comunicación con el invitado VM se asegura usando tres capas o niveles de protección más: filtrado de paquetes, un firewall de IP tradicional, y comunicación segura.

Filtrado de paquetes
El hipervisor funciona directamente sobre el hardware y divide un nodo en un número variable de VMs. Cada nodo también tiene una máquina “raíz” virtual, que implementa el sistema operativo del host sobre sistemas controlados por hipervisores.

El hipervisor y la raíz del sistema operativo proporcionan filtros de paquetes para la red, que aseguran que invitados VMs no confiables no puedan generar tráfico de identidad suplantada, recibir tráfico no dirigido a ellos, dirigir tráfico hacia extremos de infraestructura protegidos, ni enviar o recibir tráfico de difusión inapropiado.

Firewalls de IP
En la definición de servicio es posible definir extremos para que Azure Roles los exponga. La definición del extremo contiene el protocolo y el puerto a ser utilizando, y así actúa como unas reglas de firewall simple para el invitado VM. Los extremos se pueden definir para aceptar conexiones del internet o de roles que pertenezcan a la misma aplicación. Conexiones entre instancias de Roles de diferentes aplicaciones se consideran conexiones de internet. El FC aprovisiona los VMs que estén implementando roles de Azure, y por consiguiente sabe cuáles direcciones de IP pertenecen a cuáles roles.

Para hacer respetar la política de firewall que permita la comunicación interna, sólo el FC puede configurar el Fabric Agent (FC) con la lista de las direcciones IP de los roles a ser usados por los filtros de paquete, lo cual solo permite la comunicación al interior de la aplicación para legitimar direcciones legítimas de IP.

Azure Connect permite emular un VLAN que contenga roles de Azure en servidores locales. Un escenario común es la creación de un recurso compartido de archivos en un rol de Azure o el uso de Escritorio remoto para supervisar el estado de un rol específico. Profesionales de IT pueden supervisar roles específicos al utilizar Escritorio remoto de la misma manera en que pueden manejar servidores locales. Instalar herramientas en el VM remoto también es un requerimiento común de IT, que se logra usando un recurso compartido de archivos y el VM del rol.

De manera predeterminada, todos estos protocolos están bloqueados por el firewall VM de invitado. Clientes deben fijar las reglas de firewall de manera explícita para permitir tal comunicación adentro del VM.
Comunicación segura
Existen distintos tipos de canales con los cuales los roles de Windows Azure se pueden proteger:

• De cliente a Rol: Los roles apoyan el enlace de SSL con el uso de un certificado, generado por el cliente, que se carga a la configuración en el portal.
• SMAPI: Service Management API (Administración de Servicios API) funciona sobre REST y se debe proteger con autenticación mutua SSL con el uso de un certificado autofirmado que se carga a la configuración de suscripción en el portal.
• Interna: Toda la comunicación entre componentes internos de Windows Azure está protegida con SSL. En la mayoría de casos, los certificados de SSL son autofirmados. Las excepciones son certificados para los controladores de fábrica y certificados para conexiones que se pueden acceder de fuera de la red de Windows Azure (tales como el Servicio de almacenamiento).
• Del rol a SQL Azure. El SQL Azure puede forzar el cifrado SSL con todas las conexiones del cliente, lo cual asegura los datos sobre de la transferencia.
• Cuando se define la conexión de cadena a SQL Azure, los programadores deben usar los parámetros de Encrypt=True y de TrustServerCertificate.

Asegurar el host
El tercer dominio de seguridad que está bajo la responsabilidad del proveedor de la nube es el de Host y el Sistema Operativo (OS).

La virtualización es una de las tecnologías impulsoras detrás de la habilidad de servicios de nube de rápidamente escalar o desescalar (scale up or down), según la necesidad. Sin embargo, sí requiere de una administración seria y reflexiva, ya que las barreras previamente “duras” entre sistemas se virtualizan y posiblemente se pueden exponer a nuevos ataques vectores.

En Windows Azure cada Rol se ejecuta dentro de su propia virtual machine (VM) o máquina virtual. Cada máquina virtual tiene 1, 2, 4 u 8 CPUs virtuales y se le asignan hasta 14 GM de memoria. Las VMs ejecutan una versión especial de Windows Server 2008 o de Windows Server 2008 R2 al que se le instala un servidor específico de OS software (IIS, .NET, framework, etc.), dependiendo del Rol. A la VM además se le da un número muy limitado de controladores de dispositivo.

No hay almacenamiento de larga duración en nodos individuales de programación. No se garantiza que datos escritos en los discos locales persistan a través de la instalación y desinstalación de las máquinas virtuales. Cualquier dato que requiera durabilidad debe almacenarse en los servicios de almacenamiento de Azure Storage.

Windows Azure utiliza su propio hipervisor, una capa o nivel de virtualización desarrollada por Microsoft y que se construye tomando en cuenta las lecciones aprendidas porHyper-V. Funciona directamente sobre el hardware y divide el nodo en un número variable de máquinas virtuales (VMs). Cada nodo también tiene una máquina virtual de “raíz”, que ejecuta el sistema operativo del host en sistemas controlados por hipervisor. Azure usa una versión desmontada o simple de Windows Server que incluye sólo aquellos componentes que son necesarias para hospedar VMs , como el agente Fabric Controller. Esto se hace tanto para mejorar rendimiento como para reducir la superficie expuesta a ataques.

Una barrera crítica es el aislamiento de la VM raíz de las VMs invitadas y las VMs invitadas una de otra. Esta barrera la maneja el hipervisor y el OS raíz. La pareja del hipervisor y el OS raíz pondera décadas de experiencia de Microsoft en temas de seguridad de sistema operativo, así como aprendizaje más reciente del Hyper-V de Microsoft, para proporcionar un fuerte aislamiento de VMs invitadas.

Windows Azure revisa el Hard Drive Virtual (VHD) que regularmente contiene el sistema operativo. El cliente puede sin embargo pedir usar una versión específica del sistema operativo si una o varias revisiones interfiere con la aplicación del cliente.

Los clientes esperan que sus aplicaciones estén protegidas de cambios no autorizados. El mecanismo principal de protección de la integridad para datos de clientes recae sobre el diseño de la VM en sí. Cada VM está conectada con tres VHDs locales:
• El D: la unidad de disco D contiene una de varias versiones del sistema operativo del invitado, seleccionable por parte del cliente, todas de las cuales se mantienen actualizadas con las revisiones respectivas.
• El E: la unidad de disco E contiene una imagen que construye el FC basado en el paquete que el cliente proporciona.
• El C: la unidad de disco C contiene información de configuración, archivos de paginación y otros tipos de almacenamiento.

Este diseño preserva estrictamente la integridad del sistema operativo subyacente y las aplicaciones del cliente.

Seguridad de Aplicaciones
La Seguridad de Aplicaciones representa la barrera entre las responsabilidades de seguridad del proveedor de nube PaaS y aquellas del cliente.

Las aplicaciones que se hospedan en entornos de nube se consideran aplicaciones web y por consiguiente deben cumplir con los reglamentos de mejores prácticas de seguridad de aplicaciones web.

El diseño y la implementación de aplicaciones web debe tomar en cuenta los siguientes temas.
• Validación de entrada: se deben validar todas las entradas que transgredan las barreras de la confianza.
Una buena validación puede mitigar un alto porcentaje de ataques presentes y futuros. Esta validación generalmente es simple y barata pero muy efectiva.
Existen dos estrategias principales que se usan para ejecutar la validación: la “Lista blanca” y la “Lista negra”. La validación de lista blanca define un patrón de entradas válidas; todas las entradas que siguen el patrón se permiten, mientras que otras entradas se rechazan. Cuando tales patrones no se pueden definir, en su lugar se puede crear una lista negra de entradas defectuosas. Si se detectan entradas defectuosas, éstas se rechazan.
• Autenticación: identifique el usuario. Casi todas las aplicaciones web necesitan saber quién origino la solicitud.
• Autorización: verifique los permisos concedidos al usuario y verifique que sólo las puedan ejecutar aquellas personas con los permisos relevantes. Si se solicita una operación y el usuario no tiene los permisos requeridos, se debe negar la solicitud.
• Administración de configuración: Proteja información confidencial que pueda aparecer en la configuración de la aplicación, tal como las cadenas de conexión o las reglas de negocio. La administración de cambios de aplicación (i.e., nuevas versiones) es un proceso de alto riesgo que se debe manejar con sumo cuidado.
• Información confidencial: identifique y asigne información confidencial a políticas de seguridad.
• Administración de sesiones: Proteja el estado (i.e., información almacenada a través de una sesión de una ejecución de proceso de negocio).
• Criptografía: Utilice algoritmos criptográficos confiables. Controle claves de cifrado.
• Manipulación de parámetros: proteja intercambio de parámetros entre distintos módulos de la aplicación (ej., parámetros de http intercambiados entre páginas web).
• Administración de excepciones: corrija y registre todas las excepciones. Las excepciones contienen información confidencial sobre la aplicación. Dicha información es crítica para cualquier persona que esté intentando montar un ataque, mientras que el usuario final generalmente no necesita esa información o no necesita ser expuesto a tal información.
• Auditoria y registro: identifique situaciones anormales comparándolas a estados normales de aplicación.
Si un problema surge, es importante rastrearlo, y sin auditoría y registro esto es imposible. Los administradores deben saber tan pronto como posible si algo anda mal y si la aplicación puede estar expuesta a algún tipo de ataque. Para que esto ocurra, las situaciones anormales deben ser identificables inmediatamente. La auditoría y el registro proporcionan la información de base para la evaluación del estado de la aplicación.

Más información sobre seguridad de aplicaciones web se puede encontrar en el Security Guide, en MSDN, el White Paper en Security Best Practices For Developing Windows Azure Applications, y en the Open Web Application Security Project.

Confianza parcial
Uno de los principios más básicos para escribir código seguro es “run with least privilege” (ejecutar con el privilegio mínimo). Hablando en términos prácticos, esto quiere decir que el código de la aplicación nunca debe tener más permisos de los que realmente necesita. Windows Azure por consiguiente proporciona dos niveles de directiva de seguridad de acceso al código (CAS) bajo los cuales los roles se pueden ejecutar: plena confianza y confianza parcial.

Bajo confianza parcial, las siguientes restricciones aplican:
• No se permiten llamadas a código nativo.
• No se permite acceso a bibliotecas y recursos nativos.
• No se permite acceso a Diagnósticos de Windows Azure via la Librería administrada por Windows Azure.
• El acceso a lectura de sistema de archivo se otorga para el directorio de aplicación y para almacenes locales nombrados. El Acceso de Escritura y el acceso Append sólo se otorga a almacenes locales nombrados.
• No se otorga permiso de acceso al registro.
• Acceso solamente a las variables de entorno TEMP y TMP.
• No se otorga permiso de acceso al Registro de eventos.

Confianza plena se requiere en los siguientes escenarios:

• Uso de FastCGI o de PHP
• Migración de servicios tradicionales web a la nube
• Invocación de roles y generación de subprocesos (nativos o administrados)
• Llamadas a bibliotecas nativas vía P/Invoke

Si no se requiere ninguno de los anteriores, es recomendable utilizar el nivel de confianza parcial de Windows Azure. Esta opción minimiza la superficie de ataque del rol en cuestión.

Security Development Lifecycle (Ciclo de vida del desarrollo de Seguridad)
El desarrollo seguro debe comenzar tan temprano como posible y debe continuar a través del ciclo de vida del software.

Los grupos de desarrollo internos de Microsoft usan el Security Development Lifecycle (SDL), que traduce “Ciclo de vida del desarrollo de seguridad”, para lograr la seguridad máxima para todos sus productos. El SDL se usa para lidiar sistemáticamente con las amenazas de seguridad que pueden estar inherentes en el producto de software. El SDL es un grupo de procesos y herramientas diseñado para minimizar el número y la severidad de las vulnerabilidades en productos de software. El SDL abarca educación de personal de desarrollo, procesos seguros de desarrollo, y la responsabilidad de individuos y de equipos de producto, todas las anteriores para la construcción constante de software más seguro cada vez.

El SDL trata amenazas de seguridad en todo el proceso de desarrollo por medios que incluyen la modelización de amenazas durante el proceso de diseño; la adhesión a las mejores prácticas de desarrollo y a los estándares de seguridad de código durante la codificación; y el requerimiento de varias herramientas para la evaluación y la comprobación antes de la implementación. Estos chequeos proactivos durante el desarrollo hacen que el software sea menos vulnerable a posibles amenazas después de su implementación, y el SDL proporciona una metodología estructurada y coherente para su aplicación. Estas metodologías, que reciben el apoyo de un comité ejecutivo de seguridad, han ayudado a Microsoft a desarrollar software más seguro.

Windows Azure en sí no es ninguna excepción, pues el programa integra en su totalidad los parámetros de SDL. Microsoft requiere que el SDL se cumpla para cualquier software desarrollado por Microsoft implementado en Windows Azure. Microsoft recomienda que las aplicaciones del cliente que se implementen en Windows Azure también se desarrollen de acuerdo al SDL.

Identidad
Tal como se describió anteriormente, la autenticación y la autorización son desafíos básicos que cualquier aplicación segura debe tratar. Ambos temas requieren que las aplicaciones procesen la identidad. Existen dos tipos básicos de administración de identidad: basada en roles y basada en notificaciones.

En la administración de identidad basada en roles, la aplicación está encargada. El usuario suministra sus credenciales, que la aplicación utiliza para a ejecutar la autenticación. La identidad del usuario luego se mapea a los grupos, y los permisos se otorgan de acuerdo a la membrecía de grupo. La autorización basada en roles es popular, y la mayoría de aplicaciones tradicionales la usan para manejar identidades. Típicas tecnologías de autorización basada en roles son Windows Identity (e.g., Domain Join; Kerberos), ASP.NET, proveedores de suscripciones, y SQL.

En la administración de identidad basada en notificaciones, en cambio, la autenticación se ejecuta por fuera de los límites de la aplicación. Las aplicaciones establecen relaciones de confianza con Security Token Services (STSs). Los usuarios se autentican usando un STS y reciben un token que contiene una recopilación de claims, o notificaciones (i.e., piezas de información sobre el usuario). El token se firma y opcionalmente se cifra usando la clave pública de la aplicación.

Cuando una aplicación recibe un token, el usuario ya ha sido autenticado; lo único que tiene que hacer es abrir el token y procesar la información contenida de acuerdo a sus necesidades. La identidad basada en notificaciones permite una federación sofisticada y escenarios de delegación. La confianza se puede establecer entre diferentes STSs: un cliente puede autenticar comprobando la identidad contra su STS local y enviar el token que recibe al STS de confianza de la aplicación. Este STS hará un mapeo de las notificaciones en el token recibido y las usará para crear un nuevo token, que se le proporcionará a la aplicación.

Típicas tecnologías de autorización basadas en notificaciones son ADFS 2.0, WIF y Azure AppFabric Access Control Service (ACS).

Windows Azure tiene compatibilidad tanto con autorización basada en roles como con la autorización basada en notificaciones.
La autorización basada en roles típicamente se usa en los siguientes escenarios:
• Migración a la nube de una aplicación existente que use autorización basada en roles.
• Escenarios simples en los que no se requieran ni federación y delegación
• Administración de identidad sencilla que pueda ser manejada por la aplicación.

La identidad basada en notificaciones es más sencilla y más ágil. Factoring authentication out of your applications presenta muchos beneficios para programadores, profesionales de IT y usuarios. Dicho de manera sencilla hay menos cuentas para que todos manejen, y la centralización de autenticación que resulta hace que sea más fácil hacer un upgrade a métodos más fuertes de autenticación a medida que estos aparecen, e incluso a federar la identidad con otras plataformas y organizaciones.

Construir un STS no es una tarea sencilla, pero afortunadamente Azure AppFabric (parte de la plataforma de Windows Azure) introduce un STS escalable, confiable y sencillo, que puede usarse tanto en la nube como en aplicaciones locales.

Seguridad de datos
Windows Azure proporciona una infraestructura de almacenamiento de manera paralela a sus servicios de hosting que ejecutan código. Tres principales infraestructuras de datos se suministran en la plataforma de Windows Azure: Windows Azure Storage, SQL Azure, y el caché de Azure AppFabric.

Los clientes únicamente estarán dispuestos a almacenar datos en la nube si están confiados de que la nube es segura y privada. Por eso no es sorprendente que todas las tecnologías de almacenamiento contienen una amplia gama de controles para la implementación de control de acceso a datos ni que dichas tecnologías cumplen con las políticas de GFS para la conservación de políticas de privacidad.

Control de acceso
Windows Azure Storage tiene un modelo simple de control de acceso. Cada suscripción a Windows Azure puede crear una o más Storage Accounts (Cuentas de almacenamiento). Cada Cuenta de almacenamiento tiene una única clave secreta que se usa para controlar el acceso a todos sus datos. La información almacenada en tablas y colas de Windows Azure es accesible únicamente por medio de la autenticación de Azure Storage con la presentación de la clave secreta.

En contraste, los Blobs tienen una política más sofisticada de acceso a datos. La información almacenada en blobs puede que deba ser accesible al público en general. Ejemplos comunes son archivos de medios, tales como imágenes y películas que deben ser directamente accesibles desde un explorador. Los contenedores o envases de blob por lo tanto pueden marcarse como “públicos”, lo cual permite acceso a todos sus blobs sin la necesidad de presentar una llave.

En un escenario más restringido, los blobs se pueden hacer accesibles por un período limitado de tiempo y con un grupo específico de permisos de accesos, sin la necesidad de una clave. En estos casos es posible crear una Shared Access Signature (SAS), o Firma de acceso compartido. Las SAS son direcciones URL de blob especiales que contienen información de acceso de datos tal como duración y permisos concedidos. Los URLs se firman con la clave de la cuenta de almacenamiento. Estos URLs se supone deben ser distribuidos únicamente a los usuarios que deben tener acceso. Solicitudes de blob utilizando el URL normal serán negadas, pero usando una SAS es posible acceder al blob durante un período predeterminado de tiempo.

Es posible restringir el escenario un poco más mediante la creación de una referencia de una SAS a una Container-Level Access Policy (Directiva de acceso de nivel de contenedor). Una directiva de acceso de nivel de contenedor se puede modificar o revocar en cualquier momento, lo cual proporciona mayor flexibilidad y control sobre los permisos otorgados.

Integridad, disponibilidad y confiabilidad de datos
La disponibilidad y la confiabilidad de los datos son preocupaciones principales de clientes con respecto al almacenamiento de datos en su nube. Los clientes deben estar seguros de que sus datos siempre estarán inmediatamente disponibles y que fallas de hardware nunca causaran una pérdida de sus datos.

Datos almacenados en todos los Servicios de almacenamiento de Windows Azure se replican en tres nodos físicamente separados en la misma región geográfica para facilitar alta disponibilidad y para minimizar el impacto de fallas de hardware.

Todas las operaciones de almacenamiento, incluyendo delete (eliminación), están diseñados para ser coherentes al instante. La ejecución exitosa de una operación de delete remueve todas las referencias al ítem de datos asociado, y no se puede volver a acceder vía las APIs de almacenamiento. Todas las copias del ítem de datos eliminado después se recopilan en la basura. Todos los bits físicos serán sobrescritos cuando el bloqueo de almacenamiento asociado sea reutilizado para almacenar otros datos

Windows Azure se ejecuta bajo las mismas políticas y principios de seguridad que gobiernan todos los centros de datos de Microsoft. Global Foundation Services (GFS) proporciona la infraestructura de la nube para estos servicios enfocándose en la adherencia a varios estándares regulatorios, estatutarios, y de industria. La política de eliminación es sólo un ejemplo de varias políticas de integridad y de privacidad con las cuales cumple la infraestructura de Azure.
Criptografía

El cifrado de datos en almacenamiento y en tránsito puede ser útil para clientes de Windows Azure para que se ajusten a las mejores prácticas para asegurar la confidencialidad y la integridad de los datos.

Actualmente no existe compatibilidad para cifrado nativo ni en Windows Azure Storage ni en SQL Azure. Datos en Windows Azure Storage se almacenan como texto no cifrado, y no existe una opción para cifrar los datos de otro modo que a través del desarrollo de un código propio de cifrado. El framework o marco de .Net proporciona la totalidad de API necesario para crear código para cifrar los datos del cliente. SQL Azure actualmente no tiene compatibilidad con la característica de Transparent Data Encryption disponible en el Servidor Microsoft SQL.

Para datos que se acceden solo por servicios hospedados por Windows Azure, ésta no es una preocupación principal. El cifrado de datos en un servicio hospedado requiere que todas las instancias del servicio tengan acceso a las claves de cifrado, y si un servicio escoge cifrar datos éstas llaves deben almacenarse en certificados mantenidos en el almacén de certificados de Windows Azure. Sin embargo, las políticas de seguridad que han implementado los centros de datos de Microsoft ayudan a asegurar que los atacantes no puedan obtener acceso físico a los equipos que estén implementando servicios de Azure o a los discos que implementan almacenamiento de Azure. En consecuencia, las políticas de destrucción de datos eliminan la posibilidad de que los datos se tornen accesibles de manera inadvertida, a otros suscriptores de Azure.

Por lo tanto, en la medida en que un servicio implemente un nivel apropiado de seguridad de transporte (es decir, SSL), la única manera viable en que un atacante podría obtener acceso a los datos sería si obtuviese o robase los detalles de Windows Live ID utilizados por la suscripción de Azure o el Certificado de Administración utilizado para administrar los servicios hospedados. Un atacante tal tendría en todo acceso al almacén de certificado y por consiguiente los medios de descifrar los datos, de tal manera que el cifrado en este escenario sería poco provechoso.

El cifrado es valioso si usted está accediendo a datos localizados en almacenamiento de Azure desde aplicaciones ejecutadas en computadores por fuera del entorno Azure, en lugar de ser ejecutadas desde servicios hospedados en Azure. En este escenario, usuarios diferentes que implementen estas aplicaciones pueden tener que mantener confidencialidad unos de otros. Usted puede cifrar datos al interior de una aplicación del cliente, por ejemplo, usando una clave privada de AES, conocida sólo por el usuario, que se genera en un equipo del cliente o en otro lugar dentro de la empresa. La carga cifrada luego se carga al almacenamiento de Azure. Los datos los puede descifrar únicamente el usuario proporcionando esta clave (que se puede almacenar en el perfil del usuario usando DPAPI). Otros usuarios pueden generar sus propias claves privadas, y estas claves no se deben revelar. Una aplicación del cliente, tal como un explorador web, que trate de leer los datos cifrados directamente de almacenamiento Azure sin proporcionar la clave apropiada no podrá descifrar los datos.

Conclusión
La seguridad es una de las principales preocupaciones de los clientes cuando están considerando hospedar aplicaciones en la nube.

Windows Azure es una clásica solución PaaS, y como tal se encarga de todos los dominios de seguridad bajo la responsabilidad del proveedor de nube. PaaS se usa para hospedar y ejecutar aplicaciones del cliente, y como tal no puede ser responsable por el código del cliente. Los clientes deben implementar las mejores prácticas de seguridad en sus propias aplicaciones. En conjunción con los atributos de seguridad que la infraestructura provee, es posible crear una ejecución de aplicaciones segura en la nube.

Algunos aspectos de soluciones de seguridad que el proveedor de nube provee son de hecho mejores que aquellos obtenibles en un entorno local. Por ejemplo, la seguridad física de los centros de datos de Windows Azure es probablemente mayor que la suya propia. La protección de red de Windows Azure, el Host Isolation (Aislamiento de host) y el endurecimiento del sistema operativo son todos más seguros que aquellos que se encuentran en el hospedaje tradicional. Por consiguiente, hospedar su aplicación en la nube probablemente mejora su seguridad.


Hasta la próxima

Fuente: Material de Microsoft para el MVA

Información General de Windows Azure Security

Les adjunto el presente artículo, cuya autoría es de David Tesar y es propiedad de Microsoft y sirve como contenido para cursar la carreras del MVA (Microsoft Virtual Academy).

Información general
Las aplicaciones de nube se distribuyen por diseño. Asegurar la red externa que conecta la nube con la red interna adentro de la fábrica de Azure claramente es un componente crítico de seguridad de la plataforma. En el hospedaje tradicional, los clientes usan firewalls (servidores de seguridad) y otras configuraciones de red para proteger sus aplicaciones, sus datos y su infraestructura. Windows Azure cambia esa realidad porque en entornos de PaaS el cliente está escudado de casi toda la responsabilidad sobre la seguridad de red. Microsoft, como proveedor de nube, es responsable de la protección de la red sobre la cual se ejecuta la nube.

Los clientes que implementan sus datos y aplicaciones en Windows Azure deben estar seguros de que ataques de red tales como sniffing (olfateo) y ataques de tipo “man in the middle” están absolutamente mitigados dentro de los límites de la nube.

Este documento describe las medidas de seguridad empleadas por Windows Azure en la capa de redes.

Arquitectura de red
Windows Azure contiene cuatro tipos de nodos principales: nodos de Fabric Controller, nodos de cómputo, nodos de almacenamiento y nodos de infraestructura.

El Fabric Controller (FC) es el kernel del sistema operativo de Windows Azure. El FC automatiza casi todo, al aprovisionar, almacenar, enviar, supervisar y comandar las máquinas virtuales (VMs) y los servidores físicos que componen Azure. El FC está diseñado para satisfacer solicitudes y políticas de usuario y para optimizar y simplificar la implementación.

Aislamiento
El tejido de red de Windows Azure contiene tres diferentes redes aisladas:
• El VLAN principal – interconecta nodos de cliente no de confianza
• El VLAN FC – contiene FCs de confianza y sistemas de apoyo
• El VLAN de dispositivo – contiene red de confianza y otros dispositivos de infraestructura.

Los VLANs se utilizan para aislar los FCs, los nodos de cómputo y los demás dispositivos. Los VLANs dividen una red de tal manera que no es posible la comunicación entre VLANs sin que pasen por un enrutador, que previene que un nodo comprometido falsifique tráfico de fuera de su VLAN excepto a otros nodos en su VLAN, además de que se le impide eavesdropping (escuchar) el tráfico que no se origina en o se dirige a sus VLANs.

Se permite la comunicación del VLAN FC al VLAN principal, pero la comunicación no puede ser iniciada del VLAN principal al VLAN FC. La comunicación también está bloqueada del VLAN principal al dispositivo VLAN. Esto asegura que si un nodo que está implementando código del cliente está comprometido, no puede atacar nodos ni en el FC ni en VLANs de dispositivo.

La Figura 1 describe las diferentes redes aisladas implementadas en Windows Azure.
Figura 1

Aislamiento de Fabric Controllers
Como el orquestador principal de gran parte del tejido de Windows Azure, controles significativos están se han implementado para mitigar las amenazas a los FCs, especialmente de Fabric Agents (FA) potencialmente comprometidos dentro de las aplicaciones del cliente. Comunicación de FC a FA es unidireccional: el FA implementa un servicio protegido por SSL que se accede del FC y responde únicamente a solicitudes. El FA no puede iniciar conexiones al FC o a otros nodos internos privilegiados. El FC analiza (parses) fuertemente todas las respuestas como si fueran comunicaciones no confiables. Adicionalmente, los FCs y los dispositivos incapaces de implementar SSL están en VLANs separadas, que limitan la exposición de sus interfaces de autenticación a un nodo comprometido que hospeda VMs.

Administración remota de Fabric Controllers
Los Fabric Controllers tienen un API accesible al RPC que acepta comandos de SMAPI y de administradores de Windows Azure. Decisiones de nivel de política son exigidos por SMAPI en el nivel de la aplicación, que únicamente generará solicitudes concernientes a los recursos del cliente, basándose en la identidad autenticada del cliente. Los FCs hacen finer-grained Access-control decisions, como corresponde a su rol de facilidad de administración de aprovisionamiento central de bajo nivel. Las conexiones a FCs se hacen vía SSL, en el que el cliente se autentica con un certificado de cliente y la certificate fingerprint (huella de certificado) determina si un llamante tiene el nivel de acceso apropiado para hacer una solicitud determinada.

Mitigación de la Denegación de Servicio o DOS
Windows Azure tiene las conexiones más amplias al internet disponibles en la industria. Los conectores se distribuyen alrededor del globo terráqueo, y así es improbable que alguien pueda lograr producir suficiente tráfico malicioso para inundar estas conexiones y cortar a Azur de la red pública.

Si una aplicación individual es atacada, es posible spin girar temporalmente varias nuevas instancias de cálculo hasta que el ataque pase, lo cual típicamente es mitigación suficiente ya que la mayoría de ataques de denegación de servicio no duran mucho tiempo. Microsoft está considerando maneras de identificar tráfico malicioso y de no bloquearlo mientras entra el tejido Azure, pero este tipo de protección aún no ha sido implementada.

Ataques de denegación de servicio que se originen al interior del tejido son parcialmente manejados por la infraestructura. Windows Azure no detecta ni bloquea tráfico malicioso, pero sí se asegura de que todos los VMs en ejecución reciban los recursos por los que pagaron. Un VM malicioso implementado en el tejido no puede consumir recursos ilimitados y causar colapso a sus vecinos, efectivamente mitigando un ataque de denegación de acceso interno.

Arquitectura de Nodos Azure
Los roles de Windows Azure se ejecutan adentro de las máquinas virtuales (VMs) implementadas en los nodos del centro.

Entre muchas otras ventajas, la virtualización permite el aislamiento completo entre los distintos códigos de cliente. Al interior de Azure, cada nodo que se conecta a extremos adentro de Windows Azure se implementa con un servidor de seguridad (firewall) que previene que suplante (impersonating) direcciones IP. Cuando dos nodos están hablando adentro de Azure, no necesitan cifrado para garantizar la identidad del otro porque las direcciones de IP son comprobadas por la red misma.

Cada máquina virtual (VM) tiene 1, 2, 4 u 8 CPUs virtuales, y se le asignan hasta 14 GB de memoria. Las VMs ejecutan una versión especial de Windows Server 2008 o 2008 R2, con un servidor específico de software de operador de servicio instalado (IIS, .NET framework, etc.), dependiendo del rol de la VM. El sistema operativo tiene un número muy limitado de drivers de dispositivo.

Windows Firewall está habilitado en cada VM. Los únicos puertos abiertos y directamente direccionables (interna o externamente) en una VM de Windows Azure son aquellos explícitamente definidos en el archivo de Service Definition (Servicio de Definición file) configurado por el cliente.

El hipervisor se ejecuta directamente sobe el hardware y divide el nodo en un número variable de máquinas virtuales (VMs). El número de VMs implementado en cada nodo depende del número de CPUs que las VMs requieren. No hay ninguna situación en la que las VMs requieran más CPUs que las que realidad existan en el cuadro.

Cada nodo también tiene una máquina virtual de “raíz”, que ejecuta el sistema operativo de host en sistemas controlados por hipervisor. Azure usa una versión simplificada de Windows Server que incluyen únicamente aquellos componentes necesarios para hospedar VMs. Esto se hace tanto para mejorar el rendimiento como para reducir la superficie expuesta a ataques.

El hipervisor y el VM de raíz aseguran que todas las VMs obtengan una porción justa de los recursos disponibles. Esto previene una situación en la que un Rol malicioso consuma todos los recursos en el cuatro, poniendo a las otras VMs en un estado de colapso.

La Figura2 demuestra cómo el acceso de datos es filtrado por el VM de raíz y fluye a través de todo el hipervisor. Todo acceso a la red y al disco por parte de los VMs es mediado por el sistema operativo de raíz.

Figura 2

El conmutador de red virtual del hipervisor filtra todo el tráfico de y hacia las máquinas virtuales, y también previene ataques basados en sniffers contra otras VMS en el mismo host. Filtros adicionales están instalados para bloquear la difusión y el tráfico de multidifusión, con la excepción de lo que sea necesario para mantener las concesiones DHCP.

Filtrado de paquetes
El hipervisor y el sistema operativo de raíz proveen la red de filtros de paquete que aseguran que VMs no de confianza no puedan generar tráfico de identidad suplantada (spoofed traffick”) no directamente direccionado a ellos, yque no puedan dirigir tráfico a extremos protegidos de la infraestructura, y de que no puedan enviar o recibir tráfico de difusión inapropiada. Nodos de almacenamiento sólo ejecutan código y configuración provistos por Winsows Azure, y así el control de acceso se ajusta para permitir únicamente el acceso de cliente, de aplicación y de administración legítimos.

Acceso de clientes a las VMs se limita a través del filtrado de paquetes en equilibradores de carga y en la raíz del OS. En particular, la depuración remota, Servicios de Terminal remotos, y el acceso remoto los recursos compartidos de archivos no se permiten de manera predeterminada. Microsoft está haciendo planes para permitirle a sus clientes habilitar estos protocolos como una opción explícita in el futura.

Microsoft permite a sus clientes especificar si las conexiones de internet se aceptan (incluyendo instancias de rol de distintas aplicaciones) y de instancias de rol dentro de la misma aplicación. Las conexiones entre instancias de rol de distintas aplicaciones se consideran como reglas de conexiones y de conectividad al internet que son cumulativas; por ejemplo, si instancias de rol A y B pertenecen a distintas aplicaciones, la A únicamente puede abrir una conexión a la B si A puede abrir conexiones al internet y B puede aceptar conexiones al internet.

El FC traduce la lista de roles en una lista de instancias de rol, y de ahí a una lista de direcciones IP. Esta lista de direcciones IP la usa el FA para programar los filtros de paquete a sólo permitir comunicación al interior de la aplicación y hacia dichas direcciones IP. Esto les permite comunicarse con el internet y enviar tráfico a cualquier rol con visibilidad desde el internet a través de sus VIPs.

Firewalls (servidores de seguridad) incorporados
Comunicación con Windows Azure viaje a través de un número de firewalls (servidores de seguridad).

- Firewall de VM invitada:
Además de filtraje de paquetes mejorado, que bloque el tráfico no autorizado, Windows Firewall está habilitado en cada VM. Los únicos puertos abiertos y directamente direccionables (Interna o externa) de tráfico de red entrante en una VM de Windows Azure son extremos definidos explícitamente en el archivo de Definición de servicio. Este archivo define los extremos tanto externos como internos:
• Un extremo externo puede recibir tráfico entrante del internet.
• Un rol de web no puede tener más de un extremo HTTP y un extremos HTTPS. Un rol trabajador puede tener cualquier número de extremos de HTTP, HTTPS y TCP.
• Un extremo interno está disponible sólo para otras instancias de rol en funcionamiento dentro del servicio; no está disponible para clientes por fuera del servicio.
• Un rol web puede tener un único extremo interno HTTP. Un rol de trabajador puede tener cualquier número de extremos internos de http o de TCP.

Visual Studio proporciona un recuadro sencillo para definir las reglas de firewall de la VM invitada. Windows Azure Connect permite la comunicación entre VMs que estén ejecutando roles específicos. Si se hace un ensayo de ejecutar protocoles de comunicación común y simple, tal como el ping o el uso compartido de archivos, el ensayo fracasará, sin embargo, porque la solicitud está bloqueada por el firewall de la VM. Es posible crear reglas de firewall que habiliten la comunicación sobre protocolos requeridos al usar tareas de inicio o al conectarse a la instancia a través del escritorio remoto.

- Firewall de la VM host
Como se describió anteriormente, el firewall de la VM host habilita la comunicación únicamente con direcciones legítimas de IP adentro de la fábrica, y realiza filtraje de paquetes sobre todo el tráfico.

Es posible habilitar o desactivar la conexión de roles de Windows Azure haciendo clic en “Permitir otros servicios de Windows Azure acceder al servidor” en las configuraciones de reglas de firewall.

Firewall para clientes (client firewall)
Éste es el firewall que se ejecuta en la máquina de cliente o al frente de la red corporativa. En ocasiones se debe configurar para habilitar su comunicación con artefactos de Windows Azure. Un ejemplo común es SQL Azure.
SQL Azure utiliza el protocolo TDS (i.e., puerto 1433) en la exacta misma manera en que lo hace en bases de datos locales, así que tecnologías de acceso a datos como ADO.NET y EF lo pueden usar de manera transparente. Para comunicarse con SQL Azure, el firewall local debe estar configurado para permitir conexiones TCP salientes sobre el puerto TCP/1433 y a recibir tráfico que se origine en el puerto 1433.
Otro ejemplo común es el bus del servicio de AppFabric. Los canales TCP al AppFabric retransmiten el uso bidireccional del puerto TCP 828 y del puerto TCP 808 de salida. El firewall local debe estar configurado para permitir esto.

Windows Azure Connect
Windows Azure Connect es un servicio de Windows Azure que crea una red segura para roles de Windows Azure. Windows Azure Connects proporciona una sencilla interfaz de usuario para configurar conexiones, protegidas por IPsec, entre roles funcionando en Winsows Azure y en computadores o máquinas virtuales (VMs) en la red organizacional local. Luego de configurar estas conexiones, instancias de rol en Windows Azure usan direcciones de IP (IP addressing) como las de otros recursos locales en red, en lugar de tener que usar alguna forma de dirección IP virtual.

Windows Azure Connect crea una red virtual segura al conectar directamente todos los sistemas habilitados para la conexión, sean éstos instancias de rol de Windows Azure o servidores locales. Todo el tráfico Connect está asegurado de extremo a extremo por IPsec. El agente Connect de Windows Azure implementado en cada equipo local establece una política de IPsec que exige autenticación mutua basada en certificados para todas las comunicaciones entre sistemas habilitados para Connect. El IPsec también asegura que el tráfico se firme y se cifre para propósitos de integridad y confidencialidad, y exige que únicamente los sistemas en los roles y grupos de extremo apropiados puedan comunicarse con el host. Los certificados digitales son aprovisionados por el servicio de Windows Azure Connect en sí.

La Figura 3 muestra cómo Windows Azure Connect conecta roles de Azure en servidores no-locales.
Figura 3

SSL
La comunicación a través de un canal seguro se recomienda en escenarios de cliente-a-fábrica. Existen distintos canales SSL que se pueden establecer con Windows Azure:
• Clientes <-> Roles de web y trabajadores
• Clientes <-> Extremos de almacenamiento; SQL Azure; Caché de AppFabric
• Roles <-> Roles sobre extremos internos
• Roles <-> Extremos de almacenamiento; SQL Azure; Caché de AppFabric

En general, la comunicación adentro del centro de datos se considera segura, así que un cana extra de SSL para este propósito es innecesaria.
Canales SSL requiere de un certificado X.509 como su “cryptographic seed”, o criptografía base. Certificados X.509 contienen la clave pública y los metadatos utilizados para intercambiar claves criptográficas que cifran el tráfico, y para comprobar la integridad de los datos enviados a través del canal. Los certificados X.509 los puede manufacturar una autoridad de certificado (CA) de confianza, que pueden validarse a lo largo de su utilización. Esto asegura que el certificado contenga claves válidas y que en realidad pertenezca a la entidad a la cual está adscrito.

Con el uso del portal de administración, el programador puede cargar certificados X.509 a cada rol y a la suscripción general. Los certificados implementados a roles se usan para establecer canales SSL con el cliente. Los certificados implementados a la suscripción se usan para la administración API de Azure

El canal SSL que se usa para administración usa autenticación mutua. Tanto el cliente como Azure se autentican mutuamente con el uso del certificado de entidad del otro.

Autenticación mutua de SSL para tráfico de control interno
Todas las comunicaciones entre componentes internos de Windows Azure están protegidos con SSL. En la mayoría de los casos, los certificados de SSL se autofirman. Existen dos excepciones: los certificados para conexiones que se pueden acceder desde fuera de la red de Windows Azure (incluyendo el servicio de almacenamiento) y los fabric controllers (FC). Los FC tienen certificados expedidos por la Autoridad de certificados (CA) de Microsoft, que se encadena de regreso a una CA raíz de confianza. Esto permite que claves públicas de FC se puedan roll over con facilidad. Adicionalmente, las herramientas de programación de Microsoft utilizan las claves públicas FC para cifrar nuevas imágenes de aplicación suministradas por programadores para proteger todos los secretos incrustados.

Administración de certificados y de claves privadas
Para disminuir el riesgo de exponer los certificados y las claves privadas a programadores y administradores, éstas se instalan a través de un mecanismo separado del código que los utiliza. Los certificados y las claves privadas se cargan vía SMAPI o vía el Portal de Windows Azure como archivos de PKCS12(PFX) protegidos en tránsito por SSL. Estos archivos pueden estar protegidos por contraseña, pero si es el caso, la contraseña se debe incluir en el mismo mensaje. SMAPI quita la protección de contraseña si necesario y cifra el blob PKCS12 SMAPI en su totalidad usando la clave pública de SMAPI. El blob luego se almacena en el almacén secreto en el FC, con un corto nombre de certificado y la clave pública como metadatos.
Los datos de configuración asociados con cada rol especifican los certificados que deben hacerse disponibles para ese rol. Cuando se crea una instancia de rol en una VM, el FC recupera el certificado apropiado, descifra el blob PKCS12, lo re-cifra usando la llave pública de transporte del FA, y lo envía al FA en el nodo. El FA en el nodo lo envía al GA en la VM que está creando la instancia de rol, y después el GA lo descifra y lo instala en el almacén de certificado de sistema operativo con una bandera que indica que la clave privada puede ser utilizada pero no exportada. Después de la instalación, todas las copias temporales de certificados y claves se destruyen. Si se requiere la reinstalación, los certificados deben ser repackaged por el FC.

Seguridad WCF
WCF es la tecnología más común para la implementación de servicios Web utilizando el marco .NET. Es completamente compatible con Windows Azure. Los roles pueden estar expuestos a los clientes como servicios WCF y como ASP.NET aplicaciones web.
WCF cuenta con un modelo de seguridad poderoso y extensible. Puede establecer canales seguros (similares a SSL) y activar autenticación y autorización con el uso de casi cualquier tecnología relevante.

WCF también está estandarizada. Implementa los estándares de seguridad de WS-*, así que también es interoperable con las principales plataformas de servicio de web.

Windows Azure expone varios de sus artefactos, tales como AppFabric Cache y el Servicio de Control de acceso AppFabric, como servicios WCF. Cuando se utiliza el bus de servicio de AppFabric para interconectar aplicaciones o cuando se esté autenticando usuarios con AppFabric ACS, el modelo de seguridad WCF se usa para asegurar el canal.

Cuando se esté exponiendo un servicio de web WCF, usted tiene la libertad de escoger entre seguridad de mensaje WCF y seguridad de transporte WCF (es decir, SSL) para proteger su tráfico.

Conclusión
Las redes son un dominio de seguridad principal, pero es también uno de los dominios que está bajo la responsabilidad del proveedor de nube PaaS. Microsoft implementa seguridad de redes para proteger sus redes internas y para asegurar canales externos conectados a la nube. Redes seguras permiten a Microsoft logar el aislamiento entre distintos componentes de la nube y mitigar las amenazas que se originan de nodos maliciosos implementados hacia la nube Microsoft está comprometido con la protección de sus redes de ataques tanto internos como externos.

El modelo de seguridad WCF es plenamente compatible con Windows Azure y se puede usar en el esfuerzo conjunto de proteger la comunicación con su aplicación.
Aplicaciones en ejecución en la nube de Windows Azure por lo tanto gozan de la mejor protección de redes disponible en el mercado. Mover su aplicación a la nube probablemente fortalecerá su seguridad de redes a comparación con las alternativas locales comunes.

A continuación ponemos un video explicativo sobre Seguridad General de Window Azure.

Hasta la próxima.

Fuente: Microsoft.