Spamhaus’ ZEN blacklist efficiency

At work, I'm using Spamhaus' Zen blacklist for many years now. For a huge organization the amount of daily checks makes it impossible to rely on the free Spamhaus service. So we pay for a local copy of the blacklist, rsynched every 20 minutes. It allows faster check too. When you use Spamhaus' blacklists as a paid service, the question is: how can you rate your return on investment? In an attempt to answer this question, I've gathered 2 years and 9 months worth of mail server log files (12 GB bzip2) and extracted some data.

I use greylist, blacklist, whitelist, antispam/antivirus, and recipient-based filtering. So it make things quite complicated when I need clear statistics about what is going on. The MX server accepts around 1.3 million messages a month for internal delivery, but many more come knocking at the door.
The main purpose of blacklisting is to limit the amount of emails going thru expensive filters. Greylist and blacklist are cheap filters: they are fast, and they cost very few CPU, memory, and network resources. In comparison, antispam and antivirus filters are expensive: they are slow, and have a huge CPU, memory and network usage. I do before-queue content filtering. It means the MX server will scan for spam and virus before the email is accepted. So all the filtering process must take place during the SMTP session, and that's a pretty hard thing to do. To make sure that spam and virus filters are available for fast analysis, you must block as much as bad emails with cheap (and fast) filters.

So here is the deal: use of paid RBL (Spamhaus' Zen, here) is only relevant if expensive filters cannot cope with the traffic. Below, the gnuplot output for MX log files between 20100101 and 20120928. It shows in red the number of hits in zen RBL, in green the number of emails coming out of Amavisd-new as "clean", and in blue the number of spam blocked by Amavisd-new.

2 years and 9 months of data: daily spam count in blue ("Blocked Spam" in amavisd-new logs), daily clean count ("Passed") in green, daily blacklist hits in red (blocked using zen.dnsbl-local in Postfix logs).

It shows, mainly, that hits in the blacklist have plummeted, when levels of spam and clean emails out of Amavisd-new are fairly constant. So while the blacklist is blocking at least 5 times less incoming SMTP transactions, the amount of emails reaching the antispam does not change. Spamhaus' zen blacklist efficiency is good (no increase in spam detection), but becomes less useful every day.

Below, the gnuplot output for the same time period showing the number of lines in Postfix logs :

total number of lines in postfix logs, daily basis

total number of lines in postfix logs, daily basis

It's good enough to stand for the evolution of the number of SMTP sessions and it's very similar to the curve of blacklist hits. Then, we can conclude that an external factor is responsible for the drop in incoming unwanted SMTP transactions. The war on botnets really took off in 2010, so may be we have an explanation here.

Lets go back to the main idea of this post: does zen blacklist worth its yearly fee? Based on my experience, yes it does, or at least, it did. From 2008 to 2011, it was clearly an asset. Before-queue content filtering would have been absolutely unusable. Reducing dramatically the load on the antivirus and antispam, zen RBL allowed me to handle about 1,300,000 clean email messages per month on a single MX server with b-qcf (on a 6 years old Apple XServe).
On 2012, zen blacklist still blocks a good daily amount of spam before it reaches the real antispam. But it's clear that if the trend continues, I will not renew the Spamhaus subscription on september 2013. At this rate, usefulness of this blacklist will not worth its cost by the end of 2012. Now that big vendors like Microsoft have embraced the war on botnets, I'm pretty confident that I won't need zen RBL any longer.

Related posts

Utiliser auditd sur Mac OS X et FreeBSD – 3

Cet article est la suite de Utiliser auditd sur Mac OS X et FreeBSD - 2

Exploiter les résultats de l'audit

Dans le premier article j'ai mentionné très succinctement une commande qui permet de lire les logs d'audit en temps réel. Et finalement la consultation de ces logs est sans doute la chose la plus intéressante. Personne n'a envie d'activer l'audit sur une machine pour le simple plaisir de remplir son disque dur. Tout ceci doit avoir une raison d'être : pouvoir ensuite (ou en temps réel) exploiter les logs d'auditd. Continue reading

Related posts

Utiliser auditd sur Mac OS X et FreeBSD – 2

Cet article est la suite de Utiliser auditd sur Mac OS X et FreeBSD - 1

Configuration : quid des utilisateurs comme www ?

J'expliquais précédemment que le système d'audit ne peut suivre un utilisateur que si ce dernier se connecte à la machine (par ssh par exemple), et que quelques soient les ruses utilisées (su, sudo...) c'est toujours l'UID réelle de l'utilisateur qui est suivie.

À cause de cela, il est totalement impossible de traquer des évènements appartenant à des utilisateurs qui ne peuvent pas se connecter au système. Ainsi, une ligne comme celle-ci dans audit_user ne permettra de traquer aucun évènement :

# pour freebsd remplacer _www par www
_www:fc,fd,ex:

Il serait pourtant très intéressant de savoir ce que fait Apache dans votre dos, parfois sous la direction de méchants pirates.
De nos jours, La plupart des serveurs utilisent des protocoles comme l'HTTP qui permettent aux utilisateurs d'accéder aux ressources sans être authentifiés au niveau du système. Les utilisateurs en question n'existent d'ailleurs pas au niveau du système. Néanmoins, les applications web permettent de faire énormément de choses via les langages comme le PHP, y compris d'interagir avec le système, en lançant des commandes, en créant des fichiers, etc.

Si on souhaite qu'auditd puisse contrôler les actions de www, il faut recourir à un artifice. Attention tout de même, ce qui suit est plus proche d'un hack que d'une méthode vraiment propre, et je ne peux pas garantir son fonctionnement correct dans un environnement de production.

En premier lieu il faut installer un programme spécifique, qui va permettre de forcer auditd à suivre les actions pour une UID donnée, sans que l'utilisateur correspondant ait besoin de se connecter à la machine.

curl -LO http://www.freebsd.org/~csjp/setaudit.c
cc -o setaudit -lbsm setaudit.c 

Cela vous donne, si tout se passe bien, le binaire setaudit, que l'on va utiliser sous cette forme :

setaudit -a UID_WWW -m FLAGS /programme/de/lancement/d/apache

Pour suivre les évènements d'exécution de commande sous respectivement FreeBSD et Mac OS X, cela donnera :

setaudit -a www -m ex /usr/local/etc/rc.d/apache22 restart
setaudit -a _www -m ex /usr/sbin/apachectl restart

Ainsi, toutes les commandes lancées par Apache (donc sous l'UID www) sont enregistrées par auditd.
Comme le masque des évènements (les flags de l'argument -m) décrit ce que l'on doit suivre, il est même inutile de renseigner le fichier audit_user.

Pour résumer :

  • Si vous souhaitez que l'audit suive les utilisateurs qui se connectent à la machine, vous pouvez régler les classes d'évènements qui seront soumises à l'audit pour l'ensemble des utilisateurs dans le fichier audit_control, et gérer les cas particuliers dans audit_user.
  • Si vous souhaitez que l'audit suive des UID "interne", pour traquer tout signe de compromission sur un serveur web, un serveur de mail, etc. il faudra recourir à setaudit pour activer l'audit au moment du lancement du service correspondant.
  • Faites attention à la liste de flags que vous choisissez. Le volume des logs d'audit peut grossir très rapidement.

Troisième partie de l'article ->

Related posts

Utiliser auditd sur Mac OS X et FreeBSD – 1

FreeBSD et les versions récentes de Mac OS X sont livrées avec un système d'audit intégré, dérivé du Basic Security Module de SUN, et disponible en logiciel libre sous le nom d'OpenBSM. Ce système d'audit se décompose en deux parties : un ensemble d'appels systèmes dédiés et de librairies d'un côté, et des logiciels "utilisateur" de l'autre. Sauf précision contraire, les explications présentées ici sont valables à la fois pour FreeBSD 7 et 8, et Mac OS X 10.6. Dans cette série d'articles je ne vais aborder que l'aspect "utilisateur" du système d'audit : comment l'activer, comment le configurer, comment exploiter les résultats.
Le système d'audit fourni par OpenBSM a pour but la surveillante des actions des utilisateurs. Un certain nombre d'évènements peuvent être mis sous surveillance, pour tout ou partie des utilisateurs. Quand le système d'exploitation détecte qu'un utilisateur sous surveillance génère un des évènements à surveiller, il averti le démon auditd qui se charge de reporter cet évènement dans un fichier de log. Continue reading

Related posts

Que nous apprend l’affaire « Gawker »

Comme je l'évoquais brièvement dans un précédent article, les serveurs de l'entreprise de média en ligne Gawker ont été piratés récemment, avec pour conséquence immédiate la diffusion au public des logins, emails, et mots de passe chiffrés de plus d'un million d'utilisateurs. Pour plusieurs centaines de milliers d'entre eux, les mots de passe avaient même été déchiffrés avant leur diffusion.
Pour quelqu'un comme moi les dessous de l'affaire sont croustillants, et les détails techniques sont même passionnants. Mais, plus important : tout le monde a une leçon à tirer de ce fiasco monumental.
Cette leçon, et non des moindres, est la suivante : dès l'instant où vous confiez un mot de passe à quelqu'un, ce mot de passe est vulnérable. Ça paraît tout bête comme ça, on se dit "mais oui, c'est sûr qu'en donnant mon mot de passe à mon voisin, alors il n'est plus secret". Non. Relisez bien la leçon, elle est à prendre au premier degré. Oubliez votre voisin, votre copine. Vous créez un compte chez Hotmail, vous choisissez un mot de passe pour pouvoir accéder plus tard à votre boîte mail, vous fournissez ce mot de passe à Hotmail. Ça y est, ce mot de passe n'est plus sûr. Un jour, c'est inévitable, c'est déjà arrivé, et ça arrivera à nouveau, des serveurs Hotmail seront piratés et votre mot de passe pourrait tomber dans les mains de quelqu'un.
L'affaire Gawker est bourrée d'exemples illustrants parfaitement ce principe. Les employés de chez Gawker s'échangeaient des mots de passe par chat, dont les archives des conversations ont été piratées. Le piratage des bases de données des sites de Gawker a montré que les mots de passe des utilisateurs n'étaient pas sécurisés : le chiffrement utilisé était archaïque et connu depuis des années pour être déficient, etc. etc.
Continue reading

Related posts

De la sécurité de vos mots de passe

En terme de mot de passe, on nous rebat souvent les oreilles avec des recommandations sécuritaires qui tombent sous le sens. Par contre, les arguments qui sous-tendent ces recommandations sont parfois largement infondés.
Tout d'abord, on nous dit de ne pas choisir un mot de passe facile à deviner, c'est bien sûr du bon sens. On nous dit que le mot de passe doit être long, car les ordinateurs actuels permettent de tester des milliers de mots de passe par seconde. Plus le mot de passe est long, plus il sera long à trouver. Certes. C'est mathématiquement exact. Mais à quoi arrive-t-on si on force les gens à utiliser un mot de passe à la fois long et compliqué ? Ils vont utiliser le même mot de passe partout, ils vont le noter quelque part, etc.
Imaginons un instant qu'un pirate tente de deviner votre mot de passe de messagerie. Il a une très bonne connexion internet, et son ping (le délai qui s'écoule entre le moment où il envoie une requête au serveur, et le moment où le serveur dit qu'il a bien reçu cette requête) est de 10 millisecondes. Il faut ajouter à cela le temps de traitement sur le serveur, et l'envoi de la réponse. Mettons pour simplifier que la totalité de la transaction dure 20 ms. Si votre mot de passe de messagerie fait 8 caractères différents et qu'il utilise des lettres minuscules (26 possibilités), des lettres majuscules (26 possibilités), et des chiffres (10 possibilités), c'est probablement assez correct. Ce mot de passe utilise donc 8 caractères différents pris dans une série de 62. Soit un total de 136325,9 milliards de mots de passe possibles. À raison d'un mot de passe testé toutes les 20 ms, cela donne plus de 864 siècles, pour tester tous les mots de passe.
Maintenant, ajoutez des caractères parmi @#&"'(§!)-_$*/:;.,?+ (20 possibilités), et il faudra presque 9114 siècles pour tester tous les mots de passe.
Moralité, la puissance des ordinateurs permet effectivement de tester des millions de mots de passe par heure, mais la latence des connexions internet rend ce mode d'attaque quasiment impossible, car elle ralentit terriblement le processus.
Continue reading

Related posts

Le fonctionnement des snapshots

Si les tractations entre Apple et Sun s’étaient passées correctement, les utilisateurs de Mac OS X auraient pu profiter d’ici un an ou deux d’un fabuleux système de fichiers : ZFS. Mais comme souvent, l’intérêt des clients passe après les intérêts de l’entreprise, et il semble finalement qu’Apple ait décidé de créer son propre nouveau système de fichiers.

Un aspect sympathique de ZFS (parmi tant d’autres !), est sa capacité à générer et gérer des snapshots. Un snapshot, c’est une sorte de photographie à un instant donné d’un système de fichiers. Cette photographie peut alors être montée comme n’importe quel autre système de fichiers, elle peut servir de base à une sauvegarde, elle peut servir à rechercher un fichier effacé après la création du snapshot…
Plus que l’utilité évidente en matière de sauvegarde de ces snapshots, j’aimerai revenir sur leur fonctionnement interne, car c’est là que réside toute la magie. En effet, au premier abord l’idée d’une photographie à un instant T de son disque dur semble séduisante, mais très rapidement des voix s’élèvent qui s’interrogent sur le temps que cela prend, la place que cela occupe… Imaginez votre disque dur de 250 Go, 500 Go, ou même 1 To, bien rempli. Vous concluez naturellement que pour faire un snapshot de votre volume, il vous faudra un disque dur externe, de grande capacité, et que cela prend un temps fou. Fort heureusement, c’est faux.

ZFS crée ses snapshots selon le mode copy on write, tout comme le système de fichiers par défaut de FreeBSD : UFS. C’est ce dernier que je vais utiliser pour présenter le fonctionnement des snapshots. Il est probable que l’implémentation des snapshots dans ZFS diffère légèrement, mais la logique reste la même, et de nombreux autres systèmes la partage.
Continue reading

Related posts

Spam de blog : les user agents

Depuis que j'ai codé mon propre antispam pour protéger ce blog des attaques quotidiennes de malfaisants spambots, je collecte précieusement tout ce que ces derniers ont à me dire dans une base de données.
Ainsi, j'ai pu découvrir que, mis à part en de rares occasions, les user agents des spambots sont très variés. Le graphique ci-dessous montre pour la période de mai 2008 à octobre 2009 comment sont répartis le nombre de user agents distincts et le nombre de tentative de spam.

Nombre de user agents différents en fonction du temps

En mai 2008, on note le pic (il dépasse 130 POST/jour) qui correspond à très peu de user agents différents (1 à 2, suivant le jour). Alors que dans le reste de la période la courbe du nombre de POST est très proche de la courbe du nombre d'UA différents.
À noter que, plutôt que de me limiter au seul User Agent, j'ai fait ma petite analyse sur la concaténation des variables HTTP_USER_AGENT, HTTP_ACCEPT, HTTP_ACCEPT_LANGUAGE, et HTTP_ACCEPT_ENCODING. On obtient ainsi une meilleure discrimination entre les différents attaquants.

Voici un exemple abrégé de capture :

REQUEST_TIME : 2008-12-09 19:51:33
HTTP_HOST : www.patpro.net
REMOTE_ADDR : 88.198.53.43
HTTP_USER_AGENT : Mozilla/5.0 (Windows; U; Windows NT 5.0; ru; rv:1.8.1.6) 
                  Gecko/20070725 Firefox/2.0.0.6
HTTP_ACCEPT : text/xml, application/xml, application/xhtml+xml,
              text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
HTTP_ACCEPT_LANGUAGE : ru
HTTP_ACCEPT_ENCODING : deflate

Si on s'intéresse particulièrement aux variables HTTP_ACCEPT* on voit qu'elles sont utilisées de manières très inégales en fonction du robot :

header_spamweb

On peut supposer que ces caractéristiques permettent de différencier les différents botnets, et versions des scripts. Les spammers poussent donc le raffinement assez loin, dans le but, bien sûr, de passer au travers des protections antispam. Dans certaines tentatives que j'ai enregistrées, le client fourni même un cookie de session.

Related posts