Microsoft Lync Server
Header

Microsoft updates Trusted Root Certificate Program to reinforce trust in the Internet

enero 18th, 2016 | Posted by Santiago Buitrago in Seguridad - (0 Comments)

Aquí os dejo una noticia para todos los que habitualmente trabajáis con Certificados Digitalez (y también para los que no)​, en donde MSFT nos indica que retirará una serie de certificados raíz del almacén local de certificados del equipo:

Certificate Authorities to be removed in January 2016

​CA  ​Root Name  ​SHA1 Thumbprint
​Certigna ​Certigna ​B12E13634586A46F1AB2606837582DC4ACFD9497
​Ceska Posta ​PostSignum Root QCA 2 ​A0F8DB3F0BF417693B282EB74A6AD86DF9D448A3
​CyberTrust ​Japan Certification Services, Inc. SecureSign RootCA1 ​CABB51672400588E6419F1D40878D0403AA20264
​CyberTrust ​Japan Certification Services, Inc. SecureSign RootCA2 ​00EA522C8A9C06AA3ECCE0B4FA6CDC21D92E8099
​CyberTrust ​Japan Certification Services, Inc. SecureSign RootCA3 ​8EB03FC3CF7BB292866268B751223DB5103405CB
​DanID ​DanID ​8781C25A96BDC2FB4C65064FF9390B26048A0E01
​E-Certchile ​E-Certchile Root CA ​C18211328A92B3B23809B9B5E2740A07FB12EB5E
​e-Tugra ​EBG Elektronik Sertifika Hizmet Saglayicisi ​8C96BAEBDD2B070748EE303266A0F3986E7CAE58
​e-Tugra ​E-Tugra Certification Authority ​51C6E70849066EF392D45CA00D6DA3628FC35239
​LuxTrust ​LuxTrust Global Root CA ​C93C34EA90D9130C0F03004B98BD8B3570915611
​Nova Ljubljanska ​NLB Nova Ljubljanska Banka d.d. Ljubljana ​0456F23D1E9C43AECB0D807F1C0647551A05F456
​Post.Trust ​Post.Trust Root CA ​C4674DDC6CE2967FF9C92E072EF8E8A7FBD6A131
​Secom ​SECOM Trust Systems Co Ltd. ​36B12B49F9819ED74C9EBC380FC6568F5DACB2F7
​Secom ​SECOM Trust Systems CO LTD ​5F3B8CF2F810B37D78B4CEEC1919C37334B9C774
​Secom ​SECOM Trust Systems CO LTD ​FEB8C432DCF9769ACEAE3DD8908FFD288665647D
​Serasa ​Serasa Certificate Authority I ​A7F8390BA57705096FD36941D42E7198C6D4D9D5
​Serasa ​Serasa Certificate Authority II ​31E2C52CE1089BEFFDDADB26DD7C782EBC4037BD
​Serasa ​Serasa Certificate Authority III ​9ED18028FB1E8A9701480A7890A59ACD73DFF871
​Wells Fargo ​WellsSecure Public Certificate Authority ​E7B4F69D61EC9069DB7E90A7401A3CF47D4FE8EE
​Wells Fargo ​WellsSecure Public Root Certification Authority 01 G2 ​B42C86C957FD39200C45BBE376C08CD0F4D586DB

 

Si queréis ver los certificados raíz que tenéis en vuestros equipos, podéis hacerlo como indica aquí MFST:

How to determine your digital certificates

If you are unsure of how to determine the root of your digital certificates, I have included some guidance, by browser, below.  For more information on the program itself, visit http://aka.ms/rootcert.

Microsoft Edge

  1. Navigate to a web page that uses your certificate.
  2. Click the Lock icon (in the web address field); the company under “Website Identification” is the company that owns the root.

Internet Explorer

  1. Navigate to a web page that uses your certificate.
  2. Click the Lock icon (in the web address field).
  3. Click View Certificates then Certification Path.
  4. View the certificate name at the top of the Certificate Path.

Chrome

  1. Navigate to a web page that uses your certificate.
  2. Click the Lock icon (in the web address field).
  3. Click Connection then Certificate Information.
  4. Click Certification Path.
  5. View the certificate name at the top of the Certificate Path.

Firefox

  1. Navigate to a web page that uses your certificate.
  2. Click the Lock icon (in the web address field) then click the arrow on the right.
  3. Click More Information then View Certificate.
  4. Click Details.
  5. View the certificate name at the top of the Certificate Path.

Aquí tenéis las razones del porqué se retirarán dicho certificados raíz:

At Microsoft, we are continuously working to deliver on our commitment to the security of our customers and their ecosystems. A core component of our strategy to inform Windows users about the safety of the websites, apps and software they’re accessing online is built into the Microsoft Trusted Root Certificate Program. This program takes root certificates supplied by authorized Certificate Authorities (CAs) around the world and ships them to your device to tell it which programs, apps and websites are trusted by Microsoft.
Our efforts to provide a seamless and secure experience usually take place in the background, but today, we want to tell you about some changes we have made to this program. These crucial modifications will help us better guard against evolving threats affecting websites and the apps ecosystem, but they may impact a small set of customers who have certificates from affected partners.
This past spring, we began engaging with Certificate Authorities (CA) to solicit feedback and talk about upcoming changes to our Trusted Root Certificate Program. Among other things, the changes included more stringent technical and auditing requirements. The final program changes were published in June 2015. Since then, we have been working, directly and through community forums, to help our partners understand and comply with the new program requirements.
Through this effort, we identified a few partners who will no longer participate in the program, either because they have chosen to leave voluntarily or because they will not be in compliance with the new requirements. We’ve published a complete list of Certificate Authorities below that are out of compliance or voluntarily chose to leave the program and will have their roots removed from the Trusted Root CA Store in January 2016. We encourage all owners of digital certificates currently trusted by Microsoft to review the list and take action as necessary.
The certificate-dependent services you manage will be impacted if the certificates you use chain up to a root certificate Microsoft removes from the store. Though the actual screens and text vary depending on which browser a customer is using, here’s what will usually happen:
  • If you use one of these certificates to secure connections to your server over https, when a customer attempts to navigate to your site, that customer will see a message that there is a problem with the security certificate.
  • If you use one of these certificates to sign software, when a customer attempts to install that software on a Windows operating system, Windows will display a warning that the publisher may not be trusted. In either case, the customer may choose to continue.
