3. nDPI
Anuncio
Proyecto Fin de Carrera 3. 3.1. Departamento de Ingenierı́a Telemática nDPI Vista general del proyecto En este apartado se va a explicar la organización interna del proyecto, es decir, se van a explicar los ficheros y directorios que obtenemos al realizar el clone del servidor remoto. Una vez realizado el clone, lo que nos encontramos es lo siguiente: [ root@redBorder−S t r o n g h o l d redBorder−ndpi ]# l s fwboot nDPI http . c NDPI−README i n s t a l l −redBorder−S t r o n g h o l d . sh patch i n s t a l l −t r a f f i c g e n . t x t PROYECT README iptables −1.4.7 redBorder−ndpi−s o u r c e . sh linux −2.6.32 −431.11.2. el6 . i686 El directorio iptables-1.4.7 contiene las fuentes de iptables modificadas para el proyecto redBorder-ndpi. Es importante mencionarlo puesto que se requieren las fuentes de iptables para adaptar la herramienta del espacio de usuario al nuevo contexto de Netfilter. El directorio linux-2.6.32-XXXX contiene las fuentes del kernel especificada por la versión XXXX ası́ como las modificaciones del core de Netfilter que dan soporte a las nuevas capacidades. El directorio nDPI contiene las fuentes de la herramienta de inspección profunda a nivel de aplicación con las modificaciones pertinentes. Además de modificar tanto el espacio de usuario y el espacio del kernel ha sido preciso modificar el funcionamiento del helper de ndpi para iptables de acuerdo al contexto a nivel de aplicación nuevo. El directorio fwboot contiene ficheros de configuración de reglas de iptables, ficheros de configuración y scripts para automatizar el servicio redBorder-ndpi en el arranque del sistema. El directorio patch contiene el parche para la versión del kernel modificada ası́ como los módulos adicionalmente requeridos para el correcto funcionamiento de Netfilter tras la modificación intrusiva. El script install-redBorder-Stronghold.sh permite instalar las fuentes del kernel, parchearlo y actualizar los módulos de Netfilter. De esta manera, el sistema estarı́a preparado para cargar redBorder-ndpi. Es el script que debe ejecutarse para instalar el servicio completo. El script redBorder-ndpi-source.sh permite recrear las condiciones de desarrollo en el sistema. Este script solamente debe usarse cuando se quiera volver a tareas de desarrollo y en ningún caso para instalar el servicio. El fichero http.c es un fichero modificado del proyecto nDPI que resuelve conflictos con librerı́as y definiciones antiguas. La explicación detallada de los problemas resueltos se detalla en el fichero adjunto NDPI-README. Por último, el fichero PROYECT README es un fichero que da una visión global del proyecto, explica el contenido y la función de todos los elementos involucrados y sirve de guı́a para la correcta instalación del servicio. 47 Proyecto Fin de Carrera Departamento de Ingenierı́a Telemática Centrándonos en la herramienta de inspección en capa 7, nDPI, lo que vemos es lo siguiente: [ root@redBorder−S t r o n g h o l d nDPI]# l s a c l o c a l . m4 i n s t a l l −sh AUTHORS l i b n d p i . pc ChangeLog l i b n d p i . pc . i n config . guess libtool config .h l t m a i n . sh config . h . in m4 config . log Makefile config . status M a k e f i l e . am c o n f i g . sub Makefile . in configure missing c o n f i g u r e . ac ndpi− n e t f i l t e r COPYING NEWS decomp README example README. ntop INSTALL src i n s t a l l n d p i . sh stamp−h1 En este proyecto dentro del proyecto redBorder-ndpi, me compete la autorı́a del script install ndpi.sh y las modificaciones sobre el helper para iptables que se encuentran en el directorio ndpi-netfilter. El script de instalación, ası́ como el proceso de instalación completo, serán analizados en profundidad en el siguiente apartado. Por ahora, vamos a mostrar simplemente las caracterı́sticas más importantes del proyecto nDPI de la misma forma en la que se han expuesto para el proyecto redBorder-ndpi. El script install ndpi.sh instala en el sistema las capacidades de inspección profunda a nivel de aplicación que nos proporciona nDPI, ası́ como el helper de iptables modificado para el nuevo contexto de Netfilter. En el directorio src se encuentran verdaderamente las fuentes de nDPI. Cabe destacar que existe una lista, tal y como se introdujo en el apartado de presentación de nDPI, con los ficheros fuente que realizan la detección de los distintos protocolos a nivel de aplicación. El directorio ndpi-netfilter contiene las fuentes del helper para iptables de la herramienta nDPI. Además contiene las modificaciones sobre esta herramienta de usuario para adaptarla al nuevo contexto de Netfilter. 48 Proyecto Fin de Carrera 3.2. Departamento de Ingenierı́a Telemática Instalación Para la instalación de las capacidades de inspección profunda a nivel de aplicación que proporciona nDPI está pensado el script install ndpi.sh. En este apartado vamos a ver parcialmente el contenido de dicho script pero vamos a ir explicando detalladamente la razón y el sentido de cada orden ejecutada por la consola en lugar de exponer el script directamente. Para ver el resultado final de dicho script se puede consultar la sección 12.3 install ndpi.sh. En primer lugar, hay que instalar las dependencias necesarias para poder compilar nDPI [ root@redBorder−S t r o n g h o l d nDPI]# yum i n s t a l l unzip , z i p , g c c n c u r s e s −d e v e l , i p t a b l e s −d e v e l , k e r n e l −d e v e l , l i b m l n −d e v e l , automake , l i b t o o l , l i b t o o l −l t d l −d e v e l Lo siguiente serı́a descargar las fuentes de nDPI, pero como ya disponemos de ellas pasamos a la instalación de la herramienta. Para ello vamos a alojar las fuentes del proyecto en la ruta /usr/src/ para poder trabajar con ellas: [ root@redBorder−S t r o n g h o l d redBorder−ndpi ]# cp −R . . / redBorder−ndpi / u s r / s r c / [ root@redBorder−S t r o n g h o l d nDPI]# cd / u s r / s r c / redBorder−ndpi /nDPI [ root@redBorder−S t r o n g h o l d nDPI]# . / c o n f i g u r e −−with−p i c −−p r e f i x =/opt / rb / −−s b i n d i r =/opt / rb / b i n / −−exec−p r e f i x =/opt / rb [ root@redBorder−S t r o n g h o l d nDPI]# make [ root@redBorder−S t r o n g h o l d nDPI]# make i n s t a l l Llegados a este punto tenemos en el sistema instalada la herramienta de inspección a nivel de aplicación pero no está relacionada de ninguna manera con el helper de Netfilter iptables. En el estado actual del sistema se pueden hacer llamadas a funciones en C que invoquen la detección en capa 7. Esto tal cual nos es de poca utilidad puesto que lo que se pretende es dar al administrador de la red las facilidades de configurar el firewall a partir de las reglas iptables. Haciendo uso de esa necesidad se incorpora al proyecto nDPI otro proyecto de autorı́a distinta al equipo de ntop y que puede encontrarse fácilmente en GitHub [36] ”heil/ndpi-netfilter” que es a su vez un fork del proyecto original de construcción del helper ndpi. Se tomó el proyecto ”heil/ndpi-netfilter” [36] porque era el fork más reciente probado sobre versiones del kernel 2.6.32. En el siguiente apartado se va a mostrar una visión general del proyecto ndpi-netfilter, de la misma manera que se ha hecho con el proyecto redBorder-ndpi y con el proyecto nDPI, y se va a explicar paso a paso el proceso de instalación para conseguir integrar el helper de iptables dentro del proyecto nDPI, y por tanto dentro de redBorder-ndpi. 49 Proyecto Fin de Carrera 3.3. Departamento de Ingenierı́a Telemática Integración del helper Antes de proceder con la instalación del helper de iptables para ndpi y de probar su funcionamiento, vamos a explicar brevemente la estructura del proyecto en ndpi-netfilter. Haciendo un ”ls” del directorio ndpi-netfilter: [ root@redBorder−S t r o n g h o l d ndpi− n e t f i l t e r ]# l s AUTHORS k e r n e l −patch COPYING Makefile INSTALL README ipt src El directorio ipt contiene el código fuente del helper ndpi para iptables, ”libxt ndpi.c” y un Makefile que permite compilarlo. Es la implementación del espacio de usuario del módulo ndpi para Netfilter. El directorio src contiene las fuentes del helper a bajo nivel, es decir en el espacio del kernel, que realizan llamadas a las funciones ndpi de las que se dispone para realizar la inspección en capa de aplicación. El fichero ”main.c” implementa la integración entre espacio de usuario (libxt ndpi.c) y el módulo ndpi en el espacio del kernel (llamadas al código fuente ndpi) de Netfilter. Incluye además librerı́as y un Makefile que permite la compilación. En el esqueleto del proyecto que implementa el helper ndpi se puede apreciar un detalle que será muy recurrente en lo que resta de memoria. La distinción entre espacio de usuario y espacio del kernel en el core de Netfilter va a suponer el grueso de este proyecto fin de carrera y la principal complejidad a la hora de construir el firewall de aplicación. El proceso de instalación de ndpi-netfilter es algo más laborioso que el proceso de instalación de nDPI. La instalación del helper supone la mitad del script ”install ndpi.sh” el cual puede ser visto en su totalidad en la sección 12.3 install ndpi.sh. Lo primero que debemos hacer, como siempre, es alojar las fuentes en el directorio /usr/src/. En este caso ya están alojadas puesto que el proyecto redBorder-ndpi ya tiene incluido ndpinetfilter en nDPI. Lo siguiente es copiar el fichero http.c del repositorio en la ruta donde se encuentran las detecciones de todos los protocolos de aplicación contemplados e irnos al directorio raı́z del proyecto ndpi-netfilter: [ root@redBorder−S t r o n g h o l d ]# cp −R p r o j e c t / redBorder−ndpi / h t t p . c / u s r / s r c /nDPI/ s r c / l i b / p r o t o c o l s [ root@redBorder−S t r o n g h o l d ]# cd / u s r / s r c /nDPI/ ndpi− n e t f i l t e r A continuación procedemos a compilar el helper con una particularidad. El proyecto ndpinetfilter está pensado para utilizar los Makefile del proyecto nDPI y compilar el helper recompilando parte del código fuente nDPI. Por ello, la llamada al Makefile se realiza desde el raı́z ndpi-netfilter al raı́z nDPI: 50 Proyecto Fin de Carrera Departamento de Ingenierı́a Telemática [ root@redBorder−S t r o n g h o l d ndpi− n e t f i l t e r ]# LANG=C NDPI PATH=/u s r / s r c / redBorder−ndpi /nDPI make Copiamos la librerı́a dinámica resultante en el directorio de librerı́as de iptables y copiamos el módulo xt ndpi generado en el directorio /lib/modules/KERNEL VERSION/extra. [ root@redBorder−S t r o n g h o l d ndpi− n e t f i l t e r ]# cp −R i p t / l i b x t n d p i . s o / l i b / x t a b l e s [ root@redBorder−S t r o n g h o l d ndpi− n e t f i l t e r ]# cp −R s r c / x t n d p i . ko . u n s i g n e d / l i b / modules /KERNEL VERSION/ e x t r a / x t n d p i . ko La ruta donde se deja el módulo xt ndpi es una ruta que en la resolución de dependencias automática se consulta previamente a consultar los módulos por defecto del sistema. Está pensado para cargar modificaciones y extensiones del sistema operativo a nivel de módulos del kernel priorizando la funcionalidad extra sobre la funcionalidad por defecto. Las librerı́as estáticas suelen estar en el mismo directorio o directorios cercanos al código fuente, mientras que una librerı́a dinámica está pensada para que un programa sin necesidad de incorporar las librerı́as de forma local pueda hacer uso de las funciones que quedan extraı́das en el fichero .so. De esta manera, un módulo del kernel del core de netfilter podrı́a hacer uso de las funciones de npdi sin necesidad de modificar a nivel de código las librerı́as de las que depende directamente. A continuación procedemos a la resolución automática de dependencias: [ root@redBorder−S t r o n g h o l d ndpi− n e t f i l t e r ]# depmod −a Comprobamos que el módulo se ha insertado correctamente: [ root@redBorder−S t r o n g h o l d ndpi− n e t f i l t e r ]# modprobe x t n d p i Reiniciamos el servicio iptables: [ root@redBorder−S t r o n g h o l d ndpi− n e t f i l t e r ]# service iptables restart 51 Proyecto Fin de Carrera Departamento de Ingenierı́a Telemática Y por último comprobamos que el helper ndpi está correctamente integrado: [ root@redBorder−S t r o n g h o l d ndpi− n e t f i l t e r ]# i p t a b l e s −m ndpi −−h e l p . . . [ ! ] −−v e r s i o n −V p r i n t package v e r s i o n ndpi match o p t i o n s : −−f t p Match f o r FTP p r o t o c o l p a c k e t s −−pop Match f o r POP p r o t o c o l p a c k e t s −−snmp Match f o r SNMP p r o t o c o l p a c k e t s −−imap Match f o r IMAP p r o t o c o l p a c k e t s −−dns Match f o r DNS p r o t o c o l p a c k e t s −−i p p Match f o r IPP p r o t o c o l p a c k e t s −−h t t p Match f o r HTTP p r o t o c o l p a c k e t s . . . −−r a d i u s Match f o r Radius p r o t o c o l p a c k e t s −−teamviewer Match f o r Teamviewer p r o t o c o l p a c k e t s −−sap Match f o r SAP p r o t o c o l p a c k e t s −−wgatsapp Match f o r Whatsapp p r o t o c o l p a c k e t s −−l o t u s n o t e s Match f o r L o t u s N o t e s p r o t o c o l p a c k e t s −−r e m ot e s c a n Match f o r Remote Scan p r o t o c o l p a c k e t s No se muestran todos los protocolos, que son más de 165, como es obvio pero obteniendo la salida por pantalla que se muestra se pueden determinar varias cosas: La instalación de la herramienta ndpi se ha realizado de forma exitosa La instalación del helper ha terminado correctamente • Se ha podido cargar la librerı́a libxt ndpi.so de forma correcta puesto que se muestra la ayuda • El módulo xt ndpi funciona con resolución automática de dependencias • Aún falta por probar que verdaderamente la detección funciona al aplicarla sobre una regla 52 Proyecto Fin de Carrera 3.4. Departamento de Ingenierı́a Telemática Pruebas de funcionamiento, incompatibilidades y problemas de seguridad al integrar nDPI Instalada la herramienta de detección profunda en capa 7 y probada la integración del helper ndpi en Netfilter solamente falta verificar que la herramienta ndpi hace su función de manera correcta. Para ello vamos a realizar pruebas de funcionalidad bajo las siguientes condiciones: La polı́tica por defecto del firewall es polı́tica restrictiva Solamente se permite un conjunto limitado de protocolos con habilidad de detección por parte de ndpi Antes de empezar a definir reglas hay que habilitar el forwarding en el equipo que hace de firewall: [ root@redBorder−S t r o n g h o l d ]# echo ”1” >> / p r o c / s y s / n e t / i p v 4 / i p f o r w a r d Vamos a establecer la configuración más básica que se nos ocurra. Por ejemplo vamos a establecer como regla de seguridad que el firewall debe bloquear todo el tráfico que no venga por el puerto 80 y el que venga por el puerto 80 y no sea HTTP. Para ello lo primero que debemos establecer es la polı́tica por defecto restrictiva: [ root@redBorder−S t r o n g h o l d ]# [ root@redBorder−S t r o n g h o l d ]# [ root@redBorder−S t r o n g h o l d ]# [ root@redBorder−S t r o n g h o l d ]# iptables iptables iptables iptables −F −P INPUT DROP −P OUTPUT DROP −P FORWARD DROP Y comprobamos que no existan reglas y que efectivamente se ha aplicado la polı́tica restrictiva: [ root@redBorder−S t r o n g h o l d ]# i p t a b l e s −L Chain INPUT ( p o l i c y DROP) t a r g e t p r o t opt s o u r c e d e s t i n a t i o n Chain FORWARD ( p o l i c y DROP) t a r g e t p r o t opt s o u r c e d e s t i n a t i o n Chain OUTPUT ( p o l i c y DROP) t a r g e t p r o t opt s o u r c e d e s t i n a t i o n Lo siguiente que hacemos es escribir las reglas de aceleración en capa de transporte según el estado de la conexión: [ root@redBorder−S t r o n g h o l d ]# i p t a b l e s −A FORWARD −m s t a t e −−s t a t e ESTABLISHED,RELATED −j ACCEPT Imponemos que solamente dejamos pasar las conexiones que vayan al puerto 80: [ root@redBorder−S t r o n g h o l d ]# i p t a b l e s −A FORWARD −p t c p −−d p o r t 80 −m s t a t e −−s t a t e NEW −j ACCEPT Y a continuación la detección en capa de aplicación: 53 Proyecto Fin de Carrera Departamento de Ingenierı́a Telemática [ root@redBorder−S t r o n g h o l d ]# i p t a b l e s −A FORWARD −p t c p −−s p o r t 80 −m ndpi −−h t t p −j ACCEPT i p t a b l e s −A FORWARD −p t c p −−d p o r t 80 −m ndpi −−h t t p −j ACCEPT Si vemos las reglas en su conjunto: i p t a b l e s −A FORWARD −m s t a t e −−s t a t e ESTABLISHED,RELATED −j ACCEPT i p t a b l e s −A FORWARD −p t c p −−d p o r t 80 −m s t a t e −−s t a t e NEW −j ACCEPT i p t a b l e s −A FORWARD −p t c p −−s p o r t 80 −m ndpi −−h t t p −j ACCEPT i p t a b l e s −A FORWARD −p t c p −−d p o r t 80 −m ndpi −−h t t p −j ACCEPT Podemos darnos cuenta de que las reglas de aceleración en función del estado de la conexión enmascaran por completo la inspección en capa de aplicación. Las reglas que involucran al módulo ndpi nunca llegan a cumplirse puesto que primero se aceptan conexiones al puerto 80 y en el siguiente paquete, ya establecida la conexión, siempre se cumple la primera regla. Podemos plantear una solución alternativa que pase por introducir la primera regla justo al final para forzar la ejecución del módulo ndpi y la detección a nivel de aplicación. i p t a b l e s −A FORWARD −p t c p −−d p o r t 80 −m s t a t e −−s t a t e NEW −j ACCEPT i p t a b l e s −A FORWARD −p t c p −−s p o r t 80 −m ndpi −−h t t p −j ACCEPT i p t a b l e s −A FORWARD −m s t a t e −−s t a t e ESTABLISHED,RELATED −j ACCEPT De esta manera se detecta el protocolo http por el puerto 80 y la inspección se realiza de manera correcta. Sin embargo, y a medida que el número de reglas crezca, esta solución está condenada al fracaso puesto que resulta tremendamente ineficiente invocar al módulo ndpi una vez por cada regla. Con esta solución serı́a inviable construir un firewall de aplicación que fuera lo suficientemente rápido como para estar en el borde de una red corporativa. Además, tanto en esta segunda configuración como en la primera, existe un agujero de seguridad provocado por el hecho de ”filtrar” en el nivel de aplicación y aceptar conexiones en el nivel de transporte. Ya hemos visto que aceptar conexiones en el nivel de transporte enmascara la inspección a nivel de aplicación por lo que en el escenario del segundo juego de reglas cabe hacerse la siguiente pregunta ¿Qué ocurre si al acabar las reglas no hay matching? La respuesta a esa pregunta es sencilla, puesto que se aceptan conexiones en capa de transporte, un protocolo desconocido por la herramienta de inspección en la capa de aplicación harı́a matching con la regla de aceleración de conexiones establecidas en capa de transporte y pasarı́a el firewall pese a que tuviéramos definida una polı́tica por defecto restrictiva. 54 Proyecto Fin de Carrera Departamento de Ingenierı́a Telemática El hecho de pensar que la herramienta de inspección a nivel de aplicación incrementa la seguridad del sistema puesto que el filtrado es más selectivo no es solo ineficiente sino que es ilusoria. No hay nada más peligroso que la sensación de seguridad cuando además es falsa, ya que protocolos sin identificar pasan el cortafuegos de manera transparente. Cualquier programador habilidoso puede inventarse un protocolo de aplicación y pasar el firewall sin más que esperar a que haga match con la última regla. Este último resultado unido a la ineficiencia de inspeccionar todos los paquetes a nivel de aplicación durante el tiempo que dura la conexión establecida hacen que prácticamente carezca de sentido construir una extensión para iptables para inspeccionar el nivel de aplicación. De hecho, es uno de los grandes motivos por los que no han proliferado los firewall de aplicación basados en Linux. Con el análisis exhaustivo de la integración de ndpi en Netfilter y con un mı́nimo de conocimiento de Netfilter nos preguntamos ¿De verdad funciona la herramienta ndpi?¿Es posible convertir Netfilter en un verdadero firewall de aplicación? La respuesta a la primera pregunta es que sı́, ndpi es una herramienta de detección muy eficiente y con un gran potencial. Es la dinámica de reglas inherente al firewall y a la construcción de Netfilter lo que hace su uso prácticamente inservible en este contexto. De hecho, usando el segundo juego de reglas, si ndpi detecta http en el puerto 80 hace match y si probamos a poner un servidor ssh escuchando en el puerto 80 y tratamos de pasar el cortafuegos, ndpi detecta que el protocolo no es http sino ssh y rechaza la conexión. Las pruebas realizadas y los resultados obtenidos se repiten, se explican detalladamente y se amplı́an en la sección 7.2 Casos de uso. La respuesta a la segunda pregunta es, evidentemente, que sı́. Se puede construir un firewall de aplicación en Linux pero no sin mancharse las manos. Como ya se ha comentado en otras secciones, Netfilter está pensado para ser un stateful firewall a nivel de transporte, y nada más. Para convertir Netfilter en un firewall de aplicación debemos modificar su comportamiento para hacerlo compatible con la herramienta ndpi y eficiente para su uso habitual. Las soluciones propuestas para hacer de Netfilter un firewall de aplicación se presentan en el apartado 4.4 Solución a los problemas y a las incompatibilidades. 55 Proyecto Fin de Carrera Departamento de Ingenierı́a Telemática palabra 56
