In our previous piece 10 Essential Steps for Configuring a New Server we walked through some of the best practices to follow when setting up a new Linux server. But how can you tell if your server is setup correctly? More importantly, how can you ensure those initial configurations don’t drift over time? With UpGuard, you can do both at any scale, so we’ve created a policy within our cyber resilience platform to match our 10 essential steps as an example of how we can help organizations control their IT environments.
Before you can create policies like this to test your environment’s compliance, you’ll need to discover all of the assets you need and their configurations and get some real visibility into the environment. Once your assets have been added as nodes within UpGuard and their configurations have been scanned, you can start working with the real power of continuous testing by building a policy and enforcing it on a group of nodes. Policies can be based on many different things: public best practice standards like the Center for Internet Security’s critical security controls, regulated industry compliance standards such as NERC, PCI or SOX, or even one of your existing device’s configurations, if you have a golden model you want other devices to match.
Our policy in this example will be based on our Linux server configuration guide. There are a few basic things we can check in each step to help ensure servers are-- and remain-- secure.
1. User Configuration
UpGuard can check many user configuration items, so keeping track of who has what access is a breeze.
First, UpGuard can ensure that only the user accounts you expect to exist are on the server. We do this by generating a policy item based on an existing server with the accounts we want. By setting this policy, we ensure that if an account is added or removed, we receive a notification. Servers that do not match the initial user account list will fail the policy until they are remediated.
UpGuard can also look for items within configuration files to ensure that the correct directives are set. To verify that the server has a password policy, we could check a file such as
/etc/pam.d/system-auth (RedHat) or
/etc/pam.d/common-password (Debian) and make sure the options we desire are being enforced. First we add an “include” check to search our system-auth or common-password file for the following code, which sets our password policy:
password requisite pam_cracklib.so try_first_pass retry=5 minlength=8 lcredit=1
ucredit=1 dcredit=1 ocredit=0 difok=4
For reference, these parameters mean the following:
try_first_pass- sets the number of times users can attempt setting a good
password before the passwd command aborts
minlen- establishes a measure of complexity related to the password length
lcredit- sets the minimum number of required lowercase letters
ucredit- sets the minimum number of required uppercase letters
dcredit- sets the minimum number of required digits
ocredit- sets the minimum number of required special characters
difok- sets the number of characters that must be different from those in the
After building this policy, any server in our node group without this exact password configuration will fail policy and we’ll be able to tell which servers need to be fixed.
Finally, we can also monitor who has sudo access by using the Sudoers section of our policy. We can either check for specific users or base our policy off of an existing server with a properly configured
While IP address and hostname will be unique on each device, UpGuard can check to make sure that other network options, such as DNS servers and default gateways are configured correctly. This comes in handy when changing those options, so you can easily track which servers have been pointed to the new addresses. We can handle DNS by adding the
resolv.conf file to our policy and either matching it to a properly configured file or using an include check to find a specific string, such as DNS server IP addresses.
3. Package Management
Keeping track of what packages you have installed can be difficult, but with UpGuard you can see right away what you have installed and whether or not a server has extra packages installed or is missing packages you expect. We break installed packages out into its own section, so it’s very easy to work with them and tweak policies to your needs. If you have an existing server you want to use as a base model, you can ensure that all of the same packages are installed on other systems. Otherwise, you can add individual packages to the policy based on your needs.
4. Update Installation
In addition to checking which packages are installed on your servers, UpGuard can also verify which versions they are, which means not having to guess whether all of your systems have been updated to protect against the latest vulnerabilities: simply scan your node group and see which servers pass your policy.
For example, if you wanted to ensure that a specific version of nginx was installed across a cluster of servers, you could add an exact match check to the policy for the specific version of the nginx package. If any servers have a different version, they will fail policy and you’ll be able to remediate them. If any servers are updated to a different version unexpectedly, you’ll be notified.
5. NTP Configuration
Easily monitor your ntp.conf file with UpGuard and make sure your servers are all pointing to the right place for time and that the configuration options you expect are set up. Once this policy is in place, as soon as a new server is added into the node group (which can be done automatically based on certain criteria) you can tell whether NTP has been properly configured on it. Regardless of how you provision resources, continuously testing them against policy is the only way to be sure they are configured correctly.
For example, we can create a policy that checks the
ntp.conf file to make sure our two time servers are set up by adding include checks that look for the appropriate strings. Additionally, we can verify that a drift file is set for NTP by adding an include check for that string as well.
6. Firewalls and iptables
UpGuard has a special section for devices called ports that shows you which ports are accessible on your server. By monitoring this section you can ensure that ports you need stay open and ports you don’t want stay closed. In the example below, we’ve created a policy based on a server with the ports we want open. We can now apply this policy to any servers that match the criteria we set and we will be notified if one of our allowed ports closes or if a new port opens. For more granular control, you can monitor the actual
/etc/sysconfig/iptables file itself either as a match to a correctly configured file or with include checks looking for specific strings.
By adding the
ssh_config file to our policy, we can ensure that the connection strrings we expect exist in the ssh configuration. This includes checking for private key paths using the IdentityFile attribute, which can be difficult to manage if you have lots of ssh enabled servers with different keys that change regularly.
8. Daemon Configuration
UpGuard has a section for services where you can manage installed and running processes. You can check whether a service is enabled and whether or not it’s currently running. This can be useful to create a policy where you want to make sure a service like nginx is enabled and running on a collection of web servers. If a server reboots and for whatever reason the service is no longer enabled or running, policy will fail and you will receive a notification.
9. SELinux and Further Hardening
SELinux, like most Linux applications, has a plain text configuration file that can be monitored by UpGuard,
/etc/sysconfig/selinux. And like the other config files we’ve explored in this guide, it can either be matched to a source file with proper configuration, or can check the body of the file for strings to make sure certain directives are enabled or disabled. No more guessing whether SELinux is stopping your application from communicating and no more assumptions that SELinux is protecting something when in fact the directive is disabled.
UpGuard can monitor configs or other files for any additional applications, as well as external profiles for websites, database nodes and other hooks for commonly used software. The power of UpGuard is its ability to extend as far as your environment reaches and is designed to provide a single pane system of record for all of your IT assets.
UpGuard can monitor log configuration files, for example to ensure that a bank of servers are all pointed to the same syslog server, or have the appropriate size limits and rollover options. UpGuard serves as a complement to traditional logging by providing real time visibility in addition to historical trend data for configuration states.
UpGuard offers a flexible way to continuously test your configurations against policy to ensure that your environment is the way you want it all the time. No more unplanned changes flying under the radar, or guessing about system configurations. Just use our sleek, visual interface to quickly tell which of your servers comply to your standards, which don’t, and why. Our 10 Essential Steps will help you build a secure server, but a policy in UpGuard will help you scale that security to any number of servers and make sure they stay secure over time.
Whether you’re deploying hundreds of Windows servers into the cloud through code, or handbuilding physical servers for a small business, having a proper method to ensure a secure, reliable environment is crucial to success.
Read Article >
Email is as important as the website when it comes to security. As a channel for social engineering, malware delivery and resource exploitation, a combination of best practices and user education should be enacted to reduce the risk of an email-related compromise.
Read Article >