THE OFFICIAL BLOG OF THE SBS "DIVA"

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 notices 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...