Security Overview

When we talk about “security” we know what we want, but describing it and making it happen can be different matters altogether. Network security has a natural conflict with network connectivity. The more an autonomous system opens itself up, the more risk it takes on. This, in turn, requires that more effort be applied to security enforcement tasks. This article is chapter eight of the book, Cisco: A Beginner’s Guide, third edition, by Anthony Velte and Toby Velte (McGraw-Hill/Osborne, 2004, ISBN: 0072256354).

ciscoThe concept of network security may seem somewhat of a moving target—or several moving targets. When we talk about “security” we know what we want, but describing it and making it happen can be different matters altogether. Network security has a natural conflict with network connectivity. The more an autonomous system opens itself up, the more risk it takes on. This, in turn, requires that more effort be applied to security enforcement tasks.

On top of that, add departmental budget constraints (and the personnel cuts that many companies have seen in recent years) and even reasonable security solutions might seem impossible to attain. Three trends have increased the bite that security takes out of the IT department’s overall budget:

  • Internetworks are getting bigger and more complicated.
  • New threats are always emerging.
  • The typical network security system is usually not a system at all, but is a patchwork of vendor-specific tools (sound familiar?).

Network security is so pervasive a consideration that even network management consoles raise concerns. As we’ll talk about in Chapter 15, some worry about whether the SNMP infrastructure itself is secure enough. After all, stealing the right SNMP community string would give a hacker a road map to an entire internetwork’s configuration, and unless you’ve been living in a cave, you know about computer viruses spreading in various forms: e-mail bombs, Trojan horse Java applets, Denial-of-Service attacks, and other worrisome new threats to computer security. Suffice it to say that a lot of time, money, and effort go into network security.


NOTE: SNMP stands for Simple Network Management Protocol and, as you have probably deduced, it is used for network management. Don’t worry about it too much at this point. We’re mentioning it here as a bit of foreshadowing, before we talk about it in depth in Chapter 15. SNMP relates to some other protocols that are used for network security. Basically, all these protocols gather information from your network—whether for security or for network management.

In Chapter 9, we’ll talk about Cisco’s Internet access and security products. Just as a head’s up, the focus will be mainly on how firewalls—and even routers—monitor internetwork traffic at the packet level to provide security. Traffic-based security runs on firewalls and routers and deals mainly in IP addresses.

But a second kind of security operates at the people level. This kind of security, called user-based security, employs passwords and other login controls to authenticate users’ identities before they are permitted access. There are two basic types of user-based security:

  • End-user remote access to servers, in which employees dial into their enterprise internetworks and subscribers dial into their Internet service providers (ISPs)
  • Network administrator access to network devices, in which technicians log into IOS on various kinds of network devices in order to work on them

Security is the third major control system in internetworking, along with network management systems and routing protocols. Although the three control systems have distinct missions, you’ll see a familiar pattern:

  • Embedded commands Application commands built directly into IOS that are used to configure individual devices to participate in a larger network control system
  • Dedicated control protocol A communications protocol that coordinates the exchange of messages needed to perform the network control system’s tasks
  • Server and console A server to store the messages and a workstation to provide the human interface through which the network control system is operated

Figure 8-1 illustrates the common architecture shared by network control systems.

Looking at the figure, you see two new names listed next to SNMP—TACACS+ and RADIUS. These are the protocols used for security, not management, as is SNMP, but they’re analogous in how they operate. Data is gathered from network devices and stored

 


Figure 8-1.  Internetwork control systems, including security, share certain features.

in a central database, and a console is used to configure devices from a central management workstation. Network management and security systems differ in what they do, but are basically the same in how they work.

The third internetwork control system, routing protocols, differs sharply. Routing protocols don’t use servers because the information—route tables—is transient and doesn’t need to be stored on disk. Additionally, they don’t use consoles because they are largely self-operating.

The structural similarities between network management and security will make it easier to comprehend network security technology. Just swap in new names for protocols (TACACS+and RADIUS) and consoles, and you understand the general setup.

{mospagebreak title=Overview of Network Security}

There are two kinds of network security. One kind is enforced as a background process not visible to users; the other is in your face:

  • Traffic-based security Controls connections requested by a network application, such as a web browser or an FTP download
  • User-based security Controls admission of individuals to systems in order to start applications once inside, usually by user and password

One kind of traffic-based security is the use of firewalls to protect autonomous systems by screening traffic from untrusted hosts. The other kind of traffic-based security is router access lists, used to restrict traffic and resources within an autonomous system. User-based security is concerned with people, not hosts. This is the kind of security with which we’re all familiar—login-based security that asks you for a username and password.

The two types complement one another yet operate at different levels. Traffic-based security goes into action when you click a button in a web browser, enter a command into an FTP screen, or use some other application command. User-based security, on the other hand, asserts itself when an individual tries to log into a network, device, or service offered on a device.

Traffic-Based Security

Traffic-based security is implemented in a Cisco internetwork by using firewalls or router access lists. This style of security—covered in Chapter 9—focuses mainly on source and destination IP addresses, application port numbers, and other packet-level information that can be used to restrict and control network connections.

Until recently, firewalls have focused strictly on guarding against intruders from outside the autonomous system. However, they’re now coming into use in more sophisticated shops to restrict access to sensitive assets from the inside. Access lists have been the traditional tool used to enforce intramural security.

Access List Traffic-Based Security

Routers can be configured to enforce security in much the same way firewalls do. All routers have access lists, and they can be used to control what traffic may come and go through the router’s network interfaces and what applications may be used if admitted. What exactly an access list does is left to how it’s configured by the network administrator.

 

Mostly, access lists are used to improve network performance by isolating traffic in its home area, but a heavily configured access list can pretty much behave like an internal firewall, restricting traffic among departments.

Firewall Traffic-Based Security

Firewalls are basically beefed-up routers that screen processes according to strict traffic management rules. They use all sorts of tactics to enhance security: address translation to hide internal network topology from outsiders; application layer inspection to make sure only permitted services are being run; even high/low counters that watch for any precipitous spikes in certain types of packets to ward off Denial-of-Service attacks such as SYNflood and FINwait.

Firewalls intentionally create a bottleneck at the autonomous system’s perimeter. As traffic passes through, the firewall inspects packets as they come and go through the networks attached to its interfaces.

 

Firewalls read source and destination host addresses and port numbers (for example, port 80 for HTTP), and establish a context for each permitted connection. The context comes in the form of a session, where packets with a certain address pair and port number must belong to a valid session. For example, if a user tries to connect to a web server to download a file, the firewall will check the user’s source IP address and the application service requested before permitting the packets to pass.

Think of traffic-based security as being like those “easy pass” automated tollbooths on major toll roads. Vehicles are funneled through a gateway where a laser reads each electronic ID, barely slowing the flow of traffic.

User-Based Security

User-based security evokes a different picture—this one of a gate with a humorless security guard standing at the post. The guard demands to know who you are and challenges you to prove your identity. If you qualify, you get to go in. More sophisticated user-based security systems also have the guard ask what you intend to do once inside and issue you a coded visitor’s badge giving you access to some areas, but not others.

Thus, user-based security is employed where a person must log into a host, and the security comes in the form of a challenge for your username and password. In internetworking, this kind of security is used as much to keep bad guys from entering network devices such as routers or switches, as it is to restrict access to payload devices, such as servers.

Unlike firewalls, however, user-based security is nearly as concerned with insiders as outsiders. That security guard at the gate has colleagues on the inside, there to make sure nobody goes into the wrong area. You know the routine—there are employee badges and there are visitor badges, but the employee badges let you go more places.

Login/password points are generally placed on every network device and all servers. Because user-based security mechanisms are software, not hardware, they can be deployed at will within an internetwork with little impact on performance or budget. The trade-off is how much inconvenience you’re willing to put network users through, having to log in to gain access to various services. User-based security has four major applications:

  • To grant remote employees access to the enterprise internetwork
  • To grant onsite employees access to protected hosts and services within the internetwork
  • To let network administrators log into network devices
  • To let ISPs grant subscribers access to their portals

Because most user-based security involves remote dial-in connections,WANtechnologies play an important role. The two most important pieces inWANconnections are access servers and dial-in protocols.

{mospagebreak title=Access Servers and Dial-in Protocols}

Access Servers

Entering an internetwork via a dial-in connection is almost always done through an access server. The access server is a dedicated device that fields phone calls from remote individuals trying to establish a connection to a network. Access servers are also called network access servers or communication servers. Their key attribute is to behave like a full-fledged IP host on one side, but like a modem on the other side. Figure 8-2 depicts the role access servers play in dial-in connections.


Figure 8-2. Access Servers are devices dedicated to supporting remote dial-in connections.

When you connect to an internetwork’s host from the enterprise campus, you usually do so over a dedicated twisted-pair cable that is connected to a hub or a switch. To make that same connection from afar, you usually do so over a normal telephone line through an access server—a device that answers the phone call and establishes a network connection. Besides making connections for remote dial-in users, access servers can also be used to connect remote routers.

User-Based Security for Local Connectivity When you turn on your PC and log in at work, you’re not dealing with TACACS+ or RADIUS. The username and password prompts are coming from your local server. Most LAN servers run Windows 2000/2003, Linux, UNIX, or Novell platforms. They have security subsystems and user databases of their own to authenticate and authorize users. RADIUS isn’t used because it’s a dial-in password protocol. TACACS+ isn’t used because it controls entry into the Cisco network devices themselves—routers, switches, and access servers—in addition to providing dial-in security much like RADIUS.

In this chapter, discussions of local or “in-network” connections refer to network administrators logging into IOS to work on a Cisco network device.

User-Based Security for Remote Connectivity Small office and home office users tap into their enterprise internetworks via an access server, making it perhaps the most basic device in any wide area network. Low-end access servers are inconspicuous desktop devices resembling a PC without a monitor. When you dial into your ISP to get into the Internet from home, the call is also answered by an access server. As you might imagine, an ISP’s computer room is jammed with rack-mounted high-density access servers to handle connections made from thousands of subscribers. (As a reminder, high density means many ports per device.)

Access servers are intelligent devices that handle other tasks in addition to making a line connection. They provide special services to accommodate configurations frequently encountered in enterprise internetworks:

  • Routing service  Run by access servers called access routers, this makes it seem as if the dial-in user is sitting directly on the campus network. The key feature of access routers is dial-on-demand routing (DDR), which makes it possible to route traffic from a remote LAN to the main network over low-cost, dial-up phone lines.
  • Terminal service  Many WAN connections still use terminal protocols. For that reason, most access servers support terminal protocols such as IBM’s TN3270, UNIX rlogin, or Digital Equipment’s Local-Area Transport (LAT). A PC could run terminal emulation software to make such a connection.
  • Protocol translation  A remote user may be running a virtual terminal protocol and then connect to a system running another virtual terminal protocol. Most access servers still support protocol translation.

As computing infrastructure improves, terminal service and protocol translation are declining in use. In contrast, access routers are increasing in popularity as small offices build LANs of their own and turn to DDR for convenience and savings.

Dial-In Protocols

As you’ve learned by now, there’s a protocol for just about every major internetworking task. Making dial-in network connections work properly presents special problems because most telephone company infrastructure was designed to handle voice, not high-speed data. Dial-in protocols exist to handle the point-to-point dial-in connections over normal telephone lines.

  • PPP Point-to-Point Protocol is the de facto standard for remote dial-in connections to IP networks; virtually all dial-in connections to the Internet use PPP. Most PPP connections are over asynchronous lines, but a growing number are made over ISDN in areas where it’s available.
  • SLIP Serial Line Internet Protocol is also used to make point-to-point dial-in connections to IP networks from remote sites. SLIP is the predecessor to PPP, but is still in use in some quarters. You may also encounter a SLIP variant called CSLIP, Compressed Serial Line Internet Protocol.
  • ARAP AppleTalk Remote Access Protocol is Apple’s tool for dial-in connectivity to remote AppleTalk networks.

In the old days, to make a remote connection, you dialed into a PBX or terminal server to connect to a mainframe or minicomputer as a dumb terminal. With the rise of internetworking, network-attached terminal servers took over the job of taking dial-in calls. As demand for remote computing grew even more, simple terminal connections were replaced by those made using the SLIP protocol. By that point, many desktops had PCs instead of terminals, but they emulated terminals in order to make dial-in connections. The boom in demand for Internet connectivity drove the market to replace SLIP with PPP, a protocol even more capable of computer-to-computer communications over phone lines. For our purposes, we’ll assume PPP as the dial-in protocol unless otherwise noted.

{mospagebreak title=Authentication, Authorization, and Accounting}

The framework for user-based security is called authentication, authorization, and accounting (AAA), pronounced triple-a. The AAA framework is designed to be consistent and modular in order to give network teams flexibility in implementing the enterprise’s network security policy.


NOTE: Network security systems like CiscoSecure control access to LAN segments, lines, and network applications such as HTTP and FTP. Network access devices—usually access servers and access routers—control access to these network-based services, but an additional layer of security is sometimes configured into the server platform once it is reached. For example, an IBM mainframe will enforce security policies using its own mechanisms. Security for computer platforms and major application software packages is still performed using self-contained security systems resident in the application server, in addition to the network access device security measures covered in this chapter.

