www.alvaromarin.com

Blog sobre spam, sistemas antispam y correo electrónico

Euskaltel bloquea el tráfico saliente hacia el puerto 25

Como hace tiempo hizo Telefónica y como podemos ver a través de su centro de seguridad Nemesys, Euskaltel ha pasado a bloquear el tráfico saliente hacia el puerto 25 para alguna de sus redes.
Como dicen en su web:

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.

Transparencias Master Seguridad Deusto

A continuación, dejo las transparencias usadas en el Master de Seguridad de la Información, en el que impartí el módulo de Seguridad en sistemas de correo electrónico.

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 ;-)

End of Life Announcement: ClamAV 0.94.x

Me hago eco del anuncio por parte de Luca Gibelli, desarrollador de ClamAV, que comenta (ya es el segundo aviso) que a partir del 15 de Abril de 2010, la actualización de firmas del antivirus incluirá una que deshabilitará el demonio clamd para versiones anteriores a la 0.95 (más antiguas de 1 año). Estas versiones no permiten firmas más grandes de 980bytes por lo que es necesaria su actualización para empezar a usarlas.

El anuncio completo en la lista de ClamAV.

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

SpamAssassin 3.3.0

Hoy día 27 de Enero del 2010, ha sido liberada la versión 3.3.0 de SpamAssassin. En breve empezará a estar presente en los paquetes de las distintas distribuciones Linux, aunque para los que usamos CPAN ya está disponible esta última versión.

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 :-)

Protección en el kernel de FreeBSD contra DoS a SMTP

En la pasada EuroBSDCon 2009 celebrada en Septiembre, un congreso de los hackers de FreeBSD, hubo una charla cuyo título rezaba “FreeBSD kernel protection measures against SMTP DDoS attacks”, por Martin Blapp.

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.

IX Reunión del Foro ABUSES

El próximo 20 y 21 de Octubre se celebra la IX reunión del Foro Abuses, que para el que no sepa qué es (c&p):

El Foro ABUSES es un espacio para técnicos de Operadores (telcos o ISPs) que gestionan o están interesados en solucionar incidentes de seguridad y abusos en Internet. En estas reuniones del Foro ABUSES se pretende mejorar la confianza entre ISPs españoles a través de reuniones participativas que generen conclusiones y acciones.

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.

Recomendaciones de RBLs del Foro Abuses

Es común en los ISPs tener problemas con ciertas RBLs ( hasta Telefónica los tuvo con Hotmail hace poco aunque estos últimos no usen RBLs públicas sino más bien sistemas de reputación); son miles los clientes y las IPs que se gestionan, y siempre puede haber alguna intrusión en algún servidor, algún cliente al que le han robado el usuario/contraseña…etc.

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á ;-) ).

Postscreen, una posible mampara para Postfix

Si ya comentábamos en otro post que Wietse Venema tenía la idea de crear una especie de postfix-lite para aligerar el actual Postfix, parece que Wietse está trabajando también en otro proyecto llamado Postscreen.

(Lee el artículo entero)

Posible cierre de SORBS

La popular conocida lista negra de SORBS, podría cerrar el 22 de Julio del presente 2009. Parece que la Universidad de Queensland, donde tenían el hosting, ha decidido no respetar el acuerdo que tenía con SORBS y por tanto ahora mismo está en venta a no ser que alguien pueda ofrecer espacio para un rack de 42 Us en Australia.

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…

Los planes de Wietse Venema (Postfix)

En la lista de distribución de postfix-users, alguien ha comentado la existencia de un proyecto llamado OpenSMTPD creado por los chicos de OpenBSD. De hecho, en LWN se habla sobre ello y anuncia una pronta primera release del software.

¿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!

Entradas siguientes »