RE: Relaying Problem question - still fighting it!
- From: "John Tolmachoff \(Lists\)" <johnlist@xxxxxxxxxxxxxxxxxxx>
- To: "'[ExchangeList]'" <exchangelist@xxxxxxxxxxxxx>
- Date: Tue, 30 Sep 2003 12:14:50 -0700
You should be able to fine where those messages are coming from. What user
are they using to authenticate?
If you need to, you can send me your logs (zipped) off list and I will help
you review them.
Also, is there any other software, such as AV gateways, that could be
allowing relaying? It has been proven that some AV gateways and
misconfigured ones will allow open relaying.
Have you tested to see if the server is a relay without authenticating?
John Tolmachoff MCSE CSSA
Engineer/Consultant
eServices For You
www.eservicesforyou.com
-----Original Message-----
From: KEN MORRIS [mailto:KMORRIS@xxxxxxx]
Sent: Tuesday, September 30, 2003 12:03 PM
To: [ExchangeList]
Subject: [exchangelist] RE: Relaying Problem question - still fighting it!
http://www.MSExchange.org/
Chris,
I saw your previous email and added the IP's on Monday, however it appears
that what ever user has been compromised, they have gone to town with it and
given it out to others. I am now finding my queues filling up with many
others and the Bluestell group is not able to get in. So this is why I
question a forced change on the entire domain for passwords.
So now my next question is.... How do I effectively stop the newest attack?
Thank you for your help.
Ken
-----Original Message-----
From: Allen, Chris [mailto:CAllen@xxxxxxxxxxxxxxxx]
Sent: Tuesday, September 30, 2003 2:20 PM
To: [ExchangeList]
Subject: [exchangelist] RE: Relaying Problem question - still fighting it!
http://www.MSExchange.org/
I was in the exact same boat. This is what we did to resolve it:
In Exchange System Manager ->Administrative Groups->site
name->Servers->server name->Protocols->SMTP->Default Smtp Virtual Server
properties, select the Access tab, then click the relay button. In the Relay
Restrictions window, we allowed "All except the list below" and added the
firewall's internal IP as our firewall NATs all traffic including SMTP
making all inbound email to appear to be coming from the firewall IP. What
this does for us is lets our internal users relay since we have some apps
that must be able to, but at the same time, stops all outbound traffic from
relaying. This may differ for you. Chances are, you will need to select
"Only the list below" and put in your internal network range.
Now, the important part, Uncheck the "Allow all computers which successfully
authenticate to relay, regardless of the list above." What this will do is
confine relaying to the internal IPs, No longer will an external user be
able to relay using an authenticated user's information.
We were having issues with a spam gang out of the Chongqing province of
china. They brute force attacked our network in an attempt to find valid
user-name/passwords and then, when found, started relaying through us
regardless of our IP restrictions. Unchecking the box put a stop to that.
It is still a good idea to reset passwords though as you really don't know
which accounts have been compromised. Yeah its an inconvenience, but not as
much as some malicious entity using your network to wreak havoc.
Is the spam all originating from bluestellnn@xxxxxxxxxx where domain.com is
some random, yet valid domain (ie yahoo.com) and the nn is an enumeration?
If so, it is the same gang and you might want to add their ip range to a
deny rule in your firewall. It is as follows:
211.158.32.0/20
211.158.48.0/21
211.158.80.0/20
219.153.144.0/20
After doing these steps, the spam has disappeared from my queues.
If this works for you, we might want to see if we can get Microsoft to
document this in their knowledge base.
Chris Allen
Systems Administrator
Metron North America
-----Original Message-----
From: KEN MORRIS [mailto:KMORRIS@xxxxxxx]
Sent: Tuesday, September 30, 2003 1:32 PM
To: [ExchangeList]
Subject: [exchangelist] Relaying Problem question - still fighting it!
http://www.MSExchange.org/
Hi,
Our server has been compromised by an outside session using an internal
name/password, and our E2K server queues keep on filling up. I have had up
to 400 queues created over night and some of the queues can have well over
600 messages each waiting to be sent (I have frozen most of my queues as a
precaution). These relays are being set up after we are closed.
I am curious to see if anyone can answer the question of who would have the
rights to create a remote session to relay? Does it have to be an admin
account or can it be a standard user?
I have eliminated the Fire Wall by placing it on the restrictions for the
SMTP. and have unchecked the allow all to relay. So I am stumped as to how
they are still being able to set up the relaying. My next plan is a forced
network wide password change, after that...... I have to come up with a
"Plan C".
I am having the problem of trying to convince the powers that be, that all
user accounts need to have their passwords changed in order to eliminate
this hack. I am also recommending that our Domain Admin accounts be made
into guest accounts and new Domain Admin accounts be created. Does anyone
have any other suggestions and or reading that I could do. So far I have
found very little on this type of attack.
Thanks for your help!
Ken
------------------------------------------------------
List Archives: http://www.webelists.com/cgi/lyris.pl?enter=exchangelist
Exchange Newsletters: http://www.msexchange.org/pages/newsletter.asp
Exchange FAQ: http://www.msexchange.org/pages/larticle.asp?type=FAQ
------------------------------------------------------
Other Internet Software Marketing Sites:
Leading Network Software Directory: http://www.serverfiles.com
No.1 ISA Server Resource Site: http://www.isaserver.org
Windows Security Resource Site: http://www.windowsecurity.com/
Network Security Library: http://www.secinf.net/
Windows 2000/NT Fax Solutions: http://www.ntfaxfaq.com
------------------------------------------------------
You are currently subscribed to this MSExchange.org Discussion List as:
johnlist@xxxxxxxxxxxxxxxxxxx
To unsubscribe send a blank email to
$subst('Email.Unsub')
Other related posts:
