Flood SPAM SMTP

Bonjour,

J’ai eu une attaque ce matin, avec l’envoi d’environ 35 000 emails depuis mon serveur.

Je ne sais pas trop comment m’y prendre pour régler ce problème, surtout empêcher ce flood.

Pour commencer j’ai fait :

J’obtiens ceci (échantillon) :

[code]62CD0258989F 4018 Wed Aug 13 09:45:03 www-data@ns1.mondomaine.tld
(delivery temporarily suspended: connect to mx3.bol.com.br[200.147.36.13]:25: Connection timed out)
brunomensatti@bol.com.br

6BF392585DCD 4018 Wed Aug 13 08:53:11 www-data@ns1.mondomaine.tld
(connect to grego.hardonline.com.br[189.126.224.17]:25: Connection timed out)
aciaof@hardonline.com.br[/code]
Tous les emails se finissent par .com.br

Je regarde le contenu d’un email :

[code]*** ENVELOPE RECORDS deferred/8/8BEE125896F6 ***
message_size: 3978 670 1 0 3978
message_arrival_time: Wed Aug 13 09:43:25 2014
create_time: Wed Aug 13 09:43:25 2014
named_attribute: log_ident=8BEE125896F6
named_attribute: rewrite_context=local
sender: www-data@ns1.mondomain.tld
named_attribute: log_client_name=localhost.localdomain
named_attribute: log_client_address=127.0.0.1
named_attribute: log_client_port=56729
named_attribute: log_message_origin=localhost.localdomain[127.0.0.1]
named_attribute: log_helo_name=localhost
named_attribute: log_protocol_name=ESMTP
named_attribute: client_name=localhost.localdomain
named_attribute: reverse_client_name=localhost.localdomain
named_attribute: client_address=127.0.0.1
named_attribute: client_port=56729
named_attribute: helo_name=localhost
named_attribute: protocol_name=ESMTP
named_attribute: client_address_type=2
warning_message_time: Wed Aug 13 10:43:25 2014
named_attribute: dsn_orig_rcpt=rfc822;brui@ig.com.br
original_recipient: brui@ig.com.br
recipient: brui@ig.com.br
*** MESSAGE CONTENTS deferred/8/8BEE125896F6 ***
Received: from localhost (localhost.localdomain [127.0.0.1])
by ns1.mondomaine.tld (Postfix) with ESMTP id 8BEE125896F6
for brui@ig.com.br; Wed, 13 Aug 2014 09:43:25 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at ns1.mondomaine.tld
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char F4 hex):
Subject: Fw:Enc: Caixa Econ\303\264mica Federal Au[…]
Received: from ns1.mondomaine.tld ([127.0.0.1])
by localhost (ns1.mondomaine.tld [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id w64Kwc_Wqb0y for brui@ig.com.br;
Wed, 13 Aug 2014 09:43:25 +0200 (CEST)
Received: by ns1.mondomaine.tld (Postfix, from userid 33)
id 0EBA925874B4; Wed, 13 Aug 2014 08:42:07 +0200 (CEST)
To: brui@ig.com.br
Subject: Fw:Enc: Caixa Econômica Federal Autenticação: N78L41A35P6 13/08/2014 08:37:57
X-PHP-Originating-Script: 1000:send.php?.php
MIME-Version: 1.0
Content-type: text/html; charset=iso-8859-1
From: brui@ig.com.br
Message-Id: 20140813071020.0EBA925874B4@ns1.mondomaine.tld
Date: Wed, 13 Aug 2014 08:42:07 +0200 (CEST)

mygood



               
   Prezado Cliente :
Seja bem vindo (a) ao Caixa Internet Banking.
 



Informamos que desde o dia
20º de Julho de 2014
, o sistema de
identificação da Caixa Econômica

Federal atualizou, e para garantirmos o acesso aos serviços
Internet Banking CAIXA, é de extrema

importância confirmar essa atualização.



Caso o recadastramento
não seja efetuado
, você não terá
acesso aos serviços Caixa Internet

Banking e seu acesso em todos os canais Caixa serão bloqueados.



Para acessar o auto-atendimento é necessário efetuar
nesta máquina, o recadastramento da

solução de segurança da Internet Banking, para
continuar utilizando de nossos serviços.



                   
         Clique no link abaixo e siga as
instruções atentamente.



                   
                    http://www.caixa.com.br/ver/cadastro



               
 (Atualização e privada para você cliente,
não compartilhe este aplicativo)



Atenção:
Caso não conste em nossa rede de atendimento a
atualização, sua conta será bloqueada

e o desbloqueio só poderá ser realizado nas
agências da Caixa Econômica Federal.



verygood

*** HEADER EXTRACTED deferred/8/8BEE125896F6 ***
*** MESSAGE FILE END deferred/8/8BEE125896F6 ***[/code]

J’ai l’impression que c’est envoyé depuis un fichier “send.php” sur mon serveur, non ?
De même, j’ai l’impression, que c’est envoyé depuis mon serveur ? et non mon serveur qui répond à une requête ?

Je me dis, si c’est envoyé depuis mon serveur, je vais tenter de trouver le fichier (j’ai aussi fait un updatedb au cas où) :

/boot/grub/sendkey.mod /etc/amavis/en_US/template-spam-sender.txt /etc/amavis/en_US/template-virus-sender.txt /etc/fail2ban/action.d/sendmail-buffered.conf /etc/fail2ban/action.d/sendmail-whois-lines.conf /etc/fail2ban/action.d/sendmail-whois.conf /etc/fail2ban/action.d/sendmail.conf /etc/init.d/sendsigs /etc/rc0.d/K04sendsigs /etc/rc6.d/K04sendsigs /usr/lib/sendmail /usr/lib/grub/i386-pc/sendkey.mod /usr/sbin/sendmail /usr/share/doc/amavisd-new/README.sendmail-dual.gz /usr/share/doc/amavisd-new/README.sendmail-dual.old.gz /usr/share/doc/amavisd-new/README.sendmail.gz /usr/share/doc/libmailtools-perl/demos/send_demo /usr/share/doc/libmime-tools-perl/examples/mimesend /usr/share/doc/libmime-tools-perl/examples/mimesender /usr/share/doc/tcpdump/examples/send-ack.awk /usr/share/man/fr/man2/mq_timedsend.2.gz /usr/share/man/fr/man2/send.2.gz /usr/share/man/fr/man2/sendfile.2.gz /usr/share/man/fr/man2/sendfile64.2.gz /usr/share/man/fr/man2/sendmmsg.2.gz /usr/share/man/fr/man2/sendmsg.2.gz /usr/share/man/fr/man2/sendto.2.gz /usr/share/man/fr/man3/mq_send.3.gz /usr/share/man/fr/man3/mq_timedsend.3.gz /usr/share/man/fr/man3/res_send.3.gz /usr/share/man/fr/man3/svc_sendreply.3.gz /usr/share/man/fr/man3/tcsendbreak.3.gz /usr/share/man/man1/sendmail.1.gz /usr/share/perl5/Mail/Mailer/sendmail.pm /usr/share/squirrelmail/locale/bn_BD/LC_MESSAGES/restrict_senders.mo /usr/share/squirrelmail/locale/de_DE/LC_MESSAGES/restrict_senders.mo /usr/share/squirrelmail/locale/fy/LC_MESSAGES/restrict_senders.mo /usr/share/squirrelmail/locale/km/LC_MESSAGES/restrict_senders.mo /usr/share/squirrelmail/locale/lt_LT/LC_MESSAGES/restrict_senders.mo /usr/share/squirrelmail/locale/nl_NL/LC_MESSAGES/restrict_senders.mo /usr/share/squirrelmail/locale/nn_NO/LC_MESSAGES/restrict_senders.mo /usr/share/squirrelmail/locale/sv_SE/LC_MESSAGES/restrict_senders.mo /usr/share/squirrelmail/locale/vi_VN/LC_MESSAGES/restrict_senders.mo /usr/share/vim/vim73/ftplugin/gitsendemail.vim /usr/share/vim/vim73/syntax/gitsendemail.vim /usr/share/vim/vim73/syntax/sendpr.vim /var/www/postfixadmin/sendmail.php /var/www/postfixadmin/templates/sendmail.php

Le fichier ne s’y trouve pas !

J’ai regardé les fichiers

/var/log/apache2/access.log et /var/log/apache2/error.log

Dans error.log j’ai quelques erreurs comme :

J’ai scanné son ftp, il y a une tonne de documents, en espagnol, dont des documents pour envoyer en masse des emails… mais j’ai l’impression que cette tentative n’a pas fonctionnée, enfin, sinon ca serait pas dans erreur non ?

dans access.log je n’ai rien trouvé de spécial …

Des idées de la manière d’agir ? quoi cherché ?

Je suppose qu’il utilise une faille d’un de mes sites pour utiliser un lien de son site (où plutôt d’un site qu’il a piraté)

Son piratage continue… Il laisse la machine tourner…
J’ai stoppé et redémarré Apache voir si au moins ca peut le stopper quelques temps histoire de vider un peu les emails.

J’ai fail2ban mais je ne l’ai activé que pour SSH et ftp, car pour les emails, lorsque c’était activé, ca me bloquait aussi mes emails :confused: mais je m’y suis peut être mal pris… et je n’ai peut être pas bien configuré certains logiciels

Du coup, si vous avez des idées :
-de ce que je pourrais chercher (mots clefs, fichiers logs, etc.)
-Bloquer > fail2ban, autre configuration
-Autres idées…

Pour infos, le piratage a commencé vers 7h00 et a continué jusqu’à 11h, avoir redémarré Apache a apparemment stoppé temporairement le flood

Sinon j’ai une Debian 7.6, Dovecot, Postfix, SpamAssassin

Merci à vous par avance !

Ne te fie pas à l’entête

Si ça se trouve c’est directement le script qui ajoute ça.

les .br sont pour le Brésil, donc ce n’est pas de l’Espagnol mais du Portugais.

Dit toi qu’une machine infecté est une machine a réinstaller complètement, tu ne pourras jamais avoir la certitude que tu as bien fait tout le ménage sinon.

Installe RootKitHunter et fait lui faire un scan. Ça te diras si ta machine comporte un soft non désiré, ce qui voudra dire que l’intrusion a été sévère.

Si ton serveur n’a pas trop de trafic essaye de regarder les logs de ton serveur Web.
Il est possible qu’il ai exploité une faille de PostfixAdmin.
Je te conseille de désactivé tout ce qui n’est pas indispensable.
Examine (avec Htop en organisant les process par filiation) tous les process qui tournent sur ta machine.

Si Postfix n’est pas indispensable arrête le le temps de localiser la fuite.

Salut,

Merci pour ta réponse

[quote=“Mimoza”]Ne te fie pas à l’entête
Dit toi qu’une machine infecté est une machine a réinstaller complètement, tu ne pourras jamais avoir la certitude que tu as bien fait tout le ménage sinon.

Installe RootKitHunter et fait lui faire un scan. Ça te diras si ta machine comporte un soft non désiré, ce qui voudra dire que l’intrusion a été sévère.[/quote]
J’ai oublié de préciser désolé, j’ai Rkithunter, j’ai lancé et je n’ai aucun soucis, aucun rootkits sur le serveur !

[quote=“Mimoza”]Si ton serveur n’a pas trop de trafic essaye de regarder les logs de ton serveur Web.
Il est possible qu’il ai exploité une faille de PostfixAdmin.
Je te conseille de désactivé tout ce qui n’est pas indispensable.
Examine (avec Htop en organisant les process par filiation) tous les process qui tournent sur ta machine.
[/quote]
Il y a pas mal de trafic, mais j’ai quand même regardé les logs et je n’ai rien troué d’anormal… :confused: mais peut être aussi que ca ne m’a pas sauté aux yeux
J’ai déjà tout qui n’est pas indispensable de désactivé, et un parefeu pour bloquer tous les ports que je n’utilise pas.
J’avais pensé à postfixadmin aussi, malgré qu’il soit protégé par un .htaccess, du coup je vais désactiver temporairement voir si il y a une autre attaque.
Pour Htop, vu que l’attaque a été stoppée, pour l’instant je ne peux pas :confused:

J’ai coupé Apache quelques minutes et à la suite de cela plus aucune attaque. Je continue de regarder les logs, et depuis une heure je n’ai plus rien. Je pense que ce n’est pas la machine qui est infectée mais une faille sur un de mes sites web, d’ailleurs c’est le log sur la tentative de piratage que j’ai posté (qui date d’hier) qui me fait penser ca… De même, aucun utilisateur ne s’est connecté en SSH ou ftp à part moi.

J’ai placé un correctif sur la page où il a tenté de pirater au cas où que cela venait de là…

J’aurais espéré avoir d’autres points a explorer qui pourrait peut être me permettre de confirmer que c’est bien une faille d’un de mes sites, mais je ne trouve rien pour le moment :confused:

En tout cas merci pour tes propositions :wink:

[quote=“Balian”]

J’ai coupé Apache quelques minutes et à la suite de cela plus aucune attaque. Je continue de regarder les logs, et depuis une heure je n’ai plus rien. Je pense que ce n’est pas la machine qui est infectée mais une faille sur un de mes sites web, d’ailleurs c’est le log sur la tentative de piratage que j’ai posté (qui date d’hier) qui me fait penser ca… De même, aucun utilisateur ne s’est connecté en SSH ou ftp à part moi.

J’ai placé un correctif sur la page où il a tenté de pirater au cas où que cela venait de là…

J’aurais espéré avoir d’autres points a explorer qui pourrait peut être me permettre de confirmer que c’est bien une faille d’un de mes sites, mais je ne trouve rien pour le moment :confused:

En tout cas merci pour tes propositions :wink:[/quote]

Si lorsque tu coupe apache tu n’a plus rien … :whistle:

Soit le hasard veux qu’il est finit pour l’instant, soit il y a du formulaire mal sécurisé ou ajouter à un de tes domaines.
Si tu est sûr que postfix ne permettent pas le relais s’est que le problème est sur ta machine :033

Assure toi que l’envoi de mail nécessite une authentification et que tout les forumulaires utilisent l’authentification pour l’envoi (création d’utilisateur spécifique).

oui, possible qu’une faille sur un de tes sites permettent l’exécution de code PHP arbitraire, surtout si le fait de couper Apache a stopper net l’envoi de SPAM.
Par contre je crains que ta réputation en tant que serveur de mail en ai pris un coup, fait le tour des sites de listes pour vérifier.
Pas d’autre pistes a te proposer pour l’instant

[quote=“Clochette”]
Si lorsque tu coupe apache tu n’a plus rien … :whistle:

Soit le hasard veux qu’il est finit pour l’instant, soit il y a du formulaire mal sécurisé ou ajouter à un de tes domaines.
Si tu est sûr que postfix ne permettent pas le relais s’est que le problème est sur ta machine :033

Assure toi que l’envoi de mail nécessite une authentification et que tout les forumulaires utilisent l’authentification pour l’envoi (création d’utilisateur spécifique).[/quote]Je pense qu’il n’avait pas fini, car j’ai coupé Apache pendant que des emails étaient encore envoyés!
Je vais vérifier tout ca, merci à toi :wink:

[quote=“Mimoza”]oui, possible qu’une faille sur un de tes sites permettent l’exécution de code PHP arbitraire, surtout si le fait de couper Apache a stopper net l’envoi de SPAM.
Par contre je crains que ta réputation en tant que serveur de mail en ai pris un coup, fait le tour des sites de listes pour vérifier.
Pas d’autre pistes a te proposer pour l’instant[/quote]
OVH à bloqué mon trafic email assez tôt, ce qui a limité les problèmes je pense ! Mais ca ne m’étonnerait pas d’être banni :smiley: ca m’arrive parfois :12 (mon serveur génère pas mal d’emails, entre les sites, les forums etc. :confused: )

EDIT : pour l’instant, le piratage est toujours stoppé :114

Sinon, il doit être possible de remettre le service apache en route et d’utiliser postfix pour détourner le SPAM sortant et l’envoyer à la benne.

Par exemple en utilisant la table [mono]transport[/mono] de postfix en indiquant que tout ce qui est à destination d’un domaine [mono]*.br[/mono] est relayé vers un serveur smtp sur ta machine sur le port 1025. Et ensuite tu fais tourner l’utilitaire [mono]smtp-sink[/mono] sur ta machine sur le port 1025. Hop !
Exemple pour lancer smtp-sink : [mono]nohup smtp-sink -u nobody -4 localhost:1025 10 >/dev/null 2>&1 &[/mono]

Ce serait un bricolage juste mis en place le temps de trouver la brèche et de la combler.

Sinon, pour parcourir une arborescence histoire de trouver un fichier, la commande [mono]find[/mono] est pas mal, aussi. Son désavantage étant que les emplacements des fichiers ne sont pas dans une BDD : Le parcours se fait sur le disque à chaque fois.


AnonymousCoward

Mais non, la première fois seulement. Ensuite l’arborescence déjà parcourue est dans le cache du noyau, si la RAM n’est pas trop chargée. C’est comme pour les fichiers déjà lus.

PS par pur esprit de contradiction : un système de fichiers est une sorte de base de données.