dsstao
asked on
Finding out which user is infected and sending spam
Hi all,
The title pretty much says it all. I've got a situation where there are about 25 users at one of my clients and their exchange server just got blacklisted for sending spam. I log in and sure enough, there are well over 300 queues to various bogus domains and such. The problem is, I isolated the exchange server from the rest of the network, which caused the queue creation to stop, but as soon as I reconnect it, the queues start building up again.
How do I find out which workstation is presumably infected with Beagle/Sasser/etc... and sending all this bogus mail to the exchange server to be sent out?
Thanks,
Dave
The title pretty much says it all. I've got a situation where there are about 25 users at one of my clients and their exchange server just got blacklisted for sending spam. I log in and sure enough, there are well over 300 queues to various bogus domains and such. The problem is, I isolated the exchange server from the rest of the network, which caused the queue creation to stop, but as soon as I reconnect it, the queues start building up again.
How do I find out which workstation is presumably infected with Beagle/Sasser/etc... and sending all this bogus mail to the exchange server to be sent out?
Thanks,
Dave
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
That will be an NDR attack then.
Which version of Windows?
If it is 2003, then get SP1 for Windows 2003 on the machine and enable the recipient filtering.
Any reason you aren't on Exchange 2003 SP2? It will not have a direct affect, but is advisable.
Simon.
Which version of Windows?
If it is 2003, then get SP1 for Windows 2003 on the machine and enable the recipient filtering.
Any reason you aren't on Exchange 2003 SP2? It will not have a direct affect, but is advisable.
Simon.
ASKER
Actually, I got it reversed, I do have Win2k3 SP1 and Exchange 2003 SP2 already installed. What is recipient filtering and how should I enable it? Will this solve the NDR attach problem?
Recipient Filtering is outlined in my article above.
It basically means that Exchange doesn't accept email for users who don't exist on your server.
What you are seeing is an NDR attack.
This is where emails are sent to your server with invalid users on purpose. The server then tries to bounce the email to the "sender" of the message, except the sender is the real target.
Simon.
It basically means that Exchange doesn't accept email for users who don't exist on your server.
What you are seeing is an NDR attack.
This is where emails are sent to your server with invalid users on purpose. The server then tries to bounce the email to the "sender" of the message, except the sender is the real target.
Simon.
ASKER
Thanks, and I didn't RTFA (sorry, busy day). I set the recipient filter, but I also need to enable this on the SMTP virtual server. Unfortunately, it's not there! Seriously, I browse under <servername>, Protocols, SMTP, and there's nothing there. I try to create a new one, no dice. I try to stop exchange services (to restart them), they hang in a stopping state. Time for an after-hours reboot!
While I do the reboot, I have a quick question - does setting the recipient filter solve the NDR attach problem because it won't send an NDR? If so, how do legitimate senders know if they've misspelled a recipient name?
While I do the reboot, I have a quick question - does setting the recipient filter solve the NDR attach problem because it won't send an NDR? If so, how do legitimate senders know if they've misspelled a recipient name?
Did you go far enough in to the virtual server properties? I assure you it is there?
I am surprised that no one has posted the usual "fix" for this problem which is to disable the delivery of NDRs. All that fix does is hide the problem, rather than resolve it.
What it does is stop the connection from being made, rather than accepting the email and trying to deliver it. The message is refused at the SMTP level.
If a genuine sender gets a spelling wrong, then they will get an NDR back immediately from their own server, as your server has rejected the message.
Recipient Filtering is very effective at dealing with this problem while ensuring that genuine senders know that their email has failed.
Simon.
I am surprised that no one has posted the usual "fix" for this problem which is to disable the delivery of NDRs. All that fix does is hide the problem, rather than resolve it.
What it does is stop the connection from being made, rather than accepting the email and trying to deliver it. The message is refused at the SMTP level.
If a genuine sender gets a spelling wrong, then they will get an NDR back immediately from their own server, as your server has rejected the message.
Recipient Filtering is very effective at dealing with this problem while ensuring that genuine senders know that their email has failed.
Simon.
ASKER
Thanks for the clarification, and I can assure you in return that it is indeed not present. I have setup many exchange servers and I know where to look. Interestingly enough, the whole system seems "flaky" right now - I'm getting problems unrelated to Exchange both on a services level and a general stability level. For example, Backup Exec services are failing and erroring out with the "Send error report now" message, etheral closes by itself after a couple of successful scans and other services are hung in a "stopping" state. Looks like I've got work to do all around. I assume when I bounce it, the SMTP virtual server will re-appear.
Also, thanks for the information about the SMTP-level bounce. I was always curious as to how that worked. Unfortunately, it might be used by potential spammers to zero in on which addresses are actually valid and pour a torrent of messages towards them (at which point my postfix/amavisd anti-spam linux box will probably catch them).
Thanks for the article, too. I read it and got the info about how to cleanup the queues as well. While I'm assuming you've helped me solve the problem, I would like to make sure, for everyone's benefit, prior to awarding the points (which should be late today or early tomorrow).
Also, thanks for the information about the SMTP-level bounce. I was always curious as to how that worked. Unfortunately, it might be used by potential spammers to zero in on which addresses are actually valid and pour a torrent of messages towards them (at which point my postfix/amavisd anti-spam linux box will probably catch them).
Thanks for the article, too. I read it and got the info about how to cleanup the queues as well. While I'm assuming you've helped me solve the problem, I would like to make sure, for everyone's benefit, prior to awarding the points (which should be late today or early tomorrow).
What you have described as being used by spammers is covered. That is known as a directory harvest. If you look at the web page on my site where I outlined how to set the feature I also stated how to enable the tar pit. Do both, not just recipient filtering - otherwise you do expose the server.
Simon.
Simon.
ASKER
Thanks Simon, this ended up being the exact answer I needed for this topic. On another topic, which I addressed with MS was the missing SMTP virtual server, failing dcdiag and netdom query fsmo runs among other stuff (fun fun) on this server.
Thanks!
Thanks!
ASKER
I did check the queues and it is indicating postmaster@ is the sending entity. The version I'm using is Exchange 2003 with SP1 (version 6.5, build 6944.4).
Dave