On the way to Virtualization

A partir de la versión 1610, (muy cuestionable) Cloud Management Gateway, algo así como, Puerta de Enlace de Administración en la Nube, proporciona una manera sencilla de administrar clientes de Configuration Manager en Internet.

Éste servicio en la nube, (en adelante CMG), se implementa en Microsoft Azure con su suscripción de Azure correspondiente y es el propio SCCM quien publica la configuración de CMG, incluida la información de conexión y la configuración de seguridad.

El propósito es conectar a la infraestructura de SC Configuration Manager local con un nuevo rol denominado, CMG, que viene a sustituir a un descontinuado IBCM.
Una vez implementado y configurado, los clientes podrán tener acceso a los roles de sistema de sitio locales de Configuration Manager independientemente de si están conectados a la red interna privada o a Internet.

CMG autentica y reenvía las solicitudes de cliente de Configuration Manager al punto de conexión de CMG. Estas solicitudes se reenvían a los roles en la red corporativa según las asignaciones de direcciones URL.

Se realiza con una VM en Azure, de tipo Medium
Ésta VM establece un tunel ssl q sirve de proxy desde Azure, lo cual elimina el tedio de configuración en nuestras comunicaciones que requería IBCM de nuestros proxy, firewall o balanceadores.

Junto con ésta funcionalidad, muy recomendable montar otro rol en Azure que se llama Cloud Distribution Point, en adelante CDP, que sirve para distribuir aplicaciones desde un site público en internet y se realiza con una VM de tipo Small.

Con toda ésta configuración hemos de entender que, las 2 VM en Azure generan un tráfico de red, el que sirven a los puestos clientes, que genera un coste de:

• 1 Suscripción en Azure de 2 VM. (1 Small y 1 Medium) Cada instancia de CMG admite 4.000 clientes, con dos instancias daremos mejor disponibilidad.
• 1.000 GB de tráfico. 7 €./mes aprox.

Dicho esto, contemos la realidad de mi experiencia al implementarlo:
Lo primero que tenemos que saber es que necesitamos subir de versión a Configuration Manager, obligatorio trabajar con la versión 1702.

Pero ya adelanto que os dará fallo en AZURE al implementar el rol de CMG Hay dos soluciones, subir a la versión 1706, disponible desde el 29 de agosto de 2017 o aplicar éste hotfix para CMG a la versión 1702:

https://support.microsoft.com/en-us/help/4033015/provisioning-not-completed-when-creating-a-cloud-management-gateway-in

Los requisitos

Equipos cliente y servidor de sistema de sitio que ejecuten CMG. Antes de poder usar las características de versión preliminar, hay que dar consentimiento para usarlas desde la consola de SCCM para poder seleccionarlas y permitir su uso.

Dar el consentimiento es una acción que se realiza una sola vez por jerarquía y que no se puede deshacer. Mientras no dé su consentimiento, no puede habilitar nuevas características de versión preliminar incluidas con las actualizaciones. Después de activar una característica de versión preliminar, no podremos desactivarla.

Para dar consentimiento en la consola de SCCM, vamos a Administración –> Configuración del Sitio –> Sitios y seleccionamos, Configuración de jerarquía. En la pestaña General, marcamos, Consent to use Pre-Release features.

Si ha dado su consentimiento ahora puede habilitar las características de versiones preliminares en el Asistente de actualizaciones y mantenimiento al instalar la actualización.

Previamente habremos generado 4 Certificados Web Server SSL personalizados en 2048 desde la CA interna y tener a mano el CA Root de nuestra PKI
Los certificados se usan para cifrar la comunicación de los equipos cliente y para autenticar la identidad del servicio de CMG:

Certificado Admin Azure

1. PFX (con clave privada): Para SCCM CB
2. CER (solo clave publica): Para Azure

Certificado CMG

1. PFX: Para Azure (a través de SCCM CB)

Certificado CDP

1. PFX: Para Azure (a través de SCCM CB)

La Implementación

