Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2700 connectés 

  FORUM HardWare.fr
  Linux et OS Alternatifs
  réseaux et sécurité

  Possible attaque type relaylock sur qmail: que faire? fermer le relai?

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Possible attaque type relaylock sur qmail: que faire? fermer le relai?

n°1188500
paulo75
Posté le 29-12-2009 à 01:08:36  profilanswer
 

Bonjour à tous,
 
Ceci est un appel à l'aide assez urgent... le désarroi me guette !
 
Mon serveur privé linux virtuozzo a été suspendu par Amen (un hébergeur, au passage, que je déconseille fortement...) :
 
"Votre serveur privé Amen (...) à été suspendu suite à l'instabilité de la plateforme physique hébergeant ce Serveur privé ainsi que ceux d'autres client.
En effet, suite à la présence d'instabilités, nos équipes d'administration ont déterminé que le très grand nombre de processus actifs simultanément sur votre serveur en était à l'origine.
Les processus impliquées étaient de type relaylock, c'est à dire de messagerie.
Si vous ne savez pas d'où proviennent ces processus, il est possible que vous ayez été piraté: dans ce cas, une réinstallation complète et définitive de votre serveur est le seul moyen de vous prémunir de futurs problèmes.
"

 
J'ai finalement pu reprendre la main sur le serveur, mais on me somme de corriger rapidement le problème sous peine d'une désactivation du pack.
 
Sachant qu'il n'est pas rare que le support de Amen raconte un peu n'importe quoi (...), plusieurs questions se posent :
 
1. Bien que je sois sur un serveur privé type VDS (virtuozzo linux), donc partagé, Qmail est installé sur chaque serveur et je ne vois pas très bien en quoi un (prétendu) surnombre de processus sur mon serveur privé (donc avec part de CPU et part de RAM limitées) peut impacter l'ensemble de la plateforme... vous pensez que c'est réellement possible ?  
 
2. J'ai étudié les logs, en particulier la var/log/warn, et je n'ai pas trouvé de "très grand nombre de processus de type relaylock actifs simultanément"  : il y a bien sur un assez grand nombre de relaylocks (environ 1 par minute en moyenne) mais c'est tout à fait dans les normes me semble-t-il...
Quelles logs faut-il vérifier dans ces cas-là (il y a le choix dans var/log : warn, mail.warn, messages, mail.info, mail.err, xinetd.log ...) et comment détecter de graves anomalies/attaques ?
 
3. En quoi une réinstallation du serveur pourrait résoudre ce genre de problèmes ??
J'ai simplement fermé le relai sur mon serveur de messagerie depuis le plesk (préférences de messagerie du serveur), qui était auparavant en mode de relayage avec autorisation (pop3 & smtp authentifié), et il semble, heureusement, que cela ne change rien à l'envoi et la réception de mails sur mon serveur, à ma grande surprise !
En effet, je lis pourtant ceci dans la doc de Plesk :
"Avec le relais fermé, le serveur de messagerie n'acceptera que les e-mails adressés aux utilisateurs dont les boîtes aux lettres se trouvent sur ce serveur. Vos clients ne pourront pas envoyer d'e-mail par le biais de votre serveur SMTP d'envoi. Nous vous déconseillons donc le choix de l'option Relais fermé."
... je m'attendais au pire : ne plus pouvoir recevoir de mails en provenance d'adresses externes et ne plus pouvoir envoyer de mails depuis le smtp de notre serveur sur des adresses externes.
Mais ce n'est pas du tout ce qui s'est produit ! En fait, je ne constate aucune différence par rapport à avant...
Qqun pourrait-il mieux m'expliquer SVP les conséquences réelles d'un relais fermé ?
Et surtout est-ce que ca peut vraiment résoudre mon problème (si problème il y a bien sur...) ?
 
Un grand grand merci d'avance pour vos précieux conseils !

Message cité 2 fois
Message édité par paulo75 le 29-12-2009 à 01:09:18
mood
Publicité
Posté le 29-12-2009 à 01:08:36  profilanswer
 

n°1188501
mikala
Souviens toi du 5 Novembre...
Posté le 29-12-2009 à 01:44:53  profilanswer
 

paulo75 a écrit :


