Página siguiente Página anterior Índice general

1. Introducción

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 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 informació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.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, 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).

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:
  2. Montar un proxy transparente es una chapuza:
  3. No es posible crear reglas de filtrado de paquetes independientes de las direcciones de interfaz:
  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:

  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:
  8. Incompatibilidad entre CONFIG_NET_FASTROUTE y el filtrado de paquetes:
  9. No es posible la inspección de los paquetes rechazados a causa de una protección de enrutado (p.ej. Source Address Verification).
  10. No hay manera de leer automáticamente los contadores de las reglas de filtrado de paquetes.
  11. CONFIG_IP_ALWAYS_DEFRAG es una opción en tiempo de compilación, cosa que le complica la vida a las distribuciones que quieren hacer un kernel de propósitos generales.

1.3 ¿Quién eres?

Soy el único lo suficientemente tonto para hacer esto. Como coautor de ipchains y como actual mantenedor del Cortafuegos IP del Kernel de Linux, puedo ver muchos de los problemas que la gente tiene con el sistema actual, además de saber lo que tratan de hacer.

1.4 ¿Por qué se cuelga?

¡Bueno! ¡Debería haberlo visto la semana pasada!

Porque no soy un gran programador como todos desearíamos, y ciertamente no he comprobado todas las situaciones, por falta de tiempo, equipo y/o inspiración. Sí que tengo una batería de pruebas, a la que le animo que contribuya.


Página siguiente Página anterior Índice general