Si c'était arrivé il y a quelques mois, je pense que je me serai senti humilié. Je deviens un peu moins immature sous linux, je sais faire la part des choses, ce n'est pas un simple relay access. Quand ça arrive, sous windows, on parle de faille, puisque de toute façon, windows n'est pas suffisamment malléable. Sous linux on parle de négligence de l'administrateur, parce qu'en soit tout est paramétrable à souhait, et que c'était la moindre des choses de penser à ça. Autant le prendre avec serénité (j'espère quand même ne pas avoir de plainte des victimes du spam par la suite), et ça peut etre intéressant de comprendre comment le craqueur s'y est prit

Internet ramait

ben heu... internet ramait ce matin.... Je m'en suis surtout aperçu en me connectant sur un autre serveur en ssh. Le serveur de mail sert aussi de proxy, je suis allé voir ce qui s'est passé. Un "mailq" pour afficher la queue de message m'a fait peur. 1200 message en provenance de www-data@LedomaineDuTravail.fr étaient dans la queue, refusés par leurs destinataires.

Ce qui c'est passé sur le serveur mail du travail:

les logs de postfix m'indiquent que les mails ont été émis en local 127.0.0.1. par www-data (le compte utilisé par apache). Je savais que c'était un rique d'installer un serveur web sur un serveur de mail. J'ai eu l'occasion de lire exemple d'insertion de code malveillant dans des formulaires PHP mal conçus ou autres . J'ai dans le doute tout de même vérifié que www-data ne peut pas ce connecter comme les comptes systèmes.

Les logs indiquent que du spam a été envoyé de 20 heures jusqu'au petit matin. Les principales cibles étaient des adresses en @hotmail.com et @yahoo.com Dans le tas, j'ai vu passer une adresse en @finances.gouv.fr (ça craind).

Dans le main.cf de postfix, j'ai changé

smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

par

smtpd_recipient_restrictions = permit_sasl_authenticated,reject_unauth_destination

Traduction: j'ai interdit à la machine d'envoyer des mails depuis elle même. Seuls sont autorisés les utilisateurs authentifiés. Vu le type d'envoi des messages ça devrait suffire à bloquer le spammeur temporairement, le temps que j'essaie de comprendre un peu mieux ce qui c'est passé.

les taches de cron contenaient cette commande: /tmp/. /update >/dev/null 2>&1 (utilisateur www-data, toutes les heures) un petit saut dans lerepertoire /temp m'a permis de voir qu'il existait un repertoire "." et un repertoire "...", appartenant tous deux à www-data. Je les ai supprimé trop vite, j'ai juste regardé rapidement ce qu'il y avait dedans. le dossier /temp n'étant pas pris par l'utilitaire de sauvegarde quotidienne, c'est trop tard. Ma curiosité ne sera pas assouvie. J'ai vu quand même que dans le repertoire "..." il y avait un fichier qui contenait une liste d'IP publique avec des ports (80 souvent). Je me demande si ça n'était pas ça sa backdoor, le fichier correspondant à un botnet?.

J'ai évidement purgé tout ça.

Conclusion

je n'ai pas pigé comment il a fait pour s'introduire ni depuis combien de temps j'étais corrompu.Si un visiteur pourrait expliquer la technique employée, ma curiosité est preneuse. les logs des jours précédents n'indiquent pas une activité spamique, il faut que je remonte plus loin mais là les logs sont sur des bandes de sauvegarde. je ne suis pas sur d'avoir supprimé totalement les portes utilisées mais par flegme et curiosité, je n'ai pas réinstallé le serveur.

Je suis toujours impressionné par ces techniques, qui ne sont pas du simple script récupéré dans pirate mag. Je me demande par contre s'il n'aurait mieux pour lui être moins gourmant et envoyer moins de mails pour ne pas se faire remarquer... enfin, je suis loin d'être le seul a m'être fait avoir.