Blog

Writing a Custom Configuration Policy with Halo: Part II

In my last blog post I walked you through the process of creating a custom Halo policy as well as writing your first rule check. In this post we’ll complete the final two rule checks as well as apply it to a group of servers for testing.

The process for creating the final two rule checks is the same as the first. If you need detailed steps, feel free to refer back to the first blog post in this series. In this post I will simply summarize the steps for creating each rule:

  • Mouse over Policies in the main menu and click “Configuration Policies”
  • Click the hotlink for your newly created custom policy
  • Click the triangle next to “System Configuration”
  • Under System Configuration, click the “Add a New Rule” link
  • Name the rule “Min Password Age”
  • Click the critical radial box
  • Write a verbose description
  • Configuration file path is “/etc/login.defs”
  • Configuration item is “PASS_MIN_DAYS”
  • Desired value is “1”
  • Configuration item/value delimiter is a space character
  • Write a remedial suggestion
  • Your rule check should look similar to Figure 1

Figure 1: Rule check to verify minimum number of days between password changes

Click the “Save All” button

To create the final rule check, follow these steps:

  • Under System Configuration, click the “Add a New Rule” link
  • Name the rule “Days before password change prompt”
  • Leave the critical radial box unchecked
  • Write a verbose description
  • Configuration file path is “/etc/login.defs”
  • Configuration item is “PASS_WARN_AGE”
  • Desired value is “7”
  • Configuration item/value delimiter is a space character
  • Write a remedial suggestion
  • Your rule check should look similar to Figure 2

Figure 2: Rule check to verify minimum number of days between password changes

You have now completed the setup of your custom policy. We now need to apply it to a server group, and then check the policy against each of your servers.

Mouse over “Servers” in the main menu and click on “Configuration Risks”. This will show you the default server groups as well as any custom groups you have configured. Review the list, and determine which group you would like to use with your new policy. Once you have identified a group, click the group name. This will create two new options for group management as shown in Figure 3. Click the “Edit Details” link.

Figure 3: Clicking the group name expands the management options

Once you’ve clicked “Edit Details”, the “Edit Group Details” dialog box will appear. This is the screen we will use to apply our new policy. Look for the “Configuration Policies” option and click the pull down menu to the right of it. This will present a list of available policies you can use for checking the security of this group of server. An example is shown in Figure 4. Click the “Max/Min Password Policy” you just created.

Figure 4: Clicking the “Policies” pull down will present a list of available policies.

Selecting “Max/Min Password Policy” will add it to the list of Configuration policies that will be checked against this group of servers. Note that any previously selected policies will also remain on the list. Halo lets you check as many different policies against a group of servers as you need to. Note you can optionally remove policies by clicking the “remove” link next to the policy name. We can now click the “Save” button at the bottom of the dialog box to save our work. This will return you to the Configuration Risks screen.

HINT: When performing policy testing, it can be helpful to remove all other policies applied to the same group. This makes it easier to focus in on the results of your testing. If you do remove other policies, make sure you put them back once your testing is complete.

While we could run our check against every server in the group, let’s just pick one of them to verify the results. Within the list of server names, tick the box to the right of one of the server names that is currently listed as “Active”; from the “Actions” drop-down menu, select “Launch Scan”.

The Halo interface will inform you that the scan is pending and may take a few minutes to complete. If you just leave this screen open, it will update you on the status of the scan.  When it’s done, click “Details”.

When the scan finishes, the server scan details screen should look similar to Figure 5. Note that in my example two of our rules have failed testing.

Figure 5: The results of scanning a server against the newly created password policy check

Of course simply knowing the rule failed does not tell us a whole lot. Click on “Maximum password age” to bring up more detailed information (which checks passed or failed). When the details screen appears on the right, click the triangle to the left of the word “Failed”. This will show exactly why the item was out of compliance. An example is shown in Figure 6. Note that the password age is set much higher than 90 days.

Figure 6: You can view detailed information as to why a rule checked failed

You can also click through on items that passed testing if you ever wish to validate what was found in the check. Of course we’ll probably be far more interested in fixing failures that gloating over passing results. 😉

One final word on this check that is unrelated to Halo. When you modify the login.defs file to change the password aging policy, this will only impacts accounts created after the change takes place. Any account created prior to the change will maintain the same aging schedule. To change existing account, you need to edit the /etc/shadow file.

Enjoy!

Chris

Stay up to date

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

Related Posts