En anteriores artículso se ha tratado el tema de la publicación de un servidor Https haciendo uso de la funcionalidad bridging. Sin embargo en ocasiones es factible que una empresa desee emplear el mecanismo de publicación un servidor web seguro sin recurrir al sistema de bridging. Simplemente desean establecer el túnel de acceso al servidor Https a través del servidor MS Forefront Threat Management Gateway TMG 2010.

En este modo tanto los procesos de autenticación como la gestión y envío de certificados recaerá directamente sobre el servidor web. El servidor perimetral simplemente se encargará de recibir las tramas y remitirlas al servidor correspondiente mediante NAT. Para la realización de esta publicación, deberá emplearse el asistente que se proporciona a través de la consola de una regla de publicación de un protocolo no web.


Figura 1: Regla de publicación de protocolo no web

El asistente comenzará determinando la dirección IP del servidor interno al que se enviará la información. Hay que tener en consideración que este mecanismo de publicación no basa la conectividad en nombres de encabezados host, solo en direccionamiento IP. Una vez definido este, será el momento de establecer el protocolo a publicar. De forma predeterminada se encuentra para utilización el protocolo Https Server.


Figura 2: Selección del protocolo

En caso de que la publicación Https se realice por un puerto diferente del 443, tendrán que tenerse en consideración las condiciones de creación de protocolo en cuento a conexiones entrantes o salientes.

El último paso consistirá en definir la red y direcciones IP de escucha para esta regla de publicación. Tras la aplicación de los cambios, se encontrará publicado un servidor Web Seguro en modo túnel.
 

Cuando una organización activa en MS Forefront Threat Management Gateway TMG 2010, la capacidad para realizar inspección de tráfico HTTPS, puede encontrarse con la circunstancia de que determinados accesos que hasta la fecha se realizaban sin problemas, pueden fallar a partir de ese momento. Esto es debido a que el tráfico ya no se encontrará en modo túnel desde el cliente hasta el servidor, y TMG puede encontrar parámetros erróneos que anulen la conexión.

Este es caso que se muestra en la siguiente figura, donde una conexión HTTPS inspeccionada falla al cargar un programa con un formato incorrecto.


Figura 1: Fallo en la conexión por programa o formato incorrecto

Para que el acceso sea factible habrá que crearse una excepción en la inspección de tráfico, para evitar que MS Forefront TMG 2010 haga el análisis que corresponde. Para ello podrá editarse el objeto de sitios exceptuados de inspeccionar tráfico HTTP y agregarlo en el siguiente formato: *.prueba.es


Figura 2: Agregando excepción a la inspección de tráfico HTTPS

Una vez aplicado los cambios, el acceso será nuevamente factible. Hay que tener en cuenta que este error no se debe a MS Forefront TMG 2010, si no a una mala construcción de la aplicación web.
 

============================================================================
- Forefront TMG 2010: Configuración de parámetros RPC/HTTPS (1 de 2)
- Forefront TMG 2010: Configuración de parámetros RPC/HTTPS (2 de 2)
============================================================================

En el caso de que cuente con un escenario de MS Office Outlook 2007/2010 y MS Exchange Server 2007 con accesos tipo Active Sync y RPC sobre HTTPS, Microsoft ha definido los parámetros óptimos para aplicar en filtro HTTP. Esta configuración permitirá además impedir potenciales ataques que se pudieran lanzar contra los servidores a través de la regla, minimizando los métodos de conexión o limitando el uso de caracteres o extensiones.

Hay que tener en cuenta que las configuraciones óptimas para ambas publicaciones son diferentes, por lo que deberían definirse dos reglas diferentes. Los parámetros óptimos para Microsoft Active Sync son los siguientes:

- Pestaña general:

o Maximum headers length: 32768.
o Maximum payload length: 10485760 (10 MB).
o Maximum URL length: 1024.
o Maximum query length: 512.
o Verify normalization: Sí.
o Block high bit characters: Sí
o Block responses containing Windows executable content: Si

- Pestaña de métodos:

o Allow only specified methods: Options y Post.

- Pestaña de extensiones:

o Allow only specified extension: dotx.
o Block requests containing ambiguous extensions: Sí.

- Pestaña de firmas:

o Bloquear los siguientes caracteres en Request URL: ./ \ .. % :


Figura 2: Configuración óptima de parámetros generales para Active Sync

En el caso de la comunicación RPC sobre HTTPS, esto serán los parámetros adecuados:

- Pestaña general:

o Maximum headers length: 32768.
o Maximum payload length: any.
o Maximum URL length: 16384.
o Maximum query length: 4096.
o Verify normalization: Sí.
o Block high bit characters: Sí
o Block responses containing Windows executable content: Si

- Pestaña de métodos:

o Allow only specified methods: RPC_IN_DATA, RPC_OUT_DATA, GET y POST.

- Pestaña de extensiones:

o Allow only specified extension: .dll, .asmx, .xml, .lzx y .wsdl.
o Block requests containing ambiguous extensions: Sí.

- Pestaña de firmas:

o Bloquear los siguientes caracteres en Request URL: ./ \ .. % &


Figura 3: Métodos permitidos en conexión RPC sobre HTTPS

============================================================================
- Forefront TMG 2010: Configuración de parámetros RPC/HTTPS (1 de 2)
- Forefront TMG 2010: Configuración de parámetros RPC/HTTPS (2 de 2)
============================================================================