We strongly encourage all owners of digital certificates currently trusted by Microsoft to review the below list and investigate whether their certificates are associated with any of the roots we will be removing as part of the update. If you use a certificate that was issued by one of these companies, we strongly recommend that you obtain a replacement certificate from another program provider. The list of all providers is located at http://aka.ms/trustcertpartners.
With Windows 10 we will continue to work hard to provide you with safer experiences you expect from Windows, keeping you in control and helping you do great things.

Publicar los servicios web de Lync con Web Application Proxy en Windows Server Technical Preview

marzo 11th, 2015 | Posted by Santiago Buitrago in Lync Server | Seguridad | Windows Server - (0 Comments)

Cómo ya he comentado en otras ocasiones, para publicar los distintos servicios Web de Lync debemos utilizar un Proxy​ Inverso o Reverse-Proxy, para ello he publicado distintos artículos sobre IIS ARR y TMG:

Pues ahora tocaba hacerlo con Web Application Proxy, un nuevo servicio disponible desde Windows Server 2012 que viene disponible con el Rol de Acceso Remoto. En este caso voy a mostraros como configurarlo pero ya con la versión de Windows Server Technical Preview. Para ello debemos configurar el servicio de federación (AD FS) en uno de los servidores internos de la red, y además configurar el servidor que hará de Proxy Inverso como un AD-FS Proxy. Necesitamos AD-FS para almacenar la configuración del Web Application Proxy y para la configuración de la autorización. Aquí os dejo como casi siempre un esquema de red en donde tenemos los elementos necesarios para configurar este servicio, además os he puesto a la derecha varias opciones de donde podemos situar el Proxy Inverso en nuestra red:

Web Application Proxy - Lync -1.jpg

Para configurar Web Applicatio Proxy debemos hacerlo en varias fases que veremos a continuación y son las siguientes:

  • Configuración AD FS en un servidor unido al dominio
  • Configuración de AD FS Proxy en el servidor que será nuestro proxy inverso con Web Application Proxy

Los requisitos para esta configuración son los siguientes:

  • Servidor unido a un dominio (o un controlador de dominio, pero no sería lo más idóneo)
  • Una entidad certificadora, puesto que no necesitamos certificados públicos para la configuración de AD FS puesto que será interno
  • Un servidor que no esté en el dominio en donde agregaremos el rol de Acceso remoto en donde se configurará el Web Application Proxy y el servicio de Federación.

Como la configuración del Web Application Proxy se almacenará vía AD FS, será lo primero que tenemos que hacer. Para ello utilizaremos un servidor con Windows Server 2012 R2 y agregaremos el rol de AD FS, por lo que desde el Administrador del servidor pulsamos en Administrar – Agregar Roles y pulsamos en Siguiente

ADFS_WebProxy_Win10_1.png

Seleccionamos  Instalacikón basada en características o en roles y pulsamos en SiguienteADFS_WebProxy_Win10_2.png

Selecionamos el servidor sobre el cual queremos realizar la configuración de un nuevo rol y pulsamos en SiguienteADFS_WebProxy_Win10_3.png

Ahora debemos seleccionar Serviciosde federación de Active Directory y pulsamos en SiguienteADFS_WebProxy_Win10_4.png
Si seleccionar nada, pulsamos en Siguiente

ADFS_WebProxy_Win10_5.png
Pulsamos en Siguiente
ADFS_WebProxy_Win10_6.png

Para iniciar el proceso de instalación, pulsamos en Instalar
ADFS_WebProxy_Win10_7.png

Una vez que finalice la instalación del rol de Federación, debemos iniciar el asistente de configuración, para ello pulsamos en Configure el servicio de federación en este servidor
ADFS_WebProxy_Win10_8.png
Como es nuestro primer servidor de federación, seleccionaremos Crear el primer servidor de federación de una granja de servidores de federación y pulsamos en Siguiente
ADFS_WebProxy_Win10_9.png
Seleccionamos una cuenta con permisos de administrador de dominio y pulsamos en SiguienteADFS_WebProxy_Win10_10.png

Previo a este paso, debemos tener instalado en el servidor un certificado para poder utilizarlo en el servicio de federación, este certificado puede ser privado puesto que únicamente (en este artículo) será utilizado para conectarse el Web Application Proxy. Aquí os dejo un artículo como configurar una CA en Windows Server 2012:  Windows Server 2012, Instalación de una CA

Una vez que ya tenemos nuestro certificado, únicamente debemos seleccionarlo (o importarlo en este momento), escribir un nombre para el servicio de federación (debéis crear el registro DNS correspondiente) y escribir un nombre para este servicio.
ADFS_WebProxy_Win10_11.png

Ahora debemos especificar una cuenta de dominio (sin privilegios) como cuenta de servicio, si queréis ampliar información sobre la cuenta de servicio aquís tenéis un KB de MSFT https://technet.microsoft.com/en-us/library/hh831782.aspx. Una vez que hemos creado la cuenta y la hemos configurado, pulsamos en Siguiente
ADFS_WebProxy_Win10_13.png
Debemos crear una base de datos para la configuración, bien podemos crearla usando Windows Internal Database o utilizando un servidor de SQL. En este caso utilizaremos la opción de Crear una base de datos en este servidor que usa Windows Internal Database
ADFS_WebProxy_Win10_14.png

Por último, nos muestra un resumen de la configuración que vamos a realizar a través del asistente, si todo está correcto, pulsamos en Siguiente
ADFS_WebProxy_Win10_15.png
Se comprueban los requisitos del sistema para verificar que nuestro servidor cumple con todos ellos, si es así  pulsamos en Configurar para iniciar el proceso
ADFS_WebProxy_Win10_16.png
Una vez que se ha completado el proceso de instalación, nos los mostrará con la siguiente pantalla, para cerrar esta ventana pulsamos en Cerrar
ADFS_WebProxy_Win10_17.png
Ahora lo  único que nos queda es probar que el servicio funciona correctamente, para ello accedemos a la siguiente URL: https://adfs.asirlab.com/adfs/ls/IdpInitiatedSignon.aspx y pulsamos en Iniciar sesión
ADFS_WebProxy_Win10_19.png
Nos solicitará credenciales y se las especificamos para comprobar que funciona correctamenteADFS_WebProxy_Win10_20.png
Si todo ha salido bien, veremos una pantalla similar a esta. Ahora sí que damos por finalizada la configuración de AD FS que necesitamos para almacenar la configuración del AD FS Proxy que será el servidor que tiene el rol de Proxy Inverso (Web Application Proxy)

ADFS_WebProxy_Win10_21.png
Hasta ahora hemos completado la primera parte de la configuración que necesita nuestro Proxy Inverso, por lo que ahora debemos realizar las distintas configuraciones en el propio servidor que hará de proxy. Antes comentaros que el debería tener la siguiente configuración:

  • Dos tarjetas de Red con una subred IP diferente en cada interface
  • Sólo configurar la puerta de enlace y servidores DNS públicos (8.8.8.8 u otro público) en la interface que tengamos como externa
  • Si tenemos una DMZ o distintas VLAN internas, debemos configurar las rutas estáticas necesarias  para que desde la interface interna podamos tener conexión con las redes privadas en donde tenemos los servidores que vamos a publicar y el acceso al servicio de AD FS
  • Un certificado para configurarlo en las reglas de publicación del Proxy Inverso
  • Un certificado (o el mismo que el de la publicación de servicios si procede) para el servicio de Federación
  • Modificar el fichero HOSTS del equipo para que pueda resolver los distintos nombres de los servidores que vamos a publicar o que necesitemos tener acceso (AD FS)
  • El FQDN del servidor debería ser con el sufijo del dominio interno que tenemos

Una vez dicho esto, vayamos paso a paso configurando todo lo necesario para configurar el rol de Acceso Remoto y preparar la configuración del Web Application Proxy. Para ello, una vez configuradas la tarjetas de red del servidor, establezcamos el FQDN del servidor y modifiquemos el fichero HOSTS del servidor:

WebProxy_Win10_1.png

Editamos el fichero HOSTS, aquí solo he puesto el los del servidor de Lync, pero habría que poner el nombre del servicio de AD FS que hemos configurado previamente y también nos haría falta la URL de los servicios de nuestro WAC y Exchange si lo tenemos en On-Premises. Aquí no los he puesto porque me he centrado únicamente en Lync
WebProxy_Win10_0.png
Ahora que ya tenemos los requisitos previos realizados, iniciaremos el proceso de configuración del ROL de Acceso Remoto. Comentaros, que yo estoy utilizando un Windows Server Technical Preview, pero en la versión de Windows 2012 es muy similar su configuración. Dicho esto, nos vamos a la consola de administración del servidor y agregamos el rol de Acceso Remoto:
WebProxy_Win10_2.png
Seleccionamos Role-Based or feature-based installation y pulsamos en Next
WebProxy_Win10_3.png
Seleccionamos el servidor sobre el cual vamos a querer agrear el rol de acceso remoto, en este caso es el servidor sobre el cual estamos conectados y pulsamos en Next
WebProxy_Win10_4.png
Seleccionamos el Rol de Remote Access y pulsamos en Next
WebProxy_Win10_5.png
No seleccionaremos nada y pulsamos en Next para continuar con la instalación
WebProxy_Win10_6.png
Pulsamos en Next
WebProxy_Win10_7.png
Ahora debemos seleccionar el servicio que queremos instalar dentro del ROL de Remote Access que previamente hemos seleccionado, por lo que marcamos la casilla de Web Application Proxy
WebProxy_Win10_8.png
Nos muestra los componentes que tiene que agregar adicionalmente al servicio de Web Application Proxy y pulsamos en Add Features
WebProxy_Win10_9.png
ahora ya tenemos todo lo necesario para continuar, para ello pulsamos en Next
WebProxy_Win10_10.png
Nos muestra un resumen de lo que se va a instalar, si estamos de acuerdo pulsamos en Install para iniciar el proceso
WebProxy_Win10_11.png
Una vez que termine la instalación, nos mostrará la siguiente pantalla en donde nos mostrará una opción de configuración del Web Application Proxy para ellos pulsamos en Open the Web Application Proxy Wizard
WebProxy_Win10_12.png
Una vez abierto el asistente de configuración, nos mostrará una pantalla en donde nos indica que debemo configurar inicialmente el servicio de federación, para iniciar el proceso pulsamos en Next
WebProxy_Win10_13.png
Escribiemos el FQDN del servicio de federación que habíamos configurado previamente y las credenciales correspondientes con los permisos de administrador y pulsamos en Next
WebProxy_Win10_14.png
Seleccionaremos el certificado que vamos a utilizar en el AD FS Proxy, recordad que como el servidor no está en el dominio y si utilizáis certificados privados debéis instalar el certificado raíz en el servidor para que no tengáis problemas con el certificado que utilicéis. Como el certificado que he utilzado lo ha emitido mi CA interna, una vez que he importado el certificado también he instalado el certificado raiz en el contenedor de certificados raiz de confianza del propio servidor, de tal forma que vea el certificado como válido. Dicho esto, ya podemos seleccionar el certificado en la pantalla de AD FS Proxy Certificate y pulsamos en Next
8WebProxy_Win10_15.png
 Ahora nos muestra un resumen de los comandos de powershell que se ejecutarán en base a la configuración que hemos ido realizando a través del asistente y pulsamos en Configure  para continuar

WebProxy_Win10_15.png
Si tanto la URL, como las credenciales y el certificado presentado están correctos, nos mostrará la siguiente pantalla indicándonos que se ha completado de forma correcta.
WebProxy_Win10_17.png
Ahora lo único que nos queda es crear las reglas de publicación necesarias para nuestro Lync, para ello pulsamos en Publish
WebProxy_Win10_18.png
Pulsamos en Next
WebProxy_Win10_19.png
Cómo para los servicios de Lync no utilizamos preautenticación, seleccionamos Pass-through y pulsamos en Next
WebProxy_Win10_20.png
Debemos cubrir los siguientes campos disponibles en la publicación del servicio:

  • Nombre: Será el nombre descriptivo que tendrá la regla de publicación
  • External URL: Dirección web del servicio que vamos publicar, en este caso voy a publicarlos servicios web externos de Lync y este es el FQDN que había establecido en la topología de Lync (lync.asirlab.com)
  • External Certificate: Es el certificado que vamos a presentar a los usuarios externos cuando se conecten a los distintos servicios de Lync
  • Backend serve URL: Dirección web del servidor que vamos a publicar, al igual que hacemos con otros proxy debemos especificar la URL y el puerto 4443 que se corresponde con el sitio web externo que tenemos en nuestros front-END

