monitoring configuration security with cloudpassage halo

Configuration Security MonitoringSetup Guide

Contents:About Configuration Security MonitoringSetting Up and Running a Configuration ScanCreating or Customizing a Configuration Policy

What a Configuration Policy IsCreate a New PolicyAdd or Edit Policy Rules and ChecksUse the Rule Library

Managing Configuration PoliciesAddressing CSM Findings

View CSM Scan FindingsAct on Configuration Issues, Findings, and Events

Best Practices for Configuration ScanningAppendix: Configuration Policy Rule Checks

About Configuration Security Monitoring

One of the most important steps you can take toward securing your cloud servers is to ensure that their operatingsystems and applications are properly hardened against attack. Maintaining attack-resistant software configurationsmakes it much more difficult for intruders to gain a foothold on your systems.

The configuration security monitoring feature of CloudPassage® Halo® allows you to monitor the details of yourconfiguration settings, system files, running processes, ownership and permissions to ensure that no unauthorizedchanges are made that could compromise server security.

Once you set up Configuration Security Monitoring (CSM), Halo regularly scans all of your protected servers, looks forsettings that have changed and therefore are violating policy. Halo reports its findings back to the Halo portal ordirectly to you through email alerts.

In scanning each server, Halo applies a set of rules that specify what the secure configuration for that server shouldbe. Each set of rules is called a configuration policy. When you create a new policy, you can choose to base the newpolicy on an existing policy, on one of Halo's default policies containing an initial framework of default rules, or beginwith an empty policy template. In all cases, you assign the new policy a unique name, customize the policy's securityrules, then save the policy.

To set up and use Configuration Security Monitoring, follow these basic steps:

1. Define a server group that includes similarly configured servers. Servers with the same OS and applicationconfigurations can share the same configuration policy.

2. Create or find a configuration policy that can detect departures from your defined secure configuration in those1

servers. Assign that policy to your server group.

3. Enable automatic configuration scanning and set a scan frequency, or else manually execute a scan.

After a scan completes, you can examine the scan report in the Halo portal. If you have set up alerting, you may alsohave email notifications alerting you to critical configuration-security issues. Use that information to remediatedetected issues by restoring the proper configuration settings to the affected servers.

If you need to customize a Halo-provided configuration policy or create your own, you will see that policies are madeof rules, and rules are made of checks. You can learn the details of how all configuration checks work by consultingAppendix: Configuration Policy Rule Checks, at the end of this document.

For ideas on what kinds of issues and specific settings you might want to detect with Configuration SecurityMonitoring, see Best Practices for Configuration Scanning.

Setting Up and Running a Configuration Scan

The following steps provide an overview of the tasks you'll need to perform to create and run a CSM scan.

1. Define a server group to scan.

After you have installed Halo agents on your servers, organize your servers into groups along functional andarchitectural lines.

For information, In the Halo Operations Guide see Setting Up Server Groups.

2. Select or create a configuration policy.

You may want to review existing Configuration Policy choices or need to create a new policy for your ConfigurationScan.

For information, see Creating or Customizing a Configuration Policy.

3. Assign one or more Configuration Polices to a Scan.

For information, in the Halo Operations Guide see Assign Policies to a Group

4. Choose and configure an automatic or manual scan.

You can configure a scan to scan a single server, a selected set of servers, or all servers in a given server group

Automatic scans run at specified intervals.2

https://library.cloudpassage.com/help/article/link/setting-up-server-groups

https://library.cloudpassage.com/help/article/link/security-modules-and-policies#assign-policies

Manual scans run once at the time you create them.

For information about running scans, in the Halo Operations Guide, see Working with Scans.

5. View and act on scan results.

To interpret the results of a CSM scan, you can examine either scan findings or issues.

To view CSM scan findings, click the status value of a CSM scan on the Scans screen of the Environmentpage. In the Halo Operations Guide, see View Scan Findings.

The scan findings page opens. See Addressing CSM Findings and Issues.

To view CSM issues, start with the Issues view on the Environment screen, then view the Issue DetailsSidebar. In the Halo Operations Guide, see View Issue Details.

To get details of the findings underlying the issue, click the Scans link on the sidebar. The scan findings pageopens. For information see Addressing CSM Findings and Issues.

Creating or Customizing a Configuration Policy

Whether you base a new policy on the rules contained in a cloned policy or Halo policy template, or create acompletely template that contains no rules, the steps you perform to create a new CSM policy are essentially thesame.

The following section describes how configuration policies are structured and how to customize them to meet yoursecurity needs.

What a Configuration Policy Is

The purpose of a configuration policy is to define the configuration settings that a given type of server should have inorder to be hardened against attacks. The policy can apply to both the operating system and to applications runningon it. A configuration scan detects deviations from that configuration and reports them.

Each policy consists of a number of rules. Each rule examines an important configuration setting of the operatingsystem or application. The rule does this by applying one or more rule checks, which consist of pattern-matchingtemplates or file paths that characterize what the setting should be. If a rule check finds a setting that is different fromthat, the check fails and the rule fails, and Halo creates a security event that is logged and displayed in the Haloportal.

In Halo, each configuration policy applies to a group of similar servers. Therefore all servers in the group need tohave identical configurations, as far as a configuration policy is concerned. In general, that means that they must allbe running the same OS and applications. Using groups greatly reduces the number of policies that you need tocreate. Furthermore, CloudPassage provides pre-built policies for each of the major Linux distributions and theapplications commonly running on them. These policies allow for quick setup, but may require some customizing tosuit your specific environment.

You create a rule by adding and configuring one or more of the rule checks that Halo provides for you. Checks arethe building blocks of rules, and rules are the building blocks of policies.

When you create a rule, give it a meaningful name that will help you to understand what is wrong with the systemwhen the rule fails.

If any check fails, the rule fails. Rules that fail can produce either critical issues or non-critical issues, according tohow you specify it when you create or edit a rule.

There are over 40 possible types of checks that can be performed on the server. They fall into the following generalcategories:

3

https://library.cloudpassage.com/help/article/link/monitoring-your-environment#about-scans

https://library.cloudpassage.com/help/article/link/monitoring-your-environment#view-scans

https://library.cloudpassage.com/help/article/link/monitoring-your-environment#view-issue-details

Configuration settings

File presence and attributes

Directory attributes

Process presence and ownership

User identity and activity

User home directory settings

Group characteristics

Network services and the processes bound to them

About Indeterminate ResultsSeveral rule checks examine the characteristics of a particular file, such as its permissions or owners. If the file is notpresent, its characteristics cannot be determined and the results of the check are considered indeterminate. Whenyou set up automatic configuration scanning (in the Halo Operations Guide, see Working With Scans), you canspecify whether you want all indeterminate results to be considered failures of the checks (and thus potentiallygenerate events or alerts).

Create a New Policy

You can also choose to create a new configuration policy that contains no rules. To create a completely new policy:

1. In the Halo portal, navigate to Policies > Configuration Policies and click Add New Linux Policy orAdd New Windows Policy.

2. Enter a descriptive name for the policy, and optionally add more details in the Description field.

3. Click Submit. The Edit Configuration Policy page appears.

4. Add rules to the policy, as described next.

Add or Edit Policy Rules and Checks

To add rules to a new or existing configuration policy, take these steps:

1. For a new policy, the Edit Configuration Policy page appears as soon as you click Submit on the Add NewConfiguration Policy page.

For an existing policy, go to the Edit Configuration Policy page by navigating to Policies > ConfigurationPolicies. Click the name of the policy you want to add rules to (or select Edit from the Actions drop-downmenu for that policy). The Edit Configuration Policy page appears.

4

https://library.cloudpassage.com/help/article/link/monitoring-your-environment#about-scans

2. Click the small triangle beside a rule category to view its contents (or click Expand All to show the contents of allof the categories). If you are editing an existing policy, there will already be rules in at least some of thecategories.

3. To add a new rule, click Add Rule under any of the categories. (The categories are just suggestions; you canadd any kind of rule under any category.) To edit an existing rule, click its name and then click Edit.

The New Rule or Edit Rule form appears:

5

4. Supply or modify this information for the rule:

Name. Give the rule a name that explains its purpose.

Critical. Select this if a failure of this rule should be considered a critical security event and be flagged assuch on the Security Events History page in the portal.

Active. If this check box is selected, this rule is applied during a scan. Clear the check box if you want totemporarily deactivate this rule.

API Exportable. If this check box is selected, failures of this rule will be included in the results returned fromthe List Server Issues method of the CloudPassage API. You might clear the check box if you are trying tominimize the quantity of information returned from the API call.

Log. Select this if a failure of this rule should be considered a security event and thus appear on the SecurityEvents History page. For information in the Halo Operations Guide, see View the Security Events History.

Alert. Select this if a failure of this rule should generate an email alert to all users listed on the alert profile ofthis policy's server group. See Set Up Logging and Alerting for more details.

Description. Optionally supply additional information about the rule. This text appears on the ConfigurationPolicies page.

Rule Checks. The setting of these radio buttons applies to all checks in this rule. Use this setting to changethe logic of how the rule passes or fails:

If the rule contains multiple checks and you select AND (the default), all checks must pass for the rule topass; if any check fails, the rule fails.If you select OR, the rule passes if any of the checks within it passes. For the rule to fail, all of its checksmust fail.

Using the OR capability allows you to create policy rules that apply a different logic for defining rule violations.For example, a rule could have one check that requires a given file to have a specific ACL, and another checkthat requires the file to not be present. If the two checks are OR'ed, it means that the file need not exist, but if itdoes it must have that specific ACL.

5. Each rule must contain at least one rule check. To add a check, click Add New Check and choose the checkthat you want from the drop-down list.

To edit a check that is already used by the rule, scroll down below the Edit Rule dialog box to view the desiredEdit Check form.

The New Check (or Edit Check) form appears:

6. Supply or modify the information and settings as appropriate for the check. Click help beside the check's title fordetailed instructions and examples of how to set up this particular check.

See Configuration Policy Rule Checks for explanations of all checks and how to configure them.

Note: A check (and the rule it belongs to) fails if the conditions or settings it specifies do not occur (forexample, if a configuration file's setting does not equal the setting specified in the check); in that casea security event is generated and an alert may be sent. If the conditions of the check do occur (the

6

https://library.cloudpassage.com/help/article/link/monitoring-your-environment#view-security-events

actual setting matches what is in the check), the check passes and no event is generated.

7. To add more checks to this rule, click Add New Check and repeat Steps 5 and 6.

8. When finished adding checks, click Save All to save the checks, the rule, and the policy.

What Makes a Configuration Rule Pass or Fail?Because the pass/fail state of a rule after a scan depends on the state of all of its checks, the AND or OR setting ofthe rule's check operator, and the state of the "Mark indeterminate as failed" check box in the Scanner Settings tab ofthe Site Administration page in the Halo portal, many factors can contribute to the ultimate results of an individualrule's scan. The following table shows how all of the factors interact.

Note: In all cases, the final result Passes means that the configuration is considered safe and no issue orevent is created. The result Fails means that the configuration is considered unsafe and a security issueor event is created. The result Indeterminate means that there is insufficient information to make adecision, and no issue or event is created.

Indeterminate

= failure?

Checkoperator for rule Check 1 Check N Rule result Comment

NO (default)

AND (default)

Passes — Passes (only one check in the rule)

Fails — Fails (only one check in the rule)

Indeterminate — Indeterminate(only one check in the rule)

Passes Passes Passes If all checks pass, the rule passes.

Passes Fails Fails If any check fails, the rule fails.

Passes Indeterminate IndeterminateIf any check is indeterminate and nochecks fail, the rule is indeterminate.

Fails Fails Fails If all checks fail, the rule fails.

Fails Indeterminate Fails If any check fails, the rule fails.

Indeterminate Indeterminate IndeterminateIf all checks are indeterminate, the rule is indeterminate.

OR



Indeterminate — Indeterminate(only one check in the rule)


Passes Fails Passes If any check passes, the rule passes.

Passes Indeterminate Passes If any check passes, the rule passes.


Fails Indeterminate IndeterminateIf any check is indeterminate and nochecks pass, the rule is indeterminate.

Indeterminate Indeterminate IndeterminateIf all checks are indeterminate, the rule is indeterminate.

AND (default)



Indeterminate(fails)

— Fails (only one check in the rule)


Passes Fails Fails If any check fails, the rule fails.

Passes Indeterminate Fails If any check fails, the rule fails.7

YES

(fails)


Fails Indeterminate(fails)

Fails If all checks fail, the rule fails.




OR




— Fails (only one check in the rule)


Passes Fails Passes If any check passes, the rule passes.

Passes Indeterm.(fails)

Passes If any check pas es, the rule passes.


Fails Indeterm.(fails)


Indeterm.(fails)

Indeterm.(fails)


Use the Rule Library

Another way to add a rule to a policy is to copy a previously created rule. Halo supports re-use of rules in this way byproviding the Rule Library.

Whenever you create a configuration policy rule, you can — if the rule might be useful in other policies — save therule to the Rule Library. Then, when you create another policy, you can retrieve the rule from the library, insert it intoyour policy, and customize it if necessary for its new context.

To save a rule to the Library: When you are done creating or editing a configuration policy rule, click Add toLibrary beneath the last rule check form.

To retrieve a rule from the Library: On the Edit Configuration Policy page, click any of the Add a Rule fromLibrary links.

8

To view a list of rules in the Library: Navigate to Policies > Configuration Policies and click Rule Library.

Managing Configuration Policies

As your security requirements grow and change, you will also want to use Halo's policy management options tomanage the policies that are or are not included in the list of active policies.

This section describes Halo's policy actions. To perform most of the following actions, you choose an active policy,policy template, or retired policy from a list and click its Action button. Then you select an action from the drop-downlist.

Policy Manipulation Actions:

Export a PolicyTo export a policy from Halo, select "Export" from the Actions dropdown list.

Halo saves the policy's settings as a JSON-formatted file. You can securely archive the policy file, share the policywith other Halo users, or re-import it at a later time.

Import a PolicyTo import a policy into Halo, click the Import Policy button above the policy list.

On the Import page, click Choose File, then navigate to and select the desired JSON-formatted policy file to import.If the import is successful, the imported policy appears in your list of active policies.

Retire a Policy9

For CSM policies, the Retire action is only available if a policy is not used by any groups.

To retire a policy, select "Retire" from the Actions dropdown list.

Retiring a policy removes it from Halo's list of active policies and adds it to the list of retired policies. Retired policiesare available for later use if they are unretired.

Unretire a PolicyTo unretire a policy, in the Retired Policies page select "Unretire" from the Actions dropdown list.

Halo moves the policy from the retired policies list to the active policies list. It is once again available for editing orassigning to server groups.

Delete a PolicyTo delete a policy, select "Delete" from the Actions dropdown list, then in the confirmation dialog click OK.

Halo permanently removes the policy. It no longer appears in the Active Policies page and cannot be retrieved.

Note: The only way you can recover a deleted policy is to have exported it first, so that you can re-import theexported file.

Policy Creation and Editing Actions:

Clone a Policy or TemplateTo clone a policy or policy template, select "Clone" from the Actions dropdown list.

Halo creates a copy of the policy, adds the word Copy to the policy's name, and places it in the Active Policies list.You often can use the cloned template as-is, or you may wish to use it as the starting point for a custom policy. Inthat case, create a unique name and description for the new policy, then customize its rules.

Note that Halo will not permit you to save a cloned policy if it does not have a unique name.

Create a New PolicyTo create a new policy, click the Add New Policy button above the policy list.

On the new Policy page, Create a unique name and description for the policy. Initially, the policy is empty; add rulesas desired.

Halo will not permit you to save a new policy until you assign the policy a unique name.

Edit a PolicyTo edit an active policy, select "Edit" from the Actions dropdown list.

The Edit Policy page opens, on which you can change the policy's name, description, and rules. When you save it,the updated policy appears on the Active policies page.

Addressing CSM Findings

To accurately assess the level of risk associated with a given CSM finding, issue, or event, you may need to examinethe details of one or more CSM scan findings.

View CSM Scan Findings10

As described in Setting Up and Running a Configuration Scan, above, the easiest way to examine CSM findings indetail is to click a Scan's Status column to display a summary of the scan's results. From there, you can view theindividual findings within a given result.

The CSM scan results page lists the results of all the all of the "bad" findings (failed policy rules) detected in a givenconfiguration scan.

For information about the header area of the scan findings page, in the Halo Operations Guide see View ScanFindings.

The rest of the page lists the scan findings themselves, each identified as failed (critical), failed (non-critical), andindeterminate. In the list of findings, click an individual finding to expand it and view its details.

A configuration issue is a policy rule failure, which by default is a failure of any check in the rule. The aboveresults show that one check failed and one passed in the rule "Disable IP Routing" in the policy "Amazon AMI".Therefore, the rule failed.

By default, the failure of any single rule check in a rule causes the entire rule to fail. This is because a rule's rulechecks are by default logically OR'ed. For example, in the preceding illustration, in the rule "Disable IP Routing",one of the rule's rule checks failed and one rule check passed. The failure of one rule check therefor caused theentire rule to fail.

(You can change this pass-fail logic with the AND/OR radio buttons in the the rule form. See Add or Edit Policy11



https://support.cloudpassage.com/entries/22940246-create-or-customize-a-configuration-policy#create-rules

Rules and Checks in Monitoring Server Configuration Security with CloudPassage Halo.)

Click a failed or passed check to further expand the display, and see exactly what happened—what setting wastested, what value was expected, what value was found, and (optionally) what remediation steps arerecommended. From this info you may be able to infer whether this is a valid security issue that you need toaddress.

If you think that this is not a valid set of rule checks in this situation, you can either (1) click Disable this ruleso that this issue will not occur in future configuration scans or (2) disable the individual failed check on the EditPolicy page, so that it will not be used in the rule during future scans.

Act on Configuration Issues, Findings, and Events

The objective of CSM rules is to categorize the combinations of CSM events and findings that represent securityvulnerabilities in your organization's servers. By extension, the objective of investigating CSM issues, findings, andevents is to remedidate those vulnerabilities.

In most cases, the nature of the a failed rule check identifies what needs to be done to remediate the problem.

Consider whether a particular type of issue can best be remediated by making changes to individual servers, orwhether it will be more efficient to change the servers' gold master image or server template, then re-instantiatethe affected servers from that updated master.

For example, if misconfigured settings or insecure execution states appear to be the source of the issue, log in tothe affected servers to correct settings or modify insecure execution states.

Whenever your server configuration changes significantly, for example you deploy a different app serverapplication, you may need to update your configuration policy or apply a different one.

Evaluate whether an issue is best remediated by modifying server configurations or by further customizing one ormore rule checks to make the policy more precisely suited to your security environment.

When creating rules, remember that the default rules sets contained in Halo's policy templates provide detailedremediation suggestions. For information, see Creating or Customizing a Configuration Policy.

If an issue appears to be the result of unauthorized tampering with your systems, you may decide to immediatelyquarantine the affected server or servers and contact your incident response or forensics teams.

Best Practices for Configuration Scanning

Use the examples in this section to get ideas for approaching your own configuration-security needs. You'll see howyou can use the CloudPassage-provided configuration templates to protect your servers' operating systems andapplications, how you can create custom policies to protect other applications, and how you can use use Halo'spowerful rule checks to address a wide range of security issues.

Use a built-in core policy for basic OS protectionYou can find these core configuration policies in the list of configuration-policy templates in the Halo portal:

OS Core (Debian-based Linux) Policy v3

OS Core (RPM-based Linux) Policy v3

The rules in these policies check that the most critical security settings are in place. Consider using one of thepolicies as your starting point for configuration scanning.

To use either of these templates, clone it and customize it to fit your specific OS distribution and your environment

12

https://support.cloudpassage.com/entries/22940246-create-or-customize-a-configuration-policy#create-rules

(file paths, process names, and so on).

Depending on who your cloud provider is, you may need to perform some customization on the policy. For example,some of its rules have multiple checks and only one of them is enabled. In the case of the rule "Logging servicesshould be running", it checks that "syslog-ng" is the default logging service. Some cloud providers instead configure"syslog" or "rsyslog" as the default logging service. In that case, just activate the appropriate check within that rule.

Use a built-in extended policy for stronger OS protectionYou can find these extended configuration policies in the list of configuration-policy templates in the Halo portal:

OS Extended (Debian-based Linux) Policy v3

OS Extended (RPM-based Linux) Policy v3

These policies are available as options for further enhancement of the security provided in the core policy templates.You use one of these policies in conjunction with its core policy, not instead of it.

To use either of these templates, clone it and customize it to fit your specific OS distribution and your environment(file paths, process names, and so on).

These policies apply rules that check for more stringent security levels that might be required for your cloud servers.For example, the rule "User account password policies with min length extended" checks that the value forPASS_MIN_LEN is 10, which is longer than what the core rule requires. Also, password lifetime in the extendedpolicies is 90 days, compared to 180 days for core policies.

Some rules are not active by default and are in this policy as reference only.

Note: Because extended policies' security rules are more stringent, extended policies typically generate morefailure alerts by default than do core policies. To minimize false positives when using extended policies,more customization may be required .

Use a built-in application-level policy to protect server applicationsYou can find these higher-level configuration policies in the list of configuration-policy templates in the Halo portal:

Apache for CentOS, Red Hat, Fedora, Amazon AMI Linux - v2

Apache for Debian, Ubuntu Linux - v2

MySQL for CentOS, Red Hat, Fedora, Amazon AMI Linux - v2

MySQL for Debian, Ubuntu Linux - v2

These configuration policies address configurations of the application-level server software, not the operating systemsbeneath them. You would use one of these policies in conjunction with the core or advanced configuration policy forits operating system.

To use one of these templates, clone it and customize it to fit your specific OS distribution and your environment (filepaths, process names, and so on).

These policies are likely to require customization and addition of rules to meet your security requirements, especiallyif you have made changes to your application-server configuration (such as path changes, ownership changes,running account name changes, and so on).

Use a NOT rule check to verify the non-occurrence of a specificsettingSome rule checks support use of the NOT operator, which allows you to check for a state in which a specified settingdoes not exist.

For example, you could set up a configuration-file setting check to verify the number of days that must elapsebetween password resets. You could specify a number of days (for example, 3) that matches your password-management policies, and then check the configuration file for that value.

13

On the other hand, it may be that you really only want to ensure that a user cannot change his or her passwordrepeatedly in a single sitting. So any value other than zero (days) would be acceptable. In that case, you could set upa password-reset check with a value of 0 and apply NOT to that value. As long as the number of days between resetsis not zero, the check passes.

In the configuration-file setting check form, you would enter values such as these:

Configuration file path = /etc/login.defs

Configuration item = PASS_MIN_DAYS

Desired value = NOT:0

Configuration file comment character = #

Use a policy rule's and/or flags to combine related rule checksYou can create a rule that has more than one rule check, then use the rule's AND and OR flags to determine whetherall or only one of the individual rule checks must occur for that rule to pass.

The AND setting requires that all of the conditions specified in the rule be detected before Halo will create an eventfor that rule. For example, the Linux rule template Enable SELinux in /etc/grub.conf contains two rule checks:Selecting AND requires that both of those rule checks must be detected to produce an event.

Conversely, the OR setting produces an event when any one or more of the conditions specified in the rule aredetected.

For details, see What Makes a Configuration Rule Pass or Fail?

Use a string-presence rule check to verify the existence of any textThe configuration-file setting check does a great job at finding key-value pairs in configuration files or other text files.However, there may be times when you need a more general text-search capability, and that is where the string-presence check can be very handy.

Suppose, for example, you want to create a check that verifies that debugging is turned off. If the configuration-fileline that you need to verify looks like the following, you can easily use a configuration-file setting check to detect thevalue false:

Debug=false

However, if the line is more complicated, like

Debug=syslog,stderr,false

you won't be able to find the name-value pair debug and false with a configuration-file setting check. But with astring-presence check, you could have it look for this expression in the file:

^Debug=.*false.*

which essentially means "look at the beginning of a line for the string 'Debug=' followed by zero or more characters,followed by the word 'false', in turn followed by zero or more characters.

This expression would match both of the above lines, as well as even more complicated ones, like

Debug=(mode=restricted,false,max_severity=10)

If you are familiar with regular expression syntax, you'll notice that this syntax is similar, although it's not exactlyidentical and it's not as complete. The documentation for the string-presence check (see Rule Check: StringPresence) describes the details of the syntax.

Identify crashed processes on your serversYou can use the process-presence check in a configuration policy rule to alert you when a critical process on yourserver crashes.

14

For example, assume that you have decided that a crash of any of the processes rsyslogd, sshd, or apached onany of the servers in a server group should be considered critical and that you should be alerted.

1. Create a configuration policy with a rule containing a process-presence check.

2. In the form for creating the check, enter the names of the above three processes and specify that they should berunning.

3. In the form for the rule itself, select the Active, Critical, Log and Alert check boxes.

4. Save the policy and assign it to your server group.

During any of your subsequent configuration scans for that group, the absence of any of those processes will causean alert to be sent.

Locate dangerous binaries on your serversA default Linux distribution typically includes a number of system tools that, while useful for particular purposes, arenot needed on every server and may be dangerous if executed by an intruder who has broken into the system. Youcan create a configuration policy to identify the presence of those programs so you can remove them as a safetyprecaution.

Examples of these programs include telnet, tcpdump, and ping. Tools like these are useful to both administratorsand hackers, so you'll need to decide for each server group which tools must remain on the servers and which can beremoved.

1. Create a configuration policy with a rule containing multiple process-presence checks.

2. In the form for creating each check, enter the full path to the binary that should have been removed and specifythat it should not be present.

3. Save the policy and assign it to the server group that you want to monitor.

During any of your subsequent configuration scans for that group, the presence of any of those files will generate asecurity event that you can view in the Halo portal.

Copyright© 2016 CloudPassage Inc. All rights reserved. CloudPassage® and Halo® are registered trademarks of CloudPassage, Inc.

15

Monitoring Server Configuration Security > Configuration Policy Rule Checks

Appendix: Configuration Policy Rule Checks

A configuration policy rule consists of one or more checks—tests that evaluate system characteristics such asconfiguration settings, files and directories, processes, users and groups, and network services. For instructions oncreating or editing an individual check, click its name beneath either of the tabs below.

By Category Alphabetic

WINDOWSFile presenceService StartedProcess PresenceRegistry Key Value SettingLocal Security Policy setting

Local User Rights AssignmentAdvanced Audit Policy SettingDirectory PresenceGeolocation by country

LINUXConfiguration settings

Geolocation by countryConfiguration-file setting

File, string, and and package attributesFile presenceFile ACLFile user ownershipFile group ownershipFile setuidFile setgidString presencePackage presence

Directory attributesDirectory presenceMount pointDirectory ACLDirectory user ownershipDirectory group ownershipWorld-writable directories have sticky bit set

Process presence and ownershipProcess presenceProcess user ownershipProcess group ownership

User identity and activityUser presenceUser has passwordPassword is not expired

Password does not match usernameUser account UIDUser group membershipRecent account loginNo recent account login

User home directory settingsHome directory existsHome directory owned by correct userHome directory owned by correct groupHome directory files owned by correct userHome directory files owned by correct groupHome directory files have no invalid umask CommandsHome directory files have no unsafe PATH statementsHome directory has no setuid filesHome directory has no setgid filesHome directory has no device filesHome directory file presence

Group characteristicsGroup GIDGroup membersGroup has password

Network servicesNetwork service accessibilityNetwork service processes

16

Monitoring Server Configuration Security > Configuration Policy Rule Checks

Appendix: Configuration Policy Rule Checks

A configuration policy rule consists of one or more checks—tests that evaluate system characteristics such asconfiguration settings, files and directories, processes, users and groups, and network services. For instructions oncreating or editing an individual check, click its name beneath either of the tabs below.

By Category Alphabetic

Advanced Audit Policy Setting (Windows)Configuration file settingDirectory ACLDirectory group ownershipDirectory presenceDirectory presence (Windows)Directory user ownershipFile ACLFile group ownershipFile presenceFile presence (Windows)File setgidFile setuidFile user ownershipGeolocation by country (Linux and Windows)Group GIDGroup has passwordGroup membersHome directory existsHome directory file presenceHome directory files have no invalid umask CommandsHome directory files have no unsafe PATH statementsHome directory files owned by correct groupHome directory files owned by correct userHome directory has no device files

Home directory has no setgid filesHome directory has no setuid filesHome directory owned by correct groupHome directory owned by correct userLocal Security Policy setting (Windows)Local User Rights Assignment (Windows)Mount pointNetwork service accessibilityNetwork service processesNo recent account loginPackage presencePassword does not match usernamePassword is not expiredProcess group ownershipProcess presenceProcess Presence (Windows)Process user ownershipRecent account loginRegistry Key Value Setting (Windows)Service Started (Windows)String presenceUser account UIDUser group membershipUser has passwordUser presenceWorld-writable directories have sticky bit set

17

Monitoring Server Configuration Security > Configuration Policy Rule Checks > File Presence (Windows)

Rule Check: File Presence (Windows)

The File Presence check for Windows verifies the presence (or absence) of one or more files on a scanned Windowsserver. To check for the presence of a directory, use the Directory Presence (Windows) check instead.

Parameters Description

File(s) The full path to the file to look for. Any valid, full path to a single file, or a comma-delimited list of file paths is acceptable. A path may include a Windows systemenvironment variable, using the format %envVariable%partialPath.

Note: The asterisk (*) is the only acceptable wildcard character. You cannot use aquestion mark.

Important: Every target filename (other than a symbolic link) must include the fileextension.

Some valid examples:

C:\Windows\system32\winload.exe

C:\Program Files\Internet Explorer\iexplore.exe

%SYSTEMDRIVE%\Program Files\Internet Explorer\*

C:\Program Files (x86)\Adobe\Acrobat 10.0\Setup

Files\Setup.ini

D:\drivers\LAN\Silent_Install.bat,

D:\drivers\LAN\Silent_Uninstall.bat

Some examples that will not work:

C:\Program Files\Internet Explorer

Program Files\Internet Explorer\iexplore.exe

C:\Program Files\Internet Explorer\iexplore

C:\Windows\system32\?.exe

Should be present This check fails if any of the listed files is not present.

Should not be present This check fails if any of the listed files is present.

Remediation Suggestion (optional) Optional suggestion

18

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Service Is Started (Windows)

Rule Check: Service Started (Windows)

The Service Started check for Windows verifies whether one or more specified Windows Services are running on theserver. Depending on a setting, the check either passes or fails for each specified service that is running, or else itserves as a whitelist of permitted services.


Service(s) The name of the Windows service to search for. Can be any valid service name or acomma-delimited list of names. Wildcards are not allowed, although you can use theasterisk character (*) if it is part of a service name.

Note: The service name needs to be the "Service Name" of the service, not its(typically longer) "Display Name".

Some valid examples are:

dhcp

certpropsvc, dcomlaunch

Should be started/running This check fails for any of the listed processes that is not running.

Should not be started/running This check fails for any of the listed processes that is running.

OK to be started/running This check fails if any running process is not one of the list listed processes. In thiscase the check functions as a whitelist.


20

s

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Process Presence (Windows)

Rule Check: Process Presence (Windows)

The Process Presence check for Windows verifies whether one or more processes are running on the server. Thischeck applies to all running processes, including Windows services.


Process(es) The name of the process to search for. Can be any valid process name or a comma-delimited list of names. Wildcards are not allowed, although you can use the asteriskcharacter (*) if it is part of a process name.


cmd.exe

cphalow.exe,dllhost.exe

Should be running This check fails if any of the listed processes is not running.

Should not be running This check fails if any of the listed processes is running.

Allowed to be running This check fails if any running processes is not listed. If you choose this option, thecheck functions as a whitelist: the check passes if all running processes are listed, andit fails if any process not on the list is running.


21

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Registry Key Value Setting (Windows)

Rule Check: Registry Key Value Setting (Windows)

The Registry Key Value Setting check for Windows verifies whether a specified Windows registry key has a specifiedvalue.

The check examines both the name and data portions of all actual values of the specified registry key to verify that avalue of the specified name exists and that its data portion is equal to the specified expected setting. The check failsif the data portion of the value specified by name does not match the expected setting. The check is indeterminate if(1) the value specified by name does not exist in the key, or (2) the key itself does not exist.


Registry Key The full path to the registry key to examine. The key path is case-insensitive. Neitherwildcards nor recursion is supported. However, a path may include a Windowsenvironment variable, using the format %envVariable%partialPath.

Registry Value The name of the value to examine. Names are case-insensitive. Neither wildcards norrecursion is supported.

You can specify only one value name per check. Use multiple checks if you want toexamine multiple values.

Expected data The setting that the value should have. Supply it in the expected format:

If the value is a STRING, enter the string (for example, admin001).If the value is a MULTISTRING, enter a single string with the substrings separatedby \0 null terminators (for example, test1\0test2\0test3).If the value is a DWORD or QWORD, enter the decimal value as a string (forexample, 255).If the value is BINARY, enter the hexadecimal value as an unprefixed string (forexample, FAA123DF45).

To supply multiple acceptable settings for the value, use a comma-separated list.

If the expected value setting itself contains a comma, you must escape that commawith a backslash ("\,") so that it will not be considered a separator. For example, if theexpected value setting is "%SystemRoot%\system32\shell32.dll,4", enter it this way:

%SystemRoot%\system32\shell32.dll\,4

To specify that the expected value setting should be empty/nothing, leave the"Expected data" field blank.

The NOT operator is supported. Use it to specify one or more data settings that, if any ispresent, will cause the check to fail.

Some examples that will work:

1

NOT: 0

255 (do not specify hexadecimal, as in 0xFF, for a DWORD or QWORD value)admin001,jsmith,rkumar23


22

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Local Security Policy Setting (Windows)

Rule Check: Local Security Policy Setting (Windows)

The Local Security Policy Setting check for Windows verifies whether a specified Local Security Policy setting has agiven value on a scanned Windows server.

Local security policy is a set of locally stored information defining the security of a Windows system. The informationincludes the domains trusted to authenticate logon attempts, the user accounts that may access the system and how,the rights and privileges assigned to accounts, and the security auditing policy.

Note that local security policy settings are subject to override by Group Policy settings at regular refresh intervals.

This check allows you to verify the value of any one of approximately 25 local security settings.


Setting The name of the Local Security Policy setting to check. Select it from the drop-downlist.

Note: The Windows secedit tool and the List server issues call in theCloudpassage API use abbreviated setting names, as listed below under Valid Valuesfor Local Security Policy Settings.

Desired value Enter the value that this setting should have. Optionally apply the NOT, > (greaterthan), or < (less than) operator to change the meaning of certain settings.

Restrictions on valid values and operators for the currently selected setting aredisplayed on the Local Security Policy Setting dialog box; information for for all settingsis summarized under Valid Values for Local Security Policy Settings.


1 (for "Store passwords using reversible encryption")

NOT: 0 (for "Audit system events")

< 91 (for "Maximum password age")

NOT: Administrator (for "Accounts: Rename administrator account")


2 (for "Store passwords using reversible encryption")

4 (for "Audit system events";)

999 (for "Maximum password age")

Cruz=Admin (for "Accounts: Rename administrator account")


24

https://support.cloudpassage.com/entries/23131848-Servers#list-server-issues

Valid Values for Local Security Policy SettingsNote: For numeric values, units are shown in brackets [ ]. For all settings, operators are optional.

Setting secedit Name Possible valuesPossibleOperators

Account lockout duration LockoutDuration 0–99999 [hours] NOT, <, >

Account lockout threshold LockoutBadCount 0–999 [attempts] NOT, <, >

Accounts: Administrator account status EnableAdminAccount 0 = Disabled1 = Enabled

NOT

Accounts: Guest account status EnableGuestAccount 0 = Disabled NOT

25

1 = Enabled

Accounts: Rename administrator account NewAdministratorName string* NOT

Accounts: Rename guest account NewGuestName string* NOT

Audit account logon events AuditAccountLogon 0 = Log neither1 = Log success2 = Log failure3 = Log both

NOT

Audit account management AuditAccountManage 0 = Log neither1 = Log success2 = Log failure3 = Log both

NOT

Audit directory service access AuditDSAccess 0 = Log neither1 = Log success2 = Log failure3 = Log both

NOT

Audit logon events AuditLogonEvents 0 = Log neither1 = Log success2 = Log failure3 = Log both

NOT

Audit object access AuditObjectAccess 0 = Log neither1 = Log success2 = Log failure3 = Log both

NOT

Audit policy change AuditPolicyChange 0 = Log neither1 = Log success2 = Log failure3 = Log both

NOT

Audit privilege use AuditPrivilegeUse 0 = Log neither1 = Log success2 = Log failure3 = Log both

NOT

Audit process tracking AuditProcessTracking 0 = Log neither1 = Log success2 = Log failure3 = Log both

NOT

Audit system events AuditSystemEvents 0 = Log neither1 = Log success2 = Log failure3 = Log both

NOT

Enforce password history PasswordHistorySize 0–24 [passwords] NOT, <, >

Maximum password age MaximumPasswordAge 0–999 [days] NOT, <, >

Minimum password age MinimumPasswordAge 0–998 [days] NOT, <, >

Minimum password length MinimumPasswordLength 0–14 [characters] NOT, <, >

Network access: Allow anonymous SID/Nametranslation

LSAAnonymousNameLookup 0 = Disabled1 = Enabled

NOT

Network security: Force Logoff when hours expire ForceLogoffWhenHourExpire 0 = Disabled1 = Enabled

NOT

Password must meet complexity requirements PasswordComplexity 0 = Disabled1 = Enabled

NOT

26

Reset account lockout counter after ResetLockoutCount 0-99999 [hours] NOT, <, >

Store passwords using reversible encryption ClearTextPassword 0 = Disabled1 = Enabled

NOT

*May consist of alphanumeric characters plus space and other special characters, except for " / \ [ ] : | < > + = ; , ? , .

27

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Local User Rights Assignment (Windows)

Rule Check: Local User Rights Assignment (Windows)

The Local User Rights Assignment check for Windows verifies whether the provided set of users and/or groupsencompasses all who are assigned to the specified user right (policy) on a scanned server.

User Rights Assignment is part of the Local Security Policy on a Windows server. It assigns users and groups to eachsecurity right on the server. Over 40 different rights are defined.

This check passes if all users and groups on the supplied list have the selected right. The check fails if any of theusers or groups does not have that right, or if others who do have the right are missing from the list. You can use thecheck to verify that only appropriate users and groups have a given right on the server.


Policy The name of an individual user right that can be assigned. Select one from the drop-down list.

Security Settings The name(s) of one or more users or groups that should have the selected securityright. Separate individual group or user names with commas. The order of the names inthe list does not matter.

Note: This field accepts input that includes the special characters "@" and "\", so thatyou can supply domain user account names.


rkumar23, jsmith

Administrators,rkumar23

[email protected]

cruzcloud\ccolon


NOT: rkumar23

Backup Operators jsmith

Backup Operators; jsmith

Note: The user "NT SERVICE\WdiServiceHost" cannot be specified by name. For thisuser only, you must provide the SID instead of the username.


28

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Advanced Audit Policy Setting (Windows)

Rule Check: Advanced Audit Policy Setting (Windows)

The Windows advanced security audit policy allows fine-grained control over what events on a server should belogged for auditing purposes. Only logged events will be viewable in the Windows Event Viewer.

The Advanced Audit Policy Setting check verifies whether a given advanced security audit policy setting (or auditsubcategory) has the value that you expect on a scanned Windows server. Using the check in a configuration policyallows you verify that the audit events you want to log are being logged.

This one check allows you to verify the desired setting of any one of over 50 advanced audit policy settings.


Audit Subcategory The name of the advanced security audit policy setting to check. Select it from thedrop-down list.

Desired value Select the value or values that are acceptable for this setting. You can select multiplevalues:

No Auditing. Do not log any events related to this policy setting.Success. Log only successful executions of a task related to this policy setting.Success and Failure. Log both successful and failed attempts.Failure. Log only failed attempts to execute a task related to this policy setting.


30

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Directory Presence (Windows)

Rule Check: Directory Presence (Windows)

The Directory Presence check for Windows verifies whether a specified directory or set of directories is—or is not—present on a Windows system. To check for the presence of a (non-directory) file, use the File Presence (Windows)check instead.


Folder(s) The full path to the directory to look for. Any valid, full path to a single directory, or acomma-delimited list of paths is acceptable. Wildcards are not supported. However, apath may include a Windows system environment variable, using the format%envVariable%partialPath.


C:\Windows\system32

%SYSTEMDRIVE%\Windows\system32

C:\Program Files\Internet Explorer

C:\Program Files (x86)\Adobe\Acrobat 10.0\Setup Files

D:\drivers\LAN


C:\Program Files\Internet Explorer\iexplore.exe

Program Files\Internet Explorer

C:\Windows\system32\*

C:\Windows\system32\*.exe

Should be present This check fails if any of the specified directories is not present.

Should not be present This check fails if any of the specified directories is present.


32

Copyright ©2014 CloudPassage Inc. All rights reserved. CloudPassage® and Halo® are registered trademarks of CloudPassage, Inc.

33

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Geolocation by Country

Rule Check: Geolocation by Country

The Geolocation by Country check compares the server's geolocation (as displayed in parentheses in theConnecting IP Address field on the Server Summary page of the Halo portal) with the country-code valuesspecified in this check, and then either passes or fails depending on whether the server location matches or does notmatch any of the listed countries.

This check is typically used to ensure that a server is located in an approved country (whitelisting), or to ensure thatthe server is not located in a disapproved country (blacklisting).


These countries The three-letter ISO 3166-1 alpha-3 country code of a country. Can be a single validcode or a comma-delimited list of codes.


GBR

BEL, NLD, LUX

Are allowed for servers to connectfrom

This check fails if the server's geolocation is not in the specified list of country codes.

Are not allowed for servers toconnect from

This check fails if the server's geolocation is in the specified list of country codes.


34

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Configuration File Setting

Rule Check: Configuration File Setting

The configuration file setting check searches for a string or numeric value in a file on the server, and compares it withvalid values. This check is typically used to validate a name-value pair in a configuration file.


Configuration file path The name of the file to search in. If the file is not present, the test will either Fail or beIndeterminate based on the setting set in [Site Administrator menu] > SiteAdministration > Scanner Settings > Mark finding as Failed if the checkwas indeterminate checkbox. Any valid, full system path to a file is acceptable.

Example: /etc/ssh/sshd_config

Configuration file section (optional) Use this parameter to find a predefined section of the file before beginning the searchfor the desired term. This parameter will be found before looking for the Configurationitem. Any simple string can be used. If blank, this item is ignored.

Examples:

[repository]Section "device"

Configuration item The string that precedes the value to be validated. This is the name portion of thename-value pair. Any simple string can be used. This field is optional; if it is empty,the first line of the file is checked.

Example: Protocol (as in Protocol 2 in the configuration file)

Desired value A value that is compliant with the policy. This is the value portion of the name-valuepair. Any string or number value can be used. Some example values:

2 (as in Protocol 2 in the configuration file)22 (as in Port 22)yes (as in UsePrivilegeSeparation yes)/etc/ssh/ssh_host_rsa_key (as in HostKey/etc/ssh/ssh_host_rsa_key)NOT: 22 (as in Port <some number other than 22> in the configurationfile)

Using the NOT operator

Place the NOT: operator before the value to specify that it should not occur for thisitem. For example, if you wish to verify that the SSH process is listening on a non-standard port (that is, the check should fail if sshd is listening on port 22), specifyNOT: 22 as the desired value for the Port configuration item.

About comment characters and the NOT operator

Halo handles comment characters in relation to the NOT operator like this:

In each line in a configuration file, Halo ignores everything after a commentcharacter.

Therefore, in searching for a particular value for a given configuration item, if theitem exists but it or its value follows a comment character, the check faiils.

And in searching for "NOT a particular value" for a given item, if the item existsbut it or its value follows a comment character, the check passes.

In searching for "NOT a particular value" for a given item in a given section of thefile, if the file section is not found or if the configuration item is not found, thecheck passes.

Checking the value of a whole file

In certain cases, you can use the Desired value field to check the value of thecontents of an entire file. The file content must be a single string with no line breaks orreturns. In the rule check, you must leave the Configuration item field blank, andspecify the file's expected string in the Desired value field.

35

For example, to verify that IP forwarding is off, you might inspect a particular filewhose string value is either 0 or 1. You could make these settings for the check:

Configuration file path: /proc/sys/net/ipv4/ip_forwardConfiguration item: <blank>Desired value: 0

Configuration file commentcharacter (optional)

Character or string that is used to comment out a line. Commented lines are ignored inthe search for the preceding values. Any string can be used. If this field is left blank,the Halo agent assumes that no lines are commented out.

Example: #

Configuration item/value delimiter Character that separates the configuration item from the value of that item. The defaultis a space.

Note that multiple spaces between the item name and value in the configuration fileare collapsed to a single space for performing the check.

Remediation Suggestion (optional) Recommendation on how to fix the problem. This can be any string.

36

Monitoring Server Configuration Security > Configuration Policy Rule Checks > File Presence

Rule Check: File Presence

The File Presence check determines whether one or more files are present on a Linux server. To check for thepresence of a directory, use the Directory Presence check instead.


File(s) The name of the file to look for. Any valid, full path to a single file, a comma-delimitedlist of paths to individual files, a single wildcard file path, or a comma-delimited list ofwildcard file paths is acceptable.



/etc/init.d/httpd

/etc/init.d/httpd, /etc/init.d/mysqld