Abrimos la consola de SCCM CB para implementar el servicio en Azure y agregamos el rol de CMG en Cloud Services:

Como se podrá observar en los próximos cinco pasos, la implementación de CMG y DP en SCCM y Azure se realiza obligatoriamente mediante el uso de certificados.

1.- Subir el Certificado de Admin Azure

Éste certificado es necesario para la suscripción en Azure, al cual he llamado, AzureAdmin.cer

2.- AzureAdmin.pfx (Para autenticar la conexión con SCCM y siempre con la terminación cloudapp.net)

El ID de suscripción lo obtenemos de AZURE y utilizaremos el Certificado de Administración al que hemos llamado, AzureAdmin.pfx al crear tanto el Cloud Management Point, como al crear Cloud Distribution Point

Desmarcar comprobación de revocación de certificados y especificamos como Certificado pfx, generado por nuestra PKI. el que hemos llamado CMGMiEmpresa.pfx especificando el servico FQDN con la terminación, cloudapp.net

Pinchar sobre Certicados de la CRL y añadir el CA Root de nuestra PKI

El resto, next, next…de tal forma que en la consola de SCCM nos quedará CMG algo así:

3.- CARoot.cer
(En la VM de Azure para CMG. Necesario para la revocación de certificados que previamente ya hemos desmarcado)

4.- CMG.pfx

Éste Certificado para Azure a traves de SCCM CB, lo hemos utilizado ya en el Punto 2

5.- DP.pfx

La misma idea, que en los Puntos 2 y 5.
El mismo ID de suscripción que obtenemos de AZURE con el Certificado de Administración, AzureAdmin.pfx

En ésta pantalla especificamos como Certificado pfx, el generado por nuestra PKI. el que hemos llamado DPMiEmpresa.pfx

En SCCM, todas las opciones del cliente se administran desde el nodo Configuración de cliente del área de trabajo Administración de su consola.
A continuación, vamos a configurar la opción Cloud Services para los dispositivos de alguna colección dentro de nuestra jerarquía y la implementaremos sobre las recopilaciones.

Sobre el Custom Device Settings de Cloud Services que recién hemos creado, botón derecho y seleccionamos Deploy para seleccionar una colección sobre la que implementarlo.

Finalmente decir que existe un bug en la versión 1706, en el componente de notificaciones online del cliente, el cual, aunque esté conectado y exista comunicación, aparece como apagado y no será hasta la reléase 1710 que Microsoft dará solución a ese bug.

La política del ciclo de vida de soporte Microsoft proporciona directrices coherentes y previsibles para la disponibilidad de soporte del producto en el momento del lanzamiento del producto y durante toda la vida del mismo. Al comprender el soporte de producto disponible, todos estaremos mejor capacitados para maximizar la administración de las inversiones en IT y planificar estratégicamente un futuro de IT exitoso.

Microsoft ofrecerá un mínimo de 10 años de soporte (5 años de soporte principal y 5 años de soporte extendido) para productos Business y Developer.

Ésta imagen enumera los sistemas operativos Windows y los paquetes de servicio de soporte del ciclo de vida.
Para obtener más información sobre la política del ciclo de vida del soporte técnico de Microsoft sobre cualquier producto o servicio, éste es el sitio web oficial:

https://support.microsoft.com/es-es/lifecycle

Existen varias medidas específicas que se hacen necesarias para mitigar contra ransomware y otras amenazas:

1. Asegurarse de tener las últimas actualizaciones de seguridad instaladas.
2. Asegurarse de tener las últimas firmas de tu proveedor de Anti Virus.
3. No abrir correo electrónico y archivos adjuntos de personas desconocidas o de fuentes que no sean confiables.

Importante. Estas medidas de seguridad son recomendaciones que pueden evitar la contaminación por ransomware, pero estos pasos solos no previenen contra las infecciones.

Recursos adicionales

Muy recomendable revisar y acceder a los siguientes recursos adicionales:

• MMPC Blog: https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities /
• Microsoft Security Tech Center: https://technet.microsoft.com/en-us/security/default
• Microsoft Security Update Guide: http://aka.ms/securityupdateguide

Ya pasó la resaca del famoso ransomware WannaCry, sin embargo siguen las amenazas de una nueva versión.
Cuando ya sabemos casi todo del malware, llega el momento de recapacitar y ver si de una vez somos capaces de aprender algo de estos casos.

En los últimos días hemos visto noticias sobre el ciberataque mundial que ha «colapsado el mundo”, con frases como que estamos ante «el mayor ciberataque de todos los tiempos» o que «estamos ante el inicio de una guerra»…

Es cierto que hacía tiempo que no se veía un ataque que fuera tan grave, global, problemático y recurrente. Sin embargo los que tenemos algo de memoria, podemos recordar más de un ataque similar hace ya muchos años. Podemos recordar casos como el LoveLetter, Slammer, Nimda, Conficker o muchos similares. Después de cada caso de estos tendemos a recapacitar, ver los errores, se corrige, se parchea y se olvida todo. Sin embargo vemos como después de cada caso de este tipo en vez de aprender algo tendemos a olvidar rápidamente lo ocurrido.

Se ha hablado de un ataque global de gran escala con muchos infectados. La prensa se ha hecho eco de la gravedad del problema y la propagación que ha tenido. Se ha hablado de cifras de infección de en torno a 100.000 equipos, como algunas de las más elevadas. Sin embargo podemos recordar los números de infectados por otros malware a lo largo de la historia:

• CIH (1998) 60 millones de equipos infectados.
• I Love You o Loveletter (2000) fueron 50 millones infectados.
• Slammer (2003) con más de 75.000 servidores infectados en los primeros 10 minutos.
• Sasser (2004) más de 1 millón de equipos infectados.
• Conficker (2009) unos 7 millones infectados.

Los datos hablan por sí solos y las comparaciones son odiosas. En cualquier caso, ¿se aprendió algo de estos otros malware con infecciones masivas? Todo indica que no.

Y si hablamos de ransomware aunque no hay cifras concretas, estamos seguros de que el famoso virus de la policía ha infectado a mucha más gente que WannaCry. En un periodo de tiempo más extenso, sí, pero esa muestra de malware dio grandes quebraderos de cabeza a miles de usuarios.

¿Podremos aprender algo de una vez?
«de nuevo un gusano que aprovecha una vulnerabilidad en un producto de Microsoft provoca el colapso en Internet.»
«Vulnerabilidades tienen todos los sistemas, no es un problema en exclusiva de Microsoft, pero este caso viene a poner el dedo en la llaga cuando Microsoft intenta disminuir el tiempo que transcurre desde que es descubierta la vulnerabilidad hasta que el sistema del cliente es actualizado.»
Parece que se trata de algo reciente, escrito justo después del ataque, sin embargo aunque parezca sorprendente estos comentarios tienen más de 14 años.
Las conclusiones y lecciones después de cada caso son muy similares. Nada nuevo.

Actualizaciones. En esto somos muy pesados, todos los días hablando de parches, hoy es Windows, mañana el navegador… mantener los equipos y servidores actualizados nos libra de más de un 90% de los problemas. De hecho los equipos actualizados no se verían afectados por este ataque.

Aunque es cierto que la disponibilidad de un parche no asegura la protección de los sistemas, es necesario que los administradores o usuarios lo apliquen y reinicien su sistema. Si bien es cierto que en algunos casos puede ser un problema por dejadez, falta de tiempo o simple desconocimiento, existe también ciertas reticencias a su instalación inmediata en ambientes en producción. No es que los administradores tengan manías, pero muchos hemos sufrido parches que se superponen, regresiones de vulnerabilidades, problemas de estabilidad o incompatibilidad con otros componentes. Rompiendo una lanza en favor de Microsoft, eso ya no sucede de forma frecuente, máxime si implementamos soluciones del tipo a SCCM (system center configuration manager) que permite administrar de forma centralizada la configuración de todos los sistemas físicos y virtuales de una organización o grupo de organizaciones.

El problema parece que ha sido el mismo, la falta de una actualización que llevaba un par de meses publicada… pero a éste respecto, hay que decir que, la actuación sobre los sistemas casi siempre centra el foco de atención en los administradores, a quienes no siempre (la falta de criterio, de confianza y de una miope visión global de la dirección IT o de compañía) nos dejan ser proactivos, sino reactivos, justo cuando el problema ya nos ha estallado en las narices.

Usuarios y empresas deben ser conscientes de que, cada vez que no instalan un parche crítico, están dejando una puerta abierta para que un intruso pueda controlar totalmente su sistema, sustraer su información más sensible, borrar sus discos duros, o espiar todo lo que hacen con su ordenador. Y esto ocurre con mucha más frecuencia de la que se cree.
Tras el gusano Sasser en 2004, 13 años después podemos comprobar que los problemas siguen siendo los mismos.

Pero si los casos anteriores se han cobrado muchas víctimas «civiles», destaca de esta campaña los nombres de las empresas afectadas. Ransomware se ha cobrado víctimas entre corporaciones y organismos de todo el mundo, afectando a servicios tan críticos como el Servicio Nacional de Salud de Reino Unido, u organismos estatales y servicios de transporte en Rusia. WannaCry ha demostrado que las infraestructuras siguen siendo tan frágiles como hace años y que, en cuanto a gestión de riesgo, en ocasiones la ganancia de flexibilidad en las operaciones sigue priorizándose sobre la seguridad del sistema, unida en algunos casos a la desidia en el mantenimiento.

Copias de seguridad. Posiblemente siga siendo el gran olvidado, pero la realización de copias de seguridad periódicas diarias, semanales… Con una adecuada política, manteniendo las copias en un entorno diferente, etc. puede salvar de un problema de este tipo. Si hay una copia de seguridad de todos los datos del día anterior ante un problema similar podemos estar seguros que la pérdida no será tan significativa.

Pagar o no pagar. Hay que recordar que en muchos casos de ransomware aunque se ha llegado a producir el pago no se ha podido recuperar la información. La recomendación siempre es no pagar. Por lo que se sabe la cantidad recaudada en los tres monederos que recaudaban los fondos de este malware apenas sobrepasa los 70.000 dólares. Cantidad que se puede considerar baja teniendo en cuenta el impacto que ha tenido.

Indicadores de compromiso. Está muy bien disponer de un firewall, detector de intrusos y un buen número de medidas de seguridad activas y proactivas, pero de nada sirven si no se mantienen al día. Los indicadores de compromiso es el medio empleado en la actualidad para alimentar sistemas de seguridad.

De todas formas no estamos libres de problemas, siempre puede surgir un 0day que cause estragos. Vulnerabilidad no conocida, sin parche, y si quieres redondearlo para sistemas Windows actualizados, con ejecución remota de código. Aunque actualmente este tipo de problemas suelen estar tan bien cotizados en el mercado negro que no se emplean en ataques a gran escala sino para ataques muy muy dirigidos.

Microsoft también saca sus propias conclusiones, incidiendo igualmente en la importancia de mantener los sistemas actualizados y de la coordinación entre todos los actores para luchar contra estos ataques.
«Debemos tomar de este reciente ataque una renovada determinación para una acción colectiva más urgente. Necesitamos que el sector tecnológico, los clientes y los gobiernos trabajen juntos para protegerse contra los ataques cibernéticos. Se necesita más acción, y se necesita ahora. En este sentido, el ataque WannaCrypt es una llamada de atención para todos nosotros. Reconocemos nuestra responsabilidad de ayudar a responder a esta llamada, y Microsoft se compromete a hacer su parte.»
Las lecciones que debemos aprender están expuestas desde hace mucho, esperemos que esta vez haya sido la definitiva.

