Juste un retour d’expérience…

J’ai eu besoin de transformer un serveur physique avec une Ubuntu, en serveur sous VMware. A priori, le soft VMware pour faire cela ne fonctionne que si la source est un OS Windows, et des outils comme liveview semblent avoir un un support Gnu/Linux partiel.

J’ai donc voulu tenter d’abord avec l’utilisation d’un simple dd et cela semble avoir parfaitement fonctionné.

J’avais lu l’article de Sp4rKy sur u-classroom et je l’ai un peu adapté…

Pour ne pas avoir à refaire depuis le début en cas d’échec, je suis passé par une image intermédiaire. Comme le serveur physique n’avais pas de port USB pour copier sur un disque externe, j’ai fait le transfert par le réseau.
La procédure suivante devrait donc pouvoir être simplifiée dans d’autres cas de figure, pour directement copier d’un disque vers l’autre sans passer par une image intermédiaire.

• Backup

Sur la machine intermédiaire qui recoit l’image, tout ce qui arrive sur le port 9000 sera copié dans un fichier sur le disque USB:

nc -l -p 9000 | dd of=/media/disk/imageSrv

Boot du serveur à cloner sur un liveCD, puis copie du disque vers la machine intermédiaire 1.1.1.1:

dd if=/dev/sda | nc 1.1.1.1 9000

Après quelques heures, on obtient l’image brute:

ll /media/disk/imageSrv  
-rw-rr 1 user user 136G 2048-10-10 10:10 /media/disk/imageSrv

• Restauration dans VMware

Boot de la VM sur un liveCD, tout ce qui arrive sur le port 9000 sera copié sur le disque:

nc -l -p 9000 | dd of=/dev/sda

Depuis le poste qui contient l’image brute, on envoi l’image vers la VM 2.2.2.2:

dd if=/media/disk/imageSrv | nc 2.2.2.2 9000

Après quelques heures, on n’a plus qu’à rebooter en croisant les doigts.

• Informations complémentaires

A priori, le seul problème rencontré, est le réseau qui ne montait pas, voici les explications:
La carte réseau étant désormais virtuelle, avec une nouvelle MAC, Ubuntu a attribué à la nouvelle carte, le nouveau nom eth1.
Vu que dans /etc/interfaces, seule eth0 était déclarée, il n’y avais donc pas d’ip pour ma nouvelle interface eth1.
Il suffit alors de supprimer la référence AncienneMAC <-> Eth0 dans le fichier /etc/udev/rules.d/70-persistent-net.rules et de rebooter pour que la nouvelle MAC puisse se caler sur eth0. (Sinon au lieu de rebooter, il semble que l’on puisse corriger le fichier, couper networking, restarter udev, démarrer networking)

Si le liveCD contient cryptcat, il faut l’utiliser à la place de netcat afin de chiffrer les transferts.

• 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.

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.