On Tue, 13 Mar 2001 14:20:03 +0000 (GMT) Carles Pina i Estany <[EMAIL PROTECTED]> wrote:
> 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...) Aqu� est� justamente la dificultad: La l�gica con que un paquete traviesa las tables y cadenas, no es tan intuitiva como puede parecer leyendo el HOWTO. No me he pensado detalladamente lo quer�as hacer, as� que tampoco s� a que cadenas del nat te refieres. Pero si instalas en el kernel la tabla mangle y le das un default policy de drop (como yo lo he hecho), tendr�s que dejar paso tambi�n para esta. La default policy al arrancar, sin decir nada, es ACCEPT. Esto hace sentido porque la m�quina no queda instantaneamente aislada, pero es lo mas peligroso que existe. > 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... Al final creo que es un poco cuesti�n de gustos si empiezas denegando y permites lo que quieras, o si empiezas permitiendo y deniegas lo que necesites. El camino para llegar ah� es diferente. Tambi�n hay una diferencia entre DROP y REJECT. DROP simplemente descarta el paquete y no pierde mas tiempo con �l. El REJECT devuelve un paquete de error, as� que el programa del usuario puede dar un mensaje mas significativo. Como yo empiezo con DROP, coloco reglas de REJECT (talvez con tcp-reset) para aquellos programas que dificilmente pueden ser usados malificamente y qye necesitan un feedback mas explicativo. El problemas es que si rapidamente mandas muchos paquetes a una regla de REJECT estar�s automaticamente en la situaci�n de un DoS (Denial of Service), porque sobrecarga la red y los paquetes legales no tendr�n acceso. El DROP simplemente no responde y los roteadores modernos (incluyendo hasta el Linux mismo) bloquean la ruta mucho antes, si ven que siempre falla la conexi�n, asumiendo que el host remoto ni existe. Esto es la defensa contra un ataque as�. Lo puedes probar en tu red: Haz una conexi�n a una m�quina, entonces sacas el cable y lo reintentas varias veces. Llegar�s al punto que te dice `no route to host'. Ah, si tu superior es mas listo, le puedes mirar un poco los dedos: Primero usa el -L para ver las reglas duplicadas o redundantes, y despu�s usa las diferentes opciones de nmap desde la red interna y la externa para ver lo que est� abierto. Y finalmente puedes tentar lan�ar algunos ataques DoS (uno est�pido es ping -f) para ver si consiguen bloquear la m�quina. Y por �ltimo: Si comienzas con DROP y haces reglas muy espec�ficas, creo que no tendr�s que preocuparte del spoofing o egress. -- Christoph Simon [EMAIL PROTECTED] --- ^X^C q quit :q ^C end x exit ZZ ^D ? help shit .