/etc/init.d/*

/etc/rc.d/rc0.d/*, /etc/rc.d/rc1.d/*


init.d/httpd

/etc/rc.d/rc?.d

Should be present This check fails if any of the listed files is not present.

Should not be present This check fails if any of the listed files is present.


37

Monitoring Server Configuration Security > Configuration Policy Rule Checks > File ACL

Rule Check: File ACL

The File ACL check determines whether one or more files have the specified file-access settings.


File(s) The name of the file to look for. If the file is not present, the test will either Fail or beIndeterminate, depending on the state of the Mark finding as Failed if the checkwas indeterminate checkbox, accessible at [Site Administrator menu] > SiteAdministration > Scanner Settings.

Any valid, full path to a single file, a comma-delimited list of paths to individual files, asingle wildcard file path, or a comma-delimited list of wildcard file paths is acceptable.



/etc/init.d/httpd


/etc/init.d/*



init.d/httpd

/etc/rc.d/rc?.d

should have ACL(s) A three-character string representing the desired security value. Any three-digit octalvalue can be used. Use an asterisk (*) for a wildcard in any position. You can use theNOT: operator to exclude a set of values. Spaces are ignored.

Note: File setuid and setgid states are separate checks.


777

400

**7

6**

NOT: 777, 577, 377


0777

Remediation Suggestion (optional) Optional suggestion.

39

Monitoring Server Configuration Security > Configuration Policy Rule Checks > File User Ownership

Rule Check: File User Ownership

The File User Ownership check determines whether one or more files are owned by a specific user account or by oneof a list of user accounts.






/etc/init.d/httpd


/etc/init.d/*



init.d/httpd

/etc/rc.d/rc?.d

should be owned by user(s) The comma-delimited list of account names (not account UIDs) that should include theowner of this file. Any single account name or comma-separated list of names isacceptable.

Use the NOT: operator to exclude a set of names. Spaces are ignored.


root

root, admin

root, admin, jsmith

NOT: nobody, ftp, system


root, 0

0, 101, 201

IN: 0, 101, 201


41

Monitoring Server Configuration Security > Configuration Policy Rule Checks > File Group Ownership

Rule Check: File Group Ownership

The File Group Ownership check determines whether one or more files are owned by a specific user group or by oneof a list of user groups.






/etc/init.d/httpd


/etc/init.d/*



init.d/httpd

/etc/rc.d/rc?.d

should be owned by group(s) The group names (not group GIDs) of the group or groups that should include thegroup owner of this file. Any single name or comma-separated list of names isacceptable. Use the NOT: operator to exclude a set of group names. Spaces areignored.


root

root, admin

root, admin, jsmith



root, 0

0, 101, 201


43

Monitoring Server Configuration Security > Configuration Policy Rule Checks > File setuid

Rule Check: File setuid

The File setuid check determines whether one or more files have the setuid permissions bit set.






/etc/init.d/httpd


/etc/init.d/*\



init.d/httpd

/etc/rc.d/rc?.d

should be setuid Fails if the setuid bit is not set on one or more of the files.

should not be setuid Fails if the setuid bit is set on one or more of the files.


45

Monitoring Server Configuration Security > Configuration Policy Rule Checks > File setgid

Rule Check: File setgid

The File setgid check determines whether one or more files have the setgid permissions bit set.






/etc/init.d/httpd


/etc/init.d/*



init.d/httpd

/etc/rc.d/rc?.d

should be setgid Fails if the setgid bit is not set on one or more of the files.

should not be setgid Fails if the setgid bit is set on one or more of the files.


47

Monitoring Server Configuration Security > Configuration Policy Rule Checks > String Presence

Rule Check: String Presence

The String Presence check determines whether a particular text string is (or is not) present in any of one or morespecified files. You use a syntax similar to regular expressions to specify the string to find. You specify the files usingfull pathnames.

Results are reported separately for each file—passed, failed, or indeterminate.

Note: The pattern-matching for this check processes each line in a multiple-line text file as a separate targetstring, and stops analyzing that file as soon as a match occurs.


File(s) The name of the file to look for the string in. If none of the specified files is present, thecheck is indeterminate for that file.

Any valid, full path to a single file or a comma-delimited list of paths to individual files isacceptable. Wildcards are not supported.


/etc/init.d/httpd



init.d/httpd

/etc/rc.d/rc?.d

/etc/init.d/*

Contains If you choose this, the check fails for each of the listed files in which the specifiedstring is not present.

Does not contain If you choose this, the check fails for each of the listed files in which the specifiedstring is present.

...the following pattern: Enter the string to be found, or an expression that represents the string. See SearchExpression Syntax in the Halo Operations Guide for an explanation of thesupported syntax. It is similar to a subset of regular expression syntax.

Some valid search-string examples (all will match "cloud 9"):

cloud 9

cloud\s9

cloud.9

cloud\s\d

[cdlou]\a\w.d [709]

Some examples that will not work as expected (if you are familiar with regularexpressions):

[cdlou]{5}9 (repetition operator not supported)

cloud (1|9) (option operator [pipe] and grouping by parentheses notsupported)

Some example search strings that might be useful for server security:

^host\s.*0.0.0.0/0.*trustSearch for (and alert on) matching strings in the configuration file pg_hba.conf on

49

https://support.cloudpassage.com/entries/22927135-C-Search-Expression-Syntax

https://support.cloudpassage.com/entries/22927135-C-Search-Expression-Syntax

your PostgreSQL database servers. This string would allow password-freeconnection to the server from any IP address (if your firewall were down orbypassed).

In cloud environments that do not use DHCP, search for the character 0 or 1in the file /proc/net/packet. It might indicate that the host has beencompromised and is being used to sniff for traffic or do MAC spoofing.

Remediation Suggestion (optional) Description of how you plan to remediate situations in which this check fails.

50

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Package Presence

Rule Check: Package Presence

The Package Presence check compares the specified package name or names with the installed set of packages onthe server being scanned. Depending on which option you choose, the check fails and an event is generated if alisted package is not installed, or is installed, or if an installed package is not listed.


Package name(s) The name of the package to look for. Any complete package name or a comma-delimited list of package names is acceptable. Wildcards are not supported.


bash.x86_64

bash.x86_64,rsyslog.x86_64,util-linux.x86_64


bash

bash*

bash.x86_??

Should be installed If you choose this, all of the listed packages should be installed. If any is missing, thecheck fails.

Should not be installed If you choose this, none of the listed packages should be installed. If any is installed,the check fails. (The check fiunctions as a blacklist.)

Allowed to be installed If you choose this, any of the listed packages is acceptable to be installed. If anyinstalled package is not in the list, the check fails. (The check functions as a whitelist.)


51

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Directory Presence

Rule Check: Directory Presence

The Directory Presence check verifies whether a specified directory or set of directories is—or is not—present on aLinux system. To check for the presence of a (non-directory) file, use the File Presence check instead.


Folder(s) The name of the directory to look for. Any valid, full path to a single directory, acomma-delimited list of paths to individual directories, a single wildcard directory path,or a comma-delimited list of wildcard directory paths is acceptable.



/etc/init.d

/etc/init.d, /var/lib/mysql/test

/var/lib/mysql/*


init.d

/etc/init.d/mysqld

Should be present The check fails if any of the specified directories is not present.

Should not be present The check fails if any of the specified directories is present.


Copyright ©2014 CloudPassage Inc. All rights reserved. CloudPassage® and Halo® are registered trademarks of CloudPassage, Inc.53

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Mount Point

Rule Check: Mount Point

The Directory Mount Point check verifies on a Linux system that a given file or directory (specified by path) is—or isnot—mounted at a given point in the file system (also specified by path).

You can use this check to, for example, confirm that the log file file /var/log/messages is not mounted on the rootpartition (/), where it could potentially fill up the system disk and cause an outage.


Target Full path to the mounted file or directory. Widcards are not accepted.

Should be mounted on This check fails if the target is not mounted at the specified mount point.

Should not be mounted on This check fails if the target is mounted at the specified mount point.

Mount point Full path to the directory used as the mount point. Widcards are not accepted.



55

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Directory ACL

Rule Check: Directory ACL

The Directory ACL check determines whether one or more directories have the specified file-access settings.


Folder(s) The name of the directory to look for. If it is not present, the test will either Fail or beIndeterminate, depending on the state of the Mark finding as Failed if the checkwas indeterminate checkbox, accessible at [Site Administrator menu] > SiteAdministration > Scanner Settings.

Any valid, full path to a single directory, a comma-delimited list of paths to individualdirectories, a single wildcard directory path, or a comma-delimited list of wildcarddirectory paths is acceptable.



/etc/init.d/httpd


/etc/init.d/*



init.d/httpd

/etc/rc.d/rc?.d

should have ACL(s) A three-character string representing the desired security value. Any three-characteroctal value can be used. Use an asterisk (*) for a wildcard in any position. You canuse the NOT: operator to exclude a set of three-character values. Spaces are ignored.


777

400

**7

6**

NOT: 777, 577, 377


0777


56

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Directory User Ownership

Rule Check: Directory User Ownership

The Directory User Ownership check determines whether one or more directories are owned by a specific useraccount or by one of a list of user accounts.


Folder(s) The name of the directory to look for. If the directory is not present, the test will eitherFail or be Indeterminate, depending on the state of the Mark finding as Failed ifthe check was indeterminate checkbox, accessible at [Site Administrator menu]> Site Administration > Scanner Settings.




/etc/init.d/

/etc/httpd/, /etc/init.d/

/etc/rc.d/rc0.d/, /etc/rc.d/rc1.d/

/etc/rc.d/rc*.d/


init.d/httpd/

/etc/rc?.d/

should be owned by user(s) The comma-delimited list of account names (not account UIDs) that should include theowner of this directory. Any single account name or comma-separated list of names isacceptable.

Use the NOT: operator to exclude a set of names. Spaces are ignored.


root

root, admin

root, admin, jsmith



root, 0

0, 101, 201

IN: 0, 101, 201


58

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Directory Group Ownership

Rule Check: Directory Group Ownership

The Directory Group Ownership check determines whether one or more directories are owned by a specific usergroup or one of a list of user groups.


Folder(s) The name of the directory to look for. If the directory is not present, the test will eitherFail or be Indeterminate, depending on the state of the Mark finding as Failed ifthe check was indeterminate checkbox, accessible at [Site Administrator menu]> Site Administration > Scanner Settings.




/etc/init.d/

/etc/httpd/, /etc/init.d/

/etc/rc.d/rc0.d/, /etc/rc.d/rc1.d/

/etc/rc.d/rc*.d/


init.d/httpd/

/etc/rc?.d/

should be owned by group(s) The group names (not group GIDs) of the group or groups that should include thegroup owner of this directory. Any single name or comma-separated list of names isacceptable. Use the NOT: operator to exclude a set of group names. Spaces areignored.


root

root, admin

root, admin, jsmith



root, 0

0, 101, 201


60

Monitoring Server Configuration Security > Configuration Policy Rule Checks > World-Writable Directories Have Sticky Bit Set

Rule Check: World-Writable Directories Have Sticky Bit Set

The World-Writable Directories Have Sticky Bit Set check verifies that the "sticky bit" of any world-writable directoryon the server is set. If every world-writable directory has its sticky bit set, or if there are no world-writable directories,the check passes.

The sticky bit, when set, prevents all users except the directory's owner and the superuser from renaming or deletingfiles within the directory. The bit is commonly set on temporary directories to prevent one user from overwriting ordeleting another user's data.

You can exclude from this check any directories whose sticky bit you want to ignore.

If the check fails for a given directory, that directory's path, user owner, group owner, and permissions ("mode") aredisplayed in the scan results.


Exclude directories Full paths to any directories to exclude from this check.


Note: The asterisk (*) and question mark (?) characters are the only acceptablewildcard characters.


/etc/init.d

/etc/init.d, /etc/rc.d

/etc/*

/etc/rc.d/*, /etc/rc.d//*

/etc/r?.d


62

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Process Presence

Rule Check: Process Presence

The Process Presence check verifies whether one or more processes are running on the server.


Process(es) The name of the process to search for. Can be any valid process name or a comma-delimited list of names. Wildcards are not allowed, although you can use the asteriskcharacter (*) if it is part of a process name.


httpd

httpd, mysql

Should be running This check fails if any of the listed processes is not running.

Should not be running This check fails if any of the listed processes is running.

Allowed to be running This check fails if any running processes is not listed. If you choose this option, thecheck functions as a whitelist: the check passes if all running processes are listed, andit fails if any process not on the list is running.


64

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Process User Ownership

Rule Check: Process User Ownership

The Process User Ownership check determines whether one or more processes are owned by a specific useraccount or by any user in a list of accounts.


Process(es) The process to examine. Can be any valid process name or any of a comma-delimitedlist of processes. Wildcards are not allowed, although you can use the asteriskcharacter (*) if it is part of a process name.


httpd

httpd, mysql

...should be owned by user (s) A comma-delimited list of one or more account names to compare with the owner ofthe process being examined. Must be account names, not account UIDs. Spaces areignored.

Use the NOT: operator if you want to exclude certain users from owning theseprocesses.


root

root, admin

root, admin, jsmith



root, 0

0, 101, 201


65

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Process Group Ownership

Rule Check: Process Group Ownership

The Process Group Ownership check determines whether one or more processes are owned by a specified group orby one of a set of groups.


Process(es) The name of the process to check the ownership of. Can be single process or acomma-delimited list of processes. Wildcards are not allowed, but you can use theasterisk (*) if it is part of the process name.


httpd

httpd, mysql

...should be owned by user(s) An account name or a comma-delimited list of names that should (or should not) ownthis file. Must be account usernames, not UIDs. Spaces are ignored.

Use the NOT: operator to exclude a set of names.


root

root, admin

root, admin, jsmith



root, 0

0, 101, 201


67

Monitoring Server Configuration Security > Configuration Policy Rule Checks > User Account Presence

Rule Check: User Account Presence

The User Account Presence check compares the specified username or names with the current set of local useraccounts on the server being scanned. Depending on which option you choose, the check fails and an event isgenerated if a listed account does not exist, or does exist, or if an existing account is not listed.


User name(s) The username of the account to look for. Any valid username or a comma-delimited listof names is acceptable. Wildcards are not supported.


adm

adm,root,ops-admin


ec2

?smith

admin*

Should be present If you choose this, all of the listed accounts should exist on the server. If any of thelisted accounts does not exist, the check fails.

Should not be present If you choose this, none of the listed accounts should exist on the server. If any of thelisted accounts does exist, the check fails. (The check functions as a blacklist.)

Allowed to be present If you choose this, any of the listed accounts is acceptable to be present. If any existingaccount is not in the list, the check fails. (The check functions as a whitelist.)


69

Monitoring Server Configuration Security > Configuration Policy Rule Checks > User Has Password

Rule Check: User Has Password

The User Has Password check determines if the specified user or list of users have passwords in /etc/passwd. The/etc/shadow file is also checked if it is being used.


User(s) The account name or names to check. This can be a single account name or acomma-delimited list of account names. The account name must be used, not theaccount UID. Extra spaces are ignored. The ALL keyword can be used to specify thatall accounts on the system should be checked.


root

root, admin

root, admin, jsmith

ALL


root, 0

0, 101, 201


71

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Password is Not Expired

Rule Check: Password is Not Expired

The Password is Not Expired check verifies on a Linux system that the specified local accounts all have valid (notexpired) passwords. If any of the accounts has an expired password, the check fails.


User(s) The account name or names to test for unexpired passwords. Can be a single accountname or a comma-delimited list of account names. Must be the account's username,not its UID. Extra spaces are ignored.

Use the ALL keyword (all uppercase) to specify that all accounts on the systemshould be checked.


root

root, admin

root, admin, jsmith

ALL


root, 0

0, 101, 201



72

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Password Does Not Match Username

Rule Check: Password Does Not Match Username

The Password Does Not Match Username check inspects the file /etc/passwd to verify that the passwords of thespecified user or users do not match their usernames. If /etc/shadow is being used, the check also inspects thatfile.


User(s) The account name or names to test for password violation. Can be a single accountname or a comma-delimited list of account names. Must be the account's username,not its UID. Extra spaces are ignored.

Use the ALL keyword (all uppercase) to specify that all accounts on the system shouldbe checked.


root

root, admin

root, admin, jsmith

ALL


root, 0

0, 101, 201


73

Monitoring Server Configuration Security > Configuration Policy Rule Checks > User Account UID

Rule Check: User Account UID

The User Account UID check determines if a single user account has an UID of a specified value or in a specifiedrange.


User The single account name to check. Only a single account name can be used. It cannotbe a comma-delimited list of account names, or the UID, or the keyword ALL.


root

admin

jsmith


root, jsmith

ALL

...should have uid The list of acceptable UID values for the account name. This is a single UID value, acomma-delimited list of values, or a range of values using a greater-than or less-thansign. Extra spaces are ignored.


0

101,102

>1000

<500


>500, <1000

-100


74

Monitoring Server Configuration Security > Configuration Policy Rule Checks > User Group Membership

Rule Check: User Group Membership

The User Group Membership check determines whether the specified account is a member of exactly the listedgroups, and no others. If the account is not a member of one of the listed groups, or if it is a member of a group notlisted here, the check fails.

You can use this check to make sure that a given user is not a member of any group that may have higher accesspermissions than the user should be allowed.


User The single account name to check. Only a single account name can be used. It cannotbe a comma-delimited list of account names, or the UID, or the keyword ALL.


root

admin

jsmith


root, jsmith

ALL

...should be in groups The list of group names the account name should be a member of. This is a singlegroup name or a comma-delimited list of group names. The group name must be used,not the group GID. Extra spaces are ignored


root

wheel, admin

finance, company


500


76

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Recent Account Login

Rule Check: Recent Account Login

The Recent Account Login check verifies, for one or more account names, whether any of those users users havelogged in recently. If any have not (and the check fails), their accounts can be considered inactive.


User(s) The list of names to check. Can be a single account name, a comma-delimited list ofaccount names, or the keyword ALL (must be capitalized - all is treated as ausername). You must supply a username, not a UID. Extra spaces are ignored.


root

root, admin

ALL


root, 0

...should have logged in during thepast days

The number of days an account is allowed to go without an interactive login before thepolicy is violated. Must be a single positive integer value.

"login" here means only direct shell logins; it does not apply to su-ing to an accountfrom an existing shell session.


100


-50

<100


78

Monitoring Server Configuration Security > Configuration Policy Rule Checks > No Recent Account Login

Rule Check: No Recent Account Login

The No Recent Account Login check verifies whether a single account name, a list of names, or all names have notlogged in recently. This would typically be used to watchlist certain users (for example, terminated users or usersnearing termination), accounts that should be temporarily inactive, or accounts that should never have interactivelogins (like the root or Oracle accounts). If any logins have occurred (the check fails), it could be a security concern.


User(s) The list of names to check. This is a single account name, or a comma-delimited list ofaccount names, or the keyword ALL (must be capitalized - "all" is treated as ausername). The UID cannot be used. Extra spaces are ignored.


root

root, admin

ALL


root, 0

..should have NOT logged in forthe past days

The number of days an account is allowed to go without an interactive login before thepolicy is violated. This is a single positive integer value of the number of days. Thisonly tracks to interactive shell logins and does not apply to su'ing to an account from anexisting shell session.


100


-50

<100


80

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Home Directory Exists

Rule Check: Home Directory Exists

The Home Directory Exists check verifies whether the specified user or users each has a home directory. The checkpasses for a user if (1) the user has a home directory specified in /etc/passwd, and (2) the directory exists. Thecheck is indeterminate for any specified user whose account does not exist.


User(s) The list of names to check. This is a single account name, or a comma-delimited list ofaccount names (maximum length = 255 characters), or the keyword ALL (must becapitalized - "all" is treated as a username). The UID cannot be used. Wildcards arenot supported. Extra spaces are ignored. All usernames are case-sensitive.

Use the NOT operator to specify that all users except the specified ones should bechecked.


root

susang, susanh

root, admin, sysadmin204

ALL

NOT: root, admin


root, 0


82

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Home Directory Owned by Correct User

Rule Check: Home Directory Owned by Correct User

The Home Directory Owned by Correct User check verifies that the home directory of each of the specified users isactually owned by that user. The check fails for any specified user whose home directory is not owned the user.

The check is indeterminate for any user whose account does not exist, or who has no defined home directory, orwhose defined home directory does not actually exist.





root

susang, susanh


ALL

NOT: root, admin


root, 0


83

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Home Directory Owned by Correct Group

Rule Check: Home Directory Owned by Correct Group

The Home Directory Owned by Correct Group check verifies that the group owner of each specified user's homedirectory is that user's primary group. The check fails for any specified user whose home directory is not owned bythe user's primary group.






root

susang, susanh


ALL

NOT: root, admin


root, 0


84

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Home Directory Files Owned by Correct User

Rule Check: Home Directory Files Owned by Correct User

The Home Directory Files Owned by Correct User check the home directory of the specified user or users to verifythat all files in each user's home directory are owned by that user. The check fails for any specified user whose homedirectory contains any files not owned by the user.


Note: The search is recursive, including all subdirectories of the home directory. All files, including device filesand fifos, are checked. Symlinks are examined for ownership but their targets are not examined.Information is returned only on files that fail the check, and only on the first 1000 failures in each homedirectory.





root

susang, susanh


ALL

NOT: root, admin


root, 0


85

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Home Directory Files Owned by Correct Group

Rule Check: Home Directory Files Owned by Correct Group

The Home Directory Files Owned by Correct Group check searches the home directory of the specified user or usersto verify that the group owner of all files in each user's directory is that user's primary group. The check fails for anyspecified user whose home directory contains any files that are not owned by the user's primary group.







root

susang, susanh


ALL

NOT: root, admin


root, 0


87

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Home Directory Files Have No Unsafe PATH Statements

Rule Check: Home Directory Files Have No Unsafe PATH Statements

To help deter spoofing attacks, it is important to be sure that the current directory is never specified in PATHstatements. The Home Directory Files Have No Unsafe PATH Statements check verifies that the specified startupscripts in the home directory of the specified user (or users) include only safe PATH statements—meaning that nonesets the current directory in the path by including . or :: or : or a NULL field at the beginning or end of the path.

The check examines all matching files in each specified user's home directory. The check fails for an individual user ifany matching files contain unsafe PATH statements, and it passes for that user if not. The check is indeterminate forany user whose account does not exist, or who has no defined home directory, or whose defined home directorydoes not actually exist.

Note: Files larger than 10KB are ignored, even if they match the file specifications in this check.


User(s) The list of names to check. Can be a single account name, a comma-delimited list ofaccount names (maximum length = 255 characters), or the keyword ALL (must becapitalized - "all" is treated as a username). The UID cannot be used. Wildcards are notsupported. Extra spaces are ignored. All usernames are case-sensitive.



root

susang, susanh


ALL

NOT: root, admin


root, 0

File(s) The list of files to check. Can be any valid path to a single file, a comma-delimited list ofpaths to individual files, a single wildcard file path, or a comma-delimited list of wildcardfile paths. All paths are relative to the specified user's home directory and cannot startwith a slash.

Note: The asterisk (*) and the question mark(?) are the acceptable wildcardcharacters. The asterisk matches any number of filename characters, and the questionmark matches any single character.


.profile

.profile, myscripts/.bash_profile

myscripts/bash_startup*

myscripts/bash_startup?


/home/susanh/myscripts/.bash_profile

myscripts/


89

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Home Directory Files Have No Invalid umask Commands

Rule Check: Home Directory Files Have No Invalid umask Commands

The Home Directory Files Have No Invalid umask Commands check verifies that the specified startup scripts in thehome directory of the specified user (or users) include only appropriate umask commands.

If you are adding this check to a configuration policy rule, you specify what umask values are to be consideredinvalid. In general, umasks with low values are less safe because the result of their application is that overlypermissive files are created. Also, because a global umask exists, in most cases it is not appropriate for individualusers to override it.

The check examines all matching files in each specified user's home directory. The check fails for an individual user ifany matching files contain invalid umask commands, and it passes for that user if not. The check is indeterminate forany user whose account does not exist, or who has no defined home directory, or whose defined home directorydoes not actually exist.

If the check fails for a given set of umask values, the username, home directory path, filename, and actual umaskvalue are displayed in the scan results.

Note: Files larger than 10KB are ignored, even if they match the file specifications in this check.


User(s) The list of names to check. Can be a single account name, a comma-delimited list ofaccount names (maximum length = 255 characters), or the keyword ALL (must becapitalized - "all" is treated as a username). The UID cannot be used. Wildcards are notsupported. Extra spaces are ignored. All usernames are case-sensitive.



root

susang, susanh


ALL

NOT: root, admin


root, 0

File(s) The list of files to check. Can be any valid path to a single file, a comma-delimited list ofpaths to individual files, a single wildcard file path, or a comma-delimited list of wildcardfile paths. All paths are relative to the specified user's home directory and cannot startwith a slash.



.profile

.profile, myscripts/.bash_profile



Some examples that will not work:91

/home/susanh/myscripts/.bash_profile

myscripts/

Should have umask Specify the desired umask value in octal notation. Wildcards and the NOT operator aresupported.

The values entered in this field are the values that are acceptable for umask commandsin matching files. If NOT is used, none of the listed values is acceptable.


111

111,027

01?, 0*

NOT: 025, 022, 020, 01*, 00*


rwxr--r--

0123


92

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Home Directory Has No setuid Files

Rule Check: Home Directory Has No setuid Files

The Home Directory Has No setuid Files check searches the home directory of the specified user or users to verifythat the setuid bit in all the files in the directory is cleared. The check fails for any specified user whose homedirectory contains one or more files whose setuid bit is set.

(A file whose setuid bit is set may allow users to execute it with temporarily elevated privileges, and therefore couldbe a favored target of an attacker.)







root

susang, susanh


ALL

NOT: root, admin


root, 0


93

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Home Directory Has No setgid Files

Rule Check: Home Directory Has No setgid Files

The Home Directory Has No setgid Files check searches the home directory of the specified user or users to verifythat the setgid bit in all the files in the directory is cleared. The check fails for any specified user whose homedirectory contains one or more files whose setgid bit is set. .

(A file whose setgid bit is set may allow users to execute it with temporarily elevated privileges, and therefore couldbe a favored target of an attacker.)







root

susang, susanh


ALL

NOT: root, admin


root, 0


95

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Home Directory Has No Device Files

Rule Check: Home Directory Has No Device Files

The Home Directory Has No Device Files check searches the home directory of the specified user or users to verifythat none of the files in the directory is a block or character device. The check fails for any specified user whosehome directory contains one or more block or character device files.

(The presence in a user's home directory of a device file—which would normally be in the /dev directory—could be astrong indicator of an intrusion.)







root

susang, susanh


ALL

NOT: root, admin


root, 0


97

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Home Directory File Presence

Rule Check: Home Directory File Presence

The Home Directory File Presence check verifies that the specified file or files exist in the home directory of thespecified user (or users). Depending on a setting that you make, the check passes for a user either if (1) all thespecified files are present, or (2) none of them is present.

The check is indeterminate for any specified user whose account does not exist, or who has no defined homedirectory, or whose defined home directory does not actually exist.





root

susang, susanh


ALL

NOT: root, admin


root, 0

File(s) The list of files to check. Can be any valid path to a single file, a comma-delimited listof paths to individual files, a single wildcard file path, or a comma-delimited list ofwildcard file paths. All paths are relative to the specified user's home directory andcannot start with a slash.



.rhosts

.rhosts, myscripts/.bash_profile




/home/susanh/.rhosts

myscripts/

Should be present This check passes of any of the listed files are present; it fails if none is present.

Should not be present This check passes if none of the listed files is present; it fails if any are present.


99

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Group GID

Rule Check: Group GID

The Group GID check verifies whether a group of a given name name has a GID of a specified value or within aspecified range.


Group The name of the group to check. You cannot specify more than one group.


root

admin

webmasters


root, webmasters

ALL

...should have gid The set of acceptable GID values for the group. Can be a single GID value, a comma-delimited list of values, or a one-ended range of values using a greater-than (>) orless-than (<) sign. Extra spaces are ignored.


0

101,102

>1000

<500


>500, <1000

-100


101

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Group Members

Rule Check: Group Members

The Group Members check determines whether a group's membership consists of exactly the specified set of useraccounts, and no more. If the group does not include one of the listed accounts, or if it includes an account not on thelist, the check fails.

You can use this check to verify that a highly privileged group does not contain any users that should not belong.


Group The name (not the GID) of the group to check. You cannot list more than one group.


root

admin

webmasters


root, webmasters

ALL

should only have the followingusers

A list of user account names to test for membership in the group. Can be a singlename or a comma-delimited list of names. Extra spaces are ignored.


root

root, admin


root, 0

NOT: webmasters, sysadmins

ALL


103

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Grooup Has Password

Rule Check: Group Has Password

The Group Has Password check inspects the file /etc/group to verify that the specified group or groups havepasswords. It also checks /etc/gshadow if it is being used.


Group(s) The name of the group or groups to check. Can be a single group name, a comma-delimited list of names, or the keyword ALL (to specify that all accounts on the systemshould be checked). You cannot use group GIDs. Extra spaces are ignored.

The ALL keyword must be capitalized - "all" is treated as a username.


root

root, admin

root, admin, webmasters

ALL


root, 0

0, 101, 201


105

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Network Service Accessibility

Rule Check: Network Service Accessibility

The Network Service Accessibility check tests whether only the specified ports are open on the server's interfaces.The Halo agent performs the check by interrogating the network services from within the server, and the Haloanalytics engine verifies that the open ports are accessible from the Internet.

If the Halo agent finds unexpectedly open ports, it reports (in the failed check) which software processes are bound tothem. This information can help you to investigate potential undesirable network services and malware.

Note: If you want to generate a list of the currently open ports on a server, you can effectively accomplish that byspecifying "0" in the expected open ports field. If any ports are open, the check will fail and the results willlist all of the open ports.


Interface(s) The name of the interface device that the service(s) are expected to run on. Can be asingle interface name or a comma-delimited list. Must be the interface device name(such as eth0 or eth1). Because cloud server IP addresses can be dynamic, youcannot specify an IP address. Subinterfaces should use the same device namingscheme as the operating system (e.g. eth0:0, eth1:3).

Open Port(s) The port or ports expected to be open on the specified interface(s) on this server.Should be the port number followed by UDP or TCP (for example, 22/TCP). Use acomma-delimited list to specify multiple ports (for example, 22/TCP, 80/TCP). If theport is expected to listen to both TCP and UDP, use just the port number alone for thatport (for example, 22/TCP, 80/TCP, 53).

To enter a range of port numbers, use a colon (for example, 60000:61000/TCP). Therange includes the beginning port number, the ending port number, and all portnumbers between them.

The NOT: operator is supported in this field. If you use it, it applies to the entire set oflisted ports and the check fails if any of them is open. All of the unspecified ports wouldbe permitted to be open.

NOT: 1025:65535

The list of ports can be up to 2048 bytes long.


106

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Network Service Processes

Rule Check: Network Service Processes

The Network Service Processes check tests whether the open network ports are bound to their intended softwareprocesses. In the example below, port 22 should have only the sshd secure shell process bound to it. This check canhelp you detect malware bound to any of the server's open ports.


Port(s) This one parameter identifies the interface device name to be checked, the port on thatdevice to be checked, and the IP protocol used (TCP or UDP). If you specify noprotocol, the service process for both protocols will be checked.


eth0:53

eth0:22/TCP

eth0:53

eth0:22/TCP

eth0:1:53/UDP

Bound Process(es) A single process name or comma-delimited list of processes that you are allowing to bebound to this interface/port/protocol specification. The presence of any process not onthe list is considered a failure of the check.


httpd

nginx

httpd, nginx

mysql


108


109

Monitoring Server Configuration Security > Configuration Policy Rule Checks > Port is Listening

Rule Check: Port is Listening

The Port is Listening check tests whether, on each of the specified interfaces, any ot the specified ports is listeningthrough its specified protocol. Alternatively, the check tcan test for the negative of that state, testing to make sure thata specified port/protocol is not listening on any of the specified interfaces.

Success or failure of this check is reported separately for each combination of interface and port/protocol. The resultis indeterminate for each combination of interface and port/protocol in which the interface cannot be found.


Interface(s) The name of the interface device that the port(s) are expected to be listening on. Canbe a single interface name or a comma-delimited list. Must be the interface devicename (such as eth0 or eth1); because cloud server IP addresses can be dynamic,you cannot specify an IP address. Subinterfaces should use the same device namingscheme as the operating system (e.g. eth0:0, eth1:3).


eth0

eth0:1

eth0:15

eth1

Gigabit1 (a custom interface)

Port(s) The port on each of the specified interface device to be checked, plus the IP protocolused (TCP or UDP). If you specify no protocol, both protocols will be checked for theport. Can be a single port/protocol specification or a comma-delimited list.


53

22/TCP

53/UDP

Should be listening This check fails whenever the specified port is not listening through its specifiedprotocol on the specified interface.

Should not be listening This check fails whenever the specified port is listening through its specified protocolon the specified interface.



110

monitoring configuration security with cloudpassage halo

Documents