No sé hasta que punto esto es off-topic, porque hace algún tiempo alguien de esta lista también estaba luchando con los iptables. Creo entender bastante bien como funciona TCP/IP, pero con iptables también soy novato. Descubrí un truquillo que puede ser de utilidad para otros.
Cada cadena de cada tabla es procesada desde arriba para abajo. Y si activamos en el kernel el target especial LOG, podemos colocar al final de cada cadena una regla que mande un log para el syslog. Por ejemplo: iptables -t nat -A POSTROUTING -j LOG --log-level debug --log-prefix "nat-post:" (Si dejo fuera el "--log-level debug", el kernel lo escribirá en la terminal activa.) Si todo está activado en el kernel, sería necesario hacerlo para las tablas mangle, nat y filter. Con iptable -t mangle -L puedo ver qué cadenas existen para la tabla mangle, etc. Lo que hice es lo siguiente: Empecé el script limpiándolo todo (flush) para poder correr el script tantas veces como fuese necesario. Entonces, defino las default policies (en mi caso, todo DROP), y al final (dejando un hueco para las reglas) estas líneas con el LOG. Entonces me abro otra terminal y visualizo lo que está pasando con tail -f /var/log/debug. Y antes de probarlo, hago un "sh script" para hacerlo efectivo. Si ahora intento hacer alguna cosa, como lanzar un ping o usar ssh, a parte de no funcionar, la terminal del log me va a decir que la regla por defecto hizo caer un paquete, indicando los interfaces, IP's, direcciones MAC, puertos, protocolos, bueno todo lo que puede ser relevante. Con esto es fácil ver lo que tengo que permitir pasar. Entonces coloco una regla e intento de nuevo. Lo bonito es que puedo observar interactivamente que paquetes son usados por los diferentes protocolos y como atraviesan las tablas y cadenas. Cuando todo está funcionando, uso el -L otra vez para ver si una regla mas general hace redundante una regla mas específica, limpiándolo todo. Hay algunos casos en que un target REJECT sería mejor que DROP (al menos que implique un peligro de un DoS), los que también puedo ver en el log. La diferencia es el mensaje de error que da el programa en cuestión. Mi estrategia es: Todo está prohibido lo que no está explicitamente permitido. Por eso, todas las default policies las tengo en DROP. Con esta técnica defino las reglas más específicas posibles, permitiendo sólo lo imprescindible. También se puede empezar con una default policy de ACCEPT, y denegar lo que vemos en el log que había pasado. Claro, esto no evita que tenga que entender lo que quiero hacer, ni para que sirve cada una de las tablas, pero después de leer el HOWTO de Rusty, esta técnica me ha ayudado mucho. Espero que sirva a alguien! -- Christoph Simon [EMAIL PROTECTED] --- ^X^C q quit :q ^C end x exit ZZ ^D ? help shit .