Guide to the Secure Configuration of Virtuozzo Hybrid Infrastructure

with profile VHI Security Hardening
This guide is intended for system administrators and provides a comprehensive set of instructions recommended for hardening a Virtuozzo Hybrid Infrastructure cluster.
This guide presents a catalog of security-relevant configuration settings for Virtuozzo Hybrid Infrastructure. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the scap-security-guide package which is developed at https://www.open-scap.org/security-policies/scap-security-guide.

Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

Profile Information

Profile TitleVHI Security Hardening
Profile IDxccdf_org.ssgproject.content_profile_vhi_security_hardening

CPE Platforms

  • cpe:/o:virtuozzohci:vz:9

Revision History

Current version: 0.1.73

  • draft (as of 2026-02-06)

Table of Contents

  1. VHI Security Hardening
    1. Access Control
    2. Monitoring and Logging
    3. Network Security
    4. Password Policy
    5. Service Security
    6. System Hardening

Checklist

Group   Guide to the Secure Configuration of Virtuozzo Hybrid Infrastructure   Group contains 7 groups and 23 rules
Group   VHI Security Hardening   Group contains 6 groups and 23 rules
[ref]  
Group   Access Control   Group contains 3 rules
[ref]  

Rule   Ensure sudo commands use pty   [ref]

Limit sudo access and prevent attackers from exploiting sudo privileges to execute malicious programs that persist even after termination. Open the /etc/sudoers file or a file in /etc/sudoers.d/ for editing with: visudo -f /etc/sudoers visudo -f /etc/sudoers.d/<file> Add the following line: Defaults use_pty
Rationale:
Requiring that sudo commands be run in a pseudo-terminal can prevent an attacker from retaining access to the user's terminal after the main program has finished executing.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r06_check_use_pty
Identifiers and References

References:  Req-10.2.5

Rule   Limit Users' SSH Access   [ref]

Limit SSH access Restrict SSH access to authorized users only mitigates the risk of unauthorized logins and brute-force attacks. Configure SSH allow lists or group-based access policies to enforce this restriction.

In the /etc/ssh/sshd_config file, set one or more parameters as follows

AllowUsers <userlist> AllowGroups <grouplist> DenyUsers <userlist> DenyGroups <grouplist>
Warning:  Automated remediation is not available for this configuration check because each system has unique user names and group names.
Rationale:
Specifying which accounts are allowed SSH access into the system reduces the possibility of unauthorized access to the system.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_r07_ssh_restrictions
Identifiers and References

References:  11, 12, 14, 15, 16, 18, 3, 5, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06, 3.1.12, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, AC-3, CM-6(a), PR.AC-4, PR.AC-6, PR.PT-3, Req-2.2.4

Group   Monitoring and Logging   Group contains 2 rules
[ref]  

Rule   Configure remote syslog logging   [ref]

Store logs on a remote host to protect log integrity from tampering or loss and to ensure centralized logging. Configure automated monitoring/alerting on the remote log host to notify administrators of suspicious activity. On each cluster node, create a remote forwarding configuration file such as /etc/rsyslog.d/XX-remotelog with the following content: *.* action(type="omfwd" queue.filename="fwdallfile" queue.maxdiskspace="1g" queue.saveonshutdown="on" queue.type="LinkedList" action.resumeRetryCount="-1" target="syslog.example.com" port="514" protocol="tcp") After updating the configuration, restart rsyslog to apply changes: systemctl restart rsyslog.service
Warning:  It is important to configure queues in case the client is sending log messages to a remote server. If queues are not configured, the system will stop functioning when the connection to the remote server is not available. Please consult Rsyslog documentation for more information about configuration of queues. The example configuration which should go into /etc/rsyslog.conf can look like the following lines:
$ActionQueueType LinkedList
$ActionQueueFileName queuefilename
$ActionQueueMaxDiskSpace 1g
$ActionQueueSaveOnShutdown on
$ActionResumeRetryCount -1
Or if using Rainer Script syntax, it could be:
*.* action(type="omfwd" queue.type="linkedlist" queue.filename="example_fwd" action.resumeRetryCount="-1" queue.saveOnShutdown="on" target="example.com" port="30514" protocol="tcp")
Rationale:
A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r30_rsyslog_forwarding
Identifiers and References

References:  1, 13, 14, 15, 16, 2, 3, 5, 6, APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.04, DSS05.07, MEA02.01, 164.308(a)(1)(ii)(D), 164.308(a)(5)(ii)(B), 164.308(a)(5)(ii)(C), 164.308(a)(6)(ii), 164.308(a)(8), 164.310(d)(2)(iii), 164.312(b), 164.314(a)(2)(i)(C), 164.314(a)(2)(iii), 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 7.1, SR 7.2, 0988, 1405, A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.17.2.1, CIP-003-8 R5.2, CIP-004-6 R3.3, CM-6(a), AU-4(1), AU-9(2), PR.DS-4, PR.PT-1, SRG-OS-000479-GPOS-00224, SRG-OS-000480-GPOS-00227, SRG-OS-000342-GPOS-00133

Rule   Configure journald to send logs to rsyslog   [ref]

Use rsyslog for consistent and reliable remote log collection. This standardizes journald log exports and simplifies long-term retention and analysis.
Rationale:
Storing log data on a remote host protects log integrity from local attacks. If an attacker gains root access on the local system, they could tamper with or remove log data that is stored on the local system.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r31_check_frwrd_to_syslog
Identifiers and References

Complexity:low
Disruption:low
Strategy:restrict
if [ -e "/etc/systemd/journald.conf" ] ; then
    
    LC_ALL=C sed -i "/^\s*ForwardToSyslog\s*=\s*/d" "/etc/systemd/journald.conf"
else
    touch "/etc/systemd/journald.conf"
fi
# make sure file has newline at the end
sed -i -e '$a\' "/etc/systemd/journald.conf"

cp "/etc/systemd/journald.conf" "/etc/systemd/journald.conf.bak"
# Insert before the line matching the regex '^#\s*ForwardToSyslog'.
line_number="$(LC_ALL=C grep -n "^#\s*ForwardToSyslog" "/etc/systemd/journald.conf.bak" | LC_ALL=C sed 's/:.*//g')"
if [ -z "$line_number" ]; then
    # There was no match of '^#\s*ForwardToSyslog', insert at
    # the end of the file.
    printf '%s\n' "ForwardToSyslog=yes" >> "/etc/systemd/journald.conf"
else
    head -n "$(( line_number - 1 ))" "/etc/systemd/journald.conf.bak" > "/etc/systemd/journald.conf"
    printf '%s\n' "ForwardToSyslog=yes" >> "/etc/systemd/journald.conf"
    tail -n "+$(( line_number ))" "/etc/systemd/journald.conf.bak" >> "/etc/systemd/journald.conf"
fi
# Clean up after ourselves.
rm "/etc/systemd/journald.conf.bak"

Complexity:low
Disruption:low
Strategy:restrict
- name: Setting unquoted shell-style assignment of 'ForwardToSyslog' to 'yes' in '/etc/systemd/journald.conf'
  block:

  - name: Check for duplicate values
    lineinfile:
      path: /etc/systemd/journald.conf
      create: true
      regexp: ^\s*ForwardToSyslog=
      state: absent
    check_mode: true
    changed_when: false
    register: dupes

  - name: Deduplicate values from /etc/systemd/journald.conf
    lineinfile:
      path: /etc/systemd/journald.conf
      create: true
      regexp: ^\s*ForwardToSyslog=
      state: absent
    when: dupes.found is defined and dupes.found > 1

  - name: Insert correct line to /etc/systemd/journald.conf
    lineinfile:
      path: /etc/systemd/journald.conf
      create: true
      regexp: ^\s*ForwardToSyslog=
      line: ForwardToSyslog=yes
      state: present
      insertbefore: ^# ForwardToSyslog
      validate: /usr/bin/bash -n %s
  tags:
  - low_complexity
  - low_disruption
  - medium_severity
  - no_reboot_needed
  - r31_check_frwrd_to_syslog
  - restrict_strategy
Group   Network Security   Group contains 5 rules
[ref]  

Rule   Implement DNSSEC   [ref]

Implement Domain Name System Security Extensions (DNSSEC) to digitally sign DNS records and protect their integrity.
Rationale:
DNSSEC provides cryptographic validation of DNS responses, ensuring the integrity and authenticity of name resolution. Enabling and verifying DNSSEC support helps prevent DNS spoofing, cache-poisoning, and man-in-the-middle attacks, reducing the risk of traffic redirection and unauthorized access caused by compromised or malicious DNS responses.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r19_implement_dnssec
Identifiers and References

Rule   Ensure ICMP redirects are not accepted   [ref]

Configure the system to ignore ICMP redirect messages in order to prevent malicious modification of the system routing table. Disabling acceptance of ICMP redirects ensures that network traffic cannot be redirected to attacker-controlled routes. To persistently disable ICMP redirect acceptance, set the following parameters in /etc/sysctl.conf or a file in /etc/sysctl.d/:
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
Apply the active kernel parameter settings by running the following commands:
# sysctl -w net.ipv4.conf.all.accept_redirects=0
# sysctl -w net.ipv4.conf.default.accept_redirects=0
# sysctl -w net.ipv6.conf.all.accept_redirects=0
# sysctl -w net.ipv6.conf.default.accept_redirects=0
# sysctl -w net.ipv4.route.flush=1
# sysctl -w net.ipv6.route.flush=1
Rationale:
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.
This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless absolutely required."
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r20_check_icmp_redirects
Identifiers and References

References:  1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9, 5.10.1.1, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06, 3.1.20, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3. 6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2. 6, SR 2.7, SR 6.2, SR 7.1, SR 7.2, SR 7.6, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2, CM-7(a), CM-7(b), CM-6(a), SC-7(a), DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3, SRG-OS-000480-GPOS-00227

Rule   Disable Kernel Parameter for Accepting Secure ICMP Redirects on all IPv4 Interfaces   [ref]

Protect the system from receiving updates to its routing table from known but potentially compromised gateways by disabling secure ICMP redirect acceptance. This ensures the system maintains control over its routing configuration and reduces the risk of man-in-the-middle attacks. Configure the following kernel parameters to disable secure redirects: net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 These settings should be applied in /etc/sysctl.conf or files under /etc/sysctl.d/.
Rationale:
Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r21_secure_icmp_redirects
Identifiers and References

References:  1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, 3.1.20, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-7(a), CM-7(b), CM-6(a), SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, Req-1.4.3, SRG-OS-000480-GPOS-00227

Rule   Disable Accepting IPv6 Router Advertisements on All Interfaces and by Default   [ref]

IPv6 router advertisements can be used to influence host routing behavior. Configure the system to not accept router advertisements on all IPv6 interfaces and to disable acceptance by default for newly created interfaces. Set the following sysctl options to 0: net.ipv6.conf.all.accept_ra = 0 net.ipv6.conf.default.accept_ra = 0
Rationale:
An illicit IPv6 router advertisement could result in a man-in-the-middle attack by redirecting traffic through an unauthorized or compromised gateway. Disabling router advertisement acceptance prevents unauthorized route changes for existing interfaces and ensures the same protection applies to interfaces created in the future.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r22_ensure_ipv6_router_advertisements_are_not_accepted
Identifiers and References

References:  11, 14, 3, 9, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, 3.1.20, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, CM-7(a), CM-7(b), CM-6(a), PR.IP-1, PR.PT-3, SRG-OS-000480-GPOS-00227

Rule   Ensure suspicious packets are logged   [ref]

Enable logging of suspicious network packets to detect spoofed packets, unusual traffic patterns, or attempts to exploit vulnerabilities. Regularly reviewing these logs helps identify potential network threats early and supports timely mitigation. To persistently enable logging of suspicious IPv4 packets, set the following parameters in /etc/sysctl.conf or a file in /etc/sysctl.d/:
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
Apply the active kernel parameter settings by running the following commands:
# sysctl -w net.ipv4.conf.all.log_martians=1
# sysctl -w net.ipv4.conf.default.log_martians=1
# sysctl -w net.ipv4.route.flush=1
Rationale:
The presence of "martian" packets (which have impossible addresses), spoofed packets, unusual traffic patterns, or malformed packets may indicate malicious activity on the network. Logging such packets provides visibility into potential attacks and supports forensic analysis and incident response.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r23_check_log_martians
Identifiers and References

References:  1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.04, DSS03.05, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.06, 3.1.20, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3. 6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2. 6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, A.11.2.6, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.2.1, A.6.2.2, A.9.1.2, CM-7(a), CM-7(b), SC-5(3)(a), DE.CM-1, PR.AC-3, PR.DS-4, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227

Group   Password Policy   Group contains 5 rules
[ref]  

Rule   Ensure PAM Enforces Password Requirements - Minimum Length and Minimum Character Classes   [ref]

The pam_pwquality module parameters minlen and minclass control password strength requirements. The minlen parameter defines the minimum number of characters required for a valid password. Setting minlen=14 enforces a stronger minimum password length. The minclass parameter controls the minimum number of different character classes that must be present in a password. For example, setting minclass=4 requires that a password contain characters from at least four different categories. The available character classes are: - Upper-case characters - Lower-case characters - Digits - Special characters (for example, punctuation) Modify the minlen and minclass settings in /etc/security/pwquality.conf to enforce a minimum password length of 14 characters and require characters from all four categories.
Rationale:
Shorter passwords have fewer possible combinations and are therefore more susceptible to guessing and brute-force attacks. Password complexity, or strength, is a measure of a password’s resistance to compromise. Password length and the use of multiple character classes both significantly increase the size of the search space attackers must exhaust. Requiring longer passwords and multiple character categories increases the time and computational resources needed to crack passwords, reducing the likelihood of successful brute-force or guessing attacks.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r01_pwd_creation
Identifiers and References

References:  1, 12, 15, 16, 5, 5.6.2.1.1, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_SMF_EXT.1, Req-8.2.3, SRG-OS-000078-GPOS-00046

Rule   Limit Password Reuse   [ref]

Enforce a policy preventing users from reusing their last five passwords. This ensures that compromised credentials cannot be reused and applies only to local system accounts. To configure remembered password history, run the following script that will add or modify the pam_pwhistory.so and pam_unix.so lines to include the remember option:
CP=$(authselect current | awk "NR == 1 {print $3}" | grep custom/)
[[ -n $CP ]] && PTF=/etc/authselect/$CP/system-auth || PTF=/etc/authselect/system-auth
[[ -n $(grep -E "^\s*password\s+(sufficient\s+pam_unix|requi(red|site)\s+pam_pwhistory).so\s+ ([^#]+\s+)*remember=\S+\s*.*$" "$PTF") ]] \
&& sed -ri 's/^\s*(password\s+(requisite|sufficient)\s+(pam_pwquality\.so|pam_unix\.so)\s+)(.*)(remember=\S+\s*)(.*)$/\1\4 remember=5 \6/' "$PTF" \
|| sed -ri 's/^\s*(password\s+(requisite|sufficient)\s+(pam_pwquality\.so|pam_unix\.so)\s+)(.*)$/\1\4 remember=5/' "$PTF"
authselect apply-changes
Rationale:
Enforcing a password history policy that prevents the reuse of previous passwords is a critical component of credential security. It mitigates risks associated with predictable or repeated passwords and helps enforce good password hygiene among local system users.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r02_pam_settings_check
Identifiers and References

References:  1, 12, 15, 16, 5, 5.6.2.1.1, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, 3.5.8, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(f), IA-5(1)(e), PR.AC-1, PR.AC-6, PR.AC-7, Req-8.2.5, SRG-OS-000077-GPOS-00045

Rule   Set password expiration to 90 days or less   [ref]

Configure the system to limit the maximum password lifetime to 60 days or less in order to enforce regular credential updates. Shorter password expiration periods reduce the amount of time a compromised password remains valid. To configure the default maximum password age for newly created user accounts, edit the /etc/login.defs file and set the PASS_MAX_DAYS parameter to 60:
PASS_MAX_DAYS 60
       
Note that changes made to /etc/login.defs only apply to new user accounts. For existing user accounts, enforce the maximum password lifetime restriction by running the following command:
$ sudo chage --maxdays 60
        USER
       
Rationale:
Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r03_check_psswd_life
Identifiers and References

References:  IA-5(f), IA-5(1)(d), CM-6(a), SRG-OS-000076-GPOS-00044

Rule   Set minimum days between password changes to 7 or more   [ref]

Restrict frequent password changes to prevent users from cycling through old credentials, ensuring adherence to password history policies. To change the number of days a password must be active before it can be changed by a user:
  1. In /etc/login.defs, set the PASS_MIN_DAYS parameter to 7:

    PASS_MIN_DAYS 7

    Note that changes made to /etc/login.defs affect only new users.

  2. For existing users, modify minimum days between password changes by running:

    # chage --mindays 7 <user>
Rationale:
Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.

Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r04_pwd_chng_interval
Identifiers and References

References:  1, 12, 15, 16, 5, 5.6.2.1.1, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, 3.5.8, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0418, 1055, 1402, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(f), IA-5(1)(d), CM-6(a), PR.AC-1, PR.AC-6, PR.AC-7, SRG-OS-000075-GPOS-00043

Rule   Set inactive password lock to 30 days or less   [ref]

Disable inactive accounts as they pose a security risk. In certain situations, without monitoring login attempts or any ano malies, such accounts become a prime target for attackers who are willing to gain undetected or unauthorised access. To change the number of days of inactivity after a password has expired before the account is locked:
  1. Set the default password inactivity period to 30 days:

     # useradd -D -f 30

    Note that changes made by useradd affect only new users

  2. For existing users, modify the number of days of inactivity by running:

    # chage --inactive 30 <user> >
Rationale:
Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system. Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r05_check_global_and_user_inactivity
Identifiers and References

References:  1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8, 5.6.2.1.1, DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, 3.5.6, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 6.2, A.12.4.1, A.12.4.3, A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3, IA-4(e), AC-2(3), CM-6(a), DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, Req-8.1.4, SRG-OS-000118-GPOS-00060

Group   Service Security   Group contains 4 rules
[ref]  

Rule   Disable snmpd Service   [ref]

Avoid using SNMPv1, which transmits data in clear text and does not require authentication to execute commands. It is recommended to switch to SNMPv3, which provides improved security features such as authentication and encryption to protect sensitive information from unauthorized access. To disable the SNMP daemon, run: systemctl --now disable snmpd To switch to SNMPv3, update /etc/snmp/snmpd.conf with the following entries: com2sec snmpv3test localhost dummycontext com2sec snmpv3test pan51 dummycontext group snmpv3group usm snmpv3test access snmpv3group "" usm priv exact all all all rouser rousername Then create an SNMPv3 user and restart the SNMP service: systemctl stop snmpd.service net-snmp-create-v3-user systemctl start snmpd.service
Rationale:
Running SNMP software provides a network-based avenue of attack, and should be disabled if not needed.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_r24_snmpd_enabled
Identifiers and References

Rule   Ensure Default SNMP Password Is Not Used   [ref]

If SNMP is required, configure it securely by restricting access to private network interfaces and changing default community strings. Community strings act as passwords for SNMP and should never use default or well-known values. Review the /etc/snmp/snmpd.conf file for configured community strings using the rwcommunity and rocommunity directives and update them as needed. For example: rocommunity somesecom After making changes, restart the SNMP daemon to apply the configuration: systemctl restart snmpd.service
Rationale:
Whether active or not, default Simple Network Management Protocol (SNMP) community strings must be changed to maintain security. If the service is running with default authenticators, an attacker may gather information about the system and network and use it to compromise confidentiality and integrity.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_r25_snmp_community_conf
Identifiers and References

References:  1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(e), PR.AC-1, PR.AC-6, PR.AC-7, SRG-OS-000480-GPOS-00227

Rule   Ensure RPC is not enabled unless absolutely necessary   [ref]

If the system does not require RPC-based services, it is recommended to disable rpcbind to reduce the remote attack surface. To disable rpcbind, run: # systemctl --now disable rpcbind
Rationale:
If the system does not require rpc based services, it is recommended that rpcbind be disabled to reduce the attack surface.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_r26_check_rpc_policy
Identifiers and References

Complexity:low
Disruption:low
Strategy:disable
- name: Ensure RPC is not enabled unless absolutely necessary - Collect systemd Services
    Present in the System
  ansible.builtin.command: systemctl -q list-unit-files --type service
  register: service_exists
  changed_when: false
  failed_when: service_exists.rc not in [0, 1]
  check_mode: false
  tags:
  - disable_strategy
  - low_complexity
  - low_disruption
  - low_severity
  - no_reboot_needed
  - r26_check_rpc_policy

- name: Ensure RPC is not enabled unless absolutely necessary - Ensure "rpcbind.service"
    is Masked
  ansible.builtin.systemd:
    name: rpcbind.service
    state: stopped
    enabled: false
    masked: true
  when: service_exists.stdout_lines is search("rpcbind.service",multiline=True)
  tags:
  - disable_strategy
  - low_complexity
  - low_disruption
  - low_severity
  - no_reboot_needed
  - r26_check_rpc_policy

- name: Unit Socket Exists - rpcbind.socket
  ansible.builtin.command: systemctl -q list-unit-files rpcbind.socket
  register: socket_file_exists
  changed_when: false
  failed_when: socket_file_exists.rc not in [0, 1]
  check_mode: false
  tags:
  - disable_strategy
  - low_complexity
  - low_disruption
  - low_severity
  - no_reboot_needed
  - r26_check_rpc_policy

- name: Disable socket rpcbind
  ansible.builtin.systemd:
    name: rpcbind.socket
    enabled: 'no'
    state: stopped
    masked: 'yes'
  when: socket_file_exists.stdout_lines is search("rpcbind.socket",multiline=True)
  tags:
  - disable_strategy
  - low_complexity
  - low_disruption
  - low_severity
  - no_reboot_needed
  - r26_check_rpc_policy

Complexity:low
Disruption:low
Strategy:enable
include disable_rpcbind

class disable_rpcbind {
  service {'rpcbind':
    enable => false,
    ensure => 'stopped',
  }
}


[customizations.services]
masked = ["rpcbind"]

Rule   Ensure Telnet is not installed   [ref]

Replace Telnet with SSH where possible for encrypted and secure remote communications. The SSH package provides an encrypted session and stronger security communication.
Rationale:
It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities are often overlooked and therefore may remain insecure. They increase the risk to the platform by providing additional attack vectors.
The telnet service provides an unencrypted remote access service which does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to login using this service, the privileged user password could be compromised.
Removing the telnet package decreases the risk of the telnet service's accidental (or intentional) activation.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_r27_telnet_ins_chk
Identifiers and References

References:  11, 12, 14, 15, 3, 8, 9, APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.04, DSS05.02, DSS05.03, DSS05.05, DSS06.06, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, A.11.2.6, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.2.1, A.6.2.2, A.9.1.2, CM-7(a), CM-7(b), CM-6(a), PR.AC-3, PR.IP-1, PR.PT-3, PR.PT-4, Req-2.2.2, SRG-OS-000095-GPOS-00049


Complexity:low
Disruption:low
Strategy:disable

# CAUTION: This remediation script will remove telnet
#	   from the system, and may remove any packages
#	   that depend on telnet. Execute this
#	   remediation AFTER testing on a non-production
#	   system!

if rpm -q --quiet "telnet" ; then

    dnf remove -y "telnet"

fi

Complexity:low
Disruption:low
Strategy:disable
- name: Ensure telnet is removed
  package:
    name: telnet
    state: absent
  tags:
  - NIST-800-53-CM-6(a)
  - NIST-800-53-CM-7(a)
  - NIST-800-53-CM-7(b)
  - PCI-DSS-Req-2.2.2
  - disable_strategy
  - high_severity
  - low_complexity
  - low_disruption
  - no_reboot_needed
  - r27_telnet_ins_chk

