RE: Relaying Problem question - still fighting it!
- From: "KEN MORRIS" <KMORRIS@xxxxxxx>
- To: "[ExchangeList]" <exchangelist@xxxxxxxxxxxxx>
- Date: Tue, 30 Sep 2003 15:03:29 -0400
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
Other related posts:
