A P P E N D I X C |
Management Security |
In the past, network communications were simply a matter of packaging frames of information and shipping them over the wire to their destination. Protocols gave little thought to who might be viewing the frames as they crossed the wire, or what illegitimate parties might do with the information so gleaned. More and more, security has become an ever-present concern amongst the members of the networking community. Networking infrastructure is far too important to risk abuse by hackers, whether they are malevolent or simply mischievous. As a whole, the community has turned to encryption as a means of insuring the security of network transactions.
Interactive login is a mainstay for providing a means to control and/or configure an entity across the network. For decades the Telnet protocol has provided this capability for devices wishing to provide interactive login over a network. However, these protocols are chief culprits with regard to the transmission of sensitive information (like passwords) over the network unprotected. The current de facto standard for providing interactive login in a secure fashion is the Secure Shell (SSH). SSH provides a number of services in a secure manner. These include port forwarding, file transfer, X11 forwarding, and interactive login. Of these, currently only interactive login is of interest for the Sun Netra CP3140 switch.
Managing devices with a web browser has been standard practice for several years. Unfortunately, standard HTTP transactions are no more secure than Telnet. This was one of the original barriers to the success of "e-commerce". The solution (then and now) is the use of the Secure Sockets Layer (SSL) protocol. SSL provides a means of abstracting an encrypted connection between two stations. Once established, such a connection is virtually no different to use than an unsecured connection. This allows an established protocol (like HTTP) to operate in a secure manner in an open network. A third component of management on a modern networking appliance is SNMP. The SNMP protocol has it own security mechanisms outside of SSH and SSL. Consequently discussion of security for SNMP transactions is outside the scope of this chapter.
Enabling management security is a two-step process. The first step involves generating and loading appropriate authentication keys (SSH) and security certificates (SSL). Optionally, a reputable third party such as RSA Security, Inc. or Entrust, Inc. can validate these certificates and keys, but for evaluation purposes validation is unnecessary. The second step involves enabling either SSL or SSH and optionally disabling the insecure versions of Telnet and web management. Once enabled, subsequent management connections may be made in a secure manner.
To generate self-signed credentials, the open source applications ssh-keygen and openssl can be used to create the seven files used to form the security certificates and authentication keys. Both of these applications are well documented by the open source community. Detailed descriptions will not be repeated here as you can check the man pages for detailed help. Two scripts are included at the end of this appendix along with some helper files. This set of files can be freely modified and used to generate the appropriate self-signed credentials. Generation of these credentials has been verified using both cygwin and Linux.
Once the component files are created, the credentials must be loaded onto the Sun Netra CP3140 switch. This is accomplished by using the copy command from a TFTP server. From privileged EXEC mode, issue the following command:
Where the IP address of the TFTP server should be substituted as appropriate. This copy command is repeated for all the authentication components:
The SSL and SSH credentials may be uploaded separately as needed. It is likely that if security is required for one access method it would be required for all access methods. Thus it is recommended that the certificates and authentication key be created simultaneously.
Once the authentication credentials are loaded and the certificates and authentication keys are formed, management security may be configured on the FASTPATH device. From privileged EXEC mode, issue the command:
This allows Secure Shell sessions to be instantiated on the Sun Netra CP3140. The message log should be checked for errors if a secure connection cannot be established. Entries such as the following indicate the nature of the problem.
In this case, the authentication credentials were invalid and should be regenerated. Messages indicating successful start of the SSH service look like this:
To disable insecure access, issue the commands:
Exercise caution before issuing this command, as once the active telnet sessions are terminated, no new telnet sessions will be allowed. Consult the appropriate Command Reference for more information on configuring remote sessions.
Optionally or in concert with SSH, SSL may be enabled. Once again the message log is the best source of feedback for problem determination. To enable SSL, issue the privileged EXEC mode command:
Success may be determined by attempting secure web access using https. Consult the message log for failure information. Valid certificates are indicated by a message log entry that looks like the following:
0 days 01:25:29 Unit: 1 : File: sslt_util.c : Line: 303 : SSLT: Successfully loaded all required SSL PEM files |
Certificate information may be accessed using browser-specific methods. With Internet Explorer, the lock icon along the bottom message line can be checked for certificate details. Additionally, when connecting to a Sun Netra CP3140 switch that uses self-generated credentials, Explorer will warn the user about the authenticity of the certificate. When secure certificates are acquired from a third party this warning will no longer occur. Insecure web sessions may be prevented by disabling the http server using the privileged EXEC mode command:
As with Secure Shell, the best guide for information on FASTPATH commands controlling http and https access is the user configuration guide.
The following four scripts and helper files can be used to generate self-signed certificates and authentication keys.
Copyright © 2009 Sun Microsystems, Inc. All rights reserved.