Policy monitoring

The rootcheck module can be used to enforce and monitor your security policy. This is the process of verifying that all systems conform to a set of predefined rules surrounding configuration settings and approved application usage.

There are several PCI DSS requirements to verify that systems are properly hardened. An example would be:

2.2: Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
Sources of industry-accepted system hardening standards may include, but are not limited to: Center for Internet Security (CIS), International Organization for Standardization (ISO), SysAdmin Audit Network Security (SANS), Institute National Institute of Standards Technology (NIST).

Wazuh includes out-of-the-box, CIS baselines for Debian and Red Hat. Other baselines could be created for other systems or applications as well, just by adding the corresponding rootcheck file:

<rootcheck>
  <system_audit>/var/ossec/etc/shared/cis_debian_linux_rcl.txt</system_audit>
  <system_audit>/var/ossec/etc/shared/cis_rhel_linux_rcl.txt</system_audit>
  <system_audit>/var/ossec/etc/shared/cis_rhel5_linux_rcl.txt</system_audit>
</rootcheck>

Other PCI DSS requirements ask us to check that applications (especially network services) are configured in a secure way. One example is the following control:

2.2.4: Configure system security parameters to prevent misuse.

The following are good examples of rootcheck rules developed to check the configuration of SSH services:

[SSH Configuration - Protocol version 1 enabled {PCI_DSS: 2.2.4}] [any]
f:/etc/ssh/sshd_config -> !r:^# && r:Protocol\.+1;

[SSH Configuration - Root login allowed {PCI_DSS: 2.2.4}] [any]
f:/etc/ssh/sshd_config -> !r:^# && r:PermitRootLogin\.+yes;

In Wazuh, the rootcheck rules use this syntax in the rootcheck name: {PCI_DSS: X.Y.Z}, mapping all rootchecks to their relevant PCI DSS requirement.

Use cases

In order to check SSH security settings and help meet requirement 2.2.4, we have developed the rootchecks system_audit_ssh. In our example, when Wazuh runs a rootcheck scan, it is able to detect certain security deficiencies in the SSH configuration.

[root@manager ossec]# cat etc/ossec.conf | grep system_audit_ssh -B 4 -A 2

<rootcheck>
    <rootkit_files>/var/ossec/etc/shared/rootkit_files.txt</rootkit_files>
    <rootkit_trojans>/var/ossec/etc/shared/rootkit_trojans.txt</rootkit_trojans>
    <system_audit>/var/ossec/etc/shared/system_audit_rcl.txt<system_audit>
    <system_audit>/var/ossec/etc/shared/ssh/system_audit_ssh.txt<system_audit>
</rootcheck>

If enabled, the file archives.log stores every log parsed by the Wazuh engine, whether it becomes an alert or not:

[root@manager ossec]# tail -f logs/archives/archives.log
2016 Jan 29 12:58:02 manager->rootcheck Ending rootcheck scan.
2016 Jan 29 13:07:18 manager->ossec-monitord ossec: Ossec started.
2016 Jan 29 13:08:34 manager->rootcheck Starting rootcheck scan.
2016 Jan 29 13:08:36 manager->rootcheck System Audit: SSH Hardening - 3: Root can log in {PCI_DSS: 2.2.4}. File: /etc/ssh/sshd_config. Reference: 3 .
2016 Jan 29 13:08:36 manager->rootcheck System Audit: SSH Hardening - 4: No Public Key authentication {PCI_DSS: 2.2.4}. File: /etc/sshd/sshd_config. Reference: 4 .
2016 Jan 29 13:08:36 manager->rootcheck System Audit: SSH Hardening - 5: Password Authentication {PCI_DSS: 2.2.4}. File: /etc/sshd/sshd_config. Reference: 5 .
2016 Jan 29 13:08:36 manager->rootcheck System Audit: SSH Hardening - 6: Empty passwords allowed {PCI_DSS: 2.2.4}. File: /etc/sshd/sshd_config. Reference: 6 .
2016 Jan 29 13:08:36 manager->rootcheck System Audit: SSH Hardening - 7: Rhost or shost used for authentication {PCI_DSS: 2.2.4}. File: /etc/sshd/sshd_config. Reference: 7 .
2016 Jan 29 13:08:36 manager->rootcheck System Audit: SSH Hardening - 8: Wrong Grace Time {PCI_DSS: 2.2.4}. File: /etc/sshd/sshd_config. Reference: 8 .
2016 Jan 29 13:08:36 manager->rootcheck System Audit: SSH Hardening - 9: Wrong Maximum number of authentication attempts {PCI_DSS: 2.2.4}. File: /etc/sshd/sshd_config. Reference: 9 .

In this case, all the logs above are alerts, so we will see an instance of the last alert in JSON:

[root@manager ossec]# tail -n 1 logs/alerts/alerts.json | pjson

{
  "rule": {
    "level": 3,
    "description": "System Audit event.",
    "id": 516,
    "firedtimes": 7,
    "groups": [
      "ossec",
      "rootcheck"
    ],
    "pci_dss": [
      "2.2.4"
    ]
  },
  "agent": {
      "id": "000",
      "name": "manager"
  },
  "manager": {
    "name": "manager"
  },
  "full_log": "System Audit: SSH Hardening - 9: Wrong Maximum number of authentication attempts {PCI_DSS: 2.2.4}. File: /etc/ssh/sshd_config. Reference: 9 .",
  "title": "SSH Hardening - 9: Wrong Maximum number of authentication attempts",
  "file": "/etc/ssh/sshd_config",
  "decoder": {
    "name": "rootcheck"
  },
  "timestamp": "2016 Jan 29 13:08:36",
  "location": "rootcheck"
}

Kibana shows the full information about the alert: