manuals/getting-started-guide/src/main/asciidoc/chapter_security_considerations.adoc

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