Podcast – 39 – Deep Packet Inspection

El capítulo de hoy ha surgido tras atender una charla comercial vía videoconferencia donde el presentador repetía una y otra vez la gran capacidad de Deep Packet Inspection de su solución. Pero, ¿seguro qué sabía lo que es, en realidad, Deep Packet Inspection?

Fuente imagen: AltenCalSoftLabs

Técnicamente hablando la denominación Deep Packet Inspection, que ha ganado bastante fuerza en el mundillo comercial y del marketing, debe utilizarse para una familia de técnicas de análisis de tráfico en el que lo que se examina no es la cabecera sino la información enviada en el paquete de datos.

Un firewall tradicional, de lo que sólo miran la tupla clásica (es decir, IP origen/destino, los puertos origen y destino; y el protocolo utilizado) tiene suficiente con mirar las cabeceras para tener toda la información necesaria para realizar su trabajo, así que estos equipos no revisan el campo de datos de los paquetes IP que gestionan. En cambio, los actuales firewalls con capacidad de seguimiento de protocolos, o lo que comercialmente se llama Next Generation Firewall, al analizar el comportamiento del protocolo necesitan analizar el campo de datos de los paquetes para tener la información necesaria. Por ejemplo, un Next Generation Firewall al gestionar el protocolo FTP permite la primera conexión al puerto 21 y luego analizará esa conexión para saber qué puerto aleatorio se ha elegido para empezar la transmisión. Así el firewall permitirá una conexión en un puerto aleatorio que, en situación normal no hubiera permitido.

Otros ejemplos clásicos son los sistemas de seguridad WAF o IDS/IPS, ya que su función es precisamente analizar las peticiones que llegan a los sistemas y revisa si las solicitudes son correctas o malintencionadas. Así que estos sistemas deben revisar el campo de datos de los paquetes y datagramas que circulan por la red.

Los proxies de navegación pueden parecer un ejemplo claro de inspección de profunda de paquetes, ya que su función es revisar las direcciones web consultadas para poder aplicar las políticas definidas por los administradores (control de acceso, categorización, etc.), su inclusión o no dentro de esta categoría en función de la arquitectura de uso. Es decir, si en nuestra empresa tenemos un proxy de navegación conocido por todos y nuestros sistemas operativos están configurados para utilizarlo, no podemos considerar que ese proxy entre dentro de la categoría ya que no se está analizando el tráfico de la red, sino que se lo enviamos conscientemente. Aquí tenemos una comunicación cliente-servidor tradicional. Si configuramos un proxy de navegación transparente que capture el tráfico sin que el cliente lo sepa, sí que entraríamos en nuestra categoría: tenemos un equipo no detectado por cliente o servidor que analiza los campos de datos y no sólo la cabecera.

Obviamente las capacidades de obtención de información de análisis los sistemas de Análisis Profundo de Paquetes son muy útiles en funciones de seguridad y, por ello, se utilizan mucho, pero la próxima vez que un comercial os cante las bondades de la Deep Packet Inspection.. preguntadle qué hace exactamente su sistema y porqué es novedoso… porque muchas veces las técnicas de recolección de datos son las mismas y lo que cambia de una solución a otra es cómo trata la información y qué hace con ella.

Descarga directa.

2 comentarios en “Podcast – 39 – Deep Packet Inspection

  1. jorge

    Hola Andreu,

    Te felicito por el post. explicación impecable.
    Como sugerencia me gustaría proponer un podcast hablando de deep packet inspection con trafico cifrado.
    ¿Es posible? latencia? certificados?

    Un abrazo,
    Jorge

    1. Andreu Adrover Autor

      Buenas Jorge

      Gracias por escucharme y pasarte por el blog.

      El tráfico cifrado no debería ser analizable por un tercero… salvo que tenga alguno de los certificados para poderlo descifrar 😉
      Una configuración habitual en los WAF es subirle los certificados seguros de las páginas que web que quiere proteger para poder así abrir el cifrado y analizar las peticiones, para luego pasarle, o no, el tráfico a los servidores web propiamente dichos.

      Obviamente, el cifrado/descifrado del tráfico por parte de un equipo intermedio implica una latencia en el tráfico, pero si tenemos un equipo bien dimensionado y con capacidad suficiente no debería ser detectable para una usuario humano.

      Saludos

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *