• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1204
  • Last Modified:

Reverse PROXY SBS201 Client Access

I don't feel comfortable exposing my SBS2011 Machine to the web even from behind a NAT'd edge firewall.  Im considering configuring a DMZ'd reverse proxy for CAS (RWA, Pop/Imap, etc) and configuring a DMZ'd edge transport server (or IronMail) for SMTP.    

Any suggestions or recommendations?
  • 2
  • 2
2 Solutions
Cliff GaliherCommented:
Even a DMZed reverse proxy will expose your SBS server. The only real way to isolate SBS is give up REA, set up a full CAS in the DMZ, and then only allow specific proxies traffic between the CAS and the mailbox server. That is a second exchange license, another refer license (at least) and a massive configuration undertaking.

I am all for securing a network. But it also becomes a matter of risk vs reward. And I also can't recommend any strategy that gives the APPEARANCE of security without actual benefit, which is all a straight reverse proxy would do.
Hir0Author Commented:
I guess I wasn't entirely clear.  I want to impliments something like Mandiants Rproxy in the DMZ for the reverse proxy to SBS2011's "CAS" for RWA and an Edge Transport Server (Or IronMail) in the DMZ for SMTP.  Your suggestion, putting the CAS in the DMZ, is not recommended nor supported.  
I still belive my configuration will be more secure than exposing sbs2011 to the WAN via port 25 and 443.  Here is a few reasons...

- Monitor and log traffic
- Firewall/Filtering between proxy and server
- A less vurnable  separate network stack

I'm curious why you think this configuration is no better than simply exposing SBS2011.  Please provide more details for me to consider.
Cliff GaliherCommented:
What does a reverse proxy do? It looks at a packet, compares it to rules that it has, and then forwards the packet on.

What does a NAT device do? By necessity because of how NAT works, you have to set up port forwarding. Which means a NAT device *is* acting as a reverse proxy. It looks at a packet, sees if it matches one of its rules, and it forwards it on.

The NAT device has its own networking stack

So firewall/filtering? Check.
Less vulnerable network stack? Check.
Monitor and log traffic? Even your basic consumer router can do that. Check.

By adding a reverse proxy, you are *adding* a network stack. That is one *more* place a vulnerability could be found. By design, a reverse proxy has to bridge to the internal network. So if a vulnerability *is* found, they have access to your entire internal network where they could conceivably compromise a client machine to further run exploits, capture passwords, etc.

Granted your NAT device may also have such a vulnerability. But then there it is....you are no more secure with a proxy than you are with just a NAT. Either could have a networking stack vulnerability. So by adding a proxy, there are fewer moving parts.

And if the NAT nor the proxy have a vulnerability, they will both forward traffic on to the end service (OWA, RWA, etc) and if a vulnerability exists *there* then the proxy nor the NAT will protect you because they are happy to forward on the traffic as it matches their rules.

Now with that said, I do prefer the edge device that is doing NAT also be a UTM device so it is doing some application-level inspection. But even then, by combining the services, you have fewer places where things can go wrong. And having worked on many of the after-market reverse proxy setups, both open-source and proprietary, a UTM device is easier to maintain.

You put a reverse proxy package on a server and you have to independently maintain the server OS and the proxy package. NOTHING hurts worse than patching CentOS or Windows and having your proxy balk at a .Net update or a seemingly minor update to libxml.so. With the better UTMs, they maintain a customized OS as well, so everything is tested before it ever leaves their labs. I've had far more success, stability and reliability with WatchGuard, SonicWall, Barracuda, and others than I have with a software-based reverse proxy, with the lone exception being ISA/TMG. But even TMG required more patching more often, and that product has been discontinued.

Again, it is a matter of balancing risk and reward. I personally don't see much on the "reward" side of a reverse proxy in the DMZ.
Hir0Author Commented:
You make some really good points but you've missed the fundamental operation of a reverse proxy.  The added security with a reverse proxy is that a session is terminated at the proxy and then a NEW session is started to the destination server. This is fundamentally different than NAT which just translates IP address in the IP header.  I agree with you in regards to UTM appliances but they generally dont inspect packets deeper than 4 or 5 in the OSI model.  A good reverse proxy will look at traffic all the way to layer 7.  Also, as I pointed out the attack surface on a good hardened reverse proxy is smaller than a general OS.  Common attack frameworks are usually targeted to general OS, and therfor useless.

I appreciate the input but I still think its worth the time to impliment an Rproxy.   I guess I wasn't clear in my original request (apologies), but Im really looking for suggestions and recommendatons from people that have configured a reverse proxy with sbs2011.
Schuyler DorseyCommented:
I haven't configured a reverse proxy in this scenario but you may consider a Palo Alto firewall. They are application aware and work all the way up to layer 7 of OSI. While the PAN wouldn't be doing reverse proxy (would be doing NAT), it has many great security features that would help.

1. SSL decryption. If you install your mail certificate on the PAN firewall, it can inspect all inbound SSL traffic (OWA).

2. Application Aware. It is knowledgeable of Exchange specific traffic. It can scan ports 25 and 443 and make sure only Exchange traffic is going over these ports and not back doors.

3. The box includes intrusion prevention, anti-virus and antimalware.

4. It also does file monitoring. You can have it scan the SMTP traffic and drop emails containing attachments of file type you don't want (like .exe or .bat).

If the organization is at a point where security from the outsite is a risk enough to remediate it, you may consider upgrading past SBS into full blown server standard licensing. This will allow you to segment out your roles, Exchange, A.d., WSUS, Sharepoint.

As the other poster said, you will have to buy additional Exchange licensing anyway to put the CAS in your DMZ.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get Certified for a Job in Cybersecurity

Want an exciting career in an emerging field? Earn your MS in Cybersecurity and get certified in ethical hacking or computer forensic investigation. WGU’s MSCSIA degree program was designed to meet the most recent U.S. Department of Homeland Security (DHS) and NSA guidelines.  

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now