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
.