Ahora que ya tenemos todos los campos cubiertos, pulsamos en Next
WebProxy_Win10_22.png
Nos muestra un resumen de la configuración que se va a aplicar vía powershell (Add-WebApplicationProxyApplication) y para que se cree la regla de publicación pulsamos en Publish
WebProxy_Win10_23.png

Y por último en Close y ya tenemos nuestra primera regla de publicación de los servicios web de Lync
WebProxy_Win10_24.png
Y aqui tenemos nuestra primera de Lync en el Web Application Proxy, ahora tendremos que hacer todas las necearias como por ejemplo:

  • meet.asirlab.com (Reuniones en línea)
  • dialin.asirlab.com (Conferencias Telefónicas)
  • lyncdiscover.asirlab.com (Cliente Lync Móvil)
  • office.asirlab.com (Office Web App)
  • mail.asirlab.com (EWS de Exchange)

WebProxy_Win10_26.png
Por mostraros una diferente a Lync, aquí tenéis la regla de publicación del Office Web, en mi caso he puesto la dirección externa y el servidor interno siempre con la misma URL pero puede ser diferente sin problema alguno.
WebProxy_Win10_27.png

Claramente lo que nos quedaba por haacer es probar que podíamos conectarnos, por lo que tratamos de conectarmos por ejemplo a la URL de las reuniones en línea y vemos que funciona perfectamente.
WebProxy_Win10_32.png
Algo que debemos hacer es configurar el tiempo de desconexión de las conexiones que pasan por el Proxy, como por ejemplo el cliente Lync Móvil. Si recordáis había pulicado este articulo sobre las desconexiones del cliente Lync móvil através del IIS ARR (Cliente Lync Móvil 2013: La información del servidor ha cambiado. Reinicia Lync). Por defecto MSFT recomendaba poner un valor de 200 segundos Your_server_configuration_has_changed_3.jpg
y con este valor los clientes Lync de móvil cuando no tenían la aplicación en primer plano a los 200 segundos se desconectaban y claro eso genera problemas a los usuarios finales que deben reconectar cada poco tiempo. Para esto se configuraban las desconexiones a los 960 segundos, algo más razonable y que permite tener la aplicación en segundo plano iniciada durante un tiempo prudencial:

Your_server_configuration_has_changed_4.jpg

Dicho esto, ahora debemos ver como hacerlo en el Web Application Proxy, para ello debemos hacerlo mediante PowerShell. Lo primero es ver el valor por defecto y luego cambiar si fuese necesario, para ello ejecutamos el siguiente cmdlet: Get-WebApplicationProxyApplication y vemos todas las reglas de publicación. Si ahora ejecutamos Get-WebApplicationProxyApplication -Name Lync | fl nos muestra la configuración de cada publicación y vemos que el valor InactiveTransactionsTimeoutSec está establecido a 300
WebProxy_Win10_28.png
Por lo que debemos cambiarlo a 950 y así ajustarlo de forma adecuada, para ello ejecutamos el siguiente cmdlet: Set-WebApplicationProxyAppliation -ID xxxxxx.xxxxxx.xxxxxx.xxxxxxx -InactiveTransactionsTimeouts 950. El ID de la aplicación lo veis con ejecutando el cmdlet  Get-WebApplicationProxyApplication -Name Lync | fl
WebProxy_Win10_31.png
De esta forma el valor por defecto de desconexión establecido a 300 segundos (más que la recomendación de 200 segundos en el IIS ARR), lo hemos pasado a 950.
 
Por último comentaros, que si publicáis algún servicio vía HTTP tendréis que permitir la conexión en el Firewall Local de Windows, porque por defecto se ha creado solo una regla para el tráfico HTTPS. Si abrimos la consola avanzada del firewall la regla AD FS HTTPS Services (TCP-in), por lo que permitirá todas las conexiones al puerto 443 de entrada a cualquiera de las interfaces del Proxy.
WebProxy_Win10_34.png
Si creamos una regla para publicar una web vía HTTP, la conexión no funcionará …
WebProxy_Win10_32-1.png
Si vemos las conexiones activas en el servidoa al puerto 80 y el firewall activado vemos que no tenemos ninguna conexión activa
WebProxy_Win10_33.png
Lo que debemos hacer es crear una reglapara el tráfico HTTP de entrada y listo, ya tendremos acceso a los servicios web publicados en el PROXY  através del puerto 80 en TCP
WebProxy_Win10_42.png
Si ahora volvemos a conectarmos al servicio web publicado, ya tendremos acceso al mismo
WebProxy_Win10_43.png
Si nuevamente volvemos a revisar las conexiones activas, vemos que ya las vemos establecidas y con el Firewall activo
WebProxy_Win10_44.png
Por último hacer un breve comentario sobre las tres posibles (hay más, pero como norma general) ubicación del Proxy Inverso en nuestra red, he esquematizado los más habituales:
 
Opción 1: Situaremos el Proxy (fuera del dominio) en una DMZ protegido por dos Firewall corporativos, realizando filtrados a nivel 3 desde todas las zonas de red (Internet, LAN). Esta es la mejor opción posible de las que os expongo, puesto que tenemos distintas barreras de seguridad antes de tener acceso a la red interna, además de que podemos realizar distintos filtrados en distintas zonas de la red. Si fuese posible, que los dos Firewalls fuesen de compañias diferentes, evitando así que si uno  de ellos tuviese alguna vulnerabilidad, no estuviese afectada toda la red. Ni que decir tiene que debemos mantener nuestra infraesctructura de red adecudamente actualizada
WebProxy_Win10_001.png
Opción 2: La más común de todas, tenemos un firewall / Router a nivel de perímetro co un interface LAN con una subred IP diferente a la de la LAN. De esta forma el Proxy se conectará directamente al router (o switch intermedio) con una interface y subred IP y con la otra internface y subred IP a la LAN. Para esto podremos utilizar VLAN o simplemente configurar dos subredes diferentes pero todos compartiendo el mismo medio físico (Switch). Si es así no es lo más recomendable aun para este escenario  lo suyo sería una VLAN para poner las interfaces LAN del Router y WAN del Proxy, y otra VLAN en el switch para configurarlo para la red local e interface LAN del Proxy.
WebProxy_Win10_002.png

Opción 3: Menos común y la peor opción, es tener el proxy con dos interfaces en la misma subred, no tiene ni sentido tenerlo así. El proxy también puede funcionar con una sola IP, por lo que es lo mismo que tener dos interfaces con la misma subred. Es común en las empresas pequeñas tener este esquema, porque tienen un router y una interface LAN que está en la misma subred IP que la red interna para que los equipos se puedan conectar a internet. Pero si bien es cierto que con este escenario no tenemos una capa de seguridad a nivel de filtrado IP, puesto que si un atacante compromenten el Proxy, por lo menos a nivel IP ya se encuentra en la misma subred. Esto facilitará al atacanque descrubrir distintos servicios de la red local, los equipos, etc… si estuviese en otra subred IP se podrían aplicar de forma "más efectiva" distintos filtrados, porque realmente el Proxy Inverso solo necesita comunicarse con los equipos de la red coporativa que van publicar sus servicios a internet (para más cosas, pero vamos por se escueto)

WebProxy_Win10_003.png

Y ya dicho esto, ahora que cada uno tome las decisiones que crea oportunas para situar su Proxy Inverso en su red, el riesgos que quiera asumir cada uno ya …

Como veis un Proxy Inverso no es un servicio muy complicado de configurar, únicamente debemos cumplir  todos los requisitos y tener claros los conceptos de publicación, DNS, certificados, etc… pero hay que tenerlo claro :-).
 

Os dejo algunos artículos que os podrían ser de interés con respecto al Proxy Inverso para una topología de Lync:

Espero que os sea de utilidad!!!

Cómo «renovar» un certificado caducado asignado al Office Web App

marzo 11th, 2015 | Posted by Santiago Buitrago in Seguridad - (0 Comments)

Algo vital cuando implementamos cualquier servicios que tengamos un certificado de por medio, es que debemos tener claro cuando tenemos que renovarlo. Esto evitará estas cosas …. este era un servidor de Office Web App que ha estado funcionando hasta que hemos tenido una reunión en línea y nos encontramos con esto:

LS Data MCU 41033 Certificado WAC -5.png
Lo primero que podemos hacer para saber que problema tiene el servicio de Office Web App y el certificado, es acceder a la siguiente URL: https://fqdn/hosting/discovery y nos encontramos con los siguiente:
LS Data MCU 41033 Certificado WAC -2.png
Si pulsamos en Vaya a este sitio web (no recomenado) nos abrirá igualmente el sitio web al que queremos acceder y pulsamos en Error de certificado para ver problema tiene
LS Data MCU 41033 Certificado WAC -3.png
Como vemos el certificado ha caducado, el servidor de Office Web App está bien configurado pero el certificado ha caducado y así no podremos utilizarlo
LS Data MCU 41033 Certificado WAC -4.png
Si nos conectamos a nuestro Front-END, podemos observar que no se puede conectar al Office Web App porque se ha comprobado que el certificado no es válido 
LS Data MCU 41033 Certificado WAC -1.png
Como ya tenemos claro que el problema es el certificado, debemos ver la forma de "renovarlo". No sé si os habéis fijado que siempre he puesto "renovar" entre comillas, porque quiero mostraros que ocurre cuando queremos renovar un certificado que ya ha caducado. Por lo que os mostraré el proceso normal para renovar un certificado, esto podemos hacerlo de varias formas, pero lo haremos directamente desde el IIS. Para ello abrimos la consola de administración del IIS y accedemos a la opción de certificados:
LS Data MCU 41033 Certificado WAC -6.png
Ahora vemos todos los certificados que tiene el servidor y podemos observar que el certificado asignado al Office Web App ha caducado (la marco en rojo porque esta captura es posterior claramente el día 3 de Noviembre de 2014, vamo que el certificado está caducado), pulsamos con el botón secundario del ratón encima del mismo y pulsamos en Renovar
LS Data MCU 41033 Certificado WAC -7.png
Elegimos Renovar un certificado existente y pulsamos en Siguiente
LS Data MCU 41033 Certificado WAC -8.png
Si tenemos varias entidades certificados, pulsamos en Seleccionar para elegir la CA a la que enviaremos la solicitud de renovación (elegir la que haya emitido el certificado) y pulsamos en Finalizar
LS Data MCU 41033 Certificado WAC -9.png
Y cómo vemos se nos deniega la solicitud, mostrándonos una ventana de alerta
LS Data MCU 41033 Certificado WAC -11.png
 
