Services are the programs that run in the background on servers. All OSes come with a set of base services and most software utilizes services as well. Effectively managing servers means controlling these services—knowing what is there, what should and shouldn’t be running, whether or not services will automatically start on (re)boot and who the services should and shouldn’t run as. We’ll go through each of these pieces to see how a strong service management policy can help reliability and security in the data center and how configuration management and testing is key.
What Services Do I Have?
The first step to wrangling services is to get a clear picture of what services are currently installed on your systems and whether or not they are running. This can be easier said than done, depending on how many systems live in your data center and whether or not you have a decent mechanism by which to collect an inventory of services from them. Both Windows and Linux systems utilize services (or daemons), so conceptually you can apply the same policies across both.
By default, some services automatically start at boot and run in the background. Depending on the function of your server, you may or may not want these services available. A Windows file server doesn’t need the Web Publishing service running and a dedicated MySQL server shouldn’t be running nginx. But just because a service isn’t needed doesn’t necessarily mean it isn’t running. Many production systems still have default services running that are both unnecessary to support the application(s) they run, but also increase the server’s attack surface and can become vulnerabilities to be exploited. This is why knowing all the services that are running on your systems is key to managing them.
The mechanism by which you track service inventory should be able to report whether or not the service is running. If you only have a handful of servers, you can maybe go into each one and manually list the services, but that quickly breaks down at scale, whether talking about a large number of systems or trying to maintain a service inventory over time.
What Services Should Be Running?
The next step to wrangle services is to determine what services should be running. First, you can eliminate services that you know are not necessary to the application or its dependencies. These services should be both stopped and disabled (set to not start at boot).
Next, you can determine which services are crucial to your application. All application services and their dependencies should be running and enabled (set to start automatically at boot). This includes core application services, required OS services and ancillary services such as license managers, logging, monitoring, etc.
Finally you have everything that’s left—services that are neither crucial to the application nor obviously unnecessary. This is the most difficult group and must be judged on a case by case basis, at least at first. Once you develop a policy, you will be able to bring new systems in line with it easily, but to create the policy, you have to do the legwork of determining whether or not a service is needed. If you determine it isn’t needed, stop and disable it. A series of trial and error tests may be required to see how different services interact, so make sure to have a test environment available for this process—even if you are taking advice from the internet on which services to stop, you should always try it in a non-production environment before making changes.
Should Services Start Automatically on Boot?
On Windows, in the Services MMC snap-in, you can see the Startup Type of all the services on the system. These can be Automatic, Manual or Disabled. Automatic means the service will automatically start at boot, manual means the service will not start at boot, but can be started later, and disabled means the service will not start at boot and cannot be started later, unless the startup type is first changed. Additionally, you can set devices to Automatic (Delayed) which will give services with service dependencies a chance for those dependencies to start before starting the service itself. On Linux, whether you use chkconfig or systemctl, you can set services to be either “on” (start automatically at boot) or “off” (do not start automatically at boot). In either case, only the necessary services should be set to start automatically. On Windows, services that may be needed occasionally but should not be running all the time can be set to manual. And all other services should be disabled to minimize the attack surface of the server.
Who Are Services Running As?
On Windows systems, you can set services to start as specific user accounts. This can be helpful to give applications access to domain resources, or to restrict an application’s reach. By default, most Windows services are set to run as Local System. In production, you likely don’t want to leave things this way, as Local System has root access to the server. Applications should run as service accounts, either local or domain, with just enough access to perform necessary operations. Running services as Local System or, worse, a domain administrator, opens up the system and possibly the entire network if that service is compromised.
For an example of how to use UpGuard to manage services, please watch the video below:
Understanding what services are running, whether or not they should be running, whether or not they should automatically start and who they are running as, increases security by shrinking the attack surface, and increases reliability by ensuring all the necessary components are running and set to restart if the server reboots. On Windows servers, you can tighten security further by changing services to run under specifically created accounts with the least privileges necessary. Most Linux processes will run this way by default, with a service user specified in the config files. As with software, the key to maintaining and managing services is real-time visibility into your environment. Without a strong configuration monitoring application like UpGuard, maintaining services across a data center can quickly get out of hand.
How CSTAR Works What's In the Website Risk Grader? Understanding Risk in the 21st Century
All the information needed to perform a CSTAR assessment is bundled into the UpGuard platform. Learn more about CSTAR.
Read Article >
The UpGuard Website Risk Grader provides a low friction way to get an initial assessment of a business' risk profile.
Read Article >
And as we enter 2016, the risk of data breaches in particular threatens to hamper business innovation.
Read Article >