Partiendo de la base de que las aplicaciones y datos corporativos utilizan cada vez más los entornos de tecnología web, HTTP se ha convertido de facto en la nueva IP sobre el . En consecuencia, tanto los ataques XSS (Cross Site Scripting) como SQL Injection que explotan las vulnerabilidades en los navegadores o servidores web, representan en la actualidad una de las amenazas más importantes.
Por ello, y al hablar de protección contra dichas amenazas, es necesario tener en cuenta dos consideraciones fundamentales: la forma de detectar el ataque, y qué hacer, una vez se ha localizado.
¿Cómo detectar un ataque?
El método más fácil y rápido de detección es el uso de firmas de ataque (patrones de datos correspondientes a los ataques ya conocidos). Sin embargo, el mayor problema al confiar únicamente en ellas es que, una simple variación en el código del ataque, puede evitar que se detecten, lo que le permitiría a dicho ataque pasar desapercibido hasta que las firmas que contienen las nuevas modificaciones del código se actualicen en los servidores. Además, y por definición, las firmas son totalmente ineficaces contra nuevas formas de intrusiones que presenten patrones inesperados.
De esta forma, un mejor enfoque consiste en realizar un análisis más inteligente y profundo de los datos, en el que no sólo se identifique el nombre de la aplicación, sino también, se inspeccione al detalle la API, el protocolo, el contexto y el comportamiento de cada flujo de tráfico. No obstante, y a menos que el motor de prevención de ataques haya sido diseñado para realizar todos estos exámenes detallados desde un principio, el impacto en el rendimiento de las distintas capas de software adicional necesarias para realizar distintos análisis, puede ser desmedido.
¿Qué hacer, una vez que el ataque ha sido descubierto?
Bloquear el ataque es la consideración que parece obvia a primera vista. Sin duda, hay que bloquear. Pero, ¿qué ocurre sí no es posible identificar una amenaza de forma temprana, antes del momento de decidir si debemos bloquear o permitir el tráfico?
Dado que muchos firewalls de nueva generación tratan de identificar el flujo de aplicación tan sólo analizando el primer paquete, pueden ser fácilmente engañados por tácticas tan simples como el relleno (padding), por ejemplo utilizando una URL mucho más larga de lo necesario. Los firewalls deben decidir si bloquean o permiten el tráfico antes de que se sobrepase la ventana TCP (el número de paquetes que pueden ser enviados al servidor antes de recibir un acuse de recibo “ack”), ya que al sobrepasar esta ventana la comunicación se interrumpe en espera del acuse de recibo (ack). Por ello, estos dispositivos tienen que elegir entre: Permitir el paso, asumiendo el riesgo de que se produzca un ataque, o bloquear, y potencialmente interrumpir una sesión de usuario válida y legítima. Sorprendentemente, muchos firewalls adoptan el enfoque ingenuamente más optimista, de permitir el tráfico, de forma que cuando sería posible identificar el ataque, la decisión de permitir el tráfico ya ha sido tomada.
Desde este punto de vista, el bloqueo parecería la opción más segura pero, ante la posibilidad de interrumpir una sesión legítima, está lejos de ser la ideal. Sin embargo existen alternativas inteligentes que permiten resolver este conflicto aparentemente irresoluble entre seguridad y conectividad. Una alternativa eficaz sería redireccionar la sesión a un intermediario externo, por lo general un software o “proxy” que se ejecuta en otro servidor, pero implica la creación de conexiones adicionales (entre el cliente y el proxy y desde el proxy al servidor) lo que implica un alto impacto en el rendimiento.
IPS de Aplicación
Afortunadamente, hay una manera más ingeniosa de evitar los riesgos e inconvenientes anteriores. Si el firewall es capaz de realizar un juicio temporal sobre la identificación del tráfico que recibe hasta que la cadena de paquetes se haya completado, entonces se podrá solicitar su pase o su bloqueo. De esta forma, tendremos la certeza de poder interceptar el código malicioso o identificar el tipo de aplicación una vez que se haya detectado para bloquearlo, al tiempo que las sesiones legítimas pasarán sin sufrir interrupciones.
Haciendo uso de este «análisis avanzado» que acabamos de mencionar, sería posible que un cortafuegos debidamente dotado de la capacidad de «entender” el protocolo de la sesión, pueda proporcionar al cliente los acuses de recibo “ack” que está esperando del servidor. El cortafuegos envía los “ack” suplantando la identidad del servidor sin que se interrumpa la sesión.
NETASQ denomina a esta tecnología patentada Application IPS, (IPS de aplicación) y lo incluye de serie en toda la gama de sus productos UTM (equipos serie U y equipos gama S) así como en sus firewall de nueva generación (equipos NG).
