Côté sécurité, la machine était blindée de chez blindée: afin de limiter au maximum les fuites, tous les flux de données sortants vers l’extérieur étaient scrupuleusement filtrés voir même oblitérés dans certains cas: pas d’envoi de mail possible, aucun port USB, accès canalisé uniquement aux extranets des fournisseurs avec notamment un filtrage par un IDS du POST HTML, la méthode qui permet de remplir un formulaire et ainsi d’envoyer des informations sur Internet. En définitive, une machine complétement verrouillée et en théorie parfaitement sécurisée.

Au cours d’un déjeuner avec un collègue ERP, nous avons évoqué à plusieurs reprises cette machine ainsi que les précautions extrêmes qui avaient été prises pour la sécuriser. Lui en rigolait car il m’avoua qu’il existait des problèmes de communication entre les achats et la comptabilité, et que régulièrement des deltas existaient entre les deux services, essentiellement à cause de cette machine: visiblement quelques opérations d’achat n’étaient pas répercutées convenablement vers la comptabilité, essentiellement à cause d’un problème récurrent d’interfaçage avec l’ERP. Les comptables étaient souvent obligés de repasser derrière les acheteurs pour les contrôler (en utilisant leur outil de gestion) et au vue du nombre important de transactions effectuées, des tensions avaient commencé à surgir entre les deux services, l’un traitant l’autre d’incompétent. « Au lieu de transformer la machine des achats en forteresse, ils feraient mieux de corriger ce problème  » m’avait dit le collègue.

Les semaines ont passé et mon audit était sur le point de se terminer lorsque j’ai eu une conversation animée avec la DSI et notamment son responsable sécurité sur la machine des achats. Alors que celui-ci clamait haut et fort que cette machine était certainement la plus sécurisée de toute l’entreprise, moi je tempérais de la manière la plus diplomatique possible en lui rétorquant que par expérience un système n’est jamais sûr à cent pour cent. Il l’a très mal pris et a commencé à m’attaquer et aussi à critiquer mon audit et mon professionnalisme. Comme le client a toujours raison, je n’ai pas insisté et rapidement laissé tombé, le laissant à ses arguments qui ne m’ont jamais convaincu.

Je n’ai jamais de problème avec mes détracteurs, je les laisse toujours parler et évite tant que faire se peut la confrontation professionnelle: c’est fatiguant et on perd beaucoup trop de temps pour généralement des queues de cerises. Si je n’ai jamais véritablement souffert de ce type d’attaque, il y a quand même quelques chose qui m’a toujours intéressé dans ce type de situation: le défi intellectuel. Alors, je me suis mis à réfléchir sur les moyens de contourner les dispositifs de sécurité de cette machine. Comme j’y avais accès pour mon audit, j’ai pu en profiter pour mettre en place une tactique qui m’a pris plus de trois semaines d’intenses réflexions.

Tout d’abord, j’ai pu constater avec bonheur que le VBS n’avait pas été désactivé sur la machine. J’exècre ce langage au plus haut point, lui préférant Perl mais il faut bien reconnaitre qu’il est bien utile pour faire des scripts sous Windows. Ensuite, la machine n’est pratiquement jamais éteinte car elle réalise des transferts EDI la nuit.

Je commence par repérer la tâche planifiée qui lance les traitements EDI le soir à 22 heures. Il s’agit d’un script qui appelle plusieurs applications. Dedans, j’y incorpore discrètement un petit programme VBS de ma composition. Mon programme commence par ouvrir l’application e-carte bleue, celle qui génère les numéros de cartes bancaires uniques. Grâce à l’instruction SetCursorPos, je me positionne sur la fenêtre de l’application, et finalement je simule un clic de souris au moyen d’un « mouse_event ». Après grâce à l’outil en ligne de commande ImageMagick, je fais une capture d’écran. Puis je récupère les informations bancaires au moyen d’un logiciel de reconnaissance de caractères, dans mon cas il s’agit de GOCR. Toutes ces opérations sont faites en tâche de fond, discrètement. J’ai pu installer ces logiciels grâce à un répertoire partagé que la machine utilise pour y récupérer quelques fichiers à traiter. Bien évidemment ce répertoire était en lecture seul, toujours dans le but d’éviter toute fuite.

