[Snort-sigs] SID 567

Warchild warchild at ...288...
Tue Jan 22 20:11:01 EST 2002


Rule:  
alert tcp $SMTP 25 -> $EXTERNAL_NET any (msg:"INFO SMTP relaying denied"; flags: A+; content: "550 5.7.1"; depth:70; reference:arachnids,249; classtype:misc-activity; sid:567; rev:5;) 
--

Sid: 567

--
Summary:
A remote machine attempted to perform an unauthorized mail relay through a
mail server 

--
Impact:
Simply a client misconfiguration or a relatively harmless reconnaissance
technique. 

--
Detailed Information:
A remote mail client attempted to send mail to a domain other than that of
the mail server ("relaying") or to a domain that the server does not
explicitly allow relaying for. 

--
Attack Scenarios:

A simple reconnaissance technique could resemble the following to see if a
machine (in this case, neu.edu) allows mail relaying:

warchild at ...292...
[~]$ telnet neu.edu 25
Trying 155.33.211.90...
Connected to neu.edu.
Escape character is '^]'.
220 www.neu.edu running Eudora Internet Mail Server 2.2.2
helo foo.bar.com
250 www.neu.edu hello foo.bar.com (4.62.117.170)
mail from: warchild_is_a_spammer at ...288...
250 2.1.5 sender OK
rcpt to: my_spamlist at ...293...
550 5.7.1 relay restricted

More advanced techniques included "scripted" attacks that may try lists of
mail servers for "open relays", to software packages dedicated to testing
for open relays and other methods of spamming.

This rule may also be triggered by innocent misconfigurations in mail clients.

--
Ease of Attack:
Trivial.

--
False Positives:
Unknown.

--
False Negatives:
Not all mail servers "550 5.7.1" upon disallowing relaying, so a
considerable portion of relay attempts may go un-noticed.


--
Corrective Action:
Ensure that your mail server does not allow mail relaying.  If you need to
allow relaying, ensure that the rules you use to determine who can relay
and who cannot are up-to-date, accurate, and logical.  

If you do not allow relaying, consider reporting repeated abuse to the
owners of the netblock where the attack originated from.  If the "attacks"
appear to be from client misconfiguration, consider a how-to instructing
employees/users on proper use and configuration of their mail client(s)>
If the "attacks" appear to be from client misconfiguration, consider a
how-to instructing employees/users on proper use and configuration of their
mail client(s).

--
Contributors:
Warchild <warchild at ...288...>
Jon Hart <jhart at ...289...>

-- 
Additional References:
http://mail-abuse.org/tsi/ar-fix.html







More information about the Snort-sigs mailing list