Guide to the Secure Configuration of Red Hat Enterprise Linux CoreOS 4
with profile DRAFT - BSI APP.4.4. and SYS.1.6This profile defines a baseline that aligns to the BSI (Federal Office for Security Information) IT-Grundschutz Basic-Protection. This baseline implements OS-Level configuration requirements from the following sources: - Building-Block SYS.1.6 Containerisation - Building-Block APP.4.4 Kubernetes THIS DOES NOT INCLUDE REQUIREMENTS FOR A HARDENED LINUX FROM SYS.1.3 LINUX
The SCAP Security Guide Project
https://www.open-scap.org/security-policies/scap-security-guide
https://www.open-scap.org/security-policies/scap-security-guide
This guide presents a catalog of security-relevant
configuration settings for Red Hat Enterprise Linux CoreOS 4. 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
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.
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 Title | DRAFT - BSI APP.4.4. and SYS.1.6 |
|---|---|
| Profile ID | xccdf_org.ssgproject.content_profile_bsi-2022 |
CPE Platforms
- cpe:/o:redhat:enterprise_linux_coreos:4
Revision History
Current version: 0.1.75
- draft (as of 2024-10-22)
Table of Contents
Checklist
| Group Guide to the Secure Configuration of Red Hat Enterprise Linux CoreOS 4 Group contains 5 groups and 4 rules | ||||||||||||||||||||||||||||||||||||||||||||||||
| Group System Settings Group contains 4 groups and 4 rules | ||||||||||||||||||||||||||||||||||||||||||||||||
[ref]
Contains rules that check correct system settings. | ||||||||||||||||||||||||||||||||||||||||||||||||
| Group Network Configuration and Firewalls Group contains 2 groups and 1 rule | ||||||||||||||||||||||||||||||||||||||||||||||||
[ref]
Most systems must be connected to a network of some
sort, and this brings with it the substantial risk of network
attack. This section discusses the security impact of decisions
about networking which must be made when configuring a system.
This section also discusses firewalls, network access controls, and other network security frameworks, which allow system-level rules to be written that can limit an attackers' ability to connect to your system. These rules can specify that network traffic should be allowed or denied from certain IP addresses, hosts, and networks. The rules can also specify which of the system's network services are available to particular hosts or networks. | ||||||||||||||||||||||||||||||||||||||||||||||||
| Group firewalld Group contains 1 group and 1 rule | ||||||||||||||||||||||||||||||||||||||||||||||||
[ref]
The dynamic firewall daemon firewalld provides a
dynamically managed firewall with support for network “zones” to assign
a level of trust to a network and its associated connections and interfaces.
It has support for IPv4 and IPv6 firewall settings. It supports Ethernet
bridges and has a separation of runtime and permanent configuration options.
It also has an interface for services or applications to add firewall rules
directly.
A graphical configuration tool, firewall-config, is used to configure
firewalld, which in turn uses iptables tool to communicate
with Netfilter in the kernel which implements packet filtering.
The firewall service provided by firewalld is dynamic rather than
static because changes to the configuration can be made at anytime and are
immediately implemented. There is no need to save or apply the changes. No
unintended disruption of existing network connections occurs as no part of
the firewall has to be reloaded. | ||||||||||||||||||||||||||||||||||||||||||||||||
| Group Inspect and Activate Default firewalld Rules Group contains 1 rule | ||||||||||||||||||||||||||||||||||||||||||||||||
[ref]
Firewalls can be used to separate networks into different zones
based on the level of trust the user has decided to place on the devices and
traffic within that network. NetworkManager informs firewalld to which
zone an interface belongs. An interface's assigned zone can be changed by
NetworkManager or via the firewall-config tool.
The zone settings in /etc/firewalld/ are a range of preset settings
which can be quickly applied to a network interface. These are the zones
provided by firewalld sorted according to the default trust level of the
zones from untrusted to trusted:
It is possible to designate one of these zones to be the default zone. When interface connections are added to NetworkManager, they are assigned
to the default zone. On installation, the default zone in firewalld is set to
be the public zone.
To find out all the settings of a zone, for example the public zone,
enter the following command as root:
# firewall-cmd --zone=public --list-allExample output of this command might look like the following: # firewall-cmd --zone=public --list-all public interfaces: services: mdns dhcpv6-client ssh ports: forward-ports: icmp-blocks: source-quenchTo view the network zones currently active, enter the following command as root: # firewall-cmd --get-serviceThe following listing displays the result of this command on common Red Hat Enterprise Linux CoreOS 4 system: # firewall-cmd --get-service amanda-client bacula bacula-client dhcp dhcpv6 dhcpv6-client dns ftp high-availability http https imaps ipp ipp-client ipsec kerberos kpasswd ldap ldaps libvirt libvirt-tls mdns mountd ms-wbt mysql nfs ntp openvpn pmcd pmproxy pmwebapi pmwebapis pop3s postgresql proxy-dhcp radius rpc-bind samba samba-client smtp ssh telnet tftp tftp-client transmission-client vnc-server wbem-httpsFinally to view the network zones that will be active after the next firewalld service reload, enter the following command as root: # firewall-cmd --get-service --permanent | ||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||
| Group SELinux Group contains 3 rules | ||||||||||||||||||||||||||||||||||||||||||||||||
[ref]
SELinux is a feature of the Linux kernel which can be
used to guard against misconfigured or compromised programs.
SELinux enforces the idea that programs should be limited in what
files they can access and what actions they can take.
The default SELinux policy, as configured on Red Hat Enterprise Linux CoreOS 4, has been sufficiently developed and debugged that it should be usable on almost any system with minimal configuration and a small amount of system administrator training. This policy prevents system services - including most of the common network-visible services such as mail servers, FTP servers, and DNS servers - from accessing files which those services have no valid reason to access. This action alone prevents a huge amount of possible damage from network attacks against services, from trojaned software, and so forth. This guide recommends that SELinux be enabled using the default (targeted) policy on every Red Hat Enterprise Linux CoreOS 4 system, unless that system has unusual requirements which make a stronger policy appropriate. | ||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||
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.