1 .. _security_considerations:
3 ***********************
4 Security Considerations
5 ***********************
7 This document discusses the various security issues that might affect
8 OpenDaylight. The document also lists specific recommendations to
9 mitigate security risks.
11 This document also contains information about the corrective steps
12 you can take if you discover a security issue with
13 OpenDaylight, and if necessary, contact the Security Response Team,
14 which is tasked with identifying and resolving security threats.
16 Overview of OpenDaylight Security
17 =================================
19 There are many different kinds of security vulnerabilities that could affect
20 an OpenDaylight deployment, but this guide focuses on those where (a) the
21 servers, virtual machines or other devices running OpenDaylight have been
22 properly physically (or virtually in the case of VMs) secured against untrusted
23 individuals and (b) individuals who have access, either via remote logins or
24 physically, will not attempt to attack or subvert the deployment intentionally
27 While those attack vectors are real, they are out of the scope of this
30 What remains in scope is attacks launched from a server, virtual machine, or
31 device other than the one running OpenDaylight where the attack does not have
32 valid credentials to access the OpenDaylight deployment.
34 The rest of this document gives specific recommendations for deploying
35 OpenDaylight in a secure manner, but first we highlight some high-level
36 security advantages of OpenDaylight.
38 * Separating the control and management planes from the data plane (both
39 logically and, in many cases, physically) allows possible security threats to
40 be forced into a smaller attack surface.
42 * Having centralized information and network control gives network
43 administrators more visibility and control over the entire network, enabling
44 them to make better decisions faster. At the same time,
45 centralization of network control can be an advantage only if access to that
48 .. note:: While both previous advantages improve security, they also make
49 an OpenDaylight deployment an attractive target for attack making
50 understanding these security considerations even more important.
52 * The ability to more rapidly evolve southbound protocols and how they are used
53 provides more and faster mechanisms to enact appropriate security mitigations
56 * OpenDaylight is built from OSGi bundles and the Karaf Java container. Both
57 Karaf and OSGi provide some level of isolation with explicit code boundaries,
58 package imports, package exports, and other security-related features.
60 * OpenDaylight has a history of rapidly addressing known vulnerabilities and
61 a well-defined process for reporting and dealing with them.
63 OpenDaylight Security Resources
64 ===============================
66 * If you have any security issues, you can send a mail to
67 *security@lists.opendaylight.org*.
69 * For the list of current OpenDaylight security issues that are either being
70 fixed or resolved, refer to
71 https://wiki.opendaylight.org/view/Security:Advisories.
73 * To learn more about the OpenDaylight security issues policies and procedure,
74 refer to https://wiki.opendaylight.org/view/Security:Main
76 .. _security_deployment_recommendations:
78 Deployment Recommendations
79 ==========================
81 We recommend that you follow the deployment guidelines in setting up
82 OpenDaylight to minimize security threats.
84 * The default credentials should be changed before deploying OpenDaylight.
86 * OpenDaylight should be deployed in a private network that cannot be accessed
89 * Separate the data network (that connects devices using the network) from the
90 management network (that connects the network devices to OpenDaylight).
92 .. note:: Deploying OpenDaylight on a separate, private management network does not
93 eliminate threats, but only mitigates them. By construction, some
94 messages must flow from the data network to the management network, e.g.,
95 OpenFlow *packet_in* messages, and these create an attack surface even if
98 * Implement an authentication policy for devices that connect to both the data
99 and management network. These are the devices which bridge, likely untrusted,
100 traffic from the data network to the management network.
102 Securing OSGi bundles
103 =====================
105 OSGi is a Java-specific framework that improves the way that Java classes
106 interact within a single JVM. It provides an enhanced version of the
107 *java.lang.SecurityManager* (ConditionalPermissionAdmin) in terms of security.
109 Java provides a security framework that allows a security policy to grant
110 permissions, such as reading a file or opening a network connection, to
111 specific code. The code maybe classes from the jarfile loaded from a specific
112 URL, or a class signed by a specific key. OSGi builds on the standard Java
113 security model to add the following features:
115 * A set of OSGi-specific permission types, such as one that grants the right
116 to register an OSGi service or get an OSGi service from the service registry.
118 * The ability to dynamically modify permissions at runtime. This includes the
119 ability to specify permissions by using code rather than a text configuration
122 * A flexible predicate-based approach to determining which rules are
123 applicable to which *ProtectionDomain*. This approach is much more powerful
124 than the standard Java security policy which can only grant rights based on a
125 jarfile URL or class signature. A few standard predicates are provided,
126 including selecting rules based upon bundle symbolic-name.
128 * Support for bundle *local permissions* policies with optional further
129 constraints such as *DENY* operations. Most of this functionality is accessed
130 by using the *OSGi ConditionalPermissionAdmin* service which is part of the
131 OSGi core and can be obtained from the OSGi service registry. The
132 *ConditionalPermissionAdmin* API replaces the earlier *PermissionAdmin* API.
134 For more information, refer to http://www.osgi.org/Main/HomePage.
136 Securing the Karaf container
137 ============================
139 Apache Karaf is a OSGi-based runtime platform which provides a lightweight
140 container for OpenDaylight and applications. Apache Karaf uses
141 either Apache Felix Framework or Eclipse Equinox OSGi frameworks, and provide
142 additional features on top of the framework.
144 Apache Karaf provides a security framework based on Java Authentication and
145 Authorization Service (JAAS) in compliance with OSGi recommendations,
146 while providing RBAC (Role-Based Access Control) mechanism for the console and
147 Java Management Extensions (JMX).
149 The Apache Karaf security framework is used internally to control the access
150 to the following components:
160 The remote management capabilities are present in Apache Karaf by default,
161 however they can be disabled by using various configuration alterations. These
162 configuration options may be applied to the OpenDaylight Karaf distribution.
164 .. note:: Refer to the following list of publications for more information on
165 implementing security for the Karaf container.
167 * For role-based JMX administration, refer to
168 http://karaf.apache.org/manual/latest/users-guide/monitoring.html.
170 * For remote SSH access configuration, refer to
171 http://karaf.apache.org/manual/latest/users-guide/remote.html.
173 * For WebConsole access, refer to
174 http://karaf.apache.org/manual/latest/users-guide/webconsole.html.
176 * For Karaf security features, refer to
177 http://karaf.apache.org/manual/latest/developers-guide/security-framework.html.
179 Disabling the remote shutdown port
180 ----------------------------------
182 You can lock down your deployment post installation. Set
183 ``karaf.shutdown.port=-1`` in ``etc/custom.properties`` or ``etc/config.properties`` to
184 disable the remote shutdown port.
186 Securing Southbound Plugins
187 ===========================
189 Many individual southbound plugins provide mechanisms to secure their
190 communication with network devices. For example, the OpenFlow plugin supports
191 TLS connections with bi-directional authentication and the NETCONF plugin
192 supports connecting over SSH. Meanwhile, the Unified Secure Channel plugin
193 provides a way to form secure, remote connections for supported devices.
195 When deploying OpenDaylight, you should carefully investigate the secure
196 mechanisms to connect to devices using the relevant plugins.
198 Securing OpenDaylight using AAA
199 ===============================
201 AAA stands for Authentication, Authorization, and Accounting. All three of
202 can help improve the security posture of and OpenDaylight deployment. In this
203 release, only authentication is fully supported, while authorization is an
204 experimental feature and accounting remains a work in progress.
206 The vast majority of OpenDaylight's northbound APIs (and all RESTCONF APIs) are
207 protected by AAA by default when installing the +odl-restconf+ feature. In the
208 cases that APIs are *not* protected by AAA, this will be noted in the
209 per-project release notes.
211 By default, OpenDaylight has only one user account with the username and
212 password *admin*. This should be changed before deploying OpenDaylight.
214 Security Considerations for Clustering
215 ======================================
217 While OpenDaylight clustering provides many benefits including high
218 availability, scale-out performance, and data durability, it also opens a new
219 attack surface in the form of the messages exchanged between the various
220 instances of OpenDaylight in the cluster. In the current OpenDaylight release,
221 these messages are neither encrypted nor authenticated meaning that anyone with
222 access to the management network where OpenDaylight exchanges these clustering
223 messages can forge and/or read the messages. This means that if clustering is
224 enabled, it is even more important that the management network be kept secure
225 from any untrusted entities.