1. Bien que je sois sur un serveur privé type VDS (virtuozzo linux), donc partagé, Qmail est installé sur chaque serveur et je ne vois pas très bien en quoi un (prétendu) surnombre de processus sur mon serveur privé (donc avec part de CPU et part de RAM limitées) peut impacter l'ensemble de la plateforme... vous pensez que c'est réellement possible ?  


oui

paulo75 a écrit :


2. J'ai étudié les logs, en particulier la var/log/warn, et je n'ai pas trouvé de "très grand nombre de processus de type relaylock actifs simultanément"  : il y a bien sur un assez grand nombre de relaylocks (environ 1 par minute en moyenne) mais c'est tout à fait dans les normes me semble-t-il...
Quelles logs faut-il vérifier dans ces cas-là (il y a le choix dans var/log : warn, mail.warn, messages, mail.info, mail.err, xinetd.log ...) et comment détecter de graves anomalies/attaques ?
[/quotemsfg]
Vérifier les logs relatifs aux mails est nécessaire
Il faut notamment t'interesser aux destinataires des mails... est ce réellement toi qui a envoyé ces mails (on peut notamment imaginer une faille au niveau d'une des applications web hébergés par ton serveur http permettant l'envoi en masse de mails... a noter que le fait de te servir d'outils tels que plesk si celui ci n'est pas à jour favorise ce genre de souci...
[quotemsg=1188500,1,722954]
3. En quoi une réinstallation du serveur pourrait résoudre ce genre de problèmes ??


en virant des scripts installés de manière frauduleuse sur ta machine

paulo75 a écrit :


J'ai simplement fermé le relai sur mon serveur de messagerie depuis le plesk (préférences de messagerie du serveur), qui était auparavant en mode de relayage avec autorisation (pop3 & smtp authentifié), et il semble, heureusement, que cela ne change rien à l'envoi et la réception de mails sur mon serveur, à ma grande surprise !


ce qui est un signe inquiétant... ta machine relaie a priori tous les mails (si on fait confiance a ce que tu nous dis) et il parait donc normal que Amen soit un peu irrité par la présence d'un tel serveur.

paulo75 a écrit :


En fait, je ne constate aucune différence par rapport à avant...
Qqun pourrait-il mieux m'expliquer SVP les conséquences réelles d'un relais fermé ?


si le relay est désactivé tu recevras toujours tes mails mais tu ne pourras en envoyer que par le biais de la machine (webmail ou application web troué...)

paulo75 a écrit :


Et surtout est-ce que ca peut vraiment résoudre mon problème (si problème il y a bien sur...) ?


oui.
Et a priori il y a un problème.
Il serait important de lire la documentation de qmail et de le configurer de manière adéquate...


---------------
Intermittent du GNU
n°1188562
e_esprit
Posté le 29-12-2009 à 10:39:49  profilanswer
 

paulo75 a écrit :


2. J'ai étudié les logs, en particulier la var/log/warn, et je n'ai pas trouvé de "très grand nombre de processus de type relaylock actifs simultanément"  : il y a bien sur un assez grand nombre de relaylocks (environ 1 par minute en moyenne) mais c'est tout à fait dans les normes me semble-t-il...
Quelles logs faut-il vérifier dans ces cas-là (il y a le choix dans var/log : warn, mail.warn, messages, mail.info, mail.err, xinetd.log ...) et comment détecter de graves anomalies/attaques ?


/var/log/mail.log => tu verras de suite si ton serveur SMTP est/était un relais ouvert utilisé par des spammers.


---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
n°1188618
paulo75
Posté le 29-12-2009 à 12:12:04  profilanswer
 

Merci bcp pour vos réponses... je commence à y voir un peu plus clair.

 

Mais j'ai vraiment du mal à croire que j'ai des scripts installés de manière frauduleuse sur ma machine...

 
Citation :

ta machine relaie a priori tous les mails (si on fait confiance a ce que tu nous dis) et il parait donc normal que Amen soit un peu irrité par la présence d'un tel serveur.


En fait, on a fermé le relais mais il y avait toujours 127.0.0.0 / 8 dans la liste blanche ... le pbm vient pê de là ?
Encore que le fait d'avoir enlevé ce 127.0.0.0 / 8 n'a pas l'air de changer grand chose d'après les logs.
(et on arrive toujours à envoyer et recevoir des mails externes... ouf !)

 
Citation :

/var/log/mail.log => tu verras de suite si ton serveur SMTP est/était un relais ouvert utilisé par des spammers.


Il n'y a pas de mail.log mais si je prends la mail.warn, voilà ce que j'ai par exemple :

 

Dec 29 12:03:46 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 189.117.85.59:4740 (59.85.117.189.isp.timbrasil.com.br)
Dec 29 12:03:49 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 200.195.132.146:3140 (146.132.195.200.static.copel.net)
Dec 29 12:04:12 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 85.90.197.93:4587 (85-90-197-93.adsl.sta.kh.velton.ua)
Dec 29 12:04:57 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 69.41.155.10:3036 (69-41-155-10.povnweb2.com)
Dec 29 12:04:59 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 90.177.134.163:25409 (163.134.broadband10.iol.cz)
Dec 29 12:05:07 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 69.5.251.3:29939 (not defined)
Dec 29 12:05:10 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 119.71.251.92:4212 (not defined)
Dec 29 12:05:10 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 118.69.68.246:62625 (not defined)
Dec 29 12:05:29 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 93.87.236.186:2229 (not defined)
Dec 29 12:05:50 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 195.70.54.155:27116 (not defined)
Dec 29 12:06:08 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 62.193.206.46:36395 (av3.amenworld.com)
Dec 29 12:06:19 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 218.187.7.41:14995 (nk218-187-7-41.dialup.dynamic.apol.com.tw)
Dec 29 12:06:21 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 122.255.24.82:63160 (p04.wow.lk)
Dec 29 12:06:23 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 118.91.117.44:4904 (not defined)
Dec 29 12:07:12 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 219.94.56.115:15670 (56.94.219.in-addr.arpa)

 

C'est si anormal que çà d'avoir "autant" de mails qui tentent de transiter par ma machine ?
(Je croyais que c'était le principe d'un serveur de messagerie... !)

 

Encore MERCI pour votre aide.

Message cité 1 fois
Message édité par paulo75 le 29-12-2009 à 12:18:10
n°1188622
e_esprit
Posté le 29-12-2009 à 12:22:37  profilanswer
 

paulo75 a écrit :

Merci bcp pour vos réponses... je commence à y voir un peu plus clair.
 
Mais j'ai vraiment du mal à croire que j'ai des scripts installés de manière frauduleuse sur ma machine...
 

Citation :

ta machine relaie a priori tous les mails (si on fait confiance a ce que tu nous dis) et il parait donc normal que Amen soit un peu irrité par la présence d'un tel serveur.


En fait, on a fermé le relais mais il y avait toujours 127.0.0.0 / 8 dans la liste blanche ... le pbm vient pê de là ?
Encore que le fait d'avoir enlevé ce 127.0.0.0 / 8 n'a pas l'air de changer grand chose d'après les logs.
(et on arrive toujours à envoyer et recevoir des mails externes... ouf !)
 

Citation :

/var/log/mail.log => tu verras de suite si ton serveur SMTP est/était un relais ouvert utilisé par des spammers.


Il n'y a pas de mail.log mais si je prends la mail.warn, voilà ce que j'ai par exemple :
 
Dec 29 12:03:46 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 189.117.85.59:4740 (59.85.117.189.isp.timbrasil.com.br)
Dec 29 12:03:49 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 200.195.132.146:3140 (146.132.195.200.static.copel.net)
Dec 29 12:04:12 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 85.90.197.93:4587 (85-90-197-93.adsl.sta.kh.velton.ua)
Dec 29 12:04:57 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 69.41.155.10:3036 (69-41-155-10.povnweb2.com)
Dec 29 12:04:59 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 90.177.134.163:25409 (163.134.broadband10.iol.cz)
Dec 29 12:05:07 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 69.5.251.3:29939 (not defined)
Dec 29 12:05:10 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 119.71.251.92:4212 (not defined)
Dec 29 12:05:10 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 118.69.68.246:62625 (not defined)
Dec 29 12:05:29 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 93.87.236.186:2229 (not defined)
Dec 29 12:05:50 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 195.70.54.155:27116 (not defined)
Dec 29 12:06:08 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 62.193.206.46:36395 (av3.amenworld.com)
Dec 29 12:06:19 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 218.187.7.41:14995 (nk218-187-7-41.dialup.dynamic.apol.com.tw)
Dec 29 12:06:21 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 122.255.24.82:63160 (p04.wow.lk)
Dec 29 12:06:23 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 118.91.117.44:4904 (not defined)
Dec 29 12:07:12 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 219.94.56.115:15670 (56.94.219.in-addr.arpa)
 
C'est si anormal que çà d'avoir "autant" de mails qui tentent de transiter par ma machine ?
(Je croyais que c'était le principe d'un serveur de messagerie... !)
 
Encore MERCI pour votre aide.


Tu dois avoir un log plus conséquent, avec détail des expediteurs et destinataires de chaque mail qui transite (ou est refusé).
 
Après, savoir si c'est normal ou anormal... ben ca dépends.
Si les mails qui passent te sont destiné ou partent de toi, c'est OK.
Si n'importe qui peut s'en servir pour envoyer à n'importe qui (c'est un relais ouvert), la c'est pas normal du tout, enfin plus depuis 10 ans :D


---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
n°1188624
paulo75
Posté le 29-12-2009 à 12:36:23  profilanswer
 

ok c'est la log mail.info en effet
 
Et en effet on peut bien faire la différence entre un message valide envoyé :
 

Citation :

Dec 29 12:26:34 vds-785871 smtp_auth: SMTP connect from (null)@vds-785871.amen-pro.com  
Dec 29 12:26:34 vds-785871 smtp_auth: smtp_auth: SMTP user webmaster@[...] : logged in from (null)@vds-785871.amen-pro.com  
Dec 29 12:26:34 vds-785871 qmail-queue-handlers[27948]: Handlers Filter before-queue for qmail started ...
Dec 29 12:26:34 vds-785871 qmail-queue-handlers[27948]: from=webmaster@[...]
Dec 29 12:26:34 vds-785871 qmail-queue-handlers[27948]: to=[...]
Dec 29 12:26:34 vds-785871 greylisting filter[27949]: Starting greylisting filter...  
Dec 29 12:26:34 vds-785871 spf filter[27950]: Starting spf filter...  
Dec 29 12:26:34 vds-785871 spf filter[27950]: Unable to read string from file: /etc/psa/spf/spfbehavior  
Dec 29 12:26:34 vds-785871 spf filter[27950]: Unable to get spf checking mode  
Dec 29 12:26:34 vds-785871 spf filter[27950]: Unable to get options for spf filter  
Dec 29 12:26:34 vds-785871 qmail-queue-handlers[27948]: call_handlers: Error during call '/usr/local/psa/handlers/info/10-spf-FEf3CW/executable' handler
Dec 29 12:26:34 vds-785871 qmail-queue-handlers[27948]: LOG Internal error in handler '10-spf-FEf3CW'. Skip handler.
Dec 29 12:26:34 vds-785871 qmail: 1262085994.302756 new msg 320733219
Dec 29 12:26:34 vds-785871 qmail: 1262085994.302835 info msg 320733219: bytes 907 from <webmaster@[...]> qp 27951 uid 2020
Dec 29 12:26:34 vds-785871 qmail: 1262085994.307025 starting delivery 1: msg 320733219 to remote [...]
Dec 29 12:26:34 vds-785871 qmail: 1262085994.307101 status: local 0/10 remote 1/20
Dec 29 12:26:34 vds-785871 qmail-remote-handlers[27952]: Handlers Filter before-remote for qmail started ...
Dec 29 12:26:34 vds-785871 qmail-remote-handlers[27952]: from=webmaster@[...]
Dec 29 12:26:34 vds-785871 qmail-remote-handlers[27952]: to=[...]
Dec 29 12:26:34 vds-785871 smtp_auth: SMTP connect from (null)@vds-785871.amen-pro.com  
Dec 29 12:26:34 vds-785871 smtp_auth: smtp_auth: SMTP user webmaster@[...] : logged in from (null)@vds-785871.amen-pro.com  
Dec 29 12:26:34 vds-785871 qmail-queue-handlers[27958]: Handlers Filter before-queue for qmail started ...
Dec 29 12:26:34 vds-785871 qmail-queue-handlers[27958]: from=webmaster@[...]
Dec 29 12:26:34 vds-785871 qmail-queue-handlers[27958]: to=webmaster@[...]
Dec 29 12:26:34 vds-785871 greylisting filter[27959]: Starting greylisting filter...  
Dec 29 12:26:34 vds-785871 spf filter[27960]: Starting spf filter...  
Dec 29 12:26:34 vds-785871 spf filter[27960]: Unable to read string from file: /etc/psa/spf/spfbehavior  
Dec 29 12:26:34 vds-785871 spf filter[27960]: Unable to get spf checking mode  
Dec 29 12:26:34 vds-785871 spf filter[27960]: Unable to get options for spf filter  
Dec 29 12:26:34 vds-785871 qmail-queue-handlers[27958]: call_handlers: Error during call '/usr/local/psa/handlers/info/10-spf-FEf3CW/executable' handler
Dec 29 12:26:34 vds-785871 qmail-queue-handlers[27958]: LOG Internal error in handler '10-spf-FEf3CW'. Skip handler.
Dec 29 12:26:34 vds-785871 qmail: 1262085994.368869 new msg 320733267
Dec 29 12:26:34 vds-785871 qmail: 1262085994.368903 info msg 320733267: bytes 755 from <webmaster@[...]> qp 27961 uid 2020
Dec 29 12:26:34 vds-785871 qmail: 1262085994.372715 starting delivery 2: msg 320733267 to local 2-webmaster@[...]
Dec 29 12:26:34 vds-785871 qmail: 1262085994.372756 status: local 1/10 remote 1/20
Dec 29 12:26:34 vds-785871 qmail-local-handlers[27973]: Handlers Filter before-local for qmail started ...
Dec 29 12:26:34 vds-785871 qmail-local-handlers[27973]: from=webmaster@[...]
Dec 29 12:26:34 vds-785871 qmail-local-handlers[27973]: to=webmaster@[...]
Dec 29 12:26:34 vds-785871 qmail-local-handlers[27973]: mailbox: /var/qmail/mailnames/[...]/webmaster  
Dec 29 12:26:34 vds-785871 dk_check[27974]: DK_STAT_NOSIG: No signature available in message
Dec 29 12:26:34 vds-785871 qmail: 1262085994.385347 delivery 2: success: did_0+0+2/
Dec 29 12:26:34 vds-785871 qmail: 1262085994.385571 status: local 0/10 remote 1/20
Dec 29 12:26:34 vds-785871 qmail: 1262085994.385633 end msg 320733267
Dec 29 12:26:34 vds-785871 qmail: 1262085994.474959 delivery 1: success: 80.12.242.9_accepted_message./Remote_host_said:_250_2.0.0_Ok:_queued_as_6B6962017FD3/
Dec 29 12:26:34 vds-785871 qmail: 1262085994.475080 status: local 0/10 remote 0/20
Dec 29 12:26:34 vds-785871 qmail: 1262085994.475132 end msg 320733219


 
... et des messages bloqués par le config (que le relais soit fermé ou ouvert par authentification comme avant d'ailleurs) :
 

Citation :

Dec 29 12:26:58 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 77.248.58.169:50334 (dhcp-077-248-058-169.chello.nl)
Dec 29 12:27:31 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 87.220.182.216:35479 (216.182.220.87.dynamic.jazztel.es)
Dec 29 12:27:31 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 87.220.182.216:35480 (216.182.220.87.dynamic.jazztel.es)
Dec 29 12:28:31 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 123.24.92.142:12693 (localhost)
Dec 29 12:28:42 vds-785871 relaylock: /var/qmail/bin/relaylock: mail from 91.9.121.118:2134 (p5b097976.dip.t-dialin.net)


 
Merci.


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Linux et OS Alternatifs
  réseaux et sécurité

  Possible attaque type relaylock sur qmail: que faire? fermer le relai?

 

Sujets relatifs
Filesystem type unknown BOOTMGR missing [Résolu] [SAMBA] quotas sur repertoire possible?
Postfix en relai internersync n'inclure qu'un seul type de dossier
[Qmail] Queue à 800.000+ mails, possible de la vider ?[FreeBSD]]Télécharger et compiler un relai dhcp
j'ai fait un rm *.* -r dans /usr/bin par erreur. Possible d'annuler?Mettre un Emac dans une tour de PC c'est possible?
Protéger Sunbird avec mot de passe possible? 
Plus de sujets relatifs à : Possible attaque type relaylock sur qmail: que faire? fermer le relai?


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR