ReturnPath ha publicado una interesante infografía sobre listas negras. Datos sobre RBLs públicas, cuántos días duran listadas las IPs…etc. A modo de curiosidad, resulta interesante.
La imagen pesa más de 1 MB; si quieres verla, continúa leyendo…
Ya hablábamos hace algunos años (¡cómo pasa el tiempo!) sobre Greylisting y la efectividad que tenía al rechazar temporalmente conexiones de ciertas IPs (rangos dinámicos y residenciales). Gracias a esto, todos esos mensajes de spam que envían los bots (que no tienen un sistema de gestión de rechazos (sistema de colas, básicamente) como exige el RFC), son rechazados en primera instancia y no se vuelven a intentar entregar.
Un paso más es combinar esto con la geolocalización de IPs. Gracias a GeoIP, disponemos de una base de datos que guarda el país al que pertenece cada IP de Internet. En Debian por ejemplo, basta hacer:
apt-get install geoip-bin geoip-database
y disponemos ya de un comando que hace la consulta correspondiente:
# geoiplookup 81.12.209.54
GeoIP Country Edition: RO, Romania
¿Y qué podemos hacer con esto? Pues juntarlo con la idea de Greylisting y poder rechazar temporalmente, aparte de las IP dinámicas/residenciales, las conexiones realizadas desde ciertos países que son conocidos por el envío masivo de spam. Podemos sacar un listado de la web de SpamHaus:
Por ejemplo, podemos rechazar temporalmente, las conexiones que tengan como origen IPs de Rumanía, Polonia, China y Brasil. Si decidimos hacer esto, sería conveniente saber si los clientes suelen intercambiar correos con otros usuarios de dichos países, para evaluar el impacto que tendría. No obstante, los servidores legítimos de dichos países, reintentarán el envío del mensaje una vez recibido el rechazo temporal (como exige el RFC), por lo que no habrá problemas de pérdida de correos.
Si lo comentado anteriormente es aplicable para el correo entrante, algo parecido se puede hacer para el correo saliente (el que los clientes nos entregan para hacer relay y entregarlo al destino). Aplicar RBLs sobre los clientes directamente, suele provocar bastantes falsos positivos (con IPs dinámicas sobretodo) así que puede combinarse estas consultas con la geolocalización. La idea podría ser «rechazar los envíos de clientes cuya IP origen esté en una o más RBLs y además el país origen sea poco habitual o sospechoso».
En nuestros servidores de salida, en el día de ayer por ejemplo, estos son algunos de los países al que pertenecen las IPs cuyas conexiones fueron rechazadas por la política anteriormente mencionada:
Vietnam
Rusia
Polonia
Taiwan
Turquía
Rumanía
Kazajistán
Omán
…
mensajes que no tenían pinta de ser legítimos.
Por tanto, vemos como la combinación de varias herramientas, puede proporcionarnos funcionalidades que podemos aplicar en diferentes ámbitos y de diferentes formas en nuestras plataformas de correo.
Se puede leer en la web de la lista negra NJABL, que se vacían las zonas DNSBL, en el proceso de cierre de dicha lista negra:
March 1, 2013: NJABL is in the process of being shut down. The DNSBL zones have been emptied. After «the Internet» has had some time to remove NJABL from server configs, the NS’s will be pointed off into unallocated space (192.0.2.0/24 TEST-NET-1) to hopefully make the shutdown obvious to those who were slower to notice.
Esta lista se consulta desde SpamAssassin en su instalación por defecto, por lo que es conveniente deshabilitarla para evitar consultas DNS en balde. Para ello, bastará con añadir:
score RCVD_IN_NJABL_CGI 0
score RCVD_IN_NJABL_MULTI 0
score RCVD_IN_NJABL_PROXY 0
score RCVD_IN_NJABL_RELAY 0
score RCVD_IN_NJABL_SPAM 0
en la configuración de SpamAssassin. No obstante, habrá que estar atentos a futuras actualizaciones de reglas (vía sa-update), ya que dichas reglas serán deshabilitadas por los propios desarrolladores.
Actualización: a día de hoy, 6 de Marzo, ya se han actualizado las reglas por parte del equipo de SpamAssassin de tal forma que no incluyen los chequeos a dicha DNSBL.
Hemos comprobado que la lista negra RBL.DNS-SERVICIOS.COM, que es gestionada por nosotros, está incluida entre las RBLs a comprobar en MXToolBox cuando se solicita un informe de una determinada IP (bajo el apartado Blacklists).
Este servicio gratuito es ampliamente utilizado por usuarios y administradores de servidores para comprobar en qué listas negras están incluidas sus IPs.
En su propia web, hacen referencia a nuestro servicio y la URL disponible para dar de baja la dirección IP de nuestra lista.
Ya comentábamos hace tiempo además, que nuestra lista negra notifica en formato ARF a los contactos abuse de la IP que es listada, para avisar de dicha incorporación.
Un grupo de empresas de la «élite» actual de Internet, entre las que están Google, Microsoft, Facebook y Paypal, han anunciado una nueva especificación técnica colaborativa llamada DMARC «Domain-based Message Authentication, Reporting & Conformance».
Se trata de un nuevo protocolo mediante el cuál, un emisor que usa SPF y/o DKIM, puede indicar qué hacer si alguno de estos dos tests falla (nótese aquí la diferencia con el «hardfail», «softfail»…etc de SPF) al llegar a un destinatario que consulte DMARC y es más, se establece un canal de comunicación para que el destinatario pueda reportar esos emails al propietario del dominio emisor, con el fin de que éste por ejemplo, pueda investigar los posibles casos de envíos fraudulentos, phishing…etc y atajarlos de forma rápida.
Existe ya un extenso draft al respecto que habrá que ir mirando, ya que la idea parece interesante. El modo de publicación de las políticas DMARC para un determinado dominio, es similar a las de SPF, mediante un registro TXT en el DNS, por ejemplo:
«v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@alvaromarin.com»
en el que se indica la política a aplicar por los destinatarios de mensajes de este dominio cuyos tests SPF/DKIM fallen («reject» en este caso), el porcentaje de mensajes a los que aplicar esta política (100%) y la dirección donde enviar los reportes para ser analizados.
Habrá que seguir de cerca esta iniciativa.
En el mes de Mayo del pasado 2010, puse en marcha un nuevo milter en los relays de correo de entrada de Hostalia.
Dicho milter se encarga de hacer greylisting selectivo a determinadas IPs (rangos dinámicos, fundamentalmente) y el resultado ha sido ciertamente, muy efectivo.
En el siguiente gráfico, vemos como el número de mensajes que se procesan por el motor antispam (en este punto, se han pasado ya todas las RBLs y tests SMTP, por lo que son mensajes que pasan a ser procesados por MailScanner y SpamAssassin) da un bajón importante a partir de la puesta en marcha de dicho milter.
Todo esto sin un solo falso positivo :-)
Está claro, como el tiempo ha ido demostrando, que las formas de lucha contra el spam deben pasar por este tipo de soluciones. De hecho, habrá que empezar a probar seriamente PostScreen, una nueva funcionalidad que ya está presente en Postfix (a partir de su versión 2.8) y que permitirá tener una protección por delante del demonio smtpd. Prometo post sobre ello :-)
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 :-)
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…
| It comes with great sadness that I have to announce the imminent closure of SORBS. The University of Queensland have decided not to honor their agreement with myself and SORBS and terminate the hosting contract.
I have been involved with institutions such as Griffith University trying to arrange alternative hosting for SORBS, but as of 12 noon, 22nd June 2009 no hosting has been acquired and therefore I have been forced in to this announcement. SORBS is officially «For Sale» should anyone wish to purchase it as a going concern, but failing that and failing to find alternative hosting for a 42RU rack in the Brisbane area of Queensland Australia SORBS will be shutting down permanently in 28 days, on 20th July 2009 at 12 noon. This announcement will be replicated on the main SORBS website at the earliest opportunity. For information about the possible purchase of SORBS, the source code, data, hosts etc, I maybe contacted at michelle@sorbs.net, telephone +61 414 861 744. For any hosting suggestions/provision, please be aware that the 42RU space is a requirement at the moment, and the service cannot be made into a smaller rackspace without a lot of new hardware, virtual hosting is just not possible. The SORBS service services over 30 billion DNS queries per day, and has a number of database servers with fast disk to cope with the requirements. Thank you for all your support over the years, Michelle Sullivan (Previously known as Matthew Sullivan) |
Vipul’s Razor es una herramienta distribuida y colaborativa de detección de spam, como bien dice en su página web website. Se basa en fingerprints de los mensajes, comparando el del mensaje a analizar con una base de datos pública y colaborativa. Suele ser usado desde SpamAssassin como plugin, asignando al test resultante una puntuación.
Aplicando este parche, puedes hacer una lista blanca con los fingerprints que generen falsos positivos, como especifica la documentación. El problema es que sin dicho parche y a pesar de que lo pone en la documentación, esta feature de lista blanca no funciona, como dice el propio Vipul en un mensaje.
Puedes bajarte el parche de http://postmaster.hostalia.com/razor2-2.84.diff y aplicarlo con el comando patch para habilitar esta funcionalidad. Luego basta con crear un archivo llamado razor-whitelist con por ejemplo, el siguiente contenido:
# Mensaje con "test" solamente
sha1 75f8bcc2357366bbfa9c6ab0b6e5648ed0cf7083
# Mensaje con "Saludos" solamente
sha1 X0qIKOQy7MrCnYhKH6s5o-FY5kQA
# empty messages
sha1 zdGTYRw61hrsYQoLvVL2vWL1u_EA
sha1 _SsH-KtgO9VSZa2dpZ4fHt9OeOcA
sha1 Hv5WLPo9LTz96VJOTNKYM3618zQA
sha1 GKXO6MQg0SCjpwnR6yP7PX_G--4A
de tal forma que los mensajes con esos fingerprints no serán puntuados.
Como nota curiosa, SpamHaus nos concede una estrella de reconocimiento como red proactiva de no tolerancia al spam. Desde el equipo de abuse de Hostalia, estamos comprometidos con este asunto y tratamos los casos de spam/phishing/seguridad con toda la seriedad posible para acabar con ellos lo más rápido posible.
Que siga así :-)