Remote access environments include VPN networks, wireless networks, and dial-in connections. VPN networks and wireless networking scenarios are covered in the next chapter. This chapter examines how to secure the remote dial-in connections coming into the corporate network. Often, corporate networks encompass both privately connected dial-in infrastructures (direct dial-in) and public data infrastructures (virtual private dial-in networks). Virtual private dial-in networks (VPDNs) refer to outsourced services from Internet service providers (ISPs) to deliver remote access to corporate users. The ISP recognizes that a particular client belongs to an enterprise and handles the client such that the network has a “private” feel to it. Dial-in access for a corporate network usually includes access between corporate branches located in different geographic regions, telecommuters, and mobile users.
The direct dial-in access can be by way of Public Switched Telephone Networks (PSTNs)—for example, modem lines or ISDN. VPDN network access is usually provided using Frame Relay, ATM, T1/T3 circuits, DSL, or cable modems. Figure 11-1 shows a sample dial-in environment; notice that there are branch offices connected with T1 lines, mobile users dialing in with modems, and telecommuters dialing in using ISDN BRI.
Another way corporations provide dial-in access is by partnering with an ISP and using the ISP's public infrastructure to provide network access. This concept of virtual private dial-in is shown in Figure 11-2. For this model to work in a secure manner, tunneling technologies, such as GRE, L2F, L2TP, or IPsec, must be used to provide secure access back to the corporate network.
The following sections look at both the direct dial-in and the virtual dial-in scenarios and examine ways that various protocols can be applied.
NOTE
The example configurations given are specific to Cisco Systems equipment; however, many of the functions shown can also be used with other vendors' products if they are available.
The dial-in environment has security considerations similar to those involved in securing a corporation's Internet access, discussed in the preceding chapter. It may be necessary to restrict access to certain areas of the corporate network depending on who the remote user is and from where the user is trying to obtain the connection. It is usually a good idea to incorporate firewall functionality into the dial-in access perimeters and to implement some kind of auditing and intrusion detection system to keep accurate connection and traffic statistics.
Regardless of how dial-in access is provided to the corporate network (as an extension using leased lines, ISDN, or plain old telephone service [POTS] networks, or as a connection from remote parts of the Internet), the main security concerns lie in the following areas:
Identifying the caller
Identifying the location of the caller
Identifying the destination of the call
Keeping track of accessed applications and data
Keeping track of the duration of a connection
Ensuring authenticated communication
Ensuring private communication
NOTE
For all equipment that is part of the dial-in infrastructure, the same security precautions should be used on the devices composing the corporate dial-in infrastructure as described in Chapter 9, “Securing the Corporate Network Infrastructure.”
A key element in allowing dial-in connectivity is to know who is accessing your corporate network by establishing an initial authentication mechanism. Authentication can be performed at the device level or at the user level.
Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP) are two common methods of sending IP packets over standard asynchronous serial lines with minimum line speeds of 1200 baud. Using SLIP or PPP encapsulation over asynchronous lines is an inexpensive way to connect PCs to a network. SLIP and PPP over asynchronous dialup modems allow a home computer to be connected to a network without the cost of a leased line. Dialup SLIP and PPP links can also be used for remote sites that need only occasional remote node or backup connectivity. Both public-domain and vendor-supported SLIP and PPP implementations are available for a variety of computer applications.
NOTE
PPP is a newer, more robust protocol than SLIP and provides more built-in security mechanisms. PPP is much more prevalent than SLIP in modern networks.
Most serial line connections make use of PPP encapsulation, which can use a variety of authentication mechanisms to establish the identity of a peer device. (Refer to Chapter 2, “Security Technologies.”) Figure 11-3 shows an example of a simple dial-in environment. Notice that only two remote branch offices need nonpermanent low-bandwidth or variable-bandwidth connections to the corporate network (and can therefore connect to the corporate campus using ISDN). The corporate network also accommodates a few mobile users dialing in with modem connections. Challenge Handshake Authentication Protocol (CHAP) is used as the primary authentication method with PAP as the fallback method. Examples 11-1 and 11-2 show the configurations of these routers.
Example 11-1. Configuration of the Corporate Access Router
hostname CORPORATE-NAS ! ! Ensure all vty, login, line, and username passwords are encrypted. ! In the configuration file using minimal encryption (type 7) ! unless configured as a secret which uses MD5 encryption (type 5). ! service password-encryption ! ! Disables access to minor TCP services such as echo, ! chargen, discard, and daytime. ! no service tcp-small-servers ! ! Disables access to minor UDP services such as echo, ! chargen, and discard. ! no service udp-small-servers ! !Define privileged access password. ! enable secret letmedostuff ! ! Define modem usernames and passwords. ! username merike password ilikeAbsolut username toivo password joekeg username staff password iamincontrol ! ! Define shared passwords for CHAP authentication with branch routers. ! username BRANCH1 password letmein username BRANCH2 password knockknock ! ! Define ISDN switch type. ! isdn switch-type primary-5ess ! ! Loopback interface is 'logical' subnet to which ! all dial-in users belong. ! interface loopback 0 ip address 144.254.200.253 255.255.255.0 ! ! Define local LAN interface. ! interface Ethernet 0/0 description Corporation LAN ip address 144.254.166.6 255.255.255.0 ! ! Configure framing commands. ! controller T1 1/0 framing esf clock source line primary linecode b8zs pri-group timeslots 1-24 ! ! Configure PRI. ! interface Serial1/0:23 description To Branch Routers no ip address encapsulation ppp ! ! Route incoming ISDN modem calls to the modem module. ! isdn incoming-voice modem ! ! To use dialer profiles just in case we expand to ! another PRI in the future ! dialer rotary-group 0 dialer-group 1 ! no fair-queue no cdp enable ! ! Set up a dialer profile. ! interface Dialer0 ! !Users will be on subnet defined under loopback 0. ! ip unnumbered Loopback0 no ip mroute-cache encapsulation ppp ! ! Assign IP addresses from pool named dialup. ! peer default ip address pool dialup dialer in-band ! ! Define which packets keep link up as defined by dialer list. ! dialer-group 1 no fair-queue no cdp enable ! ! Define CHAP authentication with PAP as fallback. ! ppp authentication chap pap ppp multilink ! ! Modem access configuration. ! interface Group-Async1 ! ! Users will be on subnet defined by loopback 0. ! ip unnumbered loopback0 encapsulation ppp ! ! User interactively selects to use box as a ! terminal server or a PPP router. ! async mode interactive ! ! Assign IP address from pool named dialup. ! peer default ip address pool dialup no cdp enable ! ! Define CHAP authentication with PAP as fallback. ! ppp authentication chap pap ! !Define all async lines to belong to this interface. ! group-range 1 16 ! ! Address pool for dial-in users ! ip local pool dialup 144.254.200.20 144.254.200.50 ! !configure routing ! router eigrp 109 redistribute static passive-interface Dialer0 network 144.254.0.0 no auto-summary ! ip route 192.150.41.0 255.255.255.0 Dialer0 ip route 192.150.42.0 255.255.255.0 Dialer0 ! ! Permit dialing and keep line up for IP traffic. ! dialer-list 1 protocol ip permit ! ! Physical console access accessible with any login name ! but requires correct password. ! line con 0 login password igetfullcontrol ! ! Modem RS-232 interface configuration ! line 1 16 ! ! Use local database to authenticate users. ! login local ! Present a login prompt but monitor packets. ! autoselect during-login ! ! If PPP packet detected, shift automatically into PPP mode. ! autoselect ppp ! ! Selects state machine for CD and DTR modem signals. ! modem InOut ! ! Allow connections to modem using any transport. ! transport input all ! ! No login prompt and no input access allowed through auxiliary port. ! line aux 0 no exec transport input none ! ! Virtual terminal line (Telnet) access using any login name ! but requires correct password. ! line vty 0 4 exec-timeout 20 0 login password letmein !
Example 11-2. Configuration of the Branch Routers
hostname BRANCH1 ! BRANCH2: hostname BRANCH2 ! service password-encryption no service udp-small-servers no service tcp-small-servers ! !Define shared passwords for CHAP authentication with Corporate NAS. ! For BRANCH2 router it would be: username CORPORATE-NAS password knockknock. ! username CORPORATE-NAS password letmein ! isdn switch-type basic-5ess ! ! Configure Ethernet interface. ! For BRANCH2 router IP address would be 192.150.42.1 255.255.255.0. ! interface Ethernet0 ip address 192.150.41.1 255.255.255.0 ! ! Configure BRI interface. ! interface BRI0 description ISDN TO CORPORATE ip unnumbered Ethernet0 encapsulation ppp dialer wait-for-carrier-time 60 dialer map IP 144.254.166.6 name CORPORATE-NAS speed 56 5551234 dialer load-threshold 100 either dialer-group 1 ppp authentication chap pap ! ! Configure routing. ! ip classless ip route 0.0.0.0 0.0.0.0 144.254.166.6 ip route 144.254.166.6 255.255.255.255 BRI0 ! dialer-list 1 list protocol ip permit ! ! Physical console access accessible using any login name ! but requires correct password. ! line con 0 login password igetfullcontrol ! ! No login prompt and no input access allowed through auxiliary port. ! line aux 0 no exec transport input none ! ! Virtual terminal line (Telnet) access using any login name ! but requires correct password. ! line vty 0 4 exec-timeout 20 0 login password letmein !
NOTE
Because the branch routers connect to the same device at the corporate office and provide the same functionality, their configurations are nearly identical. Only one configuration is given for the branch routers; differences to show what should be configured on the BRANCH2 router were shown in the comments.
Configuring PAP or CHAP authentication on individual devices is manageable in simple environments. In corporations with hundreds or thousands of dial-in connections, however, a more scalable approach must be used. To scale to a large number of users, consider incorporating either TACACS+ or RADIUS as a better way to provide a manageable database of users. Although CHAP and PAP can be used with RADIUS and TACACS+, a more flexible PPP authentication method would be to use EAP. Both TACACS+ and RADIUS provide for separate authentication, authorization, and accounting facilities. When you use either TACACS+ or RADIUS with EAP, the authentication mechanisms can take multiple forms, including these:
To enable TACACS+ on a Cisco network access server (NAS), enter the following commands:
aaa new-model tacacs-server host ip-address-of-tacacs-server tacacs-server key key
The key must be specified both here and in the TACACS+ server configuration file if you want the packets to be encrypted between the server and the client (the NAS).
To enable RADIUS on a Cisco NAS, enter the following commands:
aaa new-model radius-server host ip-address-of-radius-server radius-server key key
The key must be specified both here and in the RADIUS server configuration file if you want the password in the packet to be encrypted between the server and the client (the NAS).
Two steps are required to configure the actual authentication mechanisms: defining a method list and applying the method list to an appropriate interface.
The first step in configuring either TACACS+ or RADIUS authentication is to define a method list. A method list is just a list describing the authentication methods to be queried, in sequence, to authenticate a user. Method lists enable you to designate one or more security protocols to be used for authentication, thus ensuring a backup system for authentication in case the initial method fails. Cisco IOS Software uses the first method listed to authenticate users; if that method fails to respond, the Cisco IOS Software selects the next authentication method listed in the method list. This process continues until there is successful communication with a listed authentication method—or until all methods defined are exhausted. The method list must be applied to an interface before any of the defined authentication methods are performed.
NOTE
The Cisco IOS Software attempts authentication with the next-listed authentication method only when there is no response from the previous method. If authentication fails at any point in this cycle—meaning that the security server or local username database responds by denying the user access—the authentication process stops, and no other authentication methods are attempted.
The syntax for specifying a method list on the access server is as follows:
aaa authentication service {default | list-name} method-type1 method-type2 method-type3 method-type4
Table 11-1 lists the definable authentication services.
Table 11-1. AAA Authentication Services
Service | Description |
|---|---|
Sets authentication list for AppleTalk Remote Access (ARA) users' attempts to log in to the router. | |
Sets authentication list for NetWare Asynchronous Services Interface (NASI) users' attempts to log in to the router. | |
Sets authentication list for enable mode. | |
Sets authentication lists for character mode connections. | |
Sets authentication lists for PPP connections. |
You can specify up to four different authentication methods per method list for backup purposes. Table 11-2 lists the methods that you can use to authenticate a user for the defined service. Although all supported methods are listed, this discussion concentrates specifically on TACACS+ and RADIUS as the primary authentication methods.
Table 11-2. AAA Authentication Methods
Method Type | Description |
|---|---|
Use the enable password for authentication. | |
Use the line password for authentication. | |
Use the local database for authentication. | |
No authentication. | |
Use TACACS+ for authentication. | |
Use RADIUS for authentication | |
Use Kerberos 5 for authentication. | |
Use Kerberos 5 Telnet authentication protocol when using Telnet to connect to the router. If selected, this keyword must be listed as the first method in the method list. | |
Allow guest logins only if the user has already logged in to EXEC. | |
Allow guest logins. | |
Do not authenticate if the user has already been authenticated on a tty line. |
Not all services can use all methods. Table 11-3 shows which authentication methods can be defined for which services in Cisco IOS Software devices.
NOTE
In more recent versions of Ciso IOS Software, the keyword group was added to support a list of TACACS+ and RADIUS servers.
After defining the authentication method list, you must apply it to the appropriate interface or line.
Although you can use any name to define a method list, there is a reserved name known as default. The authentication methods defined within default are applied to any interface or line that does not have any other list linked to it. However, any named list overrides the default method list.
NOTE
To configure the Cisco IOS Software to check the local user database for authentication before attempting another form of authentication, use the aaa authentication local-override command. This command proves useful when you want to configure an override to the normal authentication process for certain personnel (such as system administrators).
The following examples show some typical uses of the aaa authentication command:
The following command specifies that a user trying to make a character mode login to the router must be authenticated by the TACACS+ server; if that server fails to respond, use the local database instead:
aaa authentication login ADMIN tacacs+ localThe following command specifies that a user attempting a PPP connection to the router must authenticate with the RADIUS server; if that fails, the user must provide the enable password:
aaa authentication ppp USER radius enableThe following command specifies that the default for character mode access is to use RADIUS unless otherwise stated:
aaa authentication login default radiusThe following command specifies that the default for packet mode access is to use TACACS+ authentication:
aaa authentication ppp default tacacs+
After a method list has been created, the next step is to link the method list to a line or interface. The following examples provide some typical uses.
Example 11-3 configures TACACS+ as the security protocol to be used for PPP authentication using the method list dialusers.
Example 11-3. PPP Authentication Using TACACS+
! Define a local user database. username merike secret LetMeIn username cathy secret MeToo ! ! Turn on aaa. ! aaa new-model ! ! Defines a method list, dialusers, to be used on serial interfaces running PPP. ! The keyword tacacs+ means that authentication will be done through TACACS+. ! If TACACS+ returns an ERROR of some sort during authentication, the keyword ! local indicates that authentication will be attempted using the local database ! on the network access server. ! aaa authentication ppp dialusers tacacs+ local tacacs-server host 144.254.9.5 tacacs-server key iamasecret ! ! Select line and apply the test method list to this line. ! interface serial 0 ppp authentication chap pap dialusers
Example 11-4 configures RADIUS as the security protocol to be used for PPP authentication using the method list default.
Example 11-4. PPP Authentication Using RADIUS
! Define a local user database. username merike secret LetMeIn username cathy secret MeToo ! ! turn on aaa ! aaa new-model ! ! Defines a method list, default, to be used on serial interfaces running PPP. ! The keyword default means that PPP authentication is applied by default to all ! interfaces. The if-needed keyword means that if the user has already ! authenticated by going through the ASCII login procedure, then PPP ! authentication is not necessary and can be skipped. ! If authentication is needed, the keyword radius means that authentication ! will be done through RADIUS. If RADIUS returns an ERROR of some sort during ! authentication, the keyword local indicates that authentication will be ! attempted using the local database on the network access server. ! aaa authentication ppp default if-needed radius local radius-server host 144.254.9.5 radius-server key iamasecret ! ! Select line and apply the default method list to this line. ! interface serial 0 ppp authentication default
WARNING
I have seen documentation that recommends using the keyword none as a backup authentication method in the event that the NAS cannot contact the TACACS+ or RADIUS server. Because none specifies that no authentication is required, it would create a large security risk. Instead, it is better to configure a backup mechanism that either uses a locally defined database or the enable password/secret.
Authorization is the process by which you can control what users can and cannot do. Often it is not enough to just establish a link connection on authentication. After the device or user has been authenticated, a subsequent authorization step may be required to permit access to a specified area of the network. Many corporate environments restrict access to some company branches or limit certain users to only particular areas of the network or particular applications.
Here are some reasons to use authorization requests:
If you choose to assign a particular IP address or an access list to a particular user or group of users
If you choose to allow a particular user or group of users to use Telnet but not to use rlogin
If you want a user to get his or her IP address from an address pool on the NAS
If you want to add callback functionality for added security and accounting
Any and all of these reasons require authorization for the particular service to be configured on the NAS; you must also configure the appropriate profile in the TACACS+ or RADIUS configuration file.
When either TACACS+ or RADIUS authorization is enabled, the NAS uses information retrieved from the user's profile (located either in the local user database or on the security server) to configure the user's session. After this is done, the user is granted access to a requested service only if the information in the user's profile allows it.
Much like configuring authentication, the first step in configuring either TACACS+ or RADIUS authorization is to define a method list. The method list defines the sequence in which the ways to authorize will be performed. If the initial method to authorize users fails, the next method listed in the method list is used. This process continues until there is successful communication with a listed authorization method, or until all defined methods are exhausted.
The syntax for specifying a named authorization method list on the access server is as follows:
aaa authorization service-type {default | list-name} method-list
NOTE
Authorization is bypassed for authenticated users who log in using the console line, even if authorization has been configured.
Table 11-4 lists the authorization service types supported.
Table 11-4. AAA Authorization Service Types
Service | Description |
|---|---|
Checks authorization for all network activities, including SLIP, PPP, and ARAP. | |
Determines whether the user is allowed to run an EXEC shell when logging in to the NAS. This keyword may cause the TACACS+ or RADIUS daemon to return user profile information such as autocommand, ACL, and so on. | |
Checks authorization for all commands at the specified privilege level. Command authorization attempts authorization for all EXEC mode commands (including global configuration commands) associated with a specific privilege level. Valid levels are 0 through 15. Level 1 is normal user EXEC commands; level 15 is the privileged level. | |
Applies to reverse-access connections, such as reverse Telnet sessions. |
Telnet is a standard terminal emulation protocol used for remote terminal connection. Normally, you log in to a NAS through a dialup connection and then use Telnet to access other network devices from that NAS. Sometimes, however, it is necessary to establish the Telnet connection in the opposite direction—from inside a network to a NAS on the network periphery—to gain access to modems or other devices connected to that NAS. Reverse Telnet enables users with dial-out capability to Telnet to modem ports attached to a NAS.
NOTE
It is important to control access to ports accessible through Reverse Telnet. Failure to do so exposes a security hole through which unauthorized users can gain free access to modems, from which they can trap and divert incoming calls or make outgoing calls to unauthorized destinations.
Authentication during Reverse Telnet is performed through the standard authenticated login procedure for Telnet. Typically, the user has to provide a username and password to establish either a Telnet or a Reverse Telnet session. Reverse Telnet authorization provides an additional (optional) level of security by requiring authorization in addition to authentication. When enabled, Reverse Telnet can use RADIUS or TACACS+ to authorize whether this user is allowed Reverse Telnet access to specific asynchronous ports (after the user successfully authenticates through the standard Telnet login procedure).
Reverse Telnet authorization offers the following benefits:
You can specify a variety of methods to carry out the authorization for the specified service type. Table 11-5 lists the supported methods.
Table 11-5. AAA Authorization Methods
NOTE
In more recent versions of Cisco IOS Software, the keyword group was added to support a list of TACACS+ and RADIUS servers.
Once defined, method lists must be applied to specific lines or interfaces before any of the defined methods are performed. The only exception is the default method list (named default). If the aaa authorization command for a particular authorization type is issued without specifying a named method list, the default method list automatically applies to all interfaces or lines except those that have a named method list explicitly defined. (A defined method list overrides the default method list.) If no default method list is defined, no authorization takes place.
WARNING
If authorization is not explicitly configured on the access server, everything is permitted by default. If authorization is configured, however, the default behavior is to deny everything. Before configuring authorization on the access server, be sure that you have configured an authenticated user who is authorized to do everything, or you may lock yourself out of the NAS.
Example 11-5 shows the configuration on a Cisco IOS NAS for authentication and authorization services to be provided by a RADIUS server. If the RADIUS server fails to respond, the local database is queried for authentication and authorization information.
Example 11-5. Authentication and Authorization with RADIUS
! Turn on aaa. ! aaa new-model ! ! Command defines a method list, staff, for login authentication. ! aaa authentication login staff local ! ! Defines the authentication method list dialup, which ! specifies that RADIUS authentication then (if the RADIUS server ! does not respond) local authentication will be used on ! serial lines using PPP. ! aaa authentication ppp dialup radius local ! ! Defines the network authorization method list named ! dialup2, which specifies that RADIUS authorization will be used ! on serial lines using PPP. If the RADIUS server fails ! to respond, then local network authorization will be performed. ! aaa authorization network dialup2 radius local ! ! Username and password to be used for the PPP CHAP ! username staff password letmein ! ! Set RADIUS parameters. ! radius-server host 144.254.9.6 radius-server key myRaDiUSpassWoRd ! ! Define and configure asynchronous interface group. ! interface group-async 1 group-range 1 16 encapsulation ppp ! ! Selects CHAP as the method of PPP authentication and applies ! the dialup method list to the specified interfaces. ! ppp authentication chap dialup ! ! Applies the dialup2 network authorization method list to the ! specified interfaces. ! ppp authorization dialup2 line 1 16 ! ! Command used to allow a PPP session to start up automatically. ! autoselect ppp ! ! Command used to display the username and password prompt without ! pressing the Enter key. After the user logs in, the autoselect ! function (in this case, PPP) begins. ! autoselect during-login ! ! Command used to apply the staff method list for login authentication. ! login authentication staff ! ! Command to configure modems attached to the selected lines to accept ! only incoming calls. ! modem dialin
Example 11-6 shows the syntax used in CiscoSecure, the Cisco TACACS+ Access Control Server, for its TACACS+ database. The syntax may change as more functionality is added; this example is given to show what you can configure on the TACACS+ server side. Most TACACS+ servers use similar functionality and often also have a simple-to-use graphical user interface that creates the appropriate database for you.
Example 11-6. The Syntax for the CiscoSecure Server
[unknown_user] = {
[user | group] = [<user name> | <group name>] {
password = [clear | chap | arap | pap | des] ["password"]
[from "dd mmm yy" until "dd mmm yy" | until "dd mmm yy"]
password = [skey | system | no_password] [from "dd mmm
yy" until "dd mmm yy" | until "dd mmm yy"]
password = file <"file name"> [from "dd mmm yy" until "dd
mmm yy" | until "dd mmm yy"]
privilege = [clear | des ] "<password>" [0-15]
privilege = [skey] [0-15]
default service = [permit | deny]
prohibit service = <service name>
default attribute = [permit | deny]
allow <"nas name"> <"port name"> <"rem_addr">
refuse <"nas name"> <"port name"> <"rem_addr">
expires = [<"month day year"> | <"dd mmm yy">]
valid = [<"month day year"> | < "dd mmm yy">]
member = <group name>
service = shell {
default attribute = [permit | deny]
default cmd = [permit | deny]
prohibit cmd = <command>
set acl = <access-class number>
set autocmd = <"command">
set noescape = [ true | false]
set nohangup = [ true | false]
set priv-lvl = [ 0-15 ]
set timeout = <minutes>
set callback-dialstring = <phone number>
set callback-line = <line number>
set callback-rotary = <rotary number>
set nocallback-verify = 1
cmd = <command> {
[deny | permit] <"command arg">
default attribute = permit
}
time = [<Mo, Tu, We, Th, Fr, Sa, Su 0000 - 2359> | <Any 0000 - 2359>]
}
service = ppp {
default protocol = [permit | deny]
prohibit protocol = <protocol>
protocol = lcp {
default attribute = [permit | deny]
set callback-dialstring = <phone number>
set callback-line = <line number>
set callback-rotary = <rotary number>
set nocallback-verify = 1
time = [<Mo, Tu, We, Th, Fr, Sa, Su 0000 - 2359> | <Any 0000 - 2359>]
}
protocol = vpdn {
set tunnel-id = <NAS name>
set ip-addresses = <"x.x.x.x x.x.x.x">
}
protocol = ip {
default attribute = [permit | deny]
set addr = <ip address>
set addr-pool = <ip local pool name>
set inacl = <input access-list number>
set outacl = <output access-list number>
set route = <"destination_address mask gateway">
set routing = [ true | false ]
time = [<Mo, Tu, We, Th, Fr, Sa, Su 0000 - 2359> | <Any 0000 - 2359>]
}
protocol = ipx {
default attribute = [permit | deny]
set acl = <access-list number>
time = [<Mo, Tu, We, Th, Fr, Sa, Su 0000 - 2359> | <Any 0000 - 2359>]
}
protocol = atalk {
default attribute = [permit | deny]
set zonelist = <zonelist>
time = [<Mo, Tu, We, Th, Fr, Sa, Su 0000 - 2359> | <Any 0000 - 2359>]
}
}
In large corporations, accounting and billing are essential for keeping track of who is accessing which corporate resources. Although it is mostly a network management function, keeping a historical database of dial-in usage patterns can alert the network administrator to any unusual activity and can serve as a historical paper trail when an intrusion does occur. The important parameters to keep track of include the following:
When AAA accounting is enabled, the NAS reports user activity to the TACACS+ or RADIUS security server (depending on which security method you have implemented) in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the security server. This data can be analyzed for network management, client billing, and auditing purposes.
Like authentication and authorization method lists, method lists for accounting define the way accounting is performed. Named accounting method lists enable you to designate a particular security protocol to be used on specific lines or interfaces for accounting services.
aaa accounting event-type {default | list-name} {start-stop | wait-start | stop-only | none} [broadcast][ method1 [method2]]
Table 11-6 lists the six different event types supported.
Table 11-6. AAA Accounting Event Types
You can specify when accounting records are to be sent by using one of the keywords in Table 11-7.
Table 11-7. AAA Accounting Records – Keywords Specifying When They Are to Be Sent
Cisco IOS Software supports the two methods for accounting described in Table 11-8.
Table 11-8. AAA Accounting Methods
Method | Description |
|---|---|
The NAS reports user activity to the TACACS+ security server in the form of accounting records. Each accounting record contains accounting AV pairs and is stored on the security server. | |
The NAS reports user activity to the RADIUS security server in the form of accounting records. Each accounting record contains accounting AV pairs and is stored on the security server. |
In the following sample configuration, RADIUS-style accounting is used to track all usage of EXEC commands and network services such as SLIP, PPP, and ARAP:
aaa accounting exec start-stop radius aaa accounting network start-stop radius
Accounting records are text lines containing tab-separated fields. The first six fields are always the same:
For central control of dial-in use and a centralized billing strategy, it is often the requirement of large corporations to use a callback mechanism. (See Figure 11-4.)
The steps for a callback are as follows:
Remote user dials into network access server.
The NAS disconnects the call.
The NAS authenticates the remote user.
If the user is authenticated, the NAS initiates a call to the remote user and a connection is established.
Configurations for both the NAS and the TACACS+ servers are shown in Examples 11-7 and 11-8.
Example 11-7. Configuration for NAS Server
NAS(config)# aaa new-model NAS(config)# tacacs-server host 144.254.5.9 NAS(config)# tacacs-server key secretkey NAS(config)# aaa accounting exec wait-start tacacs+ NAS(config)# aaa accounting network wait-start tacacs+ NAS(config)# service exec-callback NAS(config)# arap callback ! NAS(config)# aaa authentication login EXECCHECK tacacs+ NAS(config)# aaa authorization network tacacs+ NAS(config)# aaa authentication arap ARAPCHECK tacacs+ NAS(config)# aaa authorization network tacacs+ NAS(config)# aaa authentication ppp PPPCHECK tacacs+ NAS(config)# aaa authorization network tacacs+ ! NAS(config)# line 4 NAS(config-line)# login authentication EXECCHECK NAS(config-line)# arap authentication ARAPCHECK ! NAS(config)# int async 6 NAS(config-if)# ppp authentication chap PPPCHECK NAS(config-if)# ppp callback accept
Example 11-8. Configuration for TACACS+ Server
user = merike {
arap = cleartext AAAA
login = cleartext LLLL
chap = cleartext CCCC
pap = cleartext PPPP
opap = cleartext OOOO
service = ppp protocol = lcp {
callback-dialstring=67150
}
service = arap {
callback-dialstring=2345678
}
service = exec {
callback-dialstring=3456789
callback-line=7
nocallback-verify=1
}
}
AAA is the most scalable way of providing authentication, authorization, and accounting services for many remote dial-in scenarios. Cisco IOS Software has incorporated the use of AAA into two features:
Lock and key
Double authentication/authorization
Lock and key is a traffic-filtering security feature in Cisco IOS Software devices that dynamically filters IP protocol traffic. It can be used to authorize temporary access to specified areas of a corporate network. Lock and key is configured using IP dynamic extended access lists and can be used in conjunction with other standard access lists and static extended access lists.
When triggered, lock and key reconfigures the interface's existing IP access list to permit designated users to reach specified areas of the network. When it is finished, lock and key reconfigures the interface back to its original state.
For a user to gain access to a host through a router with lock and key configured, the user must first Telnet to the router. When a user initiates a standard Telnet session to the router, lock and key automatically attempts to authenticate the user. If the user is authenticated, he or she then gains temporary access through the router and can reach the destination host.
There are three possible ways to configure an authentication query process:
Configure a security server. Use a network access security server such as a TACACS+ server. This method allows for stricter authentication queries and more sophisticated tracking capabilities.
Router# login tacacsConfigure the username command. This method allows authentication from a local database on a per-user basis.
Router# username merike password LetMeInConfigure the password and login commands. This method is less effective than the first method because the password is configured for the port, not for the user. Therefore, any user who knows the password can authenticate successfully.
Router# password IAmAPassword Router# login local
A user at a remote site can use WAN technology—such as Asynchronous Transfer Mode (ATM), dial-on-demand routing (DDR), Frame Relay, ISDN, PPP, or X.25—to connect to the corporate office using lock and key. The WAN infrastrucure is presumed to be private due to being either a direct connection between corporate sites or through a trusted service provider network. Keep in mind that Telnet sends its passwords in the clear.
The following steps, also shown in Figure 11-5, describe the lock-and-key access operation:
A user opens a Telnet session to a border (firewall) router configured for lock and key. The user connects using the virtual terminal port on the router.
The Cisco IOS Software receives the Telnet packet, opens a Telnet session, prompts for a password, and performs a user authentication process. The user must pass authentication before access through the router is allowed. The authentication process can be done by the router or by a central access security server, such as a TACACS+ or RADIUS server.
When the user passes authentication, he or she is logged out of the Telnet session, and the software creates a temporary entry in the dynamic access list. (Per your configuration, this temporary entry can limit the range of networks to which the user is given temporary access.)
The user exchanges data through the router/firewall.
The software deletes the temporary access list entry when a configured timeout is reached or when the system administrator manually clears the entry. The configured timeout can either be an idle timeout or an absolute timeout.
NOTE
The temporary access list entry is not automatically deleted when the user terminates a session. The temporary access list entry remains until a configured timeout is reached or until the entry is cleared by the system administrator.
When lock and key is triggered, it creates a dynamic opening in the firewall by temporarily reconfiguring an interface to allow user access. While this opening exists, another host can spoof the authenticated user's address to gain access behind the firewall. Lock and key does not cause the address spoofing problem; the problem is only identified here as a concern to the user. Spoofing is a problem inherent to all access lists, and lock and key does not specifically address this problem.
To prevent spoofing, you can configure network data encryption as described in the last section of this chapter. Configure encryption so that traffic from the remote host is encrypted at a secured remote router and is decrypted locally at the router interface that provides the lock-and-key service. You want to ensure that all traffic using lock and key is encrypted when entering the router. In this way, no hackers can spoof the source address because they are unable to duplicate the encryption or to be authenticated (a required part of the encryption setup process).
The first lock-and-key example is shown in Figure 11-6. This figure shows how to configure lock-and-key access from a telecommuter to a NAS, with authentication occurring locally at the campus NAS. Lock and key is configured on the BRI 0 interface of the NAS.
Example 11-9 shows the configuration.
Example 11-9. Lock-and-Key Configuration
! Telecommuter who will come in using lock-and-key. ! username telecommuter password 7 0758364708452A ! ! Define ISDN switch type. ! isdn switch-type basic-dms100 ! ! Configure interfaces. ! interface ethernet 0 ip address 144.254.166.6 255.255.255.0 interface BRI0 ip unnumbered ethernet 0 encapsulation ppp dialer idle-timeout 3600 dialer wait-for-carrier-time 100 dialer map ip 171.73.34.33 name merike dialer-group 1 isdn spid1 8316333715291 isdn spid2 8316339371566 ppp authentication chap ip access-group 101 in ! ! Configure routing. ! ip classless ip route 0.0.0.0 0.0.0.0 144.254.166.6 ip route 144.254.166.6 255.255.255.255 BRI0 ! ! Allows Telnet from telecommuter to this router. ! access-list 101 permit tcp any host 144.254.166.6 eq telnet ! ! Allows telecommuter to have access anywhere inside campus after Telneting ! to router and successful authentication. ! access-list 101 dynamic telecommuter timeout 120 permit ip any any ! dialer-list 1 protocol ip permit line vty 0 login local autocommand access-enable timeout 5
The first access-list entry allows only Telnet sessions into the router. The second access-list entry is always ignored until lock and key is triggered.
After a user Telnets into the router, the router attempts to authenticate the user. If authentication is successful, autocommand executes and the Telnet session terminates. The autocommand command creates a temporary inbound access list entry at the BRI 0 interface, based on the second access-list entry (telecommuter). This temporary entry expires after 5 minutes, as specified by the timeout value.
NOTE
Although the preceding example uses an Ethernet interface to provide the unnumbered address to the BRI, in many cases you would instead use a loopback. A loopback interface is usually configured on devices that have multiple exit interfaces, and WAN links will typically use the IP address assigned to the loopback interface to provide the unnumbered address. This alleviates the potential problem of having an unreachable device should any single exit interface become unavailable.
The second lock-and-key example is shown in Figure 11-7. This example shows how to configure lock-and-key access for a branch router, with authentication on a TACACS+ server. Lock-and-key access is configured on the BRI 0 interface of the NAS.
Example 11-10 shows the configuration on the NAS.
Example 11-10. Lock-and-Key Example Using AAA
aaa new-model aaa authentication login lockkey tacacs+ enable aaa authorization exec tacacs+ ! isdn switch-type basic-dms100 ! interface Ethernet0 ip address 144.254.166.6 255.255.255.0 ! interface BRI0 ip unnumbered Ethernet0 ip access-group 101 in no ip mroute-cache encapsulation ppp dialer idle-timeout 300 dialer map ip 192.150.42.1 name Branchrouter 97328866 dialer-group 1 isdn spid1 8316333715291 isdn spid2 8316339371566 no fair-queue compress stac ppp multilink ! router eigrp 100 network 144.254.0.0 ! ip classless ip route 0.0.0.0 0.0.0.0 192.150.42.1 ip route 192.150.42.1 255.255.255.255 BRI0 ! ! Allows Telnet from the branch hosts to this router. ! access-list 101 permit tcp any host 144.254.166.6 eq telnet ! ! Allows anybody inside campus to have access to the branch resources. ! access-list 101 permit tcp any 144.254.0.0 0.0.255.255 established ! ! Allows certain hosts inside to be accessed from the branch without authentication. ! access-list 101 permit ip any host 144.254.120.6 access-list 101 permit ip any host 144.254.120.8 ! ! Allows for branch to have access anywhere inside campus after Telneting ! to router and successful authentication. ! access-list 101 dynamic Branch timeout 5 permit ip any any ! tacacs-server host 144.254.5.9 tacacs-server key secretkey ! dialer-list 1 protocol ip permit ! line con 0 exec-timeout 2 30 password letmein line vty 0 4 exec-timeout 15 0 ! Once user logs in, authentication is by way of TACACS+. login authentication lockkey
The configuration on TACACS+ is illustrated in Example 11-11.
Example 11-12 shows the third lock-and-key example. This example shows a configuration in which two users can have different lock-and-key dynamic access list configurations and different access privileges. If these two users access the device from the same interface, only the first configured dynamic access control list is activated.
Example 11-12. Lock and Key with Multiple Access Privileges
interface Ethernet0/0 ip address 144.254.163.2 255.255.255.0 ip access-group 161 in no ip directed-broadcast no ip mroute-cache ! interface Ethernet0/1 ip address 144.254.166.8 255.255.255.0 ip access-group 141 in no ip directed-broadcast no ip mroute-cache ! access-list 141 dynamic genesis permit ip any any log access-list 141 permit ip any host 224.0.0.10 access-list 141 permit ip any any access-list 161 dynamic new permit tcp any any log access-list 161 permit ip any any
When a remote user dials in to a local corporate perimeter host (a NAS or router) over PPP, CHAP or PAP is often used to authenticate the user. However, both of these authentication methods rely on a secret password (the “secret”) that must be stored on the local host and either remembered by a user or saved on the remote host. If either host ever comes under the control of a network attacker, the secret password is compromised.
Consider a corporate user who often uses a laptop computer to log in to the corporate enterprise network, which uses only CHAP for authentication. If the laptop computer is stolen, the computer can still connect to the corporate network if the correct dial-in script is executed. For this reason alone, passwords should never be stored in dial-in scripts.
With the double-authentication feature, there are two authentication/authorization stages. These two stages occur after a remote user dials in and a PPP session is initiated.
In the first stage, the user logs in using the remote host name. CHAP (or PAP) authenticates the remote host, and then PPP negotiates with RADIUS or TACACS+ to authorize the remote host. In this process, the network access privileges associated with the remote host are assigned to the user.
NOTE
You should restrict authorization at this first stage to allow only Telnet connections to the local host. This arrangement prevents an attacker from using the device authentication to access the NAS and to then Telnet from the NAS to other parts of the network.
In the second stage, the remote user must Telnet to the NAS to be authenticated. When the remote user logs in, the user must be authenticated with the specified login authentication. The user then must enter the access-profile command to be re-authorized. When this authorization is complete, the user has been double authenticated and can access the network according to per-user network privileges.
WARNING
Double authentication can cause certain undesirable events if multiple hosts share a PPP connection to a NAS. If user Aiki initiates a PPP session and activates double authentication at the NAS, any other user automatically has the same network privileges as Aiki until Aiki's PPP session terminates. This happens because Aiki's authorization profile is applied to the NAS's interface during the PPP session; any PPP traffic from other users uses the PPP session that has already been established.
Another undesirable event can occur if, in the middle of Aiki's PPP session, another user, Jim, executes the access-profile command. This action results in a re-authorization; Jim's authorization profile is applied to the interface, replacing Aiki's profile. This replacement can disrupt or halt Aiki's PPP traffic or grant Aiki additional authorization privileges she should not have.
Example 11-13 shows the configuration on a Cisco NAS. The first three lines configure a TACACS+ server. The next two lines configure PPP and login authentication, and the last two lines configure network and EXEC authorization. The last line is necessary only if the access-profile command will be executed as an autocommand.
The sample configuration in Example 11-14 shows authentication/authorization profiles on the TACACS+ server for the remote host psycho and for three users (usernames Merike-default, Aiki-merge, and Tom-replace). The configurations for these three usernames show different configurations that correspond to the three different forms of the access-profile command. The three user configurations also show how to set up autocommand for each form of the access-profile command.
Example 11-14. Authentication/Authorization Profiles on the TACACS+ Server
key = "mytacacskey"
default authorization = permit
#
# This allows the remote host to be authenticated by the local host
# during fist-stage authentication, and provides the remote host
# authorization profile.
#
user = psycho
{
login = cleartext "welcome"
chap = cleartext "welcome"
service = ppp protocol = lcp {
interface-config="ip unnumbered ethernet 0"
}
service = ppp protocol = ip {
# It is important to have the hash sign
# and some string after it. This indicates
# to the NAS that you have a per-user config.
inacl#3="permit tcp any 192.150.42.0 0.0.0.255 eq telnet"
inacl#4="deny icmp any any"
route#5="192.150.42.0 255.255.255.0"
route#6="192.150.41.0 255.255.255.0"
}
}
# - Without arguments access-profile removes any access-lists it can find
# in the old configuration (both per-user and per-interface), and makes sure
# that the new profile contains ONLY access-list definitions.
#
user = Merike-default
{
login = cleartext "welcome"
chap = cleartext "welcome"
service = exec
{
# this is the autocommand that
# executes when Merike-default logs in
autocmd = "access-profile"
}
service = ppp protocol = ip {
# Put whatever access-lists, static routes, and so on here
# If you leave this blank, the user will have NO IP
# access-lists (not even the ones installed prior to
# this)
inacl#3="permit tcp any host 144.254.166.10 eq telnet"
inacl#4="deny icmp any any"
}
}
# With the 'merge' option, all old access-lists are removed (as before),
# but then (almost) all AV pairs are uploaded and installed. This
# will allow for uploading any custom static routes, filters, and so on,
# that the user may need in his or her profile. This needs to be used with
# care, as it leaves open the possibility of conflicting configurations.
#
user = Aiki-merge
{
login = cleartext "welcome"
chap = cleartext "welcome"
service = exec
{
# this is the autocommand that executes when Aiki-merge logs in
autocmd = "access-profile merge"
}
service = ppp protocol = ip
{
# Put whatever access-lists, static routes, and so on here
# If you leave this blank, the user will have NO IP
# access-lists (not even the ones installed prior to
# this)
inacl#3="permit tcp any any"
route#2="144.254.0.0 255.255.0.0"
}
}
#- With the 'replace' option,
# ALL old configuration is removed and ALL new configuration is installed.
#
# One caveat: access-profile checks the new configuration for address-pool and
# address AV pairs. As addresses cannot be renegotiated at this point, the
# command will fail (and complain) when it encounters such an AV pair.
# Such AV pairs are considered to be "invalid" for this context.
#-------------------------------------------------------------------------------
user = Tom-replace
{
login = cleartext "welcome"
chap = cleartext "welcome"
service = exec
{
# this is the autocommand that executes when Tom-replace logs in
autocmd = "access-profile replace"
}
service = ppp protocol = ip
{
# Put whatever access-lists, static routes, and so on here
# If you leave this blank, the user will have NO IP
# access-lists (not even the ones installed prior to
# this)
inacl#3="permit tcp any any"
inacl#4="permit icmp any any"
route#2="171.71.73.0 255.255.255.0"
}
}
You can make the double-authentication process easier for users by implementing automated double authentication. Automated double authentication provides all the security benefits of double authentication, but offers a simpler, more user-friendly interface for remote users. With double authentication, a second level of user authentication is achieved when the user Telnets to the NAS or router and enters a username and password. With automated double authentication, the user does not have to Telnet to the NAS; instead, the user responds to a dialog box that requests a username and password or personal identification number (PIN).
Automated double authentication is configured with the following command:
ip trigger-authentication [timeout seconds] [port number]
The default timeout is 90 seconds, and the default UDP port number is 7500.
NOTE
To use the automated double-authentication feature, the remote user hosts must be running a companion client application. As of Cisco IOS Software Release 12.0, the only client application software available is the Glacier Bay application server software for PCs.
Example 11-15 shows a complete configuration file for a Cisco IOS Software router with automated double authentication.
Example 11-15. Complete Configuration File for Automated Double Authentication
hostname myrouter ! no service password-encryption ! ! Set up local user database access. ! username merike secret LetMeIn username cathy secret MeToo ! ! The following command enables AAA: ! aaa new-model ! ! The following command enables user authentication via the TACACS+ server: ! aaa authentication login default tacacs+ local aaa authentication login console enable ! ! The following command enables device authentication via the TACACS+ server: ! aaa authentication ppp default tacacs+ ! ! The following command causes the remote user's authorization profile ! to be downloaded from the TACACS+ server to the Cisco router when required: ! aaa authorization exec tacacs+ ! ! The following command causes the remote device's authorization profile ! to be downloaded from the TACACS+ server to the Cisco router when required: ! aaa authorization network tacacs+ ! enable secret thisisasecret ! ip host twiggy 192.150.42.101 ip host minky 192.150.42.103 ip host itchy 192.150.42.105 ip domain-name mycompany.com ip name-server 144.254.5.27 ! ! The next command globally enables automated double authentication: ! ip trigger-authentication timeout 60 port 7500 ! isdn switch-type basic-5ess ! ! interface Ethernet0 ip address 144.254.166.10 no ip route-cache no ip mroute-cache no keepalive ntp disable no cdp enable ! interface Virtual-Template1 ip unnumbered Ethernet0 no ip route-cache no ip mroute-cache ! ! Automated double authentication occurs via the ISDN BRI interface BRI0: ! interface BRI0 ip unnumbered Ethernet0 ! ! The following command turns on automated double authentication at this ! interface: ! ip trigger-authentication ! ! PPP encapsulation is required: encapsulation ppp no ip route-cache no ip mroute-cache dialer idle-timeout 500 dialer map ip 192.150.42.1 name Branch2 5554768 dialer-group 1 no cdp enable ! ! **The following command specifies that device authentication occurs via PPP ! CHAP: ppp authentication chap ! router eigrp 109 redistribute static network 144.254.0.0 no auto-summary ! ip default-gateway 172.18.1.1 no ip classless ip route 192.150.42.0 255.255.255.0 Bri0 ! ! Virtual profiles are required for double authentication to work: ! virtual-profile virtual-template 1 dialer-list 1 protocol ip permit no cdp run ! ! configure TACACS+ server ! tacacs-server host 144.254.5.9 port 1049 tacacs-server timeout 90 tacacs-server key mytacacskey ! line con 0 exec-timeout 10 0 login authentication console line aux 0 no exec transport input none line vty 0 4 exec-timeout 10 0 login authentication default !
When using a virtual dial-in environment in which dial-in access is provided by using an ISP's public infrastructure, you must take additional security measures to ensure that the data traversing the public network is not modified in transit and is kept private. You can implement these additional security measures using a combination of various tunneling techniques, including GRE, L2F, L2TP, IPsec, and CET. (CET is a proprietary Cisco encryption mechanism and is not used very often in favor of IPsec. The end of life for CET has been announced and Cisco IOS Software 12.1 is the last version to support it; however, because it exists, it is briefly discussed here.)
NOTE
The PPTP, L2F, and L2TP tunneling technologies were discussed in Chapter 2. These techniques were specifically designed to add more security services to virtual dial-in environments. They all accomplish nearly the same functions of providing flexibility of authenticating dial-in clients with an ISP NAS (using either local or remote security servers), creating a virtual tunnel between the ISP NAS and a corporate home gateway, and finally negotiating a virtual PPP session between the originating client and the home gateway. Because extensions for multiprotocol PPP environments exist, using these mechanisms allows for native routing of non-IP protocols such as AppleTalk and IPX. If you want to add IP packet authentication and confidentiality on top of the multiprotocol data tunnel, however, you must encapsulate these protocols in an IPsec tunnel.
Although CET is a Cisco proprietary IP encryption technology that is not widely used, some details are discussed here. IPsec should be the protocol used to provide security services for IP-based networks.
The Generic Routing Encapsulation (GRE) protocol encapsulates various network protocols inside IP tunnels. With GRE tunneling, a router at each site encapsulates protocol-specific packets in an IP header, creating a virtual point-to-point link to routers at other ends of an IP cloud, where the IP header is stripped off. GRE is capable of handling the transportation of multiprotocol and IP multicast traffic between two sites that have only IP unicast connectivity. GRE tunneling does not provide any security services but is required in instances where the IP encryption technology does not support IP multicast traffic and there is a requirement to support it, such as for certain routing protocols. If data origin authentication and confidentiality is required when using GRE, however, the packets can be protected using IPsec.
WARNING
Use GRE tunneling with care because it can disguise the nature of a link, making it look slower, faster, or more or less costly than it may actually be in reality. This change can cause problems with routing behavior. It also takes up more CPU cycles than does routing a protocol natively.
GRE packets using IPv4 headers use the IP protocol type 47. If the packet encapsulated within GRE is also IPv4, the GRE header's protocol type field is set to 0x800. This may be important for filtering considerations. Some firewalls (such as the PIX firewall) do not have the capability to support GRE, but it could be set up to allow GRE traffic to pass through it.
CET is a proprietary security solution introduced in Cisco IOS Software Release 11.2. It provides network data encryption at the IP packet level and implements the following standards:
The following is a simple configuration example of two routers that use CET to encrypt/decrypt Telnet and World Wide Web traffic between the branch office and the corporate campus network. Example 11-16 shows the configuration of the branch router configuration commands, and Example 11-17 shows the configuration commands on the campus NAS.
Example 11-16. Branch Router Configuration Commands
hostname Branch_router ! ! Define encryption algorithm. ! crypto map toNAS 10 set algorithm 56-bit des cfb-64 ! ! Encryption peer is device named NAS. ! set peer NAS ! ! Encrypt/decrypt what is defined in this access list. ! match address 101 ! interface Ethernet 0 ip address 192.150.42.1 255.255.255.0 ! ! Configure branch interface to NAS which will ! use encrypted communication. ! interface Bri 0 ip address unnumbered Ethernet 0 encapsulation ppp dialer map ip 144.254.5.20 name NAS dialer-group 1 ppp authentication chap crypto map toNAS ! ! Define traffic to start dial or keep isdn line up. ! dialer-list 1 protocol ip permit ! ! encrypt/decrypt telnet traffic between branch and campus ! access-list 101 permit ip 144.254.0.0 0.0.255.255 192.150.42.0 0.0.0.255 eq telnet ! ! Encrypt/decrypt WWW traffic between branch and campus. ! access-list 101 permit ip 144.254.0.0 0.0.255.255 192.150.42.0 0.0.0.255 eq http
Example 11-17. NAS Configuration Commands
hostname NAS ! Define encryption algorithm. ! crypto map toBranch 10 set algorithm 56-bit des cfb-64 ! ! Encryption peer is device named Branch_router. ! set peer Branch-router ! Encrypt/decrypt what is defined in this access list. ! match address 101 ! interface Ethernet 0 ip address 144.254.5.20 255.255.255.0 ! ! Configuring PRI, which will use encrypted communication ! interface Serial0:23 description to the Branch crypto map toBranch ! ! Encrypt/decrypt Telnet traffic between branch and campus. ! access-list 101 permit ip 192.150.42.0 0.0.0.255 144.254.0.0 0.0.0.255 eq telnet ! ! Encrypt/decrypt WWW traffic between branch and campus. ! access-list 101 permit ip 192.150.42.0 0.0.0.255 144.254.0.0 0.0.0.255 eq http
Figure 11-8 shows a more complex scenario in which a branch router located in Estonia is connecting to the corporate network in Vancouver over the Internet.
The following security policy is defined for this scenario:
Private addresses are used for the remote branch router and the corporate network.
Communications from the remote branch to the corporate network must be private and must be encrypted.
All infrastructure devices should have authenticated access.
The policy is implemented as follows:
A tunnel is constructed between the home gateway and the remote branch router. The function of the tunnel is to provide connectivity from the branch office private network address space into the corporate network private address space.
When configuring the tunnel interface between the two routers, the source and destination of the tunnel must be registered IP addresses.
The remote router runs NAT so that communications from the remote router to the Internet are routed locally, and only communications to the corporate network go across the encrypted tunnel.
The corporate home gateway router has two separate links to the firewall: one over a network that has a registered IP address, and the other over a network with the private network address.
A filter is placed on the corporate home gateway router to ensure that only VPN routes are passed on the private network link to the firewall (access list 120).
Device authentication is by way of a local database. Passwords are the same (because this scenario deals with only a limited number of devices) but are changed every 2 months.
Example 11-18 and Example 11-19 show the configurations of the Vancouver home gateway and the Estonia branch router, respectively.
Example 11-18. Vancouver Home Gateway Configuration
hostname Vancouver-gw ! ! Ensure all vty, login, line, and username passwords are encrypted ! using minimal encryption (type 7) unless configured as a secret ! which t uses MD5 encryption (type 5). ! service password-encryption ! ! Disable access to minor TCP services such as echo, ! chargen, discard, and daytime. ! no service tcp-small-servers ! ! Disable access to minor UDP services such as echo, ! chargen, and discard. ! no service udp-small-servers ! !Define privileged access password. ! enable secret letmedostuff ! ! Local database for device authentication access ! username admin password ComeOnIN ! ! Change the encryption key every 24 hours. ! crypto cisco key-timeout 1440 ! ! Public key for the remote router Eesti ! crypto key pubkey-chain dss named-key Eesti signature serial-number 07124346 key-string 44EF0246 9EF0E99E 79BA3629 142D4C0E 923D02EF 5B358A1C 089468CE 8B3562F8 398692A8 A38D99F8 0703913C 2F51F7B6 9217128C 29BA6251 AA77E442 2EE00A63 quit ! ! Crypto map for the connection between Vancouver-gw and Eesti; ! this defines the remote crypto peer, what traffic to encrypt. ! It is applied to the tunnel and physical interfaces. ! crypto map Vancouver-to-Eesti 10 set peer Eesti match address 140 ! ! Tunnel interface from Vancouver-gw to remote branch router (Eesti). ! The tunnel interface is unnumbered to preserve address space; it could also ! use IP addresses from the private network space. ! The source of the tunnel and the destination of the tunnel are ISP registered ! addresses because the tunnel end points must be reachable across the Internet. ! interface Tunnel100 description tunnel to branch router Eesti ip unnumbered FastEthernet5/0 no ip directed- broadcast tunnel source Serial2/0 tunnel destination 207.9.31.1 crypto map Vancouver-to-Eesti ! ! Apply the crypto map to the serial interface. ! interface Serial2/0 description connection to ISP1 – DS3 ip address 207.1.1.1 255.255.255.252 no ip directed-broadcast framing c-bit cablelength 50 dsu bandwidth 44210 crypto map Vancouver-to-Eesti ! interface FastEthernet3/0 description network for Internet traffic ip address 207.1.2.1 255.255.255.240 no ip directed-broadcast full-duplex ! interface FastEthernet5/0 description network for private network traffic ip address 172.26.71.1 255.255.255.252 no ip directed-broadcast full-duplex ! ! Apply acccess list for this interface so that only private network ! traffic traverses this link. ! ip access-group 120 in ! ! configure routing ip classless ! ! Default route to ISP ip route 0.0.0.0 0.0.0.0 207.1.1.2 ! ! Routes for the corporate intranet for use by the VPN routers: ip route 172.20.0.0 255.255.0.0 172.26.71.2 ip route 172.26.0.0 255.255.128.0 172.26.71.2 ! Route to the remote branch network on router Eesti: ip route 172.26.129.0 255.255.255.0 Tunnel100 ! Route to the NAT pool on the firewall: ip route 207.1.2.16 255.255.255.248 207.1.2.2 ! ACL list to only allow VPN traffic through the VPN DMZ interface: access-list 120 permit ip 172.26.129.0 0.0.0.255 any access-list 120 permit ip 172.26.130.0 0.0.0.255 any ! ACL to determine what to be encrypted, packets between ! the two tunnel endpoints which are GRE encapsulated. access-list 140 permit gre host 207.1.1.1 host 207.9.31.1 ! line con 0 exec-timeout 2 30 login authentication admin ! line aux 0 no exec transport input none ! line vty 0 4 exec-timeout 2 30 login authentication admin transport input telnet
Example 11-19. Estonia Remote Branch Router Configuration
hostname Eesti ! ! Ensure all vty, login, line and username passwords are encrypted ! with minimal encryption (7) unless configured as a secret ! that uses MD5 encryption. ! service password-encryption ! ! Disable access to minor TCP services such as echo, ! chargen, discard, and daytime. ! no service tcp-small-servers ! ! Disable access to minor UDP services such as echo, ! chargen, and discard. ! no service udp-small-servers ! !Define privileged access password. ! enable secret letmedostuff ! ! Local database for device authentication access: ! username admin password ComeOnIN ! ! Change the encryption key every 24 hours. ! crypto cisco key-timeout 1440 ! ! Public key for the home gateway Vancouver-gw: ! crypto key pubkey-chain dss named-key VancouverESA signature serial-number 007462E4 key-string 17C11157 CC640BF3 3DC5B608 C5C60963 C0421A67 D2D7AF70 97728A9A BACA0E07 35288070 AD90A20F 56F1BFE7 D8A4BB68 2C2419E0 26CF8E17 B09CA9A0 3090942E quit ! ! Crypto map for the connection from Eesti to Vancouver-gw; ! this defines the remote ! peer, and what traffic to encrypt, which is determined by access list 140 ! This gets applied to the tunnel and physical interfaces. ! crypto map Eesti-to-Vancouver 10 set peer VancouverESA match address 140 ! ! Tunnel interface from remote branch (Eesti) to home gateway (Vancouver-gw): ! interface Tunnel100 description network connection back to headquarters (Vancouver) ip unnumbered Ethernet1/0 no ip directed-broadcast tunnel source 207.9.31.1 tunnel destination 207.1.1.1 crypto map Eesti-to-Vancouver ! ! Apply the crypto map to the physical interface; ! this is also the outside NAT interface. ! interface Serial0/0 description frame relay connection to ISP ip address 207.9.31.1 255.255.255.240 no ip directed-broadcast ip nat outside encapsulation frame-relay frame-relay lmi-type ansi crypto map Eesti-to-Vancouver ! ! NAT inside interface: ! interface Ethernet1/0 description private IP address for remote site ip address 172.26.129.1 255.255.255.0 no ip directed-broadcast ip nat inside ! ! Translate IP addresses matching access list 150 into the IP address ! given to serial interface connected to the ISP. ip nat inside source list 150 interface Serial0/0 overload ip classless ! default route to ISP ip route 0.0.0.0 0.0.0.0 207.9.31.14 ! ! Routes for the networks inside the corporate intranet that ! the remote needs to access: ! ip route 172.26.0.0 255.255.128.0 Tunnel100 ip route 172.20.0.0 255.255.0.0 Tunnel100 ! ! Traffic going to any other destination will take the default route and be ! translated by NAT, access list 150 tells NAT what to translate. ! access-list 150 permit ip 172.26.129.0 0.0.0.255 any ! ! ACL to determine what is to be encrypted, ! which are all packets between the two tunnel endpoints: ! access-list 140 permit gre host 207.9.31.1 host 207.1.1.1 ! line con 0 exec-timeout 2 30 login authentication admin ! line aux 0 no exec transport input none ! line vty 0 4 exec-timeout 2 30 login authentication admin transport input telnet
IPsec is a framework of open standards developed by the IETF that provides security services at the IP level. (Refer to Chapter 2 for details.) IPsec shares the same benefits as CET: Both technologies offer authenticated and confidential IP packet transport. IPsec, however, offers a standards-based solution that provides multivendor interoperability.
NOTE
GRE tunneling is required in an IPsec environment if there is a requirement to encrypt an IP routing protocol that uses multicast packets to distribute its routing information (for example, Open Shortest Path First [OSPF] or Enhanced Interior Gateway Routing Protocol [EIGRP]). In its current form, the IPsec standard supports only unicast IP packets. For small environments, static routes should suffice, and GRE tunnels are not necessary.
Configuring IPsec on Cisco IOS Software devices requires a number of steps, as described here. Internet Key Exchange (IKE) is on by default and is the recommended mechanism to negotiate IPsec keys. It is possible to use manual keying, but this is highly discouraged because it provides limited scalability and an administrative nightmare. This discussion is limited to IPsec using IKE.
Configure the IKE Phase 1 policy (ISAKMP policy).
Cisco literature refers to IKE Phase 1 as the ISAKMP policy. It is configured using the following command:
crypto isakmp policy priority
You can configure multiple policies and the priority number, which ranges from 1 to 10,000, which denotes the order of preference that a given policy is negotiated with an ISAKMP peer. The lower value has the higher priority.
When in the ISAKMP configuration mode, you can specify the following parameters:
Encryption algorithm: Configurable options are des or 3des; the default is 56-bit DES CBC.
Hash algorithm: Configurable options are sha (specified HMAC-SHA-1) or md5 (specifies HMAC-MD5); the default is SHA-1.
Authentication: Configurable options are rsa-sig (digital signature), rsa-encr (public key cryptography) or pre-share (preshared keys); the default is RSA signatures.
Group: Configurable options are group 1 (the 768-bit Diffie-Hellman group) and group 2 (the 1024-bit Diffie-Hellman group); the default is group 1.
Lifetime: the default is 86,400 seconds.
Set the ISAKMP identity.
The ISAKMP identity specifies how the IKE Phase 1 peer is identified, which can be either by IP address or host name. Use the following command:
crypto isakmp identity {ip-address | hostname}
By default, a peer's ISAKMP identity is the peer's IP address. If you decide to change the default, just keep in mind that it is best to always be consistent across your entire IPsec-protected network when you choose to define a peer's identity.
Configure the IPsec AH and ESP parameters.
The AH and ESP parameters are configured with the following commands:
crypto ipsec transform-set transform-set-name transform 1 transform 2 mode [tunnel | transport] crypto ipsec security-association lifetime seconds seconds
A transform set represents a certain combination of security protocols and algorithms. Depending on the version of Cisco IOS Software you are running, the transform sets offered may vary because deployment of IPsec is still somewhat new and the standard was still being modified when Cisco first started offering IPsec. The transforms offered on Cisco IOS Software 12.2 are as follows:
ah-md5-hmac: AH using the HMAC-MD5 hash function
ah-sha-hmac: AH using the HMAC-SHA-1 hash function
comp-lzs: IP compression using the LZS compression algorithm
esp-3des: ESP encryption using 3DES
esp-des: ESP encryption using DES
esp-md5-hmac: ESP hash function using the HMAC-MD5
esp-null: ESP encryption without a cipher (that is, no encryption)
esp-sha-hmac: ESP hash function using the HMAC-SHA-1 function
When there are no interoperability constraints on which algorithms to use, you should use the <esp-3des> and <esp-sha-hmac> transforms to provide the authenticated and encrypted traffic exchange.
Tunnel mode is used for most IPsec traffic traversing through the IPsec routers. If the routers are the IPsec source and destination endpoints, transport mode should be specified.
Configure the IPsec traffic selectors.
The traffic selectors are configured by defining extended access lists. The permit keyword causes all IP traffic that matches the specified conditions to be protected by IPsec
Configure the IKE Phase 2 (IPsec SA) policy.
This step sets up a crypto map, which specifies all the necessary paramters to negotiate the IPsec SA policy. The following commands are required:
crypto map crypto-map-name seq-num ipsec-isakmp match address access-list-id set peer [ip-address | hostname] set transfrom-set transform-set-name set security-association lifetime seconds seconds set pfs [group1 | group2]
It is possible to configure multiple transform sets and then apply up to six different transform sets to a specific crypto map. The transform set in the crypto map entry will be used in the IPsec SA negotiation to find a match between both peers.
Apply the IPsec policy to an interface.
The configured crypto map is then applied to the appropriate interface using the crypto map crypto-map-name command. It is possible to apply the same crypto map to multiple interfaces. This case requires the use of the following command:
crypto map crypto-map-name local-address interface-id
If you use this command, the identifying interface is used as the local address for IPsec traffic originating from or destined to those interfaces sharing the same crypto map. A loopback interface should be used as the identifying interface.
NOTE
The syntax for configuring IPsec will vary slightly depending on the Cisco IOS Software version you are using. There are also more configuration options, but they are optional and not always used. It is always good practice to review the Command Reference for your software version before starting any configurations. Sometimes the optional configuration commands are required for interoperability reasons if you have a multivendor IPsec environment.
Figure 11-9 illustrates a scenario for two routers that use IPsec to encrypt/decrypt Telnet and World Wide Web traffic between the branch office and the corporate campus network.
The IPsec parameters are as follows:
IKE Phase 1
Encryption algorithm: 3DES
Hash algorithm: SHA-1
MODP group 2 (the Diffie-Hellman group)
Authentication using preshared keys (key is iamapresharedkey)
IKE SA lifetime 28,800 seconds (8 hours)
IPsec SA
Encryption algorithm: 3DES
Hash algorithm: SHA-1
Only use ESP
ESP tunnel mode
Use perfect forward secrecy with MODP group 2
IPsec SA lifetime of 3600 seconds (1 hour)
Example 11-20 shows the configuration commands for the branch router, and Example 11-21 shows the configuration commands for the corporate NAS.
Example 11-20. IPsec Branch Router Configuration
! Define the hostname.
hostname Branch_router
!
! Configure IKE Phase 1 policy. In this example the
! policy is to use 3DES for the encryption algorithm
! and SHA-1 for the hash algorithm. Preshared
! authentication is used and MODP group 2. The
! ISAKMP (IKE) SA lifetime is 8 hours (28,800 seconds).
!
crypto isakmp policy 6
encryption 3des
hash sha
group 2
lifetime 28800
authentication pre-share
crypto isakmp key iamasharedkey address 144.254.5.20
!
! Configures the IPsec AH or ESP parameters. In this example
! the policy is to use ESP with 3DES and SHA1 in tunnel mode.
!
crypto ipsec transform-set secureDES esp-3des esp-sha-hmac
mode tunnel
!
! Configure the IP traffic selectors which are to encrypt
! Telnet and WWW traffic.
!
access-list 106 permit ip 192.150.42.0 0.0.0.255 144.254.0.0
0.0.255.255 eq telnet
access-list 106 permit ip 192.150.42.0 0.0.0.255 144.254.0.0
0.0.255.255 eq http
!
! Configure IKE Phase 2 (IPsec SA) policy.
! PFS is used and MODP group 2 is always used
! The SA lifetime is 1 hour (3600 seconds). Define
! the transform set secureDES to be used.
!
crypto map toNAS 12 ipsec-isakmp
set peer 144.254.5.20
set transfrom-set secureDES
match address 106
set pfs group 2
set security-association lifetime seconds 3600
!
! Configure internal network.
!
! interface Ethernet 0
ip address 192.150.42.1 255.255.255.0
!
! Configure the ISDN interface which connects to
! the corporate network and will have the crypto
! map applied to it.
interface Bri 0
ip address unnumbered Ethernet 0
encapsulation ppp
dialer map ip 144.254.5.20 name NAS
dialer-group 1
ppp authentication chap
crypto map toNAS
!
Example 11-21. IPsec Corporate NAS Configuration
! Define the hostname.
!
hostname NAS
!
! Configure IKE Phase 1 policy. In this example the
! policy is to use 3DES for the encryption algorithm
! and SHA-1 for the hash algorithm. Preshared
! authentication is used and MODP group 2. The
! ISAKMP (IKE) SA lifetime is 8 hours (28,800 seconds).
!
crypto isakmp policy 6
encryption 3des
hash sha
group 2
lifetime 28800
authentication pre-share
crypto isakmp key iamasharedkey address 192.150.42.1
!
! Configures the IPsec AH or ESP parameters. In this example
! the policy is to use ESP with 3DES and SHA1 in tunnel mode.
!
crypto ipsec transform-set secureDES esp-3des esp-sha-hmac
mode tunnel
!
! Configure the IP traffic selectors which are to encrypt
! Telnet and WWW traffic.
!
access-list 106 permit ip 144.254.0.0 0.0.255.255 192.150.42.0
0.0.0.255 eq telnet
access-list 106 permit ip 144.254.0.0 0.0.255.255 192.150.42.0
0.0.0.255 eq http
!
! Configure IKE Phase 2 (IPsec SA) policy.
! PFS is used and MODP group 2 is always used.
! The SA lifetime is 1 hour (3600 seconds). Define
! the transform set secureDES to be used.
!
crypto map toBranch 12 ipsec-isakmp
set peer 192.150.42.1
set transfrom-set secureDES
match address 106
set pfs group 2
set security-association lifetime seconds 3600
!
! Configure internal network.
!
interface Ethernet 0
ip address 144.254.5.20 255.255.255.0
!
!Configuring PRI.
interface Serial0:23
description to the Branch
crypto map toBranch
!
L2TP can be used to carry IP unicast, IP multicast, and non-IP protocols, and IPsec transport mode can be used to protect the L2TP-encapsulated traffic. The scenario in Figure 11-10 illustrates the remote connection of a remote branch office in Toronto and a remote branch office in New York connecting back to the corporate network in Denver. Both connections are done through local ISPs and use the Internet as the way to transport the data back to the corporate network in Denver. Mobile users also have access to the corporate network using local ISP dialup connections. Example 11-22, Example 11-23, Example 11-24, and Example 11-25 show the configurations for the home gateway router in Denver, the remote branch router in Toronto, the remote branch router in New York, and a relevant ISP NAS in Figure 11-10, respectively.
The following security policy is defined for this example:
The branch office in Toronto is allowed to communicate directly to the Internet but must encrypt all traffic going to the corporate network in Denver.
All New York branch office traffic must go through the Denver corporate office firewall.
All mobile users use authenticated and private data connections back to the corporate network through ISP collaborative agreements.
Corporate infrastructure device access is required to be authenticated and authorized for limited access.
The policy is implemented as follows:
The branch office router in Toronto allows the users to talk directly to the Internet while using an IPsec-encrypted tunnel to access the corporate network. The serial interface on the router has been assigned an IP address from the ISP's address space. The Ethernet interface uses a private network address, and NAT is used to translate traffic going to the Internet. This router uses static routing.
The branch router in New York requires that all traffic, even traffic to the Internet, must go through the corporate firewall. The serial interface on the router has been assigned an IP address from the ISP's address space; the Ethernet interface uses a private network address. This router uses OSPF routing.
There is an agreement between the ISP and the corporation that if a mobile user presents the ISP's NAS with a username in the format [email protected], the PPP session will be transported to the corporation's home gateway for termination. By using L2TP tunneling with IPsec, a secure tunnel is provided from the NAS (isp-nas) to the home gateway (Denver-gw).
Example 11-22. Home Gateway Router Configuration
hostname Denver-gw ! ! In IOS firewall IPsec images "no service tcp & no udp small servers" is the ! default so it does not have to be explicitly defined. ! Turn on time stamps for log and debug information, set to the local time with ! time zone information displayed. ! service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone ! service password-encryption ! no logging console ! ! Enable TACACS+ to authenticate login, enable any PPP sessions, also enable ! accounting start-stop records for EXEC and PPP sessions. ! aaa new-model aaa authentication login default tacacs+ enable aaa authentication login console none aaa authentication enable default tacacs+ enable aaa authentication ppp default tacacs+ aaa authorization network default tacacs+ aaa accounting exec default start-stop tacacs+ aaa accounting network default start-stop tacacs+ ! enable secret 5 $1$xDvT$sT/TGeGrAwfAKbMr4N1NZ1 enable password 7 02050D480809 ! no ip finger ip domain-name mkos.com ! ! Enable VPDN and tell it to use L2TP. The PPP name of the remote NAS will be ! isp-nas and the local PPP name is Denver-gw. Also for the VPDN, use an ! alternative tacacs+ server. Connections inbound will use virtual-template 1 ! as the basis to create to the actual virtual-access interface. ! vpdn enable ! vpdn aaa override-server 172.20.24.47 vpdn-group 1 accept dialin l2tp virtual-template 1 remote isp-nas local name Denver-gw ! ! Define the IPsec transform policy set, ! (esp-3des) ESP with triple DES encryption algorithm, ! (esp-sha-hmac) ESP with SHA authentication algorithm. Because a GRE is used, ! run IPsec in transport rather than tunnel mode. ! crypto ipsec transform-set auth2 esp-3des esp-sha-hmac mode transport ! ! IPsec using certificates: The routers must first obtain certificates from ! the Certificate Authority (CA) server. When both peers have valid certificates, ! they automatically exchange RSA public keys as part of the ISAKMP negotiation. ! All that is required is that the routers register with the CA and obtain ! a certificate. A router does not have to keep public RSA keys for all peers ! in the network. ! crypto ca identity vpnnetwork enrollment url http://mkosca crl optional cryto ca certificate chain vpnnetwork certificate 44FC6C531FC3446927E4EE307A806B20 ! Certificate is multiple lines of hex digits quit certificate ca 3051DF7169BEE31B821DFE4B3A338E5F ! Certificate of the CA, multiple of lines hex digits quit certificate 52A46D5D10B18A6F51E6BC735A36508C ! Certificate is multiple lines of hex digits quit ! ! The crypto map determines what to encrypt and to what peer to send the traffic. ! An interface can have only one crypto map applied to it. The crypto map below ! is structured into sections, which apply for the different destinations, ! while still being a single crypto map entity. ! crypto map Denver-to-remotes local-address Serial2/0 crypto map Denver-to-remotes 100 ipsec-isakmp set peer 207.9.31.1 set transform-set auth2 match address Denver_gre_Toronto crypto map Denver-to-remotes 200 ipsec-isakmp set peer 207.10.31.1 set transform-set auth2 match address Denver_gre_NewYork crypto map Denver-to-remotes 500 ipsec-isakmp set peer 201.1.1.1 set transform-set auth2 match address ISP1_VPDN ! ! Set the time zone and daylight savings time for this router. ! clock timezone PST -8 clock summer-time PDT recurring ! ! Tunnel interface to router Toronto. The tunnel source is specified as an ! interface with a registered IP address. The crypto map is applied to both ! the tunnel and physical interfaces. The IP precedence of packets being ! tunneled are copied into the IP header of the outbound frame. ! This example uses an IP unnumbered tunnel interface. Only packets destined ! for the intranet arrive on this interface because NAT is used at the remote ! for packets destined for the Internet. ! interface Tunnel100 description tunnel to branch router Toronto ip unnumbered FastEthernet5/0 no ip directed-broadcast tunnel source Serial2/0 tunnel destination 207.9.31.1 crypto map Denver-to-remotes ! ! Tunnel interface to router New York. The crypto map is applied to both the ! tunnel and physical interfaces. Note that the same crypto map has been used ! on both the tunnels, with different sections of the crypto map applying to each ! tunnel. The IP precedence of packets being tunneled are copied into the IP ! header of the outbound frame. This example uses an IP-numbered tunnel interface ! with OSPF as the routing protocol and routing information authentication ! enabled. The policy for this remote site is that all packets destined to the ! Internet must go through the corporate firewall. This is achieved by using ! policy routing (route-map VPN_InBound). ! interface Tunnel101 description tunnel to branch router NewYork ip address 172.26.123.1 255.255.255.252 no ip directed-broadcast ip ospf message-digest-key 1 md5 7 00071A15075434101F2F ip policy route-map VPN_InBound tunnel source Serial2/0 tunnel destination 207.10.31.1 crypto map Denver-to-remotes ! ! DS3 connection to ISP. Two ACLS are applied here. The inbound ACL stops ! some common protocols and network addresses known to be invalid or harmful. ! The outbound security ACL prevents packets from private network addresses ! that have not been through NAT from leaving. The crypto map is applied ! to the interface. ! interface Serial2/0 description connection to ISP1 - DS3 ip address 207.1.1.1 255.255.255.252 ip access-group IntSecurity in ip access-group IntSecurityOut out no ip directed-broadcast framing c-bit cablelength 50 dsu bandwidth 44210 crypto map Denver-to-remotes ! ! This interface is connected to the corporate network Web server and to the ! firewall, which is doing NAT for the corporate network's access to the ! Internet. ! interface FastEthernet3/0 description network for Internet traffic ip address 207.1.2.1 255.255.255.240 no ip directed-broadcast full-duplex ! ! This interface is connected to the firewall, is treated as an inside interface, ! is for the VPN traffic to access the corporate network, and is using NAT ! on the firewall to the Internet. This route-map on the interface is responsible ! for setting the correct precedence on the IP packets destined for the VPN, ! to gain the QoS agreement with the service provider. The ACL is used to allow ! only known VPN networks on the link. ! interface FastEthernet5/0 description network for VPN traffic ip address 172.26.71.1 255.255.255.252 ip access-group 120 out no ip directed-broadcast ip policy route-map VPN_QoS full-duplex ! ! The virtual template is used by the VPDN code as the basis to create the ! virtual-access interface on which the L2TP connections terminate. ! interface Virtual-Template1 ip unnumbered FastEthernet5/0 no ip directed-broadcast peer default ip address pool vpn_users ! ! OSPF for the VPN network, remote branch NewYork is running OSPF. ! The OSPF process is set to redistribute static routes that match ! route-map VPN_ROUTES_OUT, and originate the default route for the ! remote VPN sites running OSPF. Authentication is enabled for routing ! information so that only remotes with the correct key can participate. ! router ospf 100 redistribute static subnets route-map VPN_ROUTES_OUT passive-interface FastEthernet5/0 passive-interface Tunnel100 network 172.26.71.0 0.0.0.3 area 0 network 172.26.120.0 0.0.3.255 area 172.26.120.0 default-information originate area 172.26.120.0 authentication message-digest ! ip classless ! ! Default route to ISP: ip route 0.0.0.0 0.0.0.0 207.1.1.2 ! ! Corporate network uses 172.20/24 and 172.26/24. ip route 172.20.0.0 255.255.0.0 172.26.71.2 ip route 172.26.0.0 255.255.0.0 172.26.71.2 ! ! Static route to branch in Toronto (Ethernet 0): ip route 172.26.120.0 255.255.255.0 Tunnel100 ! ! Route to the NAT pool on the firewall: ip route 207.1.2.16 255.255.255.248 207.1.2.2 ! ! ACL to determine what frames get set specified QoS for ISP1: ip access-list extended Bronze_ISP1_QoS permit ip 172.26.0.0 0.0.255.255 172.26.120.0 0.0.0.255 permit ip 172.20.0.0 0.0.255.255 172.26.120.0 0.0.0.255 ! ! ACL to determine the traffic to encrypt for the VPDN L2TP tunnel: ! from ISP NAS "isp-nas" ip access-list extended ISP1_VPDN permit ip host 207.1.1.1 host 201.1.1.1 ! ! ACL to block any traffic inbound from private addresses ! and some common troublesome services: ip access-list extended IntSecurity permit tcp any any established deny ip 127.0.0.0 0.255.255.255 any deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any deny udp any any eq snmp deny udp any any eq 2000 deny udp any any gt 6000 deny tcp any any gt 6000 deny tcp any any eq 2000 deny udp any any eq tftp deny udp any any eq sunrpc deny udp any any eq 2049 deny tcp any any eq 2049 deny tcp any any eq sunrpc deny tcp any any eq 87 deny tcp any any eq exec deny tcp any any eq login deny tcp any any eq cmd deny tcp any any eq lpd deny tcp any any eq uucp permit ip any any ! ! ACL to prevent any packets from private addresses being sent to the Internet. ip access-list extended IntSecurityOut deny ip 127.0.0.0 0.255.255.255 any deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any permit ip 207.0.0.0 0.255.255.255 any ! ! ACL to determine which frames are set to Silver QoS for ISP1: ip access-list extended Silver_ISP1_QoS permit ip 172.26.0.0 0.0.255.255 172.26.121.0 0.0.0.255 permit ip 172.20.0.0 0.0.255.255 172.26.121.0 0.0.0.255 ! ! ACL determines which packets IPsec will look at for tunnel100: ip access-list extended Denver_gre_Torornto permit gre host 207.1.1.1 host 207.9.31.1 ! ! ACL determines which packets IPsec looks at for tunnel101: ip access-list extended Denver_gre_NewYork permit gre host 207.1.1.1 host 207.10.31.1 ! ! Turn on syslog and point it at the management station. logging 172.20.18.5 ! ! ACL determines which static routes are redistributed into the OSPF VPN process: access-list 18 permit 172.26.0.0 0.0.255.255 access-list 18 permit 172.20.0.0 0.0.255.255 ! ! ACL only allows Telnet to the router from particular subnets: access-list 70 permit 172.20.18.0 0.0.0.192 access-list 70 permit 172.20.24.0 0.0.0.255 ! ! ACL determines which management stations can access this device using SNMP: access-list 75 permit 172.20.18.0 0.0.0.255 ! ! ACL only allows particular networks on the VPN interface to the firewall: access-list 120 permit ip 172.26.120.0 0.0.0.255 any access-list 120 permit ip 172.26.121.0 0.0.0.255 any access-list 120 permit ip 172.26.122.0 0.0.0.255 any access-list 120 permit ip 172.26.123.0 0.0.0.255 any ! ! ACL for route map to policy route all packets to the firewall. access-list 195 permit ip 172.26.121.0 0.0.0.255 any access-list 195 permit ip 172.26.123.0 0.0.0.3 any ! ! Route map determines which routes to distribute into OSPF VPN process. route-map VPN_ROUTES_OUT permit 20 match ip address 18 set metric 1000 set metric-type type-1 ! ! Route map used to policy route all specified packets to the corporate firewall. route-map VPN_InBound permit 100 match ip address 195 set ip next-hop 172.26.71.2 ! ! Route map used to set the precedence bits on outbound VPN network packets. route-map VPN_QoS permit 100 match ip address Bronze_ISP1_QoS set ip precedence priority route-map VPN_QoS permit 200 match ip address Silver_ISP1_QoS set ip precedence immediate ! ! Configure SNMP, only allow management stations matching access list 75 ! to manage this router. snmp-server community public RO 75 snmp-server community private RW 75 snmp-server trap-source Ethernet1/0 snmp-server packetsize 4096 snmp-server enable traps snmp snmp-server enable traps frame-relay snmp-server host 172.20.18.5 traps public snmp-server tftp-server-list 75 ! ! Configure which TACACS server to use and the key. tacacs-server host 172.20.18.5 tacacs-server key SECRET12345 ! ! Console and vty are secured using TACACS+. line con 0 exec-timeout 5 0 transport input none line aux 0 ! ! Only allow Telnet to this router if the source address is in access list 70. line vty 0 4 access-class 70 in password 7 1511021F0725 transport input telnet ! ! Configure NTP so that all the routers have the same time in the network. ntp clock-period 17179770 ntp server 172.26.71.2 end
Example 11-23. Remote Branch Router in Toronto Configuration
hostname Toronto ! ! In IOS firewall IPsec images "no service tcp & no udp small servers" is the ! default. Turn on time stamps for log and debug information and set to the local ! time with time zone information displayed. ! service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption ! logging buffered 32000 debugging no logging console ! ! Enable TACACS+ to authenticate login and enable passwords, ! also enable accounting start-stop records for exec sessions. ! aaa new-model aaa authentication login default tacacs+ enable aaa authentication enable default tacacs+ enable aaa accounting exec default start-stop tacacs+ ! enable secret 5 $1$SKkd$qbTmOJ9dyffjccNUB0cvn0 enable password 7 02050D480809 ! no ip finger ip domain-name mkos.com ! ! Define the IPsec transform policy set; because a GRE is used, run IPsec in ! transport rather than tunnel mode. ! crypto ipsec transform-set auth2 esp-3des esp-sha-hmac mode transport ! crypto ca identity vpnnetwork enrollment url http://mkosca crl optional cryto ca certificate chain vpnnetwork certificate 44FC6C531FC3446927E4EE307A806B20 ! Certificate is multiple lines hex digits quit certificate ca 3051DF7169BEE31B821DFE4B3A338E5F ! Certificate is multiple lines hex digits quit certificate 52A46D5D10B18A6F51E6BC735A36508C ! Certificate is multiple lines hex digits quit ! ! The crypto map determines what packets should be encrypted as determined by ! access list 140, and the crypto peer that is the IP address of Denver-gw, ! along with the transforms that will be allowed. The setting of the local-address ! ensures that if there are multiple paths, the same IP address is always used ! for this crypto pair, no matter what interface a packet arrives on. ! crypto map ipsec-Toronto-to-Denver local-address Serial0/0 crypto map ipsec-Toronto-to-Denver 10 ipsec-isakmp set peer 207.1.1.1 set transform-set auth2 match address 140 ! ! Set the time zone and daylight savings time for this router. ! clock timezone EST -5 clock summer-time EDT recurring ! ! Tunnel interface to transport traffic to Denver-gw, the tunnel source is ! specified as an interface with a registered IP address. The IP address of ! the Ethernet is used, which is a private address; an unnumbered interface ! is used here to show that you do not have to address the tunnel interface. ! The IP precedence of the packets being tunneled are copied into the IP header ! of the outbound frame. ! interface Tunnel100 description VPN connection back to headquarters (Denver) ip unnumbered Ethernet1/0 no ip directed-broadcast tunnel source Serial0/0 tunnel destination 207.1.1.1 crypto map ipsec-Toronto-to-Denver ! ! Serial 0/0 is the connection to the ISP; it has one of the ISP's registered ! addresses. Two access lists are applied to the interface: one inbound and ! one outbound. These are explained where the access list is defined below. ! This interface is specified as the outside interface for NAT. ! Finally, the crypto map is applied to the interface to determine what ! should be encrypted. ! interface Serial0/0 description frame relay connection to ISP ip address 207.9.31.1 255.255.255.240 ip access-group IntSecurity in ip access-group IntSecurityOut out no ip directed-broadcast ip nat outside encapsulation frame-relay IETF no ip mroute-cache frame-relay lmi-type ansi crypto map ipsec-Toronto-to-Denver ! ! Ethernet 1/0 is the remote LAN interface; it is assigned a private IP address ! and is a NAT inside interface. A route-map is applied to the interface to set ! the IP precedence to get the ISP Bronze offering of QoS. ! interface Ethernet1/0 description private IP address for remote site ip address 172.26.120.1 255.255.255.0 no ip directed-broadcast ip nat inside ip policy route-map Bronze_ISP1_QoS ! ! Configure NAT: Any source address matching access list 150, ! translate to the IP address of interface serial 0/0. The overload options ! mean that many IP addresses will be translated to serial 0/0 IP addresses ! on different ports. ! ip nat inside source list 150 interface Serial0/0 overload ip classless ! ! Static routes: The default is to send all traffic to the ISP. The corporation ! uses networks 172.20/24 and 172.26/24 for its networks, so any traffic ! destined to these addresses should go across the tunnel interface. ! ip route 0.0.0.0 0.0.0.0 207.9.31.14 ip route 172.20.0.0 255.255.0.0 Tunnel100 ip route 172.26.0.0 255.255.0.0 Tunnel100 ! ! ACL to block particular services and networks, inbound from the ISP. ip access-list extended IntSecurity permit tcp any any established deny ip 127.0.0.0 0.255.255.255 any deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any deny udp any any eq snmp deny udp any any eq 2000 deny udp any any gt 6000 deny tcp any any gt 6000 deny tcp any any eq 2000 deny udp any any eq tftp deny udp any any eq sunrpc deny udp any any eq 2049 deny tcp any any eq 2049 deny tcp any any eq sunrpc deny tcp any any eq 87 deny tcp any any eq exec deny tcp any any eq login deny tcp any any eq cmd deny tcp any any eq lpd deny tcp any any eq uucp permit ip any any ! ! ACL to prevent packets from private networks leaving by the ISP interface. ip access-list extended IntSecurityOut deny ip 127.0.0.0 0.255.255.255 any deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any permit ip 207.9.31.0 0.0.0.255 any ! ! Turn on syslog and point it at the management station. logging 172.20.18.5 ! ! ACL to secure why can Telnet to the router: access-list 70 permit 207.1.1.1 access-list 70 permit 172.20.18.0 0.0.0.192 access-list 70 permit 172.20.24.0 0.0.0.255 ! ! ACL to determine which management stations can access this device using SNMP: access-list 75 permit 172.20.18.0 0.0.0.255 ! ! ACL to determine which frames should be protected (encrypted) with Ipsec: access-list 140 permit gre host 207.9.31.1 host 207.1.1.1 ! ! What packets are eligible sourced from NAT inside networks for ! address translation. access-list 150 permit ip any any ! ! Access list used in route map to set IP precedence to get specified ! QoS level from ISP. access-list 175 permit ip any any ! ! Route map used on Ethernet 1/0 to set the precedence bits of all IP frames ! to priority (1). route-map Bronze_ISP1_QoS permit 10 match ip address 175 set ip precedence priority ! ! Configure which TACACS server to use and the key. tacacs-server host 172.20.18.5 tacacs-server key SECRET12345 ! ! Configure SNMP for network management. Because only the corporation's ! management stations will manage this router, the trap source is set to use ! Ethernet 1/0. ! snmp-server community public RO 75 snmp-server community private RW 75 snmp-server trap-source Ethernet1/0 snmp-server packetsize 4096 snmp-server enable traps snmp snmp-server enable traps frame-relay snmp-server enable traps syslog snmp-server host 172.20.18.5 traps public snmp-server tftp-server-list 75 ! ! Console and vty are secured using TACACS+. ! line con 0 exec-timeout 5 0 transport input none line aux 0 ! ! Only allow Telnet to this router if the source address is in access list 70: line vty 0 4 access-class 70 in password 7 1511021F0725 transport input telnet ! ! Configure NTP so that all the routers have the same time in the network. ntp clock-period 17179770 ntp server 172.26.71.2 end !
Example 11-24. Remote Branch Router in New York Configuration
Hostname NewYork ! ! In IOS firewall IPsec images "no service tcp & no udp small servers" is the ! default. Turn on time stamps for log and debug information, set to the ! local time with time zone information displayed. ! service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption ! logging buffered 32000 debugging no logging console ! ! Enable TACACS+ to authenticate login and enable passwords, also enable ! accounting start-stop records for exec sessions. ! aaa new-model aaa authentication login default tacacs+ enable aaa authentication enable default tacacs+ enable aaa accounting exec default start-stop tacacs+ ! enable secret 5 $1$z1c.$vLAcnZ849epT8xLHNeTT0/ enable password 7 110A1016141D ! ip domain-name mkos.com ! ! Define the IPsec transform policy set; because a GRE is used, run IPsec in ! transport rather than tunnel mode. ! crypto ipsec transform-set auth2 esp-3des esp-sha-hmac mode transport ! crypto ca identity vpnnetwork enrollment url http://mkosca crl optional cryto ca certificate chain vpnnetwork certificate 44FC6C531FC3446927E4EE307A806B20 ! Certificate is multiple lines of hex digits quit certificate ca 3051DF7169BEE31B821DFE4B3A338E5F ! Certificate is multiple lines of hex digits quit certificate 52A46D5D10B18A6F51E6BC735A36508C ! Certificate is multiple lines of hex digits quit ! ! The crypto map determines which packets should be encrypted as determined ! by access list 141, and the crypto peer, which is the IP address of Denver-gw, ! along with the transforms that will be allowed. The setting of the ! local-address ensures that if there are multiple paths, the same IP address ! is always used for this crypto pair, no matter what interface a packet arrives ! on. ! crypto map NewYork-to-Denver local-address Serial0/0 crypto map NewYork-to-Denver 20 ipsec-isakmp set peer 207.1.1.1 set transform-set auth2 match address 141 ! ! Set the time zone and daylight savings time for this router. ! clock timezone est -8 clock summer-time EST recurring ! ! Tunnel interface to transport traffic to Denver-gw, the tunnel source is ! specified as an interface with a registered IP address. The router is ! configured to run OSPF with the home gateway across the tunnel interface. ! OSPF is using message digest 5 to authenticate routing updates. ! The crypto map is applied to both the tunnel and the physical interfaces. ! The IP precedence of packets being tunneled are copied into the IP header ! of the outbound frame. ! interface Tunnel101 ip address 172.26.123.2 255.255.255.252 no ip directed-broadcast ip ospf authentication-key 7 104D000A06182D1D1C ip ospf message-digest-key 1 md5 7 045802150C2E73581917 tunnel source Serial0/0 tunnel destination 207.1.1.1 crypto map NewYork-to-Denver ! ! Serial 0/0 is the connection to the ISP; it has one of the ISP's registered ! addresses. Two ACLs are applied to the interface: one inbound and one outbound. ! The crypto map is applied to the interface to determine what should ! be encrypted. ! interface Serial0/0 ip address 207.10.31.1 255.255.255.240 ip access-group IntSecurity in ip access-group IntSecurityOut out no ip directed-broadcast encapsulation frame-relay IETF frame-relay lmi-type ansi crypto map NewYork-to-Denver ! ! Ethernet 1/0 is the remote LAN interface; it is assigned a private IP address. ! A route map is applied to the interface to set the IP precedence ! level to get the ISP Silver offering of QoS. interface Ethernet1/0 ip address 172.26.121.1 255.255.255.0 no ip directed-broadcast ip policy route-map Silver_ISP1_QoS ! ! Configure OSPF for IP routing and authenticate routing updates. router ospf 100 network 172.26.120.0 0.0.3.255 area 172.26.120.0 area 172.26.120.0 authentication message-digest ! ip classless ! ! Because all traffic from the remote router must go through the firewall at ! corporate headquarters, a static default route is not used but an explicit ! route for the tunnel destination end point is used. This router gets its ! default route from OSPF. ! ip route 207.1.1.1 255.255.255.255 207.10.31.14 ! ! ACL to block particular services and networks, inbound from the ISP. ip access-list extended IntSecurity permit tcp any any established deny ip 127.0.0.0 0.255.255.255 any deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any deny udp any any eq snmp deny udp any any eq 2000 deny udp any any gt 6000 deny tcp any any gt 6000 deny tcp any any eq 2000 deny udp any any eq tftp deny udp any any eq sunrpc deny udp any any eq 2049 deny tcp any any eq 2049 deny tcp any any eq sunrpc deny tcp any any eq 87 deny tcp any any eq exec deny tcp any any eq login deny tcp any any eq cmd deny tcp any any eq lpd permit ip any any ! ! ACL prevents packets from private networks from leaving by the ISP interface. ip access-list extended IntSecurityOut deny ip 127.0.0.0 0.255.255.255 any deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any permit ip 207.0.0.0 0.255.255.255 any ! ! Turn on syslog and point it at the management station. logging 172.20.18.5 ! ! ACL secures who can Telnet to the router. access-list 70 permit 207.1.1.1 access-list 70 permit 172.20.18.0 0.0.0.255 ! ! ACL determines which management stations can access this device using SNMP. access-list 75 permit 172.20.18.0 0.0.0.255 ! ! ACL determines which frames should be protected (encrypted) with IPsec access list 141 permit gre host 207.10.31.1 host 207.1.1.1. ! ! ACL used in route map to set IP precedence to get specified QoS level from ISP. access-list 175 permit ip 172.26.121.0 0.0.0.255 any ! ! Route map used on Ethernet 1/0 to set the precedence bits of all IP frames ! to immediate (2). route-map Silver_ISP1_QoS permit 10 match ip address 175 set ip precedence immediate ! ! Configure which TACACS server to use and the key. tacacs-server host 172.20.18.5 tacacs-server key SECRET12345 ! ! Configure SNMP for network management. Because only the corporation's ! management stations will manage this router, the trap source is set to ! use Ethernet 1/0. ! snmp-server community public RO 75 snmp-server community private RW 75 snmp-server trap-source Ethernet1/0 snmp-server packetsize 4096 snmp-server enable traps snmp snmp-server enable traps frame-relay snmp-server enable traps syslog snmp-server host 172.20.18.5 traps public snmp-server tftp-server-list 75 ! ! Console and vty are secured using TACACS+. ! line con 0 exec-timeout 5 0 transport input none login authentication default line aux 0 ! ! Only allow Telnet to this router if the source address is in access list 70. line vty 0 4 access-class 70 in password 7 1511021F0725 transport input telnet ! ! Configure NTP so that all the routers have the same time in the network. ntp clock-period 17179770 ntp server 172.26.71.2 end
Example 11-25. ISP NAS Configuration
Hostname isp-nas ! aaa new-model aaa authentication login default enable aaa authentication login console none aaa authentication enable default enable aaa authentication ppp default tacacs+ local aaa authorization exec default none aaa accounting exec default start-stop tacacs+ ! enable secret 5 $1$2Ezj$2ygSyGTzphmQadmU854aL1 enable password escape ! ip domain-name isp1.net ! ! Enable VPDN on the NAS and make the source of tunnels to be the loopback. vpdn enable vpdn source-ip 201.1.1.1 ! ! VPDN group 1, connection to the home gateway Denver-gw, use LT2P, ! and the ppp name isp1. ! vpdn-group 1 request dialin l2tp ip 207.1.1.1 domain mkos.com local name isp1 ! crypto isakmp policy 10 authentication rsa-encr group 2 lifetime 240 ! ! Define the IPsec transform policy set; because an L2TP is used, run IPsec in ! transport rather than tunnel mode. crypto ipsec transform-set auth-mkos-dial esp-3des esp-sha-hmac mode transport ! crypto ca identity vpnnetwork enrollment url http://mkosca crl optional cryto ca certificate chain vpnnetwork certificate 44FC6C531FC3446927E4EE307A806B20 ! Certificate is multiple lines of hex digits quit certificate ca 3051DF7169BEE31B821DFE4B3A338E5F ! Certificate is multiple lines of hex digits quit ! ! Crypto map to encrypt traffic destined to Denver home gateway for mkos.com: ! crypto map VPDN_MKOS local-address Loopback0 crypto map VPDN_MKOS 1000 ipsec-isakmp set peer 207.1.1.1 set transform-set auth-mkos-dial match address VPDN_mkos_tunnel ! ! All L2TP traffic is sourced off the loopback, apply the crytpo map for IPsec. ! interface Loopback0 ip address 201.1.1.1 255.255.255.255 no ip directed-broadcast crypto map VPDN_MKOS ! interface Ethernet1/2 ip address 207.7.31.1 255.255.255.252 no ip directed-broadcast no ip mroute-cache crypto map VPDN_MKOS ! ! ACL to determine what traffic IPsec should be applied to. ip access-list extended VPDN_mkos_tunnel permit ip host 201.1.1.1 host 207.1.1.1 !
This chapter described the implementation considerations for providing secure remote dial-in and virtual dial-in access. This includes establishing proper authentication and authorization for any telecommuters, mobile hosts, and remote branch offices attempting to gain access to resources in the main corporate network.
It is often necessary to restrict access to certain areas of the corporate network depending on who the remote user is and from where he or she is trying to obtain the connection. Also important is keeping track of connection details (such as who connected where and the duration of the connection) to keep accurate accounting statistics for an audit trail or billing purposes.
Finally, virtual dial-in environments require some special considerations because the data is traveling over shared public networks. Usually, you will want to ensure authenticated and private (confidential) delivery of the data packets over these public networks. It is usually a good idea to incorporate firewall functionality into the dial-in access perimeters and to implement some kind of auditing and intrusion detection system to keep accurate connection and traffic statistics.
The following questions provide you with an opportunity to test your knowledge of the topics covered in this chapter. You can find the answers to these questions in Appendix E, “Answers to Review Questions.”