PDF de programación - Linux netfilter hacking COMO

Linux netfilter Hacking COMO

Rusty Russell, lista de correo [email protected]
Traducido por Gabriel Rodríguez Alberich [email protected]
v1.0.1 sábado 1 de julio 1 18:24:41 EST 2000, traducción del 7 de noviembre de 2000

Este documento describe la arquitectura de netfilter en Linux, cómo hackearla, y algunos de los sistemas más
importantes que se asientan en ella, como el filtrado de paquetes, seguimiento de conexiones (connection tracking)
y Traducción de Direcciones de Red (Network Address Translation).

Contents

1 Introducción

1.1

1.2

1.3

1.4

¿Qué es netfilter? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

¿Qué hay de malo en lo que teníamos con el 2.0 y el 2.2? . . . . . . . . . . . . . . . . . . . . .

¿Quién eres?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

¿Por qué se cuelga? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 ¿Dónde puedo conseguir el último?

3 La arquitectura de Netfilter

3.1 La base de Netfilter

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Selección de paquetes: IP Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.1 Filtrado de Paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.2 NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 Seguimiento de conexiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4 Otros añadidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Información para programadores

4.1 Comprendiendo ip tables

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1.1 Estructuras de datos de ip tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1.2

ip tables desde el espacio de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1.3 Recorrido y uso de ip tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 Extendiendo iptables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.1 El kernel

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.2 Herramienta del espacio de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2.3 Utilizando ‘libiptc’

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Comprendiendo NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3.1

Seguimiento de conexiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 Extendiendo el seguimiento de conexiones/NAT . . . . . . . . . . . . . . . . . . . . . . . . . .

2

3

3

4

5

5

5

6

6

6

7

7

7

7

7

8

9

9

9

9

12

14

15

16

16

1.

Introducción

4.4.1 Objetivos NAT estándar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.2 Nuevos protocolos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.3 Nuevos objetivos NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4.4 Ayudantes de protocolo para UDP y TCP . . . . . . . . . . . . . . . . . . . . . . . . .

4.5 Comprendiendo netfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.6 Escribiendo nuevos módulos netfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.6.1 Conectándose a los ganchos netfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.6.2 Procesando paquetes en la cola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.6.3 Recibiendo comandos desde el espacio de usuario . . . . . . . . . . . . . . . . . . . . .

4.7 Manejo de paquetes en el espacio de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Portando los módulos de filtrado de paquetes desde 2.0 y 2.2

6 La batería de pruebas

6.1 Escribiendo una prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2 Variables y entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3 Herramientas útiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.3.1

6.3.2

6.3.3

6.3.4

gen ip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

rcv ip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

gen err . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

local ip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4 Random Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 Motivación

8 Agradecimientos

1 Introducción

Hola.

2

17

17

20

20

20

20

20

21

21

22

22

22

23

23

24

24

25

25

25

26

26

27

Este documento es un viaje; algunas partes se recorren con comodidad, y en otras zonas se encontrará casi
en la soledad. El mejor consejo que puedo darle es que coja una gran taza de café o chocolate caliente, se
siente en un cómodo asiento, y absorba los contenidos antes de aventurarse en el a veces peligroso mundo
del hacking de redes.

Para un mayor entendimiento del uso de la infraestructura existente sobre el sistema netfilter, recomiendo
la lectura del Packet Filtering HOWTO y el NAT HOWTO (disponibles en castellano). Para más infor-
mación sobre la programación del kernel, sugiero el Rusty’s Unreliable Guide to Kernel Hacking y el Rusty’s
Unreliable Guide to Kernel Locking.

(C) 2000 Paul ‘Rusty’ Russell. Bajo licencia GNU GPL.

1.

Introducción

3

1.1 ¿Qué es netfilter?

netfilter es un sistema para manipular paquetes que se encuentra fuera del interfaz normal de sockets de
Berkeley. Consta de cuatro partes. Primero, cada protocolo define ”ganchos” (IPv4 define 5), que son puntos
bien definidos en el recorrido de un paquete a través de la pila de ese protocolo. En cada uno de estos puntos,
el protocolo llamará al sistema netfilter con el paquete y el número del gancho.

En segundo lugar, hay partes del kernel que pueden registrarse para escuchar los diferentes ganchos de cada
protocolo. Entonces, cuando se le pasa un paquete al sistema netfilter, éste comprueba si alguien se ha
registrado para ese protocolo y ese gancho; si es así, cada uno de los que se ha registrado tiene la posibilidad
de examinar (y quizá alterar) el paquete en cuestión, y luego rechazarlo, permitir que pase, o pedirle a
netfilter que ponga el paquete en una cola para el espacio de usuario.

En tercer lugar,
ip queue driver) para enviarlos al espacio de usuario; estos paquetes se manejan asincrónicamente.

los paquetes que han sido colocados en la cola son recogidos (por el controlador

La parte final está constituida por comentarios útiles en el código y por la documentación. Esto juega un
papel decisivo en cualquier proyecto experimental. El lema de netfilter es (robado descaradamente a Cort
Dougan):

‘‘Entonces... >en qué es mejor esto que KDE?’’

(Este lema casi dice ‘Azótame, pégame, hazme usar ipchains’).

Además de este sistema crudo, se han escrito varios módulos que proporcionan una funcionalidad similar a
la que tenían los kernels anteriores (pre-netfilter). En particular, un sistema NAT extensible, y un sistema
de filtrado de paquetes extensible (iptables).

1.2 ¿Qué hay de malo en lo que teníamos con el 2.0 y el 2.2?

1. No hay establecida una infraestructura para pasar paquetes al espacio de usuario:

• La programación del kernel se hace difícil
• La programación del kernel tiene que hacerse en C/C++
• Las políticas de filtrado dinámicas no pertenecen al kernel
• 2.2 introdujo una manera de pasar paquetes al espacio de usuario mediante netlink, pero la
reinyección de paquetes es lenta, y sujeta a comprobaciones de ‘sanidad’. Por ejemplo, reinyectar
un paquete que afirma venir de una interfaz existente no es posible.

2. Montar un proxy transparente es una chapuza:

• Tenemos que observar todos los paquetes para ver si hay un socket ligado a esa dirección
• root puede ligar (bind :-) a direcciones externas
• No se pueden redirigir paquetes generados localmente
• REDIRECT no maneja respuestas UDP: redirigir paquetes UDP al puerto 1153 no funciona
porque a algunos clientes no les gustan las respuestas que vienen de otro puerto que no sea el 53.
• REDIRECT no se coordina con la asignación de puertos tcp/udp: un usuario podría conseguir un
puerto (shadowed) por una regla REDIRECT. (a user may get a port shadowed by a REDIRECT
rule)

• Ha sido interrumpido al menos dos veces desde la serie 2.1. Has been broken at least twice during

2.1 series.

1.

Introducción

4

• El código es extremadamente molesto. Considere el número de apariciones de #ifdef CON-
FIG IP TRANSPARENT PROXY en el 2.2.1: 34 apariciones en 11 ficheros. Compare esto con
CONFIG IP FIREWALL, que aparece 10 veces en 5 ficheros.

3. No es posible crear reglas de filtrado de paquetes independientes de las direcciones de interfaz:

• Se deben conocer las direcciones de interfaz locales para distinguir los paquetes generados local-

mente o los que terminan localmente de los paquetes redirigidos.

• Incluso esto es insuficiente en casos de redirección o enmascaramiento.
• La cadena forward (redirección) sólo tiene información de la interfaz de salida, lo que significa
que usted tiene que figurarse de dónde proviene el paquete utilizando sus conocimientos sobre la
topología de la red.

4. El enmascaramiento está encima del filtrado de paquetes:Las interacciones entre el filtrado de paquetes

y el enmascaramiento hacen que sea complejo manejar un cortafuegos:

• En el filtrado de entrada (input), los paquetes de respuesta parecen ir dest