• Résumé de l’histoire

McColo Corp est un hébergeur basé en Californie, surtout connu pour sa part importante dans tout ce qui touche à des activités “cyber criminelles”…
Depuis 4 mois, Security Fix récoltait (auprès de diverses sociétés de sécurité) un maximum d’informations sur McColo pour monter un dossier sur leurs activités.
Lundi, le rapport est envoyé aux 2 principaux providers de McColo…
Mardi, l’un des deux, Hurricane Electric, coupe tous les accès Internet de McColo.. Depuis, impossible de joindre toutes leurs machines…
Et, ce qui était prévu ce produit, une baisse de 2/3 des spams dans le monde.
(Bon, je doute, comme d’autres, que cela ai été aussi simple, mais on n’a pas plus d’infos actuellement).

  • Les chiffres

Ci dessous le graph de SpamCop qui était disponible à la date de ce post à cette adresse.

uggy15niv200_

Il résume assez bien tous les graphs que j’ai pu voir sur le sujet, et correspond exactement à ce que j’ai également contasté ( -75% de spams en moyenne jusqu’à ce jour)) sur les serveurs mails dont j’ai la gestion. (Des serveurs dont le nombre de spams quotidiens ce compte toujours en plusieurs millions).

  • Divers

Biensur, les spams n’étaient pas envoyés depuis les serveurs de McColo (çà aurait un peu trop simple à bloquer).
Par contre, les serveurs qui controlaient toutes les machines infectées dans le monde, elles, étaient chez McColo…
Depuis qu’elles ne peuvent plus joindre leur serveurs “maitres”, ces machines infectées n’envoient plus de spams… (pour l’instant)…

Il n’est qu’une question de temps avant que les activités ne reprennent par d’autres providers ou sur d’autres hébergeurs… Mais quand même ça fait drôle de voir à quel point couper un seul hébergeur peut faire chuter instantanément un nombre si important de spams… A quand le retour des spams à leur niveau précédent ?

  • Updates

20Nov2008- L’ISP suédois TeliaSonera a laisser passer du traffic vers McColo en Californie quelques heures. Ceci semble avoir permis à McColo de reconfigurer ses bots pour pointer vers une IP en Russie…

21Nov2008- Les botnets Asprox/Ozdok/Mega-D sont de retour… pas encore de signes de Srizbi/Rustock..

  • Références