Hablar de consejos sobre proteger nuestra privacidad, no dejarnos engañar por estafas en línea y por e-mail o proteger nuestra reputación, son asuntos necesarios cuando nos sentamos frente a un dispositivo electrónico conectado a internet. Hace algún tiempo me hice eco en http://blogs.itpro.es/abueno/?s=jw de un didáctico video que la web jw.org publicó.

En ésta ocasión, el 30 de noviembre es la fecha elegida cada año para celebrar el Día Internacional de la Seguridad Informática (DISI), con la idea de que tanto los usuarios como las organizaciones estén conscientes de las amenazas de seguridad, aquí van algunas acciones como primera línea de defensa.

En consejos sobre seguridad y protección el primer punto que sufrimos muchos administradores y que yo alistaría figura el de, educar a los usuarios, y para ello el Centro de Seguridad y protección de Microsot: http://www.microsoft.com/security/online-privacy/phishing-scams.aspx nos ayuda a proteger nuestra privacidad del robo de identidad. Reconociendo que los usuarios son el primer factor de infecciones en una empresa, es esencial asegurar que los usuarios tengan el nivel adecuado de conocimientos para que NUNCA hagan clic en un archivo adjunto de correo electrónico o un enlace sospechoso, incluso si se trata de una fuente conocida.

Algunas versiones de virus, como “Ransomware” (del inglés ransom rescate y ware, software), son seguramente los invitados más invasivos y no deseados que siendo uno de los virus más detectados, paradójicamente es el virus con peor solución para los archivos infectados. Para los que no estén familiarizados con éste virus, Ransomware tiene a gala haberse hecho en su definición su hueco en la Wikipedia, como un tipo de programa informático malintencionado que restringe el acceso a determinadas partes o archivos del sistema infectado, y pide un rescate a cambio de quitar esta restricción. Este tipo de infección se propaga por correo electrónico, utilizando la máquina infectada como un relé, con el usuario infectado como emisor.

Si a esto le sumamos un adjunto, con un icono que nos resulta familiar (documento de Office, PDF, carpeta …) y decidimos hacer doble clic sobre él… la infección está garantizada. Algunos Ransomware utilizan esos iconos para engañar la vigilancia del usuario. Además, si un archivo adjunto de correo electrónico solicita la ejecución de una aplicación, los usuarios NUNCA deben aceptar la ejecución. Si un usuario tiene alguna duda, tiene que tomar el hábito de ponerse en contacto con el servicio de IT competente que seguramente le permitirá comprobar en un entorno aislado la validez de los datos adjuntos de su correo electrónico o si no es el caso siempre podemos comprobar la fuente desde enlaces como:

http://www.barracudacentral.org/lookups/lookup-reputation2

Si hemos sido infectados por un Ramsomware, será muy necesario que contemos con una solución de Backup-Restore. Debido a que la cave de descifrado de Ramsomware no es localizable, la mejor manera de obtener los archivos de nuevo será restaurar desde una copia de seguridad del sistema, como un Shadow Volume Copy o un System Restore. Lo mejor es poner en marcha un sistema de copia de seguridad fuera de línea, desconectado de la red para evitar que la copia de seguridad esté infectada por el Ransomware.

En este artículo se describe muy bien los principios:

http://www.backupassist.com/blog/support/cryptolocker-and-the-backup-impact/3

Actualizaciones. Es muy importante mantener el sistema operativo actualizado con las últimas actualizaciones de seguridad y para comprobar si todas sus máquinas han sido actualizadas para evitar un ataque con un problema de seguridad conocido, tanto de Microsoft como no Microsoft. Estadísticamente JAVA y Adobe representan el 90% de los vectores de intrusión.

Evite trabajar con un usuario con derechos locales de administración. Es muy recomendable no dejar que los usuarios pertenezcan al grupo administrador local de su máquina. De ésta forma se limitará su posibilidad de intrusión porque hay algunas acciones específicas que no se permitirán. Además, cualquier intrusión en su sesión tendrá el control de la máquina y pondría en peligro la integridad Directorio Activo si hablamos de un dominio.

