Configuration Security Monitoring

Configuration Security Monitoring Setup Guide Contents: About Configuration Security Monitoring Setting Up and Running a Configuration Scan Creating or Customizing a Configuration Policy What a Configuration Policy Is Create a New Policy Add or Edit Policy Rules and Checks Use the Rule Library Managing Configuration Policies Addressing CSM Findings View CSM Scan Findings Act on Configuration Issues, Findings, and Events Best Practices for Configuration Scanning Appendix: 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 operating systems and applications are properly hardened against attack. Maintaining attack-resistant software configurations makes 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 your configuration settings, system files, running processes, ownership and permissions to ensure that no unauthorized changes are made that could compromise server security. Once you set up Configuration Security Monitoring (CSM), Halo regularly scans all of your protected servers, looks for settings that have changed and therefore are violating policy. Halo reports its findings back to the Halo portal or directly to you through email alerts. In scanning each server, Halo applies a set of rules that specify what the secure configuration for that server should be. Each set of rules is called a configuration policy. When you create a new policy, you can choose to base the new policy on an existing policy, on one of Halo's default policies containing an initial framework of default rules, or begin with an empty policy template. In all cases, you assign the new policy a unique name, customize the policy's security rules, 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 application configurations can share the same configuration policy. 2. Create or find a configuration policy that can detect departures from your defined secure configuration in those 1

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 also have email notifications alerting you to critical configuration-security issues. Use that information to remediate detected 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 made of rules, and rules are made of checks. You can learn the details of how all configuration checks work by consulting Appendix: 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 Security Monitoring, 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 and architectural 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 Configuration Scan. 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

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 Environment page. 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 Details Sidebar. 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 page opens. 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 a completely template that contains no rules, the steps you perform to create a new CSM policy are essentially the same. The following section describes how configuration policies are structured and how to customize them to meet your security 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 in order to be hardened against attacks. The policy can apply to both the operating system and to applications running on 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 operating system or application. The rule does this by applying one or more rule checks, which consist of pattern-matching templates or file paths that characterize what the setting should be. If a rule check finds a setting that is different from that, the check fails and the rule fails, and Halo creates a security event that is logged and displayed in the Halo portal. In Halo, each configuration policy applies to a group of similar servers. Therefore all servers in the group need to have identical configurations, as far as a configuration policy is concerned. In general, that means that they must all be running the same OS and applications. Using groups greatly reduces the number of policies that you need to create. Furthermore, CloudPassage provides pre-built policies for each of the major Linux distributions and the applications commonly running on them. These policies allow for quick setup, but may require some customizing to suit your specific environment. You create a rule by adding and configuring one or more of the rule checks that Halo provides for you. Checks are the 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 system when the rule fails. If any check fails, the rule fails. Rules that fail can produce either critical issues or non-critical issues, according to how 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 general categories: 3

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 Results Several rule checks examine the characteristics of a particular file, such as its permissions or owners. If the file is not present, its characteristics cannot be determined and the results of the check are considered indeterminate. When you set up automatic configuration scanning (in the Halo Operations Guide, see Working With Scans), you can specify whether you want all indeterminate results to be considered failures of the checks (and thus potentially generate 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 or Add 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 New Configuration Policy page. For an existing policy, go to the Edit Configuration Policy page by navigating to Policies > Configuration Policies. Click the name of the policy you want to add rules to (or select Edit from the Actions drop-down menu for that policy). The Edit Configuration Policy page appears. 4

2. Click the small triangle beside a rule category to view its contents (or click Expand All to show the contents of all of the categories). If you are editing an existing policy, there will already be rules in at least some of the categories. 3. To add a new rule, click Add Rule under any of the categories. (The categories are just suggestions; you can add 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 as such 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 to temporarily deactivate this rule. API Exportable. If this check box is selected, failures of this rule will be included in the results returned from the List Server Issues method of the CloudPassage API. You might clear the check box if you are trying to minimize 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 Security Events 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 of this 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 Configuration Policies page. Rule Checks. The setting of these radio buttons applies to all checks in this rule. Use this setting to change the 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 to pass; 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 checks must 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 check that requires the file to not be present. If the two checks are OR'ed, it means that the file need not exist, but if it does 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 check that 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 desired Edit 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 for detailed 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 (for example, if a configuration file's setting does not equal the setting specified in the check); in that case a security event is generated and an alert may be sent. If the conditions of the check do occur (the 6

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 of the rule's check operator, and the state of the "Mark indeterminate as failed" check box in the Scanner Settings tab of the Site Administration page in the Halo portal, many factors can contribute to the ultimate results of an individual rule'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 or event is created. The result Fails means that the configuration is considered unsafe and a security issue or event is created. The result Indeterminate means that there is insufficient information to make a decision, and no issue or event is created. Indeterminate = failure? Check operator for rule Check 1 Check N Rule result Comment 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. AND (default) Passes Fails Fails If any check fails, the rule fails. Passes Indeterminate IndeterminateIf any check is indeterminate and no checks 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. NO (default) Indeterminate Indeterminate IndeterminateIf all checks are indeterminate, the rule is indeterminate. 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. OR Passes Fails Passes If any check passes, the rule passes. Passes Indeterminate Passes If any check passes, the rule passes. Fails Fails Fails If all checks fail, the rule fails. Fails Indeterminate IndeterminateIf any check is indeterminate and no checks pass, the rule is indeterminate. Indeterminate Indeterminate IndeterminateIf all checks are indeterminate, the rule is indeterminate. Passes Passes (only one check in the rule) Fails Fails (only one check in the rule) Indeterminate (fails) Fails (only one check in the rule) Passes Passes Passes If all checks pass, the rule passes. AND (default) Passes Fails Fails If any check fails, the rule fails. Passes Indeterminate Fails If any check fails, the rule fails. 7

(fails) Fails Fails Fails If all checks fail, the rule fails. Fails Indeterminate Fails If all checks fail, the rule fails. (fails) YES Indeterminate Indeterminate Fails If all checks fail, the rule fails. (fails) (fails) Passes Passes (only one check in the rule) Fails Fails (only one check in the rule) Indeterminate (fails) Fails (only one check in the rule) Passes Passes Passes If all checks pass, the rule passes. OR Passes Fails Passes If any check passes, the rule passes. Passes Indeterm. Passes If any check pas es, the rule passes. (fails) Fails Fails Fails If all checks fail, the rule fails. Fails Indeterm. Fails If all checks fail, the rule fails. (fails) Indeterm. Indeterm. Fails If all checks fail, the rule fails. (fails) (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 by providing the Rule Library. Whenever you create a configuration policy rule, you can if the rule might be useful in other policies save the rule to the Rule Library. Then, when you create another policy, you can retrieve the rule from the library, insert it into your 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 to Library 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 from Library 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 to manage 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-down list. Policy Manipulation Actions: Export a Policy To 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 policy with other Halo users, or re-import it at a later time. Import a Policy To 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 Policy 9

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 policies are available for later use if they are unretired. Unretire a Policy To 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 or assigning to server groups. Delete a Policy To 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 the exported file. Policy Creation and Editing Actions: Clone a Policy or Template To 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. In that 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 Policy To 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 rules as desired. Halo will not permit you to save a new policy until you assign the policy a unique name. Edit a Policy To 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 examine the details of one or more CSM scan findings. View CSM Scan Findings 10

As described in Setting Up and Running a Configuration Scan, above, the easiest way to examine CSM findings in detail is to click a Scan's Status column to display a summary of the scan's results. From there, you can view the individual 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 given configuration scan. For information about the header area of the scan findings page, in the Halo Operations Guide see View Scan Findings. The rest of the page lists the scan findings themselves, each identified as failed (critical), failed (non-critical), and indeterminate. 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 above results 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 rule checks 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 the entire 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 Policy 11

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 was tested, what value was expected, what value was found, and (optionally) what remediation steps are recommended. From this info you may be able to infer whether this is a valid security issue that you need to address. If you think that this is not a valid set of rule checks in this situation, you can either (1) click Disable this rule so that this issue will not occur in future configuration scans or (2) disable the individual failed check on the Edit Policy 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 security vulnerabilities in your organization's servers. By extension, the objective of investigating CSM issues, findings, and events 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, or whether it will be more efficient to change the servers' gold master image or server template, then re-instantiate the 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 to the affected servers to correct settings or modify insecure execution states. Whenever your server configuration changes significantly, for example you deploy a different app server application, 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 or more 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 detailed remediation 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 immediately quarantine 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 how you can use the CloudPassage-provided configuration templates to protect your servers' operating systems and applications, how you can create custom policies to protect other applications, and how you can use use Halo's powerful rule checks to address a wide range of security issues. Use a built-in core policy for basic OS protection You 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 the policies 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

(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 services should 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 protection You 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 for PASS_MIN_LEN is 10, which is longer than what the core rule requires. Also, password lifetime in the extended policies 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 more failure 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 applications You 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 systems beneath them. You would use one of these policies in conjunction with the core or advanced configuration policy for its operating system. To use one 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 are likely to require customization and addition of rules to meet your security requirements, especially if 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 specific setting Some rule checks support use of the NOT operator, which allows you to check for a state in which a specified setting does not exist. For example, you could set up a configuration-file setting check to verify the number of days that must elapse between password resets. You could specify a number of days (for example, 3) that matches your passwordmanagement 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 password repeatedly in a single sitting. So any value other than zero (days) would be acceptable. In that case, you could set up a password-reset check with a value of 0 and apply NOT to that value. As long as the number of days between resets is 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 checks You can create a rule that has more than one rule check, then use the rule's AND and OR flags to determine whether all 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 event for 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 are detected. For details, see What Makes a Configuration Rule Pass or Fail? Use a string-presence rule check to verify the existence of any text The 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 stringpresence check can be very handy. Suppose, for example, you want to create a check that verifies that debugging is turned off. If the configuration-file line that you need to verify looks like the following, you can easily use a configuration-file setting check to detect the value 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 a string-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 exactly identical and it's not as complete. The documentation for the string-presence check (see Rule Check: String Presence) describes the details of the syntax. Identify crashed processes on your servers You can use the process-presence check in a configuration policy rule to alert you when a critical process on your server crashes. 14

For example, assume that you have decided that a crash of any of the processes rsyslogd, sshd, or apached on any 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 be running. 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 cause an alert to be sent. Locate dangerous binaries on your servers A default Linux distribution typically includes a number of system tools that, while useful for particular purposes, are not needed on every server and may be dangerous if executed by an intruder who has broken into the system. You can create a configuration policy to identify the presence of those programs so you can remove them as a safety precaution. Examples of these programs include telnet, tcpdump, and ping. Tools like these are useful to both administrators and hackers, so you'll need to decide for each server group which tools must remain on the servers and which can be removed. 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 specify that 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 a security 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 as configuration settings, files and directories, processes, users and groups, and network services. For instructions on creating or editing an individual check, click its name beneath either of the tabs below. By Category Alphabetic WINDOWS File presence Service Started Process Presence Registry Key Value Setting Local Security Policy setting Local User Rights Assignment Advanced Audit Policy Setting Directory Presence Geolocation by country LINUX Configuration settings Geolocation by country Configuration-file setting File, string, and and package attributes File presence File ACL File user ownership File group ownership File setuid File setgid String presence Package presence Directory attributes Directory presence Mount point Directory ACL Directory user ownership Directory group ownership World-writable directories have sticky bit set Process presence and ownership Process presence Process user ownership Process group ownership User identity and activity User presence User has password Password is not expired Password does not match username User account UID User group membership Recent account login No recent account login User home directory settings Home directory exists Home directory owned by correct user Home directory owned by correct group Home directory files owned by correct user Home directory files owned by correct group Home directory files have no invalid umask Commands Home directory files have no unsafe PATH statements Home directory has no setuid files Home directory has no setgid files Home directory has no device files Home directory file presence Group characteristics Group GID Group members Group has password Network services Network service accessibility Network 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 as configuration settings, files and directories, processes, users and groups, and network services. For instructions on creating or editing an individual check, click its name beneath either of the tabs below. By Category Alphabetic Advanced Audit Policy Setting (Windows) Configuration file setting Directory ACL Directory group ownership Directory presence Directory presence (Windows) Directory user ownership File ACL File group ownership File presence File presence (Windows) File setgid File setuid File user ownership Geolocation by country (Linux and Windows) Group GID Group has password Group members Home directory exists Home directory file presence Home directory files have no invalid umask Commands Home directory files have no unsafe PATH statements Home directory files owned by correct group Home directory files owned by correct user Home directory has no device files Home directory has no setgid files Home directory has no setuid files Home directory owned by correct group Home directory owned by correct user Local Security Policy setting (Windows) Local User Rights Assignment (Windows) Mount point Network service accessibility Network service processes No recent account login Package presence Password does not match username Password is not expired Process group ownership Process presence Process Presence (Windows) Process user ownership Recent account login Registry Key Value Setting (Windows) Service Started (Windows) String presence User account UID User group membership User has password User presence World-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 Windows server. To check for the presence of a directory, use the Directory Presence (Windows) check instead. Parameters File(s) Description The full path to the file to look for. Any valid, full path to a single file, or a commadelimited list of file paths is acceptable. A path may include a Windows system environment variable, using the format %envvariable%partialpath. Note: The asterisk (*) is the only acceptable wildcard character. You cannot use a question mark. Important: Every target filename (other than a symbolic link) must include the file extension. 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 C:\Program Files\Internet Explorer Program Files\Internet Explorer\iexplore.exe C:\Program Files\Internet Explorer\iexplore C:\Windows\system32\?.exe Should be present Should not be present Remediation Suggestion (optional) This check fails if any of the listed files is not present. This check fails if any of the listed files is present. Optional suggestion 18

19

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 the server. Depending on a setting, the check either passes or fails for each specified service that is running, or else it serves as a whitelist of permitted services. Parameters Service(s) Description The name of the Windows service to search for. Can be any valid service name or a comma-delimited list of names. Wildcards are not allowed, although you can use the asterisk 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 Should not be started/running OK to be started/running Remediation Suggestion (optional) This check fails for any of the listed processes that is not running. This check fails for any of the listed processes that is running. This check fails if any running process is not one of the list listed processes. In this case the check functions as a whitelist. Optional suggestion 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. This check applies to all running processes, including Windows services. Parameters Process(es) Description The name of the process to search for. Can be any valid process name or a commadelimited list of names. Wildcards are not allowed, although you can use the asterisk character (*) if it is part of a process name. Some valid examples are: cmd.exe cphalow.exe,dllhost.exe Should be running Should not be running Allowed to be running Remediation Suggestion (optional) This check fails if any of the listed processes is not running. This check fails if any of the listed processes is running. This check fails if any running processes is not listed. If you choose this option, the check functions as a whitelist: the check passes if all running processes are listed, and it fails if any process not on the list is running. Optional suggestion 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 specified value. The check examines both the name and data portions of all actual values of the specified registry key to verify that a value of the specified name exists and that its data portion is equal to the specified expected setting. The check fails if 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. Parameters Registry Key Registry Value Description The full path to the registry key to examine. The key path is case-insensitive. Neither wildcards nor recursion is supported. However, a path may include a Windows environment variable, using the format %envvariable%partialpath. The name of the value to examine. Names are case-insensitive. Neither wildcards nor recursion is supported. You can specify only one value name per check. Use multiple checks if you want to examine 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 separated by \0 null terminators (for example, test1\0test2\0test3). If the value is a DWORD or QWORD, enter the decimal value as a string (for example, 255). If the value is BINARY, enter the hexadecimal value as an unprefixed string (for example, 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 comma with a backslash ("\,") so that it will not be considered a separator. For example, if the expected 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 is present, 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 Remediation Suggestion (optional) Optional suggestion 22

23

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 a given value on a scanned Windows server. Local security policy is a set of locally stored information defining the security of a Windows system. The information includes 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. Parameters Setting Desired value Description The name of the Local Security Policy setting to check. Select it from the drop-down list. Note: The Windows secedit tool and the List server issues call in the Cloudpassage API use abbreviated setting names, as listed below under Valid Values for Local Security Policy Settings. Enter the value that this setting should have. Optionally apply the NOT, > (greater than), or < (less than) operator to change the meaning of certain settings. Restrictions on valid values and operators for the currently selected setting are displayed on the Local Security Policy Setting dialog box; information for for all settings is summarized under Valid Values for Local Security Policy Settings. Some valid examples are: 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") Remediation Suggestion (optional) Optional suggestion 24

Valid Values for Local Security Policy Settings Note: For numeric values, units are shown in brackets [ ]. For all settings, operators are optional. Setting secedit Name Possible values Possible Operators Account lockout duration LockoutDuration 0 99999 [hours] NOT, <, > Account lockout threshold LockoutBadCount 0 999 [attempts] NOT, <, > Accounts: Administrator account status EnableAdminAccount 0 = Disabled 1 = 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 neither 1 = Log success 2 = Log failure 3 = Log both Audit account management AuditAccountManage 0 = Log neither 1 = Log success 2 = Log failure 3 = Log both Audit directory service access AuditDSAccess 0 = Log neither 1 = Log success 2 = Log failure 3 = Log both Audit logon events AuditLogonEvents 0 = Log neither 1 = Log success 2 = Log failure 3 = Log both Audit object access AuditObjectAccess 0 = Log neither 1 = Log success 2 = Log failure 3 = Log both Audit policy change AuditPolicyChange 0 = Log neither 1 = Log success 2 = Log failure 3 = Log both Audit privilege use AuditPrivilegeUse 0 = Log neither 1 = Log success 2 = Log failure 3 = Log both Audit process tracking AuditProcessTracking 0 = Log neither 1 = Log success 2 = Log failure 3 = Log both Audit system events AuditSystemEvents 0 = Log neither 1 = Log success 2 = Log failure 3 = Log both NOT NOT NOT NOT NOT NOT NOT NOT 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/Name LSAAnonymousNameLookup 0 = Disabled NOT translation 1 = Enabled Network security: Force Logoff when hours expire ForceLogoffWhenHourExpire 0 = Disabled 1 = Enabled Password must meet complexity requirements PasswordComplexity 0 = Disabled 1 = Enabled NOT NOT 26

Reset account lockout counter after ResetLockoutCount 0-99999 [hours] NOT, <, > Store passwords using reversible encryption ClearTextPassword 0 = Disabled 1 = 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 groups encompasses 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 each security 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 the users or groups does not have that right, or if others who do have the right are missing from the list. You can use the check to verify that only appropriate users and groups have a given right on the server. Parameters Policy Security Settings Description The name of an individual user right that can be assigned. Select one from the dropdown list. The name(s) of one or more users or groups that should have the selected security right. Separate individual group or user names with commas. The order of the names in the list does not matter. Note: This field accepts input that includes the special characters "@" and "\", so that you can supply domain user account names. Some valid examples are: rkumar23, jsmith Administrators,rkumar23 ccolon@cruzcloud.com cruzcloud\ccolon NOT: rkumar23 Backup Operators jsmith Backup Operators; jsmith Note: The user "NT SERVICE\WdiServiceHost" cannot be specified by name. For this user only, you must provide the SID instead of the username. Remediation Suggestion (optional) Optional suggestion 28

29

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 be logged 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 audit subcategory) has the value that you expect on a scanned Windows server. Using the check in a configuration policy allows 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. Parameters Audit Subcategory Desired value Remediation Suggestion (optional) Description The name of the advanced security audit policy setting to check. Select it from the drop-down list. Select the value or values that are acceptable for this setting. You can select multiple values: 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. Optional suggestion 30

31

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. Parameters Folder(s) Description The full path to the directory to look for. Any valid, full path to a single directory, or a comma-delimited list of paths is acceptable. Wildcards are not supported. However, a path may include a Windows system environment variable, using the format %envvariable%partialpath. Some valid examples: 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 Should not be present Remediation Suggestion (optional) This check fails if any of the specified directories is not present. This check fails if any of the specified directories is present. Optional suggestion 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 the Connecting IP Address field on the Server Summary page of the Halo portal) with the country-code values specified in this check, and then either passes or fails depending on whether the server location matches or does not match 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 that the server is not located in a disapproved country (blacklisting). Parameters These countries Description The three-letter ISO 3166-1 alpha-3 country code of a country. Can be a single valid code or a comma-delimited list of codes. Some valid examples are: GBR BEL, NLD, LUX Are allowed for servers to connect from Are not allowed for servers to connect from Remediation Suggestion (optional) This check fails if the server's geolocation is not in the specified list of country codes. This check fails if the server's geolocation is in the specified list of country codes. Optional suggestion 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 with valid values. This check is typically used to validate a name-value pair in a configuration file. Parameters Configuration file path Configuration file section (optional) Configuration item Desired value Description The name of the file to search in. If the file is not present, the test will either Fail or be Indeterminate based on the setting set in [Site Administrator menu] > Site Administration > Scanner Settings > Mark finding as Failed if the check was indeterminate checkbox. Any valid, full system path to a file is acceptable. Example: /etc/ssh/sshd_config Use this parameter to find a predefined section of the file before beginning the search for the desired term. This parameter will be found before looking for the Configuration item. Any simple string can be used. If blank, this item is ignored. Examples: [repository] Section "device" The string that precedes the value to be validated. This is the name portion of the name-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) A value that is compliant with the policy. This is the value portion of the name-value pair. 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 configuration file) Using the NOT operator Place the NOT: operator before the value to specify that it should not occur for this item. For example, if you wish to verify that the SSH process is listening on a nonstandard port (that is, the check should fail if sshd is listening on port 22), specify NOT: 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 comment character. Therefore, in searching for a particular value for a given configuration item, if the item 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 exists but 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 the file, if the file section is not found or if the configuration item is not found, the check passes. Checking the value of a whole file In certain cases, you can use the Desired value field to check the value of the contents of an entire file. The file content must be a single string with no line breaks or returns. In the rule check, you must leave the Configuration item field blank, and specify 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 file whose string value is either 0 or 1. You could make these settings for the check: Configuration file path: /proc/sys/net/ipv4/ip_forward Configuration item: <blank> Desired value: 0 Configuration file comment character (optional) Configuration item/value delimiter Remediation Suggestion (optional) Character or string that is used to comment out a line. Commented lines are ignored in the 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: # Character that separates the configuration item from the value of that item. The default is a space. Note that multiple spaces between the item name and value in the configuration file are collapsed to a single space for performing the check. 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 the presence of a directory, use the Directory Presence check instead. Parameters File(s) Description The name of the file to look for. Any valid, full path to a single file, a comma-delimited list of paths to individual files, a single wildcard file path, or a comma-delimited list of wildcard file paths is acceptable. Note: The asterisk (*) is the only acceptable wildcard character. You cannot use a question mark. Some valid examples: /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 Should not be present Remediation Suggestion (optional) This check fails if any of the listed files is not present. This check fails if any of the listed files is present. Optional suggestion 37

38

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. Parameters File(s) Description The name of the file to look for. If the file is not present, the test will either Fail or be Indeterminate, depending on the state of the Mark finding as Failed if the check was indeterminate checkbox, accessible at [Site Administrator menu] > Site Administration > Scanner Settings. Any valid, full path to a single file, a comma-delimited list of paths to individual files, a single wildcard file path, or a comma-delimited list of wildcard file paths is acceptable. Note: The asterisk (*) is the only acceptable wildcard character. You cannot use a question mark. Some valid examples: /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 have ACL(s) A three-character string representing the desired security value. Any three-digit octal value can be used. Use an asterisk (*) for a wildcard in any position. You can use the NOT: operator to exclude a set of values. Spaces are ignored. Note: File setuid and setgid states are separate checks. Some valid examples are: 777 400 **7 6** NOT: 777, 577, 377 0777 Remediation Suggestion (optional) Optional suggestion. 39

40

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 one of a list of user accounts. Parameters File(s) Description The name of the file to look for. If the file is not present, the test will either Fail or be Indeterminate, depending on the state of the Mark finding as Failed if the check was indeterminate checkbox, accessible at [Site Administrator menu] > Site Administration > Scanner Settings. Any valid, full path to a single file, a comma-delimited list of paths to individual files, a single wildcard file path, or a comma-delimited list of wildcard file paths is acceptable. Note: The asterisk (*) is the only acceptable wildcard character. You cannot use a question mark. Some valid examples: /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 owned by user(s) The comma-delimited list of account names (not account UIDs) that should include the owner of this file. Any single account name or comma-separated list of names is acceptable. Use the NOT: operator to exclude a set of names. Spaces are ignored. Some valid examples are: root root, admin root, admin, jsmith NOT: nobody, ftp, system root, 0 0, 101, 201 IN: 0, 101, 201 Remediation Suggestion (optional) Optional suggestion. 41

42

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 one of a list of user groups. Parameters File(s) Description The name of the file to look for. If the file is not present, the test will either Fail or be Indeterminate, depending on the state of the Mark finding as Failed if the check was indeterminate checkbox, accessible at [Site Administrator menu] > Site Administration > Scanner Settings. Any valid, full path to a single file, a comma-delimited list of paths to individual files, a single wildcard file path, or a comma-delimited list of wildcard file paths is acceptable. Note: The asterisk (*) is the only acceptable wildcard character. You cannot use a question mark. Some valid examples: /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 owned by group(s) The group names (not group GIDs) of the group or groups that should include the group owner of this file. Any single name or comma-separated list of names is acceptable. Use the NOT: operator to exclude a set of group names. Spaces are ignored. Some valid examples are: root root, admin root, admin, jsmith NOT: nobody, ftp, system root, 0 0, 101, 201 Remediation Suggestion (optional) Optional suggestion. 43

44

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. Parameters File(s) Description The name of the file to look for. If the file is not present, the test will either Fail or be Indeterminate, depending on the state of the Mark finding as Failed if the check was indeterminate checkbox, accessible at [Site Administrator menu] > Site Administration > Scanner Settings. Any valid, full path to a single file, a comma-delimited list of paths to individual files, a single wildcard file path, or a comma-delimited list of wildcard file paths is acceptable. Note: The asterisk (*) is the only acceptable wildcard character. You cannot use a question mark. Some valid examples: /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 setuid should not be setuid Remediation Suggestion (optional) Fails if the setuid bit is not set on one or more of the files. Fails if the setuid bit is set on one or more of the files. Optional suggestion. 45

46

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. Parameters File(s) Description The name of the file to look for. If the file is not present, the test will either Fail or be Indeterminate, depending on the state of the Mark finding as Failed if the check was indeterminate checkbox, accessible at [Site Administrator menu] > Site Administration > Scanner Settings. Any valid, full path to a single file, a comma-delimited list of paths to individual files, a single wildcard file path, or a comma-delimited list of wildcard file paths is acceptable. Note: The asterisk (*) is the only acceptable wildcard character. You cannot use a question mark. Some valid examples: /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 setgid should not be setgid Remediation Suggestion (optional) Fails if the setgid bit is not set on one or more of the files. Fails if the setgid bit is set on one or more of the files. Optional suggestion 47

48

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 more specified files. You use a syntax similar to regular expressions to specify the string to find. You specify the files using full 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 target string, and stops analyzing that file as soon as a match occurs. Parameters File(s) Description The name of the file to look for the string in. If none of the specified files is present, the check is indeterminate for that file. Any valid, full path to a single file or a comma-delimited list of paths to individual files is acceptable. Wildcards are not supported. Some valid examples: /etc/init.d/httpd /etc/init.d/httpd, /etc/init.d/mysqld init.d/httpd /etc/rc.d/rc?.d /etc/init.d/* Contains Does not contain...the following pattern: If you choose this, the check fails for each of the listed files in which the specified string is not present. If you choose this, the check fails for each of the listed files in which the specified string is present. Enter the string to be found, or an expression that represents the string. See Search Expression Syntax in the Halo Operations Guide for an explanation of the supported 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 regular expressions): [cdlou]{5}9 (repetition operator not supported) cloud (1 9) (option operator [pipe] and grouping by parentheses not supported) Some example search strings that might be useful for server security: ^host\s.*0.0.0.0/0.*trust Search for (and alert on) matching strings in the configuration file pg_hba.conf on 49

your PostgreSQL database servers. This string would allow password-free connection to the server from any IP address (if your firewall were down or bypassed). In cloud environments that do not use DHCP, search for the character 0 or 1 in the file /proc/net/packet. It might indicate that the host has been compromised 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 on the server being scanned. Depending on which option you choose, the check fails and an event is generated if a listed package is not installed, or is installed, or if an installed package is not listed. Parameters Package name(s) Description The name of the package to look for. Any complete package name or a commadelimited list of package names is acceptable. Wildcards are not supported. Some valid examples: bash.x86_64 bash.x86_64,rsyslog.x86_64,util-linux.x86_64 bash bash* bash.x86_?? Should be installed Should not be installed Allowed to be installed Remediation Suggestion (optional) If you choose this, all of the listed packages should be installed. If any is missing, the check fails. 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.) If you choose this, any of the listed packages is acceptable to be installed. If any installed package is not in the list, the check fails. (The check functions as a whitelist.) Description of how you plan to remediate situations in which this check fails. 51

52

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 a Linux system. To check for the presence of a (non-directory) file, use the File Presence check instead. Parameters Folder(s) Description The name of the directory to look for. Any valid, full path to a single directory, a comma-delimited list of paths to individual directories, a single wildcard directory path, or a comma-delimited list of wildcard directory paths is acceptable. Note: The asterisk (*) is the only acceptable wildcard character. You cannot use a question mark. Some valid examples: /etc/init.d /etc/init.d, /var/lib/mysql/test /var/lib/mysql/* init.d /etc/init.d/mysqld Should be present Should not be present Remediation Suggestion (optional) The check fails if any of the specified directories is not present. The check fails if any of the specified directories is present. Optional suggestion Copyright 2014 CloudPassage Inc. All rights reserved. CloudPassage and Halo are registered trademarks of CloudPassage, Inc. 53

54

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 is not 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 root partition (/), where it could potentially fill up the system disk and cause an outage. Parameters Target Should be mounted on Should not be mounted on Mount point Remediation Suggestion (optional) Description Full path to the mounted file or directory. Widcards are not accepted. This check fails if the target is not mounted at the specified mount point. This check fails if the target is mounted at the specified mount point. Full path to the directory used as the mount point. Widcards are not accepted. Optional suggestion Copyright 2014 CloudPassage Inc. All rights reserved. CloudPassage and Halo are registered trademarks of CloudPassage, Inc. 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. Parameters Folder(s) Description The name of the directory to look for. If it is not present, the test will either Fail or be Indeterminate, depending on the state of the Mark finding as Failed if the check was indeterminate checkbox, accessible at [Site Administrator menu] > Site Administration > Scanner Settings. Any valid, full path to a single directory, a comma-delimited list of paths to individual directories, a single wildcard directory path, or a comma-delimited list of wildcard directory paths is acceptable. Note: The asterisk (*) is the only acceptable wildcard character. You cannot use a question mark. Some valid examples: /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 have ACL(s) A three-character string representing the desired security value. Any three-character octal value can be used. Use an asterisk (*) for a wildcard in any position. You can use the NOT: operator to exclude a set of three-character values. Spaces are ignored. Some valid examples are: 777 400 **7 6** NOT: 777, 577, 377 0777 Remediation Suggestion (optional) Optional suggestion. 56

57

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 user account or by one of a list of user accounts. Parameters Folder(s) Description The name of the directory to look for. If the directory is not present, the test will either Fail or be Indeterminate, depending on the state of the Mark finding as Failed if the check was indeterminate checkbox, accessible at [Site Administrator menu] > Site Administration > Scanner Settings. Any valid, full path to a single directory, a comma-delimited list of paths to individual directories, a single wildcard directory path, or a comma-delimited list of wildcard directory paths is acceptable. Note: The asterisk (*) is the only acceptable wildcard character. You cannot use a question mark. Some valid examples: /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 the owner of this directory. Any single account name or comma-separated list of names is acceptable. Use the NOT: operator to exclude a set of names. Spaces are ignored. Some valid examples are: root root, admin root, admin, jsmith NOT: nobody, ftp, system root, 0 0, 101, 201 IN: 0, 101, 201 Remediation Suggestion (optional) Optional suggestion. 58

59

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 user group or one of a list of user groups. Parameters Folder(s) Description The name of the directory to look for. If the directory is not present, the test will either Fail or be Indeterminate, depending on the state of the Mark finding as Failed if the check was indeterminate checkbox, accessible at [Site Administrator menu] > Site Administration > Scanner Settings. Any valid, full path to a single directory, a comma-delimited list of paths to individual directories, a single wildcard directory path, or a comma-delimited list of wildcard directory paths is acceptable. Note: The asterisk (*) is the only acceptable wildcard character. You cannot use a question mark. Some valid examples: /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 the group owner of this directory. Any single name or comma-separated list of names is acceptable. Use the NOT: operator to exclude a set of group names. Spaces are ignored. Some valid examples are: root root, admin root, admin, jsmith NOT: nobody, ftp, system root, 0 0, 101, 201 Remediation Suggestion (optional) Optional suggestion. 60

61

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 directory on 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 deleting files within the directory. The bit is commonly set on temporary directories to prevent one user from overwriting or deleting 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") are displayed in the scan results. Parameters Exclude directories Description Full paths to any directories to exclude from this check. Any valid, full path to a single directory, a comma-delimited list of paths to individual directories, a single wildcard directory path, or a comma-delimited list of wildcard directory paths is acceptable. Note: The asterisk (*) and question mark (?) characters are the only acceptable wildcard characters. Some valid examples: /etc/init.d /etc/init.d, /etc/rc.d /etc/* /etc/rc.d/*, /etc/rc.d//* /etc/r?.d Remediation Suggestion (optional) Optional suggestion. 62

63

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. Parameters Process(es) Description The name of the process to search for. Can be any valid process name or a commadelimited list of names. Wildcards are not allowed, although you can use the asterisk character (*) if it is part of a process name. Some valid examples are: httpd httpd, mysql Should be running Should not be running Allowed to be running Remediation Suggestion (optional) This check fails if any of the listed processes is not running. This check fails if any of the listed processes is running. This check fails if any running processes is not listed. If you choose this option, the check functions as a whitelist: the check passes if all running processes are listed, and it fails if any process not on the list is running. Optional suggestion 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 user account or by any user in a list of accounts. Parameters Process(es) Description The process to examine. Can be any valid process name or any of a comma-delimited list of processes. Wildcards are not allowed, although you can use the asterisk character (*) if it is part of a process name. Some valid examples are: httpd httpd, mysql...should be owned by user (s) A comma-delimited list of one or more account names to compare with the owner of the process being examined. Must be account names, not account UIDs. Spaces are ignored. Use the NOT: operator if you want to exclude certain users from owning these processes. Some valid examples are: root root, admin root, admin, jsmith NOT: nobody, ftp, system root, 0 0, 101, 201 Remediation Suggestion (optional) Optional suggestion 65

66

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 or by one of a set of groups. Parameters Process(es) Description The name of the process to check the ownership of. Can be single process or a comma-delimited list of processes. Wildcards are not allowed, but you can use the asterisk (*) if it is part of the process name. Some valid examples are: httpd httpd, mysql...should be owned by user(s) An account name or a comma-delimited list of names that should (or should not) own this file. Must be account usernames, not UIDs. Spaces are ignored. Use the NOT: operator to exclude a set of names. Some valid examples are: root root, admin root, admin, jsmith NOT: nobody, ftp, system root, 0 0, 101, 201 Remediation Suggestion (optional) Optional suggestion 67

68

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 user accounts on the server being scanned. Depending on which option you choose, the check fails and an event is generated if a listed account does not exist, or does exist, or if an existing account is not listed. Parameters User name(s) Description The username of the account to look for. Any valid username or a comma-delimited list of names is acceptable. Wildcards are not supported. Some valid examples: adm adm,root,ops-admin ec2?smith admin* Should be present Should not be present Allowed to be present Remediation Suggestion (optional) If you choose this, all of the listed accounts should exist on the server. If any of the listed accounts does not exist, the check fails. If you choose this, none of the listed accounts should exist on the server. If any of the listed accounts does exist, the check fails. (The check functions as a blacklist.) If you choose this, any of the listed accounts is acceptable to be present. If any existing account is not in the list, the check fails. (The check functions as a whitelist.) Description of how you plan to remediate situations in which this check fails. 69

70

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. Parameters User(s) Description The account name or names to check. This can be a single account name or a comma-delimited list of account names. The account name must be used, not the account UID. Extra spaces are ignored. The ALL keyword can be used to specify that all accounts on the system should be checked. Some valid examples are: root root, admin root, admin, jsmith ALL root, 0 0, 101, 201 Remediation Suggestion (optional) Optional suggestion 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 (not expired) passwords. If any of the accounts has an expired password, the check fails. Parameters User(s) Description The account name or names to test for unexpired passwords. Can be a single account name 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 should be checked. Some valid examples are: root root, admin root, admin, jsmith ALL root, 0 0, 101, 201 Remediation Suggestion (optional) Optional suggestion Copyright 2014 CloudPassage Inc. All rights reserved. CloudPassage and Halo are registered trademarks of CloudPassage, Inc. 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 the specified user or users do not match their usernames. If /etc/shadow is being used, the check also inspects that file. Parameters User(s) Description The account name or names to test for password violation. Can be a single account name 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 should be checked. Some valid examples are: root root, admin root, admin, jsmith ALL root, 0 0, 101, 201 Remediation Suggestion (optional) Optional suggestion 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 specified range. Parameters User Description The single account name to check. Only a single account name can be used. It cannot be a comma-delimited list of account names, or the UID, or the keyword ALL. Some valid examples are: 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, a comma-delimited list of values, or a range of values using a greater-than or less-than sign. Extra spaces are ignored. Some valid examples are: 0 101,102 >1000 <500 >500, <1000-100 Remediation Suggestion (optional) Optional suggestion 74

75

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 listed groups, 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 not listed 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 access permissions than the user should be allowed. Parameters User Description The single account name to check. Only a single account name can be used. It cannot be a comma-delimited list of account names, or the UID, or the keyword ALL. Some valid examples are: 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 single group name or a comma-delimited list of group names. The group name must be used, not the group GID. Extra spaces are ignored Some valid examples are: root wheel, admin finance, company 500 Remediation Suggestion (optional) Optional suggestion 76

77

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 have logged in recently. If any have not (and the check fails), their accounts can be considered inactive. Parameters User(s) Description The list of names to check. Can be a single account name, a comma-delimited list of account names, or the keyword ALL (must be capitalized - all is treated as a username). You must supply a username, not a UID. Extra spaces are ignored. Some valid examples are: root root, admin ALL root, 0...should have logged in during the past days The number of days an account is allowed to go without an interactive login before the policy 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 account from an existing shell session. Some valid examples are: 100-50 <100 Remediation Suggestion (optional) Optional suggestion 78

79

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 not logged in recently. This would typically be used to watchlist certain users (for example, terminated users or users nearing termination), accounts that should be temporarily inactive, or accounts that should never have interactive logins (like the root or Oracle accounts). If any logins have occurred (the check fails), it could be a security concern. Parameters User(s) Description The list of names to check. This is a single account name, or a comma-delimited list of account names, or the keyword ALL (must be capitalized - "all" is treated as a username). The UID cannot be used. Extra spaces are ignored. Some valid examples are: root root, admin ALL root, 0..should have NOT logged in for the past days The number of days an account is allowed to go without an interactive login before the policy is violated. This is a single positive integer value of the number of days. This only tracks to interactive shell logins and does not apply to su'ing to an account from an existing shell session. Some valid examples are: 100-50 <100 Remediation Suggestion (optional) Optional suggestion 80

81

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 check passes for a user if (1) the user has a home directory specified in /etc/passwd, and (2) the directory exists. The check is indeterminate for any specified user whose account does not exist. Parameters User(s) Description The list of names to check. This is a single account name, or a comma-delimited list of account names (maximum length = 255 characters), or the keyword ALL (must be capitalized - "all" is treated as a username). The UID cannot be used. Wildcards are not supported. Extra spaces are ignored. All usernames are case-sensitive. Use the NOT operator to specify that all users except the specified ones should be checked. Some valid examples are: root susang, susanh root, admin, sysadmin204 ALL NOT: root, admin root, 0 Remediation Suggestion (optional) Optional suggestion 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 is actually 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, or whose defined home directory does not actually exist. Parameters User(s) Description The list of names to check. This is a single account name, or a comma-delimited list of account names (maximum length = 255 characters), or the keyword ALL (must be capitalized - "all" is treated as a username). The UID cannot be used. Wildcards are not supported. Extra spaces are ignored. All usernames are case-sensitive. Use the NOT operator to specify that all users except the specified ones should be checked. Some valid examples are: root susang, susanh root, admin, sysadmin204 ALL NOT: root, admin root, 0 Remediation Suggestion (optional) Optional suggestion 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 home directory is that user's primary group. The check fails for any specified user whose home directory is not owned by the user's primary group. The check is indeterminate for any user whose account does not exist, or who has no defined home directory, or whose defined home directory does not actually exist. Parameters User(s) Description The list of names to check. This is a single account name, or a comma-delimited list of account names (maximum length = 255 characters), or the keyword ALL (must be capitalized - "all" is treated as a username). The UID cannot be used. Wildcards are not supported. Extra spaces are ignored. All usernames are case-sensitive. Use the NOT operator to specify that all users except the specified ones should be checked. Some valid examples are: root susang, susanh root, admin, sysadmin204 ALL NOT: root, admin root, 0 Remediation Suggestion (optional) Optional suggestion 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 verify that all files in each user's home directory are owned by that user. The check fails for any specified user whose home directory contains any files not owned by the user. The check is indeterminate for any user whose account does not exist, or who has no defined home directory, or whose defined home directory does not actually exist. Note: The search is recursive, including all subdirectories of the home directory. All files, including device files and 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 home directory. Parameters User(s) Description The list of names to check. This is a single account name, or a comma-delimited list of account names (maximum length = 255 characters), or the keyword ALL (must be capitalized - "all" is treated as a username). The UID cannot be used. Wildcards are not supported. Extra spaces are ignored. All usernames are case-sensitive. Use the NOT operator to specify that all users except the specified ones should be checked. Some valid examples are: root susang, susanh root, admin, sysadmin204 ALL NOT: root, admin root, 0 Remediation Suggestion (optional) Optional suggestion 85

86

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 users to verify that the group owner of all files in each user's directory is that user's primary group. The check fails for any specified user whose home directory contains any files that are not owned by the user's primary group. The check is indeterminate for any user whose account does not exist, or who has no defined home directory, or whose defined home directory does not actually exist. Note: The search is recursive, including all subdirectories of the home directory. All files, including device files and 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 home directory. Parameters User(s) Description The list of names to check. This is a single account name, or a comma-delimited list of account names (maximum length = 255 characters), or the keyword ALL (must be capitalized - "all" is treated as a username). The UID cannot be used. Wildcards are not supported. Extra spaces are ignored. All usernames are case-sensitive. Use the NOT operator to specify that all users except the specified ones should be checked. Some valid examples are: root susang, susanh root, admin, sysadmin204 ALL NOT: root, admin root, 0 Remediation Suggestion (optional) Optional suggestion 87

88

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 PATH statements. The Home Directory Files Have No Unsafe PATH Statements check verifies that the specified startup scripts in the home directory of the specified user (or users) include only safe PATH statements meaning that none sets 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 if any matching files contain unsafe PATH statements, and it passes for that user if not. The check is indeterminate for any user whose account does not exist, or who has no defined home directory, or whose defined home directory does not actually exist. Note: Files larger than 10KB are ignored, even if they match the file specifications in this check. Parameters User(s) Description The list of names to check. Can be a single account name, a comma-delimited list of account names (maximum length = 255 characters), or the keyword ALL (must be capitalized - "all" is treated as a username). The UID cannot be used. Wildcards are not supported. Extra spaces are ignored. All usernames are case-sensitive. Use the NOT operator to specify that all users except the specified ones should be checked. Some valid examples are: root susang, susanh root, admin, sysadmin204 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 of paths to individual files, a single wildcard file path, or a comma-delimited list of wildcard file paths. All paths are relative to the specified user's home directory and cannot start with a slash. Note: The asterisk (*) and the question mark(?) are the acceptable wildcard characters. The asterisk matches any number of filename characters, and the question mark matches any single character. Some valid examples:.profile.profile, myscripts/.bash_profile myscripts/bash_startup* myscripts/bash_startup? /home/susanh/myscripts/.bash_profile myscripts/ Remediation Suggestion (optional) Optional suggestion 89

90

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 the home 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 considered invalid. In general, umasks with low values are less safe because the result of their application is that overly permissive files are created. Also, because a global umask exists, in most cases it is not appropriate for individual users to override it. The check examines all matching files in each specified user's home directory. The check fails for an individual user if any matching files contain invalid umask commands, and it passes for that user if not. The check is indeterminate for any user whose account does not exist, or who has no defined home directory, or whose defined home directory does not actually exist. If the check fails for a given set of umask values, the username, home directory path, filename, and actual umask value are displayed in the scan results. Note: Files larger than 10KB are ignored, even if they match the file specifications in this check. Parameters User(s) Description The list of names to check. Can be a single account name, a comma-delimited list of account names (maximum length = 255 characters), or the keyword ALL (must be capitalized - "all" is treated as a username). The UID cannot be used. Wildcards are not supported. Extra spaces are ignored. All usernames are case-sensitive. Use the NOT operator to specify that all users except the specified ones should be checked. Some valid examples are: root susang, susanh root, admin, sysadmin204 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 of paths to individual files, a single wildcard file path, or a comma-delimited list of wildcard file paths. All paths are relative to the specified user's home directory and cannot start with a slash. Note: The asterisk (*) and the question mark(?) are the acceptable wildcard characters. The asterisk matches any number of filename characters, and the question mark matches any single character. Some valid examples:.profile.profile, myscripts/.bash_profile myscripts/bash_startup* myscripts/bash_startup? 91

/home/susanh/myscripts/.bash_profile myscripts/ Should have umask Specify the desired umask value in octal notation. Wildcards and the NOT operator are supported. The values entered in this field are the values that are acceptable for umask commands in matching files. If NOT is used, none of the listed values is acceptable. Some valid examples: 111 111,027 01?, 0* NOT: 025, 022, 020, 01*, 00* rwxr--r-- 0123 Remediation Suggestion (optional) Optional suggestion 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 verify that the setuid bit in all the files in the directory is cleared. The check fails for any specified user whose home directory 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 could be a favored target of an attacker.) The check is indeterminate for any user whose account does not exist, or who has no defined home directory, or whose defined home directory does not actually exist. Note: The search is recursive, including all subdirectories of the home directory. All files, including device files and 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 home directory. Parameters User(s) Description The list of names to check. This is a single account name, or a comma-delimited list of account names (maximum length = 255 characters), or the keyword ALL (must be capitalized - "all" is treated as a username). The UID cannot be used. Wildcards are not supported. Extra spaces are ignored. All usernames are case-sensitive. Use the NOT operator to specify that all users except the specified ones should be checked. Some valid examples are: root susang, susanh root, admin, sysadmin204 ALL NOT: root, admin root, 0 Remediation Suggestion (optional) Optional suggestion 93

94

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 verify that the setgid bit in all the files in the directory is cleared. The check fails for any specified user whose home directory 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 could be a favored target of an attacker.) The check is indeterminate for any user whose account does not exist, or who has no defined home directory, or whose defined home directory does not actually exist. Note: The search is recursive, including all subdirectories of the home directory. All files, including device files and 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 home directory. Parameters User(s) Description The list of names to check. This is a single account name, or a comma-delimited list of account names (maximum length = 255 characters), or the keyword ALL (must be capitalized - "all" is treated as a username). The UID cannot be used. Wildcards are not supported. Extra spaces are ignored. All usernames are case-sensitive. Use the NOT operator to specify that all users except the specified ones should be checked. Some valid examples are: root susang, susanh root, admin, sysadmin204 ALL NOT: root, admin root, 0 Remediation Suggestion (optional) Optional suggestion 95

96

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 verify that none of the files in the directory is a block or character device. The check fails for any specified user whose home 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 a strong indicator of an intrusion.) The check is indeterminate for any user whose account does not exist, or who has no defined home directory, or whose defined home directory does not actually exist. Note: The search is recursive, including all subdirectories of the home directory. All files, including device files and 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 home directory. Parameters User(s) Description The list of names to check. This is a single account name, or a comma-delimited list of account names (maximum length = 255 characters), or the keyword ALL (must be capitalized - "all" is treated as a username). The UID cannot be used. Wildcards are not supported. Extra spaces are ignored. All usernames are case-sensitive. Use the NOT operator to specify that all users except the specified ones should be checked. Some valid examples are: root susang, susanh root, admin, sysadmin204 ALL NOT: root, admin root, 0 Remediation Suggestion (optional) Optional suggestion 97

98

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 the specified user (or users). Depending on a setting that you make, the check passes for a user either if (1) all the specified 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 home directory, or whose defined home directory does not actually exist. Parameters User(s) Description The list of names to check. This is a single account name, or a comma-delimited list of account names (maximum length = 255 characters), or the keyword ALL (must be capitalized - "all" is treated as a username). The UID cannot be used. Wildcards are not supported. Extra spaces are ignored. All usernames are case-sensitive. Use the NOT operator to specify that all users except the specified ones should be checked. Some valid examples are: root susang, susanh root, admin, sysadmin204 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 of paths to individual files, a single wildcard file path, or a comma-delimited list of wildcard file paths. All paths are relative to the specified user's home directory and cannot start with a slash. Note: The asterisk (*) and the question mark(?) are the acceptable wildcard characters. The asterisk matches any number of filename characters, and the question mark matches any single character. Some valid examples:.rhosts.rhosts, myscripts/.bash_profile myscripts/bash_startup* myscripts/bash_startup? /home/susanh/.rhosts myscripts/ Should be present Should not be present Remediation Suggestion (optional) This check passes of any of the listed files are present; it fails if none is present. This check passes if none of the listed files is present; it fails if any are present. Optional suggestion 99

100

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 a specified range. Parameters Group Description The name of the group to check. You cannot specify more than one group. Some valid examples are: 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 commadelimited list of values, or a one-ended range of values using a greater-than (>) or less-than (<) sign. Extra spaces are ignored. Some valid examples are: 0 101,102 >1000 <500 >500, <1000-100 Remediation Suggestion (optional) Optional suggestion 101

102

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 user accounts, and no more. If the group does not include one of the listed accounts, or if it includes an account not on the list, the check fails. You can use this check to verify that a highly privileged group does not contain any users that should not belong. Parameters Group Description The name (not the GID) of the group to check. You cannot list more than one group. Some valid examples are: root admin webmasters root, webmasters ALL should only have the following users A list of user account names to test for membership in the group. Can be a single name or a comma-delimited list of names. Extra spaces are ignored. Some valid examples are: root root, admin root, 0 NOT: webmasters, sysadmins ALL Remediation Suggestion (optional) Optional suggestion 103

104

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 have passwords. It also checks /etc/gshadow if it is being used. Parameters Group(s) Description The name of the group or groups to check. Can be a single group name, a commadelimited list of names, or the keyword ALL (to specify that all accounts on the system should be checked). You cannot use group GIDs. Extra spaces are ignored. The ALL keyword must be capitalized - "all" is treated as a username. Some valid examples are: root root, admin root, admin, webmasters ALL root, 0 0, 101, 201 Remediation Suggestion (optional) Optional suggestion 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 Halo analytics 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 to them. 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 by specifying "0" in the expected open ports field. If any ports are open, the check will fail and the results will list all of the open ports. Parameters Interface(s) Open Port(s) Remediation Suggestion (optional) Description The name of the interface device that the service(s) are expected to run on. Can be a single 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, you cannot specify an IP address. Subinterfaces should use the same device naming scheme as the operating system (e.g. eth0:0, eth1:3). 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 a comma-delimited list to specify multiple ports (for example, 22/TCP, 80/TCP). If the port is expected to listen to both TCP and UDP, use just the port number alone for that port (for example, 22/TCP, 80/TCP, 53). To enter a range of port numbers, use a colon (for example, 60000:61000/TCP). The range includes the beginning port number, the ending port number, and all port numbers between them. The NOT: operator is supported in this field. If you use it, it applies to the entire set of listed ports and the check fails if any of them is open. All of the unspecified ports would be permitted to be open. NOT: 1025:65535 The list of ports can be up to 2048 bytes long. Optional suggestion 106

107

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 software processes. In the example below, port 22 should have only the sshd secure shell process bound to it. This check can help you detect malware bound to any of the server's open ports. Parameters Port(s) Description This one parameter identifies the interface device name to be checked, the port on that device to be checked, and the IP protocol used (TCP or UDP). If you specify no protocol, the service process for both protocols will be checked. Some valid examples are: 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 be bound to this interface/port/protocol specification. The presence of any process not on the list is considered a failure of the check. Some valid examples are: httpd nginx httpd, nginx mysql Remediation Suggestion (optional) Optional suggestion 108

Copyright 2016 CloudPassage Inc. All rights reserved. CloudPassage and Halo are registered trademarks of CloudPassage, Inc. 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 listening through its specified protocol. Alternatively, the check tcan test for the negative of that state, testing to make sure that a 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 result is indeterminate for each combination of interface and port/protocol in which the interface cannot be found. Parameters Interface(s) Description The name of the interface device that the port(s) are expected to be listening on. Can be a single 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, you cannot specify an IP address. Subinterfaces should use the same device naming scheme as the operating system (e.g. eth0:0, eth1:3). Some valid examples are: 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 protocol used (TCP or UDP). If you specify no protocol, both protocols will be checked for the port. Can be a single port/protocol specification or a comma-delimited list. Some valid examples are: 53 22/TCP 53/UDP Should be listening Should not be listening Remediation Suggestion (optional) This check fails whenever the specified port is not listening through its specified protocol on the specified interface. This check fails whenever the specified port is listening through its specified protocol on the specified interface. Optional suggestion Copyright 2014 CloudPassage Inc. All rights reserved. CloudPassage and Halo are registered trademarks of CloudPassage, Inc. 110