El objetivo es evitar que los equipos de nuestros clientes puedan ser utilizados sin su consentimiento para envío masivo de SPAM, PHISHING y otras amenazas emergentes a día de hoy en Internet

Parece, no obstante, que el bloqueo se produce solamente a sus redes de IPs dinámicas.

Si por ejemplo, un cliente de Euskaltel tuviese un servicio de correo contratado en una empresa de hosting como puede ser Hostalia, simplemente cambiando el puerto de salida del 25 al 587 (como reza el RFC 2476 – Message Submission) en su cliente de correo, podría seguir usando dicho servicio.

Telefónica ya consiguió en su día salir de los primeros puestos de redes emisoras de spam con esta medida y a pesar de las quejas iniciales, todos nos hemos visto beneficiados por esta medida.

No queda más que decir que bien por Euskaltel y que a ver si el resto de ISPs siguen las mismas políticas.

Dicho módulo comenzó con estas transparencias introductorias en las que se da un repaso a todo lo que engloba el servicio de correo electrónico, como son los protocolos y RFCs, MTAs, el problema del spam, botnets, phishing, diversas técnicas antispam, filtrado por contenidos, pasarelas de correo…etc.

Espero que os resulte interesante ;-)

El anuncio completo en la lista de ClamAV.

A más de uno le pillará el toro, seguro ;-)

En el Changelog se puede leer una amplia lista de cambios y nuevas features introducidas en esta nueva versión.

A modo de resumen, comento varias de ellas:

- Las reglas no se distribuyen ahora con SpamAssassin, sino de forma independiente, por lo que después de instalarlo habrá que hacer un sa-update para proceder a bajarlas.

- El plugin de AWL (AutoWhiteList) pasa a estar deshabilitado por defecto. Daba bastantes problemas así que me parece correcto.

- El plugin de DKIM, pasa a estar habilitado por defecto. Un pequeño empujón para el tema de DKIM ;-)

- Nuevos parámetros para soportar reputaciones del servicio DCC

- Nuevas opciones para debugging

- Los scores de las reglas han sido generados mediante un algoritmo genético y pulidos gracias a reportes de usuarios, beta testers.

- Añadidas las listas PSBL, CSS, ReturnPath…

- …

Para ver la lista completa de cambios, remito al Changelog que ya he comentado :-)

El paper de aquella charla se puede encontrar en:

http://www.ukuug.org/events/eurobsdcon2009/papers/BSDCON09-SMTP-DDoS-Final.pdf

Como el propio título hace suponer, se trata de un módulo (llamado accf_smtp para el kernel de FreeBSD capaz de gestionar las conexiones SMTP entrantes al servidor y prevenir cierto tipo de ataques (comunes entre las botnes). Con dichas conexiones, puede realizar diversas funciones como hacer una pausa antes de entregar el banner del servicio SMTP, rechazar conexiones que no envíen primeramente el comando HELO/EHLO, establecer número máximo de caracteres en parámetros de comandos…etc.

Soy de la opinión de Wietse Venema que comentaba que esas funciones no son para hacerlas en el kernel sino en userland, como ya hacen numerosos servidores de correo electrónico, por lo que en realidad no supone nada nuevo.

Esta idea está basada en el ya existente accf_http, que gestiona las conexiones HTTP entrantes.

Habrá que esperar a ver qué opinan los que puedan probarlo en sus FreeBSDs.

Este año se celebra en A Coruña, organizada conjuntamente por Mundo-R y RedIRIS/Red.es

La agenda de la reunión es la siguiente:

Dia 20 de Octubre (martes)

* 10.00-10.30 Recepción y Bienvenida

* 10.30-13.30 Sesión 1

Mejores prácticas entre fiscales, ISPs y Fuerzas de seguridad del Estado

Debate y puesta en común. Se contará con la presencia de Luis M. Uriarte Valiente: (Fiscalía Provincial de Pontevedra, Miembro del Servicio de Criminalidad Informática (SCI) )

Presentación de la “Oficina de Seguridad del Internauta” INTECO-cert

* 16.00-18.00h. Sesión 2 (tarde):

Intercambio de experiencias entre miembros del Foro

o Experiencia de soluciones antispam: CloudMark , Commtouch etc
o R: “Sobre análisis de protocolos y búsqueda de IRCs de control de botnets”
o ARSYS: “Experiencias abuses”
o Dynahosting: “Nuevo miembro del Foro ABUSES”

Día 21 de Octubre (miércoles)

* 10.00-13.30h. Sesión cerrada y exclusiva a miembros del Foro ABUSES

Experiencias con implementación de herramientas para los requerimientos de la Ley de Retención de Datos. Solución implementada en EUSKALTEL.

Asuntos internos Foro ABUSES

* 13.00-13.30h Sesión final

Conclusiones y próxima reunión

Durante el foro, haré una presentación de nuestra experiencia con Cloudmark, un software antispam que llevamos tiempo probando con interesantes resultados.

Esto es más aceptable; se soluciona el problema para evitar más envío de spam y se da de baja la IP de dicha lista negra. Hasta aquí correcto. El problema viene con listas que o tienen una política dudosa de listado (como listar rangos completos sin motivo alguno) o ponen mil impedimentos para dar de baja tu IP.

Por ello, desde el Foro Abuses, se acordó sacar un documento de consenso para comentar las listas más conocidas y ver cuáles eran las que más problemas nos acarreaban.

El documento final, muestra una serie de puntuaciones sobre las RBLs en base a varios criterios y califica a varias de ellas como “no recomendables” para su uso, como APEWS, SPAMCANNIBAL, UCEPROTECT…etc.

Este documento, obviamente, es público y se le puede dar la difusión que se considere (para eso está ;-) ).

Como se puede ver en su web, se trata de un nuevo demonio que actuará delante del proceso smtpd actual para escuchar las peticiones SMTP externas. Dicho demonio gestionará las conexiones para intentar evitar los ya famosos zombies, consultar RBLs…etc.

En unas transparencias se habla un poco más del tema y de su arquitectura. Por ahora, el demonio se basa en la consulta de una lista blanca de 24 horas de duración en la que se listan las IPs que no están en RBLs y que pasan los tests de pausa después del “saludo” inicial que devuelve el servidor (aquí es donde la mayoría de zombies caerán). Las IPs que estén listadas en alguna lista negra o no pasen dichos tests, se rechazarán. Dicho saludo se trata de una respuesta multilínea, en este formato:

220 servidor.dns-servicios.com ESMTP
[espera de unos segundos]
220 servidor.dns-servicios.com ESMTP

donde el primer saludo lo lanza Postscreen y el segundo el proceso SMTPD real. Como decía, muchos zombies pondrán el comando HELO/EHLO antes de esa segunda línea y caerán en “la trampa”.

Veremos cómo evoluciona el proyecto, pero a primeras, parece interesante :)

SORBS mantenía unas políticas de deslistado de IPs bastante controvertidas, llegando a veces hasta a cobrar por el deslistado de una IP de su lista negra. Es por ello que mucha gente se alegra de tal cierre.

De una u otra forma, SORBS ha sido una de las listas negras más usadas y que siempre ha estado ahí con sus listas de relays abiertos, proxys, SOCKS, rangos de IPs dinámicas…etc. Su trabajo hay que reconocerlo ya que llevan desde 2002 con dicho proyecto, soportando 30 billones de consultas DNS al día.

Veremos el 22 de Julio qué es lo que pasa.

El comunicado es el siguiente:

ANNOUNCEMENT: Possible SORBS Closure…

¿Para qué reinventar la rueda? “Simplemente” por cuestiones de licencia; parece que en OpenBSD no les gusta excesivamente la licencia pública de IBM que tiene Postfix, por ello han decidido desarrollar otro servidor SMTP.

Wietse Venema, el creador de Postfix, ya decía que no le apetecía mucho andar con jaleos de licencias con los abogados de IBM, y el bueno de él comenta:

Apart from that, if they come up with a decent MTA then I welcome
some competition. More motivation for me to look into postfix-lite.

Por lo que parece, Wietse tiene prevista hacer una limpieza de código importante, sobre todo evitando código de compatibilidad con versiones antiguas y demás:

Fully-featured as far as RFCs are concerned, but not necessarily
drop-in compatible with earlier Postfix configurations or file
formats.

Ideally this means eliminating thousands of lines of non-obvious
code, either by removing the feature or workaround altogether, or
by replacing it with code that is easier to maintain but not 100%
compatible. This will be a slow process.

Veremos cómo avanza OpenSMTPD, pero realmente lo tienen bastante difícil para desbancar no solo a Postfix, sino a otros proyectos ya muy maduros como Exim, Qmail, Sendmail…etc.
Tienen MUCHO trabajo por delante…suerte!