Probleme Exchange 5.5 et virus MyDoom

Vincent

29/01/2004 à 21:33

Bonsoir,

Je crois que de memoire tu pexu configurer le serveur SMTP pour qu'il
verifie le nom de domaine avant envoie.
Grosso modo c'est dans les propriété du server virtuel SMTP sous 2000, je
sais pu ou c'est sous 5.5 ca fait 5 ans que j'en ai pas vu ;)
J'espere que ca pourra t'aider

--
Cordialement,
Vincent L.

PS : Pour m'ecrire supprimer nospamallowed_

"Cyril Drouin" wrote in message
news:67b701c3e6a5$ec19c510$
Nous avons un problème sur un serveur Exchange 5.5
configuré pour laisser entrer certains domaines locaux
(domain1.Com et domain2.com).

Depuis l'arrivée de MyDoom, nous recevons des milliers
d'email adressés à des utilisateurs de type
et MAIS
l'utilisateur n'existe pas sur le
domaine 'domain1.com', Exchange traite le mail
correctement et envoi un avis de non réception à
l'expéditeur.

Problèmes : parfois le domaine d l'expéditeur n'existe
pas, le fichier priv.edb grossit a vue d'oeil (Pourquoi ?
Exchange stocke t'il les messages quelquepart ??), le
priv.edb a explosé 2 fois en 24 heures.

Comment faire pour que les messages addressés à des
destinataires ne soient traités que dans le cas OU le
destinataire est bien valide dans le domaine ?

J'ai rien vu dans les options de exchange 5.5 la dessus.

merci de votre aide la dessus,

Cyril Drouin
Bysoft.fr

29/01/2004 à 22:25

En fait nous sommes victime d'une attaque de
type "Reverse UCE"..et je vois pas comment la contrer !!

Reverse UCE. If you set your system to Do not reroute
incoming SMTP mail, malicious users can use your system
as a launching point to flood another computer system
with SMTP messages. Because the messages include your
company's address, they look as if you sent them. For a
more detailed look at the SMTP protocol dialog between
sender and server, see Mark Minasi's Windows NT Magazine
article "Untangling Email" (April 1998). Figure 1 shows a
typical SMTP dialog.

As the system issues each of these commands, the Exchange
server returns a code to the sending system. All the
server responses in the dialog start with a numerical
code. This code is either 250 OK, which represents
success, or another error code, such as 501 Unrecognized
parameter. The SMTP protocol specifies that 200-level
codes signify success, 400-level codes signify temporary
failures, and 500-level codes signify critical failures.

The logic that the IMS uses when determining whether to
deliver a message flows as follows:

Accept sender's address.
Accept recipient's address.
Accept a data stream containing message header and body
text.
Determine whether the recipient is a member of the local
system (i.e., whether the address is in the Global
Address List-GAL).
If yes, deliver the message to the local recipient. If
no, use the sender's address to generate an NDR.
Because step 5 can result in the system directing a
message back to the sending address, a malicious user
could engineer a mail flood by supplying a bogus
addressee (RCPT TO) with a valid sending address (MAIL
FROM)-the target of the flood-and then infinitely
generating messages to the Exchange IMS. In any case, the
malicious user achieves the objective of getting an
unsolicited message to a destination.

Unnecessary burden on system. You can see the second
disadvantage of using the Do not reroute incoming SMTP
mail setting by reading the SMTP dialog. You're providing
the IMS with the following information: the message
sender (MAIL FROM), the message recipient (RCPT TO), and
the message (DATA). When your POP3 client sends a
message, as in this test, it goes through a similar
process. In the current configuration (Do not reroute
incoming SMTP mail), the IMS accepts the RCPT TO
specification and sends the return code 250 OK even if
the recipient isn't part of the local system. Next, the
IMS lets you execute the DATA command, through which you
could supply megabytes and megabytes of message body
text. This action can tie up your system resources, even
though the system eventually generates an NDR.

-----Message d'origine-----
Bonsoir,

Je crois que de memoire tu pexu configurer le serveur
SMTP pour qu'il

verifie le nom de domaine avant envoie.
Grosso modo c'est dans les propriété du server virtuel
SMTP sous 2000, je

sais pu ou c'est sous 5.5 ca fait 5 ans que j'en ai pas
vu ;)

J'espere que ca pourra t'aider

--
Cordialement,
Vincent L.

PS : Pour m'ecrire supprimer nospamallowed_

"Cyril Drouin" wrote in message
news:67b701c3e6a5$ec19c510$
Nous avons un problème sur un serveur Exchange 5.5
configuré pour laisser entrer certains domaines locaux
(domain1.Com et domain2.com).

Depuis l'arrivée de MyDoom, nous recevons des milliers
d'email adressés à des utilisateurs de type
et MAIS
l'utilisateur n'existe pas sur le
domaine 'domain1.com', Exchange traite le mail
correctement et envoi un avis de non réception à
l'expéditeur.

Problèmes : parfois le domaine d l'expéditeur n'existe
pas, le fichier priv.edb grossit a vue d'oeil (Pourquoi ?
Exchange stocke t'il les messages quelquepart ??), le
priv.edb a explosé 2 fois en 24 heures.

Comment faire pour que les messages addressés à des
destinataires ne soient traités que dans le cas OU le
destinataire est bien valide dans le domaine ?

J'ai rien vu dans les options de exchange 5.5 la dessus.

merci de votre aide la dessus,

Cyril Drouin
Bysoft.fr

.

En fait nous sommes victime d'une attaque de
type "Reverse UCE"..et je vois pas comment la contrer !!

Reverse UCE. If you set your system to Do not reroute
incoming SMTP mail, malicious users can use your system
as a launching point to flood another computer system
with SMTP messages. Because the messages include your
company's address, they look as if you sent them. For a
more detailed look at the SMTP protocol dialog between
sender and server, see Mark Minasi's Windows NT Magazine
article "Untangling Email" (April 1998). Figure 1 shows a
typical SMTP dialog.

As the system issues each of these commands, the Exchange
server returns a code to the sending system. All the
server responses in the dialog start with a numerical
code. This code is either 250 OK, which represents
success, or another error code, such as 501 Unrecognized
parameter. The SMTP protocol specifies that 200-level
codes signify success, 400-level codes signify temporary
failures, and 500-level codes signify critical failures.

The logic that the IMS uses when determining whether to
deliver a message flows as follows:

Accept sender's address.
Accept recipient's address.
Accept a data stream containing message header and body
text.
Determine whether the recipient is a member of the local
system (i.e., whether the address is in the Global
Address List-GAL).
If yes, deliver the message to the local recipient. If
no, use the sender's address to generate an NDR.
Because step 5 can result in the system directing a
message back to the sending address, a malicious user
could engineer a mail flood by supplying a bogus
addressee (RCPT TO) with a valid sending address (MAIL
FROM)-the target of the flood-and then infinitely
generating messages to the Exchange IMS. In any case, the
malicious user achieves the objective of getting an
unsolicited message to a destination.

Unnecessary burden on system. You can see the second
disadvantage of using the Do not reroute incoming SMTP
mail setting by reading the SMTP dialog. You're providing
the IMS with the following information: the message
sender (MAIL FROM), the message recipient (RCPT TO), and
the message (DATA). When your POP3 client sends a
message, as in this test, it goes through a similar
process. In the current configuration (Do not reroute
incoming SMTP mail), the IMS accepts the RCPT TO
specification and sends the return code 250 OK even if
the recipient isn't part of the local system. Next, the
IMS lets you execute the DATA command, through which you
could supply megabytes and megabytes of message body
text. This action can tie up your system resources, even
though the system eventually generates an NDR.

-----Message d'origine-----
Bonsoir,

Je crois que de memoire tu pexu configurer le serveur
SMTP pour qu'il

verifie le nom de domaine avant envoie.
Grosso modo c'est dans les propriété du server virtuel
SMTP sous 2000, je

sais pu ou c'est sous 5.5 ca fait 5 ans que j'en ai pas
vu ;)

J'espere que ca pourra t'aider

--
Cordialement,
Vincent L.

PS : Pour m'ecrire supprimer nospamallowed_

"Cyril Drouin" <cyril.drouin@bysoft.fr> wrote in message
news:67b701c3e6a5$ec19c510$a101280a@phx.gbl...
Nous avons un problème sur un serveur Exchange 5.5
configuré pour laisser entrer certains domaines locaux
(domain1.Com et domain2.com).

Depuis l'arrivée de MyDoom, nous recevons des milliers
d'email adressés à des utilisateurs de type
user1@domain1.com et user2@domain2.com. MAIS
l'utilisateur user1@domain1.com n'existe pas sur le
domaine 'domain1.com', Exchange traite le mail
correctement et envoi un avis de non réception à
l'expéditeur.

Problèmes : parfois le domaine d l'expéditeur n'existe
pas, le fichier priv.edb grossit a vue d'oeil (Pourquoi ?
Exchange stocke t'il les messages quelquepart ??), le
priv.edb a explosé 2 fois en 24 heures.

Comment faire pour que les messages addressés à des
destinataires ne soient traités que dans le cas OU le
destinataire est bien valide dans le domaine ?

J'ai rien vu dans les options de exchange 5.5 la dessus.

merci de votre aide la dessus,

Cyril Drouin
Bysoft.fr

.

Vous avez filtré cet utilisateur ! Consultez son message

En fait nous sommes victime d'une attaque de
type "Reverse UCE"..et je vois pas comment la contrer !!

Reverse UCE. If you set your system to Do not reroute
incoming SMTP mail, malicious users can use your system
as a launching point to flood another computer system
with SMTP messages. Because the messages include your
company's address, they look as if you sent them. For a
more detailed look at the SMTP protocol dialog between
sender and server, see Mark Minasi's Windows NT Magazine
article "Untangling Email" (April 1998). Figure 1 shows a
typical SMTP dialog.

As the system issues each of these commands, the Exchange
server returns a code to the sending system. All the
server responses in the dialog start with a numerical
code. This code is either 250 OK, which represents
success, or another error code, such as 501 Unrecognized
parameter. The SMTP protocol specifies that 200-level
codes signify success, 400-level codes signify temporary
failures, and 500-level codes signify critical failures.

The logic that the IMS uses when determining whether to
deliver a message flows as follows:

Accept sender's address.
Accept recipient's address.
Accept a data stream containing message header and body
text.
Determine whether the recipient is a member of the local
system (i.e., whether the address is in the Global
Address List-GAL).
If yes, deliver the message to the local recipient. If
no, use the sender's address to generate an NDR.
Because step 5 can result in the system directing a
message back to the sending address, a malicious user
could engineer a mail flood by supplying a bogus
addressee (RCPT TO) with a valid sending address (MAIL
FROM)-the target of the flood-and then infinitely
generating messages to the Exchange IMS. In any case, the
malicious user achieves the objective of getting an
unsolicited message to a destination.

Unnecessary burden on system. You can see the second
disadvantage of using the Do not reroute incoming SMTP
mail setting by reading the SMTP dialog. You're providing
the IMS with the following information: the message
sender (MAIL FROM), the message recipient (RCPT TO), and
the message (DATA). When your POP3 client sends a
message, as in this test, it goes through a similar
process. In the current configuration (Do not reroute
incoming SMTP mail), the IMS accepts the RCPT TO
specification and sends the return code 250 OK even if
the recipient isn't part of the local system. Next, the
IMS lets you execute the DATA command, through which you
could supply megabytes and megabytes of message body
text. This action can tie up your system resources, even
though the system eventually generates an NDR.

-----Message d'origine-----
Bonsoir,

Je crois que de memoire tu pexu configurer le serveur
SMTP pour qu'il

verifie le nom de domaine avant envoie.
Grosso modo c'est dans les propriété du server virtuel
SMTP sous 2000, je

sais pu ou c'est sous 5.5 ca fait 5 ans que j'en ai pas
vu ;)

J'espere que ca pourra t'aider

--
Cordialement,
Vincent L.

PS : Pour m'ecrire supprimer nospamallowed_

"Cyril Drouin" wrote in message
news:67b701c3e6a5$ec19c510$
Nous avons un problème sur un serveur Exchange 5.5
configuré pour laisser entrer certains domaines locaux
(domain1.Com et domain2.com).

Depuis l'arrivée de MyDoom, nous recevons des milliers
d'email adressés à des utilisateurs de type
et MAIS
l'utilisateur n'existe pas sur le
domaine 'domain1.com', Exchange traite le mail
correctement et envoi un avis de non réception à
l'expéditeur.

Problèmes : parfois le domaine d l'expéditeur n'existe
pas, le fichier priv.edb grossit a vue d'oeil (Pourquoi ?
Exchange stocke t'il les messages quelquepart ??), le
priv.edb a explosé 2 fois en 24 heures.

Comment faire pour que les messages addressés à des
destinataires ne soient traités que dans le cas OU le
destinataire est bien valide dans le domaine ?

J'ai rien vu dans les options de exchange 5.5 la dessus.

merci de votre aide la dessus,

Cyril Drouin
Bysoft.fr

.

fritz $mvp$

30/01/2004 à 10:05

bonjour Cyril,
je ne connais pas de procédure pour empêcher un serveur Exch5.5 de
renvoyer ces rapports de non remise (NDR).
l'acceptation d'un message seulement quand le destinataire existe pour
de bon n'est possible qu'avec Exch2003.

avec Exch5.5, une copie du message avec destinataire inconnu dans ton
domaine est systématiquement déposée dans la "BL Administrateur du
service messagerie Internet".
dans le cas où le domaine du destinataire du rapport de non remise (= le
faux expéditeur du message reçu) serait inconnu, le NDR devrait rester
dans la file d'attente des messages sortants de ton service messagerie
Internet.

avis aux utilisateurs de pytheas mailgate avec ce problème: il est
désormais possible de retarder automatiquement l'expédition de ces
rapports de non remise pour un certain nombre d'heures, pour pouvoir les
supprimer dans la file d'attente des messages sortants de ce produit.
pour l'obtenir:

cordialement,
fritz

Cyril Drouin wrote:
: Nous avons un problème sur un serveur Exchange 5.5
: configuré pour laisser entrer certains domaines locaux
: (domain1.Com et domain2.com).
:
: Depuis l'arrivée de MyDoom, nous recevons des milliers
: d'email adressés à des utilisateurs de type
: et MAIS
: l'utilisateur n'existe pas sur le
: domaine 'domain1.com', Exchange traite le mail
: correctement et envoi un avis de non réception à
: l'expéditeur.
:
: Problèmes : parfois le domaine d l'expéditeur n'existe
: pas, le fichier priv.edb grossit a vue d'oeil (Pourquoi ?
: Exchange stocke t'il les messages quelquepart ??), le
: priv.edb a explosé 2 fois en 24 heures.
:
: Comment faire pour que les messages addressés à des
: destinataires ne soient traités que dans le cas OU le
: destinataire est bien valide dans le domaine ?
:
: J'ai rien vu dans les options de exchange 5.5 la dessus.
:
: merci de votre aide la dessus,
:
: Cyril Drouin
: Bysoft.fr

fred

30/01/2004 à 16:35

Je pense que le script que j'ai posté dans le topic "Solution au Virus (MyDoom)" fonctionne aussi sur Exchange 5.0.
A tester :)
En tout cas sur Exchange 2000, il supprime automatiquement les mails comportant le virus lors de leur arrivés sur le serveur. Donc pas de aucun Avis de réception est envoyés.

Fred.

-----Message d'origine-----
Nous avons un problème sur un serveur Exchange 5.5
configuré pour laisser entrer certains domaines locaux
(domain1.Com et domain2.com).

Depuis l'arrivée de MyDoom, nous recevons des milliers
d'email adressés à des utilisateurs de type
et MAIS
l'utilisateur n'existe pas sur le
domaine 'domain1.com', Exchange traite le mail
correctement et envoi un avis de non réception à
l'expéditeur.

Problèmes : parfois le domaine d l'expéditeur n'existe
pas, le fichier priv.edb grossit a vue d'oeil (Pourquoi ?
Exchange stocke t'il les messages quelquepart ??), le
priv.edb a explosé 2 fois en 24 heures.

Comment faire pour que les messages addressés à des
destinataires ne soient traités que dans le cas OU le
destinataire est bien valide dans le domaine ?

J'ai rien vu dans les options de exchange 5.5 la dessus.

merci de votre aide la dessus,

Cyril Drouin
Bysoft.fr
.

Thierry DEMAN [MVP]

30/01/2004 à 23:22

Cyril Drouin wrote:

Nous avons un problème sur un serveur Exchange 5.5
configuré pour laisser entrer certains domaines locaux
(domain1.Com et domain2.com).

Depuis l'arrivée de MyDoom, nous recevons des milliers
d'email adressés à des utilisateurs de type
et MAIS
l'utilisateur n'existe pas sur le
domaine 'domain1.com', Exchange traite le mail
correctement et envoi un avis de non réception à
l'expéditeur.

Problèmes : parfois le domaine d l'expéditeur n'existe
pas, le fichier priv.edb grossit a vue d'oeil (Pourquoi ?
Exchange stocke t'il les messages quelquepart ??), le
priv.edb a explosé 2 fois en 24 heures.

Comment faire pour que les messages addressés à des
destinataires ne soient traités que dans le cas OU le
destinataire est bien valide dans le domaine ?

J'ai rien vu dans les options de exchange 5.5 la dessus.

merci de votre aide la dessus,

Cyril Drouin
Bysoft.fr

Bonsoir,

dans la configuration du connecteur SMTP de Exchange 5.5, sur l'écran
indiquant le compte recevant les messages d'erreurs (généralement
l'administrateur), il suffit de décocher tous les cas d'erreurs pour les NDR
ne soient plus générés (de mémoire, y compris vers l'extérieur) !

A+

--
Thierry DEMAN-BARCELÒ
MVP Exchange,SQL/Server,[MCSE option Messaging, MCSA 2003].
FAQ Exchange: http://faqexchange.dyndns.org
Site personnel: http://webfamilial.dyndns.org/thierry/pageprincipale.htm

Probleme Exchange 5.5 et virus MyDoom

5 réponses

Veuillez sélectionner un problème