C’est à ce niveau que je suis confronté à une difficulté majeure: comment envoyer automatiquement ces informations à l’extérieur de l’entreprise, sachant que je n’ai accès ni au mail, ni au FTP, ni même à ce fameux POST qui m’aurait bien aidé ? Je dois bien avouer qu’il n’y a pas beaucoup de solution à ce problème, d’autant plus que la machine ne peut accéder qu’à certains sites, essentiellement ceux des fournisseurs. En parlant de ceux-là, justement j’ai découvert quelque chose d’intéressant.  Plusieurs d’entre eux utilisent le fameux logiciel de statistiques Awstats. C’est ce que j’ai découvert en examinant le cache Google qui a fortuitement indexé plusieurs pages des statistiques web des fournisseurs.

C’est là que j’ai découvert la solution à mon problème:  je vais utiliser mon User-Agent pour transporter les codes bancaires. Prenez par exemple ce User-Agent Firefox:

Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.8)                Gecko/20100202 Firefox/3.5.8 (Build 01425)

Que je transforme en:
Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8 (Build 4970549792752184-0510-174)

Vous notez la différence ? En fait, j’incorpore le code bancaire directement dans le User-Agent; dans ce cas, on pourrait presque parler de stéganographie. Pour terminer, j’utilise le logiciel Wget et son option « -U » muni du User-Agent qui va chercher anodinement la page d’accueil du fournisseur. Finalement, depuis chez moi, je récupère les pages de statistiques web que j’examine avec un dernier script qui met les codes bancaires dans un simple fichier CSV. Et voilà comment j’ai pu récupérer plusieurs milliers de codes en à peine trois mois.

Bien entendu, je n’ai pas dévoilé cette astuce à mon client et gardé toute cette tactique pour moi. J’étais content: j’avais pu me prouver à moi même que j’avais entièrement raison lorsque j’expliquais au client qu’il n’existe aucun système fiable à cent pour cent. L’audit s’est finalement terminé après que mes relations se soient beaucoup dégradées avec cette société. Ils n’ont pas été très satisfaits de mes conclusions, et je pense que cela vient du responsable sécurité qui a tout fait pour discréditer mes travaux. Ils n’ont jamais voulu payé la prestation qui se monte à plusieurs centaines de millier d’Euros. Nous sommes désormais en contentieux avec eux, et je pense que cela va durer encore des années.

Je ne suis pas quelqu’un de revanchard, mais quelque part j’ai quand même l’impression d’avoir été bien floué. Alors est-ce une folie passagère ou tout simplement un mauvais coup de colère, j’ai décidé de mettre tous ces codes bancaires en ligne, de sorte que d’une façon ou d’une autre ils payent chèrement ma prestation. Il y a exactement 8734 codes bancaires, il s’agit juste de l’extraction d’une base MySql; en aucun cas, je n’ai déplombé le secret des cartes bancaires.

Vu le foutoir qui règne toujours entre leur service achat et comptabilité, qu’ils gèrent des milliers de commandes par mois, qu’ils ne sont absolument pas au courant de ma petite bidouille ainsi que la grande improbabilité qu’ils lisent Pagasa, franchement n’hésitez pas à vous servir de ces codes. Attention, je vous rappelle qu’un code ne sert qu’une seule fois.

Bons achats à tous.

Aujourd’hui, ce ne serait évidemment plus possible, car nous avons affaire à des millions de virus, vers, chevaux de Troie, sans compter tous les Spywares, Adwares qui hantent l’Internet: heureusement nous disposons d'antivirus tout simplement téléchargeables, comme cloud pour venir contrer tous ces parasites- il faudrait forcément rassembler une équipe tant les proportions d’infection sont grandes. On peut véritablement parler d’épidémie, et ceci dure depuis déjà de nombreuses années sans que l’on puisse en voir la fin.

Connaissant ce milieu, je me suis penché sur les motivations qui peuvent pousser quelqu’un à écrire un virus. Vous verrez qu’elles offrent un large éventail de profils bien distincts les uns des autres. Elles sont aussi à la hauteur du nombre gigantesque de malwares que l’on recense chaque jour.

La première motivation est le défi intellectuel. En effet, ce n’est pas forcément donné à tout le monde de coder un virus, capable d’infecter des millions de machines. Pour avoir déjà désassembler quelques virus, il faut parfois une très bonne maitrise technique pour arriver à produire « quelque chose » de performant. Je vous laisse imaginer le défi que cela représente d’aller inspecter les entrailles de Windows et  pondre un code capable d’exploiter une faille LSASS. Maintenant, la chose est tout de même devenue plus aisée grâce  à l’utilisation de langages plus simple comme le Visual Basic. Mais le résultat ne sera pas forcément spectaculaire; c’est toujours en assembleur que l’on sera capable d’aller au plus loin dans le codage d’un virus. Le défi est finalement similaire au challenge que l’on peut se lancer dans un sport ou une activité extrême.

La deuxième motivation est la vengeance. Lorsque l’on a été brimé par son employeur, par exemple, il est tellement facile de déposer quelque part « une petite cochonnerie », bien cachée au sein du système d’information qui se déclenchera quelques semaines après notre licenciement départ. Ce genre de chose n’est pas à proprement parlé un virus, mais plutôt un cheval de Troie; le but n’étant pas de forcément se reproduire, mais juste de nuire à l’ennemi. Par exemple, on peut imaginer un programme qui, à chaque redémarrage du PC, va aller effacer aléatoirement un fichier stratégique, comme une DLL par exemple.

Notre troisième motivation est la reconnaissance. Si vous faites partie de ceux dont on se moque tout le temps, parce que vous transportez votre ventre dans une brouette, vous avez beaucoup de chances de rentrer dans cette catégorie. En mal de notoriété, vous cherchez le coup d’éclat, vous faire remarquer et créer un virus peut certainement vous aider dans votre quête. Le seul problème, c’est que vous allez devoir affronter un paradoxe que votre esprit n’arrivera pas à résoudre: vous voulez être connu, mais vous savez pertinemment que si vous déclarez sur un forum que vous êtes l’auteur du ver Sasser, vous avez beaucoup de chances d’avoir des problèmes avec la justice. Et pour votre gouverne, les sociétés n’embauchent pas les créateurs de virus, il s’agit d’une légende urbaine. De toutes les manières, il est clair que vous allez avoir des ennuis.

Notre quatrième motivation est sans doute la pire des choses, puisqu’il s’agit de terrorisme.Vous ne l’avez peut être pas remarqué, mais l’Internet grouille de cyber-activistes, cyber-anarchistes, cyber-extrême-machin, etc. A l’image du pyromane qui se délecte de la vue d’un feu de forêt, certains ne rêvent que de destruction. Et l’Internet a ceci de fabuleux, c’est qu’il est un formidable terrain de jeu pour les créateurs de virus destructeurs, capables de semer la destruction des systèmes d’exploitations ou des précieuses données. Et je profite de cette occasion pour vous dévoiler comment on a déjà tenté si ce n’est de détruire l’Internet, mais le ralentir fortement: en lançant un DDOS massif sur les principaux serveurs root.

Et je termine avec la dernière motivation: l’argent. Évidemment, avec les milliards qui transitent sur l’Internet, il est normal que les bandits de grands chemins se soient attaqués à ce nouveau territoire. De plus en plus de Botnets sont désormais utilisés pour des malversations financières. Les précédents exploits du Botnet Mariposa ne sont pas là pour me contredire.

Même si le chiffre me semble ridiculement bas, il existe une bonne dizaine de Botnets clairement identifiés par des « chasseurs » : le Kraken, composé de plus de 400000 machines capable de générer 9 milliards de spams par jour, le Srizbi autrefois responsable de 60% du spam sur Internet, etc.

Parmi tout cela, l’un de ces Botnet a retenu toute mon attention pour le très haut niveau de technicité employé dans son utilisation: il s’agit du Botnet Storm.

Le Storm, encore appelé Storm Worm, de part son étroite relation avec un cheval de Troie du même nom, a été identifié pour la première fois en Janvier 2007. Les médias prétendent que ce Botnet serait composé de 1 à 50 millions de machines, mais les experts estiment que « seulement » 160000 machines forment ce Botnet.

Bien entendu, il est très difficile de déterminer l’origine du Storm: certains pensent qu’il serait contrôlé directement depuis le sol Américain alors que d’autres estiment, qu’à l’instar de plusieurs de ces « confrères », il serait Russe et même l’œuvre du sinistre Russian Business Network, une occulte organisation cyber-criminelle.

Comme tous les autres Botnet, le but principal du Storm est de générer du spam de nature différente: fichiers PDF ou Excel contenant des images, enregistrement vocal de MP3, texte brut, et email d’hameçonnage (Phishing). Au mois de mars 2008, 20% des spams sur Internet proviendrait du Storm.
Il est également à noter qu’une partie des machines est exclusivement dédiée à l’extension du Botnet, en envoyant par mail des chevaux de Troie chargés d’infecter les machines sur Internet.

Outre le spam, le Botnet est également capable de lancer des attaques DDOS contre d’autres groupes et organisations mais aussi en direction de ceux qui le traquent.

Si le Storm est particulier, c’est que son anatomie est différente des autres Botnet. Au fil du temps, ces auteurs semblent s’être durement focalisés sur la survie de leur création, passant d’une organisation relativement simple et classique à quelque chose de beaucoup plus sophistiquée.

Dans un Botnet rudimentaire, vous trouvez toujours un serveur principal appelé Command and Control (C&C) qui se charge de contacter et de contrôler ces milliers de machines contaminées sur tout le réseau. Pour casser ce type de Botnet, il suffit donc de trouver le C&C et de le désactiver: les machines Zombies sont alors privées de toute commande à distance et rendues partiellement inoffensives.

Le Storm a une approche foncièrement différente et s’organise en différentes couches. Tout en haut de la pyramide, vous avez un C&C tournant sous Apache, et vraisemblablement placé en Russie, selon les dires des experts. Au niveau inférieur, vous trouvez un proxy Nginx chargé de dissimuler la présence du C&C.
Au troisième niveau, vous trouvez une collection de Nginx qui masque le proxy principal du niveau supérieur. Au quatrième niveau se trouvent les nœuds publiques qui agissent comme des reverse proxies et qui renvoient les communications vers le C&C, agissant comme des serveurs DNS fast flux. La technique du fast flux consiste à associer un même nom de domaine à plusieurs IP différentes, et ce rapidement. Finalement, le dernier niveau se compose de milliers de machines serviles, réparties sur tout l’ensemble du réseau.

Le processus d’infection se fait généralement par mail mais peut aussi être déclenché via le réseau P2P. Lorsque la victime a cliqué sur le lien situé dans son mail, le programme va télécharger un fichier exécutable directement depuis un nœud du quatrième niveau. Une fois infectée, la machine compromise et le nœud s’échangent l’adresse IP du nouveau Zombie. L’information est alors envoyée au troisième niveau, puis au second pour finalement parvenir au C&C.

Au deuxième et troisième niveau, les proxies Nginx écoutent le trafic P2P des réseaux Overnet et eDonkey. Overnet est un réseau à base de table de hachage distribuée (DHT) basé sur l’algorithme Kademlia. Il s’agit du même protocole utilisé par les anciennes versions de eDonkey. Depuis octobre 2007, le Storm a changé son protocole: non seulement il utilise Overnet pour communiquer, mais les dernières versions du programme utilisent désormais leur propre réseau P2P. Ce réseau est quasiment identique à Overnet si ce n’est que l’information qui y circule y est encryptée.

Pour identifier les nœuds ainsi que le contenu sur le réseau Overnet, l’algorithme DHT utilise une clé linéaire (Généralement 128 bits) . Tous les algorithmes DHT ont leur propre façon de calculer la distance logique entre deux nœuds ou entre un nœud et du contenu distribué.

Kademlia calcule la distance entre les nœuds en effectuant un ou exclusif entre leur hachage publié.
Lorsqu’une machine souhaite trouver du contenu sur le réseau, elle calcule (ou reçoit) le hachage du contenu et recherche des machines adjacentes à elle même. Ces dernières répondent également en annonçant leurs propres machines adjacentes. Le processus est répété jusqu’à ce qu’une machine soit à même de répondre à la requête de la recherche du contenu.

C’est parce que le réseau Overnet fonctionne sur un modèle de distribution qu’il n’existe aucun annuaire des machines. La liste des machines actives ainsi que le contenu publié sont distribués en petits morceaux directement dans la mémoire de toutes les machines du réseau. C’est toujours l’absence d’annuaire centralisé ainsi que la nature dynamique de ce qui est stocké dans la DHT qui rend le Storm tellement résistant à son démantèlement.

En conclusion, je dirai qu’à la vue de tout ce que j’ai pu lire sur le sujet, ce botnet est un véritable chef d’œuvre de technologie au service du mal. Sa complexité et son architecture lui ont valu le privilège d’être le sujet de plusieurs études, voir même de thèses écrites par des chercheurs de haut niveau. Maintenant, loin de moi de vouloir faire l’apologie du cybercrime, on ne peut que rester perplexe devant un tel déchainement de recherches techniques, de réflexions et d’efforts, surtout pour de si noirs desseins.