Ahora queremos saber el porqué se nos ha denegado la solicitud, para ellos vamos al Visor de Eventos del servidor que tiene la CA instalada y veremos el siguiente evento:
LS Data MCU 41033 Certificado WAC -12.png
El problema viene dado porque queremos renovar un certificado que ya está caducado y eso no es posible: (http://technet.microsoft.com/en-us/library/dd378790(WS.10).aspx)
LS Data MCU 41033 Certificado WAC -42.PNG
De ahí que nos muestre el error de solicitud denegada, solo podemos "renovar" si el periorido está dentro del período de validez del mismo, sino no podremos hacerlo. Pues bien, si esto nos ocurre lo que debemos hacerr es solicitar un nuevo certificado. Esto también os lo voy a comentar porque para el servicio de Office Web App tiene una particularidad para que nos funcione correctamente, debe tener el nombre de sujeto con el que queramos acceder al servicio y además el nombre FQDN del propio servidor como alternativo además del FQDN igualmente, ahora os lo muestro. Cómo es un certificado SAN lo podemos solicitar de varias formas, vía PowerShell, vía Consola de Administración de Certificados del servidor o bien utilizando una herramienta como Digicert Tool que nos hará la solicitud más sencilla. Esta utilidad, no solo vale para solicitar el certificado a DigiCert, sino para crear nuestra solicitud (CSR: Creación de CSR para Lync de forma sencilla) y enviarla a nuestra CA interna.
 
Lo que tenemos que hacer es ejecutar la herramienta de DigiCert (Digicert Tool ) y lo primero que haremos será pulsa en Create CSR que nos permitirá cubrir los datos necesarios para enviar la solicitud a nuestra CA:
LS Data MCU 41033 Certificado WAC -13.png
Si previamente hemos seleccionado algún certificado que ya tenìamos instalado en el equipo, nos preguntará si queremos importar los atributos del certificado para el nuevo CSR, vamos a pulsar en Sí (en mi caso porque es el mismo certificado el que quiero solicitar):
LS Data MCU 41033 Certificado WAC -14.png
Como podéis observar, el Common Name es el nombre FQDN del propio servidor y luego como alternativos tenemos ese mismo nombre y además por el que quiero conectarme al servicio web (office.asirsl.com). Así es como debéis solicitar este certificado, como Nombre Común el FQDN del propio servidor y como alternativo el mismo FQDN y además el que queréis utilizar para que el Lync, SharePoint y Exchange utilicen para conectarse a él. Ahora cubrimos el restro de datos, teniendo especial importancia el tamaño de clave, que debemos establecerlo a 2048 y pulsamos en Generate
LS Data MCU 41033 Certificado WAC -15.png
Ahora nos mostraré el CSR que utilizaremos para enviarlo a nuestra CA y así completar la solicitud, pero bien podemos copiar el texto o guardar el fichero, yo copiaré directamente el texto porque completaré la solicitud en este mismo instante, por lo que pulsaré en Copy CSR
LS Data MCU 41033 Certificado WAC -16.png
LS Data MCU 41033 Certificado WAC -17.png

Una vez copiado, abrirmos un navegador y accedemos al servicio Web de inscripción de certificados de nuestra CA http(s)://FQDN_CA/certsrv y pulsamos en Solicitar un certificado

LS Data MCU 41033 Certificado WAC -18.png
 Pulsamos en Solicitud avanzada de certificado
LS Data MCU 41033 Certificado WAC -19.png
Ahora en Enviar una solicitud de certificado con un archivo codificado en Base64 CMC o PKCS#10 o una solicitud de renovación con un archivo codficado en base64 PKCS #7
LS Data MCU 41033 Certificado WAC -20.png

En el primero hueco pegamos el texto copiado previamente (el CSR), elegimos como plantilla de certificado Servidor Web y escribimos una descripción de la solicitud (no obligatorio), pulsamos en Enviar
LS Data MCU 41033 Certificado WAC -21.png
En la siguientes dos alertas pulsamos en Sí 

 LS Data MCU 41033 Certificado WAC -22.png
LS Data MCU 41033 Certificado WAC -23.png
Ahora seleccionamos Codificado en Base64 y pulsamos en Descargar Certificado
LS Data MCU 41033 Certificado WAC -24.png

Nos mostrará un aviso para que abramos o guardemos el fichero, lo vamos a guardar para completar la solicitud desde la herramienta de DigiCert

LS Data MCU 41033 Certificado WAC -25.png
Abrimos la DigiCert Tool y pulsamos en Import
LS Data MCU 41033 Certificado WAC -26.png
Pulsamos en Browse para elegir el fichero que vamos a importar, que es el que nos hemos descargado previamente desde la web de nuestra CA
LS Data MCU 41033 Certificado WAC -27.png
Pulsamos en Siguiente
LS Data MCU 41033 Certificado WAC -28.png
Escribimos una descrpción para poder identificarlo de forma sencilla  (sí ya sé que he puesto Ceritificado en vez de Certificado) y pulsamos en Finalizar
LS Data MCU 41033 Certificado WAC -29.png
Ahora nos muestra una ventana informándonos de que se ha importado correctamente el certificado y que ya lo tenemos disponible para asignar al IIS o Exchange, ahora pulsamos en Aceptar
LS Data MCU 41033 Certificado WAC -30.png
Como vemos, ya tenemos el nuevo certificado  disponble para asignárselo al servicio de Office Web App
LS Data MCU 41033 Certificado WAC -31.png
Como es un nuevo certificado, tenemos que asignárselo nuevamente al OFfice Web App, para ello lo primero  es desconfigurar el servicio de Office Web App para lo haremos en varios pasos:
 
Paso 1: Ver la configuración actual: Get-OfficeWebAppsFarm
LS Data MCU 41033 Certificado WAC -33.png
Paso 2: Eliminar la configuración del Office Web App: Remove-OfficeWebAppsMachine
LS Data MCU 41033 Certificado WAC -34.png
Paso 3: Configurar nuevamente las Office Web App con el nuevo certificado (me he equivocado en la descripción (no en los nombres que tiene el certificado) del certificado y le he puesto "Ceritificado Office Web App de ahí que así lo veáis en el cmdlet:  New-OfficeWebAppsFarm -InternalUrl "https://office.asirsl.com" -ExternalUrl "https://office.asirsl.com" –EditingEnabled:$true –CertificateName “Ceritificado Office Web App”
LS Data MCU 41033 Certificado WAC -36.png

Ahora ya tenemos nuestro certificado "renovado" (recordad lo comentado anteriormente sobre lo de renovado) y asignado nuevamente a nuestro Office Web App. Ahoar si nos vamos Lync por ejemplo, ya tenemos disponible el poder compartir las presentaciones de PowerPoint en nuestras reuniones:

 
LS Data MCU 41033 Certificado WAC -37.png
LS Data MCU 41033 Certificado WAC -41.png
Si ahora nos vamos a un Front-END y abrimos el Evento de Sucesos ya podemos ver que no tiene problemas con este servicio (claramente, ya lo estamos utilizando):
LS Data MCU 41033 Certificado WAC -38.png
Si ahora volvemos a acceder a la URL: https://FQDN/Hosting/Discovery ya podemos ver que no nos muestra el error del certificado
LS Data MCU 41033 Certificado WAC -40.png
 
Por lo que damos por cerrado el proceso de "renovación", algo más tedioso por no poder renovarlo y si tener que volver a solicitarlo nuevamente. Si solo tuviéramos que renovarlo era simplemente finalizar la renovación y ya quedarí operativo el servicio. Aquí la recomendación es tener un procedimiento para gestionar la caducidad de los certificados de nuestra infraestructura, bien con alguna herramienta que nos alerta de la caducidad del certificado (SCOM 2012 )por ejemplo), configurar una alerta de para que nos avise cuando el servidor tenga una alerta en el visor de eventos (Lync Server: Renovación de Certificados y Alertas) o anotarnos en el calendario del Outlook una fecha anterior a la caducidad del certificado para renovarlo antes de encontrarnos con el problema.
 
La idea de este artículo era mostraros que si caduca un certificado ya no podemos renovarlo y cual sería el proceso de configuración del servicio de Office Web App con el nuevo certificado.
 
Espero que os sea de utilidad!!!

Cómo publicar ADFS 3.0 mediante TMG 2010 para la federación con Office 365

marzo 11th, 2015 | Posted by Santiago Buitrago in Seguridad - (0 Comments)

Es posible que estéis pensando en migrar vuestro Exchange, SharePoint o Lync a la nube, y con esto buscáis que vuestros usuarios puedan iniciar sesión en las aplicaciones nombradas con las mismas credenciales de vuestro dominio local. Para ello debéis realizar una serie de pasos antes, uno de ellos es la publicación del AD FS que habéis configurado en alguno de vuestros servidores On-Permises, y si tenéis un Reverse-Proxy (TMG, F5, KEMP, IIS ARR, etc..) debéis realizar una serie de configuraciones las cuales voy a comentaros si utilizáis TMG. Debemos disponer de un certificado digital de una entidad certificadora pública (DigiCert, Verising, Geotrust, etc..), tanto puede ser un certificado con un solo nombre, como SAN o Wildcard, aquí no tenemos problema con el tipo de certificado, lo que sí es que los nombres de dominio que tenga el certificado se deben corresponder con lo que vamos a publicar (lo de siempre vamos) y en base a los UPN que hayamos sincronizado con Office 365 porque harán referencia a los inicios de sesión de los usuarios. Una vez dicho esto, veamos cual sería la configuración del TMG, para ello nos vamos a la consola de administración y con el botón derecho hacemos clic encima de la opción Reglas de Firewall – Nuevo – Regla de Publicación Web

Publicar AD FS via TMG 2010.png

Escribimos uno nombre corto pero descriptivo para la regla de publicación que vamos a crear y pulsamos en Siguiente

Publicar AD FS via TMG 2010 - 1.png

Elegimos la opción Permitir y pulsamos en Siguiente
Publicar AD FS via TMG 2010 - 2.png

Selecionamos que queremos publicar una única web o un balanceador y pulsamos en Siguiente

Publicar AD FS via TMG 2010 - 3.png

Requisito inprescindible es que el servidor web que vamos a publicar sea bajo SSL y pulsamos en Siguiente

Publicar AD FS via TMG 2010 - 4.png

Escribimos el FQDN del nombre del servicio a publicar en interno (en mi caso es el mismo que el externo, tratando de tener un criterio único) y pulsamos en Siguiente

Publicar AD FS via TMG 2010 - 5.png

Especificamos una ruta del servidor web que vamos a publicar, en este caso escribimos /adfs/* (de tal forma que esta regla solo permitirá la conexión cuando se intente acceder aa /adfs/ y cualquier cosa de aquí en adelante) y pulsamos en Siguiente:
Publicar AD FS via TMG 2010 - 6.png
Ahora escribimos el nombre público con el que se publicará el servicio web, de tal forma que el TMG sepa que si le llega una petición con una cabecera adfs.asirsl.com tenga claro que esta es la regla que tendrá que aplicar, y en la ruta igualmente permitimos únicamente las conexiones desde /adfs/ hacia adelante. Si el nombre es diferente al interno es cuestión de que lo pongáis, eso si, este nombre debe tener su registro DNS de Tipo A (o CNAME, pero mejor A) en el servidor DNS externo):
Publicar AD FS via TMG 2010 - 7.png
Elegimos el Listener que previamente hemos configurado con el certificado que vayamos a utilizar y pulsamos en Siguiente
Publicar AD FS via TMG 2010 - 8.png

Ahora nos toca elegir el tipo de autenticación, debemos escoger No delegación, pero el cliente puede autenticarse directamente y pulsamos en Siguiente

Publicar AD FS via TMG 2010 - 9.png
Cómo último paso guiado por el asistente añadiremos al grupo Todos los Usuarios y pulsamos en Siguiente

Publicar AD FS via TMG 2010 - 10.png

Y por último pulsamos en Finalizar

Publicar AD FS via TMG 2010 - 11.png

Nos quedaria por ajustar varias cosas en esta regla, para ello la buscamos entre las directivas de Firewall, vamos a sus propiedades y configuramos las diferentes opciones tal cual os muestro:

Publicar AD FS via TMG 2010 - 12.png

Esto es a modo revisión, porque si lo recordáis esto es justamente lo que hemos configurado con el Asistente

Publicar AD FS via TMG 2010 - 14.pngPublicar AD FS via TMG 2010 - 13.png

También debemos configurar una cosa más a nivel del protocolo HTTP, para ello pulsamos con el botón secundario de ratón encima del protocolo de la regla de AD-FS 3.0 y pulsamos en Configurar HTTP:

Publicar AD FS via TMG 2010.png
Y desmarcamos las casillas que os muestro en la siguiente imagen:

Publicar AD FS via TMG 2010 - 17png.png

Ahora sí que podempos aplicar los cambios pendientes en el TMG y si ya tenemos todas las configuraciones preparadas para iniciar sesión en Office 365 con nuestras credenciales de dominio, solo toca probarlo. Para ello nos vamos a https://login.microsoft.com, introducimos nuestro usuario y si estámos federados correctamente automáticamente nos redirigirá la petición a nuestro ADFS para autenticarnos, ahí es cuando entre en juego la regla que hemos creado:

Paso 1: Introducimos el usuario de nuestra organización

Publicar AD FS via TMG 2010 - 18.png

Paso 2: El sistema automáticamente nos intenta redirigir a la página de incio que hemos publicado anteriormente (adfs.asirsl.com)

Publicar AD FS via TMG 2010 - 19.png

Paso 3: Nos solicitará las credenciales, las introducimos y pulsamos en Aceptar

Publicar AD FS via TMG 2010 - 21.png

Paso 4: Ya estamos dentro de Office 365 accediendo con nuestras credenciales de dominio

Publicar AD FS via TMG 2010 - 20.png

Sin el momento de conectarnos revisamos el LOG del TMG, veremos las conexiones oportunas y si hemos iniciado sesión correctamente lo podremos ver con claridad:

Publicar AD FS via TMG 2010 - 15.png
Como podéis apreciar la publicación es sencilla y rápida, os llevará más tiempo la configuración de la sincronización, preparación del AD y el AD FS que esta regla. Si bien es cierto que esto no es complejo, únicamente debemos cumplir los requisitos previos y funcionará  muy bien. Otra cosa es configurar los diferentes servicios con autenticación integrada, entornos híbridos, etc.. pero bueno eso para otro momento.

Espero que os sea de utilidad!!!

Cómo solucionar la vulnerabilidad de SSL 3.0

marzo 11th, 2015 | Posted by Santiago Buitrago in Seguridad - (0 Comments)

Como sabréis Google ayer anunció que había un problema de seguridad que afecta al protocolo SSL 3.0, como bien describe en el siguiente artículo:

Vulnerabilidad en el Protocolo SSL 3.0.JPG

Dicha vulnerabilidad se llama POODLE y aquí tenéis un PDF en donde biene correctamente descrita la vulnerabilidad: https://www.openssl.org/~bodo/ssl-poodle.pdf . Esto afecta a todas las implementaciones en donde utilicemos SSL 3.0, algo que como bien indica ya no se debería utilizar puesto que ya un protocolo muy antiguo con más de 15 años. Si trabajáis con IIS, TMG u otro serivicio que utilice SSL deberíais deshabilitar el uso de SSL 3.0, para ello debemos crear las siguientes claves de registro en los servidores afectados y reiniciarlos para que se hagan efectivos los cambios. Antes de ponernos manos a la obra podéis verificar si vuestro servicio está afectado o no por este problema, para ello podéis acceder a la siguiente web y especificar vuestras URLs: http://www.poodlescan.com/. Si vuestra web tiene habilitado SSL 3.0 o 2.0 os lo indicará, mirar este ejemplo en donde lo he habilitado a propósito para poder ver la advertencia que nos muestra:
 Vulnerabilidad en el Protocolo SSL 3.0 -1.JPG
En el caso de que el servicio no estuviese afectado, nos mostraría la siguiente pantalla:
Vulnerabilidad en el Protocolo SSL 3.0 -2.JPG
Si resulta que en nuestro servidor utilizamos SSL 3.0 debemos crear las siguientes claves de registro para deshabilitarlo:
 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
"DisabledByDefault"=dword:00000001
Vulnerabilidad en el Protocolo SSL 3.0 -3.jpg
 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
"Enabled"=dword:00000000
Vulnerabilidad en el Protocolo SSL 3.0 -4.jpg
Es posible que también tengáis habilitado el SSL 2.0, pues lo deshabilitaremos de la misma forma, creando una clave en el registro:
 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
Vulnerabilidad en el Protocolo SSL 3.0 -5.jpg
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"Enabled"=dword:00000000
Vulnerabilidad en el Protocolo SSL 3.0 -6.jpg

Por último debemos reniciar el servidor para completar el proceso, de tal forma que nuestro servidor no sea vulnerable por POODLE. Comentaros que si tenemos un Proxy Inverso (TMG, IIS ARR, etc..) podemos realizar este cambio únicamente en servidor y ya quedaríais igualmente protegidos, aunque lo suyo sería también configurar de forma manual los servidores que publicamos a través del proxy inverso. Las claves de registro para el TMG serían las mismas que las anteriores, pero a mayores debemos configurar las siguientes claves (más información: http://www.isaserver.org/articles-tutorials/configuration-security/improving-ssl-security-forefront-threat-management-gateway-tmg-2010-published-web-sites.html):

 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\AllowInsecureRenegoClients]
"Enabled"=dword:00000000
 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\DisableRenegoOnServer]
"Enabled"=dword:00000001
Vulnerabilidad en el Protocolo SSL 3.0 -7.jpg
Una vez establecidos estos valores (y los de deshabilitar SSL 3.0) reiniciamos el servicio de Firewall del TMG y ya quedaría correctamente protegido. Mirad el antes y después de una análisis desde la utilidad de DigiCert Certificate Agent (utilidad que nos permte analizar de forma remota los certificados instalados en nuestros servidores):
 
TMG con SSL 3.0 HABIILTADO
Vulnerabilidad en el Protocolo SSL 3.0 -8.jpg
TMG CON SSL 3.0 DESHABILITADO Y CON TLS 1.0 (SI ES POSIBLE DESHABILITARLO TAMBIÉN), 1.1 y 1.2 HABILITADO
Vulnerabilidad en el Protocolo SSL 3.0 -9.jpg
Si queremos habilitar o deshabilitar TLS en los servidores, podemos hacerlo de la misma forma que hemos hecho con el SSL 3.0 pero con las claves adecuadas para TLS:

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"DisabledByDefault"=dword:00000000
 Vulnerabilidad en el Protocolo SSL 3.0 -11.jpg
 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"Enabled"=dword:00000000
Vulnerabilidad en el Protocolo SSL 3.0 -11.jpg

Y así todo igual con las versiones TLS 1.1 y TLS 1.2 :

 

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"Enabled"=dword:00000000

 
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"Enabled"=dword:00000000
 

Aquí os dejo los ficheros .reg en función de lo que queráis deshabilitar:

SSL 2.0 para IIS: Deshabilitar SSL 2.0.zipDeshabilitar SSL 2.0.zip

SSL 3.0 para IIS: Deshabilitar SSL 3.0.zipDeshabilitar SSL 3.0.zip

SSL 3.0 en TMG (opciones de seguridad a mayores): Deshabilitar SSL 3.0 en TMG.zipDeshabilitar SSL 3.0 en TMG.zip

En la web de DigiCert tenéis información suficiente también sobre este tema, por lo que no dejéis de visitarla: https://blog.digicert.com/sslv3-vulnerability-poodle/?mkt_tok=3RkMMJWWfF9wsRokuq7JZKXonjHpfsX56ekqW6S0lMI%2F0ER3fOvrPUfGjI4DScdgI%2BSLDwEYGJlv6SgFQrLAMbdw0bgKXRA%3D Aquí encontraréis información de como deshabilitar SSL 3.0 para IIS, Apache y Nginx:

IIS: https://www.digicert.com/ssl-support/iis-disabling-ssl-v3.htm

Apache: https://www.digicert.com/ssl-support/apache-disabling-ssl-v3.htm

Nginx: https://www.digicert.com/ssl-support/nginx-disabling-ssl-v3.htm

DigiCert ha puesto a disposición de lo miembros registrados una utilidad para verificar nuestros servidores con SSL: Certificate Inspector, desde la cual escribimos el FQDN de nuestro servidor y lo chequerá en línea mostrando más información que si únicamente tenéis SSL 3.0 habilitado en vuestro servidor. 

Espero que os sea de utilidad!!!