[arnaken]

En fait, le fichier maillog est vide (et ça fait un moment que ça dure), est-ce que ça pourrait être un signe de hack ? Si oui, comment réactiver le log de postfix ?

[Nowwhat]

Bonjour,

D'abord un test qui va t'aider à comprendre d’où ils viennent ces spam, transmis ensuite par postfix:

Coupe immédiatement votre serveur web (yep : Apache).
Vidange complète du queue de postfix, puis "tail" (exemple : tail -f /dossier/mail.log) le log de postfix.

Des nouveau mails spam sont ajoutés ?

[arnaken]

Bonjour,

Je déterre un petit peu ce post car j'ai un problème similaire sur mon serveur, à savoir des gens malveillants qui l'utilisent pour envoyer du spam via postfix.

Déjà, les symptomes :
De nombreux mails partent via postfix avec comme from un identifiantquelconque@monserveur.com. Les headers ressemblent tous à ça :
from mail.monserveur.com (node-33i.pool-125-27.dynamic.totbb.net [125.27.15.174]) by monomdeserveur (Postfix) with ESMTPSA id 6F79BA976C; Thu, 7 Jan 2016 13:51:07 +0100 (CET)

A noter que je suis en release 3 d'OVH avec tous les paramètres par défaut (jusqu'à présent).

Je vous explique un peu mes actions jusqu'à présent :
1. J'ai réussi à "contenir" les mails de spam dans ma queue en activant l'option postfix "Use SASL SMTP authentication?" Yes
Le problème est que tous mes mails sortants sont bloqués par cette action, donc c'est une solution forcément temporaire

2. J'ai essayé de modifier les paramètres postfix pour filtrer les mails du type identifiantquelconque@monserveur.com en faisant ceci :
- Activation de "Allow connections from same network "
- Activation de "Allow authenticated clients"
- Activation de "Reject email to other domains"
- Activation de "Reject anonymous logins "
- Activation de "Require SASL SMTP authentication"
- Dans smtpd_sender_restrictions, j'ai mis "check_sender_access hash:/etc/postfix/sender_access"
- Dans le fichier sender_access, j'ai mis :
webmaster@monserveur.com OK (c'est la seule adresse utilisée pour l'envoi de mails)
monserveur.com REJECT

Le spam opère comme s'il passait "au-dessus" des paramètres postfix, comme si ça ne lui faisait rien. J'ai mis par exemple des valeurs bidons à mynetworks et j'étais bien bloqué pour l'envoi d'emails, en revanche les spams continuaient d'arriver dans la queue postfix...

3. J'ai testé rkhunter et la solution préconisée ci-dessus, tout semble normal, et aucun fichier php n'est utilisé lors de la création des mails spam (/tmp/wrapsendmail.log reste vide)

4. J'ai testé monserveur.com via les mxtools pour vérifier que mon serveur n'est pas en open relay et ce n'est pas le cas :
220 monserveur.com ESMTP Postfix [719 ms]
EHLO PWS3.mxtoolbox.com
250-monserveur.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN [719 ms]
MAIL FROM:
250 2.1.0 Ok [719 ms]
RCPT TO:
554 5.7.1 : Relay access denied [719 ms]

Je n'ai donc plus qu'un espoir : me tourner vers vous. Qu'est-ce que j'ai loupé ? Comment arrêter l'hémorragie ? Merci pour votre aide.

[TBC_Ly0n]

Si ce sont des spams entrants, c'est la conf du serveur à revoir.
Si ce sont des spams sortants, il faut analyser précisément les entêtes afin de savoir quel compte spamme, voire quel script le fait.
Ca se fait assez facilement sur une Debian; Pour les autres OS, à voir comment ils sont paramétrés.

[Hotcmel]

Je deterre un peu ce topic afin de savoir comment tu t y ais pris pour regler ton probleme car j ai le meme soucis que toi sauf que moi j ai desactivé qmail

[causta]

Bonjour,
merci beaucoup pour cette information très précieuse, j'ai mis ça en place, plus qu'à attendre, je vous tiendrais au courant.
Très bon weekend,
Léandre

[cassiopee]

D'après l'entête du spam, l'UID qui a émis le message est 33.

Dans une Debian cela correspond par défaut à l'utilisateur "www-data"
donc cela oriente vers un script PHP.

Ça peut être un script PHP faillible (type formulaire de contact),
mais ça peut aussi être un script PHP uploadé par le pirate/spammeur
(par exemple suite à une faille dans un WordPress, Joomla, etc.)
et qui permet toutes sortes de fonctions dont, entre autres, le spam.

Afin de savoir quel est le script en question, tu peux utiliser
la manip suivante :

dans le php.ini, remplacer :

sendmail_path = /usr/sbin/sendmail -t -i

par

sendmail_path = /usr/bin/wrapsendmail.pl -t -i

et relancer Apache.

Le contenu du fichier "wrapsendmail.pl" à placer dans "/usr/bin" :

#!/usr/bin/perl
#
# Wrapper to sendmail calls from PHP's mail()
#
# Configure sendmail_path in your php.ini to point to this script,
# and touch and chmod 777 /var/log/wrapsendmail.log
#
# It logs some information about page calling mail(), and after that
# calls the real sendmail binary.
#
# I think this script is public domain.
#

use Env;

my $date = `date`;
chomp $date;

open (INFO, ">>/tmp/wrapsendmail.log") || die "Failed to open file ::$!";
my $uid = $>;
my @info = getpwuid($uid);
my $datos = "\n";
my $mailprog = '/usr/sbin/sendmail';
foreach  (@ARGV)
{
         $arg="$arg" . " $_";
}

if ($REMOTE_ADDR)
{
        print INFO "$date - $REMOTE_ADDR ran $SCRIPT_NAME at $SERVER_NAME :: $arg\n";
}
else
{
                print INFO "$date - $PWD -  @info  :: $arg\n";
}


open (MAIL,"|$mailprog $arg") || die "cannot open $mailprog: $!\n";
while ()
{
        $datos="$datos" . " $_";
        print MAIL;
}
my $str = substr($datos,0,70);
if ($REMOTE_ADDR)
{
        print INFO "***********************\n$date - $REMOTE_ADDR ran $SCRIPT_NAME at $SERVER_NAME :: $arg\n";
}
else
{
        print INFO "***************************************************\n$date - $PWD -  @info  :: $arg :: $str \n";
}

close (INFO);
close (MAIL);

# EOF

A noter qu'on m'a signalé que ce script pouvait entrainer une surcharge CPU
en cas de grosses pièces jointes, donc il ne faut l'utiliser que le temps
de trouver le script PHP fautif et ensuite revenir à la configuration normale.

Dans le fichier de log "/tmp/wrapsendmail.log" tu trouveras une entrée
pour chaque message émis depuis un script PHP, avec, entre autres
informations, le nom du script PHP émetteur.

[causta]

ça c'est le site d'un de mes clients, justement il apparait souvent dans les logs de spam, j'avais demandé à ce client de verrouiller tous ses formulaires de contact pendant une semaine et le problème continuait ...

l'ip c'est l'ip d'un de mes serveurs oui, j'en ai deux avec une ipfailover par dessus. L'ip du serveur est donc normalement invisible pour le client.

[la_flegme]

salut

http://www.reactic.fr/

c'est ton domaine ?

176.31.99.68

c'est ton ip ?

[causta]

Bonjour à tous,

cela fait plus de 2 ans que j'ai des serveurs chez OVH/
J'ai dû déménager mes serveurs sur des nouveaux serveurs en Février.

Réinstallés quasiment à l'identique, différences : debian 6 au lieu de débian 5 et le kernel qui est du coup plus récent ainsi que tous les package apache postfix, etc ...

Je fais de l'hébergement de site web, j'utilise DTC comme gestionnaire de sites web.
Depuis plus de deux ans, tout fonctionnait très bien, depuis le déménagement c'est la grosse galère ...

depuis la mi mars mon serveur sert de relai spam ... et pourtant d'après tous les tests que je fais nous ne sommes pas openrelay ...

voici un exemple d'entête de spam qu'on reçoit :
http://zy0.de/q/176.31.99.68

Entre temps j'ai effectué plusieurs tests.

- j'utilise webmin pour superviser postfix et autres.
- j'ai installé logwatch, rkhunter, fail2ban et d'autres utilitaires pour diagnostiquer et protéger mon serveur, ils me disent plein de chose mais rien de vraiment concluant me permettant de comprend la source du problème
- rkhunter me dit cependant tous les jours "Please inspect this machine, because it may be infected." or après certaines analyses, ma machine ne semble pas infectée ...
- J'ai configuré iptables afin de bloquer le port 25 en sortie uniquement le temps de trouver une solution, du coup mon serveur ne sert plus de relai, mais les emails de mes clients restent aussi bloqué dans la file d'attente de postfix ...
- J'ai configuré TLS/SSL sur mon serveur SMTP, débloqué le port 587 (submission), dans mon client mail du coup, impec, je peux soit envoyer des mails via le port 587 ou via le port 465 de façon sécurisé, or, au niveau de mon serveur, les emails transitent toujours au final sur le port 25 et donc restent bloqué dans la file d'attente de postfix
(connect to alt4.gmail-smtp-in.l.google.com[173.194.79.26]:25: Connection timed out)

Cela fait maintenant presque un mois que je test tout pour sécuriser ce qui reste à sécuriser, à remettre en question toute mon installation et ma configuration, à scruter internet à la recherche de l'information que je ne sais pas, à essayer diverses configurations récupérées par ci ou par là, rien n'y fait, au bout de plusieurs heures, 24h max, le spam reprend ... et je dois bloquer le port 25 pour éviter de me faire blacklister ...

Il-y a t'il une solution (un peu bourrin certes mais bon), pour bloquer définitivement le port 25 en sortie via iptables et obliger les emails à sortir exclusivement soit par le port 465 soit par le port 587 ?

Pour informations, voici la mécanique des spam dont on est victime :
- des emails sous la forme de "hugo20037@aol.com" ou "benny12335@aol.com" (tous les noms y passent et les numéros changent également, en général on se fait attaquer par vague de même nom suivi de chiffres différents @aol.com)
donc comme je disais, des mails sous la forme de "XXXX12345@aol.com" se font passer pour notre serveur et envoient des emails à des adresses diverses qui n'ont pas l'air d'exister mais qui changent là par contre à chaque fois.
- comme les adresses destinatrices n'existent pas, du coup retour de mail en erreur à l'adresse XXXX12345@aol.com qui du coup pointe vers notre serveur en raison de l'ip contenu dans l'entête je pense, etc ...

par jour, des 100ène de mails transitent ainsi si je laisse le port 25 ouvert, en moyenne 300 mails par jours d'après mes derniers logs ...

Voilà, merci d'avance si quelqu'un peut me trouver une solution ... on désespère limite ...


A bientôt
Léandre