La force de ce programme est qu’il vous est possible de définir vous même vos propres tests à effectuer. Ceci se fait d’un manière très aisée via un simple fichier de configuration.

Il est souvent intéressant de constater que certaines formes d’adresses perturbent grandement les MTA qui finissent par accepter le relayage. Les résultats doivent toutefois être relativisés car certains MTA feignent d’accepter le relayage, mais détruisent en interne le message.

Chksmtp peut également être utilisé comme CGI et peut gérer les résultats de ses tests en HTML. Chksmtp détecte automatiquement l’environnement utilisé.

Vous pouvez tester en ligne chksmtp en cliquant ici.

Dernière version de chksmtp (RPM Linux):
1.17 (26 décembre 2005, md5: 06e381b6bc44dd1a2bb27ecf983073af)

Anciennes versions de chksmtp (RPM Linux): 1.16 (1 décembre 2004), 1.15 (2 juillet 2004), 1.14 (1 mai 2004), 1.13 (14 avril 2004), 1.12 (5 avril 2004), 1.11 (9 mars 2004)

Historique:

* 26/12/05: Ajout des blacklists
* 06/12/05: Ajout de la gestion du VRFY
* 23/06/05: Ajout du paramétrage du « HELO »
* 28/05/05: Modification d’un petit bug dans la capture CGI (Car 0×11)
* 15/05/05: Ajout du reverse
* 14/05/05: Modification des paramètres CGI pour une meilleure localisation
* 13/04/05: Correction d’un bug dans la saisie du formulaire HTML
* 01/12/04: Gros bug TLS corrigé
* 29/10/04: Ajout du paramétrage du fichier de configuration (chksmtp –conf fichier)
* 28/09/04: Modification des stats
* 23/09/04: Ajout du calcul du LA, installation de la version anglaise
* 31/07/04: Ajout de la commande HELP, et meilleure identification du MTA
* 06/07/04: Ajout de la gestion des authentifications (SMTP AUTH)
* 02/07/04: Petit bug d’affichage sur les stats
* 16/05/04: Correction mineure, ajout des stats
* 24/04/04: Petit bug d’affichage corrigé, ajout des reconnexions, du paramétrage du port SMTP, des signatures et des timeout sur les connexions et reconnexions
* 18/04/04: Meilleure optimisation de pgm(), support TLS ajouté
* 16/04/04: Ajout de la gestion esmtp
* 15/04/04: Ajout du nombre de tests, modification du message d’exclusion
* 14/04/04: Ajout des timers+CPU, prise en compte d’une erreur sur le fichier log
* 13/04/04: Ajout des exclusions
* 07/04/04: Modification du format des logs, prise en compte du masque dans chkip()
* 05/04/04: Suppression de la bufferisation des sorties HTML, modifications des sorties, correction de quelques bugs d’affichage (accents ok)
* 29/03/04: Ajout des CR dans le code HTML, modification de getconnect() pour une meilleure prise en compte des timeout
* 03/03/04: Suppression des caractères accentués
* 16/01/04: Bug caractère continuation à la connexion
* 03/10/01: TM, Première version

Sendmail va tourner dans le sous-environnement que vous allez créer dans le répertoire /sendmail, et aucun autre répertoire ne sera visible à l’extérieur de ce dernier.
Il vous faut maintenant fournir les éléments vitaux au logiciel (bibliothèques, répertoires, fichiers, etc.). Vous devez pour cela créer des fichiers physiques, car les liens symboliques sont proscrits car ils ne peuvent sortir du répertoire prison /sendmail :
# cd /sendmail
# mkdir usr
# mkdir usr/sbin

Sendmail est enfermé dans sa prison, avec des droits restreints :
# cp /usr/sbin/sendmail /sendmail/usr/sbin
# chown 0:0 /sendmail/usr/sbin/sendmail
# chmod 500 /sendmail/usr/sbin/sendmail

Des applications, telles que les serveurs Web, utilisent divers raccourcis pour accéder à Sendmail. Vous devez donc créer ces raccourcis :
# mkdir /sendmail/lib # cd /sendmail/lib
# ln -s ../sbin/sendmail sendmail
# mkdir /sendmail/bin
# cd /sendmail/bin
# ln -s ../sbin/sendmail sendmail

Fournissez maintenant à Sendmail les programmes annexes dont il a besoin, en commençant par extraire les bibliothèques dynamiques qu’il utilise :
# ldd /sendmail/usr/sbin/sendmail
libdb.so.3 => /lib/libdb.so.3 (0×40016000)
libresolv.so.2 => /lib/libresolv.so.2 (0x4004f000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4005d000)
libnsl.so.1 => /lib/libnsl.so.1 (0×40060000)
libdl.so.2 => /lib/libdl.so.2 (0×40075000)
libc.so.6 => /lib/libc.so.6 (0×40078000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0×40000000)

Le résultat peut varier suivant les options de compilation et les versions des noyaux :
# cd /sendmail/lib
# cp /lib/libdb.so.3 .
# cp /lib/libresolv.so.2 .
# cp /lib/libcrypt.so.1 .
# cp /lib/libnsl.so.1 .
# cp /lib/libdl.so.2 .
# cp /lib/libc.so.6 .
# cp /lib/ld-linux.so.2 .

Créez la file d’attente :
# mkdir /sendmail/var
# mkdir /sendmail/var/spool
# mkdir /sendmail/var/spool/mqueue
# chmod 700 /sendmail/var/spool/mqueue

Créez le répertoire /var/run pour que Sendmail y place son numéro de processus (sendmail.pid) :
# mkdir /sendmail/var/run

# touch /sendmail/var/run/sendmail.pid

Ajoutez l’unité /dev/null, dont Sendmail a besoin en interne :
# mkdir /sendmail/dev
# mknod /sendmail/dev/null c 1 3
# chown 0:0 /sendmail/dev/null
# chmod 666 /sendmail/dev/null

La définition du noeud (c 1 3) n’est valable que sous Linux.
Pour écrire ses historiques, Sendmail communique avec syslog via un socket. Vous devez donc créer ce dernière dans l’environnement chroot :
# /usr/sbin/syslogd -m 0 -p /sendmail/dev/log

L’emplacement de syslogd peut différer d’un système à un autre. Prenez garde à n’avoir qu’une seule instance de syslogd dans le système.

A ce stade, vous devez régler le délicat problème de la résolution de noms. Sendmail ne peut fonctionner correctement sans cette résolution. Cette configuration s’effectue dans le répertoire /etc :
# mkdir /sendmail/etc

Créez le fichier d’aiguillage des services (etc/nsswitch.conf) de façon à renseigner l’emplacement des fichiers, indispensables à la résolution de noms. Le contenu du fichier /sendmail/etc/nsswitch.conf est le suivant :
services: files

La ligne services renseigne le fichier etc/services, lequel contient la corrélation entre un numéro de port TCP ou UDP et le nom usuel du service.
Pour utiliser ce dispositif, vous devez pouvoir accéder à la bibliothèque libnss_files-2.2.2.so :
# cd /sendmail/lib
# cp /lib/libnss_files-2.2.2.so .

Cette bibliothèque est généralement appelée via un autre nom, libnss_files.so.2 :
# ln -s libnss_files-2.2.2.so libnss_files.so.2

Voici la bibliothèque nécessaire à la résolution de noms (DNS) :
# cp /lib/libnss_dns.so.2 .
/
et le fichier /sendmail/etc/services :
smtp 25/tcp mail

Puisque le chroot concerne uniquement SMTP, seule cette ligne est nécessaire.
Voici enfin le fichier du client DNS etc/resolv.conf :
nameserver 127.0.0.1

Nous supposons ici que vous disposez d’un serveur DNS local (127.0.0.1). Il est recommandé de mettre celui de votre FAI, car cela simplifie grandement la configuration de votre serveur.
Pour le répertoire /etc/mail contenant les données de configuration, vous disposez d.une alternative :
· Placer les bases de données et le fichier de configuration dans /sendmail/etc/mail par le biais d’un petit script exécuté à chaque modification du paramétrage. De cette façon, vous isolez et sécurisez les fichiers source (alias, access, etc.) et le fichier mc dans l’environnement primaire.
· Créer un lien de /etc/mail vers /sendmail/etc/mail, exposant ainsi les fichiers source dans l’environnement chroot.
Choisissez ici la seconde possibilité, la plus commode :
# mkdir /sendmail/etc/mail
# ln -s /sendmail/etc/mail /etc/mail

Voici le fichier d’état de Sendmail, sendmail.st :
# touch /etc/mail/sendmail.st

