The honest fact of the matter is there are great numbers of Systems Administrators out there who are building servers (even some on the internet) without even minimal exposure to the specifics of securing a windows computer. Thankfully, over the last few years security awareness has been heightened and many larger companies have been investing in the space with security training and building policy but the problem is still not eliminated. In response to a SecurityFocus question on the Microsoft list this morning, I put together a list of my key things to think about when building a server.
This list is not exhaustive. There are entire books written on the subject. This is simply my list of things that I think folks may not necessarily think about when they build a server. I hope someone out there finds it useful as a starting point for things to think about.
1) Document the server.
This is an oft-overlooked step. If this is a corporate environment, you should have several key pieces of information for every machine in the environment. The hardware on the machine. Who owns it. What applications it serves. The data classification level the machine is intended to support. Many IT shops simply don't do this but the frank truth of the matter is that any company should.
If something is compromised, whether you think you are a hacking target or not or you think you have high value data or not, you need to be able to quickly return information on what the machine is, what it has, and what was installed on it in the event of a compromise.
This does not have to be complex! It can be as simple as an excel workbook.
If you have multiple server rooms or data centers, set up a tab for each and each row is one machine. Simple to use, easy to update. You can host the workbook on a share or on a SharePoint site. If you have a SharePoint site, it's even easier because then you can just build a custom list on a SharePoint site somewhere and you are set. If you are a Lotus Notes shop, there are options in domino to build such a list as well.
2) Install the minimums. If the server has been re-purposed, start with a fresh OS install.
Minimizing the attack surface starts with not building in unnecessary stuff in the first place. I have seen a "guest" base image in a highly virtualized environment that seemed to have everything and the kitchen sink in a corporate environment. During an audit, when challenged on this, the IT folks said that they wanted the swiss army knife already in place so if they needed a tool, everything was already in a path variable and they could count on being able to type the same commands on any system being hosted.
Remember that utilities and non-role applications are a double edged sword.
Sure, they may save your IT guy 3 minutes while he doesn't have to put in a live disk or some kind of utility CD or map a share but is saving those 3 minutes during a support response really worth the increased exposure that you are placing on the system or giving those added capabilities to an attacker during the initial compromise?
As an aside, installing Microsoft Office on a server that is not specifically intended to be the back end of thin clients is stupid. Don't do it. (I've seen it in multiple environments at several different customers so it does happen, even with clients who should know better.)
3) Immediately review the service configuration and default accounts.
If you don't need them, disable them, or in the case of services at least set them to manual so they do not run by default. With Windows default accounts, make sure that the steps that you can take, you have.
- Disable Guest
- Re-name Administrator, where practical
- Use VERY strong passwords for default accounts
- The length and strength of the admin passwords should be longer and stronger than your regular user complexity requirements.
With the services, take the most restrictive approach possible. Remember, if something doesn't start, we can always restart whatever was stopped so its ok if something now fails to start. We just make the necessary adjustments and restart it and we know not to stop that particular service again ;) You ARE building the security for this server while it is in a build or pre-production stage..... right? You should be able to risk causing other service failures while you determine what services are necessary.
4) Make sure your host-installed security clients are installed and configured correctly.
- Windows Update
- If applicable, does it point to the right WSUS infrastructure?
- If applicable, does it download automatically and allow you to manually install?
- Is the install consistent with policy, if applicable?
- Antivirus
- This varies by environment according to the security architecture of the environment in question.
- If it is supposed to be there, is the client installed?
- Does the client have the correct auto-update settings?
- Is the client pointing at the correct management server, if applicable?
- Are the correct automatic scans in place, if applicable?
- Host-Based IDS
- Again, varies by environment.
- If it is supposed to be there, is the client installed?
- Is it configured according to the norms of the environment?
- Firewall Client
- Again, varies by environment.
- If it is supposed to be there, is the client installed?
- Is it configured according to the norms of the environment?
- If necessary, have you configured the host specific rules for this server at the firewall level in a centralized design or at the host level if the rules are host based?
- Are your I/O streams documented somewhere? They should be.
5) Review local security policy and configuration.
This one would seem straightforward. Have you taken the time to ensure that the local security policy settings are appropriate to the environment and that applicable GPOs, if any, are being applied to the system? Did you ensure that you have secured access to critical places in the file structure? If only certain kinds of accounts are allowed to have access to windows/system32, for example, are the appropriate DACLs in place?
Have you specified SACLs to allow specific event auditing on those critical file structures?
6) Configure the Event Viewer.
Make sure you have adequate space in your logs for events and that you have configured event expiration appropriately. If you are logging file system events and logon events, make sure you have the appropriate space for these entries to be applied to the log. If you are in a Windows Server 2008 environment, have you taken the time to build the subscriptions necessary for this server's event logs to be collated to your central event database?
If applicable, are the appropriate event monitoring clients installed and configured correctly? Have you tested it? Did the event show up where it was supposed to? This is particularly true for environments with SNMP monitoring or Tivoli or similar centralized systems for server events.
7) Where practical, avoid using the default anything to run an application.
If you are installing a web service in particular, you want to avoid defaults which can be guessed by an attacker. Use a custom domain account to own the IIS application pool. If you are running apache on windows, take the time to actually go through the configuration file and ensure you are running the minimum required modules. The IIS equivalent in IIS6 and prior is to make sure you have installed the minimum components possible.
In Windows Server 2008 and IIS7, the default IIS role install has very few features. Add only the ones you need. You may need to work with the application developer or the application vendor to ensure that you are properly supporting the application. In my experience, the developer wants everything and the kitchen sink to be available to ensure that they can minimize the number of things they will potentially have to troubleshoot later. Make it clear that this is not an option.
If there are concerns about ensuring the application runs, enable everything they want at first, and get the application working. Then start tightening feature selection item by item until something breaks. Then move on and try to tighten other items. Done properly, you should help minimize both the attack surface of the system in terms of installed software, and also the capabilities that would be available to an attacker which compromises the web host portion of the server.
8) Limit the access the server has to resources it does not need.
The network configuration for the server should restrict what the server has access to and where traffic is directed. In cases where the server is multi-homed, you can use routing rules and either a host based firewall client or other access control means to limit server access.
At the switch or router level, restrict in-bound or cross-network paths which the server's segment does not require access to.
At the host level, ensure that your default gateway is towards the "outside". If you are in a complex environment where there are customer specific networks or specific gateways, the default gateway on the server should point towards the customer specific gateway, not towards an infrastructure network or an "inside" enterprise network. Use route rules to specify exceptions. Recall that default gateway and route rules locally on the box affect only directions of the network flow, NOT necessarily access control to services or the box itself.
If you are using a local firewall, set the lowest permissions possible. If possible, restrict your network source addresses to only those that should be allowed access to the service. If, on a middle-tier application server for example, requests should only originate from certain web servers and a network segment hosting your engineers, then your exceptions should be specific and should allow that traffic from only those segments. Remember to set the appropriate permissions for remote access applications in use.
If you are using a remote access methodology, as in most installations, ensure that you have appropriately secured it. The remote access method should NEVER be world-accessible, particularly if it is being hosted on the default port. If you are using a multi-homed box, restrict the remote access port to the internal LAN access only or internal LAN sources only, and then anyone outside of the organization who needs to get to the box should have some capability to VPN in or there should be some kind of private networking arrangement. If you can get to the box from the web, so you can your opponent.
9) Security by obscurity is not security.
Changing the default names or settings does not, by itself, apply any kind of security, it simply makes an attacker do a little more work to compromise the box with some specific types of attack. Do not fool yourself that you can rename some things and build a new application pool and call it "good".
You must ALSO secure the box with appropriate permissions and other settings as discussed. Many companies fall into this trap.
This also applies to any "clever" ideas that the organization might have to "disguise" a server. In one audit I was party to, I had a client with a domain controller he had named to use the naming convention of an application server. Because of this, he felt he did not have to protect it as well. Within 2 minutes, I showed him 3 or 4 different ways to get the list of DCs from Active Directory, including the "app" server in question.
Always assume your attacker is smarter than you are, this ensures a healthy respect for them, and accordingly a serious approach to security.
10) Follow policy.
If your company does not have a security policy, get up, go find the IT manager responsible for the infrastructure, and kick the chair out from under them. With all of the news even on CNN and the rest of the public (dis)information sources out there, there should be no one in IT that is not aware at some level of the need for information security.
If your company DOES have a policy, make sure that your server is compliant.
This should include a window of time when updates can be applied. A method of making and documenting changes to the server. Ensuring that at a technical level, appropriate points on the system are compliant (permissions are set correctly, necessary programs are installed, etc).
If the system is later compromised, the last thing that you ever want to have happen is for some other company's lawyer to point out that the system was not compliant with the company's OWN policy and that it was YOU who built it. You might as well pack your box and move on before it gets to that point if you did not follow, to the letter, the policy requirements of the company or hosting environment.