Hola! Disculpa Carlos, pero he estado buscando el mensaje al que te refieres y no encuentro nada, ¿podrías dar alguna indicación más?. Gracias y disculpa las molestias.

Creo que la parte util del mensaje era la que te "pego" a continuación: Ya, ya. Pero el bloqueo tambiÚn puede ser dinßmico. Yo estoy usando esto en "/etc/sysconfig/scripts/SuSEfirewall2-custom", que public¾ uno en la lista de seguridad: fw_custom_before_antispoofing() { #Cer 2051225 - de un correo en suse-security # Blocking ssh attacks iptables -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'SSH attack: ' iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --update --seconds 60 --hitcount 6 -j REJECT # This will block all further syns from an IP address starting on the # sixth port 22 connection within 60 seconds. It takes 60 seconds of # absolute quiet from that same ip address (or a reboot) to make the # block go away. Kills a LOT of brute force ssh attacks. I've also # used this both against web statistics spammers and email DOSers with # good results. true } No se si debiera usar DROP en vez de REJECT :-? Lo que hace es bloquear la IP a partir del sexto intento de conexi¾n al puerto 22; a partir de ese momento necesita un minuto de silencio desde esa IP antes de borrar el bloqueo. -- Salutacions - Saludos, Josep M. Queralt

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-08-18 a las 17:25 +0200, Jordi Espasa Clofent escribió:

...

No se si debiera usar DROP en vez de REJECT :-?

Pues según los manuales teóricos siempre es mejor DROP, ya que simplemente, no responde a nada. Por su parte REJECT no permite entrada, claro está, pero contesta con un "no puedes", por así decirlo. DROP se mantiene en silencio y ello se considera más seguro.

O al menos eso tengo entendido; sino que alguien nos corrija.

Así lo entiendo yo. La cuestión era si, en esa regla del cortafuegos, que es mejor usar. Se puede considerar que el otro lado ya sabe que existimos, puesto que intenta entrar con ssh varias veces: es cuando nos hemos dado cuenta que está probando varias veces seguidas (intentos contestados) cuando le rechazamos y le mandamos a paseo. Puede que reject sea lo adecuado en este caso. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFE5f64tTMYHG2NR9URAkdaAJ9i6Xy2lSS1E+TP11zEeUY8L//TaQCdHgKz TQMurTNkbV/6gMSlNe0y4gc= =TJZx -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-08-18 a las 14:49 -0400, Victor Hugo dos Santos escribió:

El 18/08/06, Carlos E. R. escribió:

...

Así lo entiendo yo. La cuestión era si, en esa regla del cortafuegos, que es mejor usar. Se puede considerar que el otro lado ya sabe que existimos, puesto que intenta entrar con ssh varias veces: es cuando nos hemos dado cuenta que está probando varias veces seguidas (intentos contestados) cuando le rechazamos y le mandamos a paseo. Puede que reject sea lo adecuado en este caso.

se utilizamos en la regla la opcion DROP.. los paquetes que envia el "atacante" no obtendran respuesta de entrega o error y el "atacante" intentara una vez.. y otra .. y otra hasta que se temine el TTL (o se aburra)... o tenga una opcion de "timeout" en el script

... Si, pero te falta fijarte en un detalle. Se trata de que el atacante ya sabe que estás ahí y que tienes un ssh escuchando. El cortafuegos le deja hacer seis intentos en un minuto - conexiones completadas, login password etc - y es en el séptimo intento cuando el módulo "recent" se da cuenta y le manda a freir monas. Usar drop en estas circunstancias es incluso contraproducente, porque tardará un tiempo en darse cuenta de que se le rechaza, y cuando vuelva a intentarlo el timeout de un minuto habrá concluido y le dejará conectar de nuevo otras seis veces. Aparte de eso, las diferencias, en este caso, entre drop y reject, son académicas: el atacante ya tiene confirmada la existencia del servidor. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFE6MmatTMYHG2NR9URAr23AKCTpnc2yxQ1h9Y4dD6baYyGdYSA3gCfXBmP 9NFwwyoJVsQWfUbkrqWgEKY= =SL+Q -----END PGP SIGNATURE-----

El Domingo, 20 de Agosto de 2006 22:44, Carlos E. R. escribió:

Si, pero te falta fijarte en un detalle. Se trata de que el atacante ya sabe que estás ahí y que tienes un ssh escuchando.

* El modulo iptables no es el encargado de la autentificacion, si no de banear la ip por tanto drop a las baneadas, reject puede conllevar dependiendo del numero de conexiones denegacion de servicio, hay otros metodos mas efectivos si lo que se quiere es "luchar".

El cortafuegos le deja hacer seis intentos en un minuto - conexiones completadas, login password etc - y es en el séptimo intento cuando el módulo "recent" se da cuenta y le manda a freir monas. Usar drop en estas circunstancias es incluso contraproducente, porque tardará un tiempo en darse cuenta de que se le rechaza,

* El robot ataca rangos de direcciones y no contestarle cuando esta baneado es la mejor idea.

y cuando vuelva a intentarlo el timeout de un minuto habrá concluido y le dejará conectar de nuevo otras seis veces.

* El timeout de un minuto es ridiculo, ademas en sshd_config hay como tres opciones configurables antes de que entre iptables a banear, que han de ir en consonancia.

Aparte de eso, las diferencias, en este caso, entre drop y reject, son académicas: el atacante ya tiene confirmada la existencia del servidor.

* En este caso en el que ya se han producido intentos de conexion si pero por norma mejor no contestar.