Mon blog

Python & Datalove <3

Attaque de mon serveur de mail

Je viens de me rendre compte que mon serveur de mail perso, auto-hébergé depuis plusieurs années dans mon garage avait fait l'objet d'une attaque. J'ai donc demandé un peu d'aide sur les IRC des internets, et on ma demandé de faire un post-mortem.

PS: Suite à l'écriture, je pense que le billet est très long, donc c'est à vos risques et périls. Je n'ai pas forcément solutionné le truc, et tout avis est bon à prendre. Si vous voulez me contacter (et si mon serveur fonctionne), n'hésitez pas !

Curriculum Vitae

Afin de bien se représenter les choses, on va d'abord commencer par faire un point sur le matériel, le logiciel, et la personne qui s'en occupe (ou pas)...

Tout d'abord, il faut savoir que j'ai mis en place mon propre serveur de mail il y a presque 10 années. Je n'y connaissais pas grand chose, je suis plutôt un développeur qu'un "admin sys" (autrement dit, je ne sais pas m'occuper des serveurs et j'avoue que je trouve ça ennuyant). Après ces 10 années, force est de constater que ça m'ennuie toujours autant, que j'ai appris quelques trucs, et que je tâche de me débrouiller pour en faire le moins possible.

Niveau matériel, j'utilise des portables avec écran HS vendus pas chers via petites annonces ou bien je récupère à la déchetterie. Bon, le dernier point c'est tellement tendu maintenant que j'y ai un peu renoncé, et puis comme le matériel a tendance à pas trop lacher, j'achète pas des trucs tous les mois non plus.

Niveau logiciel, j'ai bien entendu installé postfix. Je dis bien entendu car après quelques recherches, j'ai vite vu qu'il y avait pléthore de documentation sur les internets, et que tout un chacun le loue comme un serveur de mail puissant et fiable. Pour information, il faut savoir que je suis un tout petit consommateur de mails, j'en reçois pas mal (listes et autres), mais je dois en envoyer 1 par jour en moyenne...

Enfin, le tout est installé sur une Debian que je mets à jour (si si) quand j'y pense et tout tourne à peu près derrière une box ADSL dont le débit est plutôt mauvais.

Les soucis usuels

Depuis quelques années, les temps sont durs pour les serveurs de mail auto-hébergés. Les "grands" de ce monde s'emploient à mettre en place des règles anti-spam plus ou moins farfelues, mais pas que, heureusement (je ne retrouve pas l'article de Stéphane Bortzmeyer à ce sujet à l'heure où j'écris ces lignes).

Il est plutôt connu et reconnu que les adresses en yahoo et en laposte sont souvent difficiles à joindre. Les adresses comme gmail peuvent également l'être mais je dirais que c'est plus à cause de leur strict respect de beaucoup de sécurité. Et comme je l'ai dit avant, j'ai peut-être pas tout configuré comme il le faudrait. Cela dit, bon an, mal an (je viens d'apprendre à l'écrire...), les mails que j'envoyais jusque là était en général plutôt bien acceptés.

Or donc, il y a quelques mois (le temps passe vite), je me retrouve du jour au lendemain coupé du monde : plus de mail, plus de site web (auto-hébergé aussi). Et je finis par découvrir que mon adresse IP fixe a changée. Free, mon Fournisseur d'Accès à Internet que j'utilise depuis donc plus de 10 années m'avait fait sauté mon IP...

Alors, le temps de comprendre, de tout remettre en état, j'ai finalement réussi à remettre d'aplomb tout le bousin. De même, il a fallu reconfigurer ce qu'on appelle le "reverse DNS" et qui, pour faire smiple, permet au serveur destinataire du mail de vérifier que c'est bien moi qui lui écrit.

Ainsi, régulièrement, des choses se passent et il faut parfois se prendre une demi-journée pour régler les soucis.

Des soucis plus étranges

Et pui un beau jour, lorsque je cherche à écrire à mon père (qui possède une adresse free), je me fais bêtement retoquer : après lui avoir téléphoné je me rends compte qu'il n'a rien reçu. Après quelques jours (merci au protocole SMTP de ré-essayer un peu au cas où), la nouvelle tombe : free refuse mon mail.

Il refuse d'ailleurs un autre mail dans lequel j'avais juste mis un lien. C'est souvent considéré comme du spm potentiel, mais ça m'était souvent arrivé auparavant (l'envoi) sans être bloqué pour autant.

Et donc, feignant comme pas deux, je procrastine bêtement en me disant que "ra gna gna", free a du augmenter ses règles imbéciles pour lutter soi-disant contre le spam et que moi, petit auto-hébergé, je me retrouve pris dans les filets.

Mais les soucis ne s'arrêtent pas là. Mon serveur de mail est installé sur un vieux portable qui a tendance à chauffer si on l'utilise trop et voilà qu'un jour je me rends compte qu'il est arrêté (oui, je l'ai dit, je regarde peu mes mails). Ok, pas de souci je le relance. Mes mails arrivent à nouveau à ma boite mais pas super rapidement, étrange, mais bon, il y a pire...

Le piratage

Et voilà que le soir même le PC s'arrête à nouveau. Cette fois je décide d'investiguer un peu et je vais donc jeter un oeil au syslog, ce que je considère comme le log un peu central du PC (oui, je vous vois les adminsys purs et durs, je vais dire pas mal de bêtises e tfaire des raccourcis, donc lisez ce qui suit comme s'il s'agissait d'une simple fiction...).

Le log me renvoie des choses plutôt étranges, même pour un novice comme moi :

Dec 19 09:35:44 kepler postfix/smtp[1798]: 5DBBC9C0D8D: to=<turk38k@icloud.com>, relay=mx02.mail.icloud.com[17.42.251.12]:25, delay=851, delays=844/0.96/6.3/0, dsn=4.7.0, status=deferred (host mx02.mail.icloud.com[17.42.251.12] refused to talk to me: 550 5.7.0 Blocked - see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=82.64.206.161)
Dec 19 09:35:44 kepler postfix/smtp[1886]: connect to 183.com[39.105.14.253]:25: No route to host
Dec 19 09:35:44 kepler postfix/smtp[1798]: 5DBBC9C0D8D: to=<turkeyman1959@icloud.com>, relay=mx02.mail.icloud.com[17.42.251.12]:25, delay=851, delays=844/0.96/6.3/0, dsn=4.7.0, status=deferred (host mx02.mail.icloud.com[17.42.251.12] refused to talk to me: 550 5.7.0 Blocked - see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=82.64.206.161)

Là, je me rends compte que, potentiellement et si je lis bien, mon serveur cherche à envoyer des mails que je n'ai pas envoyé moi.

Je bondis aussitôt sur mon clavier et interroge sur le canal qui me sert de bouée de sauvetage à tous les coups : #debian-facile sur freenode. Rapidement, comme d'habitude, les conseils arrivent en la personne de vv222 (oui, je sais, le pseudo est bizrre mais la personne est a-do-ra-ble).

Il me préconise quelques commandes pour essayer de comprendre ce qui se passe à coup de grep sur le fichier de log /var/log/mail.log (qui semble vachement plus approprié que syslog au passage). J'en profite pour découvrir l'option -C de cet outil qui permet d'afficher n lignes avant et après la ligne trouvée par grep. C'est fort utile et ça me resservira, mais dans le contexte qui nous occupe, ça ne donne rien : Il semble en effet que la connexion n'a pas lieu juste avant.

Aucun souci, je fais alors un head sur ce même fichier et découvre une ligne que je trouve intéressante :

Dec 19 09:35:33 kepler postfix[1669]: Postfix is running with backwards-compatible default settings
Dec 19 09:35:33 kepler postfix[1669]: See http://www.postfix.org/COMPATIBILITY_README.html for details
Dec 19 09:35:33 kepler postfix[1669]: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"
Dec 19 09:35:35 kepler postfix/postfix-script[1733]: warning: symlink leaves directory: /etc/postfix/./makedefs.out
Dec 19 09:35:36 kepler postfix/postfix-script[1778]: starting the Postfix mail system
Dec 19 09:35:36 kepler postfix/master[1780]: daemon started -- version 3.4.14, configuration /etc/postfix
Dec 19 09:35:36 kepler postfix/qmgr[1782]: 301999C0647: from=<SRSO+yf09=Cw=pobox.com=ann@pobox.com>, size=545, nrcpt=50 (queue active)
Dec 19 09:35:36 kepler postfix/qmgr[1782]: 709199C6762: from=<SRSO+yf09=Cw=pobox.com=ann@pobox.com>, size=545, nrcpt=50 (queue active)
Dec 19 09:35:36 kepler postfix/qmgr[1782]: DF31B9C66BC: from=<foobar@mindiell.net>, size=40898, nrcpt=6 (queue active)
Dec 19 09:35:36 kepler postfix/qmgr[1782]: 74FFC9C09DD: from=<SRSO+yf09=Cw=pobox.com=ann@pobox.com>, size=545, nrcpt=50 (queue active)
Dec 19 09:35:36 kepler postfix/qmgr[1782]: 1AD6B9C664E: from=<SRSO+yf09=Cw=pobox.com=ann@pobox.com>, size=545, nrcpt=50 (queue active)

J'en déduis que le qmgr (Queue Manager a priori, je suis pas un expert hein) est en train d'envoyer des mails alors que le serveur vient de démarrer. Et j'arrête donc aussitôt le serveur à nouveau, au moins le temps de comprendre :

postfix stop

Je note également le compte foobar (foobar n'est pas le vrai nom hein) qui est potentiellement peu, voire pas du tout utilisé par son propriétaire.

Je cherche ensuite sur internet comment je peux vider la queue directement car de toute façon je n'ai clairement aucun mail en cours d'envoi. De même je comprends mieux pourquoi la réception de mes mails était aussi lente. Je tombe rapidement sur :

postsuper -d ALL
postsuper -d ALL deferred

Ces 2 commandes semblent faire le job : 47 messages supprimés. Je me dis également que 47 mails c'est pas énormé, mais je me souviens également que la plupart des commandes visualisées dans les logs sont bloquées :

Dec 19 09:35:43 kepler postfix/smtp[1877]: connect to 1757.com[104.160.174.173]:25: No route to host
Dec 19 09:35:43 kepler postfix/smtp[1798]: 5DBBC9C0D8D: host mx02.mail.icloud.com[17.57.154.7] refused to talk to me: 550 5.7.0 Blocked - see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=82.64.206.161
Dec 19 09:35:43 kepler postfix/smtp[1877]: 1AD6B9C664E: to=<anne1757@1757.com>, relay=none, delay=209929, delays=209923/2.7/3.8/0, dsn=4.4.1, status=deferred (connect to 1757.com[104.160.174.173]:25: No route to host)
--
Dec 19 09:35:43 kepler postfix/smtp[1839]: connect to 151.com[154.213.19.157]:25: Connection refused
Dec 19 09:35:43 kepler postfix/smtp[1798]: 5DBBC9C0D8D: host mx01.mail.icloud.com[17.57.154.23] refused to talk to me: 550 5.7.0 Blocked - see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=82.64.206.161
Dec 19 09:35:43 kepler postfix/smtp[1819]: connect to 1966.com[194.36.38.236]:25: Connection refused
--
Dec 19 09:35:43 kepler postfix/smtp[1878]: connect to 193.com[156.235.164.35]:25: Connection refused
Dec 19 09:35:43 kepler postfix/smtp[1798]: 5DBBC9C0D8D: to=<turd132@icloud.com>, relay=mx02.mail.icloud.com[17.42.251.12]:25, delay=851, delays=844/0.96/6.3/0, dsn=4.7.0, status=deferred (host mx02.mail.icloud.com[17.42.251.12] refused to talk to me: 550 5.7.0 Blocked - see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=82.64.206.161)
Dec 19 09:35:43 kepler postfix/smtp[1839]: 6E6CB9C00C4: to=<anne151@151.com>, relay=none, delay=210288, delays=210280/4.3/2.9/0, dsn=4.4.1, status=deferred (connect to 151.com[134.122.162.11]:25: Connection refused)
Dec 19 09:35:44 kepler postfix/smtp[1798]: 5DBBC9C0D8D: to=<tureengstrom@icloud.com>, relay=mx02.mail.icloud.com[17.42.251.12]:25, delay=851, delays=844/0.96/6.3/0, dsn=4.7.0, status=deferred (host mx02.mail.icloud.com[17.42.251.12] refused to talk to me: 550 5.7.0 Blocked - see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=82.64.206.161)
Dec 19 09:35:44 kepler postfix[1900]: Postfix is running with backwards-compatible default settings
--
Dec 19 09:35:44 kepler postfix[1900]: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"
Dec 19 09:35:44 kepler postfix/smtp[1798]: 5DBBC9C0D8D: to=<turk38k@icloud.com>, relay=mx02.mail.icloud.com[17.42.251.12]:25, delay=851, delays=844/0.96/6.3/0, dsn=4.7.0, status=deferred (host mx02.mail.icloud.com[17.42.251.12] refused to talk to me: 550 5.7.0 Blocked - see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=82.64.206.161)
Dec 19 09:35:44 kepler postfix/smtp[1886]: connect to 183.com[39.105.14.253]:25: No route to host
Dec 19 09:35:44 kepler postfix/smtp[1798]: 5DBBC9C0D8D: to=<turkeyman1959@icloud.com>, relay=mx02.mail.icloud.com[17.42.251.12]:25, delay=851, delays=844/0.96/6.3/0, dsn=4.7.0, status=deferred (host mx02.mail.icloud.com[17.42.251.12] refused to talk to me: 550 5.7.0 Blocked - see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=82.64.206.161)
Dec 19 09:35:44 kepler postfix/postfix-script[1906]: stopping the Postfix mail system

Je commence à entrevoir le pourquoi du comment de free. En réalité, mon serveur semble servir de boite à spam pour un petit rigolo d'où mes blocages de mails ces derniers temps. Ça me rassure un peu pour le monde et je m'attaque à la suite de l'enquête...

Premier réflexe après avoir relancé le serveur, je vérifie que plus aucun mail n'est envoyé. Et là, je me rends compte que quelqu'un (un bot clairement) se connecte via le fameux compte foobar et envoie des tripotées de mails...

Nouvel arrêt du serveur. Je change le mot de passe du compte, direct. Je relance le serveur : plus rien pour le moment... Voilà une bonne chose de faite. Enfin, quand je dis plus rien, je veux dire plus de mails envoyés, parce que niveau tentatives, y a du lourd :

Dec 19 16:01:19 kepler postfix/smtpd[4253]: connect from unknown[41.139.28.161]
Dec 19 16:01:19 kepler postfix/smtpd[4253]: lost connection after CONNECT from unknown[41.139.28.161]
Dec 19 16:01:19 kepler postfix/smtpd[4253]: disconnect from unknown[41.139.28.161] commands=0/0
Dec 19 16:01:28 kepler postfix/smtpd[4288]: connect from unknown[41.139.28.161]
Dec 19 16:01:28 kepler postfix/smtpd[4288]: lost connection after CONNECT from unknown[41.139.28.161]
Dec 19 16:01:28 kepler postfix/smtpd[4288]: disconnect from unknown[41.139.28.161] commands=0/0
Dec 19 16:01:38 kepler postfix/smtpd[4289]: connect from unknown[41.139.28.161]
Dec 19 16:01:38 kepler postfix/smtpd[4289]: lost connection after CONNECT from unknown[41.139.28.161]
Dec 19 16:01:38 kepler postfix/smtpd[4289]: disconnect from unknown[41.139.28.161] commands=0/0
Dec 19 16:02:46 kepler postfix/smtpd[4253]: connect from unknown[141.98.80.87]
Dec 19 16:02:50 kepler postfix/smtpd[4253]: warning: unknown[141.98.80.87]: SASL LOGIN authentication failed: authentication failure
Dec 19 16:02:51 kepler postfix/smtpd[4253]: lost connection after AUTH from unknown[141.98.80.87]
Dec 19 16:02:51 kepler postfix/smtpd[4253]: disconnect from unknown[141.98.80.87] ehlo=1 auth=0/1 commands=1/2
Dec 19 16:02:51 kepler postfix/smtpd[4288]: connect from unknown[141.98.80.87]
Dec 19 16:02:55 kepler postfix/smtpd[4288]: warning: unknown[141.98.80.87]: SASL LOGIN authentication failed: authentication failure
Dec 19 16:02:56 kepler postfix/smtpd[4288]: lost connection after AUTH from unknown[141.98.80.87]
Dec 19 16:02:56 kepler postfix/smtpd[4288]: disconnect from unknown[141.98.80.87] ehlo=1 auth=0/1 commands=1/2

Et puis, alors que je suis en train d'écrire ces lignes, ça revient (j'ai pas tout mis hein, j'ai surtout arrêté le serveur à nouveau) :

Dec 19 16:04:33 kepler postfix/smtpd[4288]: connect from 187-108-79-140.ip3.com.br[187.108.79.140]
Dec 19 16:04:36 kepler postfix/smtpd[4288]: 35F6F9C0257: client=187-108-79-140.ip3.com.br[187.108.79.140], sasl_method=PLAIN, sasl_username=foobar@mindiell.net
Dec 19 16:04:40 kepler postfix/cleanup[4294]: 35F6F9C0257: message-id=<EEA46F07-A575-111D-045D-0AFCA250275E@mindiell.net>
Dec 19 16:04:41 kepler postfix/qmgr[4241]: 35F6F9C0257: from=<foobar@mindiell.net>, size=41023, nrcpt=7 (queue active)
Dec 19 16:04:43 kepler postfix/smtpd[4288]: 223789C0259: client=187-108-79-140.ip3.com.br[187.108.79.140], sasl_method=PLAIN, sasl_username=foobar@mindiell.net
Dec 19 16:04:44 kepler postfix/smtp[4298]: 35F6F9C0257: to=<millerbob422@gmail.com>, relay=gmail-smtp-in.l.google.com[66.102.1.27]:25, delay=8.5, delays=5.4/0.03/0.63/2.4, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[66.102.1.27] said: 550-5.7.1 [82.64.206.161       7] Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked. Please visit 550-5.7.1  https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1  for more information. v7si10368820wmb.142 - gsmtp (in reply to end of DATA command))

Ok, il reste un problème, le compte continue d'essaye d'envoyer des mails et le bot arrive à s'y connecter. Il me faut comprendre la première ligne importante, celle avec sasl bla bla. Direction les internets...

Solutionnage (c'est pas français, mais je suis chez moi ici, na)

Bon, un rapide coup d'oeil côté documentation de postfix explique l'intérêt du SASL. Ça permet à un ordinateur de se connecter au serveur et de récupérer les droits liés au réseau. En gros, je n'autorise que certaines adresses IP à envoyer des mails (uniquement celle du serveur donc) :

# Liste des adresses IPs autorisées à envoyer du courrier
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

C'est une protection de base (si j'ai bon souvenir) pour éviter que n'importe qui puisse utiliser mon serveur de mail. Le souci, c'est que là, même moi sur le réseau local, je peux pas envoyer de mail (prévenez-moi si je me goure hein...).

J'ai donc paramétré (apparemment, ou alors c'est par défaut) la possibilité de se connecter via SASL :

# SASL parameters
smtpd_sasl_local_domain = 
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination
smtpd_tls_auth_only = no

Premier point, je sais que lorsque je me connecte à mon mail, j'utilise le protocole IMAP, mais ce n'est a priori que pour le consulter. En effet, après vérification scientifique, pour envoyer un mail, mon client se connecte en utilisant l'authentification SASL et ça parait plutôt logique :

// Ici je lance mon client : connexion IMAP pour lire les mails
Dec 19 16:22:54 kepler imapd: Connection, ip=[::ffff:192.168.0.254]
Dec 19 16:22:54 kepler imapd: Connection, ip=[::ffff:192.168.0.254]
Dec 19 16:22:54 kepler imapd: LOGIN, user=moi, ip=[::ffff:192.168.0.254], port=[52714], protocol=IMAP
Dec 19 16:22:54 kepler imapd: /etc/courier/shared/index: Permission denied
Dec 19 16:22:54 kepler imapd: LOGIN, user=typematrix, ip=[::ffff:192.168.0.254], port=[52716], protocol=IMAP
Dec 19 16:22:54 kepler imapd: /etc/courier/shared/index: Permission denied
Dec 19 16:22:54 kepler imapd: Connection, ip=[::ffff:192.168.0.254]
Dec 19 16:22:54 kepler imapd: Connection, ip=[::ffff:192.168.0.254]
Dec 19 16:22:54 kepler imapd: LOGIN, user=moi, ip=[::ffff:192.168.0.254], port=[52726], protocol=IMAP
Dec 19 16:22:54 kepler imapd: LOGIN, user=moi, ip=[::ffff:192.168.0.254], port=[52728], protocol=IMAP
// Ici j'essaye d'envoyer un mail, donc connexion via protocole SMTP et donc SASL avec un peu de TLS tout de même
Dec 19 16:23:07 kepler postfix/smtpd[4584]: connect from unknown[192.168.0.254]
Dec 19 16:23:07 kepler postfix/smtpd[4584]: Anonymous TLS connection established from unknown[192.168.0.254]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Dec 19 16:23:07 kepler postfix/smtpd[4584]: 780CA9C0257: client=unknown[192.168.0.254], sasl_method=PLAIN, sasl_username=moi

Donc, je ne peux pas juste débrancher le SASL et continuer ainsi. C'eût été trop simple et l'informatique n'est jamais si simple... On va donc tâcher de comprendre et mieux configurer ce machin un peu SA(S)LE (ah ah ah).

Déjà, les lignes de la configuration doivent être expliquées :

  • smtpd_sasl_auth_enable = yes : Bon, là j'autorise le SASL, je peux pas m'en passer a priori. Je laisse

  • broken_sasl_auth_clients = yes : Ça c'est pour permettre à de vieux clients de pouvoir s'authentifier quand même. Dans le doute, je vais le mettre à no, mon client est à jour.

  • smtpd_sasl_type : Je n'ai pas cette option, donc mon serveur utilise l'implémentation appelée Cyrus SASL. Ça semble être un bon truc (l'avantage d'utiliser Postfix), je touche pas.

  • smtpd_sasl_security_options = noanonymous : Alors, ça c'est pour gérer les options de sécurité. Il y en a plusieurs. Là, j'interdis les accès anonyme (ça me semble la base, et c'est peut-être le cas). Mais il est aussi possible d'interdire l'authentification "plain", c'est à dire en texte clair sur le réseau. Pas sûr que ça soit le souci, mais on peut essayer. Ne pas oublier non plus que je me connecte à mon mail uniquement depuis mon réseau interne, donc ça devrait pas être complètement risqué, mais bon, au point où j'en suis. On voit d'ailleurs que je me connecte actuellement avec ce mode là, je testerai plus tard donc (procrastination mon amour).

  • smtpd_tls_auth_only = no : Cette option permet de fournir l'accès SASL uniquement après mise en place d'une session TLS. Je tente ça pour voir... Je peux encore envoyer des messages, donc c'est pas mal. J'attends un peu pour voir si la connexion extérieure se fait à nouveau (oui, c'est du direct). A priori, pas mal de connexions basiques pour tenter de faire du relais et pas de manière aussi forte qu'avec le bot. Après 15 minutes à attendre (et à manger, parce qu'on se refait pas), le bot semble ne plus se connecter au compte.

  • smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination : Cette option permet donc à des clients d'utiliser le serveur pour en envoyer (pas juste pour en déposer); limite ça aux réseaux listés par ailleurs; et rejette des destinations inconnues.

Analyse du piratage

Ainsi donc, on peut dire que c'est en grande partie ma faute tout ce bousin et la perte de temps de mon après-midi de week-end. Pour autant j'ai aussi appris quelques trucs :

  • Si ça ne marche pas, il y a de fortes chances que ça soit ta faute
  • Sécuriser, ça mange pas de pain
  • Ne pas laisser des comptes inutilisés sans protection
  • Ne pas laisser un serveur sans surveillance

Je suis également aller faire un tour sur le répertoire Maildir du compte piraté. Celui-ci contient les mails envoyés et je peux donc voir tout le bazar en place. Si je regarde mon propre compte, le répertoire new contient 0 mail. Celui du compte piraté : plus de 17000... Ça veut tout dire.

D'après ce que je vois, les envois en masse ont commencé le 26 novembre à 1h du matin. Forcément, j'ai une fâcheuse tendance à dormir à cette heure-là.

La suite

J'ai jeté un oeil aux mails envoyés, il s'agit de spam bête et méchant, voire de phishing. Mon serveur a donc servi de zombie pendant quelques semaines. Il me reste maintenant à rétablir la confiance envers les différents acteurs de mails, heureusement les messages de rejets sont explicites et des liens sont donnés pour permettre aux gens de sortir de l'impasse.

Je vais également supprimer le compte ciblé afin de limiter tout risque par la suite, mais je pense que son mot de passe n'était pas suffisamment solide et surtout pas modifié depuis un moment (hmm, 4 ans ?).

Je tâcherai de parler du dé-black-listage et des techniques de surveillance du serveur de mail dans un prochain billet, là j'ai besoin de faire une pause et puis je sens que ça va encore me prendre du temps et que je trouverai bien une raison de procrastiner un peu plus à ce sujet...