PDF de programación - Intercepción de tráfico en sistemas GNU/Linux

INTERCEPCIÓN DE TRÁFICO EN SISTEMAS GNU/LINUX

Jon Ander Ortiz Durántez

[email protected]

20 de Febrero del 2006

La intercepción del tráfico  esta considerado por parte de los desarrolladores de IDS´s como uno

de los pasos fundamentales para dar solución a los problemas de seguridad actuales, solucionando los
problemas que pueden surgir de las respuestas activas (como puede ser el caso de el SnortSam), y
dando una respuesta en tiempo real a las necesidades de seguridad reclamadas hoy en día.

ÍNDICE

1. La importancia de la intercepción de tráfico............................................................1
2. Introducción a la gestión de tráfico en sistemas GNU/Linux..................................2
3. Primera aproximación a la intercepción de tráfico: A nivel de kernel.................. 4
4. Modificando iptables desde userland (libiptc)..........................................................7
5. Comunicación kernel­userland via netlink...............................................................8
6. Intercepción desde userland: libipq..........................................................................10

I

  _________________________________Copyleft____________________________________

Copyright (c) 2006 Jon Ander Ortiz Durántez         

This    work     is   licensed   under    the    Creative    Commons      Attribution­

NonCommercial­ShareAlike License. To view a copy of this license, visit

http://creativecommons.org/licenses/by­nc­sa/2.0/ or send a letter to Creative

Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

Copyright (c) 2006 Jon Ander Ortiz Durántez.

           

Esta obra esta licenciada ba jos los términos de la licencia Atribuciónn­No Comercial

Comparte Igual de Creative Commons. Para ver una copia de esta licencia visite
http://creativecommons.org/licenses/by­nc­sa/2.0/es/deed.es o escriba una carta a
Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

   IMPORTANCIA DE LA INTERCEPCIÓN DE TRÁFICO
1.     
 
 

La intercepción de tráfico consiste en el análisis del tráfico antes de enrutarlo, es decir, que

podemos analizar, manipular, autorizar o denegar el tráfico que pasa, sale o viene a nuestro sistema.

Tradicionalmente se han utilizado otro tipo de librerías para analizar el tráfico de red tal y como
llega a nuestro sistema (como por ejemplo Libpcap), pero hay que tener en cuentra que este tráfico se
trata de una copia de lo que pasa por la red en ese instante, por lo que no tenemos posibilidad de poder
manipular dicho tráfico, sólo podemos analizarlo.

La intercepción de tráfico se utiliza principalmente para sistemas de seguridad y IPS (Intrusion
Prevention Systems), la intercepción de echo es lo que marca la diferencia entre los IPS y los IDS, ya
que estos últimos sólo pueden detectar los ataque, pero la capacidad de respuesta es bastante reducida,
dadas las caracteríasticas de los datos que recibe (Se tratan de copias del trafico de red).
Tradicionalmente este tipo de aplicaciones utilizan la respuesta activa (como la solución SnortSam1 –
un output plugin para el Snort),en el mísmo IDS al detectar un ataque, actué sobre el entorno para
eliminar esa amenaza (actualizar las reglas de iptables del router para bloquear determinada IP). Este
sistema es débil por naturaleza:

• Es débil ante los ataques spoofeados.
• No evita que los paquetes con los que se ha detectado el ataque lleguen a su destino.

Los sistemas que implementan la intercepción de tráfico, solucionan estos problemas:

• Todos los paquetes que son detectados como ataque pueden ser desechados.
• No somos sensibles ante los ataques spoofeados, porque no se modifica el entorno.

La principal contrapartida de la intercepción de tráfico es que se introduce un lag en la

comunicación.

La herramienta más conocida que implementa intercepción de tráfico es el IPS Snort­Inline2, que

intercepta tráfico de la librería libipq (en sistemas linux) o de ipfw (en sistemas BSD).

1 http://www.snortsam.net/
2 http://snort­inline.sourceforge.net/

1

2.INTRODUCCION A LA GESTIÓN DE TRÁFICO EN SISTEMAS

GNU/LINUX

Los sistemas GNU/Linux siempre se han caracterizado por ser grandes sistemas orientados (en

mayor o menor medida), hacia las redes, esto hace que la gestión adecuada del tráfico de red sea una
tarea imprescindible para el kernel. 

Hoy en día la parte encargada de la seguridad de el tráfico de red que recorre las pilas de los
protocolos correspondientes es NETFILTER, existente desde el Kernel 2.4, se trata de una parte del
kernel que se encarga de filtrar y dar acceso  a los diversos módulos del kernel a las pilas de los
protocolos.

Pero antes de NETFILTER, existían otras soluciones,   en los kernels 2.2, 2.0 y anteriores, como

pueden ser ipchains o ipfwadm (El cual deriva de la solucion ipfw de BSD). El propio Rusty Rusell3,
explica las razones [RR001] de dicho cambio de arquitectura y filosofía de ipchains a Netfilter, entre
otras:

• No había una infraestructura para pasar paquetes a espacio de usuario. (Se realizó una

solución mediante Netlink, pero era extremadamente lenta).

• No era posible crear reglas de filtrado de paquetes independientes de las direcciones de

interfaz. (Había que conocer las direcciones de las interfaces locales para poder distinguir
los paquetes).

• La programación del kernel era un cáncer.

¿QUE ES AHORA NETFILTER?

Netfilter es una serie de ganchos (hooks), en varios puntos de la pila de protocolos (No es parte

de la pila de protocolos ni nada por el estilo):

­­­>[1]­­­>[ROUTE]­­­>[3]­­­>[4]­­­>

            |        
          ^
            |                      |

                        |                [ROUTE]
  
     

           
           
  
    
        
                     
             
            
Estructura de ganchos de Netfilter dentro de la pila ipV4.

            v                     |
[2]                 [5]
 |                     ^
             |                      |
            v                      |

NF_IP_PRE_ROUTING [1]
NF_IP_LOCAL_IN [2]
NF_IP_FORWARD [3]
NF_IP_POST_ROUTING[4]
NF_IP_LOCAL_OUT[5]

3 Desarrollador de IPCHAINS y NETFILTER (sigue manteniendo actualmente este último en el Kernel 2.6).

2

El recorrido que siguen los paquetes por la pila del protocolo IPV4 Es el siguiente:

– El paquete entra por la izquierda se realiza sobre el, comprobaciones de seguridad

(sanity checks), y entra al primer gancho NF_IP_PRE_ROUTING.

– Pasamos a un proceso de enrutamiento que decide si el paquete viene a un proceso

local, o en su lugar es un paquete que hay que enrutar por otra interfaz. En este punto
puede haber paquetes que sean desechados porque no pueden ser enrutados.

– Si está dirigido a otra interfaz ­> Lo pasa a otro gancho:  NF_IP_FORWARD.
– Si es un paquete para un proceso local, pasa a el gancho:  NF_IP_LOCAL_IN.
– El tráfico que se genera en los procesos locales pasan por el gancho:

NF_IP_LOCAL_OUT, antes de enrutarse bien a un proceso local o a otra interfaz.
– Todo el trafico saliente del sistema, pasa por el gancho   NF_IP_POST_ROUTING.

Por lo tanto, Netfilter, proporciona, aparte de otros servicios que luego comentaremos, una serie

de ganchos (hooks) a los que diferentes módulos del kernel pueden engancharse (hookearse), para
filtrar / manipular ellos mismos el tráfico.

¿Y QUE SON EN REALIDAD LAS IP TABLES?

Las ip tables es un sistema de selección de paquetes sobre el sistema Netfilter. Se trata de un
sistema totalmente extensible, cualquier modulo del kernel puede decirle darle a iptables una tabla
nueva y decir que los paquetes pasen por la misma. 

Internamente está compuesto por tres tablas (filter – filtra los paquetes, mangle – como

manipular los paquetes antes de enrutarlos, nat – Para traducciones de direcciones de red ).

Los filtros se aplican desde la tabla filter ­> solo filtran los paquetes en ningún momento pueden
modificar los paquetes.  Los filtros se aplican sobre los ganchos NF IP LOCAL IN, NF IP FORWARD
y NF IP LOCAL OUT. (Input forward y Output en las construcciones de las reglas de iptables).
Las traducciones o NAT se aplican desde la tabla nat, estas se alimentan de tres ganchos:
• NF IP PRE ROUTING y NF IP POST ROUTING , para alterar el origen y el destino de los

paquetes no – locales.

• NF IP LOCAL OUT para alterar el destino de los paquetes locales.

Iptables proporciona un vector en memoria kernel que puede ser leído y modificado desde zona

de usuario mediante setsockopt y getsockopt. (para ello probar a hacer un strace en el comando iptables
;)).

3

3. PRIMERA APROXIMACIÓN A LA INTECEPCIÓN DE

TRÁFICO: A NIVEL DE KERNEL

La intercepción de tráfico a nivel de kernel, es adecuada solamente cuando el flujo de paquetes a

analizar es muy alto, dado que hoy en día la intercepción de tráfico se puede hacer a nivel de usuario,
de una manera mucho más sencilla que programar un LKM.

Para el ejemplo que vamos a realizar vamos a utilizar la interfaz que netfilter provee a nivel de

kernel para utilizar los ganchos que tiene sobre la pila de protocolos.

//code
#define __KERNEL__
#define MODULE

#include <linux/config.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/version.h>

#include <linux/init.h>
#include <linux/netdevice.h> 
#include <linux/netfilter_ipv4.h>
#include <linux/skbuff.h>
#include <linux/netfilter.h>
#include <linux/ip.h>
#include <asm/checksum.h> //De aqui utilizamos la ip_fast_csum

static struct list_head lista = {NULL,NULL};
//La lista es solo para funcionamiento interno de la función 
static struct nf_hook_ops operations;

static unsigned int operation_hook(unsigned int hook, 

struct sk_buff **skb,

  const struct net_device *indev, const
  struct net_device outdev, int (*okfn)
  (struct sk_buff *))
  

(*skb)­>nfcache=NFC_UNKNOWN;
printk("Paquete! %d \n",(*skb)­>len);
if ((*skb)­>nh.iph­>protocol == 0x01){ //Si etamos en el icmph
(*skb)­>nh.iph­>protocol = 0x02; //Lo cambiamos =)
(*skb)­>nh.iph­>check=0; //