[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OT iptables



On Tue, 13 Mar 2001 14:20:03 +0000 (GMT)
Carles Pina i Estany <is08139@salleURL.edu> 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
datageo@terra.com.br
---
^X^C
q
quit
:q
^C
end
x
exit
ZZ
^D
?
help
shit
.



Reply to: