Re: Filtrando mediante IPtables
On Sun, 9 Dec 2001 08:27:03 -0800 (PST)
Deb Ma Il <debmail10@yahoo.com> wrote:
> _Hola!
>
> He montado para una asociacion de mi universidad un
> servidor (acceso mediante SSH, con HTTP, SMTP y POP3,
> de momento) en Debian. Para protegerlo lo maximo
> posible le he instalado el IPtables con el siguiente
> filtrado:
>
> ---CUT---
>
No consigo entender completamente la lógica que dicta el orden de los
comandos.
Aqui estamos en POST-ROUTING, lo último que pasa en el procesamiento
de los packets:
> iptables -t nat -A POSTROUTING -o lo -j SNAT --to-source MI_IP
Hasta aqui TODOS van a poder salir a la Internet enmasquerado con tu
IP... Al menos que insertas alguna regla al principio o en otra
cadena, todos se alegrarán de poder usar el gnutella o morpheus...
Continuamos en la tabla filter, en su cadena FORWARD.
> iptables -A FORWARD -p tcp ! --syn -m state --state NEW \
> -j LOG --log-prefix "New not syn:"
Estás usando -A (append) en todos los demás. Si no me engaño, vas a
escribir este mensaje para TODOS los packets; como esto es un
firewall, preasumo que tienes poco tráfico que origina en él mismo. Si
tienes mucho tráfico de pasada, imagino que te vas a hinchar el
/var/log/kern.log
> iptables -A FORWARD -p tcp ! --syn -m state --state NEW -j DROP
No consigo ver el objetivo de esto. ¡Estás descartando todos los
packets que no sean el primero! ¿Estás segura que esto te funciona?
[*]
> iptables -A FORWARD -i eth0 -j ACCEPT
Esta regla va a acceptar todos los PRIMEROS packets que vienen de
eth0 (supongo que la tarjeta para la red interna); como ya descartaste
los packets que vendrán a continuación, no llegarán a ser evaluados
por esta regla. Recuerda que nat-prerouting viene antes.
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Esta es la regla que deberias haber puesto antes. Si no me equivoco,
todos los packets que son NEW no son ESTABLISHED o RELATED y vice
versa (con alguna excepción por ejemplo con el FTP). Como descartaste
todos los que no sean NEW, nunca habrá packet que va a llegar a esta
regla.
> iptables -A FORWARD -m limit --limit 3/minute --limit-burst 3 \
-j LOG --log-level DEBUG --log-prefix "IPT FORWARD packet died: "
Limitar el log es buena idea, sólo que llega tarde. El target LOG ya
lo ha encontrado antes, y los que no sean NEW ya los descartaste.
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> iptables -P FORWARD DROP
> iptables -N icmp_packets
> iptables -N tcp_packets
> iptables -N udpincoming_packets
> iptables -N allowed
> iptables -A allowed -p TCP --syn -j ACCEPT
Esto esencialmente es lo mismo que NEW (creo)
> iptables -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
Esto ya lo comprobaste para la cadena FORWARD de la table
filter. ¿Porque no lo definista antes y saltas a "allowed" ya ahi?
> iptables -A allowed -p TCP -j DROP
Creo que no es posible que llegues a esta regla. Todos los que sean
SYN (NEW) plus todos los que sean ESTABLISHED,RELATED (!NEW), son 100%
de los packets. ¿En que caso entonces puede tocar esta?
Toda esta tabla hace esencialmente lo mismo que un -j ACCEPT.
> iptables -A icmp_packets -p ICMP -s 0/0 --icmp-type 0 -j ACCEPT
> iptables -A icmp_packets -p ICMP -s 0/0 --icmp-type 3 -j ACCEPT
> iptables -A icmp_packets -p ICMP -s 0/0 --icmp-type 5 -j ACCEPT
> iptables -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT
Creo que deberias permitir todos los tipos de ICMP; hay algunos
mensajes mas o menos esotéricas (por ejemplo los que pueden ser
generados en un ruta multipath cuando una línea cae). Si no quieres
responder a los pings, puedes prohibir ellos explicitamente (o
permitirlos sólo desde algún IP conocido).
> iptables -A tcp_packets -p TCP -s IP_PERMITIDA --dport 22 -j allowed
> iptables -A tcp_packets -p TCP -s OTRA_IP_PERMITIDA --dport 22 -j allowed
Aqui puede ser conveniente especificar también la interfaz de entrada
para dificultar el IP spoofing.
> iptables -A tcp_packets -p TCP -s X.Y.0.0/16 --dport 25 -j allowed
OK. Sólo los de la univseridad pueden mandarte un mensaje. Aunque
dependerá donde llamas a esta tabla.
> iptables -A tcp_packets -p TCP -s 0/0 --dport 80 -j allowed
> iptables -A tcp_packets -p TCP -s 0/0 --dport 110 -j allowed
> iptables -A udpincoming_packets -p UDP -s 0/0 --source-port 53 -j ACCEPT
> iptables -A udpincoming_packets -p UDP -s 0/0 --source-port 2074 -j ACCEPT
Si tienes un DNS corriendo, también necesitarás el 53 en tcp. No
conozco el 2074.
> iptables -t nat -A PREROUTING -i eth0 -s 192.168.0.0/16 -j DROP
> iptables -t nat -A PREROUTING -i eth0 -s 10.0.0.0/8 -j DROP
> iptables -t nat -A PREROUTING -i eth0 -s 172.16.0.0/12 -j DROP
Antes has escrito:
iptables -A FORWARD -i eth0 -j ACCEPT
Con estas reglas invalidas la anterior, porque la cadena PREROUTING es
lo primero que se toca (DROP) y la cadena FORWARD de la tabla filter
ni va a ver este packet. Aqui estoy asumiendo otra vez que eth0 sea la
interface interna. Hm. Será que eth0 es la externa? Si es la externa
la regla anterior permititía el forward de cualquier cosa a la red
interna. No te estoy siguiendo.
[...]
> ---CUT---
>
> Notas:
> MI_IP es la IP del servidor.
> X.Y.0.0/16 esta para que desde cualquier ordenador de
> la universidad se puedan enviar mails mediante el SMTP
> de mi servidor.
> IP_PERMITIDA es la IP del ordenador desde el que
> quiero que se pueda acceder mediante SSH.
Se te escapó decir que es eth0.
> Las cadenas estas os sonaran pq me las he copiado del
> IPtables HOWTO, adaptandolas a mis necesidades.
Pues no me suenan, y mi firewall es bien diferente. ¿Este te funciona?
> _Que os parece este filtrado? Parece estar bastante
> bien, _no? Se lo he ense_ado a un par de amigos que
> dominan el tema minimamente y me han dicho que no
> parece tener ningun fallo descomunal...
Bueno, la última palabra la tiene la práctica. Si funciona lo que debe y
si no funciona lo que no debe, el filtrado es perfecto.
> El "problema" es el que el servidor no se deja ni
> pingear ni scannear (un scanner de puertos desde fuera
> me devuelve que no hay ninguno abierto). _Esto es
> seguridad o *paranoia*? O:-)
No. Esto es un error. Ya se que con los iptables se ha puesto de moda
filtrar los pings. Primero no te ayuda, porque entonces usarán el
traceroute (hay diferentes versiones, algunos usan UDP), y segundo
estás violando los estándars RFC. Por otra parte, si quieres cojer tu
correo, no se como lo vas a hacer si el puerto 110 está filtrado (si
todos están filtrados, también el 110, ¿verdad?) Y lo mismo con el
puerto 80, que no te va a incrementar mucho el contador de visitas en
tu página web. He marcado un comentario arriba con [*], porque creo
que es la explicación porque el scanner de puertos no encuentra nada.
> Bueno, nada mas :-) Es mi primer msj a la lista asi
> que sirva de presentacion :-) Si me pudierais echar
> una mano y decirme que os parece el filtrado os
> estaria muy agradecida :-)
HTH
--
Christoph Simon
ciccio@kiosknet.com.br
---
^X^C
q
quit
:q
^C
end
x
exit
ZZ
^D
?
help
.
Reply to: