open relay is closed but yet i'm being used to relay spam - Microsoft Exchange

Hello,

The symptoms you describe are not necessarily those of a relay. If your org
receives spam for non-existant recipients, it will attempt to send an NDR.
Obviously the reply address is bogus thus a full queue. After the timeout
period, these messages (among others) are deleted and dropped into the
badmail folder with the extensions you mentioned.

If you're still not convinced (and depending on the complexity of your
Exchange setup, it may be a good idea), due to routing costs setup, the
server you are referring to may be routing for an open server somewhere
else.

HTH

Mark

PS: There are a number of sites that will comprehensively test your server
to check relaying ability. The drawback is that if you are, they
automatically add you to a blacklist. www.ordb.org is one such site.



"JA" <none@nospam.com> wrote in message
news:O53VjLZqDHA.2312@TK2MSFTNGP12.phx.gbl...
> i've checked everywhere, even tested to see if i can telnet into port 25
and
> send messages without authenticated but it says relaying not allowed.
>
> then why is it that my server can still be used to send spam?
>
> how can i tell? i see all these messages stuck in my
> c:\exchsrvr\mailroot\vsi 1\queue directory
>
> there are all these .eml files. when i open one to read, it has a totally
> different from address. and the content of the message is definately
> spam.
>
> i am using exchange 2000 sp3 and windows 2000 server sp4
>
> how the heck is my server still being used as a relay? AND... there are
all
> kinds
> of junk in this directory too:
> c:\exchsrvr\mailroot\vsi 1\badmail
> *.bdp
> *.bdr
> *.bad
>
> whats going on? any advice would be appreciated... you can send me an
email
> directly at amihara@nospam.hawaii.edu if you want (without the nospam of
> course).
>
> thanks!
>
>

Hi JA,

You are being used as an Authenticated Relay. What you need to do is go into
the properties of your Default Virtual server and under relay settings take
the check out of "Allow all computers which successfully authenticate to
relay, regardless of the list above". Restart the SMTP and the Routing
Engine Services. Once you stop the SMTP Service you can rename the Mailroot
folder to Mailroot.old and then start the SMTP Service back up, this will
create a clean Mailroot folder and you will not have to deal with all the
Spam in the Queue folder. At this point you can just delete the
mailroot.old.

Hope this helps,
--
Patrick Genova
Pgenova@online.microsoft.com
Please do not send mail directly to this alias.This alias is for newsgroup
purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

That's not an option if you have to support POP3/SMTP and IMAP users. Also,
unless the messages that are stuck in the queue are actually being
delivered, there is no reason to suspect that he is being used as an
authenticated relay. Exchange will also freely accept messages with an
encapsulated smtp address, but it will later reject them.

--
Ben Winzenz
Network Engineer
Gardner & White

Exchange FAQ's: http://www.swinc.com/resource/exch_faq.htm
Exchange 2000 FAQ's: http://www.swinc.com/resource/e2kfaq.htm


"Patrick Genova (MSFT)" <pgenova@online.microsoft.com> wrote in message
news:OAMjG4dqDHA.2620@TK2MSFTNGP09.phx.gbl...
> Hi JA,
>
> You are being used as an Authenticated Relay. What you need to do is go
into
> the properties of your Default Virtual server and under relay settings
take
> the check out of "Allow all computers which successfully authenticate to
> relay, regardless of the list above". Restart the SMTP and the Routing
> Engine Services. Once you stop the SMTP Service you can rename the
Mailroot
> folder to Mailroot.old and then start the SMTP Service back up, this will
> create a clean Mailroot folder and you will not have to deal with all the
> Spam in the Queue folder. At this point you can just delete the
> mailroot.old.
>
> Hope this helps,
> --
> Patrick Genova
> Pgenova@online.microsoft.com
> Please do not send mail directly to this alias.This alias is for newsgroup
> purposes only.
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
>

On Wed, 12 Nov 2003 17:04:42 -1000, JA <none@nospam.com> wrote:
> i've checked everywhere, even tested to see if i can telnet into port 25 and
> send messages without authenticated but it says relaying not allowed.
>
> then why is it that my server can still be used to send spam?

http://www.securiteam.com/windowsntf...SP04206KG.html

Or:

http://www.spamhaus.org/rokso/search...dencefile=2669
http://www.vamsoft.com/orf/authattack.asp

Please note that the advice in the above vamsoft.com URL does not
appear to work in all circumstances, and in particular is entirely
ineffective in a Small Business Server 2000 environment. We have not
yet had one customer who has been able to secure a Small Business
Server 2000 installation satisfactorily against this SMTP AUTH
vulnerability, to the best of my knowledge.

Given that the unscrupulous bulk emailers currently exploiting SMTP
AUTH are running brute force username and password cracking programs
against target machines for as long as it takes (one customer reported
having examined their logs that such a program ran against their
machine continuously for a period of 3 consecutive weeks before a
vulnerable username and password was found), this exploit (short of
turning SMTP AUTH off altogether, which does not appear to be possible
in a Small Business Server 2000 environment as previously mentioned)
is extremely hard to defend against.

SMTP AUTH, and to a lesser extent the NTLM vulnerability referenced
in the first URL above, currently represents approximately 75-85% of
the Unsolicited Bulk Email related complaints that we are receiving
in respect of the easynet UK customer base, so it would be extremely
helpful if:

1. Microsoft were to acknowledge that SMTP AUTH hijacking vulnerability
is a widespread, serious shortcoming in various Microsoft mail
server platforms affecting both the infrastructure of the Internet
and the esteem in which their products are held by end users (some
customers affected by this are migrating from Exchange altogether,
or installing *nix based MTAs in front of their Exchange Servers to
protect them from abuse) which does not currently appear to be the
case, and;

2. Designed and implemented a fix for this issue which end users can
easily install and apply, in the form of a Service Pack or patch
which remedies the issue for most users in most cases, including
a security fix which prevents, *by default*, the use of insecure
passwords and also disables all default accounts with weak (or no)
passwords until the system's administrator intervenes manually and;

3. Published an advisory, and such a Service Pack or patch, on their
web site and also made that information available to abuse teams
at ISPs such as ourselves.

Unfortunately, as things stand at present, the insecurity in this
respect of Exchange Server 5.5, Exchange Server 2000 and (in
particular) Small Business Server 2000 is a large and still increasing
problem.

--
Anthony Edwards * anthony.edwards@uk.easynet.net
Abuse Team Manager * Tel: 0800 053 0588
Easynet Ltd * DDI: 0161 227 0707
http://www.uk.easynet.net * Fax: 0845 333 4503

thanks! that seems to have done the trick... for now...

"Patrick Genova (MSFT)" <pgenova@online.microsoft.com> wrote in message
news:OAMjG4dqDHA.2620@TK2MSFTNGP09.phx.gbl...
> Hi JA,
>
> You are being used as an Authenticated Relay. What you need to do is go
into
> the properties of your Default Virtual server and under relay settings
take
> the check out of "Allow all computers which successfully authenticate to
> relay, regardless of the list above". Restart the SMTP and the Routing
> Engine Services. Once you stop the SMTP Service you can rename the
Mailroot
> folder to Mailroot.old and then start the SMTP Service back up, this will
> create a clean Mailroot folder and you will not have to deal with all the
> Spam in the Queue folder. At this point you can just delete the
> mailroot.old.
>
> Hope this helps,
> --
> Patrick Genova
> Pgenova@online.microsoft.com
> Please do not send mail directly to this alias.This alias is for newsgroup
> purposes only.
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
>

NO.

No way ... We are just like Exchange 2k dude. Untick the box and
problem solved.

"We disabled the SMTP Server services' ability to relay for anyone
other than the internal IP subnet and external network card regardless
of authentication - this step would prevent any future password style
attacks on it's relay ability. The only downside was that some remote
staff used the POP3/SMTP facilities with their Outlook Express clients
- we reconfigured these guys to use VPN first so that the could still
use this facility."

Let me repeat this ...there is NOTHING is SBS to make us any different
than our big brothers. What happens to you guys... happens to us.

There probably was a guest account or password still cracked.

SBSFAQ.COM:
http://www.sbsfaq.com/news/getArticl...00B1E572030000


Anthony Edwards <anthony.edwards@uk.easynet.net> wrote in message news:<vr7av0jdau4849@news.supernews.com>...
> On Wed, 12 Nov 2003 17:04:42 -1000, JA <none@nospam.com> wrote:
> > i've checked everywhere, even tested to see if i can telnet into port 25 and
> > send messages without authenticated but it says relaying not allowed.
> >
> > then why is it that my server can still be used to send spam?
>
> http://www.securiteam.com/windowsntf...SP04206KG.html
>
> Or:
>
> http://www.spamhaus.org/rokso/search...dencefile=2669
> http://www.vamsoft.com/orf/authattack.asp
>
> Please note that the advice in the above vamsoft.com URL does not
> appear to work in all circumstances, and in particular is entirely
> ineffective in a Small Business Server 2000 environment. We have not
> yet had one customer who has been able to secure a Small Business
> Server 2000 installation satisfactorily against this SMTP AUTH
> vulnerability, to the best of my knowledge.
>
> Given that the unscrupulous bulk emailers currently exploiting SMTP
> AUTH are running brute force username and password cracking programs
> against target machines for as long as it takes (one customer reported
> having examined their logs that such a program ran against their
> machine continuously for a period of 3 consecutive weeks before a
> vulnerable username and password was found), this exploit (short of
> turning SMTP AUTH off altogether, which does not appear to be possible
> in a Small Business Server 2000 environment as previously mentioned)
> is extremely hard to defend against.
>
> SMTP AUTH, and to a lesser extent the NTLM vulnerability referenced
> in the first URL above, currently represents approximately 75-85% of
> the Unsolicited Bulk Email related complaints that we are receiving
> in respect of the easynet UK customer base, so it would be extremely
> helpful if:
>
> 1. Microsoft were to acknowledge that SMTP AUTH hijacking vulnerability
> is a widespread, serious shortcoming in various Microsoft mail
> server platforms affecting both the infrastructure of the Internet
> and the esteem in which their products are held by end users (some
> customers affected by this are migrating from Exchange altogether,
> or installing *nix based MTAs in front of their Exchange Servers to
> protect them from abuse) which does not currently appear to be the
> case, and;
>
> 2. Designed and implemented a fix for this issue which end users can
> easily install and apply, in the form of a Service Pack or patch
> which remedies the issue for most users in most cases, including
> a security fix which prevents, *by default*, the use of insecure
> passwords and also disables all default accounts with weak (or no)
> passwords until the system's administrator intervenes manually and;
>
> 3. Published an advisory, and such a Service Pack or patch, on their
> web site and also made that information available to abuse teams
> at ISPs such as ourselves.
>
> Unfortunately, as things stand at present, the insecurity in this
> respect of Exchange Server 5.5, Exchange Server 2000 and (in
> particular) Small Business Server 2000 is a large and still increasing
> problem.