Security for AD Exchange 2000 Server

Darksamie

Senior member
Mar 23, 2000
220
0
0

I am going to open up my Exchange 2000 server to the net so that people can log in to OWA. The main concern with this is security.

At present, I have the following in place:

- Watchguard Firebox 700 running SMTP and HTTP proxies (killing most of the bad stuff)
- Microsoft Baseline Security Analyser & IISLockdown
- Innoculate IT with Exchange option

Is there anything else that I can do to make sure that no one will get into this exchange server and cause problems for me? I would be very interested to hear from any IT managers out there who have effective security policies for this kind of environment (IIS).

Thanks
 

Saltin

Platinum Member
Jul 21, 2001
2,175
0
0
The first thing you are going to want to do is ensure you patch your IIS all the way up. Put down SP3 for Win2k. then apply and hotfixes.

The next thing to do is to implement SSL. You don't want your users accessing OWA by HTTP as they will be logging on with thier NT credentials in plaintext.

If you set up SSL (HTTPS), credentials will be encypted. Much more secure.

If you don't know how to set that up, look into it. There are plenty of article in Technet, and it is worth the small amount of trouble.
 

Tallgeese

Diamond Member
Feb 26, 2001
5,775
1
0
The security holes in various releases of OWA have been well-documented.
The number varies depending on who you talk to, but there have been AT LEAST 5 major vulnerabilities (issues that would offer control of the entire server to an attacker) in the different versions of OWA over the last 2 years.
Since OWA relies on IIS, then IIS vulnerabilities can also come into play.

In single server implementation, where the OWA web host is also the primary Exchange server, you are at greater risk.

At a minimum, I would probably configure a front-end OWA host in a DMZ, to afford protection to the main Exchange server from direct attacks using the OWA sessions.
However, that doesn't seem to be in play here.

That being said, I think OWA can be a great solution for many folks.
However, the security implications of OWA are significant, IMHO.
 

Darksamie

Senior member
Mar 23, 2000
220
0
0

Would having a front end OWA server really make much of a difference? If they compromised the front end server then they would definately be able to get into the main exchange server.

Please correct me if I am wrong...
 

N11

Senior member
Mar 5, 2002
309
0
0
At a minimum, I would probably configure a front-end OWA host in a DMZ, to afford protection to the main Exchange server from direct attacks using the OWA sessions.
However, that doesn't seem to be in play here.


From my experience this is one of the more challenging implementations in a DMZ. I've made various attempts in both checkpoint and sonicwall environments for getting this scenario to work -- referencing off of an MS technet article on the necessary ports to open as well as a maybe/youmightneedthis registry hack with no luck.

I'm not a security expert but even in the checkpoint environment where a checkpoint guru counterpart was unable to get it working the solution was everything wide open between the frontend and the exchange 2k server in the lan.

If you seriously have gotten this to work please let me know as I cannot and do not have the experience to. The MS recommended ports to for authentication and communication have never worked for me.
 

Tallgeese

Diamond Member
Feb 26, 2001
5,775
1
0

Tallgeese

Diamond Member
Feb 26, 2001
5,775
1
0
Originally posted by: Darksamie
Would having a front end OWA server really make much of a difference? If they compromised the front end server then they would definately be able to get into the main exchange server.
Maybe, maybe not...but probably so. Especially if using an "Allow all" configuration like N11 described.
The dependence upon RPC calls through the firewall for OWA function seems mighty spooky to me.
 

Tallgeese

Diamond Member
Feb 26, 2001
5,775
1
0
Originally posted by: N11
From my experience this is one of the more challenging implementations in a DMZ.
You ain't just whistlin Dixie brother!
If you seriously have gotten this to work please let me know as I cannot and do not have the experience to. The MS recommended ports to for authentication and communication have never worked for me.
I did get this type of setup to work in a test only implementation...and damned if I can remember what the magic answer was. We were, however, able to use granular access control at the firewall, and weren't allowing all ports between the back-end Exchange server and the front-end OWA box. I'll see if I can dig up any old configs or notes on it tomorrow.

My office looks like a war zone right now, so it might take awhile to find.
 

N11

Senior member
Mar 5, 2002
309
0
0
No, the traffic was never sniffed -- after the registry modifications failed to provide results I terminated the quest.

I've always wanted to see the scenario work -- even given how terribly vulnerable IIS can leave a segment or even an entire network in situations as described earlier. At the time at the given location checkpoint 3.0b was being run, I'm sure several advances have been made up to 4 and to whatever they have now.

What I do know is that it was a tremendous pain at the time and the quick solution was to lock down IIS and pass through everything -- not much different than dropping it in the lan, translating the traffic and preventing outbound from it. I did find the IIS lockdown utility to be relatively useless my first attempts with it -- more out of curiosity as to what damage it would cause in an OWA frontend environment than anything. Disabling scripts from executing making asp non-functional including the logoff page -- even re-enabling just scripting never did bring back script execution. Anyway, all of this is why I don't take interest in microsoft tainted networks.
 

Saltin

Platinum Member
Jul 21, 2001
2,175
0
0
I've had arguments about the DMZ implementation before. I don't agree with it and think it's a bad idea.

If I break into a DMZ, I should, by definition, not be able to effect any machines other than the machines in the DMZ. If you allow LDAP, Kerberos, etc from the private network into the DMZ (which you need to do with Exchange 2000 OWA), you are essentially nullifying any security the DMZ may provide. It makes no sense whatsoever.

It is a much better option to simply ensure OWA is available only over SSL (HTTPS), and then publish port 443 through your firewall to the OWA machine. The fact that port 80 is not published reduces the danger of worm scans (Nimda, Code Red, etc), as they look for/at port 80. SSL will also encrypt authentication, which is necessary IMO.

The problems with OWA and IIS arent necessarily the products themselves (although admittedly, they do require patching and dilligent maintenance), the problems lay in the methods people use to implement the products.
The DMZ method never made any sense to me, and I would never use it.

A well patched IIS running OWA over HTTPS is not easy to hack, at least with any documented exploits. That's good enough for me. Add to this the fact that nothing else even comes close to the functionality and features available with OWA, and the risk is acceptable.

No product is 100%, I focus on maximizing the percentage, and I don't worry about the rest. I could get hacked, sure... I could get hit by a bus too.
 

Woodie

Platinum Member
Mar 27, 2001
2,747
0
0
Add the URLScan utility on the IIS front end. Otherwise, it can pass malformed URLS right through the front end server, directly to the backend exchange server, and compromise THAT server.

DMZ is very hairy, we canceled the whole project rather than do that.

OWA is problematic from a security perspective, and we haven't come to a completely satisfactory answer. Well, we found a way that we were comfortable with, but there weren't enough $$ for it. (Involved a third party URL filtering firewall from Whale Communications, and an ISA box).
 

Saltin

Platinum Member
Jul 21, 2001
2,175
0
0
Another option, that alot of places use now, is OWA via VPN only. The site is an internal site, and you cant access it unless you VPN in first. That's about as good as it gets.
 

Darksamie

Senior member
Mar 23, 2000
220
0
0

I was thinking of using SSL for all remote logins and closing port 80 alltogether. This would seem to be the best way to protect the server, however my only worry is that some people won't be able to get into OSA from certain remote sites.

I would think though, that reducing the risk should be a lot more important than this :)

I am going to look into securely configuring OWA over SSL and see how that goes.

Are there any FAQ's that may be of use with this?

 

Woodie

Platinum Member
Mar 27, 2001
2,747
0
0
Do you use bad password lockouts? If so, keep in mind that anyone on the Internet can browse to your OWA site, and try logins until the accounts locks out. Could make life for internal employees "interesting"!