et un très simple fichier mc :
include(`/usr/lib/sendmail-cf/m4/cf.m4′)
VERSIONID(`Sendmail chrooté ‘)dnl
OSTYPE(`linux’)dnl
define(`confMAX_MESSAGE_SIZE’, `5000000′)dnl
define(`STATUS_FILE’, `/etc/mail/sendmail.st’)dnl
define(`confDOMAIN_NAME’, `monserveur.com’)dnl
define(`ALIAS_FILE’, `/etc/mail/aliases’)dnl
define(`SMART_HOST’,`smtp.monfai.com’)dnl
define(`confLOG_LEVEL’,`14′)dnl
define(`confSEPARATE_PROC’,`true’)dnl
FEATURE(`access_db’,`hash -o /etc/mail/access’)dnl
FEATURE(always_add_domain)dnl
MAILER(smtp)dnl

qui vous permet de construire votre sendmail.cf :
# m4 sendmail.mc >sendmail.cf

Le niveau d’enregistrement des événements a été fixé à 14 (define(`confLOG_LEVEL’,`14′)). Cette valeur est particulièrement élevée afin de repérer les éventuelles erreurs. Dans cette configuration, tout le courrier est expédié vers le serveur de votre FAI, smtp.fai.com.
Voici le fichier /etc/mail/aliases :
MAILER-DAEMON: postmaster
postmaster: root
bin: root
daemon: root
nobody: root
system: root
root: monemail@monadresse.com

que vous créez de la façon suivante :
# chroot /sendmail /usr/sbin/sendmail -bi -v

Le root est en fait un alias vers une autre adresse e-mail. Sur le serveur chrooté, vous n’acceptez, par commodité, aucune livraison de courrier (voir plus haut).
Voici le fichier /etc/mail/access correspondant, qui contrôle les adresses autorisées à utiliser le relais :
127.0.0.1 RELAY
10 RELAY
localhost RELAY
localhost.localdomain RELAY

que vous créez de la manière suivante :
# makemap -v hash access.db <access

Seule la machine locale et le réseau IP 10.0.0.0 sont autorisés à utiliser le relais SMTP.
Démarrez Sendmail :
# chroot /sendmail /usr/sbin/sendmail -bd -q15m

Le serveur doit maintenant fonctionner correctement.
L’utilitaire strace est recommandé pour la mise au point d’un Sendmail chrooté. Il permet notamment de déterminer les fichiers et bibliothèques manquants.
Désormais, vous disposez d’un Sendmail parfaitement sécurisé, enfermé dans une prison logique.

Ceci est très dangereux car la plupart des personnes générant du courrier non sollicité (encore appelé spam) utilisent ce genre de relais. Ils ont moins de chance de se faire repérer en utilisant un serveur tiers plutôt que celui de leur FAI (Fournisseur d’Accès Internet).

Pour information, les spammeurs envoient généralement des milliers voire des dizaines de milliers d’emails; on voit clairement le risque encouru lorsqu’un serveur est relais ouvert.

Nous allons maintenant tester manuellement un serveur SMTP afin de voir si oui ou non, celui-ci est un relais ouvert.
La première chose à faire est d’extraire du DNS le MX (Mailer Exchanger), en fait le nom du serveur SMTP qui peut nous faire entrer sur un domaine de messagerie. Ceci se fait grâce à la commande NSLOOKUP:
nslookup -q=mx domaine.fr 194.2.0.20

Le « -q=mx » indique que l’on s’intéresse uniquement au champs MX du DNS, le domaine.fr représente le domaine de messagerie et l’adresse IP est tout simplement le DNS que l’on interroge, ici celui d’Oleane.
Le même résultat peut être obtenu avec la commande DIG:
dig mx domaine.fr

En retour, nous obtenons:
mail.domaine.fr

Nous pénétrons sur le serveur au moyen d’un simple telnet:
telnet mail.domaine.fr 25

Le 25 correspond au numéro du port SMTP. En réponse, nous obtenons quelque chose de semblable à ceci:
220 mail.domaine.fr Simple Mail Transfer Service Ready

Le 220 indique que la connexion a été acceptée et qu’un dialogue SMTP peut commencer.
Nous commençons par nous identifier:
helo mamachine.domaine.com
ou
ehlo mamachine.domaine.com

Nous lui donnons notre adresse SMTP, lui indiquant la source du message:
mail from: moi@mondomaine.com

Attention, le domaine doit exister car bien souvent le serveur SMTP fait une requête DNS pour vérifier que celui-ci n’est pas factice. Certains serveurs demandent également d’utiliser une syntaxe quelque peu différente:
mail from: <moi@mondomaine.com>

Nous lui donnons l’adresse SMTP correspondant au destinataire du message:
rcpt to: lui@sondomaine.com
ou
rcpt to: <lui@sondomaine.com>

Ici, il y a deux possibilités:
554 : Recipient address rejected: Relay access denied

Le code d’erreur 554 indique que le serveur SMTP n’accepte pas le relais.

250 OK

Le code de retour 250 autorise le relais: le serveur est donc un relais ouvert. On ne peut toutefois en être absolument sûr car certains serveurs peuvent rejeter le relayage après le dialogue SMTP.

Vous avez la possibilité de tester en ligne si un serveur est relais ouvert ou non en cliquant ici.
Le programme consiste à tester plusieurs formes de relayage possible. Le résultat est toutefois à prendre au conditionnel car certains serveurs SMTP feignent d’accepter du courrier mais l’effacent par la suite. Toutefois, le fait d’échouer sur le premier test indique tout de même une grosse faille potentielle.

Ce petit programme Perl effectue une dizaine de tests sur un serveur SMTP donné. Il faut, bien sûr, se trouver à l’extérieur du réseau sur lequel se trouve ce serveur.
Attention, suivant le serveur que vous utilisez, le programme peut vous indiquer qu’il est relais-ouvert mais en fait il n’en est rien, car le message est rejeté en interne après la clôture de la transaction SMTP.

Si vous voulez être absolument sûrs que le serveur est un relais ouvert, remplacez les deux variables $domaine et $test dans la fonction tst() respectivement par votre domaine de messagerie ainsi que par votre compte POP.

Exemple:
$domaine= »wanadoo.fr »;
$test= »jacques.vanpiperzen »;

Si le serveur est effectivement relais alors vous recevrez prochainement du courrier.
Le programme demande une adresse IP ou un nom de machine comme argument; il y aurait moyen de l’améliorer en y ajoutant des alarm() afin de pallier à d’éventuels dépassements de temps sur l’accès au serveur.

La meilleure façon de se protéger efficacement contre le relayage est bien évidement d’avoir un serveur SMTP bien configuré mais ce n’est pas forcément évident à mettre en oeuvre surtout sur des systèmes aussi complexes qu’Exchange Server ou Lotus Notes; ces deux serveurs demandent généralement une bonne pratique avant d’être parfaitement maîtrisés.

Aussi, je m’appuierai plus sur une sécurité à l’échelle d’IP; l’avantage est que l’on devient complètement indépendant de la configuration SMTP.
Une approche pourrait être que chaque fois que l’on découvre quelqu’un utilisant son serveur SMTP de façon illicite, alors on interdit à toute la classe IP de ce même utilisateur d’accéder au serveur. Cette approche (déjà rencontrée) est très mauvaise:
- elle pénalise autrui, à savoir les utilisateurs innocents,
- elle ne résout pas le problème,
- a ce rythme, des pans entiers d’Internet ne pourront bientôt plus communiquer avec le serveur.

La meilleure façon de procéder consiste à appliquer les étapes suivantes:
- Tout d’abord, on laisse gérer le courrier par le FAI; celui-ci dont le métier est l’Internet doit être capable de répondre à la problématique suivant:
« Je ne veux pas que mon serveur SMTP soit relais ouvert ».
Pour être plus précis, on va confier la gestion du MX du domaine au FAI; suite à l’extraction du MX, tout le courrier entrant arrivera donc directement chez le FAI.
- Le FAI ré-acheminera tout le courrier sur notre serveur SMTP.
- Le port 25 de notre serveur de messagerie ne sera accessible que par le(s) adresses IP du/des serveur(s) SMTP de notre FAI.

Ceci se fera grâce à un filtrage élémentaire sur le routeur (Exemple CISCO):
access-list 125 permit tcp host 10.0.0.10 host 192.168.0.10 eq smtp
access-list 125 deny tcp any any eq smtp log

où le 10.0.0.10 représente le serveur du FAI et le 192.168.0.10 le nôtre.
Toutes les autres tentatives d’utiliser le(s) serveur(s) SMTP sont enregistrées.

On peut faire la même chose grâce à un iptable sous Linux :
/sbin/iptables -A INPUT -j ACCEPT -p tcp -s 10.0.0.10 -d 192.168.0.10 –dport 25

Grâce à cette technique, on canalise le flux SMTP et on interdit ainsi à quiconque de l’utiliser, si ce n’est les personnes autorisées.