Complexity:low
Disruption:low
Strategy:disable
include remove_telnet

class remove_telnet {
  package { 'telnet':
    ensure => 'purged',
  }
}
Group   System Hardening   Group contains 4 rules
[ref]  

Rule   Disable USB storage   [ref]

To restrict USB access on the system to reduce the physical attack surface and prevent unauthorized device connections. Edit or create a configuration file in the /etc/modprobe.d/ directory. For example: # vim /etc/modprobe.d/usb-storage.conf Add the following line: install usb-storage /bin/true Unload the usb-storage module by running: # rmmod usb-storage
Rationale:
USB storage devices such as thumb drives can be used to introduce malicious software.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r11_check_usb_storage
Identifiers and References

References:  1, 12, 15, 16, 5, APO13.01, DSS01.04, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, 3.1.21, 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.310(d)(1), 164.310(d)(2), 164.312(a)(1), 164.312(a)(2)(iv), 164.312(b), 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.6, A.11.2.6, A.13.1.1, A.13.2.1, A.18.1.4, A.6.2.1, A.6.2.2, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, CM-7(a), CM-7(b), CM-6(a), MP-7, PR.AC-1, PR.AC-3, PR.AC-6, PR.AC-7, SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163, SRG-OS-000480-GPOS-00227, SRG-APP-000141-CTR-000315

Rule   Ensure idle shell timeout is 900 seconds or less   [ref]

Setting the TMOUT environment variable in shell profile scripts ensures that unattended shell sessions are automatically terminated after a per iod of inactivity. This reduces the risk of unauthorized access to an idle session. The TMOUT option should be configured in /etc/bashrc, /etc/profile, and any scripts under /etc/profile.d/*.sh (as well as the corresponding files for any other shells in use). The configuration should include the following lines:
readonly TMOUT=900 export TMOUT 
Rationale:
Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r12_tmout_900
Identifiers and References

References:  1, 12, 15, 16, DSS05.04, DSS05.10, DSS06.10, 3.1.11, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, CIP-004-6 R2.2.3, CIP-007-3 R5.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, AC-12, SC-10, AC-2(5), CM-6(a), PR.AC-7, FMT_MOF_EXT.1, SRG-OS-000163-GPOS-00072, SRG-OS-000029-GPOS-00010

Rule   Ensure /tmp is configured   [ref]

Create a separate file system for /tmp with restrictive mount options like noexec to block execution of malicious scripts. Use tmpfs or a dedicated partition for /tmp to mitigate risks from hardlink exploitation and unauthorized script execution.

Configure /etc/fstab appropriately. For example:

tmpfs  /tmp  tmpfs defaults,rw,nosuid,nodev,noexec,relatime  0 0

Alternatively, you can do the following:

Enable systemd /tmp mounting by running:

systemctl unmask tmp.mount
systemctl enable tmp.mount
Rationale:
Mounting /tmp on a separate filesystem with nosuid, nodev, and noexec prevents execution of malicious code and reduces the risk of privilege escalation in a world-writable directory.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r13_tmp_configured
Identifiers and References

Rule   Ensure NTP is configured and in use   [ref]

Redundant configuration of NTP servers ensures consistent and accurate timekeeping across systems, preventing discrepancies that may affect logs, authentication, and clustered services. It is recommended to configure multiple reliable NTP sources to maintain synchronization even if one server becomes unreachable. Configure at least two NTP servers on each system and update /etc/chronyd.conf to remove the default pool entry and specify the desired local servers:
#pool pool.ntp.org iburst
server ntp1.local.example.com
server ntp2.local.example.com
After updating the configuration, restart the chronyd service:
systemctl restart chronyd.service
Rationale:
If chrony is in use on the system proper configuration is vital to ensuring time synchronization is working properly.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_r14_ensure_NTP_conf
Identifiers and References

References:  CM-6(a), AU-8(1)(a), Req-10.4.3, SRG-OS-000355-GPOS-00143

Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.