S 4.204 Secure administration of routers and switches

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

There are different ways to access routers and switches for administration purposes. Depending on the type of access used, a number of security precautions must be taken. With larger networks, it is recommended to integrate the routers and switches in a central network management system, because otherwise secure and efficient administration can virtually not be ensured.

The methods used for administration should be specified in the security policy, and administration may only be performed in accordance with the security policy. Any unused administration interfaces should be disabled. Several aspects are covered below, which should be taken into account in terms of administration.

If possible, administrative access should also be restricted by configuring access control lists (ACLs) (see also S 5.111 Configuration of access control lists on routers).

Remote administration

Numerous active network components offer remote administration options with the help of the Telnet service. However, the use of Telnet entails the risk of authentication data being spied out, because all the data are transmitted in plain text and it is therefore possible to read the data traffic including user name and password (see also T 2.87 Use of insecure protocols in public networks). SNMP is also often used for remote administration. Similarly, the SNMPv1 and SNMPv2 versions do not offer adequate options for securing communication. SNMPv3 is the first version to offer security mechanisms which allow for use outside isolated administration networks.

Where routers and switches are accessed remotely, it is always necessary to protect communications. This can be achieved, for example, by using the SSH service instead of Telnet (see S 5.64 Secure Shell) or by creating separate LAN segments which are solely used for administrative purposes (see section on administration network).

Unprotected remote administration via external (insecure) networks must never be performed. This must be taken into consideration when defining the security policy. No insecure protocols should be used in the internal network either.

Web server

Many devices provide the option of performing administrative work via a browser interface. In this case, an HTTP server is started on the router and/or switch; access is performed using any clients and the web browser.

The default settings for accessing the web interface are not uniform for all manufacturers. Ideally, access should be disabled in the basic settings, but it is also possible to use this service in an unprotected manner without entering any user information. This should be checked when installing equipment and, if necessary, the configuration must be changed accordingly.

As with the use of the TELNET service, the user name and the password are transmitted in plain text with HTTP. Moreover, a whole series of exploits are known which exploit vulnerabilities of the HTTP servers of different manufacturers. Thus, we strongly advise against using the HTTP service for administrative purposes. If possible, the HTTP server should be deactivated when the system is initially configured unless access is to be gained via a separate management network.

In addition to access via HTTP, some devices also offer the option of accessing the web interface via HTTPS. If this option is available, then preference should always be given to HTTPS over HTTP.

When using the web interface, it should also be kept in mind that, in many cases, not all the configuration settings are accessible via this route.

Administration network (out-of-band management)

In order to counter the risks with remote administration, some devices offer the option of configuring a separate logical port (management interface) for administration. For switches, this port should be assigned to a VLAN which is used only for administrative purposes (out-of-band management) and which only contains the management interfaces. This management network should be completely separated from other parts of the network. This will compensate for any vulnerabilities such as login information which is transmitted in unencrypted form in the protocols used for administrative tasks such as TELNET or the outdated SNMP versions.

Access Control Lists (ACLs) should be configured in such a manner that permission to access the management interface is only granted to the management station. All services not needed by the management interface should be disabled.

Network management systems

Active network components are normally integrated in a central network management system. In addition to the measures outlined above, it is also necessary to note the safeguards covered in module S 4.2 Network and system management.

Central authentication server

Instead of access and rights control being configured locally on the device, it can be implemented via a central server. Local configuration is not entirely practicable in large environments with a large number of active network components. In such cases, the effort required for administration for the maintenance of many authorisations in parallel is very high.

The central server provides for standardised administration of all access attempts and authorisations. Sensitive data are no longer stored on the devices themselves and therefore do not have to be maintained on an individual basis. Instead, all the information is stored in encrypted form in a database and its administration is quite straightforward. This type of server also offers advanced options for logging, e.g. the number of dial-in or access attempts and the time at which they occur can be documented. Examples of this include RADIUS and TACACS+ (Terminal Access Controller Access Control System). Authentication should be protected by a central authentication server in complex networks with a large number of active network components.

If it is not possible to use an authentication server (for example, due to failure of the server or network problems), local access should be still configured. This can be protected by a password used solely for this purpose.

The authentication server should be used, if possible, for cases of local access which have not been configured specifically for situations in which the authentication server is unavailable, as otherwise users who log on locally will bypass central authorisation and monitoring.

Authorisation administration for user accounts and system commands

Authorisation administration can take place at different levels and with different degrees of granularity, depending on the manufacturer. If system commands are administrated and authorised, commands which should only be accessible to certain users or groups can be grouped together in one authorisation level and/or assigned to this one level. This is already pre-configured by Cisco, for example, at two levels:

Access to any given authorisation level is password-protected. In order to access a system command which is protected accordingly, users first need to switch to the relevant authorisation level and enter the appropriate password. They will then be in a position to execute all the commands assigned to this level. User accounts are assigned their authorisations through the assignment of users to an authorisation level. In general, each user should be assigned only the minimum authorisations necessary. Thus, different roles can be defined along the lines suggested in the following examples:

Users are thus automatically assigned to an authorisation level once they have logged onto the equipment. Alternatively, they must specifically enter the relevant authorisation level and the corresponding password following logon. Protection of access via a central authentication server should always be configured for security-critical roles.

The options for the assignment of authorisations to users and roles can even be carried so far that authorisations can be granted for every individual command, with these authorisations being checked on the authorisation server prior to any execution.

When drawing up the rights and role concept for the administration of the active network components, it is necessary to consider the options available on the individual systems. The application scenario and protection requirements should be taken into consideration when deciding on the degree of differentiation between the authorisation levels on a case-by-case basis. In this case, the rule of thumb could be defined as follows: "As fine as necessary, as simple as possible." Subdivisions which are too rough do not offer adequate security, whereas excessively fine subdivisions can impair the efficiency of work and entail the risks of errors.

Password encryption

Routers and switches should support the option of storing passwords in encrypted form in configuration files (see also S 2.280 Criteria for the procurement and selection of suitable routers and switches). This is possible, for example, on Cisco devices using the enable secret command.

The encryption of passwords is particularly important if configuration files are sent over the network or stored in central servers.

If the equipment supports password encryption, this function should definitely be used. Here, the encryption procedure should be taken into consideration, as some devices support different procedures. Older operating systems, in particular, still use weak encryption procedures which may still be supported in more recent versions for reasons of compatibility. When migrating to a new device or to a new version of an operating systems, checks should be carried out in this respect as to whether the newer version supports stronger encryption procedures.

In addition, there are procedures for all devices, which do not allow encrypted passwords to be made readable again, but result in the resetting of passwords.

Some services cannot be protected with password encryption. They include SNMPv1 and SNMPv2, RADIUS and TACACS+. The passwords for the latter services should always be unique. They should not be used for any other service and should be changed at regular intervals. SNMPv1 and SNMPv2 should only be used in conjunction with out-of-band management (see above: administration network) and, wherever possible, be replaced by SNMPv3.

Session timeouts

All types of access can be protected by the assignment of passwords. However, this protection can become ineffective if sessions are unattended, for example, if an administrator who is logged on leaves his computer and forgets to terminate the session or to activate the screen lock. For this reason, it is advisable to configure timeouts so that connections are terminated or blocked after a defined period of time has expired without any user activity. Here, timeout periods should not exceed 10 minutes.

Review questions:

© Federal Office for Information Security. All rights reserved.