hola
s�, fu� yo :-) No s� si hubo alguien m�s Ahora ya me funciona, aunque tu "t�cnica" la veo muy �til. El problema principal mio era como decirle ciertas cosas (FORWARD a 3 redes i SNAT al resto...) El "truco" es ponerle, en la tabla NAT un -j ACCEPT de lo que queremos que no haga nada (si pones un ACCEPT en el forward llega al nat, entonces me hacia el masquerading, con el ACCEPT no hace nada, y la �ltima regla del nat el snat y listo...) Sobre el tema de poner todo en REJECT y poner ACCEPT lo que se quiera, tengo el forward en REJECT, hago el FORWARD de lo que quiero, pero el INPUT est� en ACCEPT... con un par de reglas anti-spoofing y algo m�s... que creo que "mi superior" quit� porqu� decia que podrian traer problemas... en fin, �l sabr�, si fuese por mi estar�a claro... Gracias y hasta pronto On Tue, 13 Mar 2001, Christoph Simon wrote: > 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 > . > > > -- > Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null > ---- Carles Pina i Estany E-Mail: [EMAIL PROTECTED] || #Linux User: 87347 || Nick: Pinux URL: http://www.salleurl.edu/~is08139 Los ni�os no vienen de Paris, sino de Estar-dos Unidos
