Détection spam VPS

Et avec les messages ids ? rien dans les logs de postfix ?

Votre serveur est à jour ?
Tous les CMS dessus aussi ?
Aucun site piraté ?

Non rien dans les logs.
Le serveur est à jour ainsi que les CMS. Aucun site piraté à priorité. En tout cas l'analyse des logs httpd n'ont rien donnés...

Non rien dans les logs.
Le serveur est à jour ainsi que les CMS. Aucun site piraté à priorité. En tout cas l'analyse des logs httpd n'ont rien donnés...

Ce qui est sûre : quand c'est postfix qui envoi le mail, l'IP 'destination' figure dans les logs.
Donc, si cet IP '65.20.x.49' n'est pas présent, vous avez une preuve formelle que ce n'est pas postfix qui les a envoyé.

Reste le cas: 99 % que qu'un de vos sites est contaminé, le fait que les sites / CMS sont à jour n'est pas une garanti que des fichiers tiers existent qui peuvent envoyer des mails sans passer par postfix.
Soit : rare mais ça existe : vous avez carrément un sorte de programme autonome - une sorte de trojan - qui transmet des mails directement.

Une méthode très simple (mais très radical) : arrêter votre serveur web (apache2, nginx). Il y a fort à parier que votre serveur ne envoi plus des spams.
Un poil lus compliqué est de consulter le doc de PHP : il existe un paramètre dans le php.ini qui vous donne la possibilité de logger toutes les mails qui ont été envoyé par la fonction mail(). Si les mails viennent d'un de vos sites, vous les voyez (mais bon, dans ce cas, ils seront aussi loggé dans le mail.log de postfix).

Attention : le souci n'est pas à prendre à la légère. Au bout de X blocages pour envoi des spams, votre IP ne pourrait plus envoyer des mails - à vie. Ce qui vous oblige à quitter votre VPS pour en prendre un autre.

Merci beaucoup pour cette réponse.
Je vais pouvoir tester tout cela!

Je reviens vers vous car je n'ai toujours pas trouver de solution.
J'ai stoppé httpd et postfix et toujours mon serveur est toujours détecté.
J'ai fais un clamscan pour vérifier si j'avais des malwares, tout est ok de ce côté là.

OVH ne me donne aucune infos supplémentaires...

Bonjour,

Est-ce que les spams partent à intervalle régulier?

Si oui, est-ce possible de passer le serveur en rescue pour voir si cela continue?

Car si cela continue continue c'est qu'il y a un problème de détection côté OVH.

Si cela s'arrête votre serveur est infecté plus en profondeur que prévu et il faudrait examiner tous les logs et penser à passer par une réinstallation/sécurisation/remise des données et si cela recommence après tout ça, c'est qu'une backdoor est présente dans vos fichiers et/ou vous avez réutilisé les même MDP.

Cordialement, janus57

Bonjour Janus57,

Merci pour cette réponse. Les spams semblent tout le temps partir.

Quand je fais un telnet sur le port 25 ou 587, je n'ai rien...
Est ce que les emails passent tous par Postfix forcément? Car le serveur est détecté aussi quand je désactive le service Postfix et aucune trace des spams dans /var/log/maillog...

Le seul point que je vois c'est dans le résumé de logwatch :
1449 *Warning: Pre-queue content-filter connection overload
1833 SASL authentication failed
669 Miscellaneous warnings

15.922M Bytes accepted 16,695,197
8.411M Bytes delivered 8,819,849
======== ================================================

112 Accepted 52.83%
100 Rejected 47.17%
-------- ------------------------------------------------
212 Total 100.00%
======== ================================================

27 Reject unknown user 27.00%
73 Reject milter 73.00%
-------- ------------------------------------------------
100 Total Rejects 100.00%
======== ================================================

Est ce que vous auriez une piste car je n'arrive pas à aller plus loin ?

Cordialement,
Loic

Bonjour,

Est ce que les emails passent tous par Postfix forcément?

non, comme dit plus haut ça peut être un script PHP voir autre qui a été mis sur le serveur et envoie les mails autrement que par votre serveur mail local.

Il faut faire le test dans l’ordre à savoir :
1 - désactiver le serveur mail
2 - si cela continue, désactiver le serveur
3 - passer en rescue (pour couper l'envoie de spam) et analyser les logs au moment de la première détection pour voir les actions qui ont été effectué le jour là et les jours précédents.

Par contre si une fois le serveur mis en rescue les spams continue là y a un problème de détection.

Sinon l'autre moyen, transférer le site sur un nouveau serveur, serveur qui aura été configuré "à la main" (sans utiliser un backup du premier sauf pour les données du site comme la base SQL).

Cordialement, janus57

Est ce que les emails passent tous par Postfix forcément? Car le serveur est détecté aussi quand je désactive le service Postfix et aucune trace des spams dans /var/log/maillog...

la détection ne se fait pas en temps réel.
Une fois qu'OVH bloque le serveur car il a envoyé des spams, il est flaggué "bloqué" pendant un bon moment..

Après, il y a un méthode simple de vérifier. Est-ce que le serveur envoie des mails ? Est-ce que vous êtes à l'origine des mails ?
Il faudrait lire tous les logs qui concernent les mails.

Bonjour,

J'ai eu exactement le même problème et voici comment je m'y suis pris :
Il s'agit peut-être d'un serveur mail monté en mémoire, non journalisé.

Tout d'abord, on liste les services utilisant le port 25
$ lsof -i tcp:25

On va pouvoir vérifier si il n'y a pas un process suspect et en vérifier l'origine
$ lsof -Pnp

Ensuite, on tue les process qui posent souci soit par id
$ kill -9

soit par nom
$ pkill -9

également vérifier s'il n'y a pas des tâches CRON créées

$ cd /var/spool/cron/
$ cat *

Enfin, essayer de trouver l'origine de l'infection (souvent un webshell uploadé grâce à un plugin défaillant)

Bonjour Michael,

Merci, je crois avoir une piste !
J'ai en effet deux services suspects :
fs 10338 apache 3u IPv4 566799844 0t0 TCP vps.monserveur.fr:37494->77.72.83.83:smtp (SYN_SENT)
fs 10339 apache 3u IPv4 566800290 0t0 TCP vps.monserveur.fr:60205->77.72.83.84:smtp (SYN_SENT)

Voilà ce que me donne la liste des process :
fs 10338 apache cwd DIR 8,1 4096 2 /
fs 10338 apache rtd DIR 8,1 4096 2 /
fs 10338 apache txt REG 8,1 7184 16972 /usr/bin/perl
fs 10338 apache mem REG 8,1 21056 18269 /usr/lib64/perl5/auto/File/Glob/Glob.so
fs 10338 apache mem REG 8,1 120008 24852 /usr/lib64/perl5/auto/POSIX/POSIX.so
fs 10338 apache mem REG 8,1 17976 17104 /usr/lib64/perl5/auto/Fcntl/Fcntl.so
fs 10338 apache mem REG 8,1 25624 24834 /usr/lib64/perl5/auto/Socket/Socket.so
fs 10338 apache mem REG 8,1 19336 24768 /usr/lib64/perl5/auto/IO/IO.so
fs 10338 apache mem REG 8,1 99170352 458814 /usr/lib/locale/locale-archive
fs 10338 apache mem REG 8,1 10312 524325 /lib64/libfreebl3.so
fs 10338 apache mem REG 8,1 1924768 524326 /lib64/libc-2.12.so
fs 10338 apache mem REG 8,1 143280 524471 /lib64/libpthread-2.12.so
fs 10338 apache mem REG 8,1 15056 524479 /lib64/libutil-2.12.so
fs 10338 apache mem REG 8,1 40872 524398 /lib64/libcrypt-2.12.so
fs 10338 apache mem REG 8,1 596864 524501 /lib64/libm-2.12.so
fs 10338 apache mem REG 8,1 20024 524453 /lib64/libdl-2.12.so
fs 10338 apache mem REG 8,1 113904 524502 /lib64/libnsl-2.12.so
fs 10338 apache mem REG 8,1 111440 524506 /lib64/libresolv-2.12.so
fs 10338 apache mem REG 8,1 1485896 17165 /usr/lib64/perl5/CORE/libperl.so
fs 10338 apache mem REG 8,1 159312 526378 /lib64/ld-2.12.so
fs 10338 apache mem REG 8,1 142879 49403 /usr/share/locale/fr/LC_MESSAGES/libc.mo
fs 10338 apache mem REG 8,1 26060 33278 /usr/lib64/gconv/gconv-modules.cache
fs 10338 apache 0r CHR 1,3 0t0 3817 /dev/null
fs 10338 apache 1w CHR 1,3 0t0 3817 /dev/null
fs 10338 apache 2w CHR 1,3 0t0 3817 /dev/null
fs 10338 apache 3u IPv4 566999301 0t0 TCP MONIP:41852->77.72.83.83:25 (SYN_SENT)
fs 10338 apache 4w FIFO 0,8 0t0 436210619 pipe
fs 10338 apache 5r FIFO 0,8 0t0 436210620 pipe

Bizarre non?

Tous tes sites tournent sous le user "apache" ?
Si oui, cela ne va pas faciliter la recherche...

Oui c'est tout bon. J'ai tué le process et nettoyer les fichiers en question.
Merci bcp en tout cas ! Tu m'as pas sauvé la vie mais pas loin :-)

"apache" n'est qu'un serveur web. Autrement dit : il va envoyer es fichiers sur ton serveur vers le navigateur qui demande ces fichiers. « Les fichiers » ici, c’est ton site web.
Dès son installation, il saura faire pas grand-chose que montrer un page de Bienvenue, si un navigateur lui demande.
Peu après, un "site" va être mise en place. Ce site n'est presque jamais une collection des pages html et css (donc quasi sans risque), mais des scripts PHP, perl, java et autre. Pas de problème pour Apache, il va lancer l’interpréteur concernant (PHP, perl, etc).
Et c'est là où ça se gâte.
Très souvent, un visiteur mal intentionné découvre vite quelles scripts que t'as déposé sur ton site, et il connaît les failles. La faille le plus connu est lui qui permet le visiteur de « uploader » des scripts à lui. "Uploader" donc déposer CES fichiers script sur TON site. Puis il 'visite' ce script avec son navigateur, et ça lui permet d'exécuter des (ces !) fonctions PHP sur ton serveur. Quelques secondes plus tard il aura aussi uploadé une liste des adresses mail, et un copie d'un message spam, et go .... ton serveur web commence à relayer ces messages.
Le script malveillant de ce visiteur ne va pas utiliser le serveur mail qui se trouve sur ton serveur - qui pourrait être présent, ou même pas ! Il va envoyer des messages directs vers les destinataires.
Ça fonctionne bien comme ça depuis de décennies.
Ce qui est arrivé sur ton serveur.

C'est pour ça que je te demande de couper ton serveur web (donc : toutes tes sites aussi). La transmission des mails va s'arrêter aussi sec.

Pour combattre la contamination, inutile de démarrer le serveur dans mode rescue.
Ajoute simplement un règle parafeur qui interdit le "TCP - destination porte 25" et plus aucun mail sortira. Puis, avec les outils mentionnés plus haut tu trouveras rapidement les fichiers concernant qui

Exemple : un site basé sur WordPress - et uniquement Wordpress sans aucun extension ni plugin, risque pas grand-chose. Mais hélas, comme les PC's et les smartphones, les gens n’arrêtent pas d'inclure des extensions, applications etc. Il faut UN faille dans un de ces apps et c'est foutu.
N’oublie pas ! WordPress (encore une fois, il ne s'agit qu’un exemple) est plutôt très sûr. Mais le même garantie n'est pas valable pour ces extensions qui peuvent être écrit par n'importe qui. Certains auteurs sont des vrais expert, et leur qualité de code est excellent - d'autre, c'est du médiocre voir pire.

Comme c'est dit plus haut, le blocage des spams ne fonctionne pas en temps réel. Et une fois ton serveur bloqué pour émission des mails, le moment que tu puisses débloquer va être prolongé à chaque blocage. Au bout de quelques fois OVH a compris que tu gère mal les choses, et il sera impossible de débloquer. Il faut bien comprendre : OVH s'en fout complétement que t'as pas des notifions de sécurité, que tu sache pas où regarder pour voir si les scripts t'as utilisé sont sur, ou pas.
Simplement : t''es responsable pour les scripts que tu utilises - et ceci est valable si t'es l'auteur, ou pas.

Je te conseille donc ceci : en cas de doute, n'installe RIEN sur ton serveur.
Tu vas me dire : mais, hé, ho, je ne sais pas lire, voir comprendre, ce perl, PHP, etc. Pas grave : dans ce cas, n’utilise que ce qui est connu pour **hyper sur**, comme WordPress, et s'il te faut des extensions, sélectionné QUE ceux qui ont une suivi permanente, avec des milliers d'utilisateur connus, et un très bon support et suivi. Évite les extensions que presque personne utilise, qui n'ont pas été mise à jour depuis des mois (années). Des auteurs peu connu, etc.

PS: un serveur lancé en mode rescue ne pourrait pas envoyer des mails. Dans ce mode, un noyau d'OVH est utilisé, et ton disque dur n'est pas lu ni vu. Le disque n'est même pas "mounté" au démarrage. T'auras un login pas SSH (disons que c'est un app sur ^^) et basta : pas de serveur web, ni mail, rien. Aucun programme est démarré, sauf les processus de base pour faire tourner le kernel sur ton dédié.

PS2 : Hors sujet : mais : oubli logwatch.
T'as un serveur postfix. T'es donc **obligé de lire** son ficher log (/var/mail/log) de A à Z. C'est uniquement ainsi que trouve des linges classiques, les warnings et les erreurs.
Les warnings, pas bien grave mais tu dois comprendre la signification chaque warning puis trouver une solution, ou l'accepter dans un cas extrême (j'en ai très peu ou pas).
Jamais des erreurs.

Moi, je ne l'inspecte plus mes logs chaque jour (250 mails sortent / entrant chaque jour) mais de temps en temps je pars à la chasse de ce perle rare qui pourrait déceler un soucis avec un boite mail, domaine, SSL (certificat) etc. Puis je utilise ceci https://www.1domaine.fr/munin/papy-team.org/www.papy-team.org/index.html#postfixdomaine.fr/munin/papy-team.org/www.papy-team.org/index.html#postfix car ces graphs peuvent me dire très rapidement s'il y un changement suspect sur mon serveur.

Bonjour

J'ai le même souci , cependant dans les logs , je n'ai que mes mails que j'envoi pour le fonctionnement du site .... Mon site est un site de rencontre amicale , il faut que je puisse informer les membres des éventements .....

Il apparait que ovh soyoustart bloque les envois de emails sans discernement ...
j'ai envoyé 200 mails et je suis bloqué ...

Lorsque j'ai acheté la location du serveur ( 50 euros par mois ) je n'ai pas été averti de telles conditions .....

Sans solutions , bé , je vais changer d'hébergeur ..... Flute quoi , je paye et j'ai pas le service !


Soyoustart m'envoit bien des messages ,
- on vient de se connecter
- voici votre facture
- maintenance
- ou encore plus rarement de la pub ...

C'est fait ce que je dis , pas ce que je fais