Dispositivos SSL VPN
Redes privadas virtuales
Combinar seguridad y sencillez es lo que prometen las redes privadas virtuales basadas en SSL (SSL VPN). Comprobar en qué grado esto es verdad en la práctica fue el objetivo de la comparativa realizada por la Network World Global Test Alliance con gateways de este tipo de siete fabricantes, de los que NetScreen y Nokia se situaron en cabeza.
En la comparativa realizada por la Network World Global Test Alliance, se evaluaron los productos NetScreen-SA 5000 v3.3 (NetScreen Technologies), Nokia Secure Access System v1.1 (Nokia), FirePass Controller 4000 v4.02 (F5 Networks), Symantec Clientless VPN Gateway v4.02 (Symantec), Netilla Security Platform v4.01 (Netilla Networks), e-Gap Remote Access Appliance v2.5 y AEP SureWare A-Gate AG-600 v2 (AEP Systems.
Aunque de forma general todos los productos analizados están bien orientados al uso corporativo, destaca el de NetScreen por su excepcional soporte de aplicaciones, sus muy buenos mecanismos de control de accesos y por su interoperatividad global. Nokia, Symantec y F5 se sitúan a continuación gracias al amplio soporte de aplicaciones que ofrecen.
Se probó la interoperatividad de cada dispositivo con un total de 20 aplicaciones de empresa. Los tests se hicieron desde un punto de vista profesional, focalizándose muy especialmente en las prestaciones de seguridad y de control de accesos. En cuanto a características, se evaluaron las herramientas de logging, generación de informes y auditoría. También se probó la capacidad de escanear la integridad del cliente, que ayuda a garantizar que las funciones de cortafuegos y de escaneo de virus están actualizadas.
Cuando se trata de funciones de proxy y de conversión de aplicaciones (ver recuadro “Conceptos y técnicas”), se encontraron grandes diferencias entre los distintos. AEP y Whale fueron los más débiles en este área, mientras que Nokia fue el que ofreció el soporte más potente de conversión de aplicaciones para servidores de archivos Microsoft, FTP y Network File System (NFS). F5, Netscreen y Symantec ofrecen un subconjunto de los tres. Netilla sólo ofrecía conversión para Windows Terminal Services y un extenso conjunto de emuladores de terminal, incluyendo telnet, Secure Shell (SSH) e IBM 3270. F5 and NetScreen también incluyen soporte de emulación de terminal para telnet y SSH, pero sus emuladores sólo funcionaron el 25% de las veces que se intentaron.
Cuando algunas aplicaciones no pueden ser convertidas, los gateways SSL VPN tienen dos mecanismos para dar acceso directo a la red: port forwarding y extensión de red (ver recuadro “Conceptos y técnicas”. Pero ambas técnicas exigen desplazar software a la estación de trabajo del usuario final, lo que implica cuestiones de compatibilidad de navegador, posibles problemas con los sistemas operativos y cuestiones de seguridad. Respecto de este último punto, precisamente, cuando entran en acción las técnicas de port forwarding y extensión de red se pierde uno de los puntos fuertes de las SSL VPN, que reside en su capacidad para controlar accesos a nivel de aplicación, ya que dejan de ser “conscientes” de la aplicación subyacente.
Aplicaciones: factor clave
Todos los gateways analizados, excepto los de AEP y Netilla, proporcionan alguna funcionalidad port-forwarding. Sin embargo, como esta técnica no siempre resulta adecuada, algunos dispositivos añaden inteligencia para operar a nivel de aplicación en dos áreas: en e-mail, específicamente MAPI para clientes Exchange y Notes (NetScreen, Nokia y Symantec); y en clientes de sobremesa remotos mediante servicios de terminal de Citrix (NetScreen y Nokia).
En vez de dotar de mayor “inteligencia” al port forwarding, muchos SSL VPN optan por soportar extensión de red, técnica que consiste en conectar el sistema del usuario final a la red corporativa mediante controles de acceso exclusivamente basados en información de nivel de red, como dirección IP de destino y número de puerto. Tal era el caso de todos los gateways analizados, salvo los de Nokia y Whale.
Una característica común de este tipo de productos es la de soporte de e-mail. AEP, NetScreen, Nokia y Symantec incluyen proxies para los estándares SMTP (Simple Mail Transfer Protocol), POP (Post Office Protocol) e IMAP (Internet Message Access Protocol). Para añadir seguridad a estos protocolos, se encriptan desde el cliente al gateway mediante POP-over-SSL, IMAP-over-SSL y SMTP-over-SSL.
Problemas de interoperatividad
Comenzamos con cinco aplicaciones Web básicas, algunas de las cuales incluía JavaScript básico. El único fabricante que soporta las cinco aplicaciones sobre las siete plataformas fue Nokia; F5 y NetScreen, una menos; y Whale y Symantec, tres menos. AEP tuvo un mal comportamiento con dos de las aplicaciones, una con JavaScript y la otra contra un servidor Web protegido con SSL; de hecho, AEP, a diferencia del resto, no soporta servidores de back-end con SSL. Netilla restó puntos por perder gráficos, aunque las páginas se cargaban correctamente finalmente tras algunos intentos.
El siguiente test se llevó a cabo con las aplicaciones de correo Outlook Web Access 2003 y iNotes, versiones 6.0 y 6.5. Aquí, Nokia tuvo el mejor comportamiento, seguido de AEP y Symantec.
En todos los casos, está muy claro que los gateways necesitan cierta puesta a punto para funcionar correctamente. Eso es justo lo que hubo que hacer en la mayor parte de los sistemas a fin de incrementar la compatibilidad. Y no siempre es sencillo. Netilla es un buen ejemplo. Para definir una aplicación, se puede seleccionar “Fast HTML Translation” o “Full HTML Translation.” La única documentación existente para fundamentar una u otra elección es la ambigua nota “Fast resulta apropiado para la mayoría de las páginas.” Por el contrario, Whale dedica 75 páginas de documentación a cuestiones relacionadas con la puesta a punto del tratamiento de las aplicaciones.
En la tercera serie de tests se utilizaron tres aplicaciones Web avanzadas que incluían Java y diferentes tipos de Flash. Los resultados fueron pésimos. F5, NetScreen y Symantec puntuaron poco en este apartado, pero AEP, Netilla, Nokia y Whale no pasaron de cero. La lección es simple: las aplicaciones avanzadas con herramientas como Java y Flash no funcionarán fácilmente en los gateways SSL VPN si no se emplean técnicas como port forwarding o extensión de red.
Con el cuarto conjunto de pruebas se examinó el modo en que estos dispositivos trataban servidores de ficheros Microsoft, FTP y NFS mediante conversión de aplicaciones. No todos los dispositivos soportan todos los protocolos, y, en otros caos, algunas, en principio, buenas herramientas no lo eran siempre tanto. Así, la herramienta para servidores de archivos de F5 no trabajó apropiadamente con el navagador Safari utilizado; la de Netilla no lo hizo con ninguno salvo con Internet Explorer sobre Windows; y la de Whale no pudo tratar las versiones más antiguas de Internet Explorer ni de Netscape.
Además, hubo que vérselas con algunas dificultades con los productos de Nokia y Symantec en cuanto a compatibilidad de servidores FTP. Cuando se probó con un servidor FTP Unix estándar, ambos trabajaron perfectamente, pero no cuando se intentó con un servidor OpenVMS.
Las últimas series de tests se centraron en las capacidades de port forwarding y extensión de red, con la condición de que no se permitiese ningún soporte técnico. La primera co
En la comparativa realizada por la Network World Global Test Alliance, se evaluaron los productos NetScreen-SA 5000 v3.3 (NetScreen Technologies), Nokia Secure Access System v1.1 (Nokia), FirePass Controller 4000 v4.02 (F5 Networks), Symantec Clientless VPN Gateway v4.02 (Symantec), Netilla Security Platform v4.01 (Netilla Networks), e-Gap Remote Access Appliance v2.5 y AEP SureWare A-Gate AG-600 v2 (AEP Systems.
Aunque de forma general todos los productos analizados están bien orientados al uso corporativo, destaca el de NetScreen por su excepcional soporte de aplicaciones, sus muy buenos mecanismos de control de accesos y por su interoperatividad global. Nokia, Symantec y F5 se sitúan a continuación gracias al amplio soporte de aplicaciones que ofrecen.
Se probó la interoperatividad de cada dispositivo con un total de 20 aplicaciones de empresa. Los tests se hicieron desde un punto de vista profesional, focalizándose muy especialmente en las prestaciones de seguridad y de control de accesos. En cuanto a características, se evaluaron las herramientas de logging, generación de informes y auditoría. También se probó la capacidad de escanear la integridad del cliente, que ayuda a garantizar que las funciones de cortafuegos y de escaneo de virus están actualizadas.
Cuando se trata de funciones de proxy y de conversión de aplicaciones (ver recuadro “Conceptos y técnicas”), se encontraron grandes diferencias entre los distintos. AEP y Whale fueron los más débiles en este área, mientras que Nokia fue el que ofreció el soporte más potente de conversión de aplicaciones para servidores de archivos Microsoft, FTP y Network File System (NFS). F5, Netscreen y Symantec ofrecen un subconjunto de los tres. Netilla sólo ofrecía conversión para Windows Terminal Services y un extenso conjunto de emuladores de terminal, incluyendo telnet, Secure Shell (SSH) e IBM 3270. F5 and NetScreen también incluyen soporte de emulación de terminal para telnet y SSH, pero sus emuladores sólo funcionaron el 25% de las veces que se intentaron.
Cuando algunas aplicaciones no pueden ser convertidas, los gateways SSL VPN tienen dos mecanismos para dar acceso directo a la red: port forwarding y extensión de red (ver recuadro “Conceptos y técnicas”. Pero ambas técnicas exigen desplazar software a la estación de trabajo del usuario final, lo que implica cuestiones de compatibilidad de navegador, posibles problemas con los sistemas operativos y cuestiones de seguridad. Respecto de este último punto, precisamente, cuando entran en acción las técnicas de port forwarding y extensión de red se pierde uno de los puntos fuertes de las SSL VPN, que reside en su capacidad para controlar accesos a nivel de aplicación, ya que dejan de ser “conscientes” de la aplicación subyacente.
Aplicaciones: factor clave
Todos los gateways analizados, excepto los de AEP y Netilla, proporcionan alguna funcionalidad port-forwarding. Sin embargo, como esta técnica no siempre resulta adecuada, algunos dispositivos añaden inteligencia para operar a nivel de aplicación en dos áreas: en e-mail, específicamente MAPI para clientes Exchange y Notes (NetScreen, Nokia y Symantec); y en clientes de sobremesa remotos mediante servicios de terminal de Citrix (NetScreen y Nokia).
En vez de dotar de mayor “inteligencia” al port forwarding, muchos SSL VPN optan por soportar extensión de red, técnica que consiste en conectar el sistema del usuario final a la red corporativa mediante controles de acceso exclusivamente basados en información de nivel de red, como dirección IP de destino y número de puerto. Tal era el caso de todos los gateways analizados, salvo los de Nokia y Whale.
Una característica común de este tipo de productos es la de soporte de e-mail. AEP, NetScreen, Nokia y Symantec incluyen proxies para los estándares SMTP (Simple Mail Transfer Protocol), POP (Post Office Protocol) e IMAP (Internet Message Access Protocol). Para añadir seguridad a estos protocolos, se encriptan desde el cliente al gateway mediante POP-over-SSL, IMAP-over-SSL y SMTP-over-SSL.
Problemas de interoperatividad
Comenzamos con cinco aplicaciones Web básicas, algunas de las cuales incluía JavaScript básico. El único fabricante que soporta las cinco aplicaciones sobre las siete plataformas fue Nokia; F5 y NetScreen, una menos; y Whale y Symantec, tres menos. AEP tuvo un mal comportamiento con dos de las aplicaciones, una con JavaScript y la otra contra un servidor Web protegido con SSL; de hecho, AEP, a diferencia del resto, no soporta servidores de back-end con SSL. Netilla restó puntos por perder gráficos, aunque las páginas se cargaban correctamente finalmente tras algunos intentos.
El siguiente test se llevó a cabo con las aplicaciones de correo Outlook Web Access 2003 y iNotes, versiones 6.0 y 6.5. Aquí, Nokia tuvo el mejor comportamiento, seguido de AEP y Symantec.
En todos los casos, está muy claro que los gateways necesitan cierta puesta a punto para funcionar correctamente. Eso es justo lo que hubo que hacer en la mayor parte de los sistemas a fin de incrementar la compatibilidad. Y no siempre es sencillo. Netilla es un buen ejemplo. Para definir una aplicación, se puede seleccionar “Fast HTML Translation” o “Full HTML Translation.” La única documentación existente para fundamentar una u otra elección es la ambigua nota “Fast resulta apropiado para la mayoría de las páginas.” Por el contrario, Whale dedica 75 páginas de documentación a cuestiones relacionadas con la puesta a punto del tratamiento de las aplicaciones.
En la tercera serie de tests se utilizaron tres aplicaciones Web avanzadas que incluían Java y diferentes tipos de Flash. Los resultados fueron pésimos. F5, NetScreen y Symantec puntuaron poco en este apartado, pero AEP, Netilla, Nokia y Whale no pasaron de cero. La lección es simple: las aplicaciones avanzadas con herramientas como Java y Flash no funcionarán fácilmente en los gateways SSL VPN si no se emplean técnicas como port forwarding o extensión de red.
Con el cuarto conjunto de pruebas se examinó el modo en que estos dispositivos trataban servidores de ficheros Microsoft, FTP y NFS mediante conversión de aplicaciones. No todos los dispositivos soportan todos los protocolos, y, en otros caos, algunas, en principio, buenas herramientas no lo eran siempre tanto. Así, la herramienta para servidores de archivos de F5 no trabajó apropiadamente con el navagador Safari utilizado; la de Netilla no lo hizo con ninguno salvo con Internet Explorer sobre Windows; y la de Whale no pudo tratar las versiones más antiguas de Internet Explorer ni de Netscape.
Además, hubo que vérselas con algunas dificultades con los productos de Nokia y Symantec en cuanto a compatibilidad de servidores FTP. Cuando se probó con un servidor FTP Unix estándar, ambos trabajaron perfectamente, pero no cuando se intentó con un servidor OpenVMS.
Las últimas series de tests se centraron en las capacidades de port forwarding y extensión de red, con la condición de que no se permitiese ningún soporte técnico. La primera co
