Re: Serveur Courier-smtp utilisé comme serveur de spamerait
Pour info, tu peux utiliser ce site
http://www.alaide.com/outils_testmailrelay.php
Cela ne reglera pas ton probleme directement mais ca peux aider afin d'etre
sur de ne pas etre en danger.
tu mets juste l'@ip publique de ton serveur mail et tu as un rapport si
d'autres peuvent s'en servir comme open relay
@+
----- Original Message -----
From: "Camille Turiel" <cturiel@free.fr>
To: <debian-user-french@lists.debian.org>
Sent: Thursday, April 20, 2006 11:24 AM
Subject: Re: Serveur Courier-smtp utilisé comme serveur de spamerait
AllCoKe a écrit :
>Le 19/04/06, Camille Turiel <cturiel@free.fr> a écrit :
>
>
>
>>"relay_domains" permet de creer une exception aux restrictions
"reject_unauth_destination" et "permit_auth_dest..", or ds ton cas (config
par defaut) "smtpd_recipient_restrictions = permit_mynetworks,
reject_unauth_destination".Ce qui veux dire que s'il y a une wildcard qui
traine ds ta table, ou un "aol.com" (par hasard) qui traine ds cette table,
n'importe qui peut relayer à travers ton serveur à destination de ts les
domaines présents ds cette dernière.
>>Qd à la directive "smtpd_sender_restrictions" c'est idem: "relay_domains"
s'applique à la restriction "permit_mynetworks" donc si le destinataire
matche ce paramètre il n'y aura pas non plus de restrictions sur
l'expediteur.
>>
>>Pourquoi utilises-tu cette table ? peux-tu ns en envoyer le contenu ?
>>
>>
>
>J'utilise Postfixadmin qui utilise ces tables.
>Par contre dans cette table domain, il n'y a absolument rien d'autres
>que mes deux domaines.
>
>
>
Cet outil (frontal graphique j'imagine) ne fait pas partie du paquetage
Postfix, et je ne le connait pas. En revanche ce qui est sur c'est que
ce genre d'outils est à proscrire si tu ne connais pas deja bien le
fonctionnement interne de Postfix, c'est tout juste utile pour la
gestion des comptes. Sinon pour info, ce n'est pas postfixadmin qui
utilise ces tables mais Postfix, bien que cela soit postfixadmin qui
l'aie crée, et ma question était de savoir pourquoi tu as ajouté cette
exception (relay_domain) et que contenait cette table.
Cela met bien en évidence le problème des frontaux graphiques de config:
ds ce cas tu ne sais pourquoi tu as positionné cette directive, c'est
regrettable et cela te complique serieusement le débugage...
Pour en revenir au pb initial si il y a tes deux domaines ds cette table
cela veut dire que tu as un controle très restrictif qui bloque tt par
défaut et ne fait passer que tes domaines gérés par le biais de
l'exception "relay_domain" ou figurent tes domaines...maintenant reste à
savoir comment ton spammeur à pu attaquer malgré tout ton smtpd, pour
cela la seule solution est d'analyser les logs pour determiner
exactement par quel transport il est passé, j'imagine que les transports
spécifiques (comme celui utilisé pour la réinjection ds Postfix après
traitement antivirus) ont bien été limités à l'hôte local, et que les
restrictions du transport en question ont été redéfinies (ce qui est
souvent le cas pour éviter un double contrôle inutile...).
Donc en résumé si tu as un transport smtp spécifique ex sur port 10024
non restreint et non limité à l'hôte local il est possible que le
spammeur l'aie utilisé pour injecter ses pourriels...pour cela il
faudrait que tu nous envoie ton master.cf afin d'analyser la config des
services.
Et puis tant qu'à faire si tu peux nous faire parvenir le morceau de log
concernant l'attaque en question cela pourrait nous faciliter grandement
la tâche.
>>Ceci dit le mieux est d'essayer de reproduire le problème, pour mieux
l'analyser ensuite, je te conseille d'attaquer ton serveur depuis un autre
sous-réseau, et d'activer le debug sur le domaine que tu veux essayer de lui
faire relayer ex: "debug_peer_list = aol.com", c'est assez bavard mais
redoutablement efficace,
>>
>>
>sinon en attendant tu peux deja commenter la directive "relay_domain"
>et essayer de relayer depuis "l'exterieur".
>
>
Normalement en faisant cela il devrait systématiquement refuser le relay
quel que soit le domaine...
>Sur ce point, je ne sais absolument pas comment attaquer mon serveur
>et je n'ai pas d'autre réseau sous la main :/
>
>
>
>
Le plus simple est d'ajouter une deuxième interface Ex eth0:1 sur un
autre sous-réseau IP Ex: 10.0.0.2 (ds /etc/network/interfaces) et tu
l'attaques sur cette interface, sinon si tu veux t'amuser tu peux te
connecter avec un bon vieux modem RTC et tu attaques ton serveur sur son
adresse externe comme le ferait un client standard.
>
>Le 19/04/06, Marc PERRUDIN <debianNOSPAM@mp342.org> a écrit :
>
>
>>tu ne peux pas. Beaucoup de fai refuse les mails en provenance directe
>>de serveurs smtp personnels. Pour pouvoir envoyer des mails a ces fai,
>>tu dois passer par le relai smtp de ton fai (configuration de type
>>smarthost).
>>
>>
>
>Smarthost ? De quoi s'agit-il ? Mettre le smtp de mon FAI dans
>relayhost ne suffit pas ?
>
>
C'est la même chose, la config "smarthost" correspond à ce type de
configuration (relay sur smtp de ton ISP par ex) c'est simplement
l'appellation utilisée par dpkg.
>
>
>
>
>2006/4/19, manioul <manioul@manioul.org>:
>
>
>
>>Voici une liste de restrictions que tu peux tester:
>>
>>permit_mynetworks
>>reject_invalid_hostname
>>reject_unknown_hostname
>>reject_non_fqdn_hostname
>>reject_unknown_sender_domain
>>reject_non_fqdn_sender
>>reject_unauth_destination
>>reject_invalid_hostname
>>reject_non_fqdn_hostname
>>reject_non_fqdn_sender
>>reject_non_fqdn_recipient
>>reject_unknown_sender_domain
>>reject_unknown_recipient_domain
>>reject_rbl_client
>>
>>Ainsi que différentes cibles:
>>
>>smtpd_helo_restrictions =
>>smtpd_etrn_restrictions =
>>smtpd_sender_restrictions =
>>smtpd_recipient_restrictions =
>>
>>
>
>Merci, je vais me documenter sur ces restrictions !
>
>
Je pense qu'il te serait plus utile de te documenter sur le
fonctionnement global de Postfix afin de mieux cerner les concepts qui
mettent en oeuvre ces restrictions.
Cordialement,
Camille.
-------------------------------------------------------------------------------------------------------------------
Ce message électronique et tous les fichiers attachés qu'il contient sont confidentiels et destinés exclusivement
à l'usage de la personne à laquelle ils sont adressés. Si vous avez reçu ce message par erreur, merci de le
retourner à son émetteur. La publication, l'usage, la distribution, l'impression ou la copie non autorisée de ce
message et des attachements qu'il contient sont strictement interdits.
Sans virus connus
Reply to: