Securing MOSS 2007 in a heavily managed environment

Posted: November 17, 2008 in MOSS 2007

                Recently I have had the opportunity to implement a MOSS farm in an extremely secure and managed environment. This included HIPPA, SOX, and DOD compliance, to an extreme I had never seen before.

                In such an environment, implementing MOSS can be an extreme challenge to say the least. Using some hindsight looking back at the challenges the project encountered though, I can say a lot of the risks can be mitigated somewhat with some forward planning. I will first give an extremely high level description of the farm, and I will break down the risks into 2 main groups (in no particular order), either of which can severely impact your architecture. There is way too much to go in depth on everything, I will however provide links to help you out if you need to face such a project.

Farm Layout

                The farm we created had 4 WFEs, I App/Index/CA server and a clustered SQL 05 (A/P) on the back end. It had only 5 Site collections, 1 of which had to be broken off to its own Web app using a separate SQL instance on the cluster for its content DB (for security/compliance reasons).  It utilized standard NTLM AD auth for the farm with OOB search.  The WFEs were separated out into 2 groups of 2 with each group of 2 having their own load balancer and host header. The entire system was based on 64 bit architecture.


                In our implementation, we had some pretty heavy firewalls around each of the servers. This included firewalls around the network, one for each MOSS server and one for the SQL cluster. Needless to say we had ,to be pretty exhaustive on a list of firewall rules. All told, we have 70+ firewall rules to allow the farm to talk.

                To this point, you need to consider a few things. First of all, find a tool to independently test each rule to ensure it is open, and to trace what communication MOSS is attempting. I have seen a lot of references on MOSS ports online, NONE of them hit all the ports we needed. No matter how good you are, it is likely you will miss at least a couple. 

Also, keep in mind that MOSS uses different ports depending on what you are doing.  For example a MOSS farm already configured, running normally will use a smaller set of ports than one that is being actively configured or patched. For example, we found all calls to the DB (UDP 1433, 1434) that only occurred during the config wizard and never any other time.  Also MOSS will utilize different ports depending on if it uses Kerberos or SSL, or LDAP/AD, or depending on how your SQL cluster is configured.

You would be wise to have a nice, easy to read chart on all the servers and services you need to hit, particularly your non-MOSS servers such as SQL, AD servers, DNS Servers, SMTP, etc. They will likely be firewalled as well.

 IMO, you need to resist the temptation to just grab a huge list from the web and push all the rules it gives you out there. It is a fast track to getting your farm up but in the long run, such a game plan will leave you opening up holes in your firewall that you will never use. As painful as the firewall can be, it is there for a reason and you do not want to open up security holes that can leave you or your client failing an audit.

You will want to sit down with the networking people and explain everything you are looking for up front. Be extremely anal. Down to the specific host headers (in quotes), ports protocols and be prepared to explain in deep detail why each port is used. Any network engineer in such an environment that is worth his salt will ask for this info. Also, set the expectation with them that while you will try to nail as many rules as possible, you will miss some and you will need to define the process that will allow you to add additional ports. Most network admins will appreciate that you want to open as few as possible at first and then slowly open additional ones as you need them.



File permissions

                In our implementation, our server OS’ also had some serious compliance requirements for the DOD restrictions. This meant the compliance software which pushed these rules removed tons of ACLs from the file system and registry, disabled services, blocked ports, reset IE permissions, and a few other fun things. You would be wise to ask for a list of these up front and exclusive obtain exclusive access to the person responsible for maintaining the list of restrictions. Depending on the scope of your restrictions, finding the resolution to this can involve accessing multiple MS product teams or reverse engineering ACL, service, and Group Policy permissions required for MOSS, WSS, IIS, Asp.Net, .Net (all versions), COM+, and even Windows Server 2003 itself. There were rules in there that actually killed the OS.

                Keep in mind, if you have DOD compliance, you will need to provide detailed justification for each and every exclusion you identify. Usually, it has to be more in depth than “It breaks ASP.Net”. There a few good links I found on technet to at least get you moving on this. However, if you are doing this for the first time for any of the dependencies for MOSS (IIS, Asp.Net, etc), you would be wise to call MS premier support and proactively get them involved in helping you debug this. Also, you will need someone above the front line offshore support, they will not be able to help you in any manner on this. It is simply over their skill set.

                Aside from MS support, the only other way I have found, is to get a functional system up and compare the permissions as they cause issues. It is a long, painfull process so buy some coffee and stock in whatever company makes it. You will be needing it if you take this route. Also, if at all possible, virtualize the machine you are testing with. Rebuilding a physical machine over and over will cost you weeks.  As with the firewalls, you need to resist the urge to just grant cascading permissions all over the place. You need to just open up what you need and nothing more. Particularly in the c:windows folder. The DOD restricts these for a reason.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s