[opensuse-es] Ataques de diccionario a cuentas pop3
Hola, Desde inicios de agosto estoy notando un incremento de intentos de acceso a cuentas pop3 inexistentes. Por los datos del registro parece algún ataque de esos de diccionario automatizado (usan logins de cuentas del sistema del tipo "webalizer, spam, oracle, admin, root", así como nombres de usuario de personas aleatorios "tomy, jones, jmartinez..."). Uso cyrus y sasl2. Los datos que veo son el host, la ip, el nombre de usuario y el error (badlogin plaintext, user not found: checkpass failed). Ya me había acostumbrado a los intentos de "relay" vía smtp que suelen venir de redes de China pero esto es nuevo y no sé si sería conveniente tomar alguna medida (bloqueo de ip, informar al administrador de la red :-?). De momento, los 3 equipos desde lo que se ha producido el intento de acceso a las cuentas pop3 están operativos y accesibles vía web (son las típicas páginas de inicio de configuración servidores web). ¿Qué se suele hacer en estos casos? ¿Merece la pena comunicarlo? ¿O es algo normal que va por rachas, como el spam...? :-? Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El día 26 de agosto de 2008 13:26, Camaleón
Hola,
Desde inicios de agosto estoy notando un incremento de intentos de acceso a cuentas pop3 inexistentes. Por los datos del registro parece algún ataque de esos de diccionario automatizado (usan logins de cuentas del sistema del tipo "webalizer, spam, oracle, admin, root", así como nombres de usuario de personas aleatorios "tomy, jones, jmartinez...").
Uso cyrus y sasl2. Los datos que veo son el host, la ip, el nombre de usuario y el error (badlogin plaintext, user not found: checkpass failed).
Yo implemente la solucion Postfix + openLDAP con cuentas virtuales agrega mucha seguridad ya que los usuarios del correo no tienen permiso de nada mas ... es mas ... nisiquiera existen en el sistema =D
Ya me había acostumbrado a los intentos de "relay" vía smtp que suelen venir de redes de China pero esto es nuevo y no sé si sería conveniente tomar alguna medida (bloqueo de ip, informar al administrador de la red :-?). De momento, los 3 equipos desde lo que se ha producido el intento de acceso a las cuentas pop3 están operativos y accesibles vía web (son las típicas páginas de inicio de configuración servidores web).
A mi me han estado atacando sobre el ssh ... :s varios servidores de china ...
¿Qué se suele hacer en estos casos? ¿Merece la pena comunicarlo? ¿O es algo normal que va por rachas, como el spam...? :-?
Siendo paranoico habria que poner una nueva regla en el SuSEfirewall2 ;) Me parece que es por rachas ... y falta la mas bonita del año ... NAVIDAD ahi si es cataratas de correos bausura, intentos de login por todos los puertos es la etapa en que todos descansan menos los sysadmins :( -- Ing. Alejandro Rodriguez || @LeX Usuario Linux # 379802 openSUSE 11.0 --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 26/08/08, Alex Rodriguez escribió:
Yo implemente la solucion Postfix + openLDAP con cuentas virtuales
agrega mucha seguridad ya que los usuarios del correo no tienen permiso de nada mas ... es mas ... nisiquiera existen en el sistema =D
Al usar "sasl2" también utilizo cuentas virtuales ;-).
Siendo paranoico habria que poner una nueva regla en el SuSEfirewall2 ;)
Pues sí. En ese servidor no tengo el cortafuegos activado. Probaré a configurar el del router a ver si puede encargarse de ésto. Si no, pues tendré que activar el susefirewall2 con el script que comenta Josep :-) Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón> En ese servidor no tengo el cortafuegos activado. Probaré a configurar Camaleón> el del router a ver si puede encargarse de ésto. Si no, pues tendré Camaleón> que activar el susefirewall2 con el script que comenta Josep :-) Si es un router con un cortafuegos normalito me parece que no. Se limitará al abierto-cerrado y a la redirección de IP.
El 27/08/08, J.M.Queralt escribió:
Si es un router con un cortafuegos normalito me parece que no. Se limitará al abierto-cerrado y a la redirección de IP.
Le he activado todas las opciones del apartado "DoS Defense" (syn-udp-icmp flood defense) junto con todos los bloqueos que tiene y he habilitado el registro de actividad para que vaya enviando todo al servidor, a ver qué caza. Si veo que no es efectivo, cortafuegos susero al canto :-) Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón> administrador de la red :-?). De momento, los 3 equipos desde lo que Camaleón> se ha producido el intento de acceso a las cuentas pop3 están Camaleón> operativos y accesibles vía web (son las típicas páginas de inicio de Camaleón> configuración servidores web). Camaleón> Camaleón> ¿Qué se suele hacer en estos casos? ¿Merece la pena comunicarlo? ¿O es Camaleón> algo normal que va por rachas, como el spam...? :-? En general yo acostumbro a pasar, aunque ensucien en exceso el "logwatch" ya que normalmente son ordenadores domésticos "zombies". Sin embargo cuando se trata de servidores infectados,SI que acostumbro a mandar un correo al administrador de la red de donde proviene el ataque con alguna parte "demostrativa" del "log" y la petición de que haga cesar la actividad maliciosa. Normalmente la respuesta es positiva ya que se trata de servidores de proveedores medios o grandes que no buscan ni quieren mala fama. Lo que si hago es bloquear las IP's atacantes para evitar los ataques ya que al tratarse de máquinas profesionales acostumbran a disponer de anchos de banda considerables que pueden afectar al rendimiento de la máquina propia. En los ataques al servidor SSH, en SuSE, utilizo un script que hace años puso Carlos E.R. en la lista y en el que puedes limitar los intentos de conexión, bloqueando el acceso durante X minutos a quienes los sobrepasen fallando la contraseña. El script se podría adaptar para hacer lo mismo en el puerto del POP3 en lugar del puerto del SSH
El día 26 de agosto de 2008 14:14, J.M.Queralt
En los ataques al servidor SSH, en SuSE, utilizo un script que hace años puso Carlos E.R. en la lista y en el que puedes limitar los intentos de conexión, bloqueando el acceso durante X minutos a quienes los sobrepasen fallando la contraseña.
Me interesa .... link ? o lo busco en google como script ssh de Carlos ? :p -- Ing. Alejandro Rodriguez || @LeX Usuario Linux # 379802 openSUSE 11.0 --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Alex> Alex> Me interesa .... link ? Alex> o lo busco en google como script ssh de Carlos ? :p No hace falta, tengo un archivo con mensajes interesantes. :-) La parte util era esa: ---------------- BEGIN ------------------------------------------------------- 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 :-? ---------------- END ------------------------------------------------------- Si quieres el mensaje completo (o todo el tema) se publicó el 22 de Enero del 2006 en el tema "Puerto ssh en SuSEFirewall2". Yo particularmente, y a la pregunta de si usar DROP o REJECT, me decanto por la primera solución, prefiero que el atacante se pare a esperar una respuesta a que pase a otra víctima inmediatamente al recibir un REJECT
2008/8/26 J.M.Queralt
---------------- END -------------------------------------------------------
Si quieres el mensaje completo (o todo el tema) se publicó el 22 de Enero del 2006 en el tema "Puerto ssh en SuSEFirewall2".
Yo particularmente, y a la pregunta de si usar DROP o REJECT, me decanto por la primera solución, prefiero que el atacante se pare a esperar una respuesta a que pase a otra víctima inmediatamente al recibir un REJECT
Excelente ! ya tengo tarea administrativa =D -- Ing. Alejandro Rodriguez || @LeX Usuario Linux # 379802 openSUSE 11.0 --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Alex> > Alex> Excelente ! Alex> ya tengo tarea administrativa =D Vale, pues añádele LoginGracetime MaxStartups MaxAuthTries implementados por el propio servidor SSH. :-)
2008/8/26 J.M.Queralt
Alex> Alex> Me interesa .... link ? Alex> o lo busco en google como script ssh de Carlos ? :p
No hace falta, tengo un archivo con mensajes interesantes. :-)
La parte util era esa:
---------------- BEGIN -------------------------------------------------------
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.
Tengo un servidor en opensuse 10.3, le puse ese scripts, por que vi, que en la pagina donde hablo Carlos de ellos, en el historial de suse. Pero reinicio susefirewall2_init o _setup, me bloqueo la terminal ya que estaba en modo remoto, tuve que apagar el servidor, y volver a prenderlo. Prueba ssh moncada. Me equivoco el password 9 veces y no me bloqueo, en lugar de hitcount 6 le puse 3. Y en lugar de 60 second le puse 600. Pero aun así no funciono. Por que, o que me falto. Gracias Cada que me conecto al servidor donde guarda el log.
true }
No se si debiera usar DROP en vez de REJECT :-?
---------------- END -------------------------------------------------------
Si quieres el mensaje completo (o todo el tema) se publicó el 22 de Enero del 2006 en el tema "Puerto ssh en SuSEFirewall2".
Yo particularmente, y a la pregunta de si usar DROP o REJECT, me decanto por la primera solución, prefiero que el atacante se pare a esperar una respuesta a que pase a otra víctima inmediatamente al recibir un REJECT
-- No olvides visitar mi pagina. http://www.i-moncads-s.co.cc http://www.marco-a-moncada.co.cc En esta vida, tu vida; solo te falta, para terminar ser alegre, y una sonrisa, no te cuesta nada. Solo tienes que tomar la mano que te saluda, y devolver una sonrisa. La persona, que te esta tendiendo la mano, puede ser que te este pidiendo ayuda, y tan solo la platica y la conversión se vuelve mas amena, con el principio de tu alegría demostrada atravez de tus dientes. Se alegre, y se feliz con quien camina a tu lado. Y mas con el que te tiende la mano pidiendo auxilio. Se feliz siempre y no mires a quien la das. Marco Aurelio Moncada Coello Calle Francisco Lozada Chavèz, numero 20, local 5. Atizapan de Zaragoza, Estado de México México, 044-55-1920-2224, 011-521-551920-2224 --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Marco> Pero reinicio susefirewall2_init o _setup, me bloqueo la terminal ya Marco> que estaba en modo remoto, tuve que apagar el servidor, y volver a Marco> prenderlo. Probablemente lo tengas mal instalado. Tienes que buscar el fichero etc/sysconfig/scripts/SuSEfirewall2-custom Dentro de SuSEfirewall2-custom tienes que buscar la función " fw_custom_before_antispoofing" que probablemente estará vacía Sustituyes el contenido de la función por el contenido del script, procurando no repetir ni el nombre de la función ni la llave "}" que la cierra Vigila también que con el cortar y pegar no te haya cambiado los finales de linea. .Reiniciando el cortafuegos ya debería funcionar.
El día 27 de agosto de 2008 14:54, J.M.Queralt
Marco> Pero reinicio susefirewall2_init o _setup, me bloqueo la terminal ya Marco> que estaba en modo remoto, tuve que apagar el servidor, y volver a Marco> prenderlo.
Probablemente lo tengas mal instalado.
Tienes que buscar el fichero etc/sysconfig/scripts/SuSEfirewall2-custom
Dentro de SuSEfirewall2-custom tienes que buscar la función " fw_custom_before_antispoofing" que probablemente estará vacía
Sustituyes el contenido de la función por el contenido del script, procurando no repetir ni el nombre de la función ni la llave "}" que la cierra
Vigila también que con el cortar y pegar no te haya cambiado los finales de linea.
.Reiniciando el cortafuegos ya debería funcionar.
Te mando el documento completo: # # ------------------------------------------------------------------------ fw_custom_before_antispoofing() { # these rules will be loaded before any anti spoofing rules will be # loaded. Effectively the only filter lists already effective are # 1) allow any traffic via the loopback interface, 2) allow DHCP stuff, # 3) allow SAMBA stuff [2 and 3 only if FW_SERVICE_... are set to "yes"] # You can use this hook to prevent logging of uninteresting broadcast # packets or to allow certain packet through the anti-spoofing mechanism. #example: allow incoming multicast packets for any routing protocol #iptables -A INPUT -j ACCEPT -d 224.0.0.0/24 #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 600 --hitcount 3 -j LOG --log-prefix 'SSH attack: ' iptables -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack --update --seconds 600 --hitcount 3 -j REJECT true } fw_custom_after_antispoofing() { # could also be named "before_port_splitting()" nada mas la parte importante -- No olvides visitar mi pagina. http://www.i-moncads-s.co.cc http://www.marco-a-moncada.co.cc En esta vida, tu vida; solo te falta, para terminar ser alegre, y una sonrisa, no te cuesta nada. Solo tienes que tomar la mano que te saluda, y devolver una sonrisa. La persona, que te esta tendiendo la mano, puede ser que te este pidiendo ayuda, y tan solo la platica y la conversión se vuelve mas amena, con el principio de tu alegría demostrada atravez de tus dientes. Se alegre, y se feliz con quien camina a tu lado. Y mas con el que te tiende la mano pidiendo auxilio. Se feliz siempre y no mires a quien la das. Marco Aurelio Moncada Coello Calle Francisco Lozada Chavèz, numero 20, local 5. Atizapan de Zaragoza, Estado de México México, 044-55-1920-2224, 011-521-551920-2224 --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-08-27 a las 21:54 +0200, J.M.Queralt escribió:
fw_custom_before_antispoofing" que probablemente estará vacía
Sustituyes el contenido de la función por el contenido del script, procurando no repetir ni el nombre de la función ni la llave "}" que la cierra
Vigila también que con el cortar y pegar no te haya cambiado los finales de linea.
.Reiniciando el cortafuegos ya debería funcionar.
También hay que activar las reglas custom. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIuEqHtTMYHG2NR9URAjXfAJ0VCSkVfbJIrNHl0Fus9IbkHGdBjgCfbKp5 OhZqAq4fEStVYeyA/iXrOw4= =XEIy -----END PGP SIGNATURE-----
El 26/08/08, J.M.Queralt escribió:
En general yo acostumbro a pasar, aunque ensucien en exceso el "logwatch" ya que normalmente son ordenadores domésticos "zombies".
Si sólo fuera envío de spam... pero intentos automatizados de acceso a cuentas pop3 no me hace ninguna gracia :-(
Sin embargo cuando se trata de servidores infectados,SI que acostumbro a mandar un correo al administrador de la red de donde proviene el ataque con alguna parte "demostrativa" del "log" y la petición de que haga cesar la actividad maliciosa.
Normalmente la respuesta es positiva ya que se trata de servidores de proveedores medios o grandes que no buscan ni quieren mala fama.
Sí, tienes razón. Les voy poner al corriente para que al menos lo sepan.
Lo que si hago es bloquear las IP's atacantes para evitar los ataques ya que al tratarse de máquinas profesionales acostumbran a disponer de anchos de banda considerables que pueden afectar al rendimiento de la máquina propia.
En los ataques al servidor SSH, en SuSE, utilizo un script que hace años puso Carlos E.R. en la lista y en el que puedes limitar los intentos de conexión, bloqueando el acceso durante X minutos a quienes los sobrepasen fallando la contraseña.
El script se podría adaptar para hacer lo mismo en el puerto del POP3 en lugar del puerto del SSH
Hum... supongo que cambiando el puerto del 22 al 110 serviría. Lo que no veo claro en esa regla es cómo detecta que el login es fallido. Tengo usuarios con ip fija que conectan cada poco tiempo y de continuo al servidor de correo para comprobar la cuenta ¿no les afectaría este script? :-? Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón> Si sólo fuera envío de spam... pero intentos automatizados de acceso a Camaleón> cuentas pop3 no me hace ninguna gracia :-( Nooooo ! los "zombies" como tales no solo envían "spam" los puedes poner a ejecutar cualquier tarea, por ejemplo lanzar scripts buscando sitios con vulnerabilidades conocidas o ataques DOS, lo que quieras. :-) Camaleón> Lo que no veo claro en esa regla es cómo detecta que el login es Camaleón> fallido. Tengo usuarios con ip fija que conectan cada poco tiempo y de Camaleón> continuo al servidor de correo para comprobar la cuenta ¿no les Camaleón> afectaría este script? :-? No, porque utiliza el LOG y cuenta los intentos marcados con el prefijo SSH attack: a la que ha contado cinco intentos y se produce el 6 activa el REJECT durante 60 segundos para la IP atacante. A mi, en el puerto 22 me funciona perfectamente. Así queda en el "logwatch" --------------------- SSHD Begin ------------------------ Illegal users from: 64.201.253.226 (64-201-253-226.TrueBroadband.paxio.net): 5 times alias/password: 1 time office/password: 1 time recruit/password: 1 time rfmngr/password: 1 time sales/password: 1 time **Unmatched Entries** Address 64.201.253.226 maps to 64-201-253-226.truebroadband.paxio.net, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT! : 5 time(s) ---------------------- SSHD End ------------------------- Para instalarlo solo hay que hacer un "cortar y pegar" del código dentro de la función " fw_custom_before_antispoofing" en "etc/sysconfig/scripts/SuSEfirewall2-custom"
El 27/08/08, J.M.Queralt escribió:
Nooooo ! los "zombies" como tales no solo envían "spam" los puedes poner a ejecutar cualquier tarea, por ejemplo lanzar scripts buscando sitios con vulnerabilidades conocidas o ataques DOS, lo que quieras. :-)
Por eso decía... si sólo fuera spam, vale. Pero intentos de acceso (aunque sea a cuentas de correo) eso ya no :-/ Les acabo de enviar un correo a los administradores directos de la red con copia a sus superiores >:-). 3 redes distintas: Alemania, EE.UU y Korea.
No, porque utiliza el LOG y cuenta los intentos marcados con el prefijo SSH attack: a la que ha contado cinco intentos y se produce el 6 activa el REJECT durante 60 segundos para la IP atacante.
Pero, hum... ¿cómo distingue entre una conexión con éxito de una fallida? :-? Porque si sólo activa un contador por cada conexión de la misma IP me van a estar llamando cada 5 minutos diciendo que el correo no les va :-P Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón> Camaleón> Pero, hum... ¿cómo distingue entre una conexión con éxito de una fallida? :-? Porque eso sale en los logs del sistema. Solo hay que leerlo. :-) En este caso concreto tendría que buscar las líneas en /var/log/maillog que indicaran una conexion fallida añadirle el "tag" correspondiente e iniciar el contador. La linea en maillog seria parecida a esta: Aug 27 13:59:58 ns1 ipop3d[10338]: pop3s SSL service failed from 83.42.57.XXX El script del que hablamos hace lo mismo en el log del var/log/secure Aug 2 22:52:54 ns1 sshd[15661]: Failed password for invalid user test from ::ffff:218.7.13.215 port 38512 ssh2 Camaleón> Porque si sólo activa un contador por cada conexión de la misma IP me Camaleón> van a estar llamando cada 5 minutos diciendo que el correo no les va Lo que te decía, en el SSH funciona. Además solo contará conexiones fallidas, no _todas_ las conexiones.
El 27/08/08, J.M.Queralt escribió:
Porque eso sale en los logs del sistema. Solo hay que leerlo. :-)
En este caso concreto tendría que buscar las líneas en /var/log/maillog que indicaran una conexion fallida añadirle el "tag" correspondiente e iniciar el contador.
La linea en maillog seria parecida a esta:
Aug 27 13:59:58 ns1 ipop3d[10338]: pop3s SSL service failed from 83.42.57.XXX
Josep, lo siento, debo estar en plan "ceporro". No lo pillo O:-). Supongamos que pongo: *** # Cambio el puerto al 110 y el nombre de la regla. Inicia el filtro iptables -A INPUT -p tcp --syn --dport 110 -m recent --name pop3attack --set # Cambio el puerto al 110, el nombre de la regla y el nombre de la marca. Se define el contador # a 6 (¿limite de seis conexiones?) y se define el intervalo de tiempo a 60 segundos. Se registra # en /var/log/firewall iptables -A INPUT -p tcp --dport 110 --syn -m recent --name pop3attack --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'POP3 attack: ' # Cambio el puerto al 110, el nombre de la regla y el nombre de la marca. Si se han intentado # seis conexiones dentro de esos 60 segundos, se rechazan las siguientes iptables -A INPUT -p tcp --dport 110 --syn -m recent --name pop3attack --update --seconds 60 --hitcount 6 -j REJECT *** ¿Cómo sabe que esas conexiones son resultan en éxito o son erróneas? :-? Si se hacen 7 conexiones correctas vía pop3 dentro de esos 60 segundos ¿no bloquea la ip?
El script del que hablamos hace lo mismo en el log del var/log/secure
Aug 2 22:52:54 ns1 sshd[15661]: Failed password for invalid user test from ::ffff:218.7.13.215 port 38512 ssh2
Hum...
Lo que te decía, en el SSH funciona. Además solo contará conexiones fallidas, no _todas_ las conexiones.
Lo que no entiendo es cómo detecta esa regla del ipfilter que es una conexión "fallida" o que ha tenido "éxito". ... (¬_¬ leyendo información sobre ipfilter, syn flood, etc...) http://en.wikipedia.org/wiki/SYN_flood Ahhh... ya, por el --syn. Grosso modo, al especificar el "tcp --syn" estás buscando una conexión "no completada" o "no finalizada" y descartando "las válidas" o "finalizadas". *** TCP SYN attack: A sender transmits a volume of connections that cannot be completed. This causes the connection queues to fill up, thereby denying service to legitimate TCP users. *** O.k., aclarado. En ese caso, es posible que me sirva la protección del router :-). De momento no ha registrado ningún intento de acceso, lo voy a dejar registrando durante algún tiempo... Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón> Camaleón> Josep, lo siento, debo estar en plan "ceporro". No lo pillo O:-). No es culpa tuya, es del ser antisocial y resentido con toda la humanidad que inventó las IPtables. Con lo cómodo que hubiera sido si hubiera hecho algo entendible por un simple mortal como nosotros. Camaleón> iptables -A INPUT -p tcp --dport 110 --syn -m recent --name pop3attack Camaleón> --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'POP3 attack: ' El truco está ahí arriba. "LOG" se refiere a un "modulo de objetivos" (target module) extendido que hace referencia, en resumen, al fichero /var/log/messages salvo que en el fichero de configuración de syslog se especifique otra cosa y log-prefix es quien escribe en message el "tag" La otra parte del truco esta en "recent" que crea una lista de IPs para hacer la comparación Camaleón> Camaleón> Ahhh... ya, por el --syn. Grosso modo, al especificar el "tcp --syn" Camaleón> estás buscando una conexión "no completada" o "no finalizada" y Camaleón> descartando "las válidas" o "finalizadas". Sip, esta es la tercera parte del truco
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-08-27 a las 23:17 +0200, J.M.Queralt escribió:
Camaleón> iptables -A INPUT -p tcp --dport 110 --syn -m recent --name pop3attack Camaleón> --update --seconds 60 --hitcount 6 -j LOG --log-prefix 'POP3 attack: '
El truco está ahí arriba.
"LOG" se refiere a un "modulo de objetivos" (target module) extendido que hace referencia, en resumen, al fichero /var/log/messages salvo que en el fichero de configuración de syslog se especifique otra cosa y log-prefix es quien escribe en message el "tag"
¿Mande? Que yo sepa eso es sólo para definir que mensaje debe escribir la regla en el syslog cuando salte y rechace una conexión. No anda mirando en el log a ver si el sshd ha aceptado o rechazado la conexión. Son tres intentos por minuto, independientemente de si fallan o no: eso es lo que siempre he entendido.
La otra parte del truco esta en "recent" que crea una lista de IPs para hacer la comparación
Camaleón> Camaleón> Ahhh... ya, por el --syn. Grosso modo, al especificar el "tcp --syn" Camaleón> estás buscando una conexión "no completada" o "no finalizada" y Camaleón> descartando "las válidas" o "finalizadas".
Sip, esta es la tercera parte del truco
Eso si, pero la conexión al servidor ssh o pop3 ya se ha hecho, es completa a efecto de paquetes. Se hace la conexión completada y entonces se inicia un dialogo de autentificación, que es el que falla (a nivel de aplicación). - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIuE1/tTMYHG2NR9URAoSwAJ4mWp+moFs1ncxDWN4Z3UfMcBQo0gCfV+2a 6QbKseeHBqjdSHa05c1EnUU= =9UCX -----END PGP SIGNATURE-----
El Miércoles, 27 de Agosto de 2008, Camaleón escribió:
*** TCP SYN attack: A sender transmits a volume of connections that cannot be completed. This causes the connection queues to fill up, thereby denying service to legitimate TCP users. ***
O.k., aclarado. En ese caso, es posible que me sirva la protección del router :-). De momento no ha registrado ningún intento de acceso, lo voy a dejar registrando durante algún tiempo...
Saludos,
* Utiliza Denyhosts o programa similar hay un par de ellos, esta pensado para esto sobre ssh principalmente, pero puedes bloquear diversos servicios o ALL, utiliza tcpwrappers, es decir podras bloquear discriminatoriamente servicios que lo soporten o optar por ALL (todos). * En cualquier caso tienes el router en multipuesto, asi que las conexines traspasaran el router hasta que la maquina que ejecuta denyhosts la rechace, es decir habra trafico.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-08-27 a las 10:46 +0200, Camaleón escribió:
Pero, hum... ¿cómo distingue entre una conexión con éxito de una fallida? :-?
Creo que no se distingue. Por cierto, ese "script" viene instalado en la 10.3 en la parte "fija", no en la custom. Es la regla "FW_SERVICES_ACCEPT_EXT", y el comentario dice: # Allow max three ssh connects per minute from the same IP address: # "0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Porque si sólo activa un contador por cada conexión de la misma IP me van a estar llamando cada 5 minutos diciendo que el correo no les va :-P
Que vayan a por ajo y agua :-P ¿Quien les manda consultar la cuenta 3 veces en un minuto? :-P Tienes remedios. Puedes aumentar el numero de intentos. O, si tus usuarios son internos o usan IPs fijas o de rangos conocidos, los pones en una regla FW_TRUSTED_NETS que tiene precedencia sobre la anterior. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIuEwftTMYHG2NR9URAg5xAJ9YtOQiuUgUbNMiGEhoAzy/JnqPDACghV4G /YYnhJyKjyRZ45KLrAtgqUY= =V9BU -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-08-26 a las 22:14 +0200, J.M.Queralt escribió:
En los ataques al servidor SSH, en SuSE, utilizo un script que hace años puso Carlos E.R. en la lista y en el que puedes limitar los intentos de conexión, bloqueando el acceso durante X minutos a quienes los sobrepasen fallando la contraseña.
Ah, lo puse yo, pero el script no es mio. Viene de un correo en la lista de seguridad. Además, en la suse 10.3 y siguientes no es necesario, porque el cortafuegos ya lo incorpora: FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh" Ojo: para que funcione, el puerto no debe estar abierto/cerrado en ninguna otra regla del mismo.
El script se podría adaptar para hacer lo mismo en el puerto del POP3 en lugar del puerto del SSH
Claro, por supuesto. Y en la linea de arriba, también, cambiando el numero de puerto y el nombre. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIuEoktTMYHG2NR9URAu6mAJ99iGC49dgNe2ibePqfcFCK9mvEswCZAdCQ QMvI1mivmVDkTffmraL6EUU= =Ob5M -----END PGP SIGNATURE-----
Camaleón escribió:
no sé si sería conveniente tomar alguna medida
Claro, tienes que tomar medidas. (bloqueo de ip, No, eso no funciona. informar al
administrador de la red :-?
Intentalo, nada pierdes.. . De momento, los 3 equipos desde lo que
se ha producido el intento de acceso a las cuentas pop3 están operativos y accesibles vía web (son las típicas páginas de inicio de configuración servidores web).
primero no uses pop3, solo IMAP, segundo preocupate de que los passwords de los usuarios sean de calidad, no palabras del diccionario.. Este tipo de "ataque" no es nuevo y es un problema intrinseco de casi cualquier servicio de internet. -- "A computer is like an Old Testament god, with a lot of rules and no mercy. " Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
El 27/08/08, Cristian Rodríguez escribió:
primero no uses pop3, solo IMAP,
No veo ninguna diferencia entre el uso de estos dos protocolos a efectos de intentos de ataque de diccionario o de fuerza bruta :-?. Tengo habilitados pop3 / pop3s / imap e imaps.
segundo preocupate de que los passwords de los usuarios sean de calidad, no palabras del diccionario..
Vale :-) Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-08-27 a las 13:26 +0200, Camaleón escribió:
primero no uses pop3, solo IMAP,
No veo ninguna diferencia entre el uso de estos dos protocolos a efectos de intentos de ataque de diccionario o de fuerza bruta :-?.
Lo mismo pienso yo.
Tengo habilitados pop3 / pop3s / imap e imaps.
Podrías desactivar pop3/imap - que vienen desactivados en suse en algunos de los daemons. Creo que no vienen ni compilados. Pero eso no va a evitar el problema en absoluto. El ssh es un protocolo seguro, pero es igualmente victima de ataques de diccionario: la defensa más eficaz consiste precisamente en desactivar la entrada por login/pass y exigir ciertificados a ambos lados. ¿Te imaginas el cacao de los usuarios si les dices que tienen que implementar certificados en SU maquina? >:-)
segundo preocupate de que los passwords de los usuarios sean de calidad, no palabras del diccionario..
Vale :-)
Eso es lo único que puedes hacer - aparte de lo del módulo recent. Hay servidores "serios" (teleline.es) que rechazan las conexiones rápidas seguidas, aunque creo que lo hacen para impedir la sobrecarga por consultar el correo varias veces por minuto. Puede que haya programas de analisis de seguridad que examinen las IPs habituales de acceso a las cuentas, y hagan saltar alarmas si el patrón cambia. El GMAIL lo hace: no salta alarmas, o no las he visto, pero sí registra las conexiones y las puedes ver tu misma. Otra medida de seguridad es el cambio de passwords ciclicamente, y exigir passwords seguras, y tener programas que lo comprueben. Quizás se pueda usar el "john". Y considera el exigir passwords distintas en el servidor SMTP. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIuFBmtTMYHG2NR9URAuXCAJoDBp/WyIC/ozKwYnh7zO2UYPBpqQCcDsgo G/CRRxeRCaGCFWiwUHias2k= =o69/ -----END PGP SIGNATURE-----
Cristian> (bloqueo de ip, Cristian> Cristian> No, eso no funciona. El bloqueo de IP funciona, otra cosa diferente es que sea util o no lo sea. Si el ataque proviene de "zombies" (ordenadores domésticos con IP dinámica) evidentemente carece de sentido bloquear las IPs. Sin embargo en este caso estamos hablando de servidores, en concreto parece ser que son 3, en los cuales si que es util bloquear la IP, ya que presumiblemente se trata de máquinas con un ancho de banda considerable que pueden hacer disminuir el rendimiento de la máquina atacada. Además son máquinas con una IP estática, las añades a IPtables y te olvidas de ellas de por vida. Cristian> primero no uses pop3, solo IMAP, segundo preocupate de que los passwords Cristian> de los usuarios sean de calidad, no palabras del diccionario.. Lo de no usar POP3 y solo usar IMAP me desconcierta. No veo ninguna razón de seguridad lógica para esa afirmación Estamos hablando de un servidor de correo con usuarios virtuales, es decir, que no son usuarios del sistema, por lo que el problema, sea en el puerto 110, en el 446 o en el 146, no es por el usuario (que cada cual aguante su vela si usa un password inseguro) ni tampoco es un problema de protocolo, se trata simplemente de un problema que puede resentir el rendimiento de la máquina atacada. Cosa distinta será si esa afirmación es producto de una fobia personal por el POP3. En ese caso debo manifestarte que yo tengo la contraria ya que odio profundamente el IMAP por la gran cantidad de recursos que gasta. :-.) Cristian> Este tipo de "ataque" no es nuevo y es un problema intrinseco de casi Cristian> cualquier servicio de internet. El ataque no es nuevo pero si que es extraño en un servicio de correo que supongo de tamaño pequeño. Es mucho más común el ataque al servidor SSH o al servidor FTP.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-08-27 a las 20:59 +0200, J.M.Queralt escribió:
Cristian> Este tipo de "ataque" no es nuevo y es un problema intrinseco de casi Cristian> cualquier servicio de internet.
El ataque no es nuevo pero si que es extraño en un servicio de correo que supongo de tamaño pequeño. Es mucho más común el ataque al servidor SSH o al servidor FTP.
Sirve para a continuación atacar el servidor smtp asociado teniendo el par login/pass correcto para enviar correo spam (o peor) en nombre de la victima. >:-/ Es un ataque *muy* serio. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIuE5otTMYHG2NR9URAlqNAJ9lFI1yriKWSO+ivvtQOpL3chD7PQCfZaqm QPK6dH9h0Ki2Uk/ZpAfTNy4= =n0GK -----END PGP SIGNATURE-----
participants (7)
-
Alex Rodriguez -
Camaleón -
Carlos E. R. -
Cristian Rodríguez -
J.M.Queralt -
jose maria -
Marco Aurelio Moncada Coello