Add Additional sysctl values for security

Bug #1669739 reported by Luke Hinds
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
Expired
Undecided
Unassigned

Bug Description

The following additions should be added to sysctl [1] to improve security and help meet security compliance standards.

* Disable Core Dumps for SUID programs

    fs.suid_dumpable = 0

Rationale: The core dump of a setuid program is more likely to contain sensitive data, as the program itself runs with greater privileges than the user who initiated execution of the program. Disabling the ability for any setuid program to write a core file decreases the risk of unauthorized access of such data.

* Enable Randomized Layout of Virtual Address Space

    kernel.randomize_va_space = 2

Rationale: Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process's address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to re-purpose it using return oriented programming (ROP) techniques.

* Restrict Access to Kernel Message Buffer

    kernel.dmesg_restrict=1

Rationale: Unprivileged access to the kernel syslog can expose sensitive kernel address information.

* Network sysctl tweaks:

- Disable Kernel Parameter for Sending ICMP Redirects

    net.ipv4.conf.default.send_redirects = 0
    net.ipv4.conf.all.send_redirects = 0

Rationale: An attacker could use a compromised host to send invalid ICMP redirects to other router devices in an attempt to corrupt routing and have users access a system set up by the attacker as opposed to a valid system.

- Disable Kernel Parameter for Accepting ICMP Redirects

    net.ipv4.conf.all.accept_redirects = 0
    net.ipv4.conf.default.accept_redirects = 0

Rationale: Attackers could use bogus ICMP redirect messages to maliciously alter the system routing tables and get them to send packets to incorrect networks and allow your system packets to be captured.

- Disable Kernel Parameter for secure ICMP Redirects

    net.ipv4.conf.default.secure_redirects = 0
    net.ipv4.conf.all.secure_redirects = 0

Rationale: Secure ICMP redirects are the same as ICMP redirects, except they come from gateways listed on the default gateway list. It is assumed that these gateways are known to your system, and that they are likely to be secure.

- Enable Kernel Parameter to log suspicious packets by Default

    net.ipv4.conf.default.log_martians = 1
    net.ipv4.conf.all.log_martians = 1

Rationale: Enabling this feature and logging these packets allows an administrator to investigate the possibility that an attacker is sending spoofed packets to their system.

- Ensure source routed packets are not accepted

net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

Rationale: Setting net.ipv4.conf.all.accept_source_route and
net.ipv4.conf.default.accept_source_route to 0 disables the system from accepting source routed packets. Assume this system was capable of routing packets to Internet routable addresses on one interface and private addresses on another interface. Assume that the private addresses were not routable to the Internet routable addresses and vice
versa. Under normal routing circumstances, an attacker from the Internet routable addresses could not use the system as a way to reach the private address systems. If, however, source routed packets were allowed, they could be used to gain access to the private address systems as the route could be specified, rather than rely on routing protocols that did not allow this routing.

- Ensure broadcast ICMP requests are ignored

net.ipv4.icmp_echo_ignore_broadcasts = 1

Rationale: Accepting ICMP echo and timestamp requests with broadcast or multicast destinations for your network could be used to trick your host into starting (or participating) in a Smurf
attack. A Smurf attack relies on an attacker sending large amounts of ICMP broadcast messages with a spoofed source address. All hosts receiving this message and responding would send echo-reply messages back to the spoofed address, which is probably not routable. If many hosts respond to the packets, the amount of traffic on the network could be significantly multiplied.

- Ensure bogus ICMP responses are ignored

net.ipv4.icmp_ignore_bogus_error_responses = 1

Rationale: Some routers (and some attackers) will send responses that violate RFC-1122 and attempt to fill up a log file system with many useless error messages.

Ensure Reverse Path Filtering is enabled

net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

Rationale: Setting these flags is a good way to deter attackers from sending your system bogus packets that cannot be responded to. One instance where this feature breaks down is if asymmetrical routing is employed. This would occur when using dynamic routing protocols
(bgp, ospf, etc) on your system. If you are using asymmetrical routing on your system, you will not be able to enable this feature without breaking the routing.

- Ensure TCP SYN Cookies is enabled

net.ipv4.tcp_syncookies = 1

Rationale: Attackers use SYN flood attacks to perform a denial of service attacked on a system by sending many SYN packets without completing the three way handshake. This will quickly use up slots in the kernel's half-open connection queue and prevent legitimate connections from succeeding. SYN cookies allow the system to keep accepting valid connections, even if under a denial of service attack.

- Ensure IPv6 redirects are not accepted by Default

net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

Rationale: It is recommended that systems not accept ICMP redirects as they could be tricked into routing traffic to compromised machines. Setting hard routes within the system (usually a single default route to a trusted router) protects the system from bad routes.

- Disable Source-Routed Packets

net.ipv6.conf.default.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

Rationale: see ipv4 source-routed packets

- Ensure IPv6 is disabled

options ipv6 disable=1

Rationale: If IPv6 is not to be used, it is recommended that it be disabled to reduce the attack surface of the system.

[1] https://github.com/openstack/tripleo-heat-templates/blob/1fcae324219a77d74fa12fb9eaac400a0658cac4/puppet/services/kernel.yaml

Luke Hinds (lhinds)
description: updated
description: updated
Luke Hinds (lhinds)
description: updated
Luke Hinds (lhinds)
description: updated
Revision history for this message
Alex Schultz (alex-schultz) wrote :

Just an FYI but there's a problem with disabling ipv6 and wanting to set net.ipv6.* options. If you disable ipv6, the sysctl module fails because the ipv6 options are not available to be changed. We've run into this on the undercloud. So we'll probably want to make ipv6 configurable and only set those options if ipv6 is enabled.

Revision history for this message
Luke Hinds (lhinds) wrote :

Thanks Alex, good tip off. So will make sure there is a conditional to verify its main sate before setting any related ipv6 options.

Changed in tripleo:
milestone: pike-1 → pike-2
Changed in tripleo:
milestone: pike-2 → pike-3
Changed in tripleo:
milestone: pike-3 → pike-rc1
Changed in tripleo:
milestone: pike-rc1 → pike-rc2
Changed in tripleo:
milestone: pike-rc2 → queens-1
Changed in tripleo:
milestone: queens-1 → queens-2
Changed in tripleo:
milestone: queens-2 → queens-3
Mike Fedosin (mfedosin)
Changed in tripleo:
assignee: nobody → Mike Fedosin (mfedosin)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to tripleo-heat-templates (master)

Fix proposed to branch: master
Review: https://review.openstack.org/531210

Changed in tripleo:
status: Triaged → In Progress
tags: added: pike-backport-potential
Changed in tripleo:
milestone: queens-3 → queens-rc1
Changed in tripleo:
milestone: queens-rc1 → rocky-1
Changed in tripleo:
milestone: rocky-1 → rocky-2
Changed in tripleo:
milestone: rocky-2 → rocky-3
Changed in tripleo:
milestone: rocky-3 → rocky-rc1
Changed in tripleo:
status: In Progress → Triaged
assignee: Mike Fedosin (mfedosin) → nobody
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on tripleo-heat-templates (master)

Change abandoned by Alex Schultz (<email address hidden>) on branch: master
Review: https://review.openstack.org/531210
Reason: Abandoning this patch per the TripleO Patch Abandonment guidelines (https://specs.openstack.org/openstack/tripleo-specs/specs/policy/patch-abandonment.html). If you wish to have this restored and cannot do so yourself, please reach out via #tripleo on freenode or the OpenStack Dev mailing list.

Changed in tripleo:
milestone: rocky-rc1 → stein-1
Changed in tripleo:
milestone: stein-1 → stein-2
Revision history for this message
Emilien Macchi (emilienm) wrote : Cleanup EOL bug report

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (FUTURE, PIKE, QUEENS, ROCKY, STEIN).
  Valid example: CONFIRMED FOR: FUTURE

Changed in tripleo:
importance: High → Undecided
status: Triaged → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.