RELAY?? But I fixed it already!..now what? 30

[POSAPAY]

Hey all,

On my Exchange 5.5 I have setup the routing, as well as only except from authenticated sources.
Running McAfee GroupShield5.

yet .. currently the Queues is full with like 400-800 e-mails spinning through it constantly.
Destination is random, origin is "bluestell__@_______.___"
The underscores are random characters.
right after the bluestell, there are two characters that seem to follow the incremental rule with the alphabet.
starts out as "aa" and goes up to "zz" then restarts.
The domain after the @ seems to vary from e-mail to e-mail.
Mostly common domains, such as hotmail, yahoo, att.net..etc.

The headers seem to be missing, I can't figure out what IP or server it is coming from. Simply no header contents.

Anybody have any ideas? My usual daily 1500 e-mail traffic just went over last two days to 9000+ emails.

I just turned off notifications, and disabled outbound responses to reduce the e-mail count and processes...but I'm looking for a way to make sure this person can't connect to my server. Anybody have a similar case before?

Thanks,
-Peter

 

[tman138]

Wow. I don't know why I didn't check here first! I've been fighting this thing since September the 9th when the first 10000 e-mails in queue brought my 5.5 Exchange server to a halt. I finally today found that by checking the 'Clients can only submit if homed on this server' check box on the connections tab under IMS properties that this halted the slamming that I was taking. I've spent more time in the last 3 days on this server than I have in the last three years! Thanks for all the help!

 

[MusicManJoe]

Hello All,

Thanks again for assistance fixing the bluestell issue...

for a while I have seen messgages in the outgoing queue originating from <> I have checked the logs for allowed logons, they aren't coming from anyone listed there. Anyone know where they may be coming from?

Thanks
Joe

 

[ImWoody]

OK, same thing happens to me yesterday but I was able to discern the senders IP address by turning on SMTP Protocol and Interface logs. I blocked the address 211.158.88.246, which is another CHINANET Chongging province network IP address. There's a couple of things I've found out while researching this problem that might answer a few questions I've seen posted here.

1st: &quot;I've deleted all the messages in the queue and restarted the service with the machine unplugged from the network but more messages keep showing up.&quot;

This one boggled my mind too for a while but an in-depth search of the system log produced this:

&quot;Event ID:3038 An attempt to remove processed messages from the outbound store que has failed. The removal will be retried later. If the messages are not removed before the service is shut down, the mail will be resent at service startup causing duplicate mail.&quot;

The only way to avoid this is to shut down the service, go into the exchsrvr\imcdata folder and delete the contents of the &quot;out&quot; folder and the queue.dat file and then restart the service. Microsoft KB324059 article details this process. So there is no internal source or virus spamming your server....

2ND: &quot;I've applied all the patches and my system still allows e-mail to be relayed.&quot;

Yup, tore out handfuls of hair on this one too but I kept digging and found out that this is by design and that not everything you might think is happening, is actually happening. If someone sends and e-mail formatted like this name%otherdomain.com@yourdomain.com to your Exchange server, it will accept it and generate a NDR after failing a directory lookup. Microsoft says this is acceptable as it does not forward the message. Well, a great lot of help that is to us as our servers still have to process it. This is effectivly a DOS on our servers by flooding it with requests that the server will queue and attempt to process. This is all detailed BTW in Microsoft KB304897 article (look at example six) and can be verified at

http://members.iinet.net.au/~remmie/relay/

(look at the last test and then check you IMS queues)

The only true solution seems to be to go third party for a spam killing type of appliance or software as Exchange just doesn't cut the mustard.

Hope this helps!

ImWoody

 

[tahoe2]

This is what finally stopped the relaying in my domain:

set routing to route the domain to inbound, click on restrictions, and choose Hosts and Clients with these IP addresses, and leave the field blank. This effectively shuts the relay door. You can test by typing the following at a command prompt:

telnet servername 25

where servername is the name of your Exchange server. The Exchange server will respond with a message similar to 220 host.domain.com ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2650.10) ready. Then enter the following commands. The commands are case-sensitive, and the punctuation (e.g., colons, angle brackets—< >) is important, so include all the marks.

1 type
HELO me
The server will respond with 250 OK and possibly identify your IP address and your host name.

2 type
MAIL FROM: someaddress@somedomain.com
Again, the server will respond with 250 OK.

3 type
RCPT TO: nobody@afakedomain.com
The server will respond with 550 Relaying prohibited.

Using a valid address from your GAL, enter
RCPT TO: thegaladdress@yourdomain
The IMS will reply with 250 OK when it accepts the address.

To close the session, type
QUIT


If you do not get the 550 RELAYING PROHIBITED message, you need to try again.

So this stopped the main problem, now all I have to worry about is the 529 errors that pop up every 12 seconds on the security log...

thread10-659407 this helps!

Corie

 

[alanmalm]

The <> messages are typically NDR or (Non Delivery Report) messages from the Postmaster. Most often, this is what is called NDR spam which is a loophole in the RFC.

The fix in Exchange 5.5 and Exchange 2000 is a third party utility such as Praetor from cmsconnect.com or Mailsweeper. The best fix is Exchange 2003 where all this (and more) magically disappears! Exchange 2003 has RBL listing capabilities as well as the abilities to remove NDR spam.

You are absolutely right about what it is.

 

[alanmalm]

IMWOODY - -

&quot;If someone sends and e-mail formatted like this name%otherdomain.com@yourdomain.com to your Exchange server, it will accept it and generate a NDR after failing a directory lookup.&quot; You are correct!

&quot;Microsoft says this is acceptable as it does not forward the message. This is effectivly a DOS on our servers by flooding it with requests that the server will queue and attempt to process. This is all detailed BTW in Microsoft KB304897 article (look at example six) and can be verified at

http://members.iinet.net.au/~remmie/rela...;(look

at the last test and then check you IMS queues)&quot;

Right again, although it is not just Microsoft that says this. It is an RFC standard. The RFC requires the ability to send an NDR and you WANT this ability. Just for grins, what if I sent your company an email that would save you 10 million dollars and fumble-fingered the address? What if you didn't know I was sending it? You would never get the message and I would &quot;assume&quot; that you got it.

You wouldn't really know without calling or getting the NDR.

All the major spam lists only care if the message actually is relayed (not just accepted). Otherwise, EVERYONE would be on spam lists!!

--Alan

 

[RoundEye]

Well a friend of mine and I found a possible problem, we are still scanning the drives right now and have found two trojans so far. Netspy and executer, they scan random unassigned ports and steal passwords.

You can download the scanner from here,

http://www.softandco.com/download/Anti-Trojan/download988.html

Make sure it's updated and run a full scan. I was running Anasil network monitor and seen random port scans coming from the IP of the Exchange server. It would only try and connect to ports that were unassigned to other services or programs.

I'm sure he'll post later to fill y'all in with more details, but from reading through the thread it seems as if nobody has run a trojan scan yet. Norton Corporate didn't pick up either one of these trojans either.

Give it a try and see if it helps, we still don't know the full results yet because the scan isn't finished, but it can't hurt to try.

If you want to try Anasil, you can get a demo copy from here,

http://www.anasil.net/

 

[joeg701]

Thanks to everyone on this list for helping me find the problem with my server. Bluestell has sent 100,000 messages through my machine since September 2nd.
Here's something that might help others:

- Turn on SMTP Protocol logging to maximum.
- Wait for spammer to start using your open relay.
- Shut down IMS.
- Examine the protocol logs in \exchsrvr\imcdata\log
- Search for 'LOGIN authentication successful'
If found, you will see log entries like this:

