PDF de programación - netfilter-hacking-COMO

30/7/18
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

netfilter-hacking-COMO.txt

1

Este documento describe la arquitectura de netfilter en Linux, cómo

_h_a_c_k_e_a_r_l_a, y algunos de los sistemas más importantes que se asientan

en ella, como el filtrado de paquetes, seguimiento de conexiones (con-
nection tracking) y Traducción de Direcciones de Red (Network Address
Translation).
______________________________________________________________________

Índice general

1. Introducción
1.1 ¿Qué es «netfilter»?
1.2 ¿Qué hay de malo en lo que teníamos con el 2.0 y el 2.2?
1.3 ¿Quién eres?
1.4 ¿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.2.2.1 Enmascaramiento, redireccionamiento de puertos y proxys transparentes
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.1.1 Nuevas funciones de concordancia
4.2.1.2 Nuevos objetivos
4.2.1.3 Nuevas tablas
4.2.2 Herramienta del espacio de usuario
4.2.2.1 Nuevas funciones de concordancia
4.2.2.2 Nuevos objetivos
4.2.3 Utilizando `libiptc'
4.3 Comprendiendo NAT
4.3.1 Seguimiento de conexiones
4.4 Extendiendo el seguimiento de conexiones/NAT
4.4.1 Objetivos NAT estándar
4.4.2 Nuevos protocolos
4.4.2.1 Dentro del kernel
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 gen_ip
6.3.2 rcv_ip
6.3.3 gen_err
6.3.4 local_ip
6.4 Random Advice

7. Motivación
8. Agradecimientos

file:///home/xavi/smbhome102/xavi/pdfs/tmp/181.10.47.218/compartir/biblioteca/INFOSEC/FW-IPTABLES/netfilter-hacking-COMO.txt

30/7/18

netfilter-hacking-COMO.txt

2

______________________________________________________________________

11.. IInnttrroodduucccciióónn

Hola.

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 _h_a_c_k_i_n_g 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 información

sobre la programación del kernel, sugiero el _R_u_s_t_y_'_s _U_n_r_e_l_i_a_b_l_e
_G_u_i_d_e
_t_o _K_e_r_n_e_l _H_a_c_k_i_n_g y el _R_u_s_t_y_'_s
_U_n_r_e_l_i_a_b_l_e _G_u_i_d_e _t_o _K_e_r_n_e_l _L_o_c_k_i_n_g.

(C) 2000 Paul `Rusty' Russell. Bajo licencia GNU GPL.

11..11.. ¿¿QQuuéé eess ««nneettffiilltteerr»»??

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, los paquetes que han sido colocados en la cola son
recogidos (por el controlador ip_queue_driver) para enviarlos al
espacio de usuario; estos paquetes se manejan asincrónicamente.

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).

11..22.. ¿¿QQuuéé hhaayy ddee mmaalloo eenn lloo qquuee
tteennííaammooss ccoonn eell 22..00 yy eell 22..22??

file:///home/xavi/smbhome102/xavi/pdfs/tmp/181.10.47.218/compartir/biblioteca/INFOSEC/FW-IPTABLES/netfilter-hacking-COMO.txt

30/7/18
11..22.. ¿¿QQuuéé hhaayy ddee mmaalloo eenn lloo qquuee
tteennííaammooss ccoonn eell 22..00 yy eell 22..22??

netfilter-hacking-COMO.txt

3

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 ttooddooss 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.

· El código es extremadamente molesto. Considere el número de
apariciones de #ifdef CONFIG_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 localmente 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 destinados a la propia máquina

· En el filtrado de redirección (forward), los paquetes
desenmascarados no se pueden ver

file:///home/xavi/smbhome102/xavi/pdfs/tmp/181.10.47.218/compartir/biblioteca/INFOSEC/FW-IPTABLES/netfilter-hacking-COMO.txt

30/7/18
· En el filtrado de salida (output), los paquetes parecen venir de
la máquina local

netfilter-hacking-COMO.txt

4

5. La manipulación del TOS, la redirección, el ICMP unreachable y el
marcado (mark) (que pueden proporcionan redirección de puertos,
enrutado y QoS) también están encima del código de filtrado de
paquetes.

6. El código de ipchains no es ni modular ni extensible (p.ej.
filtrado de direcciones MAC, opciones de filtrado, etc).

7. La falta de una infraestructura suficiente ha llevado a la
profusión de distintas técnicas:

· Enmascaramiento, además de módulos por cada protocolo

· NAT estático veloz mediante código de enrutamiento (no tiene
manejo por protocolo)

· Redirección de puertos (port forwarding), redirección, auto
redirección (auto forwarding)

· Los Proyectos NAT