Mon serveur s’est mis à envoyer des mails en masse (du spam). Je l’ai su par deux côtés :
Un mail envoyé à une adresse gmail et qui est revenu, avec le message suivant :
This is the mail system at host domain.tld.
I’m sorry to have to inform you that your message could not be delivered to one or more recipients. It’s attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can delete your own text from the attached returned message.
The mail system exemple@gmail.com: host gmail-smtp-in.l.google.com[66.102.1.26] said:
550-5.7.1 [mon adresse IP] Our system has detected an unusual rate of 550-5.7.1 unsolicited mail originating from your IP address. To protect our 550-5.7.1 users from spam, mail sent from your IP address has been blocked. 550-5.7.1 Please visit 550-5.7.1 https://support.google.com/mail/?p=UnsolicitedIPError to review our 550 5.7.1 Bulk Email Senders Guidelines. k2si4511964wmf.87 - gsmtp (in reply to end of DATA command)
En cherchant, on a trouvé 3 processus louches, qui s’appelaient juste “proc”, et qui tournait avec le user “wordpress”. On n’a pas réussi à trouver le fichier qui lance ce processus. Par contre on les a stoppés et à priori ça a stoppé l’envoi des spams : en écoutant sur le port 25, on avait beaucoup de trafic et on n’en a presque plus (il correspond maintenant à notre usage du mail).
Par contre je suppose qu’il y a encore quelque chose qui traîne quelque part qui pourrait les relancer, et j’aimerais bien trouver ce que c’est. À priori c’est le site sous wordpress qui s’est fait infecter, comme ça m’était déjà arrivé ([Resolu] Virus sur wordpress pas à jour), sauf que maintenant je les maintiens bien à jour.
Donc si quelqu’un a une piste, une idée de comment chercher ça, je suis preneur…
Hm ben c’est un peu dur de diagnostiquer le truc comme ça… Si les process qui tournaient étaient liés à wordpress, alors c’est surement spécifique à Wordpress.
Après, tu peux investiguer un peu plus du côté des logs pour voir quel utilisateur envoyait exactement des mails (e.g. le header From:) et voir si il n’y a pas une politique qu’on pourrait rajouter dans postfix ou rspamd pour limiter ces abus mais bon…
Le soucis c’est que ton serveur apparait comme compromis.
À moins de déterminer exactement ce qui est en est la cause,
ET l’ampleur (jusqu’à un accès root possiblement).
En attendant il faudrait fermer les ports smtp 25 et 465 ou désactiver postfix, et comme l’a indiqué captain faire un check au niveau des logs:
nano /var/log/mail.log
Mais bon… moi je considérerais à ta place l’éventualité de refaire une installation. Comment être sûr que ce qui t’a infecté n’a pas aussi fait le ménage derrière toi?
À voir si quelqu’un viendra t’aider davantage.
Bon courage
Oui enfin il faut relativiser un peu Certes on peut se poser la question de la taille de la compromission, mais si l’accès root avait été compromis (ce qui est quand même autre chose que de trouver une “faille” pour envoyer des spams via php), ben, justement, se faire remarquer en envoyant quelques bêtes spams est pas la tactique la plus judicieuse pour l’attaquant…
Après la question de réinstaller/pasréinstaller dépends du modèle de menace et de à quel point le serveur et les données qu’il contient sont critiques.
Quelques détails en plus:
Le processus qui faisait tourner un programme nommer “proc” était exécuté avec PERL, donc à priori “proc” était écrit en PERL.
Il tournait effectivement uniquement avec l’utilisateur wordpress, ce qui laisse supposer qu’il n’a pas été possible de faire une élévation de privilège. Ceci dit on ne peut pas en être certains à 100%.
Couper les port mail n’est pas évident en l’occurence car le serveur en question héberge des mails. Là on s’aperçoit que la combinaison serveur mail / serveur web n’est pas toujours évidente. Ceci dit c’est ce qui a permit de déterminer qu’il y avait compromission.
On a pas trouvé de trace dans les logs des fameux mails envoyés, on suppose donc que “proc” envoyait lui même les mails via le port 25.
Je pense qu’ajouter une régle “–match owner” dans iptables pour éviter que l’utilisateur wordpress puisse ouvrir un port vers l’exterieur serait une bonne idée sur le plan défensif (ça pourrait être rajouté à l’app).
Il y aurait sans doute des choses à faire avec selinux (mais j’en ai déjà mal au crane). Chrooter spécifiquement wordpress serait aussi une bonne idée.
On devrait sans doute ajouter un avertissement sur l’app wordpress, c’est quand même un vecteur d’infection important.
Pour info, j’ai vu aujourd’hui en écoutant le port 25 via cette commande (ça peut servir à d’autres) :
tcpdump host 89.234.140.166 and port 25 -i tun0 -n
que le serveur envoyait de nouveau des spams (en tout cas beaucoup de trafic sur le port 25). Cette fois j’ai trouvé 2 processus qui s’appelaient “bash” et tournaient toujours sous le user wordpress. Les tuer a arrêté l’envoi de spam.
J’ai toujours pas pris le temps de désinstaller/réinstaller proprement le site, mais il va falloir je crois…
Ce qui est bizarre, c’est que je n’ai pas vraiment été blacklisté en fait… J’ai toujours 10/10 sur mailtester, gmail accepte de nouveau mes mails…
Peut-être que je l’ai repéré assez vite pour l’interrompre avant d’être blacklisté.
Suite de l’histoire (et fin j’espère) :
J’ai désinstallé l’app wordpress responsable, tuer les processus et supprimé l’utilisateur et rebooté. Ensuite j’ai réinstallé wordpress, et j’ai de nouveau trouvé des processus qui envoyé du spam avec l’utilisateur wordpress.
En cherchant, on a trouvé un fichier wordpress dans /var/spool/cron/crontabs, qui contenait ça :
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/var/tmp/GCwKLZYUey3 installed on Fri Jul 28 12:18:22 2017)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
*/10 * * * * /var/tmp/GCwKLZYUey >/dev/null 2>&1
Et le fichier dans /var/tmp/GCwKLZYUey est un binaire assez illisible… qui à priori lançait des processus qui envoyaient du spam.
Certes on peut se poser la question de la taille de la compromission, mais si l’accès root avait été compromis (ce qui est quand même autre chose que de trouver une “faille” pour envoyer des spams via php), ben, justement, se faire remarquer en envoyant quelques bêtes spams est pas la tactique la plus judicieuse pour l’attaquant…