Forefront TMG 2010: Conexiones VPN con SSTP (1 de 3)

by Admin 18. julio 2011 19:53
============================================================================
- Forefront TMG 2010: Conexiones VPN con SSTP (1 de 3)
- Forefront TMG 2010: Conexiones VPN con SSTP (2 de 3)
- Forefront TMG 2010: Conexiones VPN con SSTP (3 de 3)
============================================================================

Como ya hemos visto anteriormente Microsoft Forefront Threat Management Gateway TMG 2010 permite hasta tres tipos de conexiones VPN (Virtual Private Network) distintas, como son mediante el uso de los protocolos PPTP, L2TP y el que ahora tratamos SSTP (Secure Socket Tuneling Protocol). En entradas anteriores desgranamos el funcionamiento de dos de ellas y como montar Redes VPN en Forefront TMG 2010 haciendo uso de PPTP y cómo hacerlo con L2TP. A continuación hablaremos y analizaremos el tercer tipo de conexión VPN permitido por Forefront TMG 2010: SSTP.

Las redes VPN implementadas por medio de SSTP hacen uso de un protocolo de comunicaciones cifradas y autenticadas ampliamente extendido, como es SSL, sobre el que funcionan los protocolos de páginas web seguras HTTP-s o FTP-s. El objetivo de SSTP es conseguir montar conexiones VPN cifradas y autenticadas que puedan ser utilizadas desde la amplia mayoría de conexiones remotas, donde los puertos SSL suelen estar permitidos. Sin embargo, hay que tener presente una serie de limitaciones a la hora de implementarlo en una organización.
Características y consideraciones:

El protocolo SSTP solo puede utilizarse si cuenta con una infraestrura de clientes con Windows Vista Service Pack1 o superior, es decir, Windows Vista SP2 y Windows 7 tamibén lo sosportan. Este protocolo también puede utilizarse con Windows Server 2008 y Windows Server 2008 R2 para establecer conexiones SSTP VPN siempre que se como clientes ya que actualmente las conexiones SSTP no están disponibles para implementar redes VPN de sitio a sitio.

Para poder hacer esta implementación, debido a que la red VPN usa SSL, es necesario que los servidores VPN SSTP, incluyendo Forefront TMG 2010 tengan instalado un certificado digital de sitio Web para enlazar la escucha Web SSTP. Además, el cliente VPN SSTP debe poder comprobar la lista de revocación de certificados (CRL) para confirmar que no ha sido cancelado el certificado del sitio Web enlazado a la escucha Web SSTP. La comprobación de CRL puede desactivarse en el cliente, pero no es una idea recomendable para un despliegue de producción. Forefront TMG también debe poder comprobar la lista CRL del certificado del sitio Web utilizado por el agente de escucha Web SSTP. A día de hoy, solo Windows Server 2008 y Windows Server 2008 R2 x64 pueden actuar como servidores VPN SSTP.

Como punto a tener en cuenta, se debe considerar que cuando se configura Forefront TMG 2010 para admitir conexiones SSTP, realmente se crea un Web Listener, necesario para aceptar las conexiones. Este Web Listener está configurado para permitir conexiones anónimas y será necesaria una dirección IP dedicada para él, ya que se trata de una conexión SSL con un certificado vinculado. Si se desea publicar cualquier otro sitio SSL utilizando el mismo servidor Forefront TMG 2010, se tendrá que hacer uso de direcciones IP adicionales para apoyar esas conexiones. Teniendo en cuenta que casi todos los sitio SSL publicados deben estar protegidos con pre-autenticación, se deberá tener más de una dirección IP en la interfaz externa para dividir el tráfico a los servidores web y a los servicios de VPN SSTP.

Cómo funciona SSTP

El proceso de conexión SSTP es bastante sencillo de entender. A continuación se puede ver cómo funciona el proceso de conexión SSTP:

Inicialmente el cliente VPN SSTP establece una conexión TCP con la puerta de enlace VPN SSTP utilizando un puerto de origen TCP aleatorio en el cliente VPN SSTP y el puerto TCP 443 en la puerta de enlace VPN SSTP. El cliente envía un mensaje de SSL-Hello, indicando que quiere establecer una sesión SSL con la puerta de enlace VPN SSTP. La puerta de enlace VPN SSTP responderá enviando la clave públicad de su certificado digital al cliente VPN SSTP.

Una vez recibido, el cliente valida el certificado digital mediante la comprobación de que sea un certificado emitido por una entidad de confianza, es decir, que la calve pública de la entidad emisora del certificado deberá estar en el almacén de entidades emisoras raíz de confianza del cliente para que se pueda comprobar si el certificado es correcto. Además, comprobará que el certificado no ha sido revocado, comprobándolo en la CRL de la entidad emisora (CA).

Una vez comprobado el certificado, el cliente VPN SSTP determina el método de cifrado para la sesión SSL, genera una clave de sesión SSL que cifra con la clave pública del Gateway VPN SSTP y la envía a la puerta de enlace VPN SSTP. La puerta de enlace VPN SSTP descifra con la clave privada la clave de sesión SSL que viene en el mensaje y, a partir de ese instante, todas las comunicaciones entre ellos se cifran con el método de cifrado negociado y la clave de sesión SSL.

Una vez elegido el método de cifrado, el cliente VPN SSTP envía una petción HTTP sobre SSL (HTTPS) con un mensaje de solicitud a la puerta de enlace VPN SSTP para negociar el tunel SSTP y establecer la conexión con el servidor. Una vez establecido el tunel SSTP, se negocia una conexión PPP con el servidor SSTP. Esta negociación incluye autenticar las credenciales del usuario utilizando métodos de autenticación estándar PPP - incluso autenticación EAP - y los parámetros de tráfico IPv4 o IPv6.

En la siguiente imagen podemos ver la arquitectura del protocolo VPN. SSTP tiene un encabezado adicional en comparación con los otros dos protocolos VPN. Porque hay encapsulación HTTPS a la cabecera SSTP. L2TP y PPTP no tienen encabezados de capa de aplicación encapsulando la comunicación.


Figura 1: Diagrama de funcionamiento VPN SSTP

============================================================================
- Forefront TMG 2010: Conexiones VPN con SSTP (1 de 3)
- Forefront TMG 2010: Conexiones VPN con SSTP (2 de 3)
- Forefront TMG 2010: Conexiones VPN con SSTP (3 de 3)
============================================================================

Forefront TMG 2010: Extensión de rango de puertos SSL válidos

by Admin 30. septiembre 2010 07:30
Un problema bastante habitual al que se han enfrentado los administradores de MS ISA Server es la de permitir el paso de tráfico de tipo SSL a través de puertos no estándar. Todo el mundo está acostumbrado a asumir la conexión HTTPS a través del puerto 443, sin embargo esto no es así es todas las circunstancias. Muy a menudo, inclusive en las conexiones con los servicios web de la Administración Pública, estas se dan sobre puertos tipo 8443 o 444 por poner algún ejemplo.

Cuando esto sucede se produce un fallo de conexión. Esto es debido a un problema de envío del cliente firewall y Secure Nat al módulo de Web Proxy. Este de forma predeterminada solo envía las conexiones SSL para tráfico HTTP al puerto TCP 443. Si un cliente intenta una conexión HTTPS sobre otro puerto el intento de conexión fallará, aunque se haya creado la correctamente la regla de acceso correspondiente.

Esta circunstancia también ocurre con la versión más reciente del producto: MS Forefront Threat Management Gateway 2010. Para evitarlo puede realizarse la extensión de rangos de puertos válidos para conexiones SSL. Informática64 desarrolló una aplicación denominada Lissa 2004 que permitía de forma gráfica y cómoda realizar esta extensión de puertos SSL para MS ISA Server. Lissa 2004 es válida también para ser utilizada en MS Forefront TMG 2010.

De forma predeterminada los únicos puertos habilitados para la conexión SSL son:

- 443 para HTTPS. - 563 para NNTP.

La siguiente imagen muestra este hecho:


Figura 1: Listado de puertos SSL habilitados de forma predeterminada

Podrá agregarse un nuevo puerto o conjunto de puertos a través de la función de agregar un nuevo rango. En el ejemplo se va a añadir el puerto 444 para la conexión con la Administración.


Figura 2: Agregando el puerto 444

Para que los cambios sean efectivos deberán guardarse los cambios y reiniciar los servicios de firewall del servidor.


Figura 3: Guardar cambios reiniciando servicios

A partir de este momento las reglas de acceso que permitan tráfico a través del puerto 444 serán efectivas para tráfico de tipo SSL. En el caso de que ya no sea necesaria dicha comunicación, podrán eliminarse los puertos para túnel SSL a través de la misma aplicación. Simplemente deberá marcarse en la columna Del aquellos puertos que desean eliminarse, guardando y reiniciando nuevamente los cambios.
 

Forefront UAG: Publicar la Lista de Certificados Revocados CRL [4 de 4]

by Admin 21. agosto 2010 08:00
============================================================================
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [1 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [2 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [3 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [4 de 4]
============================================================================

Los pasos 7 y 8 consisten en definir las propiedades del vínculo en el portal y el proceso de autorización. Deberá mantenerse su configuración por defecto. Finalizado el asistente y antes de que la configuración sea activada deberán realizarse una serie de configuraciones adicional.

En primer lugar, para que el acceso sea directo, deberá definirse que la primera aplicación accesible al acceder a la dirección de la conexión, sea la de la WEB CRL y no la del portal como queda configurado automáticamente. Para ello y seleccionando en el trunk correspondiente, se definirá la aplicación CRL creada en última instancia tal y como se muestra en la siguiente figura.


Figura 11: Selección como la aplicación inicial la de CRL

Posteriormente deberá definirse a través de sus propiedades que no se desea autentificar la conexión. Para ello, y a través de la configuración avanzada de la conexión, no se marcará la configuración de autenticación.


Figura 12: Configuración correcta de la autenticación para la publicación de la CRL

La última tarea consiste en seleccionar, a través de las propiedades de sesión el desactivar, los componentes de instalación y activación y el scripting para el portal de aplicaciones. Esto deshabilitará determinados componentes que permitirá la conexión transparente tal y como se muestra en la imagen siguiente.


Figura 13: Desactivación de componentes

Con esta última configuración, y tras la activación de los cambios, la CRL se encontrará publicada correctamente a través del servidor Microsoft Forefront Unified Access Gateway UAG 2010. A partir de estos momentos los usuarios no recibirán las advertencias de error y los procesos que requieran la comprobación de la CRL funcionarán satisfactoriamente.

============================================================================
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [1 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [2 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [3 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [4 de 4]
============================================================================

Forefront UAG: Publicar la Lista de Certificados Revocados CRL [3 de 4]

by Admin 19. agosto 2010 07:22
============================================================================
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [1 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [2 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [3 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [4 de 4]
============================================================================

El siguiente paso consiste en definir el proceso de autenticación. Sin embargo este proceso no es significativo porque posteriormente se deshabilitará el proceso de autenticación para hacer la CRL disponible a todo el mundo. Los pasos 4 y 5 definen la seguridad de tipo Endpoint que se establecerá para el acceso al portal. Deberá operarse como en todos los procedimientos de publicación habituales y que ya se definieron anteriormente en este blog [Forefront UAG: Creación de Políticas de Acceso].

La definición de las políticas completará el asistente de configuración del portal. Posteriormente habrá de crearse una aplicación de tipo web para la publicación de la CRL. Sobre el nuevo portal deberá crearse una aplicación web a través del asistente de creación de aplicaciones.


Figura 8: Creación de una nueva aplicación Web para la publicación de la CRL

Definido el tipo de aplicación, el paso 2 consiste en la definición de nombres que aparecerán en el portal. Este dato en principio no es crítico puesto que posteriormente se definirá que el acceso a la aplicación será automático sin pasar por el portal.

El paso 3 consiste en definir las políticas tal y como se asignan convencionalmente siguiendo las políticas de empresa. No obstante su comprobación se deshabilitará en procesos posteriores. En el siguiente paso se debe definir si el acceso se realiza a través de una aplicación o balanceador o existe en la organización una granja de servidores web y será el servidor de MS Forefront UAG el encargado de realizar el balanceo.

El paso número 5 es muy importante ya que en él se define la dirección de acceso para el acceso al servidor IIS interno y la ruta de acceso a la carpeta donde se encuentre el fichero con la CRL. De forma predeterminada se depositan en la carpeta CertEnroll pero en el ejemplo se ha definido directamente el fichero de CRL a través de la carpeta raíz del servidor web. También debe definirse en este paso el nombre público, que deberá coincidir con el definido a través del asignado en el CDP.


Figura 9: Definición de rutas de acceso

El paso 6 consiste en la definición del proceso de autenticación para la aplicación que se está creando. No deberá especificarse ninguno. Es más, se deshabilitará posteriormente para que el proceso de acceso sea totalmente transparente, tal y como requiere la comprobación de la revocación de certificados.


Figura 10: Autenticación sin definir

============================================================================
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [1 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [2 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [3 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [4 de 4]
============================================================================

Forefront UAG: Publicar la Lista de Certificados Revocados CRL [2 de 4]

by Admin 17. agosto 2010 07:32
============================================================================
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [1 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [2 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [3 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [4 de 4]
============================================================================

El acceso a la lista de revocación, se puede realizar de múltiples formas. A través de conexiones HTTP, LDAP o directamente por SMB en una red interna. La definición de las rutas se establece a través de las propiedades extendidas de la entidad certificadora.


Figura 4: Definición de la dirección URL para el acceso a la CRL

Para que el acceso del cliente a la CRL sea factible, se podrá realizar la presentación de la misma a través del propio Microsoft Unified Access Gateway 2010. Para ello podrá publicarse una aplicación Web con la dirección de la CRL correspondiente tal y como se detalla a continuación. El primer paso consiste en publicar un nuevo portal de tipo HTTP tal y como se muestra en la imagen siguiente:


Figura 5: Creación de una nueva conexión HTTP

En la creación de la nueva conexión se establecerá la creación de un portal. Aunque este no será utilizado posteriormente es necesario para la creación de la aplicación web posterior. Determinadas configuraciones de las que se definan serán empleadas para la conexión.


Figura 6: Selección del tipo de conexión

El siguiente paso de creación del portal es muy importante, debiendo definirse el nombre de publicación del portal. Este deberá coincidir exactamente con la dirección URL definida a través de las propiedades del CDP (CRL Distribution Point) que se mostró en la Figura 3. En el caso de este ejemplo: ca.empresa.es/crl


Figura 7: Definición de las propiedades de acceso al portal

============================================================================
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [1 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [2 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [3 de 4]
- Forefront UAG: Publicar la Lista de Certificados Revocados CRL [4 de 4]
============================================================================

Un Blog de:

Libros de Forefront TMG 2010
& SharePoint 2010: Seguridad
¡Ya disponibles a la venta!

 
250 páginas. 20 €. En Español

Compra tu Libro de Seguridad

 
250 páginas. 20 y 12 €. En Español

Próximos Eventos Seguridad & Forefront

Compra tus libros de:
Análisis Forense & LOPD

GFI Web Monitor

MetaShield Protector

Calendario de Artículos

<<  mayo 2013  >>
lumamijuvido
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

Mostrar calendario en la página principal

Últimos Comentarios

Comment RSS