Hardening SBS / OWA

dave-lew99

dave-lew99

dave-lew99

Associate
Joined
14 Apr 2008
Posts
1,230
Location
Manchester
I'm in the midst of putting a proposal together for my boss for us to buy SBS Server, mainly to make my job easier - i'm a Dev who also looks after the company IT.

It would let us do all the nice AD stuff as well as the exchange calander/contacts/mail facilities.

At the moment we have an LDAP server which does auth for some network services and a postfix/dovecot setup for email.

The main stumbling block is being able to convince my boss that it will be safe to put OWA on the web. Obviously it'll be SSL enabled and from what i've read, use FBA.

How else can i harden the box? The plan was just to forward ports 25 and 443 from the web using our ordinary Draytek router, i've seen that people publish OWA through ISA server though.

What else could i do to protect it from attacks?
 
Standard IIS hardening checklists, you can publish it through ISA but don't, it's the most horrendous pain going (describes ISA in general of course).

90% of large corporates are simply forwarding 80/443 in the firewall. Of course they're running dedicated front ends for OWA in seperate security zones but still.

If you're exceptionally paranoid pay your firewall vendor for an IDP subscription and put an inspect rule on all the forwarded traffic..
 
If you are PARTICULARLY bothered about putting it out on the open net then implement a VPN solution for your end users to access it remotely, on the internal LAN.

A Sonicwall SSL-VPN appliance would not run you much at all and would handle it.
 
Thanks for the info and links guts, the IIS checklists look particularly useful, in this case it'll be SBS server - so doing our AD etc and no front/back end style configuration.

We specifically want to be able to do push email to mobiles so the VPN solution doesn't work (i have a Cisco router to go in to do our VPNs, to be replaced with an ASA in the next 6-12 months as our VPN requirement has increased by some margin)

Have you had any trouble with mobile clients and none-standard ports? (not that security by obscurity is a solution)

I'm going to deploy the trial edition of SBS as part of my proposal, so i can get up to speed with the current versions (the last exchange/windows server i really used was 2003)
 
Personally the best way to keep it secure in conjunction with the security guides listed above is to implement a clientless SSL VPN solution, if you’re looking at moving to an ASA within the near future it is very feature rich, also the clientless SSL VPN client leaves no footprint on the host machine which effectively allows you to access the internal network services from any machine with a public internet connection including but no limited to OWA.

I’m in the same camp as you, i wouldn’t implement OWA unless i had a proper PKI in place ideally i really wouldn’t want it opened up to the outside world at all although i believe the role based Exchange 2007 installation takes away some risk but as your going for SBS this may be somewhat tricky, may be wrong out about Exchange as its been awhile but id be inclined to investigate the SSL VPN scenario.
 
I have use a ASA 5540 with my solution. However, i don't use PAT so i am unable to advise on non-standard ports even though in theory it should be fine.
 
For gods sake please don't use non-standard ports. One day somebody else will likely have to maintain the setup you came up with and spending days working out what random ports people have assigned to things is no fun at all. There are standards for a reason!

And as you've correctly identified, security by obscurity isn't actually security at all.

I'd also forget all about SSL VPNs for OWA, OWA is designed to be on the internet without a VPN and it's pretty secure out of the box. IIS is a decent web server these days and the OWA code is so widely used it's reasonably certain it's bug free and bugs will be fixed quickly.

Just forward the ports and if you want to be extra careful sort out some IDP. If you're paranoid enough to think SSL VPNs for OWA are a good idea or necessary in some way then I suggest that by those standards you shouldn't be exposing an SBS server to the internet at all.
 
We have VPNs anyway, for our other internal office systems, a VPN won't solve the problem for using smartphones with Exchange, pretty much the only reason OWA would be on the web and not via VPN.

It would need to work with windows mobile ActiveSync and it's equivalents for Symbian and the iPhone etc.

I'm happy that IIS is secure enough (or at least there is plenty of easy to follow information to make it so), i really dislike using odd ports - it causes so much more hassle than it's worth. My boss is a different story.

Proper IDP will come later i think. As it stands now, i've no reservations about exposing OWA.

As re certificates, i may set it up to require client side certificates to be installed, one for each staff member, then i can start to use that for other services (and i'll have it for the VPNs anyway).

What are you guys using for PKI management? Windows Server built in?
 
To be honest, OWA can and should be exposed for remote users logging in without a VPN in my opinion. It's a hassle free and secure way for people to check their email without having to faff about and as a business it makes sense to make it easy for staff to check their email so long as it doesn't compromise security.

Having OWA over a VPN makes little sense - they'll need a VPN setup so why not just use outlook while you're at it (unless you allow VPNs to be established from any old machine - which I feel is bad practice and only machines verified secure should be allowed to connect).
 
I'll look into those, the idea of exposing OWA isn't really for the webmail bit of it, it's so phones and so on will sync properly, remote users will just be able to use Outlook anyway over the VPN - although since you can do Outlook over HTTPS then i may just do that instead.
 
Don't go SBS, go 2008 and separate exchange. Keep your domain secure inside your network and stick OWA in a DMZ
 
Biffa said:
Don't go SBS, go 2008 and separate exchange. Keep your domain secure inside your network and stick OWA in a DMZ
Click to expand...

You mean Exchange 2007? Also with 2007+ Edge servers, they don't need to be put in a DMZ.

Although the Edge Transport Server role is isolated from Active Directory on the internal corporate production network, it is still able to communicate with the Active Directory by making use of a collection of processes known as EdgeSync that run on the Hub Transport Server and which, since it is part of the Active Directory, have access to the necessary Active Directory data. The Edge Transport server uses Active Directory Application Mode (ADAM) to store the required Active Directory data, which is data such as Accepted Domains, Recipients, Safe Senders, Send Connectors and a Hub Transport server list (used to generate dynamic connectors so that you do not need to create them manually).
 
dave-lew99 said:
What are you guys using for PKI management? Windows Server built in?
Click to expand...

I used GoDaddy for our to sign the SSL cert :)

You can use Windows CA's but if you using a number of devices is easier to get one from a trusted root for example go daddy, verisign etc.. ?
 
andyd said:
RSA?
Click to expand...

Would be my choice but I acknowledge they are very expensive. There are cheaper equivalents from other providers (Entrust and Aladdin come to mind immediately). Cheaper still the phone based tokens are an option (RSA again and Verisign VIP are good examples). At the bottom end good old smartcards are simple and relatively cheap.

But for OWA, password policies and some appropriate education on security should suffice (We use john the ripper against our unix password sets and name and shame offenders for example). If email is *that* sensitive it shouldn't be exposed externally at all or downloaded to mobile devices.
 
Thanks BRS, i was about to say that SBS Vs Server 2k8 + Exchange 2k7 for 7 people is a bit of a no brainer!

andyd, your SSL certs, do you have to buy additional ones for everywhere you want to deploy them? All of our internal ones are a bit ad-hoc, i was hoping to put them under a common CA and just import that as a root onto workstations and devices, keeps the costs down.

For stuff accessible from public places (ie if we were to run our own HTTPS server) then i'd use a bought in signed one, as it's just easier for site visitors.

One of the reasons for pushing for SBS over what we have, is being able to enforce a proper password and security policy, i'm happy that i can make it secure without a lot of work.
 
You must log in or register to reply here.
Back
Top Bottom