Writing a Custom Configuration Policy with Halo: Part I

Out of the box, Halo provides a lot of configuration checks to ensure your servers maintain a secure posture. We’ve followed the NIST lockdown guidelines, and can help you quickly assess which of your servers could potentially be exposed to the highest level of risk.

Every environment is a bit different however, so there may be times when you want to perform your own custom checks. In this post I’ll walk you through the process of setting up a simple policy which will verify that all of your servers meet your corporate policy for password changes. While we could define a much more detailed policy, I want to keep this simple so you can focus on the process of creating a policy.

Where to Begin

We want to verify that servers are enforcing a password change policy. In other words, we want to check that users are forced to change their password after a specified amount of time. What this magic value should be will be a matter of your corporate password policy. In this example we will use a value of 90 days.

Further, we want to verify that a minimum amount of time must go by before users are permitted to change their passwords. While this check may seem a bit odd on the surface, it helps to keep users from “cheating” during password changes. Most servers will remember a specified number of old passwords. When a user changes their password, they are not permitted to reset it to any of these previous values. If a minimum time value is not specified, a user could repeatedly change their password until this maximum is exceeded, and then set the password back to its original value. Usually a minimum value of one day is sufficient to block this type of activity.

Identifying What to Check

Before we start writing our new policy, we need to do a bit of homework. We need to understand:

  • What files to check
  • What to look for
  • What values are acceptable

Once we have this information in hand we can turn our attention to writing a proper policy.

On most Linux distributions, the minimum and maximum password age is set within the /etc/login.defs file. The “PASS_MIN_DAYS” parameter defines the minimum password age in days, and the “PASS_MAX_DAYS” parameter defines how long the password can be used for before it must be changed. There is also a related valued titled “PASS_WARN_AGE” which defines how many days before expiration the user will start getting prompted to change their password. We will check this value as well, and ensure it is set to 7 days.

Writing Your Policy

To begin creating your new policy, start by logging in to your Halo account. From the main menu, mouse over the “Policies” option, and then click “Configuration Policies” from the drop down menu. When the “My Configuration Policies” screen appears, click the “Add New Configuration Policy” button. This should bring you to the “Add New Configuration Policy” screen shown in Figure 1.

Figure 1: The “Add New Configuration Policy” screen


When the screen appears, give it a descriptive name such as “Max/Min Password Policy Check” or similar. You can then fill in the description box with more verbose information. Once complete, click the “Submit” button.

Your new policy will now appear on the screen. Look for the “System Configuration” item and click the triangle just to the left of it. This will open up some additional options. Click the top option, “Add a New Rule”. Your screen should now look similar to Figure 2.

Figure 2: The Add a New Rule screen

Before we go any further, let’s talk about how Halo’s verification checks are organized. At the Macro level, we have “policies”. Policies include all of the security checks we wish to perform against a system. For example the Base OS policies are defined to check the security settings of all software installed by default. Each policy is then made up of one or more individual “rules”. A rule defines a specific policy parameter we want to validate. For example verifying that users must change their password after a pre-determined amount of time is an excellent example of a rule. Finally, rules are made up of one or more “checks”. A check is where we actually verify that a specific file or parameter is within compliance. Most rules only require a single check. There are instances however where we may need to check values in multiple places in order to ensure the rule meets compliance. So you will frequently see only a single check associated with each rule, but it is entirely possible to see two or three different checks being performed to validate a single rule.

So our policy is going to include three different rules, each performing a single check. The first will validate that passwords must be changed every 90 days. The second will validate that passwords cannot be changed any more frequently than once per day. The third check will validate that users will start being prompted to change their password seven days before the password will expire.

Creating Rule Checks

OK, back to our policy. Your screen should still look like Figure 2 above. Name your rule “Maximum password age”, click the “Critical” radial box, and enter a more verbose description of your choosing. Next, click the “Add New Check” button. Your screen should now appear similar to Figure 3.

Figure 3: Adding a new check

Note that Halo has a number of predefined check types to work with. The one we are interested in however is listed at the very top, namely “Configuration File Setting”. Click this hot link. This will open a new screen where you can define the parameters of your rule check. Figure 4 shows mine already filled in. Feel free to use the same values I did.

Figure 4: Rule Check Configuration Screen

In the first dialog box we define the file we wish to check along with its full path. In this case, the file is /etc/login.defs as shown above. In the second dialog box, we can tell Halo to look for the value only within a specific section of the configuration file. Since login.defs does not use sections, we will leave this blank. The next dialog box is looking for the configuration item. This will be the item name which starts at the first character position on the line. We have to ensure that we enter the value exactly as it will appear in the configuration file. In this case we will use a value of “PASS_MAX_DAYS”. The Desired value dialog box permits us to specify what value we wish to key in on. In this case, we want to check to see that passwords get aged out in 90 days. The next dialog box lets us define what the file uses for a comment character. Since we are not looking for a commented out line, it is safe to leave this line blank.

The Configuration item/Value delimiter dialog box identifies what character will appear between the configuration item and the desired value. Usually this is one or more spaces, a tab or an equal sign. One caveat you will run into is that you cannot enter a tab character into this field. This is because the tab key is reserved for use by the user interface for navigating between fields on the screen.

Luckily, we have a way around this problem. Halo will process both space characters and tabs the same way. So if the delimiter used was one or more spaces or tabs, you can enter in a single space character into this field to cover them all. Note that you have to enter in some value as a delimiter, or Halo will not permit you to save your rule.

Next, we can enter an optional remedial suggestion. This should be an explanation of how to fix the problem if a system is found to be non-compliant. This could be a description of how to manually edit the file, or how to leverage some form of centralized management system your organization has implemented.

Once complete, click the “Save All” button to save your work. That’s it. You’ve just created your first rule check! Only two more rule checks to go and you will have completed your first custom policy. We’ll complete these rule checks as well as apply them to our servers in the next blog post.

Next: Writing a Custom Configuration Policy with Halo – Part II

Stay up to date

Get the latest news and tips on protecting critical business assets.

Related Posts