1# Network Security Considerations
2
3This describes network services provided by OpenBMC-based systems,
4some threats the BMC faces from its network interfaces, and steps
5OpenBMC takes to address these threats.
6
7This is only intended to be a guide; security is ultimately the
8responsibility of projects which choose to incorporate OpenBMC into
9their project.  If you find a security vulnerability, please
10consider [how to report a security vulnerability][].
11
12[how to report a security vulnerability]: https://github.com/openbmc/docs/blob/master/security/how-to-report-a-security-vulnerability.md
13
14Threats to the BMC are classified using the [CIA triad][].  All threat
15types are significant; here is an example of each:
16 - Confidentiality: If an attacker can get data from the BMC, they may
17   be able to chain other vulnerabilities to establish a covert
18   information channel to get sensitive information from the host.
19 - Integrity: If an attacker can modify BMC settings or data, they may
20   be able to gain additional access, and launch more attacks.
21 - Availability: If an agent can overwhelm the BMC's resources, either
22   by accident or on purpose, the BMC will not be available to service
23   its host (denial of service).
24
25[CIA triad]: https://en.wikipedia.org/wiki/Information_security#Key_concepts
26
27This document is organized by how OpenBMC services connect to the
28network.  The general flow is:
29 - The BMC is presumed to have a network adapter.  The security
30   considerations of the NIC are important to the BMC security, but
31   are outside the scope of this document.
32 - Network traffic then flows through the kernel, detailed below.
33 - Finally, connections flow to various OpenBMC services.
34
35OpenBMC provides services on TCP and UDP ports.  For example, the
36HTTPS protocol on port 443 is used to provide REST APIs and serve Web
37applications.  These services are detailed below.  Implicit is that
38all other ports are inactive.
39
40OpenBMC also initiates network communications, for example, NTP, LDAP,
41etc.  These are covered with their associated functions.
42
43
44## Kernel and ICMP messages
45
46Network traffic is handled by the Linux kernel.  The exact kernel and
47device driver have security considerations which are important to BMC
48security, but are better addressed by the Linux kernel community.
49You can learn which kernel and patches are used from the kernel
50recipes typically found in the board support packages for the BMC
51referenced by your machine's configuration.  For example, in the
52`https://github.com/openbmc/meta-aspeed` repository under
53`recipes-kernel/linux/linux-aspeed_git.bb`.
54
55Per [CVE 1999-0524][], responding to certain ICMP packets can give an
56attacker more information about the BMC's clock or subnet, which can
57help with subsequent attacks.  OpenBMC responds to all ICMP requests.
58
59[CVE 1999-0524]: https://nvd.nist.gov/vuln/detail/CVE-1999-0524
60
61General considerations for ICMP messages apply.  For example, packet
62fragmentation and packet flooding vulnerabilities.
63
64It is sometimes useful to filter and log network messages for debug and
65other diagnostic purposes.  OpenBMC provides no support for this.
66
67
68## General considerations for services
69
70Several services perform user identification and authentication:
71 - Phosphor REST APIs
72 - Redfish REST API SessionService
73 - Network IPMI
74 - SSH secure shell
75
76OpenBMC's [phosphor-user-manager][] provides the underlying
77authentication and authorization functions and ties into IPMI, Linux
78PAM, LDAP, and logging.  Some of OpenBMC services use phosphor-user-manager.
79
80[phosphor-user-manager]: https://github.com/openbmc/docs/blob/master/architecture/user-management.md
81
82Transport layer security (TLS) protocols are configured for each
83service at compile time, become part of the image, and cannot be
84changed dynamically.  The protocols which use TLS include:
85 - RAKP for IPMI.
86 - SSH for ssh and scp.
87 - HTTPS for Web and REST APIs.
88
89Automated network agents (such as hardware management consoles) may
90malfunction in a way that the BMC continuously gets authentication
91failures, which may lead to denial of service.  For example, a brief
92delay before reporting the failure, for example, of one second, may
93help prevent this problem or lessen its severity.  See [OWASP Blocking
94Brute Force Attacks][].
95
96[OWASP Blocking Brute Force Attacks]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
97
98Network agents may fail to end a session properly, which causes the
99service to use resources to keep track of orphaned sessions.  To help
100prevent this, services may limit the maximum number of concurrent
101sessions, or have a session inactivity timeout.
102
103Services which are not required should be disabled to limit the BMC's
104attack surface.  For example, a large scale data center may not need a
105Web interface.  Services can be disabled in several ways:
106 1. Configure OpenBMC recipes to build the unwanted feature out of the
107    BMC's firmware image.  This gives the BMC the advantage of a
108    smaller attack surface.
109 2. Implement something like the [Redfish ManagerNetworkProtocol][]
110    properties for IPMI, SSH, and other BMC services, possibly by
111    using shell commands like 'systemctl disable ipmid' and 'systemctl
112    stop ipmid'.
113
114[Redfish ManagerNetworkProtocol]: https://redfish.dmtf.org/schemas/ManagerNetworkProtocol.v1_4_0.json
115
116Network services should log all authentication attempts with their
117outcomes to satisfy basic monitoring and forensic analysis
118requirements.  For example, as part of a real-time monitoring service,
119or to answer who accessed which services at what times.
120
121OpenBMC does not have a firewall.
122
123Laws may require products built on OpenBMC to have reasonable security
124built into them, for example, by not having a default password.  See,
125for example, [CA Law SB-327].
126
127[CA Law SB-327]: https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201720180SB327
128
129## Services provided on TCP and UDP ports
130
131### TCP port 22 - Secure Shell (SSH) access to the BMC
132
133The Secure Shell (SSH) protocol is provided, including secure shell
134(ssh command) access to the BMC's shell, and secure copy (scp command)
135to the BMC's file system.
136
137The default SSH server implementation is provided by Dropbear.
138All configuration is at compile-time with defaults for:
139 - Authentication provided by Linux PAM, where methods include
140   username and password, and SSH certificates (the `ssh-keygen`
141   command).
142 - Transport layer security (TLS) protocols offered.
143
144SSH access to the BMC's shell is not the intended way to operate the
145BMC, gives the operator more privilege than is needed, and may not be
146allowed on BMCs which service hosts that process sensitive data.
147However, BMC shell access may be needed to provision the BMC or to
148help diagnose problems during its operation.
149
150
151### TCP port 443 - HTTPS REST APIs and Web application
152
153BMCWeb is the Web server for:
154 - The Redfish REST APIs.
155 - The webui-vue Web interface.
156 - The Phosphor D-Bus REST interface.
157And initiates WebSockets for:
158 - Host KVM.
159 - Virtual media.
160 - Host serial console.
161
162The [BMCWeb configuration][] controls which services are provided.
163
164General security considerations for HTTP servers apply such as given
165by [OWASP Application Security][].
166
167BMCWeb controls which HTTPS transport layer security (TLS) ciphers it
168offers via compile-time header file `include/ssl_key_handler.hpp` in
169the https://github.com/openbmc/bmcweb repository.  The implementation
170is provided by OpenSSL.
171
172BMCWeb provides appropriate HTTP response headers, for example, in
173header file `include/security_headers_middleware.hpp` and
174`crow/include/crow/websocket.h` in the
175https://github.com/openbmc/bmcweb repository.
176
177[BMCWeb configuration]: https://github.com/openbmc/bmcweb#configuration
178[OWASP Application Security]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
179
180#### REST APIs
181
182BMCWeb offers three authentication methods:
183
184 1. The Redfish SessionService, which takes a username and password
185    and provides an X-Auth token.
186 2. The Phosphor D-Bus REST interface '/login' URI, which takes a
187    username and password and provides a session cookie.  This method
188    is deprecated in OpenBMC.
189 3. Basic Access Authentication, which takes a username and password
190    (often URL encoded like https://user:pass@host/...) in an
191    "Authorization" request header, and returns no credentials.  This
192    method is deprecated by RFC 3986.
193
194The username and password are presented to phosphor-user-manager for
195authentication.
196
197The first two methods create the same kind of session but return
198different credentials.  For example, you can create a Redfish session,
199and use your credentials to invoke Phosphor D-Bus REST APIs.  Note,
200however, that the X-Auth tokens are required to use POST, PUT, PATCH,
201or DELETE methods.
202
203General security considerations for REST APIs apply:
204https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md
205
206Redfish provides security considerations in the "Security Detail"
207section of the "Redfish Specification" (document ID DSP0266) available
208from https://www.dmtf.org/standards/redfish.
209
210#### The webui-vue Web application
211
212General considerations for Web applications such as given by [OWASP
213Web Application Security Guidance][] apply to OpenBMC.  The
214webui-vue uses username and password-based authentication, and
215REST APIs for subsequent access.
216
217[OWASP Web Application Security Guidance]: https://www.owasp.org/index.php/Web_Application_Security_Guidance
218
219The web app also provides interfaces to use the host serial console,
220virtual media, and host KVM.
221
222### TCP port 2200
223
224Access to the BMC's [host serial console][] is provided via the SSH
225protocol on port 2200.
226
227[host serial console]: https://github.com/openbmc/docs/blob/master/console.md
228
229This uses the same server implementation as port 22, including the
230same TLS mechanisms.
231
232How the host secures its console (for example, username and password
233prompts) is outside the scope of this document.
234
235### TCP and UDP ports 5355 - mDNS service discovery
236
237General security considerations for service discovery apply.  For
238example, described here: https://attack.mitre.org/techniques/T1046/
239
240### UDP port 427 - SLP, Avahi
241
242General security considerations for service discovery apply.
243
244### UDP port 623 - IPMI RCMP
245
246The IPMI network-facing design is described here:
247https://github.com/openbmc/docs/blob/master/architecture/ipmi-architecture.md and
248the implementation is described here:
249https://github.com/openbmc/phosphor-net-ipmid.
250Note that host IPMI is outside the scope of this document.
251
252General security considerations for IPMI apply.  For example,
253described here: https://www.us-cert.gov/ncas/alerts/TA13-207A
254
255OpenBMC implements RCMP+ and IPMI 2.0.  The phosphor-user-manager
256provides the underlying authentication mechanism.
257
258Supported IPMI ciphers can be found in the code, for example, by
259searching for function `isAlgorithmSupported`, or from the `ipmitool`
260command such as `ipmitool channel getciphers ipmi`.
261
262OpenBMC supports IPMI "serial over LAN" (SOL) connections (via
263`impitool sol activate`) which shares the host serial console socket.
264