On Sun, 9 Dec 2001 08:27:03 -0800 (PST)
Deb Ma Il <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
---
^X^C
q
quit
:q
^C
end
x
exit
ZZ
^D
?
help
.