Overview of the AAA Model

AAA’s purpose is to control who is allowed access to network devices and what services they are allowed to use once they have access. Here is a brief description of the AAA model’s three functional areas:

  • Authentication Validates the user’s identity as authentic before granting the login
  • Authorization Grants the user the privilege to access networks and commands
  • Accounting Collects data to track usage patterns by individual user, service, host, time of day, day of week, and so on

Thankfully, the acronym makers put the three functions in sequential order, making the AAA concept easier to pick up: first, you’re allowed to log in (your identity is authenticated); then you have certain privileges to use once you’re in (you have predetermined authorizations); and finally, a running history is kept on what you do while logged in (the network team keeps an account of what you do).

The philosophy is to let network teams enforce security policy on a granular basis. Most AAA parameters can be put into effect per LAN segment, per line (user), and per protocol—usually IP.

AAA is a clearly defined security implementation framework that everybody can understand. The architecture is defined down to the command level. Indeed, the AAA concepts are actual IOS commands. Starting an AAA process on a Cisco device involves using the aaa prefix followed by one of the three root functions, such as aaa authentication. A whole AAA command line might read aaa authentication ppp RemoteWorkers tacacs+ local, for example. The purpose of AAA is to provide the client-side command structure on which CiscoSecure relies.

AAA Modularity

A security policy is a set of principles and rules adopted by an enterprise to protect system resources, confidential records, and intellectual property. It’s the network manager’s responsibility to implement and enforce the policy, but in the real world, security policy can get dragged down into the mire of office politics, budget constraints, and impatience. An end-user manager can have a lot of clout as to how the policy will be conducted on his or her turf. After all, the company, not the IT department, funds the network. Consequently, there can be a lot of variance among security policies—even within an enter-prise’s internetwork.

This means that security policies must be highly adaptable. CiscoSecure tries to satisfy this need with modularity—the ability to separately apply security functions by secured entity, independent of how they are applied to other resources. The AAA architecture gives you the option to implement any of the three functions independent of the other two. This includes whether they’re activated on a device, which security protocol is used, and what security server or user database is accessed.

Authentication Controls The aaa authentication command validates a user’s identity at login. But once you’re authenticated, exactly what can you access? That depends on the type of access being made:

  • If you’re a network administrator logging into a switch to tweak its config file, the authentication gets you into that switch’s IOS command prompt.
  • If you’re an employee sitting inside the enterprise and you were authenticated by a router, you get into a protected host to run Windows or browser-based internetwork client-server applications.
  • If you’re a telecommuter and an access server authenticated you, you’re admitted to your enterprise’s internetwork to run the same client-server applications.
  • If you dialed into the Internet from home, as a member of the general public, you were authenticated by one of your ISP’s many access servers, and you enter the World Wide Web.

Security must protect three destination environments: the Internet, the internetwork, and, most of all, the internal operating system of the devices over which internetworks run. Figure 8-3 illustrates access types and destination environments.

The scenario of the network administrator logging into IOS devices is unique. In Cisco internetworks, that type of access is usually authenticated using TACACS+. Other types of access open into a Windows-or HTTP-based application service. Network administrators access a device’s IOS environment in order to perform device maintenance tasks.

Users also require different dial-in services. Although almost everybody uses PPP nowadays, there still can be different requirements. Depending on the local network from which the call is made, different PPP services may be required, such as IP, IPX, NetBEUI, or just a plain terminal connection.

Whatever the issues may be, different requirements often call for a variety of authentication methods to be used in the same internetwork. CiscoSecure lets the network manager employ any of the major dial-in protocols and authentication techniques. In addition, it supports the ability to apply these different tools by network interface or line—even on the same device.

 
Figure 8-3.  User authentication takes place in four scenarios that open into three worlds.

Authorization Controls  AAA authorization limits services to the user. In other words, if authorization has been activated on a secured entity using the aaa authorization command users must be explicitly granted access to it.

The person’s user profile is usually stored in the security server and sometimes also in the device’s local user database. When the administrator logs into the device and his or her user profile is checked, the device configures the authorizations to know what commands to allow the administrator to use during that session. Commands can be authorized by IOS command mode (the MyRouter> versus MyRouter# prompts) or by specific commands within a mode. Figure 8-4 lays out some of the various forms authorizations can take. Authorization can be more complicated than authentication. After you’ve been authenticated,the security server must supply the access device configuration information specific to the user—for example, which networks the user may access, which applications may be run, which commands are okay to use, and so on. Without centralized maintenance of authorization information, it wouldn’t be practical to assign authorizations byuser. (It’s hard enough just to keep usernames and passwords up-to-date.)

Accounting Controls  Accounting doesn’t permit or deny anything, but instead keeps a running record of what users do.AAAaccounting is a background process that tracks the person’s logins and network use. Figure 8-5 shows how AAA security accounting tracks resource usage.


Figure 8-4.  Authorization can be enforced by network, command mode, and even by command.


Figure 8-5.  AAA accounting is a background process that tracks a user’s network activity.


NOTE:  By default, AAA defines IOS as having two command modes: the user EXEC mode (sometimes also called Shell) and the privileged EXEC modes. The IOS level command can be used to further divide things up into 16 command levels (numbered 0–15), so access to commands can be authorized on a more fine-grained basis.

Trends Leading to Client-Server Security Systems

As with most network control systems, AAA uses the client-server model to manage security. In other words, there is a central security server holding the user profile information used by client access devices to enforce security. When a user makes a request to connect to a network, line, or service, the client device queries the server to check if it’s okay. Centralization is necessary because it’s no longer feasible to administer security one access device at a time; there are simply too many of them to keep track of.

In the 1970s, a natural by-product of remote users dialing into central mainframes was that user security profiles (accounts, passwords, and authorizations) were stored right there on the same computer where all the services sat. This made it easy for the security system to check on user permissions. Then, in the 1980s, departmental minicomputers became popular, spreading computers out into the organization. Terminal servers were invented to provide the additional entry points the distributed topologies required, but user databases were now spread across many access devices—making it much tougher to maintain the security system. By the time IP-based networking took off, it became apparent that security information had to be centralized. Figure 8-6 depicts this trend.

The rise of internetworking demands that an enterprise offer dial-in access throughout the organization. Doing so presents problems for enforcing consistent security controls across so many access servers. The AAA architecture is Cisco’s game plan for meeting these challenges.

AAA’s Two Security Protocols: TACACS+ and RADIUS

It’s possible to use AAA security on a stand-alone basis, with no central security database. In the real world, few do this because it would require the extra effort of maintaining security parameters on a device-by-device basis—a labor-intensive and mistake-prone proposition. IOS supports stand-alone security because, in some cases, a security server is unavailable—for example, in a very small internetwork or during the period of time when a security server is being implemented but is still not operable.

AAA configures access devices as clients. Client devices include access servers, routers, switches, and firewalls. The clients query one or more security servers to check whether user connections are permitted. To do this, a protocol is needed to specify rules and conventions to govern the exchange of information. AAA security can use two protocols to handle client-server security configurations:

  • RADIUS A security protocol used mainly for authentication. RADIUS stands for Remote Authentication Dial-in User Service. RADIUS is an industry standard under the auspices of the IETF.
  • TACACS+ A proprietary Cisco protocol that is largely the equivalent of RADIUS, but with stronger integration of authorization and accounting with authentication. TACACS stands for Terminal Access Controller Access Control System. Cisco has submitted TACACS+ to the IETF for consideration as a security protocol standard.


Figure 8-6.  Security systems have evolved along with the computing industry.


NOTE: There is a third security protocol called Kerberos. Developed at MIT, Kerberos is an emerging open standard for secret-key authentication that uses the Data Encryption Standard (DES) cryptographic algorithm. Microsoft, for example, integrated Kerberos into Windows 2000. Although more difficult to implement and administer, Kerberos is gaining in popularity in internetworks more sensitive to security. Its key benefits are that it can function in a multivendor network like RADIUS, but it doesn’t transmit passwords over the network (it passes so-called tickets instead). IOS includes Kerberos commands in its AAA framework.

{mospagebreak title=How AAA Works}

AAA is the security infrastructure of IOS devices. AAA commands are located in the IOS privileged EXEC mode. Each client device is configured for security using the AAA commands from global configuration mode. Properly configured, the device can then make use of the CiscoSecure server via either the TACACS+ or RADIUS security protocols— or both.

In fact, AAA commands can be used stand-alone to secure a device. In other words, the device can use a local user database stored in NVRAM on the device itself, instead of one on a RADIUS or TACACS+ server. However, this is rarely done because it entails maintaining and monitoring user security data in hundreds, or even thousands, of device config files instead of in a single database.

TACACS+ and RADIUS are client-server network protocols used to implement client-server security over the network. In that sense, they are the equivalent of what SNMP is to network management.

 A user database changes every time users are added or deleted, passwords are changed, or authorizations are modified. Separating the user database from device config files reduces the number of places updates must be made. Most internetworks use a primary server and one or two alternate security servers, leaving only a few places in which user profile databases need to be updated.

Ensuring that the user databases contain identical data is called database synchronization. This can be done automatically by using Replication Partners in CiscoSecure. In the scenario with three security servers, the three user databases would be configured as replication partners, and the CiscoSecure ACS would automatically synchronize user profile records between the three on a daily basis.

The AAA Approval Process

AAA works by compiling attributes that specify a user’s permissions. In the AAA context, an attribute is an entity (or object) to which the person may have access. For example, an authentication attribute might be a specific LAN segment to which the person is permitted access. An authorization attribute might be the limit on concurrent connections the person may have open at one time.

When a user attempts to connect to a secured service, the access device checks to see if the user has clearance per the security policy. It does so by sending a query to the server database to look for a match. The secured access device knows what to query for based on its config file parameter settings, and the query is to verify that the user has permission to do whatever is being attempted.

Attribute-Value Pairs The query contains the attributes that are mandatory for the requested service, as defined in the access device’s config file. The server processes the query by searching for the same attributes in the user’s profile in the user database. The search is for so-called attribute-values. An attribute, called an attribute-value pair (or AV pair) in TACACS+ terminology, is a fancy term for a network entity that is secured.

For example, in someone’s user profile, the password is an attribute, and the person’s actual password, imreallyme, is the value paired with it. When the user enters the password, the access device handling the login first knows to check for a password because to do so is set as a parameter in the device’s config file. By checking the person’s user profile, it looks for a match between the value entered into the password prompt and what’s on file in the user database for the username the person entered. Figure 8-7 shows the AAA procedure for handling a user’s request for a connection.

How AAA Handles Authentication Transactions When the connection is established, the access device contacts the security server to obtain a user prompt and displays it to the user. The user enters the information (usually just a username and password), and the protocol (RADIUS or TACACS+) encrypts the packet and sends it to the server. The server decrypts the information, checks the user’s profile, forms and encrypts the response, and returns the response to the access device.

The rules of AAA approval are fairly simple: If an ACCEPT is returned, the requested connection is made. If a REJECT is returned, the user’s request-for-connection session is terminated, but if an ERROR is returned and the access device is configured for multiple security servers, the query is then forwarded to an alternate server. If that server also fails to return a response, the process continues until the query runs out of servers. At that point, if the access device has been configured with a second method, it will iterate through the process again, first trying for approval with a query to the primary security server, and so on. If the access device exhausts authentication methods, it terminates the user’s request-for-connection session.

The CONTINUE response is another optional configuration parameter that prompts the user for additional information. The prompts can be anything the network administrator arbitrarily defines. For example, prompting users for their mother’s maiden name is a common challenge.


Figure 8-7.  User access requests are granted if attribute-values are matched in the user profile.


NOTE: A daemon (pronounced either with long e or long a) is a process that runs on a server to perform a predefined task, usually in response to some event. The term comes from Greek mythology, in which daemons were guardian spirits. Daemons are called system agents in Windows parlance. A TACACS+ daemon sits on the security server and fields authentication or authorization queries from client access devices. It does so by searching the user database for required AV pairs and returning the results to the client in TACACS+ packets.

Authorization Transactions If the user is authenticated, the daemon is contacted to check for authorization attributes on a case-by-case basis. Figure 8-8 depicts how authentication and authorization work together.

Authorization attributes can be issued for such services as connection type (login, PPP, and so on), IOS command modes (User EXEC or Privileged EXEC), and various connection parameters, including host IP addresses, user timeouts, access lists, and so on.


Figure 8-8.  Once authenticated, a user’s authorizations are cleared as needed.

Authorization is, by nature, more sophisticated than authentication. More information than just username and password is involved, and the attributes have a state. For example, the Maximum-Time attribute requires the server to keep tabs on how long the user has been connected and to terminate the session when the value (number of seconds) for the user has been exceeded.

Authentication Protocols

CiscoSecure supports a number of authentication mechanisms. Also called password configurations or password protocols, authentication protocols make sure you are who you say you are when logging into a system. Here are four major authentication mechanisms supported by AAA:

  • ASCII American Standard Code for Information Interchange is the oldest authentication protocol. ASCII is a machine-independent technique for representing English characters and has many other uses besides authentication. ASCII authentication requires the user to type in a username and password to be sent in clear text (that is, unencrypted) and matched with those in the user database stored in ASCII format.
  • PAP Password Authentication Protocol is used to authenticate PPP connections. PAP passes passwords and other user information in clear text. You know PAP as a protocol that lets you store your username and password in the dialog box so you don’t have to type it during each login.
  • CHAP Challenge Handshake Authentication Protocol provides the same functionality of PAP, but it is much more secure since it avoids sending the password and other user information over the network to the security server. Figure 8-9 depicts how challenge-response works.
  • Token-Card This authentication technique uses one-time passwords. A token-card is an electronic device that’s a bit larger than a credit card. The card is used to generate an encrypted password that must match one filed for the user in the token-card database residing on the security server. The encrypted password is good for only one use; thus the name token. Token-card authentication systems provide the best access security.

AAA also supports NASI (NetWare Asynchronous Services Interface), an authentication protocol built into Novell LANs. Another vendor-specific password protocol is ARAP (AppleTalk Remote Access Protocol), with a double challenge-response authentication mechanism that goes CHAP one better by making the security server authenticate itself to the client as well. In addition, there are subtle variations in how the PAP protocol works with Windows NT/2000/2003.

Security comes at a cost—mostly in the form of increased inconvenience to users, but there’s also additional expense to deploy and administer security measures. For example, CHAP requires some extra hardware and expertise, and token-cards are cumbersome to deploy. Can you imagine the giant Internet service provider AOL mailing token-cards to 


Figure 8-9.  CHAP authentication doesn’t send the password over the network.

every new user and administering a token database of one-time passwords? The added expense and logistical complexity of advanced authentication protocols have discouraged their adoption.

PAP is by far the most widely used authentication protocol because it’s simple for users and inexpensive for network operators. When you log into the Internet from home, you’re almost certainly going through a PAP mechanism. Corporate internetworks are more likely to use CHAP, while token-cards are mainly used to protect high-security networks in the military, R&D, or banking. From an ISP’s standpoint, preventing a hacker from gaining free Web access isn’t worth the trouble and expense of replacing PAP with a better authentication technology.

{mospagebreak title=Methods and Types}

Certain pieces must be put in place before security can be enforced. As you just saw, the access device must be configured to query one or more security servers for authenticationand authorization, and the user database must have profiles containing attributes that define what the user is permitted to do on the network. But what exactly happens when the query hits the TACACS+ or RADIUS database? What steps are taken to verify the user’s identity and figure out what services that person is permitted?

AAA command statements in an access device’s config file tell the device what to do when a user tries to log in. The root AAA commands authenticate, authorization, and accounting are used in conjunction with various keywords to code config file instructions on how connection attempts are to be handled. As mentioned earlier, these instruction parameters are modular in that they can be applied per user and per service. The instructions are implemented in the access device’s config file using methods and types.

  • A method is a prepackaged computer program that performs a specific function. For example, radius is a method to query a RADIUS server.
  • A type is the entity to which the method applies. For example, a radius method is applied to a ppp type so that when a user attempts to make a connection using the PPP protocol, the access device queries its RADIUS server to authenticate the person’s identity.

Because there are almost always multiple security parameters set for a device, AAA configurations are referred to as named method lists. They’re called named methods because they are named by the administrator in the device config file and applied to one or more specific secured entity types. Figure 8-10 shows how named method lists and types work together to enforce security.

 
Figure 8-10.  Named method lists enforce security policies in access device interfaces. 


NOTE: There are unnamed methods in the form of the default method list. If an interface or line has no named method list configured, a default method list is automatically put into force for it. To have no AAA security, it must be explicitly configured this way by using the none method. Cisco makes it hard to have no security in force.

Named method lists are entered into the config file of the access device being secured— usually an access server or a router. IOS applies methods in the sequence in which they appear in the configuration, initially trying the first method and then turning to the following ones until an ACCEPT or REJECT is returned. Figure 8-11 explains a typical named method list.

The last part of the AAA configuration in Figure 8-11 specifies lines because authentication deals with individual users. Traffic-based security can be applied on the interface level because the firewall or router monitors information in the header of each packet— a process that is done either to all or none of the packets passing through an interface. By contrast, user-based security controls individuals as they make a remote network connection via an access server, or log into IOS inside a router or switch within the network. Each of these two scenarios involves using a line.


Figure 8-11.  The basic parts of a device security configuration model

AAA Authentication Methods and Types AAA has several methods to authenticate user identity. Only one method may be used per user line (except when the Local method is configured as backup to one of the three client-server methods). Table 8-1 lists Cisco’s authentication methods.

The list of AAA methods in Table 8-1 varies slightly according to the password mechanism being used. Remember that AAA is an architectural model that must be adapted to differences in the way other vendors design their products. For example, AAA supports Guest and Auth-Guest methods for the password protocol in Apple’s ARAP.

It’s possible to configure different authentication methods on different lines within the same access device. For example, you might want to configure PPP connections to query the user database on a RADIUS server, but to check the local user database for login connections made from the console or AUX ports.

Connection Types Because authentication is applied to user lines, named authentication methods are applied to connection types. A connection type is the communications protocol used to make a connection. To explain, remote connections to ISPs and internetworks nowadays are usually PPP connections. But when a network administrator logs into IOS in order to work on a device, that connection is via a Telnet session (if over the network) or a terminal emulator (if over the console or AUX port). Table 8-2 explains the authentication types.

IOS Command Keyword

AAA Authentication Method

RADIUS

Authenticates using the RADIUS protocol and user database.

TACACS+

Authenticates using the TACACS+ protocol and user database.

Krb5

Authenticates using the Kerberos 5 protocol and user database. (Note: Kerberos can only be used with the PAP password protocol.)

Local

Authenticates using a user database stored in memory in the access device, or for backup if the security server does not respond.

Enable

Authenticates using Enable Secret passwords in the access device’s config file.

If-needed

Does not require authentication if the user has already been authenticated on a VTY or TTY line.

None

Uses no authentication.

Table 8-1. Authentication Methods in IOS

 

IOS Command Keyword

AAA Authentication Type

Login

Line connections made to Ethernet or Token Ring network interfaces using Telnet, or to console or AUX ports using virtual terminal (VTY)

PPP

Dial-in line connections made to serial network interfaces

using Point-to-Point Protocol

SLIP

Dial-in line connections made to serial network

interfaces using Serial Line Internet Protocol

ARAP

Dial-in line connections made to serial network

interfaces using AppleTalk Remote Access Protocol

Table 8-2. Entity Types Secured by AAA Authentication Methods

The following example statement illustrates a serial interface on an access server being configured to use TACACS+ to authenticate persons making PPP network connections:

MyAccessServer(config)#aaa new-model
MyAccessServer(config)#aaa authentication ppp MyList tacacs+ local
MyAccessServer(config)#interface serial0
MyAccessServer(config-if)#ppp authentication pap MyList
MyAccessServer(config-if)#tacacs-server host 10.1.13.10
MyAccessServer(config-if)#tacacs-server key DoNotTell

The aaa new-model command activates (enables) the AAA inside the device’s IOS software. Then the statement specifies that a TACACS+ security protocol be used and that the local user database should be used if the TACACS+ server fails to respond. The interface serial0 command points the configuration to all lines on the access server’s serial network interface named serial0. The ppp authentication pap MyList tacacs+ local specifies that the PAP password protocol be used for PPP connections and applies the named method list MyList to be used as the test.

The next statement specifies that the TACACS+ server resides on the host computer at IP address 10.1.13.10. The next line specifies that the encryption key DoNotTell be used for all communications between the security server and the client access device being configured here. The shared encryption key also must be configured on the security server(s) with which the client access device will communicate.


NOTE: Three types of protocols play a major role in AAA: dial-in protocols such as PPP, security protocols such as RADIUS, and password protocols such as CHAP. Dial-in protocols are network protocols that handle signals over phone lines, keeping the IP packets together between the access server and the remote user. Security protocols provide the client-server messaging system to the centralized user database. Password protocols are relatively simple mechanisms to deal with the person logging in. Some dial-in protocols incorporate their own password protocol—ARAP, for example.

AAA Authorization Methods and Types AAA has five methods for authorization. There are actually six, but the none method is a request not to do any authorization procedure. Table 8-3 explains the AAA authorization methods. Each method is a keyword for use as an argument with the root aaa authorization command. These, in turn, are applied to secured entity types.

As mentioned, RADIUS and TACACS+ can coexist on the same access device. Depending on the connection being attempted and how the device is configured, the client will query either the RADIUS or the TACACS+ servers, which are separate user databases.

The if-authenticated command waives authorization if the user has already been authenticated elsewhere. This is important, because during a single session a user may make dozens of connections to entities secured by AAA authorization (such as IOS command modes), and it would be unwieldy for the client device to query the TACACS+ or RADIUS server each time.

IOS Command Keyword

AAA Authorization Method

TACACS+

Sends a message requesting authorization information from the TACACS+ server.

RADIUS

Sends a message requesting authorization information from the RADIUS server.

If-authenticated

Allows access to the requested function if the user has already been authenticated. (If here is the word if, as in “depending on,” not the mnemonic IOS uses for network interface in the config prompt.)

Local

Uses the local user database to execute the authorization

program.

Krb5-instance

Uses an instance defined in the Kerberos instance map.

None

Does not execute any authorization methods on this access device.

Table 8-3. AAA’s Six Named Methods for User Authentication

Generally, a device’s local user database contains only usernames and passwords. Remember that network devices don’t have hard disks, and they must store permanent information in NVRAM memory, already burdened with storing a boot image of IOS and even daily AAA accounting logs. For this reason, local user databases generally do not hold authorizations for users. Therefore, if a security server were unavailable when a user logged in, that person would likely be unable to access any services configured to require authorization. Figure 8-12 shows how a local user database coexists with the server database(s).

If no authorization is to be executed on a secured entity, this should be explicitly configured by using the none command. Otherwise, the IOS software will automatically put the default authorization methods into force. The four types of secured objects to which AAA authorization methods can be applied are explained in Table 8-4.

The four authorization entity types can be broken down into two pairs:

  • The EXEC and Command methods each deal with access to IOS commands.
  • The Network and Reverse Access methods both deal with connections, but those which go in different directions.

On Cisco access devices, the aaa authorization config-commands command is enabled by default. That way the device has security right out of the box, in case the administrator installs it without configuring security. The following example statement illustrates a router being configured to require authorization for any type of network connection. This would apply, for example, whether the connection was being made via a console TTY login, a Telnet VTY login, or a PPP dial-in login:


Figure 8-12.  A user database can be stored in the access device’s NVRAM for local use.

Type

AAA Authorization Type

Network

Applies method to network-related service requests, including direct Login connections (via console or AUX), Telnet connections (via IP or IPX), or dial-in connections (via PPP, SLIP, or ARAP).

Reverse Access

Applies method to Telnet sessions in which the user attempts to connect from the secured access device to another host—

a common maneuver by a hacker who has broken into a network device.

EXEC

Applies method to sessions in the User EXEC command mode and can be applied by user, date, and start and stop times.

Commands

Applies method to restrict access to specific commands. Command methods must be applied to an IOS command level group. There are two default groups, numbers 0 and 15 (user EXEC and privileged EXEC modes, respectively). The Command method can be applied by user, date, and start and stop times.

Table 8-4. IOS’s Four Authorization Types

MyRouter(config)# aaa new-mode
MyRouter(config)# aaa authorization network NetTeam tacacs+ local

The preceding command specifies that the TACACS+ security protocol be used to check users against the NetTeam named method list, and to use the local user database for backup. By default, this authorization is applied to all network interfaces on the device (as opposed to authentication methods, which must be applied to specific lines).

But, as mentioned earlier, sometimes having authorizations stored on the device itself isn’t practical. To accommodate this, the restriction could be loosened using the none command to allow a network connection if the TACACS+ server fails to respond:

MyRouter(config)# aaa authorization network NetTeam tacacs+ none

In the preceding command, the user’s identity must have already been authenticated with a password to get this far into the AAA configuration. The none command goes into effect only when the TACACS+ server fails to respond. The following code statement configures a somewhat more sophisticated authorization:

MyRouter(config)# aaa authorization commands 15 SeniorTechs MyRouter(config)# line vty 0 5
MyRouter(config-line)# authorization commands 15 SeniorTechs

The preceding statement shows an example of configuration by line, as opposed to network interface. Here, the six virtual terminal (VTY) lines are secured. In this example, the named method list SeniorTechs is declared as necessary for an administrator to use IOS command level 15 in this device. We mentioned earlier that the IOS level command can be employed to authorize the use of a group of commands. By default, all Privileged EXEC mode commands are grouped into level 15, and all User EXEC mode commands are grouped into level 0. Therefore, the preceding code snippet specifies that only administrators with user profiles configured with the SeniorTechs attributes will be permitted to use the Privileged EXEC commands.

{mospagebreak title=Method and Types Continued}

Accounting Methods and Types AAA accounting methods configure user activities to track within a secured access device. Accounting methods gather data from TACACS+ and RADIUS packets and log it into a file stored on the access device. The security server comes around each day and collects the data into a central AAA accounting database. Table 8-5 explains how the two work.

Notice that the only accounting methods are the security protocols themselves. This is because accounting data is, by default, collected for the entire device. The reason for the two methods is that the accounting data must travel either in TACACS+ or RADIUS packets to the server (AAA accounting isn’t done without servers).

AAA has five accounting secured entity types, slightly different from those for authorization. Table 8-6 explains them.

The system accounting keyword only collects a default set of variables. It cannot be configured to collect only certain events. The reason for this is that a system event simply happens—a user does not request permission to cause it. An example system event would be a network interface going down at 11:32:28 Tuesday, January 9, 2005. AAA accounting does not automatically associate the system event with a security transaction, but comparing accounting and authorization logs for that date and time would make it easy for a system administrator to figure out who the culprit was.

Like authorization, AAA accounting named method lists must be applied to all network interfaces they are meant to secure, and then applied to an indicated accounting type. For example, the MyRouter(config)# aaa accounting network tacacs+ command configures IOS to keep track of all SLIP, PPP connections made over a network interface that are authorized using TACACS+.

Command Keyword

AAA Accounting Method

TACACS+

Logs accounting information on TACACS+ in the CiscoSecure ACS database

RADIUS

Logs accounting information on RADIUS in the CiscoSecure ACS database

Table 8-5. AAA Accounting Uses One Method per Security Protocol

 

Command Keyword

AAA Accounting Type

Network

Applies method to network connections, usually a PPP connection, but methods can also be named for logins, SLIP, or ARAP connections.

EXEC

Provides information on all User EXEC mode terminal

sessions within the access device’s IOS environment. EXEC

accounting information can be collected by user, date, and start and stop times.

Commands

Provides information on any commands issued by users who are members of an IOS Privileged EXEC mode. Command accounting information can be collected by user, date, and start and stop times.

Connection

Provides information on all outbound connections attempted from the secured access device in sessions made using the Telnet, rlogin, TN270, PAD, and LAT terminal protocols.

System

Provides information about system-level events, such as reboots.

Table 8-6. AAA Accounting Types that Track Asset Usage for Five Secured Entity Types

Accounting is a little more complicated in how it tracks requests, though. AAA accounting relies on so-called accounting notices to gather data. An accounting notice is a special packet notifying the accounting method of an event. This information is recorded in the accounting log file for upload to the appropriate security server. One of three AAA accounting keywords must be used to specify exactly when during the service request process the notices are to be sent. The terminology can get a bit confusing, but Figure 8-13 will help you visualize how the three work:

  • Stop-only For minimal accounting. Has RADIUS or TACACS+ send a stop recording accounting data notice at the end of the requested service. Stop-only accounting is good only for tracking who went where. This is important information for security purposes.
  • Start-stop For more accounting. Has RADIUS or TACACS+ send a start accounting notice at the beginning of the requested service and a stop accounting notice at the end of the service. Start-stop accounting yields the elapsed time of a connection.
  • Wait-start For maximum accounting. Has RADIUS or TACACS+ wait until the start notice is received by AAA accounting before the user’s request process begins. Most regard wait-start as overkill and an inconvenience to users, so its use is limited to very sensitive services.


Figure 8-13.  AAA accounting can use any of the three methods to track user activity.

To select a method, include any one of the three keywords as arguments to the root aaa accounting command in the configuration statement. The three options give differing levels of accounting control. For example, if an administrator requests entry into a secured device’s User EXEC mode, the stop-only process records only the end of the administrator’s session within User EXEC mode. The start-stop process records the beginning and the end of the session. The wait-start process ensures that no connection is made prior to the accounting notice having been received and acknowledged.

The following example shows an AAA accounting configuration. Lines 2, 3, and 4 show all three AAA functions being configured together, the normal practice in the real world.

MyAccessServer(config)# aaa new-model
MyAccessServer(config)# aaa authentication login NetTeam local
MyAccessServer(config)# aaa authentication ppp RemoteWorkers tacacs+ local
MyAccessServer(config)# aaa authorization network NetTeam tacacs+ local
MyAccessServer(config)# aaa accounting network WeWillBillYou
MyAccessServer(config)#
MyAccessServer(config)# tacacs-server host BigUnixBox
MyAccessServer(config)# tacacs-server key JustBetweenUs
MyAccessServer(config)#
MyAccessServer(config)# interface group-async 1
MyAccessServer(config-if)# group-range 1 16
MyAccessServer(config-if)# encapsulation ppp
MyAccessServer(config-if)# ppp authentication chap RemoteWorkers
MyAccessServer(config-if)# ppp authorization NetTeam
MyAccessServer(config-if)# ppp accounting WeWillBillYou

The accounting commands are woven in with the others, to give you an idea of how statements really look. As configured here, full start-stop accounting records will be logged for all network connections made by the network team through any of the 16 asynchronous ports on the device, MyRouter.

Exactly what gets logged depends on how the named method list WeWillBillYou is configured. Most network managers, at a minimum, would use the network command to account for connection times. Generally speaking, the command-oriented parameters exec and commands are useful only for security audits.

RADIUS and TACACS+ Attributes

A security protocol is largely defined by the attributes it supports. After all, they define the raw material used to operate the user-based security system. RADIUS and TACACS+ are separate protocols packaged into the AAA command structure within IOS. The major differences between the two come into play inside the user database, where each user has a security profile containing attributes that define what that person may do. As separate technologies, RADIUS and TACACS+ have their own attributes.

RADIUS is an open standard under the auspices of the IETF and defines nearly 60 attributes. We won’t list them all here, but Table 8-7 shows several to help you see what’s involved in user-based security.

Seventeen RADIUS attributes are so-called vendor-proprietary attributes. These are items that vendors can customize to extend functionality within their products. Table 8-8 shows a few Cisco extensions to give you an idea of what vendors like to customize.

RADIUS Attribute

Description

User-Name

The name of a person’s user profile account. For example, Anne Marie’s username might be “amarie.”

User-Password

The secret pass code created by the person.

CHAP-Password

The encrypted value returned during the challenge-handshake exchange. This is the username mixed with a random number called a challenge.

NAS-IP Address

The IP address of the access server requesting authentication. (Recall that NAS stands for network access server, the same thing as an access server.)

NAS-Port

The physical port number on the access server. This includes the various types of interfaces possible, such as asynchronous terminal lines, synchronous network lines, ISDN channels, and other types of interfaces.

Service-Type

The service requested or granted—for example, an administrator might request the enable command in IOS in order to enter the Privileged EXEC command mode.

Login-Port

The TCP port with which the user is to be connected—for example, port 80 for HTTP Web browsing.

Acct-Session-Id

A unique accounting identifier used to match start and stop notices in an accounting log file.

Acct-Session-Time

The number of seconds the user remained connected.

Acct-Authentic

The way the user was authenticated, whether by RADIUS, the local user database, TACACS+, or Kerberos.

Table 8-7. RADIUS Attributes Used to Enforce User-Based Security

Cisco-Specific RADIUS Attribute

Description

Password-Expiration

Specifies a time interval or event that forces the user to create a new password.

IP-Direct

The Cisco device will bypass all routing tables and send packets directly to a specified IP address. For example, IP-Direct might be used to make sure a user’s WAN connection goes through a firewall.

Idle-Limit

Specifies the maximum number of seconds any session may be idle.

Table 8-8. Cisco Extensions to the RADIUS Standard

TACACS+ has over 50 attributes (attribute-value pairs). While TACACS+ and RADIUS both support the three AAA functions, TACACS+ is more sophisticated. For example, it has attributes such as Tunnel-ID to help secure VPN connections. This is why internetworks that use RADIUS for authenticating dial-in users will frequently use TACACS+ for authorization and accounting. Table 8-9 shows example TACACS+ attributes to give you a feel for the protocol.

The sampling of AV pairs in Table 8-9 shows two areas in which TACACS+ is stronger than RADIUS. First, TACACS+ offers stricter internal security than RADIUS by locking down commands and access lists. The first thing a hacker would do upon breaking into an IOS device would be to make new entries into its access lists, which makes file transfers possible. These AV pairs not only help to stop hackers, they also let the network manager specify which devices, IOS commands, or access lists individual administrators may work with. Locking out certain team members helps avoid configuration errors.

The second area in which TACACS+ is stronger is protocol support. For example, TACACS+ has AV pairs to enhance security of VPNs, which are exploding in popularity. As would be expected, TACACS+ also has accounting attributes to go along with the areas where it expands beyond RADIUS. For example, the cmd= xAV pair lets you keep track of which IOS commands an administrator uses while working on a device. This can be useful information for diagnosing how a configuration error was made.

{mospagebreak title=Dynamic Access Lists}

Access lists are normally used to filter traffic at the packet level. In other words, when a connection is attempted through a router interface, packet headers are inspected for prohibited IP addresses or application port numbers, and traffic is passed or blocked. These are

TACACS+ AV Pair

Description

service=x

Specifies the connection service to be authorized or accounted. For example, aaa authorization service=ppp would be used to authorize a person to make a remote PPP connection to a device. Another example would be

service=shell to let an administrator get into a device’s

Privileged EXEC command mode.

protocol=x

A protocol is a subset of a service. For example, a PPP connection might use TN3270, VINES, Telnet, or other protocols. A key protocol nowadays is VPDN (Virtual Private Dialup Network). The AV pair protocol=vpdn would let a remote dial-in user establish an encrypted connection to the enterprise’s VPN network.

routing=x

Specifies whether routing updates may be propagated through the interface used for the connection.

priv-lvl=x

Specifies the IOS command mode the person may use. For this to work, commands must first be grouped using the level command.

acl=x

Restricts connection access lists on a device. Connection

access lists are also called reflexive access lists, and are used

to track sessions.

inacl=x, inacl#=x,

Four AV pairs restricting access to per-user inbound and

outacl=x, outacl#=x

outbound access lists placed on an interface.

tunnel-id

Specifies a username for establishing remote VPN connections.

gw-password=x

Specifies the password placed on the home gateway into the VPN. Must be used where service=ppp and

protocol=vpdn.

Table 8-9. TACACS+ Authentication and Authorization AV Pairs

called extended access lists, and they’re discussed in Chapter 9. To review here, such access lists are extended in that they can filter based on network application port numbers instead of just addresses. They’re also called static extended access lists, because the permit and deny commands are blindly enforced, regardless of the user. To make an exception for a particular person, an administrator would need to go into the router’s config file and edit the list for that interface.

Dynamic access lists are configured using so-called lock-and-key commands. By employing these, a user who would otherwise be blocked can be granted temporary access to a network or subnet via a Telnet session over the Internet.

The Telnet session is opened to a router configured for lock-and-key. The dynamic access list prompts the user for authentication information. As with other user-based security protocols, lock-and-key can be configured to check against a user database on the router itself (local), or against a user database maintained on a TACACS+ or RADIUS server. If authenticated, the user is automatically logged out of the Telnet session and can start a normal application such as a browser.

Lock-and-Key Using a Local User Database

The following sequence of code snippets shows how lock-and-key could be configured on a router using a locally maintained user authentication file. To start, a particular network interface on the router is declared along with a subnetted IP address. The ip access-group command places the just-named interface and networks under the control of access list 103:

MyRouter(config)# interface ethernet1
MyRouter(config-if)# ip address 209.198.208.30 255.255.255.0 MyRouter(config-if)# ip access-group 103 in

The keyword in specifies that access control be applied only to inbound connections (lock-and-key can also be used to restrict outbound connections).

In the following statement, the first entry of access list 103 allows only Telnet connections into the router. The second entry of access list 103 is ignored until lock-and-key is triggered whenever a Telnet connection has been established in the router. The keyword dynamic defines access list 103 as a dynamic (lock-and-key) list.

MyRouter(config)# access-list 103 permit tcp any host 209.198.207.2 eq telnet
MyRouter(config)# access-list 103 dynamic InCrowd timeout 60 permit ip any any

This is the key juncture. If so configured, an attempted Telnet connection to the router causes it to check against its local user database to see if the user and password are valid for lock-and-key access to the router. If validated, the timeout 60 permit ip any any statement gives the user 60 minutes to use the router as a connection between any two IP addresses.

Finally, an autocommand statement creates a temporary inbound access list entry (named InCrowd in the previous statement) at the network interface Ethernet1 and line 0 on the router. The temporary access list entry will time out after five minutes.

MyRouter(config)# line vty 0
MyRouter(config-line)# login local
MyRouter(config-line)# autocommand access-enable timeout 5

The temporary access list entry isn’t automatically deleted when the user terminates the session. It will remain configured until the timeout period expires.

Dynamic access lists can also be configured to authenticate users against a user database maintained on either a TACACS+ or RADIUS server. This, in effect, turns a router into an access server through which a user can gain entry into an internetwork, but only by logging in via a Telnet session.

It goes without saying, and is certainly a cliché, that network security is extremely important and necessary. However, understanding that it’s important and understanding how to actually implement it are two different things. To be sure, an entire book can be (and many have been) written on the subject of network security in general, and Cisco security in particular. The object of this chapter was to show you various details behind some of the important components in securing your internetwork. In Chapter 9, we’ll talk about some specific tools that Cisco offers in the realm of network access and security.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye