he cerrado el puerto en el firewall y ahora ya puedo enviar local , lo que me preocupa fue esa hola de ataque que tuve y si abro el puerto en el firewall , me lo buelven a botar, el problema que tenia es que miraba con el comando netstat como 30 o 40 ip conectados al puerto 25 , y de pronto no podia enviar correos ni locales ... menos a fuera , me llego a generar 13450 correos al postmaster , que se puede hacer en estos casos? habra una forma de decirle al firewall de cuantas conexiones puede permitir al puerto 25 ... esto si que me preocupe , bueno tengo montado un servidor con la 9.3 (postfix+amavis+spamassassin+razor+dcc) parte del log de /var/log/mail cuando tuve los atentados Dec 11 20:08:52 ns1 postfix/smtpd[17442]: connect from smtp3.wanadoo.co.uk[193.252.22.156] Dec 11 20:08:52 ns1 postfix/smtpd[17742]: connect from outmail1.freedom2surf.net[194.106.33.237] Dec 11 20:08:53 ns1 postfix/smtpd[17156]: NOQUEUE: reject: RCPT from unknown[82.196.201.163]: 450 Client host rejected: canno t find your hostname, [82.196.201.163]; from=<> to= proto=SMTP helo= Dec 11 20:08:53 ns1 postfix/smtpd[17156]: disconnect from unknown[82.196.201.163] Dec 11 20:08:53 ns1 postfix/smtpd[17742]: warning: unknown smtpd restriction: "reject_unknow_recipient_domain" Dec 11 20:08:53 ns1 postfix/smtpd[17742]: NOQUEUE: reject: RCPT from outmail1.freedom2surf.net[194.106.33.237]: 451 Server co nfiguration error; from=<> to= proto=ESMTP helo= Dec 11 20:08:53 ns1 postfix/smtpd[17442]: warning: unknown smtpd restriction: "reject_unknow_recipient_domain" Dec 11 20:08:53 ns1 postfix/smtpd[17442]: NOQUEUE: reject: RCPT from smtp3.wanadoo.co.uk[193.252.22.156]: 451 Server configur ation error; from=<> to= proto=ESMTP helo= Dec 11 20:08:53 ns1 postfix/smtpd[17631]: connect from smnvesb.stratos.ca[209.128.59.28] Dec 11 20:08:53 ns1 postfix/smtpd[17156]: connect from host-75-50-220-24.midco.net[24.220.50.75] Dec 11 20:08:53 ns1 postfix/cleanup[17813]: AE26035802: message-id=<20061212020853.AE26035802@ns1.aglobal.org.ni> Dec 11 20:08:53 ns1 postfix/smtpd[17742]: disconnect from outmail1.freedom2surf.net[194.106.33.237] Dec 11 20:08:53 ns1 postfix/qmgr[16308]: AE26035802: from=, size=947, nrcpt=1 (queue active) Dec 11 20:08:53 ns1 postfix/local[17817]: AE26035802: to=, orig_to=<postmaster>, relay=local, delay=0 , status=sent (delivered to maildir) Dec 11 20:08:53 ns1 postfix/local[17817]: AE26035802: to=, orig_to=<postmaster>, relay=local, delay=0, s tatus=sent (delivered to maildir) Dec 11 20:08:53 ns1 postfix/qmgr[16308]: AE26035802: removed Dec 11 20:08:53 ns1 postfix/cleanup[17815]: C4C7335802: message-id=<20061212020853.C4C7335802@ns1.aglobal.org.ni> Dec 11 20:08:53 ns1 postfix/smtpd[17442]: disconnect from smtp3.wanadoo.co.uk[193.252.22.156] Dec 11 20:08:53 ns1 postfix/qmgr[16308]: C4C7335802: from=, size=934, nrcpt=1 (queue active) Dec 11 20:08:53 ns1 postfix/local[17814]: C4C7335802: to=, orig_to=<postmaster>, relay=local, delay=0 , status=sent (delivered to maildir) ---------- Forwarded message ---------- From: Carlos E. R. Date: 11-dic-2006 20:37 Subject: Re: [opensuse-es] me atacan el postfix To: OS-es -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-12-11 a las 18:15 -0600, gnu forever escribió:

hola lista , por aqui de nuevo , se extrañaran por lo de hylafax , no he disistido de montar ese servidor pues encontre que en relidad el modem me estaba dando problemas porque ni en winsock marca , bueno pues escribo porque me estan atacando el servidor de correo , todo el dia de hoy veo que el servidor manda como 40 mensajes por minuto al postmaster , con este tipo de mensajes

No lo tengo claro, pero por las dudas, primero para el servidor, o mejor, cierra el puerto en el firewall, y luego investiga. Mira en el log /var/log/mail, y ejecuta el comando "mailq" para ver que tienes en la cola. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFfhXqtTMYHG2NR9URAoDfAJ9ofPbichDe+5r09djxWkmGKRSk7QCeMJwx 3pbv1Z/ccrBcLxW6m9HfnWQ= =mkIw -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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 2006-12-11 a las 21:34 -0600, gnu forever escribió:

he cerrado el puerto en el firewall y ahora ya puedo enviar local , lo que me preocupa fue esa hola de ataque que tuve y si abro el puerto en el firewall , me lo buelven a botar, el problema que tenia es que miraba con el comando netstat como 30 o 40 ip conectados al puerto 25 , y de pronto no podia enviar correos ni locales ... menos a fuera , me llego a generar 13450 correos al postmaster , que se puede hacer en estos casos? habra una forma de decirle al firewall de cuantas conexiones puede permitir al puerto 25 ...

La cuestión era pararlo para estudiar con cuidado que es lo que estaba pasando, corregirlo, y entonces volverlo a abrir. Pueden ser correos legales, incluso, o simple spam, que te han "descubierto". Tienes que examinar con cuidado esos correos que estabas recibiendo a ver que es lo que dicen. Si quieres, me puedes mandar algunos como anexo en privado si tienen información personal, y así te digo mi opinión.

esto si que me preocupe , bueno tengo montado un servidor con la 9.3 (postfix+amavis+spamassassin+razor+dcc)

parte del log de /var/log/mail cuando tuve los atentados

Dec 11 20:08:52 ns1 postfix/smtpd[17442]: connect from smtp3.wanadoo.co.uk[193.252.22.156]

Dec 11 20:08:52 ns1 postfix/smtpd[17742]: connect from outmail1.freedom2surf.net[194.106.33.237]

Dec 11 20:08:53 ns1 postfix/smtpd[17156]: NOQUEUE: reject: RCPT from unknown[82.196.201.163]: 450 Client host rejected: cannot find your hostname, [82.196.201.163]; from=<> to= proto=SMTP helo=

Un rechazo correcto

Dec 11 20:08:53 ns1 postfix/smtpd[17156]: disconnect from unknown[82.196.201.163]

Dec 11 20:08:53 ns1 postfix/smtpd[17742]: warning: unknown smtpd restriction: "reject_unknow_recipient_domain"

Un error de configuración.

Dec 11 20:08:53 ns1 postfix/smtpd[17742]: NOQUEUE: reject: RCPT from outmail1.freedom2surf.net[194.106.33.237]: 451 Server configuration error; from=<> to= proto=ESMTP helo=

Un error de configuración genera un rechazo a un correo que parece destinado a tí. Luego entonces el error anterior no es un simple aviso, es importante. Cuando el from está vacío "<>" creo recordar que se trata de un correo de rechazo no rechazable, lo cual genera una situación peculiar.

Dec 11 20:08:53 ns1 postfix/smtpd[17442]: warning: unknown smtpd restriction: "reject_unknow_recipient_domain"

Dec 11 20:08:53 ns1 postfix/smtpd[17442]: NOQUEUE: reject: RCPT from smtp3.wanadoo.co.uk[193.252.22.156]: 451 Server configuration error; from=<> to= proto=ESMTP helo=

Lo mismo.

Dec 11 20:08:53 ns1 postfix/smtpd[17631]: connect from smnvesb.stratos.ca[209.128.59.28]

Dec 11 20:08:53 ns1 postfix/smtpd[17156]: connect from host-75-50-220-24.midco.net[24.220.50.75]

Dec 11 20:08:53 ns1 postfix/cleanup[17813]: AE26035802: message-id=<20061212020853.AE26035802@ns1.aglobal.org.ni>

Dec 11 20:08:53 ns1 postfix/smtpd[17742]: disconnect from outmail1.freedom2surf.net[194.106.33.237]

Dec 11 20:08:53 ns1 postfix/qmgr[16308]: AE26035802: from=, size=947, nrcpt=1 (queue active)

Dec 11 20:08:53 ns1 postfix/local[17817]: AE26035802: to=, orig_to=<postmaster>, relay=local, delay=0, status=sent (delivered to maildir)

Esto es un correo dirigido al postmaster que se redirige "soporte" por alguna regla tuya.

Dec 11 20:08:53 ns1 postfix/local[17817]: AE26035802: to=, orig_to=<postmaster>, relay=local, delay=0, status=sent (delivered to maildir)

Dec 11 20:08:53 ns1 postfix/qmgr[16308]: AE26035802: removed

Dec 11 20:08:53 ns1 postfix/cleanup[17815]: C4C7335802: message-id=<20061212020853.C4C7335802@ns1.aglobal.org.ni>

Dec 11 20:08:53 ns1 postfix/smtpd[17442]: disconnect from smtp3.wanadoo.co.uk[193.252.22.156]

Dec 11 20:08:53 ns1 postfix/qmgr[16308]: C4C7335802: from=, size=934, nrcpt=1 (queue active)

Dec 11 20:08:53 ns1 postfix/local[17814]: C4C7335802: to=, orig_to=<postmaster>, relay=local, delay=0, status=sent (delivered to maildir)

Puede ser spam o pueden ser rebotes legales a correos que tu enviaste, o que alguien que se hace pasar por tí ha enviado. por ejemplo, si un puñetero spammer usa tu nombre o el de tu organización como remite de sus millones de correos de spam, y de esos un porcentaje son rechazados, serán rechados a _tí_, que eres inocente. Esos correos irían precisamente al postmaster, y tienes que aguantarte, me temo, o sea, rezar para que el spamassassin los caze. Y ojito con esto, porque el amavis_new tiene una configuración estúpida que puede rechazar el spam y ¡tratar de devolverlo al remitente! - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFfow/tTMYHG2NR9URArHQAJwIsQDRihwGgfUWGwC20WZ2Kfk8eQCeP0Fo OQa4cFwn+G/aIkypWRytk7A= =55PY -----END PGP SIGNATURE-----

El 12/12/2006 18:01:50 gnu forever escribió: xserverlinux> señores abro el puerto en el susefirewall , y veo que se me pegan como xserverlinux> moscas al puerto 25 , les dejo un netstat , y es ahi cuando no puedo xserverlinux> enviar correos ni locales , menos afuera Como chapuza, de manera provisional, y mientras esperas que pase "la tormenta" lo que puedes hacer, si no tienes demasiados usuarios remotos es instalar y usar POP3s/SMTPs (puerto 465) y cerrar el puerto 25. -- Saludos, Josep M. Queralt --------------------------------------------------------------------- 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 12/12/2006 19:28:52 gnu forever escribió: xserverlinux> pero los servidores como yahoo , hotmail, netscape y otros , no xserverlinux> sabran como enviarme op escuchan en su defecto ese puerto? , nunca xserverlinux> habia escuchado del puerto 465!! es nuevo para mi Es el puerto SMTP para conexiones seguras (SMTPs). EL puero para POP3 seguro (POP3s) es el 995. Del IMAPs no me acuerdo. :-) xserverlinux> he configurado postfix con tls , creo que es lo mismo que ssl ... El SSL es un poco más antiguo. En realidad el TSL lo sustituye. Si quieres aclararte con los conceptos quizá esta página te venga bien: http://www.cored.df.gob.mx/cgi-bin/templatecored.pl?.State=documentacion&seleccion=/documentacion/c_redesb/postfix.html -- Saludos, Josep M. Queralt

El 13/12/06, Carlos E. R. escribió:

El problema que tiene es un backsatter o como se llame gigantesco.

Lo que me extraña es que la cantidad de correos que recibe no le permitan el uso normal de Postfix, es decir, que los usuarios locales tengan problemas para enviar correos debido a la saturación del servidor. Me gustaría saber cuántos correos tiene en cola (mailq), porque salvo que sea una salvajada (> 5.000) Postfix no debería tener problemas en un equipo medio (puede tardar más tiempo en enviar los mensajes pero no bloquearse). P.S. Yo también estoy notando un incremento de los correos de spam, de recibir en una cuenta 500 al día han pasado a ser 1.500... 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 13/12/06, Carlos E. R. escribió:

No, eso lo he oído otras veces, ocurre. Es porque el número de procesos atendiendo al smtpd es limitado (lo puedes ilimitar, allá tú), y sobre todo si se queda pensando si acepta el correo o no.

Pero es raro. Puede aumentarlo (creo que la variable era "concurrent_process_limit" o similar), al menos para verificar si ampliando el número de procesos concurrentes mejora un poco la saturación.

No es por eso.

Pues si la cantidad de mensajes que tiene que procesar no afecta ¿qué es lo que lo deja frito? 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 13/12/2006 14:02:25 Camaleón escribió: noelamac> noelamac> Pues si la cantidad de mensajes que tiene que procesar no afecta ¿qué noelamac> es lo que lo deja frito? Es que el problema se produce en la entrada de la red. Son miles de máquinas intentando dejar un mensaje en el puerto 25 al mismo tiempo, es decir conectando a la vez, y hay que contestar todas las peticiones, bien sea aceptando o rechazando las peticiones. Es la versión SMTP del ataque DoS. En realidad no se queda frito, simplemente se satura, no tiene tiempo material de atender todas las peticiones. -- Saludos, Josep M. Queralt

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-12-13 a las 16:33 +0100, Camaleón escribió:

El 13/12/06, Josep M. Queralt escribió:

...

Es que el problema se produce en la entrada de la red. Son miles de máquinas intentando dejar un mensaje en el puerto 25 al mismo tiempo, es decir conectando a la vez, y hay que contestar todas las peticiones, bien sea aceptando o rechazando las peticiones.

¿Y no podría configurarse para dar prioridad a los correos de clientes autentificados, por ejemplo? Una especie de QoS para servidores de correo.

No, porque para saber que es un cliente autentificado primero ha de conectarse, autentificarse, y ocupar uno de los 2 (o 5, o 20, o los que hayas puesto) atendedores que están atendiendo las conexiones de entrada. Repito, el postfix se configura para atender simultaneamente un número determinado de peticiones en el puerto smtp (o cualquier otro que quieras). No atiende a todos al mismo tiempo para no saturarse, por eso se configura un límite, el que sea. Con ese límite, el programa no tiene problemas de saturación interna ni abuso de cpu ni nada. El resto, que espere. Lo que se hace es atender a los clientes en un puerto distinto del normal - - sea el de smtps, sea el de submission, sea otro que te inventes. Como en ese puerto distinto no hay barullo, no hay problema.

Al resto, cuando llegue al límite de peticiones, les podría responder con un código de "try later", vamos, que lo intente más tarde. Es que no veo control alguno entonces en el servidor de correo y por tanto es extremadamente vulnerable ¿no?

Sí tiene control, lo que pasa es que no te das cuenta de como funciona. Piensalo, yo me voy con morfeo :-P - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFgB/YtTMYHG2NR9URAn4fAKCUvWpnatxV0LZU7o/teekUTOpefgCfc42s lYJJ6MIMhAXNpFqIBQc51kg= =iHFX -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-12-13 a las 16:56 +0100, Camaleón escribió:

El 13/12/06, Carlos E. R. escribió:

...

No, porque para saber que es un cliente autentificado primero ha de conectarse, autentificarse, y ocupar uno de los 2 (o 5, o 20, o los que hayas puesto) atendedores que están atendiendo las conexiones de entrada.

Vale, ya quedamos en que lo que suele hacerse en estos casos (como lo tenía Gmail) es establecer la prioridad de los clientes por medio de un servicio especial y de uso restringido (utilizando seguridad en smtp). El servicio vulnerable queda para "el resto" que conectan al puerto 25.

No se puede hacer de otra forma; no puedes saber que son clientes prioritarios antes de que entren, salvo que usen una puerta distinta. Es como en una tienda: el público entra por recepción, y los amigos del jefe por la de atrás.

La única solución que le veo es tener más servidores para atender las peticiones de forma adecuada, pero no siempre es posible esa configuración...

Por más que pongas, te los pillan. Internet es más grande.

...

Sí tiene control, lo que pasa es que no te das cuenta de como funciona.

Control tendrá, pero el que Postfix quiere no el que yo quiero :-)

Veamos, a ver si lo consigo explicar. En el /etc/postfix/master.cf hay una linea como esta: # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) smtp inet n - n - 5 smtpd # Max procs: the maximum number of processes that may execute this # service simultaneously. Default is to use a globally configurable # limit (the default_process_limit configuration parameter in main.cf). # Specify 0 for no process count limit. Esto se traduce en que en el puerto smtp de internet (cualquier interface) tendré, como máximo, 5 daemons smtpd atendiendo lo que entre, y por donde entre, en el puerto 25. Y ojo, que según que configuraciones, el filtro de contenidos (amavis) también entra por el mismo puerto y colapsa por el tiempo que tarda. Si yo pongo: smtps inet n - n - 5 smtpd Entonces tendré otros 5 daemons smtpd atendiendo al puerto smtps ('s', es otro puerto) de internet. Puedo poner cualquier puerto: submission inet n - n 5 - smtpd o con diferentes reglas: submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes O incluso puedo diferenciar por interface: ipexterna:smtp inet n - n - 25 smtpd ipinterna:smtp inet n - n - 5 smtpd ¿Ves el problema y la solución? Los correos de la red interna comparten el mismo puerto que los de internet, y si hay 200 intentos de conexión y el límite es 20, pues no entra nadie más de nunguna parte. Si tienes dos interfaces, la solución es simple: diferencialas en el postfix, puesto que puedes. Si la interfaz es la misma, entonces diferencia por número de puerto, que es lo que queda. Puedes ajustar mucho. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFgDNHtTMYHG2NR9URAsWEAJsGam4xPfaooDzaaWb0B6tZtrXPxQCcCyZE 8zsjQqI+6QqypIeEtO2FP8w= =XnYA -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-12-13 a las 18:23 +0100, Camaleón escribió:

El 13/12/06, Carlos E. R. escribió:

...

No se puede hacer de otra forma; no puedes saber que son clientes prioritarios antes de que entren, salvo que usen una puerta distinta. Es como en una tienda: el público entra por recepción, y los amigos del jefe por la de atrás.

Bueno, en la vida real se distingue entre las personas con llave y las que llaman a la puerta: misma entrada, distinto tratamiento :-D

...

Por más que pongas, te los pillan. Internet es más grande.

Pues de alguna manera lo harán los grandes isp tipo Google, Telefónica, Yahoo... lo suplen con granjas de equipos, digo yo...

¡Claro, pero eso es otra categoría! Esa gente es muy gorda.

...

Veamos, a ver si lo consigo explicar.

Está claro, sólo pongo el duda el concepto. Forzar a mis usuarios a utilizar otro puerto para evitar colapsos no me parece lo más razonable. Las facilidades deberían ser para mis propios usuarios no para el resto.

Vale, pero la cuestión es que hasta que un usuario tuyo no consiga llegar al mostrador y enseñar su credencial, no puedes darle trato de favor. Ese es el problema, mientras todos se agolpen en la misma puerta no sabes quienes son tus clientes y quienes no hasta que que enseñen el carnet. De eso no te libras. Puedes poner un mostrador enorme con muchos empleados, y entonces te aseguras dar un servicio más rápido - pero te cuesta más. El mostrador cuesta dinero y los empleados comen, y se ponen enfermos. O puedes poner dos mostradores - lo cual es sencillo de hacer, y el público normal lo desconoce (dicho de otra forma: todos van al 25). Es tu eleción... como todo en ingeniería. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFgEDitTMYHG2NR9URAi1cAJ9g01x4LrqRrJug9LuwrTYxiaMFtQCdGbU7 N/Nz75HqaMfJRpKSGe5h/L0= =TgOb -----END PGP SIGNATURE-----

El 13/12/2006 16:33:51 Camaleón escribió: noelamac> noelamac> ¿Y no podría configurarse para dar prioridad a los correos de clientes noelamac> autentificados, por ejemplo? Una especie de QoS para servidores de noelamac> correo. Si los autentificados los llevas por conexiones seguras (995-465) no hay problema. Los puedes separar de los demás. noelamac> Al resto, cuando llegue al límite de peticiones, les podría responder noelamac> con un código de "try later", vamos, que lo intente más tarde. Es que noelamac> no veo control alguno entonces en el servidor de correo y por tanto es noelamac> extremadamente vulnerable ¿no? El problema es precisamente que hay que responder. El servidor se colapsa de tanto responder y por eso al final hay que cerrar el puerto 25. Cuando tienes ataques de esta envergadura cualquier máquina (no solo un determinado servicio) es vulnerable, Este tipo de ataques se pusieron de moda hará seis o siete meses, con una vulnerabilidad que se descubrió en una versión de Sendmail. La ventaja es que como hay que usar muchos recursos "zombies" para el ataque, estos suelen durar pocos días y después van a por otra presa que les resulte más fácil (p.e. que no sepa que hacer) -- Saludos, Josep M. Queralt

La duda que tengo es si le atacan directamente a él, o es de rebote.

Es relativamente sencillo saberlo, coger unas cuantas IPs al azar y pasarlas por DNSstuff. Mirar si se corresponden con servidores de Internet o bien son IP dinámicas y, ya de paso, mirar si tienen una procedencia geográfica común.

Es como si alguien estuviera spameando masivamente a todo el mundo usando como remite direcciones del domnino de la victima; muchos de estos correos tienen destinatarios inexistentes u otros problemas y son rebotados a la victima.

Haber, yo tengo varios dominios en esta situación desde hace un par o tres de semanas. Me rebotan los mensajes que mandan falsos usuarios del tipo xlc@dominio.com o sdf@dominio.com pero eso me genera un "extra" que no supera los 500 mensajes diarios y solo me ha ocurrido en dominios alojados en servidores con SendMail ya que los que tengo con Postfix rechazan los rebotes, pero ya te digo, no supone ninguna cantidad alarmante como para ir al colapso, solo se trata de "spammers" hij*s de p*ta" que han cogido nombres que yo tengo la desgracia de gestionar.

La otra posibilidad que se me ocurre leyendote es que la victima sea intencionada, y los rebotes son falsos.

De los "logs" que se pusieron por aquí me llamó la atención que muchos mensajes carecían del "From", eran "From:< >". De todas maneras no es necesario mandar nada para intentar el ataque. Con pedir la conexión al puerto 25 y dejar la conexión abierta hasta que el SMTP se canse es suficiente. Una sola no hace daño, aunque lo haga muchas veces, pero si son varios centenares a la vez ya me dirás. :-( Para saber si los rebotes son falsos habría que hacer lo que decía al principio del ensaje e investigar un poco. -- Salutacions - Saludos, Josep M. Queralt --------------------------------------------------------------------- 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 14/12/2006 1:50:55 Carlos E. R. escribió: robin.listas> A ver si me explico. La situación original es esta: robin.listas> robin.listas> spammer robin.listas> robin.listas> robin.listas> victima 2 intermediario destinatario (victima 1) robin.listas> A B C robin.listas> robin.listas> robin.listas> robin.listas> Si ésta hipótesis es cierta, hay un spammer, dos victimas, y un gi... te robin.listas> tiene un relay abierto, y que es el culpable de todo. No, el culpable continúa siendo el spammer, el intermediario solo necesita consultar con el gilipollólogo por si tiene cura. robin.listas> ¿Puede ser eso? Si, pero se necesitarían muchos "open-relays" para hacer daño. Esto se hace con ordenadores domésticos infectados, Con cada nueva vulnerabilidad de XP hay una nueva oleada de spam. robin.listas> > Para saber si los rebotes son falsos habría que hacer lo que decía al robin.listas> > principio del ensaje e investigar un poco. robin.listas> robin.listas> Si, tienes razón. Es un poquillo pesado, claro. No se trata de mirarlos todos, solo unos cuantos al azar, y ya de paso mirar también si esos servidores estan en "open-relay". Lo más probable es que se trate de IP dinámicas de usuarios domésticos usando sus cuentas legales de correo. -- Saludos, Josep M. Queralt

El 14/12/2006 12:34:10 Carlos E. R. escribió: robin.listas> > Esto se hace con ordenadores domésticos infectados, Con cada nueva robin.listas> > vulnerabilidad de XP hay una nueva oleada de spam. robin.listas> robin.listas> No creo que los intermediarios sean simples domésticos con XP, porque los Me refería a los spammers que conectan con el Open-Relay quieres son "domésticos". En realidad, pero, el "zombie" puede a) lanzar el ataque directamente usando su propio motor smtp. b) usar un Open-Relay c) Usar el SMTP /s legal/es del usuario infectado Un ejemplo: ==== INIT FILE ==== Return-Path: Received: (qmail 4735 invoked by uid 500); 14 Dec 2006 17:53:56 +0900 Delivered-To: shirofan.com-unknown@shirofan.com Received: (qmail 4733 invoked by uid 500); 14 Dec 2006 17:53:56 +0900 Delivered-To: shirofan.com-dixon@shirofan.com Received: (qmail 4731 invoked from network); 14 Dec 2006 17:53:56 +0900 Received: from unknown (HELO isogin1.kappe.ne.jp) (127.0.0.1) by isogin1.kappe.ne.jp with SMTP; 14 Dec 2006 17:53:56 +0900 Received: from hato1.exp.kappe.ne.jp ([192.168.1.178]) by isogin1.kappe.ne.jp (MailMonitor for SMTP v1.2.2 ) ; Thu, 14 Dec 2006 17:53:56 +0900 (JST) Received: (qmail 28091 invoked from network); 14 Dec 2006 17:53:56 +0900 Received: from unknown (HELO cpe-065-184-101-069.sc.res.rr.com) (65.184.101.69) by hato1.kappe.ne.jp with SMTP; 14 Dec 2006 17:53:56 +0900 Received: from [65.184.45.173] (helo=njq) by cpe-065-184-101-069.sc.res.rr.com with smtp (Exim 4.43) id 1GvBhG-0007hZ-2K; Fri, 15 Dec 2006 03:57:50 -0800 ............^^^^^ el spammer o zombie conecta con el Open Relay o Servidor "legal" La IP es 65.184.xx.xx es dinámica y pertenece a "rr.com" por lo que se puede deducir que es un usuario de "rr.com" está usando una cuenta "legal" de este ISP (ya que está usando su servidor de correo. Message-ID: <001101c7203f$ca91cdd0$ad2db841@njq> From: "Sophy Y. Mccormick" To: Subject: Techies code stuff that will process provided you follow the process correctly. Date: Fri, 15 Dec 2006 03:44:36 -0800 ==== END FILE ==== robin.listas> con nombre de dominio y todo. Eso no lo pone el XP automáticamente en una robin.listas> casa, el usuario tiene que prepararlo a propósito. XP lleva un motor SMTP preinstalado. Solo es necesario activar la casilla del servicio correspondiente. De todas maneras hay muchos virus que llevan integrado su propio motor SMTP, de ahí esas Listas Negras que bloquean IP's dinámicas. robin.listas> > Lo más probable es que se trate de IP dinámicas de usuarios domésticos usando robin.listas> > sus cuentas legales de correo. robin.listas> robin.listas> Tengo mis dudas. Respecto a los intermediarios, digo. Son maquinas con robin.listas> servidores de correo establecidos, quizás de empresas pequeñas. Si realmente se trata de un ataque puede ir combinado desde Open-Relays, Cuentas Legales y SMTP víricos. Todo depende de los recursos que dedique el hacker para intentar romper la máquina atacada robin.listas> Lastima que no tenga copia. En el tema hay algunos logs del servidor presuntamente atacado, pero la gracia está en analizar primero algunos de los mensajes originales que provocan el rebote, la lástima es que no siempre viene el mensaje original en el rebote. -- Saludos, Josep M. Queralt

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-12-15 a las 09:33 +0100, Josep M. Queralt escribió:

En realidad, pero, el "zombie" puede

a) lanzar el ataque directamente usando su propio motor smtp. b) usar un Open-Relay c) Usar el SMTP /s legal/es del usuario infectado

Un ejemplo:

==== INIT FILE ====

Return-Path: ... Received: from [65.184.45.173] (helo=njq) by cpe-065-184-101-069.sc.res.rr.com with smtp (Exim 4.43) id 1GvBhG-0007hZ-2K; Fri, 15 Dec 2006 03:57:50 -0800

............^^^^^ el spammer o zombie conecta con el Open Relay o Servidor "legal"

Ya, si.

La IP es 65.184.xx.xx es dinámica y pertenece a "rr.com" por lo que se puede deducir que es un usuario de "rr.com" está usando una cuenta "legal" de este ISP (ya que está usando su servidor de correo.

Vale. Si, eso coincide con lo que creo.

==== END FILE ====

robin.listas> con nombre de dominio y todo. Eso no lo pone el XP automáticamente en una robin.listas> casa, el usuario tiene que prepararlo a propósito.

XP lleva un motor SMTP preinstalado. Solo es necesario activar la casilla del servicio correspondiente.

Pero tienen que tener un nobre de dominio configurado para que funcione, para recibir y enviar.

De todas maneras hay muchos virus que llevan integrado su propio motor SMTP, de ahí esas Listas Negras que bloquean IP's dinámicas.

Si, conozco lo de los virus. Llevan un motor, pero también algunos son capaces de averiguar si en la intranet hay un servidor de correo con acceso externo y usarlo. Por eso incluso en las intranets hay que usar certificación en el correo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFgu4StTMYHG2NR9URAtiHAKCV0ZDO4AK5Wv8VtQmzUqJYXTSeYwCeIaqN 8bZPh9HeaTH7HO8lQqn7YtU= =MbFG -----END PGP SIGNATURE-----

tcp 0 0 165.98.245.78:25 207.253.180.28:41897 SYN_RECV tcp 0 0 165.98.245.78:25 87.233.133.133:52729 SYN_RECV tcp 0 0 165.98.245.78:25 217.12.180.110:20955 SYN_RECV tcp 0 0 165.98.245.78:25 82.153.252.28:56007 SYN_RECV tcp 0 0 165.98.245.78:25 161.111.254.7:43063 SYN_RECV tcp 0 0 165.98.245.78:25 69.20.62.68:36034 SYN_RECV tcp 0 0 165.98.245.78:25 195.251.255.153:47857 SYN_RECV tcp 0 0 165.98.245.78:25 192.89.123.50:56019 SYN_RECV tcp 0 0 165.98.245.78:25 81.14.243.18:32450 SYN_RECV tcp 0 0 165.98.245.78:25 216.22.31.5:44204 SYN_RECV tcp 0 0 165.98.245.78:25 66.113.130.211:37141 SYN_RECV tcp 0 0 165.98.245.78:25 203.194.133.154:51014 SYN_RECV tcp 0 0 165.98.245.78:25 192.86.98.58:33375 SYN_RECV saludos lista... he probado distintas soluciones... --------------------------------------------------------------------- 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 18/12/2006 13:08:41 Carlos E. R. escribió: robin.listas> robin.listas> 1) No podrás evitar esas conexiones. Algunas de ellas son de servidores robin.listas> de correos importantes. Tienes que aguantar el chaparrón y esperar que robin.listas> pase. Ajo y agua. Hay otra chapuza que se puede intentar, fundamentalmente para evitar la caida de otros servicios. Hablo de memoria por lo que no recuerdo el nombre, pero hay un script en perl que permite limitar el ancho de banda que se puede asignar por puertos. Yo lo he visto usar para limitar los consumos en redes P2P pero no creo que haya ningún impedimento para usarlo en el puerto 25. De todas maneras limita anchos de banda (bandwitch) no los recursos que se (mal)gastan en atender las peticiones del puerto, pero quizá pudiera servir. Por otro lado y a estas alturas del tema ya tendría que tener puesto el SMTPs/POP3s y, yo creo, que la tormenta ya tendría, también, que haber pasado. -- Saludos, Josep M. Queralt

2006/12/13, Camaleón :

El 13/12/06, Carlos E. R. escribió:

...

El problema que tiene es un backsatter o como se llame gigantesco.

Lo que me extraña es que la cantidad de correos que recibe no le permitan el uso normal de Postfix, es decir, que los usuarios locales tengan problemas para enviar correos debido a la saturación del servidor.

Me gustaría saber cuántos correos tiene en cola (mailq), porque salvo que sea una salvajada (> 5.000) Postfix no debería tener problemas en un equipo medio (puede tardar más tiempo en enviar los mensajes pero no bloquearse).

P.S. Yo también estoy notando un incremento de los correos de spam, de recibir en una cuenta 500 al día han pasado a ser 1.500...

ya provaste postgrey ??? por aca, ha dado excelentes resuldatos !!! salu2 -- -- Victor Hugo dos Santos Linux Counter #224399 --------------------------------------------------------------------- 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 2006-12-13 a las 13:52 +0100, Josep M. Queralt escribió:

Con la "chapuza" que le propuese puede enviar y recibir también desde el exterior ya que temporalmente tiene el 25 cerrado.

No podrá recibir del exterior precisamente por tener el 25 cerrado. Las unicas conexiones en el stmps serán de los autorizados, pero no de la gente que le envíe correos legales. Se queda incomunicado - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFgAC2tTMYHG2NR9URAgyOAJ4l4Q+z4O/wvSDIW8QRhCuZP8Tq3wCgke5D YBAWIFCJ6evLhKe2CWntXoE= =Qrm6 -----END PGP SIGNATURE-----

El Miércoles, 13 de Diciembre de 2006 15:45, Josep M. Queralt escribió:

Si claro. De todas maneras ten en cuenta que en la situación actual no puede recibir de nadie. :-)

Yo he padecido este tipo de ataques en un servidor con una línea de 100 Mb. y no le he encontrado otra solución que cerrar el puerto 25 intermitentemente mediante un script en IPtables.

Eso si, a los usuarios de este servidor se les ha dicho siempre que usen POP3s y SMTPs. Cuando se produce la saturación ellos pueden enviar y recibir.

* Configura una maquina con smtp como solo relay aguas arriba del servidor principal que se encargue de los procedimientos verificadores que uses RBL, smtpd_*_restrictions, verificar origen, postgrey, etc, y que implemente la seccion "anvil", http://www.postfix.org/rate.html * http://wiki.qpsmtpd.org/ http://www.openfusion.com.au/labs/qpsmtpd/denysoft_greylist

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-12-13 a las 13:05 -0600, gnu forever escribió:

de hecho estoy pensando en configurar greylisting como me lo habia recomendado carlos , lo raro que veo es que el ataque lo tengo ,pero reviso la cola de correos y no tengo nada , estos tipos si que se la saben, por otro lado configure postfix con TLS y el puerto 465 , pero no me funciono , cuando me envian de otros dominios me rebotan desde luego porque buscan el puerto 25 , por estos momentos tengo cerrado el puerto 25 , no quiero ni abrirlo hasta que implemente greylisting los usuarios pueden mandar tanto locales como externo , pero no pueden recibir , he aumentado los procesos hasta 40 y no resuelve me falta probar lo del submision , pero viendo por ahi no recibiria segun lo que entendido....

Tanto lo del submision como lo del smtps (465) sirven para que tus usuarios puedan acceder y enviar, que es uno de los problemas. Eso si lo soluciona. Lo que no puedes evitar es la manada que tienes en tropel a la puerta. Si cierras la puerta ellos no entran, pero tampoco los legítimos. Y si la abres, pues entraran los que puedan. Lo del greylisting ayudará si la manada es de zombies y otros bichos; si no verdaderos correos rebotados, no ayuda en nada. Sólo puedes capear el temporal y esperar que pase. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFgFKrtTMYHG2NR9URAmpkAJ9XjiW0SyYbOPXtGKrQywiR/WHc3QCfSgMV 1Dy8W4PzN07ZRdk3i7/iYY8= =sPuP -----END PGP SIGNATURE-----

ok como puedo hacer que escuche el puerto 773 ? o asignar mas procesos al smtpd? saludosss ... El 12/12/06, Carlos E. R. escribió:

Eso no es ningún problema, lo rechaza y ya está. Te ocupa recursos, que se le va a hacer.

Respecto a no poder enviar tú correos, eso tenía una solución, que es escuchar en el puerto "submit" (773) localmente. Se le asigna un proceso distinto de los correos del exterior, por lo cual no lo pueden saturar. Si no, la soulución es asignar más procesos al smtpd, con lo cual también entrarán más rápido.

Puedes también aplicar medidas como "grey listing". Eso puede ayudar si son spammers, no si son verdaderos servidores de correo.

Lo del netstat no me dice casi nada. Por diversión, usa "-puta" y te pondrá los nombres en vez de las IPs.

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 The Tuesday 2006-12-12 at 21:42 +0100, escribí:

De lo primero (submit) no consigo encontrar referencias ahora. Creo que es esto:

localhost:submit inet n - n - 5 smtpd

Me confundí de nombre, es el "submission", el 587. Viene ya preparado en la configuración: #submission inet n - n - - smtpd # -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes que es bastante restrictiva, si te fijas - pero no hace falta que lo restrinjas tanto. Los correos me entran, pero no registran ese detalle en el log. Si sé que funciona porque al restringirlo me salió el rechazo, luego estaba entrando por ahí. Si te das cuenta, no tiene puesto limitación de subprocesos; mejor le pones algo. Ah! Tienes un "TUNING_README" en la documentación del postfix, creo que te interesa. - -- Saludos, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFfxe5tTMYHG2NR9URAqgNAJ90S+AlHPSWwTFV1RWIsqHbAZZskACglR5U Ant1nZNwerdpaRfx5uhn0Dw= =3ndr -----END PGP SIGNATURE-----