This article is part of our ongoing UpGuard 101 series that focuses on ways to use UpGuard to keep your environment ready and yourself sane in real world scenarios.
If you’re a sysadmin, one of your main tasks is building new servers to support business and internal applications. Chances are, you will need more than one of the same type of server, such as in a cluster or load-balancing scenario, or identical servers for development, testing and production. One of the best out-of-the-box features of UpGuard is the ability to build a policy from one configuration and apply that policy to other nodes that should match it. This gives you instant visibility of the differences in configuration between systems. We’ll use that capability to demonstrate how UpGuard can save you time when you’re tasked with building multiple, identical servers.
A new web application has been chosen to run your business’ online portal. You have been tasked with building two Microsoft IIS servers, one for testing and one for production. These servers need to have an identical initial configuration and must be prevented from drifting as time goes on. Application developers and admins will also be using the servers and you need to know if they make any configuration changes as soon as possible to make sure they are uniform across the two systems. Fortunately, UpGuard makes this common scenario a simple process.
Create the Base Nodes
If you’re not auto-deploying application servers in the cloud programmatically like magic yet, you can still take advantage of UpGuard’s configuration monitoring and alerts to make the traditional methods of server deployment more bearable until you do. So, if you’re doing this the old-fashioned way, set up your Windows servers and go ahead and update them as well. We’ll use UpGuard to make sure they have the same patches. Once the servers are done with updates, add them into the UpGuard console as nodes.
Node Group Scan
Next, we create a node group for these servers since we want to apply the same policies to both of them. Before we can diff the servers, we need them to report their current status, so we can initiate a manual scan of the node group to begin data collection. Now that we have a scanned node group, we can diff it and verify that we built and patched our servers the same. Missing patches and configuration differences will be highlighted in the diff view and should be addressed before moving forward. Ensuring the same patch level for servers across dev/test/prod environments means that any testing or development done in those environments won’t miss the impact of the absence or addition of a new update on the production system. Similarly, a clustered or load-balanced environment with different updates can cause conflicts and errors, so it is vital to track and manage configurations across these systems.
Build a Policy From a Configuration
Now that we have a baseline for our barebones systems, we will install IIS on one server according to the specifications of the application it will serve. This includes requirements like the type of authentication allowed (basic, digest), what web features are installed (such as HTTP redirection or ASP.NET) and what management and monitoring tools and scripts are needed. Managing multiple IIS environments with different configurations can be troublesome without visibility and automated policy monitoring to instantly confirm not only how the servers are configured, but how they should be configured and why.
Once the IIS installation is complete and the server has rebooted, run another scan on it in UpGuard and diff it with the previous one. You can hide everything that hasn’t changed by toggling the “Unchanged” button under differences. This should show only the changes made by the IIS install. Now we can build a policy to ensure the IIS config is identical between the two servers. One cool thing about the interface is that you can search to find and put similar items into a policy at once. If we type “web-” in the search box, all of the IIS features (and nothing else) show up. We can then right click on the root icon and add them to a new policy for this node group.
We can re-scan the node group now and if we did everything right, the server we’ve installed IIS on should have 100% compliance, while the other server should have 0%. We’ve established our IIS install baseline and can now compare other servers to it and compare the original to it over time. If a dev, tester or sysadmin removes or modifies one of the required components, our server will begin to fail the IIS policy on the next scan, alerting us to the change. This allows us to either revert the change, if it was unintentional or temporary, or alter the policy to reflect the change and remove it from other nodes in the group.
Using the Policy
Installing IIS on the second server should be pretty easy, but it often happens that a requirement can be overlooked or forgotten. This time we’ll install IIS with just the default options checked instead of configuring it for the application, as happens frequently with multi-server rollouts. After completing the IIS install and rebooting, we can scan the second system again. When we do, we see that most of the requirements in the policy we made have been met-- IIS was installed-- but a few were left out, and this gives us our checklist of what we still need to install. As best practice, we can go into each one of these checks and add comments in the “background” field so we remember down the line why we added this policy.
Our second server is failing the Basic-Auth, Http-Redirect, Request-Monitor,Scripting-Tools and WIndows-Auth checks. We forgot to configure IIS. But we don’t have to wait for application deployment and failure to find out and we don’t have to reference any vendor documentation or notes to figure out exactly what is missing. It’s all right there in our console, highlighted in red. We can now go back into the second server and install the missing IIS features. After correcting the mistake, we can scan again with UpGuard and verify that both servers now have 100% compliance with the policy.
This is a simple example, but illustrates the basic concept of how configuration monitoring can make IT ops better and easier. As time goes on in our example, we can do some other cool things. If we need to add additional servers, we simply put them into our node group and scan them. They will automatically have the policy we created applied and we can see if our IIS configs match. This is particularly great in cases where months or even years have elapsed between the initial rollout and the additional server(s). Likewise, if the requirements for our policy change, we can update the policy by making the changes on one of our servers and then adding those changes to the existing policy. This makes it simple to keep up with changes across any number of servers caused by application or system updates. It gets even easier when you begin to automate those changes with tools like Puppet, Chef or Ansible. Finally, our policy will alert us to any changes made on those servers that affect the IIS configuration. We can even go so far as to define within our policy that certain files should exist (in webroot, for instance) or utilize PowerShell scripts to check information on the website config, application pools and virtual directories.
The policy options are robust and customizable and every organization can tailor them to the needs of their environment. As projects require more grouped servers to operate, a solid configuration management strategy will ensure reliable, secure systems across any size scope.
Sure, you could manually dig into each machine and run openssl version, or spend the afternoon scripting a solution if you're fancy, but that amount of work will only get you through today.
Read Article >
By following these 10 steps for improving IIS 7 security, you can achieve and maintain an even stronger level of security for your web apps.
Read Article >