¿Su aplicación esta lista para un ambiente seguro?
¿Su aplicación esta lista para un ambiente seguro?
Por Yuri Diógenes
Traducido por Ricardo Gómez Rey
1. Introducción
A medida que aumentamos las capas de seguridad en un ambiente estamos propensos a caer en escenarios de incompatibilidad con las aplicaciones antiguas, problemas de rendimiento con aplicaciones que no habían sido diseñadas con seguridad en mente entre otros problemas. Hace un tiempo atrás trabaje en un caso aquí en Microsoft donde teníamos problemas de rendimiento de una aplicación que trabajaba en Windows donde tenía que acceder un Mainframe. Una aplicación que básicamente permitía que el usuario navegara en una estructura semejante a Windows Explorer, sin embargo los archivos presentes en la interface gráfica de la aplicación estaban localizados físicamente en el mainframe.
Bien, hasta ahí todo bien, en realidad la aplicación tenía mucha utilidad, sin embargo después de la implementación de Windows XP SP2 en red y la activación de Windows Firewall, la copia de un archivo que antes demoraba algunos segundos, paso a demorar algunos minutos.
Primero fue necesario un trabajo manual para detectar los puertos que la aplicación usaba por qué no había documentación del fabricante recomendándolos puertos necesarios para que la aplicación funcionara con éxito. Después de este trabajo, conseguimos tener la aplicación funcionando, sin embargo con el rendimiento degradado, lo que lo convertía en no viable.
Este articulo muestra una breve discusión sobre el escenario y cuál fue el resultado final del mismo.
2. Windows Firewall
Es común oír la frase: “Pero eso sucedió después que habilite el Firewall” y esto es común y muchas veces es lo esperado. Si antes usted tiene una casa, con una puerta abierta donde todos entran y salen sin pedir permiso, ahora usted tiene una casa con un portero, donde para todo el que entra es necesario que el portero confirme si es permitido o no. Esto es la premisa básica de la habilitación del Windows Firewall, podemos esperar lo siguiente cuando lo habilitamos:
- Programas clientes que dejan de acceder el servidor
- Programas que no consiguen transmitir datos por la red
- Accesos a estaciones que funcionaban y ahora no funcionan más.
Todo esto y mucho más hacen parte del costo de tener un ambiente seguro. En este momento no se debe desconectar el firewall pensando que esta es la solución, se debe procurar es que su aplicación funcione con el Windows Firewall habilitado.
Microsoft publico un artículo el 842242 con una lista de programas que pueden parar de funcionar cuando se habilita este recurso en Windows XP SP2. Vea esta lista antes de pensar que su software no es posible de trabajar con Windows Firewall
Para más detalles de cómo funciona el Firewall de Windows vea el siguiente White paper:
Understanding Windows Firewall
https://www.microsoft.com/windowsxp/using/security/internet/sp2_wfintro.mspx
3. Obteniendo Información
Como dije anteriormente, aunque las reglas y las excepciones en el Windows Firewall fueron creadas, continuábamos con el problema principal, que era la lentitud a la hora de copiar archivos.
Para obtener datos con el fin de diagnosticar la causa raíz usamos:
· Network Monitor: instalamos el network monitor en Windows XP, con eso podíamos hacer una captura de paquetes y verificar con precisión que estaba aconteciendo. Ustedes pueden bajar el Network Monitor del link: ftp://ftp.microsoft.com/PSS/Tools/NetMon/
· Habilitamos el log de paquetes que fueron descartados para el firewall. Ustedes pueden habilitarse log con el comando “netsh firewall set logging droppedpackets = enable”, o a través de la interfaz gráfica en Panel de control / Windows Firewall / Advanced / Security Logging;
Con estas opciones habilitadas necesitábamos ahora realizar la simulación o problema pata que pudiésemos tener la captura del log de paquetes que fueron descartados.
4. Analizando los Datos
Comencemos entonces con el log del Firewall, que está localizado en el siguiente camino %Windir%\pfirewall.log. Este log tiene el siguiente encabezado:
#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
Para más información sobre como interpretar cada campo de este log vea el artículo:
Troubleshooting Windows Firewall settings in Windows XP Service Pack 2
https://support.microsoft.com/?id=875357
Nota: Importe este log en Excel y así podrá usar el auto filtro de Excel, eso permitirá que usted por ejemplo, filtre los paquetes por protocolo = TCP o acción = DRP.
Usando esta simple ayuda, es posible verificar con facilidad que habían diversos paquetes descartados (Action = DROP), cuyo campo TCPFLAGS era igual a R, que significa RST (Reset the concection). Lo que continuaba siendo extraño, Pues un “RST”es un Flag que es aceptable y utilizado normalmente en el Stack de TCP/IP. En realidad el TCP utiliza el bit de R (RST o Reset) para reiniciar una conexión TCP, por ejemplo, como una respuesta para un pedido de conexión a un servicio inexistente, como la muestra la figura de abajo:
Con este bit configurado para “R” teníamos a primera vista que verificar la causa raíz del problema, en este momento surgían dos preguntas claves: Por qué Windows esta reseteando el paquete del host (mainframe) y por que el paquete está siendo descartado. Para respondernos estos “por qué” fue necesario analizar la captura de red. En el resultado de la captura de paquetes con el Network Monitor, el encabezado de TCP era parecido al mostrado abajo:
Note que en este caso no estamos recibiendo un RST,ACK convencional, en realidad estamos recibiendo un RST, PUSH. Este flag PUSH es usado para asegurar que el dato está siendo entregado con la debida prioridad, sin embargo esto afecta totalmente la forma con que los datos son tratados en ambos lados de la comunicación.
En este caso teníamos un paquete viniendo del mainframe con esta secuencia, que a su vez era descartado por el firewall, teniendo en cuenta que no era el tipo de secuencia esperada.
5. Conclusión
Este artículo fue en realidad apenas un ejemplo de cómo las cosas pueden ser complicadas cuando no tenemos documentación suficiente de la aplicación con sus debidos requisitos de comunicación. La tendencia es que cada vez más el Firewall de Windows esté presente tanto en los computadores personales como en los computadores corporativos. Mas allá de esto muchas mejoras de seguridad están presentes en Windows vista, y que también van a requerir que las aplicaciones de terceros sigan documentaciones precisas en forma que no tengamos tanto efecto colateral en el uso del Firewall.
En este caso especifico no teníamos documentación suficiente acerca de la aplicación, era difícil realmente prever si esta requería solamente los puertos que detectamos o si era preciso abrir más puertos. También no fue posible obtener respuesta de por qué la aplicación del lado del servidor enviaba un RST, PUSH – teníamos la hipótesis estaba reiniciando la conexión debido a que Windows estaba enviando un acceso tentativo en un puerto no disponible, pero si eso era verdad, por que estaba siendo enviado el PUSH en vez de un ACK.
Recuerde, la utilización del firewall es algo que depende mucho de la forma en que las aplicaciones funcionan para abrir las conexiones de redes. No tendría sentido tener un firewall si la aplicación necesita de todos los 65.534 puertos para la comunicación.
6. Referencias
Microsoft Windows 2000 TCP/IP Implementation Details
https://www.microsoft.com/technet/itsolutions/network/deploy/depovg/tcpip2k.mspx
Manually Configuring Windows Firewall in Windows XP Service Pack 2
https://www.microsoft.com/technet/community/columns/cableguy/cg0204.mspx
Inappropriate TCP Resets Considered Harmful
ftp://ftp.rfc-editor.org/in-notes/rfc3360.txt
Explanation of the
Three-Way
Handshake via TCP/IP
https://support.microsoft.com/kb/172983/EN-US/
The Basics of Reading TCP/IP Traces