============================================================================
- Forefront TMG 2010: Configuración de parámetros RPC/HTTPS (1 de 2)
- Forefront TMG 2010: Configuración de parámetros RPC/HTTPS (2 de 2)
============================================================================

Una de las características que puede aportar un producto como MS Forefront Threat Management Gateway a una organización es el de los filtros a nivel de aplicación. Dentro de estos el correspondiente a HTTP, se ha utilizado recurrentemente ante múltiples circunstancias. Por ejemplo, en el hecho de poder filtrar contenido transmitido de tipo P2P o de mensajería instantánea en tráfico de tipo HTTP.

Las posibilidades aportadas por este filtro, son muchas, pudiendo emplearse tanto en escenarios de conexión directa donde los usuarios se comunican mediante reglas de acceso o bien cuando se produce la publicación de un servicio Web. Los parámetros aplicables en cada tipo de comunicación, podrían ser diferentes, ajustándose por lo tanto en función de las necesidades. Este filtro por lo tanto se aplica de forma independiente en cada una de las reglas o publicaciones que se creen. La siguiente imagen muestra como acceder al filtro HTTP de una regla.


Figura 1: Configuración del filtro HTTP

Los parámetros configurable a través del filtro HTTP son cinco:

- General: Se especifican entre otros los valores máximos de longitud de URL, cabecera, payload o consulta.

- Métodos: Permite bloquear o permitir según las necesidades determinados métodos aplicados sobre el tráfico HTTP.

- Extensiones: Permite bloquear o permitir según las necesidades determinados tipos de extensiones de ficheros.

- Cabecera: Permite bloquear determinados tipos de cabeceras utilizadas por aplicaciones HTTP o bien incluso modificar las que emite el servidor para crear la confusión de un potencial atacante.

- Firmas: Pueden definirse mecanismo de bloqueos basado en palabras claves que afecten a la dirección URL, el encabezado o cualquier dato transmitido desde el origen o destino.

============================================================================
- Forefront TMG 2010: Configuración de parámetros RPC/HTTPS (1 de 2)
- Forefront TMG 2010: Configuración de parámetros RPC/HTTPS (2 de 2)
============================================================================

============================================================================
- MS Forefront Unified Access Gateway: Creación de Políticas de Seguridad de Acceso [I de IV]
- MS Forefront Unified Access Gateway: Creación de Políticas de Seguridad de Acceso [II de IV]
- MS Forefront Unified Access Gateway: Creación de Políticas de Seguridad de Acceso [III de IV]
- MS Forefront Unified Access Gateway: Creación de Políticas de Seguridad de Acceso [IV de IV]
============================================================================

Políticas basadas en complemento gráfico

Por contra al uso de expresiones, el otro modo de crear políticas es a través de un sistema gráfico. Éste, aunque no es tan flexible, permite definir condiciones a aquellos administradores que no trabajen habitualmente con VBScript. Como en el caso de las expresiones se diferencia también el tipo de plataforma sobre el que trabajar, aunque ya se realiza desde la propia política.

Decidida la plataforma sobre la que se trabajará, el editor de políticas correspondiente mostrará las variables en modo gráfico que podrán utilizarse. En esta circunstancia las operaciones lógicas con las que se pueden trabajar son menores: “AND” y “OR”. La siguiente figura muestra un ejemplo de política para sistemas Windows donde se han incluido una serie de condiciones a evaluar en la seguridad final del cliente.


Figura 7: Política de seguridad a través del editor de expresiones

Para cada componente Microsoft Forefront Unified Access Gateway UAG 2010 presenta una serie de elementos con los que trabajar. Principalmente se basan en consultas WMI con la que recoger en el cliente los estados de cada uno de los elementos. La siguiente imagen, muestra las condiciones de antivirus que debería tener el cliente para el cumplimiento de la seguridad exigida.


Figura 8: Definición del componente antivirus

Además de habilitar el componente, el administrador podrá definir los valores mínimos para versión y actualización que deberá presentar el producto para considerarlo dentro de las normas de cumplimiento. Hay que tener cuidado en este aspecto puesto que cualquier valor planteado incoherentemente implicaría el no cumplimiento de la política y por lo tanto se le denegaría el acceso.

Si por necesidad, una política que inicialmente se plantea en modo gráfico, se decide que hay que meter ciertos operadores más complejos, podrá optarse por convertirla en Script. Este proceso permitirá tratar la política como si fuera una expresión.


Figura 9: Conversión de la política en Script

El proceso de creación en script es irreversible y en adelante deberá tratarse la política como cualquiera otra de tipo expresión. La siguiente imagen muestra la conversión realizada en modo script, de la política de seguridad que se había creado anteriormente en modo gráfico.


Figura 10: Modo expresión de la “Política de seguridad de la organización”

============================================================================
- MS Forefront Unified Access Gateway: Creación de Políticas de Seguridad de Acceso [I de IV]
- MS Forefront Unified Access Gateway: Creación de Políticas de Seguridad de Acceso [II de IV]
- MS Forefront Unified Access Gateway: Creación de Políticas de Seguridad de Acceso [III de IV]
- MS Forefront Unified Access Gateway: Creación de Políticas de Seguridad de Acceso [IV de IV]
============================================================================