I've looked at this issue myself for my organization. You have some
security issues that you have to solve. First SSL by itself doesn't solve
completely your issues. With your current setup, you have some big
problems, you have IIS directly connected to the Internet and you can't
trust the client.

First issue: IIS directly connected to the Internet. Personally, I don't
trust IIS nor it's implementation of SSL because of the bug track record
(many other security professionals agree with me on this point). There have
been one or two issues that have allowed hackers to violate an IIS server
even prior to authenticating in the SSL connection. This is in addition to
the many many exploits that can occur during a web connection. And in your
case, the client can send any username/password to the server as many times
as he/she wishes. So a hacker can brute force attack a user's account to
gain access. Then with the other IIS vulnerabilities, he/she can exploit
the rest of the OWA service.

Second issue: you can't trust the client. SSLv3/TLSv1 comes in two forms
(IETF standard not the MS extensions for NTLM) for client side
authentication, basic and certificate. The basic authentication would allow
a hacker to brute force attack your system. The certificate based
authentication will prevent brute force attacks. (If your users lose their
keys, that is another matter.) However as others have pointed out,
certificate based authentication has it's own issues for administration.

Solution:

Put a reverse proxy in front of your IIS/OWA server (in a DMZ protected by a
firewall) with an SSL/TLS implementation that is well respected in the
security community. If you want to go cheap but good, then try Squid on a
Linux box. Disable SSLv2 and only allow strong ciphers (i.e. disable all
encryption ciphers below 128 bits.) On the reverse proxy enable client
authentication. You can use basic authentication if you use a strong
solution such as SecurID, S/Key, etc. or set up certificate authentication.
I would use a solution that can be enabled with a PKI such as Entrust.

On the reverse proxy, log all connections and use some sort of Intrusion
Detection system such as SNORT to monitor the traffic. Directly connect
(2nd interface) the reverse proxy to the IIS/OWA server (also in the DMZ).
At this point, you can either allow anonymous access to the login page on
the OWA server or you can again ask for a client side authentication. The
OWA server should be in it's own domain with a one-way trust to the other
domain(s) for your email clients. Make sure that the IIS/OWA and reverse
proxy servers are locked down accordingly and do NOT use any of the same
administrator passwords the same.

Basically what you've done now is provided an application proxy with strong/
two-factor authentication. Before an external person can even touch the
IIS/OWA server, you know who they are and are confident that they are
authorized. With the IDS system on the reverse proxy, you will get a good
idea if anyone is even trying to get in the front door. As a fall back, the
hacker has two systems to try and attack to get inside (security in-depth).

My .02
Ron Ogle
Rennes, France

> -----Original Message-----
> From: Evan Mann [mailto:emannquestinc.org]
> Sent: Thursday, January 03, 2002 5:10 PM
> To: 'focus-mssecurityfocus.com'
> Subject: Securing OWA w/SSL on IIS5.0
>
>
> I would like someone to tell me if what I did is the
> appropriate way to
> secure my OWA connections. The main goal was to secure the password
> exchange as my OWA server is firm external use and I have to allow
> anon/basic text auth for it. The OWA server itself sits
> behind my firewall
> and is accessed via an HTTP proxy from external to internal.
> SSL on port 443
> also NATs the same way.
>
> In any event, I found all the appropriate MS KB articles on
> setting up a CA
> and securing an IIS5.0 website with SSL. It was pretty
> basic. Installed
> the CA. Setup my OWA website with a certificate. Not much
> else needed to
> be done according to the KB articles. Now whenever I hit the site the
> typical IE popup about accepting a certificate pops up and I
> accept it and
> IE shows the page as being secured, and all further OWA pages.
>
> On my test computer, I also installed the certificated for
> the CA into my
> trusted certificates list. I do not plan to have all my
> users of OWA do
> this at this time, is this a good or bad idea?
>
> I am "ignorning client certificates" on my particular website, mainly
> because I am clueless as to how to configure these, and when
> I use "accept
> client certificates", I get an additional certificate box
> where I am to
> select a certificate, but none are in a list to select.
>
> Am I at the point where I'm actually encrypting the password
> exchange and
> all other data sent over OWA, or do I have a false sene of security?
>
> Evan Mann
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]