The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The following topics describe the security measures that Open SDN Controller implements:
There are three levels of security built into Open SDN Controller: OS-level security, application-level security, and API-level security. This topic covers the security measures that are in place for each of these levels and describes any potential vulnerabilities that you should be aware of.
At the OS level, there are two main attack vectors: VM console access and SSH access. Console access is subject to VMware security measures and assumes that the client is following the guidelines VMware recommends to secure your VM console. SSH access is protected because root logins are not allowed and SSH access is disabled for all users except the sysadmin user (a user with less privileges). In addition, Open SDN Controller forces the sysadmin user to change their password after logging in for the first time and enforces password complexity requirements.
The main security vulnerability at the OS level is that the sysadmin user has sudo privileges. As a result, if the password is ever compromised, that user can get sudo root access to the system.
To address the application attack vector, Open SDN Controller redirects all HTTP traffic from port 80 to port 443, which is configured to use HTTPS to handle data. The controller also uses HTTPS to encrypt all passwords.
The main security vulnerability at the application level is that user passwords are stored in Open SDN Controller’s database, meaning that the controller and user passwords reside in the same location.
At the API level, Open SDN Controller uses HTTPS to handle HTTP traffic. It also minimizes password exposure in API calls by generating a token hash of the password for every call that is made. As a result, REST API calls and the password are not stored together.
Open SDN Controller supports the use of your company’s Lightweight Directory Access Protocol (LDAP) server for authentication. To enable this functionality, complete the following procedure.
In OSC 1.1, you can configure a RADIUS server to implement AAA authentication. There are a number of commercial and open source RADIUS servers available for you to choose from. The following topics assume that you are configuring the FreeRadius server.
The RADIUS protocol is based on UDP. Since UDP does not make use of connections, it cannot use SSL or another type of encryption based on TCP connections to handle communications. To work around this, each client that wants to use the RADIUS server for authentication must be predefined and added to the server. In FreeRadius, you accomplish this by updating the clinet.cfg file, which is located in the /etc/freeradius directory.
Note | If you are using the RadiusDesk suite, the directory in which clinet.cfg resides will differ. |
To add a new client, locate the following parameters in the RADIUS server’s client.cfg file and define values for them:
client—client’s hostname
ipaddr—client’s IP address
secret—password-like value assigned to the client
Here is what a sample client configuration looks like. The values you need to specify are italicized:
client cosc-ova-181 { ipaddr = 192.0.2.122 secret = cosc }
The RADIUS configuration file, radius.cfg, is located in the /opt/cisco/controller/etc directory. It is an active file, which means that any changes made to it will automatically be rolled into OSC at runtime. As a result, you do not need to restart the controller after you edit the configuration file.
Here is an example of what the configuration file looks like:
radius-secret=cosc radius-enable=true radius-host=198.51.100.137
where radius-secret indicates the secret you defined for this client, radius-enable indicates whether RADIUS integration has been enabled, and radius-host indicates the RADIUS server’s IP address.
After you have enabled RADIUS, you will be able to log into OSC with any defined RADIUS username and password combination. Note that a local OSC user is created from the RADIUS user and is assigned the User role. If you want to change the RADIUS user’s role to Admin, you need to log into OSC as an admin user and then change that user’s role from the Users page.
Complete the following procedure to set up TLS support on either a Nexus 3000 Series or Catalyst 4000 Series switch.
If your company has a pre-signed certificate file, you can use that instead of the certificate file that comes with Open SDN Controller.Before you complete the following procedure, make sure that your certificate's .crt and .key files are available.
The following table lists the ports used by Open SDN Controller (in both single node and 3-node cluster setups) and their purpose. When viewing this table, note that:
Port Number |
Purpose |
---|---|
22 |
Incoming and outgoing SSH traffic |
53 |
Outbound DNS traffic |
80 |
Incoming HTTP traffic |
123 |
NTP connections |
179 |
Southbound BGP connections |
443 |
Incoming and outgoing HTTPS traffic |
830 |
Southbound NETCONF connections |
1099 |
Remote JMX connections |
4189 |
Southbound PCEP connections |
6633 |
Southbound OpenFlow connections |
6653 |
Southbound OpenFlow connections |
44444 |
Remote JMX connections |
The following table lists the protocols, TCP/IP services, and platform system services that Open SDN Controller supports.
Protocols | |
BGP-LS/PCEP |
NETCONF |
ICMP |
OpenFlow |
TCP/IP Services | |
DNS |
NTP |
HTTPS |
SSH |
JMX |
|
Platform System Services | |
cassandra |
flume |
collectd |
httpd |
controller |
Java |
cyanite |
pathman |
elasticsearch |
|