WashingtonPost: Lien 1 Lien 2 Lien 3 Lien 4
F-Secure
Sophos
Un [rapport](http://hostexploit.com/downloads/Hostexploit Cyber Crime USA v 2.0 1108.pdf) de HostExploit sur McColo.
McColo up again, down again
Le botnet pointe vers la Russie
Le point par CBL

A priori il n’est pas possible d’utiliser sort ou uniq tout en préservant l’ordre.

$ cat toto  
ccc  
FFFF  
ccc  
aaaaaaaaa  

e  
FFFF  
e  
bbbb  
dddddddd  
FFFF  

Possible en utilisant awk

$ awk ' !x[$0]++' toto  
ccc  
FFFF  
aaaaaaaaa  

e  
bbbb  
dddddddd

Pour des connexions manuelles sur des ports SSL:

openssl s_client -connect www.kernel.org:443

Ou plus simple sans avoir en sortie tout ce qui concerne le certificat:

sudo apt-get install telnet-ssl
telnet -z ssl www.kernel.org 443

Ces outils de chez nominum permettent de tester les performances d’un serveur de cache / Récursif ( ResPerf ) et d’un serveur Authoritative ( DNSPerf ).

Le README explique que Bind doit etre installé car des librairies…etc.. sont utilisées. Il ne reste ensuite qu’à compiler.

Les man sont bient faits et expliquent de manière assez détaillée la manière dont les 2 programmes fonctionnent.

  • ResPerf
resperf -s 10.0.0.2 -d queryfile

queryfile est de la forme

domain1.com A  
domain2.fr MX  

Le fichier utilsé par QueryPerf dans le billet précédent peut donc être utilisé

$ wc -l /tmp/ile  
880000 /tmp/file  
$  
$ head -4 /tmp/file  
fhs.com A  
bluejean.com.tr A  
geeo.org A  
bluessiden.com MX  
$

Sans les données en cache on obtient sur un Bind:

Statistics:  

Queries sent: 74240  
Queries completed: 9780  
Queries lost: 64460  
Ran for: 49.438710 seconds  
Maximum throughput: 1392.000000 qps  
Lost at that point: 33.14%

Avec les données déjà en cache on obtient sur un Bind:

Statistics:  

Queries sent: 78073  
Queries completed: 13794  
Queries lost: 64279  
Ran for: 49.679299 seconds  
Maximum throughput: 2044.000000 qps  
Lost at that point: 1.83%
  • DNSPerf

Tout pareil au niveau des commandes ou des sorties, mais avec un code optimisé pour faire les requètes sur un serveur qui a authorité sur les domaines demandés.

Queryperf est un outil pour tester les performances d’un serveur DNS.

Il est fourni dans les sources de Bind.. Il n’y a qu’à compiler.

bind-9.5.0-P2/contrib/queryperf/

Il y a plusieurs options, une des principales est de lui fournir en entrée un fichier avec des noms de domaines à résoudre.

$ queryperf -v -d /tmp/fichier

Ce fichier est sous la forme:

$ cat /tmp/fichier  
nom1.fr A  
nom2.com MX  

Par défaut il utilise 127.0.0.1 comme serveur à interroger mais ceci, comme le reste, se change par les options.

Pour créer un fichier source avec quelques entrées, j’ai utilisé comme base une de mes règles de rejet dans les logs de Postfix.. à coups de :

| grep "from=<" | awk -F@ '{print $3}' | awk -F> '{print $1}'

Puis on ajoute A ou MX à la fin de la ligne à coups de:

| awk '{print $0"\tA"}'
| awk '{print $0"\tMX"}'

On obtient au final:

$ wc -l /tmp/file   
880000 /tmp/file   
$ ll /tmp/files | awk '{print $5'}   
13M   
$ head /tmp/file   
fhs.com A   
bluejean.com.tr A   
geeo.org A   
bluessiden.com MX   
americanhomestaffing.com A   
$

Ce sont des domaines trouvés dans les MAIL FROM:<> d’un des règles de rejet. On doit donc avoir un peu de tout, des domaines qui existent, d’autres non, des DNS non joignables.. Bref quelquechose qui doit être a peu près représentatif d’un trafic réel. (On n’a pas de “vrais” noms de machine, c’est vrai).

On obtient donc pour du récursif sur un Bind:

Statistics:   

Parse input file: once   
Ended due to: reaching end of file   

Queries sent: 880000 queries   
Queries completed: 872400 queries   
Queries lost: 7600 queries   
Queries delayed(?): 0 queries   

RTT max: 5.006302 sec   
RTT min: 0.000009 sec   
RTT average: 0.064140 sec   
RTT std deviation: 0.156662 sec   
RTT out of range: 3 queries   

Percentage completed: 99.14%   
Percentage lost: 0.86%   

Started at: Tue xxx x 11:59:54 2008   
Finished at: Tue xxx x 13:18:25 2008   
Ran for: 4710.344667 seconds   

Queries per second: 185.209377 qps   

Un dump du cache pour vérifier:

$ rndc dumpdb   
$ ll /var/chroot-named/etc/namedb/named_dump.db | awk '{print $5}'   
6.9M   
$

On peut ensuite “gréper” un domaine de la liste pour trouver les entrées correspondantes dans le cache.

Le test en cours:

queryPerfUggy

Ce n’est probablement pas ce qui se fait de mieux pour des stats, mais ca peut aider lors de manipulations diverses sur des serveurs DNS.