Y algo difícil para muchos administradores.

Evitemos el uso de cuentas con derecho de Administración del Dominio.

El uso de las cuentas que son capaces de administrar el dominio deben reducirse al mínimo tiempo posible. Si una cuenta de dominio, con derechos de administración del dominio se ve comprometida, es fácil imaginar las consecuencias. No dudes en vestir a una lista de las cuentas que tienen el derecho de administrar el dominio y cambiar todas las contraseñas una vez que el ataque ha terminado.

Hay que prestar atención a los mecanismos de propagación.                                                                  

Un recurso compartido, el correo electrónico… ransomware puede utilizar diversas formas de difusión. Por eso, acciones como, limitar el uso de permisos de escritura y hacer cumplir la seguridad en el archivo adjunto de correo electrónico son de las recomendaciones catalogadas como, mejores prácticas para limitar las posibilidades de propagación.

Administrar macros en Office. Muchas infecciones son procedentes de documentos de Office recibidos por e-mail que contiene macros maliciosos. El manejo de gestión de las macros es una buena idea para evitar que los usuarios ejecutar macros sin pensarlo dos veces. En primer lugar, desactivar la ejecución automática de macros. Aquí os adjunto como hacerlo: https://support.office.com/en-ZA/Article/Enable-or-disable-macros-in-Office-documents-7b4fdd2e-174f-47e2-9611-9efe4f860b12#bm2Es

Éste es sin duda un primer paso para evitar ser infectado de forma automática una vez que se haya abierto el documento de Office que contiene la macro maliciosa. Sin embargo, no impide que el usuario de clic en «Activar» para ejecutar la macro una vez que se abre el documento. Por lo tanto, bien como administradores de un sistema o a título individual, debemos poner en su lugar una ubicación de confianza para las macros, es decir, un usuario sólo podrá ejecutar macros desde una ruta previamente configurada, de nuevo os adjunto un muy buen enlace para saber cómo hacerlo:

https://support.office.com/en-us/article/Add-remove-or-change-a-trusted-location-7ee1cdc2-483e-4cbb-bcb3-4e7c67147fb4?CorrelationId=cd218d92-02cf-427b-806c-59f6a7c22809&ui=en-US&rs=en-US&ad=US

El artículo podría parecer inútil, pero un usuario suele caer en la tentación de hacer clic en cada advertencia hasta que se ejecuta la macro. Esto evitará que un usuario ejecute una macro sin antes haber movido el archivo a una ubicación específica de confianza. Esto ayudará a reforzar la educación del usuario y por lo tanto el usuario puede pensar dos veces antes de ejecutar una macro contenida en un documento de Office que no se confía.

Activar la «Administración del filtrado de archivos», si ofrecemos recursos compartidos desde un entorno servidor de file share, este nos permite proteger los archivos y carpetas compartidas mediante la prevención, en función de las normas específicas definidas por usted mismo, la creación de archivos con la extensión mencionada y permite recibir una alerta si alguien trata de crear un archivo con un no permitidos extensión. Por ejemplo, es posible bloquear la creación de archivos con la extensión * .encrypted, *.hbbjfvd o cualquier otra extensión que utilice el virus para cifrar los datos. También podría impedir la creación de nada, excepto las extensiones que figuran en su lista blanca.

Los siguientes enlaces le ayudarán a configurar esta función:

• http://blogs.technet.com/b/josebda/archive/2008/08/20/the-basics-of-windows-server-2008-fsrm-file-server-resource-manager.aspx
• http://www.catalyticit.com.au/cryptolocker-file-screens/
• https://technet.microsoft.com/en-us/library/cc732074.aspx

Activar AppLocker (o SRP si aún calzas un Windows XP).

