[Design] Kernel-based BMC firewall
Joseph Reynolds
jrey at linux.ibm.com
Sat Mar 2 08:31:12 AEDT 2019
Here is my BMC firewall design. I'll post it as a gerrit docs review in
a few days if nobody steers this in a different direction.
Highlights:
- firewall established by default when networking starts
- BMC-specific firewall rules to be documented
- firewall logging not started by default
Enjoy,
- Joseph Reynolds
# Firewall
Author:
Joseph Reynolds <josephreynolds1>
Primary assignee:
< Name and/or IRC nic or None >
Other contributors:
< Name and/or IRC nic or None >
Created:
2019-03-01
## Problem Description
OpenBMC needs an integral firewall to monitor and control its IP
traffic.
## Background and References
The Yocto/OpenEmbedded projects offer ready-made Linux kernel-based
firewall recipes. These are based on:
- the Linux `netfilter` kernel modules which provide the basic
capability
to work with IP packets.
- the `iptables` Linux command (and similar commands like ip6tables)
work
with netfilter tables
- the `arno-iptables-firewall` package which provides shell scripts
that
uses iptables to establish a firewall.
- the `ulogd` firewall logger package
References:
- The Linux firewall documentation:
http://linuxdocs.org/HOWTOs/Firewall-HOWTO-2.html
- Basic concepts from Wikipedia:
- https://en.wikipedia.org/wiki/Netfilter
- https://en.wikipedia.org/wiki/Iptables
- The OpenEmbedded recipes for firewalls:
http://layers.openembedded.org/layerindex/branch/master/recipes/?q=iptables
- Log connections via ulogd.
## Requirements
The BMC must automatically establish a firewall when the network
service is started, and remove it when networking stops. The firewall
rules must have reasonable defaults for a BMC.
The firewall must have these capabilities:
1. Block unauthorized IP traffic to and from the BMC.
2. Block malicious packets.
3. Log network traffic.
4. Rate-limiting to thwart denial of service attacks.
The firewall must not:
- Consume excessive CPU cycles.
- Consume excessive space in memory or on disk.
The system integrator must be able to:
- Establish firewall rules to implement security policy.
- Set default IP logging behavior.
- Configure the firewall for IPv4, IPv6, or both.
- Remove firewall capabilty from the BMC if desired.
The admin user must be able to:
- Temporarily modify, disable, or re-enable the firewall.
- Enable or disable IP logging.
- Retrieve the firewall logs, if enabled.
## Proposed Design
This adds a set of BitBake recipes to set up an IP firewall based on
Linux kernel netfilter modules, the iptables commands, and the
arno-iptables-firewall package.
The firewall gets put up when systemd starts the networking service, and
gets taken down when networking stops.
The firewall logging service is also made available, but it is not
started
The firewall rules will default to disallow all IP traffic, then be
permissive in allowing all legitimate BMC traffic. We'll have
customized firewall rules specific to a generic BMC environment and
document these rules in the docs repository.
These rules are intended to be "secure by design" and documented well
enough for a system integrator to change them as needed.
## Alternatives Considered
A user interface to indicate the firewall's status was considered.
This would invoke iptables and return success only if it showed
firewall rules, something like `iptables -L -n -v`. This is not
needed for basic function.
The `ufw` firewall was considered. It is implemented in Python which
is being removed from the OpenBMC image.
## Impacts
There are three levels of impact:
1. If the firewall recipes are present:
- Uses more flash space for kernel modules and iptables commands.
2. When the firewall is enabled:
- Uses more memory for kernel modules and related tables.
- Uses more CPU cycles for network service.
3. When the firewall IP logging service is enabled:
- Uses more resources for CPU and log file storage.
If the firewall rules are overly restrictive, functions which require
IP may not work correctly. The documentation must show how to
identify and fix this problem, specifically:
- How to enable IP logging.
- How to find, read, and interpret the log.
- How to change firewall rules to allow your traffic.
## Testing
Ensure all functions which use IP continue to work. Enable firewall
IP logging during these tests, and check it for errors.
From the requirement section:
- Test the firewall's capabilities. For example:
- Send badly formed packets.
- Send traffic to closed ports.
- Test each of the admin user's functions.
Test the procedure to enable logging and detect blocked IP traffic.
Note the recommended dev-environment [1] maps TCP ports 22 and 443 (to
ports 2222 and 2443). This is not an issue for the BMC's firewall
because this mapping is done by the simulator, so the BMC sees the
original port numbers: 22 and 443.
[1]:
https://github.com/openbmc/docs/blob/master/development/dev-environment.md
More information about the openbmc
mailing list