Locking down Remote Access to Small Business Server 2003

Recently I have been asked by a few people on and off the blog about an update on our SBS deployment in the office. As some have pointed out to me in comments and email, my Audiovox post explores the fact we are indeed using it in the office now.

And I noticed Susan recently discussed "agility" about strong authentication, and asked:

We want security, but we want simplicity...oh an can you make it cheap?

I can answer that Susan. The answer is YES. So I guess its time to update the saga that is our SBS deployment so you can see how.

If you recall, in our last installment on this topic, I had a few requirements that had to be met before I would deploy SBS in the office.

I had a need for a SBS 2003 machine that is hosting Outlook Web Access (OWA) and Outlook Mobile Access (OMA) for external parties, clients and virtual employees around the Net. The idea was that I can create a virtual office in our DMZ without having to expose critical business resources not needed by these users to the outside. SBS 2003 looks like a perfect solution for this.

To reduce the attack surface of machines connecting remotely while ensuring strong audit trails, I required that ALL connections coming into these services (actually ALL services except incoming SMTP) be authenticated to Active Directory. My goal was to eliminate the potential compromise of unknown threats that may be exposed from vulnerable code or services that may exist along the code execution path between the OWA front end with IIS to the Exchange backend. It also reduced the risks of poorly configured or unknown services that may be running when they shouldn't be. Since the circle of trust for this group of users is quite small, I have a relative level of assurance that I can mitigate most risks by simply removing the ability to connect to the server anonymously and do bad things that they shouldn't. By removing the ability for an adversary to even throw a connection request to the IIS box without authenticating, I could get that assurance level.

It didn't quite work out as planned. I so wanted to use ISA as the front end to this box right on SBS, while offering extended functionality such as two factor authentication. In the end, ISA 2000 was NOT capable to do what I wanted. And ISA 2004, which had the POTENTIAL for a work around was not available until SP1, which wasn't released at the time. And even now, in further tests it looks like ISA 2004 wouldn't quite do what I wanted anyways.

So now that we know what failed, lets discuss how I met my requirements.

I moved the firewall off the server, and used a hardware firewall that supported all the functionality I wanted. I still use the built in ISA firewall on the SBS box as a second line of defense, mostly to deal with filters and proxies that can do some application level filtering for me. For the hardware firewall, I evaluated WatchGuard, Checkpoint, Secure Computing, Cisco, NetScreen, NetMaster and Sonicwall. I demanded that the firewall offer:

• Both ingress and egress filtering
  
• RADIUS authentication with groupings on the WAN interface
  
• Clean NAT, not NAPT. (Network address port translation, as used in Linux ipmasquarading was NOT enough)
  
• Stateful Packet Filtering
  
• SNMP or Syslog logging to external devices for log consolidation
  
• Built in 5 port switch
  
• SME pricing

Funny enough, the last item seemed to be a kicker. Once filtered down on reasonable costs, only WatchGuard and Sonicwall were left. Although Cisco now owns Linksys and they offer dirt cheap NAT devices (some around $50, wow), none of them could properly handle ingress AND egress filtering while offering RADIUS auth on the external interface. You will see why RADIUS auth is important in a moment.

In the end, I selected the Sonicwall TZ170 with the Sonicwall Enhanced OS. It was around $500, but offered much more scalability for my "Virtual Office" DMZ network than other solutions.

With the firewall now in place, I wanted to configure the absolute minimum attack surface to the outside world. So, from the outside you simply see two ports. The first being the SMTP port for the Exchange server and the second being the authentication port, to allow remote users to authenticate to the network. I could have went with a multidrop offsite POP solution to a Unix server running postfix to remove even the SMTP port, but I decided to go with Exchange 2003 directly, and use the ISA mail proxy filters to deal with some of the obvious door rattling. Exchange 2003 has matured alot from its earlier versions, and I am willing to accept the risks that are exposed with the SMTP service. Time will tell if that was a good call.

Here is where things got fun. Because I cannot trust the machines entering the network, I simply refused to allow a Layer3 connection in. Even with a VPN quarantined tunnel and new technology like NAC (Network Admission Control from Cisco) or NAP (Network Access Protection from Microsoft), I don't wish to expose the business to such unnecessary risk. So IPSec and PPTP were out of the question. And these SSL VPNs are just to weird in what they can really offer.

In comes Remote Web Workplace (RWW) for Small Business Server. It provides a passive conduit to Exchange through Outlook Web Access (OWA) over SSL, and offers a private intranet through Sharepoint. It gives me shared contacts and calendaring, while offering no need to configure any hosts to use it. It ALSO offers a secure tunnel to an internal Terminal Server through a special bridging RDP control directly in the browser. This allowed me to install a separate Windows Server 2003 box behind the firewall with some line of business apps we have. The result, I have to open up a few ports:

• Port 443 for Remote Web Workplace (OWA/OMA)
  
• Port 444 for Sharepoint
  
• Port 4125 for secure Remote Desktop to a Terminal Server

Now, although these ports are not always open, I simply did not wish to risk it at all. Remember, I want to reduce the attack surface so people cannot even fire requests to these services until I know who they are. On top of that, because I cannot trust the hosts connecting in, there is a risk that it may have installed viruses, malware, keystroke loggers etc which could expose the company to even more risk.

The solution? Find a two factor authentication solution that would work here. At that point, even if a keystroke logger recorded the passwords, it wouldn't matter. With a one time password (OTP), the information is useless to them. They can never use it to log in.

I evaluated quite a few solutions. The ones worth talking about were from RSA (SecurID), Authenix (A-Key) and CryptoCard (CryptoServer). In the end, it came down again to a combination of cost, and comfort. As an old RSA SecurID user, I was VERY familiar with their keyfob tokens. But they are ridiculously expensive, forcing you to buy a 25 user license to get started. (I only need to deal with 5 users initially) Authenix didn't have a keyfob, but had a neat OTP generated in a window on a USB key. But I ended up going with Cryptocard, as the server natively installed into the SBS box and hooked directly into the Active Directory tree to manage the tokens for my users. That's right... on installation it ties nicely into Active Directory on SBS. And it has a keyfob similar to RSA, but WITHOUT a 3 year expiry timeout. In other words, I never have to buy new tokens for my users, unless they lose the token. Oh, and to boot... they have AWESOME SMB pricing, with an initial 5 pack of tokens and the server coming in around $500.

So, the final result? From the outside world you see two ports. Well, sort of. Sonicwall has a nice stealth mode to help reduce pentest style scans, and in many cases you won't even find that unless you know what to look for. You can log into the auth port with a browser, which challenges you for credentials. You enter in your AD username and a passcode which is a combination of a 4-8 digit alphanumeric PIN along with a 6 digit OTP. Using RADIUS, the firewall then pops a request over to the SBS box, verifies that the user is in Active Directory and that the OTP matches for the token. If so, it sends an ACCEPT response to the firewall. The firewall then prompts the user with an "Acceptable Use" dialog, which the user must accept. After accepting the "Acceptable Use" policy, then, and ONLY then, the firewall will open up the port forwards for the IP you are currently at that are needed for Remote Web Workplace. You can now use the regular RWW login stuff to go about your business. If you idle for more than 15 minutes, the firewall immediately locks that back up, and all the ports are blocked until you relog in.

Oh, and a nice side affect of RADIUS groupings. I can control what ports trusted users can access, and at what time of day. So I can further limit service exposure to business hours, and only services that are needed. As an example, I have added a Linux server behind the firewall that uses RADIUS and the Cryptocard webagent to allow source control check-ins and check-outs. My "dev" group is permitted access to that server to do secure checkouts of code, only after authenticating with a OTP. Talk about wicked add-on with no extra cost. Nothing beats the ability to check out a piece of code securely on your TabletPC while at a Starbucks, make a fix and check it back in, all over the free Wifi. Or accessing your email while at an airport web terminal, and not worrying about the vile filth that might be installed on there.

Using this scenario, I can consolidate my auth logs through RADIUS against my login services with RWW. In this way, I know WHO is coming in, from WHERE at WHAT time, and WHAT they are doing. And since I have a strong audit trail on the SBS box, my daily reports with SBS show me when people try to do things they shouldn't. Walla... I met all my objectives, reduced the attack surface to something I find acceptable, and did it all for around $1000 for 5 users. And to scale more users, I simply buy more 5 packs of the Cryptocard tokens and SBS User CALs as needed.

Now the solutions is NOT perfect. I would prefer to have RWW use two factor authentication natively, so I can force an OTP login scenario. The difficulty with this is that things like OWA would break, since they use a cached password from the RWW login. Further to this, Microsoft currently has no intentions to add RADIUS support to the RWW login. Susan and I are currently taking this up the chain of command and hopefully we can rattle the right chains to get something done about that.

Oh, and OMA doesn't work well yet. The problem is a limitation on the Smartphone 2003. The Sonicwall login page uses some neat javascript which PocketIE just can't handle. One solution is to use a static IP on GPRS; not a practical solution if you know much about wireless telco providers and their cell networks. Right now I am talking with level 3 support at Sonicwall and will probably write a simple login app for the Smartphone to deal with this. If I do that, I will publish it so other can use it if they so desire. For now I am just using ActiveSync to keep my Smartphone in sync with the Exchange server, only after authenticating the machine using Activesync with my cryptocard token.

So there you have it. That's what I had to do to get an SBS Virtual Office Extranet setup to allow remote users to access resources around the world. It was a struggle to find all the right bits, but the fact I was able to deploy enterprise-level two factor authentication for my SBS network for under $1000, it IS possible for the SME. Is it overkill? I don't think so. Does it scale. Absolutely. The SBS box will reach its critical mass before this solution does. And at an ammortized cost of approximately $125/user, it's well within budget if you consider the risks it mitigates, and the protection it offers. And I would do it again in a heart beat.

Posted by SilverStr at June 7, 2005 12:23 AM | TrackBack