OT iptables
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
datageo@terra.com.br
---
^X^C
q
quit
:q
^C
end
x
exit
ZZ
^D
?
help
shit
.
Reply to: