4

Network Security

This chapter focuses on network security. It is broken down into categories of physical security and logical access security. There are various elements to each of these including specific security protocols, administrative access control (to prevent unauthorized users from accessing the network elements and wreaking havoc), access tools (to provide secure mechanisms for authorized users to access and recover, view and set information on the network elements), and filters and access control lists (used to prevent unauthorized traffic from traversing the network elements, particularly important in the detection and mitigation of the effects of denial of service (DoS) attacks). Security extends to other aspects (e.g. security of routing protocol messages) but that will be covered elsewhere in the book.

4.1SECURING ACCESS TO YOUR NETWORK DEVICES

If you are to keep your network running smoothly, then it is essential for you and your customers that you are able to limit access to your network devices to authorized users. By not protecting your network from unauthorized access, you leave yourself open to attack and also provide a conduit for attacks on other networks.

In addition, it is not sufficient to simply permit or deny access. It is also important to be able to classify users into groups with different levels of access (for example, a NOC operator might only need to view information while a network engineer would need to be able to modify configurations, etc.). Finally, it is essential that you are able to identify what has been changed, when and by whom. For this reason (among others), it is critical that each user has an individual account. It is of little value if you know that ‘neteng’ made a change. Knowing that ‘guyd’ made the change is much more useful.

Designing and Developing Scalable IP Networks G. Davies

2004 Guy Davies ISBN: 0-470-86739-6

36	NETWORK SECURITY

4.1.1 PHYSICAL SECURITY

Physical security is an often overlooked component of a successful security policy. It is absolutely vital that you strictly control physical access to your network devices. After all, if an intruder has unconstrained physical access to your network, then they will have access to all the buttons and switches on the network devices, the power supplies, the cabling, the interface cards and ports on the router (e.g. the console port and the management Ethernet ports) of all your devices and Ethernet and wireless connectivity to your network resources.

The first task is to ensure that intruders cannot get to the power supplies and the on/off switch. Even if the intruder cannot gain access to your operating network devices, they have the ability to severely disrupt the operation of your network by simply turning off the devices. The ability to power off a device with concurrent access to the console port also provides access on several vendors’ devices to mechanisms for resetting the device to factory defaults. This would make it even more time-consuming to recover the box to a functional state.

A carefully chosen, well-protected location for your equipment to which as few individuals as possible have authorized access is the basis on which physical security can be built. Large hubs are often built in commercial secured facilities. A well-run secured facility can provide a high level of security with constrained access to your devices. If this is not sufficient for your purposes, some facilities offer steel cages into which only one customer’s equipment is placed. The downside of steel cages is that they can constrain growth within the hub. It can be extremely tricky and can add to the costs due to extra cabling expenses to build a single hub spread throughout several cages in a single facility.

While access via the console port can be authenticated, and in this author’s opinion always should be, the console port is often left unprotected. The same premise applies to Ethernet and wireless ports. This is discussed later in this chapter.

If physical security is overlooked, all other aspects of security are irrelevant. Once the physical security is sorted, then you need to take care of the logical security of your network.

4.1.2AUTHENTICATION, AUTHORIZATION AND ACCOUNTING (AAA)

The first fundamental part of the logical jigsaw is AAA. The authentication and authorization of users as they connect to network devices are vital. If you have no control over who can access your devices and what level of access they have, you are unlikely to be able to keep your network running for more than a few minutes! Similarly, if you are unable to account for who did what and when they did it, you are unlikely to be able to maintain the stability of the network in the long term. Various mechanisms and protocols are available to support authentication, authorization and accounting.

4.1 SECURING ACCESS TO YOUR NETWORK DEVICES

37

4.1.2.1 Local AAA

This is the simplest mechanism for user authentication. It also inherently provides a significant amount of flexibility. However, it is also by far the most administratively timeconsuming and the most difficult with which to maintain the highest levels of security. Each network device contains a database of locally authenticated and authorized users. There is often less granularity of authorization levels and accounting is based on internal logging mechanisms. These authorization levels and accounting mechanisms often tend to be somewhat proprietary in nature and output format thus they are difficult to use in a multi-vendor environment.

The main problems associated with local authentication and authorization are based on the maintenance of consistent details across all network devices. For example, if a user changes their password on one device, the password does not automatically get changed across the network. Also, if a user leaves your company, you have to visit every single network device to remove their authentication. However, this problem can be turned into a benefit if you wish to provide authentication to users for subsets of your network devices. This can be quite difficult if you use a centralized AAA mechanism (see below). Often, this kind of requirement leads operators to develop Perl or Expect scripts to manage the local accounts on all the network devices. This implies that the usernames and passwords are recorded somewhere on a workstation or server, which is likely to impose further security risks. For larger networks, it is invariably better to use a centralized AAA mechanism.

Similar problems exist with local accounting. If all your accounting is local to each network device, then it is not easy to analyse and correlate events occurring on several devices. However, with local accounting, it is obvious to which device the logs relate. With centralized accounting, it is necessary to include some information in the accounting packets to identify the device to which it refers. There are various logging/accounting mechanisms with many being based upon the System Logging (Syslog) protocol. This provides a flexible set of features to log information generated locally and possibly transmit that information to an external server. Syslog can record information at various levels of detail on a scale from 0 (emergency messages relating to a total failure of the network element) through to 7 (debug level messages). It is also possible to record information relating to particular functions of the network device.

4.1.2.2 TACACS/TACACS+

Terminal Access Controller Access Control System (TACACS) and TACACS+ are Cisco proprietary access control systems. Both are centralized AAA systems based on a client server model. TACACS and TACACS+ have been implemented by several other router vendors but, although the details of the protocol are publicly available, the development of the protocol remains entirely under the control of Cisco. In fact, the protocol has remained unchanged for some years and, as far as I know, there are no plans for any modifications to the protocol in the future.

38	NETWORK SECURITY

A number of TACACS+ servers are available, ranging from Cisco’s own commercial Cisco Secure ACS server to various free implementations. Generally, they are UNIXbased, although Cisco also provides a Microsoft Windows server-based implementation of its ACS server, which supports TACACS+ and RADIUS.

As with all client/server-based AAA mechanisms, the major flaw in the system is related to the loss of the central server. TACACS provides for multiple servers to provide AAA but, if for some reason all servers lose contact with a device, then it is necessary to have a default local login known only to a few carefully chosen engineers.

4.1.2.3 RADIUS

Remote Authentication Dial-In User Service (RADIUS) is an AAA protocol standardized by the IETF. It is almost universally supported by network vendors and provides a mechanism for authenticating users and groups of users and for associating particular access levels with those users or groups of users. It also provides a means of accounting various statistics regarding each user session (time logged in, time logged out, bytes in, bytes out, etc.).

RADIUS is also extensible, providing a means for vendors to create RADIUS attributes specific to their own network equipment’s requirements. These attributes are known as Vendor Specific Attributes (VSAs).

There are many implementations of RADIUS servers, some commercial (e.g. Cisco ACS, Funk Steel Belted RADIUS, etc.), some free (e.g. Microsoft IAS, FreeRADIUS). There are implementations that run on various UNIX platforms and Microsoft Windows server platforms, among others.

As with TACACS, it is necessary to create a default local account for use in the event of the failure of the RADIUS servers.

4.1.2.4 DIAMETER

DIAMETER is a framework for authentication, authorization and accounting, the base protocol being defined in RFC 3588. It extends the concepts developed with RADIUS and TACACS+ to provide a comprehensive, reliable, secure, auditable and extensible AAA mechanism.

Specific enhancements over RADIUS include standardized failover mechanisms, transport layer security, reliable delivery, standardized proxy and relay functionality, standardized server-initiated messaging and standardized roaming support. Many of these functions are present in some implementations either as optional standardized functions or as proprietary extensions. However, this leads to difficulty in operating them in a multi-vendor environment.

Applications for DIAMETER are also documented in various Internet drafts. These include Network Access Servers (NAS), Extensible Authentication Protocol (EAP) and Mobile IP.

Currently, there are few widely deployed implementations of elements of the DIAMETER framework, either in network devices or as AAA servers.

4.1 SECURING ACCESS TO YOUR NETWORK DEVICES

39

4.1.2.5 SSL/TLS

Unlike the previous entries in this section, Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are not mechanisms for the storage and exchange of AAA information. Instead, they provide the means to authenticate yourself to the device with which you are exchanging information and for you to authenticate that device. Authentication is based on the Public Key Infrastructure (PKI). The basis of the security of PKI is that there is a hierarchy of trust. At the top of the hierarchy is a root Certificate Authority (CA), which is considered to be trusted absolutely. There are a number of global root CAs, whose certificates are distributed with many operating systems and applications (particularly web browsers). You can pay a root CA for presigned certificates or to get locally generated certificates signed by these global root CAs. However, many enterprises and some service providers run their own, internal CAs, whose certificates are only distributed to hosts that operate within the boundaries of that network. That CA signs certificates for servers, network devices and individuals within the organization exclusively for the purpose of authenticating them to each other. This CA can operate independently of the global hierarchy by simply selfsigning its own certificate or it can have its CA certificate signed by one of the global root CAs.

When two entities (individuals, hosts, organizations) wish to authenticate each other, they exchange certificates. When you try to authenticate your peer, you follow the chain of certificates back up the hierarchy of trust from the signed certificate you have received to a point you trust. Generally, this is a chain of just two certificates (i.e. the certificate you receive will have been signed by a root CA).

SSL/TLS is widely used on web servers, and less widely used on mail servers, as a mechanism for authenticating the server to the client. This is most widely used on web servers where the server is being used to take credit card details so that the user can be sure that the server taking their details belongs to the organization to which it purports to belong. In environments where HTML and XML are used to monitor and maintain network devices, SSL/TLS provides a mechanism for both parties to authenticate each other. In most cases, it is tricky for a rogue device to masquerade as a valid device. However, it is possible. It is also eminently possible for a rogue user to masquerade as a valid user.

Running a CA is a difficult task. It can place a particularly heavy administrative load on the network operator if each user is required to authenticate himself using a certificate. Every user would require a personal certificate. These certificates can be difficult to transport between hosts if, for example, the user changes their laptop or if they temporarily need to use a different workstation. However, if this is the type of authentication required, the only alternative is to buy a certificate for each user from a global root CA. Even with bulk discounts, this could be prohibitively expensive. As usual, you are left with a compromise. You could internally manage a CA, with the attendant administrative load and costs or pay a third party for the numerous individual certificates from a CA. As always, you must make your own compromises between cost, complexity and security.