9/11/03 6:12:54 AM : <<< AUTH LOGIN
9/11/03 6:12:54 AM : >>> 334 VXNlcm5hbWU6
9/11/03 6:12:54 AM : <<< YmFja3Vw
9/11/03 6:12:54 AM : >>> 334 UGFzc3dvcmQ6
9/11/03 6:12:54 AM : <<< ########
9/11/03 6:12:54 AM : >>> 235 LOGIN authentication successful

- Use a base-64 converter such as

http://www.wc.cc.va.us/dtod/base64/

to decode the characters above, and you will see what account is being used to break into your server.

9/11/03 6:12:54 AM : >>> 334 Username:
9/11/03 6:12:54 AM : <<< backup
9/11/03 6:12:54 AM : >>> 334 Password:
9/11/03 6:12:54 AM : <<< ########
9/11/03 6:12:54 AM : >>> 235 LOGIN authentication successful

 

[tHErEALfINSTER]

Some helpful (hopefully) information about our Blue Steel mystery person...

I visited the Blue Steel website, or at least one of them, and in the FAQ (

http://www.grasphere.com/twt/faq.html)found

the toll-free number, (888-271-1767). Of course I called and left a message, (no, not for their product...) , and then I searched out that number on Google and found it on another site, (

http://www.devineworld.com),

which has the phone number 310-459-2111, so I traced that number and found the following information listed in Google.

Ruedi Devine, (310) 459-2111, 18219 Coastline Dr, Malibu, CA 90265
R Schinz, (310) 459-2111, 18219 Coastline Dr, Malibu, CA 90265

Hope this helps.

Let me know if there is anything from this... I am sick of spam...

fINSTER (tHE rEAL oNE)

 

[roxannes]

fINSTER, what does any of this have to do with a company called Blue Steel?? Don't bother those poor people! All of the spam being talked about in this thread is using a bluestell** email address (bluestell, not bluesteel) and is coming from China.

 

[tHErEALfINSTER]

===================

To quote Posapay,

&quot;On my Exchange 5.5 I have setup the routing, as well as only except from authenticated sources.
Running McAfee GroupShield5.

yet .. currently the Queues is full with like 400-800 e-mails spinning through it constantly.
Destination is random, origin is &quot;bluestell__@_______.___&quot;
The underscores are random characters.
right after the bluestell, there are two characters that seem to follow the incremental rule with the alphabet.
starts out as &quot;aa&quot; and goes up to &quot;zz&quot; then restarts.
The domain after the @ seems to vary from e-mail to e-mail.
Mostly common domains, such as hotmail, yahoo, att.net..etc.&quot;

===================

Return-Path: <bluestellfg@hotmail.com>
Return-Path: <bluestellem@msn.com>
Return-Path: <bluestellkg@aol.com>
Return-Path: <bluestellod@msn.com>
Return-Path: <bluestelllj@earthlink.net>

Please forgive me if I'm wrong, but aren't the spam in question just a little like the ones I have listed above? Perhaps we're getting different spam. If so, I apologize.

If your spam, and my spam ARE from the same people, whom I like to think of as 'The Penis People', then the information I posted before should at least be considered a lead.

Roxanne, I could be WAY off base here, and I definately don't want to send the dogs after the wrong fox, so to speak. I found this thread because of my search for the people responsible for the spam in my inbox. I don't want to have to change my email address or email domain because of some yahoo. (pun intended).

If our spam IS the same stuff, simply follow the trail I outlined in my first post and check it out for yourself...

BTW, I'm not even sure there is anything we can do realistically or legally with this matter anyway. At least not from my out-of-country perspective. My tiny home-based business can muster little.

Anyway. Please respond and let me know if I am really this clever or not.

Thanks.

fINSTER

 

[POSAPAY]

fINSTER and roxannes,
you both have made a point, and while you both have your argument for it, these won't solve the issue with Exchange.

The patches are great.. the password changing is nice fix.
But I'm assuming, if one &quot;person/company/hacker&quot; was able to do it, then can others also do the same?

Can easy passwords be compromised in the future?
What can be done against it, and how are these passwords compromised?

I don't care if people like bluestell are out there or not, as long as the servers have proper protection, their existence won't even be known.

So how does a password compromise start?
What type of software is used for that, and how?
Any particular ports in use that admins should watch and log?


BTW...I wouldn't mind smacking the person that spamed my server...but unfortunately that won't solve the server's vulnerability.
Also... THANKS TO EVERYONE FOR YOUR HELP!
-Peter

 

[McRight]

hi, i did all what they said here to solve the problem described in the 2 first sections.
1/took the server offline
2/monitoring
3/after resetting the passwords and deleting unknown administrator accounts i saw indeed a backup user trying to connect
4/applied the post sp4 fix (ms02-11) included and all nt hotfixes available
5/queue kept on filling so i added all internal recepients to the restrictions tab and turned on relay to these ipadresses with all others blank
result : bluestell stopped ; a few <> appeared for 10 minutes and then mailserver was clean

i tried sending / receiving after applying all this and left
now i'm getting 550 5.7.1 relaying prohibited when sending to that domain.
telnetting is blocked so i can't check remote.
any suggestions on this ?
thanks

 

[georgeks]

Can you post more details? Have you checked

http://www.ordb.org

to see whether you re blacklisted or not? Misconfigured client / server? CAn you say more about what you did in step 5? The procedure i described above, except my exchange server has also being applied to 23 more exchange servers (in different domains)without any complications. Can you describe the configuration of your routing restrictions. Normally you dont have to fill in any ips . Sorry for the late post but i m out of the office most of the time.
Good luck and keep us informed
George

 

[LorenzoAdmin]

I have the same problem &quot;Bluestell&quot; spam mail.
I have followed all the Georgeks steps but the problem still exist.
I have changed all administrator users password with very strong password but I have always the same problem, in the event log I found:
Connection from 211.158.51.155 was successfully authenticated (AUTH LOGIN) as \administrator.
And many message in the outboud queue.
PLEASE HELP ME!!!!THANKS!!!

 

[cwright69]

I am having the same symptons on our server. Here are the steps I tackled to date:

1 - took the server out of production and updated all the patches for Exchange 5.5
2 - enabled all the logging to look for an account that might be used to send SPAM
3 - changed the password for every user, service, etc. on the NT box
4 - cleared out the pending emails
5 - basically, did everything listed here but the SPAM is STILL coming...

We run Norton Anti-Virus and a Trojan/Worm program, but they find nothing.

Anybody have any more ideas to resolve?

 

[tahoe2]

Add every IP you find in the event log to the 'IP addresses that can NEVER relay' box that under 'relay restrictions' on the routing tab.
Also, uncheck the box next to 'hosts and clients that successfully authenticate'.
Check the box next to 'hosts and clients with these IP addresses', but leave that box blank!

Hope this helps.

Corie

 

[thewell23]

Ok, I had this problem last week and it took about 6 or 7 hours to resolve. I tried everything that was posted up here through 9/23 but nothing worked. Ultimately, I applied the MS patch, stopped Exchange, deleted the in and out queues (yes emails will be lost) and then removed the Internet Mail Service and then re-created it. The user's Exchange box has been bluestell and NDR free for a week solid now, although I can see remote machines trying to connect using an \abc and an \administrator account. This might be worth a shot if you've tried everything else.

 

[Dreacle]

I had the bluestell spam here as well, and when I followed several of the steps above I found that the account that was connecting to our exchange server was one that did not exist on the machine at all. (nor on our domain).

It was &quot;admin&quot;. So I created the Admin account on the local machine, gave it a secure password, then disabled it. Spam stopped immediately and hasn't come back for 3.5 days now.

Hope this helps.

Cheers
David

 

[R1ck]

Well the same here,
but found out that the abused login (test) was not a local account, but an account from a trusted domain.
Disabled it and now waiting to see what happens in the next hours.