Es seguramente la protección más eficaz contra ransomware con el filtrado de URL y filtrado de archivo comprimido que contiene los ejecutables a nivel de proxy y el nivel de mensajería. Esta herramienta permite bloquear o autorizar la ejecución de programas específicos en función de varios criterios como colecciones (un conjunto de extensiones), versiones de archivos, firmas, rutas … y esto por los usuarios / grupos específicos de forma explícita.

Esos artículos deberían ayudarnos a configurarlo:

https://technet.microsoft.com/en-us/library/ee791885(v=ws.10).aspx

Casi perfecta, GPO App Locker:

http://community.spiceworks.com/how_to/59664-free-almost-perfect-malware-protection-with-gpo-app-locker

Detener cryptolocker y ransomware:

https://4sysops.com/archives/stopping-cryptolocker-and-other-ransomware/

Además, aquí están el cryptolocker y los malwares más utilizados con sus rutas y extensiones:

• %OSDRIVE%\Users\*\AppData\Local\Temp\*.tmp
• %OSDRIVE%\Users\*\AppData\*\*.tmp
• %temp%\*.tmp
• %OSDRIVE%\Users\*\AppData\Local\Temp\*.exe
• %OSDRIVE%\Users\*\AppData\*\*.exe
• %temp%\*.exe

El mayor inconveniente de esta herramienta es que podría bloquear aplicaciones legítimas para ejecutar.

Seguridad vs. Funcionalidad.

Sin embargo, es posible configurar reglas de excepción para evitar problemas de compatibilidad, en el siguiente enlace explica como hacerlo:

https://technet.microsoft.com/en-us/library/dd759051.aspx10

Office 365 Implementar Filtrado Fuerte.

Existe malware que utiliza la ejecución automática para instalarse y propagarse. Parece obvia la recomendación, configurar una regla de transporte en nuestro servicio de correo, tal vez Exchange Server para bloquear o marcar mensajes de correo electrónico con contenido ejecutable. El motor se basa en la lista de extensiones y de análisis de contenido para determinar si un archivo es un ejecutable o no.

Para mí lo más fácil es consultar enlaces que detallen el procedimiento y puedan ofrecerme información adicional, personalmente éste lo utilizo bastante:

http://blogs.msdn.com/b/tzink/archive/2014/04/08/blocking-executable-content-in-office-365-for-more-aggressive-anti-malware-protection.aspx

El artículo se basa en EOP (Exchange Online Protection), estos artículos traen información muy precisa sobre EOP:

• Información general del Intercambio Online Protection:
https://technet.microsoft.com/en-us/library/jj723119(v=exchg.150).aspx

• Las mejores prácticas para la configuración de EOP:
https://technet.microsoft.com/en-us/library/jj723164(v=exchg.150).aspx

• Configurar las políticas de Filtro:
https://technet.microsoft.com/en-us/library/jj200684(v=exchg.150).aspx

• Uso de reglas de transporte para inspeccionar archivos adjuntos de mensajes: http://blogs.technet.com/b/exchange/archive/2009/05/11/3407435.aspx

• Explicaciones genéricas disponibles aquí:
https://technet.microsoft.com/en-us/library/jj919236(v=exchg.150).aspx

Aplicar reglas de filtrado a nivel del rol de Edge o servidor de transporte de mensajería. Esto nos permitirá filtrar los archivos adjuntos de correo con anexos zip que contengan ejecutables.

Activar el filtrado de URL o activar el filtrado de URL en sus servidores proxy. Por ejemplo, en TMG:

https://technet.microsoft.com/en-us/magazine/ff472472.aspx)

Microsoft ha liberado por primera vez en éste 2014, coincidiendo con las últimas versiones de Windows 8.1 y Windows Server 2012 R2, un cliente de Remote Desktop Services (RDP) para sistemas operativos no Microsoft, en particular para IOS, Mac OSX y Android.

El anuncio aquí:
•http://blogs.msdn.com/b/rds/archive/2013/10/21/microsoft-remote-desktop-apps-for-ios-mac-os-x-and-android-available-for-download.aspx

Y las apps pueden descargar desde las correspondientes stores:
•https://itunes.apple.com/us/app/microsoft-remote-desktop/id715768417
•https://play.google.com/store/apps/details?id=com.microsoft.rdc.Android (como veréis, muy similar en aspecto a la propia App “Modern UI” que se incluye en Windows 8.1 y Windows 8.1 RT)

Por tanto, queda únicamente por resolver el asunto del Linux.
En este ámbito existen varias soluciones que principalmente descansan en las implementaciones de rdesktop (como sería el caso de KRDC, Gnome –RDP) y FreeRDP (Remmina, Vinagre, etc.). Al final, estos desarrollos suelen estar desfasadas en una o dos versiones de protoólo con respecto a la ultima, y en ocasiones no incluyen todas las funcionalidades posibles (RemoteFX, RD Gateway… ese gran desconocido del que ya hablamos).
Dentro del mundo de soluciones completas de virtualización del escritorio o Thin/Zero Clients basados en diferentes sabores de Linux.

Dirigido a un público joven y a formadores y bajo el título, «Si usas las redes, no te enredes», el web site, jw.org, ha lanzado en formato de animación de pizarra, lo que me parece, ideología a parte, un interesante y bien realizado, dibujo animado de unos 4 minutos de duración, sobre una pizarra blanca que va cobrando vida, para representar diversas situaciones muy reales, que en cierta forma, expertos en seguridad informática y hacking ético, preconizan de forma más densa y ampliada.

Aquí os dejo el enlace que me parece digno de ver y escuchar nada menos que en 34 sorprendentes idiomas:

Si usas las redes, no te enredes

http://www.jw.org/finder?locale=es&docid=502014276&prefer=lang

El cliente de mensajería instantánea para smartphones, WhatsApp, añade un cifrado o encriptado de mensajes bastante cuestionable, donde la seguridad varía, dependiendo de si usamos WhatsApp en Android o en iOS

Las comunicaciones para Android se “protegen” con un ridículo hash MD5, cuyo fin en ningún caso es el de cifrar nada, sino el de comprobar que el contenido de un fichero informático es el mismo en origen y destino.

El cifrado de nuestras credenciales en Android se reduce a un simple hash MD5 del número IMEI del móvil puesto del revés, algo que se puede conseguir muy fácilmente. En el caso de iOS el cifrado se obtiene haciendo el mismo hash MD5 de la dirección MAC del terminal repetida dos veces. Para los que no lo sepan: un hash MD5 de un archivo genera un código alfanumérico que sirve para identificar o confirmar la integridad de dicho archivo. En cualquier caso, el cifrado utilizado por WhatsApp en otras plataformas como iOS tampoco es como para tirar cohetes. Es más, no cubre mucha de la información que WhatsApp toma del teléfono, que continúa enviándose en un documento XML.

Y eso no es todo: cuando WhatsApp revisa nuestra agenda de teléfonos móviles los datos siguen enviándose en un documento XML que muestra información de un usuario como su número, su estado o su cuenta de Jabber (Protocolo extensible de mensajería y comunicación de presencia) si consta en la agenda.

La seguridad de la misma cuenta de WhatsApp es tan irrisoria que usando una red Wi-Fi abierta se corre el riesgo de que la cuenta quede permanentemente hackeada, con acceso completo a tu cuenta.

La recomendación parece obvia… pero como no va a ser el caso,  si no estás por la labor de dejar un, por otra parte, comodísimo servicio como es WhatsApp, ten al menos cuidado de las redes en la que lo utilizas y por lo menos evita usar la aplicación para enviar/recibir contenido que consideres sensible de ser usado fraudulenta o maliciosamente.

La invitación de muchos blogs pasa por quejarnos, como medida para que los desarrolladores de aplicaciones se enteren bien de los fallos de su software, por ejemplo, redactar críticas y poner puntuaciones bajas en las tiendas  de aplicaciones, léase Marketplace, Google Play, App Store o Windows Store.

Leer más…