|
|
Network security is a broad topic that can be addressed at the data link, or media, level (where packet snooping and encryption problems can occur), at the network, or protocol, layer (the point at which Internet Protocol (IP) packets and routing updates are controlled), and at the application layer (where, for example, host-level bugs become issues).
As more users access the Internet and as companies expand their networks, the challenge to provide security for internal networks becomes increasingly difficult. Companies must determine which areas of their internal networks they must protect, learn how to restrict user access to these areas, and determine which types of network services they should filter to prevent potential security breaches.
Cisco Systems provides several network, or protocol, layer features to increase security on IP networks. These features include controls to restrict access to routers and communication servers by way of console port, Telnet, Simple Network Management Protocol (SNMP), Terminal Access Controller Access Control System (TACACS), vendor token cards, and access lists. Firewall architecture setup is also discussed.
When most people talk about security, they mean ensuring that users can only perform tasks they are authorized to do, can only obtain information they are authorized to have, and cannot cause damage to the data, applications, or operating environment of a system.
The word security connotes protection against malicious attack by outsiders. Security also involves controlling the effects of errors and equipment failures. Anything that can protect against a deliberate, intelligent, calculated attack will probably prevent random misfortune as well.
Security measures keep people honest in the same way that locks do. This case study provides specific actions you can take to improve the security of your network. Before going into specifics, however, it will help if you understand the following basic concepts that are essential to any security system:
It is important to control access to your Cisco routers. You can control access to the router using the following methods:
You can secure the first three of these methods by employing features within the router software. For each method, you can permit nonprivileged access and privileged access for a user (or group of users). Nonprivileged access allows users to monitor the router, but not to configure the router. Privileged access allows the user to fully configure the router.
For console port and Telnet access, you can set up two types of passwords. The first type of password, the login password, allows the user nonprivileged access to the router. After accessing the router, the user can enter privileged mode by entering the enable command and the proper password. Privileged mode provides the user with full configuration capabilities.
SNMP access allows you to set up different SNMP community strings for both nonprivileged and privileged access. Nonprivileged access allows users on a host to send the router SNMP get-request and SNMP get-next-request messages. These messages are used for gathering statistics from the router. Privileged access allows users on a host to send the router SNMP set-request messages in order to make changes to the router's configurations and operational state.
You configure a password for nonprivileged mode by entering the following commands in the router's configuration file. Passwords are case-sensitive. In this example, the password is "1forAll."
line console 0 login password 1forAll
When you log in to the router, the router login prompt is as follows:
User Access Verification Password:
You must enter the password "1forAll" to gain nonprivileged access to the router. The router response is as follows:
router>
Nonprivileged mode is signified on the router by the > prompt. At this point, you can enter a variety of commands to view statistics on the router, but you cannot change the configuration of the router. Never use "cisco," or other obvious derivatives, such as "pancho," for a Cisco router password. These will be the first passwords intruders will try if they recognize the Cisco login prompt.
Configure a password for privileged mode by entering the following commands in the router's configuration file. In this example, the password is "san-fran."
enable-password san-fran
To access privileged mode, enter the following command:
router> enable Password:
Enter the password "san-fran" to gain privileged access to the router. The router responds as follows:
router#
Privileged mode is signified by the # prompt. In privileged mode, you can enter all commands to view statistics and configure the router.
Setting the login and enable passwords may not provide enough security in some cases. The timeout for an unattended console (by default 10 minutes) provides an additional security measure. If the console is left unattended in privileged mode, any user can modify the router's configuration. You can change the login timeout via the command exec-timeout mm ss where mm is minutes and ss is seconds. The following commands change the timeout to 1 minute and 30 seconds:
line console 0 exec-timeout 1 30
All passwords on the router are visible via the write terminal and show configuration privileged mode commands. If you have access to privileged mode on the router, you can view all passwords in cleartext by default.
There is a way to hide cleartext passwords. The command service password-encryption stores passwords in an encrypted manner so that anyone performing a write terminal and show configuration will not be able to determine the cleartext password. However, if you forget the password, regaining access to the router requires you to have physical access to the router.
You can access both nonprivileged and privileged mode on the router via Telnet. As with the console port, Telnet security is provided when users are prompted by the router to authenticate themselves via passwords. In fact, many of the same concepts described in the "Console Access" section earlier in this chapter apply to Telnet access. You must enter a password to go from nonprivileged mode to privileged mode, and you can encrypt passwords and specify timeouts for each Telnet session.
Each Telnet port on the router is known as a virtual terminal. There are a maximum of five virtual terminal (VTY) ports on the router, allowing five concurrent Telnet sessions. (The communication server provides more VTY ports.) On the router, the virtual terminal ports are numbered from 0 through 4. You can set up nonprivileged passwords for Telnet access via the virtual terminal ports with the following configuration commands. In this example, virtual terminal ports 0 through 4 use the password "marin":
line vty 0 4 login password marin
When a user telnets to a router IP address, the router provides a prompt similar to the following:
% telnet router Trying ... Connected to router. Escape character is '^]'. User Access Verification Password:
If the user enters the correct nonprivileged password, the following prompt appears:
router>
The user now has nonprivileged access to the router and can enter privileged mode by entering the enable command as described in the "Privileged Mode Password" section earlier in this chapter.
If you want to allow only certain IP addresses to use Telnet to access the router, you must use the access-class command. The command access-class nn in defines an access list (from 1 through 99) that allows access to the virtual terminal lines on the router. The following configuration commands allow incoming Telnet access to the router only from hosts on network 192.85.55.0:
access-list 12 permit 192.85.55.0 0.0.0.255 line vty 0 4 access-class 12 in
It is possible to access Cisco products via Telnet to specified TCP ports. The type of Telnet access varies, depending upon the following Cisco software releases:
For Software Release 9.1 (11.4) and earlier and Software Release 9.21 (3.1) and earlier, it is possible, by default, to establish TCP connections to Cisco products via the TCP ports listed in Table 16-1.
| TCP Port Number | Access Method |
|---|---|
7 | Echo |
9 | Discard |
23 | Telnet (to virtual terminal VTY ports in rotary fashion) |
79 | Finger |
1993 | SNMP over TCP |
2001 through 2999 | Telnet to auxiliary (AUX) port, terminal (TTY) ports, and virtual terminal (VTY) ports |
3001 through 3999 | Telnet to rotary ports (access via these ports is only possible if the rotaries have been explicitly configured first with the rotary command) |
4001 through 4999 | Telnet (stream mode) mirror of 2000 range |
5001 through 5999 | Telnet (stream mode) mirror of 3000 range (access via these ports is possible only if the rotaries have been explicitly configured first) |
6001 through 6999 | Telnet (binary mode) mirror of 2000 range |
7001 through 7999 | Telnet (binary mode) mirror of 3000 range (access via these ports is possible only if the rotaries have been explicitly configured first) |
8001 through 8999 | Xremote (communication servers only) |
9001 through 9999 | Reverse Xremote (communication servers only) |
10001 through 19999 | Reverse Xremote rotary (communication servers only; access via these ports is possible only if the ports have been explicitly configured first) |
The following is an example illustrating an access list denying all in-bound Telnet access to the auxiliary port and allowing Telnet access to the router only from IP address 192.32.6.7:
access-class 51 deny 0.0.0.0 255.255.255.255 access-class 52 permit 192.32.6.7 line aux 0 access-class 51 in line vty 0 4 access-class 52 in
To disable connections to the echo and discard ports, you must disable these services completely with the no service tcp-small-servers command.
You might want to create access lists to prevent access to Cisco products via these TCP ports. For information on how to create access lists for routers, see the "Configuring the Firewall Router" section later in this chapter. For information on how to create access lists for communication servers, see the "Configuring the Firewall Communication Server" section later in this chapter.
With Software Release 9.1 (11.5), 9.21 (3.2), and any version of Software Release 10, the following enhancements have been implemented:
For later releases, a Cisco router accepts TCP connections on the ports listed in Table 16-2 by default.
| TCP Port Number | Access Method |
|---|---|
7 | Echo |
9 | Discard |
23 | Telnet |
79 | Finger |
1993 | SNMP over TCP |
2001 | Auxiliary (AUX) port |
4001 | Auxiliary (AUX) port (stream) |
6001 | Auxiliary (AUX) port (binary) |
Access via port 23 can be restricted by creating an access list and assigning it to virtual terminal lines. Access via port 79 can be disabled with the no service finger command. Access via port 1993 can be controlled with SNMP access lists. Access via ports 2001, 4001, and 6001 can be controlled with an access list placed on the auxiliary port.
Nonprivileged and privileged mode passwords are global and apply to every user accessing the router from either the console port or from a Telnet session. As an alternative, the Terminal Access Controller Access Control System (TACACS) provides a way to validate every user on an individual basis before they can gain access to the router or communication server. TACACS was derived from the United States Department of Defense and is described in Request For Comments (RFC) 1492. TACACS is used by Cisco to allow finer control over who can access the router in nonprivileged and privileged mode.
With TACACS enabled, the router prompts the user for a username and a password. Then, the router queries a TACACS server to determine whether the user provided the correct password. A TACACS server typically runs on a UNIX workstation. Public domain TACACS servers can be obtained via anonymous ftp to ftp.cisco.com in the /pub directory. Use the /pub/README file to find the filename. A fully supported TACACS server is bundled with CiscoWorks Version 3.
The configuration command tacacs-server host specifies the UNIX host running a TACACS server that will validate requests sent by the router. You can enter the tacacs-server host command several times to specify multiple TACACS server hosts for a router.
If all servers are unavailable, you may be locked out of the router. In that event, the configuration command tacacs-server last-resort [password | succeed] allows you to determine whether to allow a user to log in to the router with no password (succeed keyword) or to force the user to supply the standard login password (password keyword).
The following commands specify a TACACS server and allow a login to succeed if the server is down or unreachable:
tacacs-server host 129.140.1.1 tacacs-server last-resort succeed
To force users who access the router via Telnet to authenticate themselves using TACACS, enter the following configuration commands:
line vty 0 4 login tacacs
This method of password checking can also be applied to the privileged mode password with the enable use-tacacs command. If all servers are unavailable, you may be locked out of the router. In that event, the configuration command enable last-resort [succeed | password] allows you to determine whether to allow a user to log in to the router with no password (succeed keyword) or to force the user to supply the enable password (password keyword). There are significant risks to using the succeed keyword. If you use the enable use-tacacs command, you must also specify the tacacs-server authenticate enable command.
The command username <user> password [0 | 7] <password> allows you to store and maintain a list of users and their passwords on a Cisco device instead of on a TACACS server. The number 0 stores the password in cleartext in the configuration file. The number 7 stores the password in an encrypted format. If you do not have a TACACS server and still want to authenticate users on an individual basis, you can set up users with the following configuration commands:
username steve password 7 steve-pass username allan password 7 allan-pass
The two users, Steve and Allan, will be authenticated via passwords that are stored in encrypted format.
Using TACACS service on routers and communications servers, support for physical card key devices, or token cards, can also be added. The TACACS server code can be modified to provide support for this without requiring changes in the setup and configuration of the routers and communication servers. This modified code is not directly available from Cisco.
The token card system relies on a physical card that must be in your possession in order to provide authentication. By using the appropriate hooks in the TACACS server code, third-party companies can offer these enhanced TACACS servers to customers. One such product is the Enigma Logic SafeWord security software system. Other card-key systems, such as Security Dynamics SmartCard, can be added to TACACS as well.
The SNMP agent on the router allows you to configure different community strings for nonprivileged and privileged access. You configure community strings on the router via the configuration command snmp-server community <string> [RO | RW] [access-list]. The following sections explore the various ways to use this command.
Unfortunately, SNMP community strings are sent on the network in cleartext ASCII. Thus, anyone who has the ability to capture a packet on the network can discover the community string. This may allow unauthorized users to query or modify routers via SNMP. For this reason, using the no snmp-server trap-authentication command may prevent intruders from using trap messages (sent between SNMP managers and agents) to discover community strings.
The Internet community, recognizing this problem, greatly enhanced the security of SNMP version 2 (SNMPv2) as described in RFC 1446. SNMPv2 uses an algorithm called MD5 to authenticate communications between an SNMP server and agent. MD5 verifies the integrity of the communications, authenticates the origin, and checks for timeliness. Further, SNMPv2 can use the data encryption standard (DES) for encrypting information.
Use the RO keyword of the snmp-server community command to provide nonprivileged access to your routers via SNMP. The following configuration command sets the agent in the router to allow only SNMP get-request and get-next-request messages that are sent with the community string "public":
snmp-server community public RO 1
You can also specify a list of IP addresses that are allowed to send messages to the router using the access-list option with the snmp-server community command. In the following configuration example, only hosts 1.1.1.1 and 2.2.2.2 are allowed nonprivileged mode SNMP access to the router:
access-list 1 permit 1.1.1.1 access-list 1 permit 2.2.2.2 snmp-server community public RO 1
Use the RW keyword of the snmp-server community command to provide privileged access to your routers via SNMP. The following configuration command sets the agent in the router to allow only SNMP set-request messages sent with the community string "private":
snmp-server community private RW 1
You can also specify a list of IP addresses that are allowed to send messages to the router by using the access-list option of the snmp-server community command. In the following configuration example, only hosts 5.5.5.5 and 6.6.6.6 are allowed privileged mode SNMP access to the router:
access-list 1 permit 5.5.5.5 access-list 1 permit 6.6.6.6 snmp-server community private RW 1
If a router regularly downloads configuration files from a Trivial File Transfer Protocol (TFTP) or Maintenance Operations Protocol (MOP) server, anyone who can access the server can modify the router configuration files stored on the server.
Communication servers can be configured to accept incoming local area transport (LAT) connections. Protocol translators and their translating router brethren can accept X.29 connections. These different types of access should be considered when creating a firewall architecture.
A firewall architecture is a structure that exists between you and the outside world to protect you from intruders. In most circumstances, intruders are represented by the global Internet and the thousands of remote networks it interconnects. Typically, a network firewall consists of several different machines as shown in Figure 16-1.
In this architecture, the router that is connected to the Internet (exterior router) forces all incoming traffic to go to the application gateway. The router that is connected to the internal network (interior router) accepts packets only from the application gateway.
The application gateway institutes per-application and per-user policies. In effect, the gateway controls the delivery of network-based services both into and from the internal network. For example, only certain users might be allowed to communicate with the Internet, or only certain applications are permitted to establish connections between an interior and exterior host.
The route and packet filters should be set up to reflect the same policies. If the only application that is permitted is mail, only mail packets should be allowed through the router. This protects the application gateway and avoids overwhelming it with packets that it would otherwise discard.
This section uses the scenario illustrated in Figure 16-2 to describe the use of access lists to restrict traffic to and from a firewall router and a firewall communication server.
In this case study, the firewall router allows incoming new connections to one or more communication servers or hosts. Having a designated router act as a firewall is desirable because it clearly identifies the router's purpose as the external gateway and avoids encumbering other routers with this task. In the event that the internal network needs to isolate itself, the firewall router provides the point of isolation so that the rest of the internal network structure is not affected.
Connections to the hosts are restricted to incoming file transfer protocol (FTP) requests and email services as described in the "Configuring the Firewall Router" section later in this chapter. The incoming Telnet, or modem, connections to the communication server are screened by the communication server running TACACS username authentication, as described in the "Configuring the Firewall Communication Server" section later in this chapter.
interface ethernet 0 ip address B.B.13.1 255.255.255.0 interface serial 0 ip address B.B.14.1 255.255.255.0 router igrp network B.B.0.0
This simple configuration provides no security and allows all traffic from the outside world onto all parts of the network. To provide security on the firewall router, use access lists and access groups as described in the next section.
In this case study, incoming email and news are permitted for a few hosts, but FTP, Telnet, and rlogin services are permitted only to hosts on the firewall subnet. IP extended access lists (range 100 to 199) and transmission control protocol (TCP) or user datagram protocol (UDP) port numbers are used to filter traffic. When a connection is to be established for email, Telnet, FTP, and so forth, the connection will attempt to open a service on a specified port number. You can, therefore, filter out selected types of connections by denying packets that are attempting to use that service. For a list of well-known services and ports, see the "Filtering TCP and UDP Services" section later in this chapter.
An access list is invoked after a routing decision has been made but before the packet is sent out on an interface. The best place to define an access list is on a preferred host using your favorite text editor. You can create a file that contains the access-list commands, place the file (marked readable) in the default TFTP directory, and then network load the file onto the router.
The network server storing the file must be running a TFTP daemon and have TCP network access to the firewall router. Before network loading the access control definition, any previous definition of this access list is removed by using the following command:
no access-list 101
The access-list command can now be used to permit any packets returning to machines from already established connections. With the established keyword, a match occurs if the TCP datagram has the acknowledgment (ACK) or reset (RST) bits set.
access-list 101 permit tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 established
If any firewall routers share a common network with an outside provider, you may want to allow access from those hosts to your network. In this case study, the outside provider has a serial port that uses the firewall router Class B address (B.B.14.2) as a source address as follows:
access-list 101 permit ip B.B.14.2 0.0.0.0 0.0.0.0 255.255.255.255
The following example illustrates how to deny traffic from a user attempting to spoof any of your internal addresses from the outside world (without using 9.21 input access lists):
access-list 101 deny ip B.B.0.0 0.0.255.255 0.0.0.0 255.255.255.255
The following commands allow domain name system (DNS) and network time protocol (NTP) requests and replies:
access-list 101 permit udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 53 access-list 101 permit udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 123
The following command denies the network file server (NFS) user datagram protocol (UDP) port:
access-list 101 deny udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 2049
The following commands deny OpenWindows on ports 2001 and 2002 and deny X11 on ports 6001 and 6002. This protects the first two screens on any host. If you have any machine that uses more than the first two screens, be sure to block the appropriate ports.
access-list 101 deny tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 6001 access-list 101 deny tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 6002 access-list 101 deny tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 2001 access-list 101 deny tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 2002
The following command permits Telnet access to the communication server (B.B.13.2):
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.2 0.0.0.0 eq 23
The following commands permit FTP access to the host on subnet 13:
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 eq 21 access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 eq 20
For the following examples, network B.B.1.0 is on the internal network. Figure 16-2The following commands permit TCP and UDP connections for port numbers greater than 1023 to a very limited set of hosts. Make sure no communication servers or protocol translators are in this list.
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 gt 1023 access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.1.100 0.0.0.0 gt 1023 access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.1.101 0.0.0.0 gt 1023 access-list 101 permit udp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 gt 1023 access-list 101 permit udp 0.0.0.0 255.255.255.255 B.B.1.100 0.0.0.0 gt 1023 access-list 101 permit udp 0.0.0.0 255.255.255.255 B.B.1.101 0.0.0.0 gt 1023
The following commands permit DNS access to the DNS server(s) listed by the Network Information Center (NIC):
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 eq 53 access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.1.100 0.0.0.0 eq 53
The following commands permit incoming simple mail transfer protocol (SMTP) email to only a few machines:
access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.13.100 0.0.0.0 eq 25 access-list 101 permit tcp 0.0.0.0 255.255.255.255 B.B.1.100 0.0.0.0 eq 25
The following commands allow internal network news transfer protocol (NNTP) servers to receive NNTP connections from a list of authorized peers:
access-list 101 permit tcp 16.1.0.18 0.0.0.1 B.B.1.100 0.0.0.0 eq 119 access-list 101 permit tcp 128.102.18.32 0.0.0.0 B.B.1.100 0.0.0.0 eq 119
The following command permits Internet control message protocol (ICMP) for error message feedback:
access-list 101 permit icmp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
Every access list has an implicit "deny everything else" statement at the end of the list to ensure that attributes that are not expressly permitted are in fact denied.
Fortunately, there is an alternative to this behavior that allows the client to open the "data" socket and allows you to have the firewall and FTP too. The client sends a PASV command to the server, receives back a port number for the data socket, opens the data socket to the indicated port, and finally sends the transfer.
In order to implement this method, the standard FTP client program must be replaced with a modified one that supports the PASV command. Most recent implementations of the FTP server already support the PASV command. The only trouble with this idea is that it breaks down when the server site has also blocked arbitrary incoming connections.
interface ethernet 0 ip access-group 101
To control outgoing access to the Internet from the network, define an access list and apply it to the outgoing packets on serial 0 of the firewall router. To do this, returning packets from hosts using Telnet or FTP must be allowed to access the firewall subnetwork B.B.13.0.
Some well-known TCP and UDP port numbers include the services listed in Table 16-3.
| Service | Port Type | Port Number |
|---|---|---|
File Transfer Protocol (FTP)—Data | TCP | 20 |
FTP—Commands | TCP | 21 |
Telnet | TCP | 23 |
Simple Mail Transfer Protocol (SMTP)—Email | TCP | 25 |
Terminal Access Controller Access Control System (TACACS) | UDP | 49 |
Domain Name Server (DNS) | TCP and UDP | 53 |
Trivial File Transfer Protocol (TFTP) | UDP | 69 |
finger | TCP | 79 |
SUN Remote Procedure Call (RPC) | UDP | 111 |
Network News Transfer Protocol (NNTP) | TCP | 119 |
Network Time Protocol (NTP) | TCP and UDP | 123 |
NeWS | TCP | 144 |
Simple Management Network Protocol (SNMP) | UDP | 161 |
SNMP (traps) | UDP | 162 |
Border Gateway Protocol (BGP) | TCP | 179 |
rlogin | TCP | 513 |
rexec | TCP | 514 |
talk | TCP and UDP | 517 |
ntalk | TCP and UDP | 518 |
Open Windows | TCP and UDP | 2000 |
Network File System (NFS) | UDP | 2049 |
TCP and UDP | 6000 |
The Computer Emergency Response Team (CERT) recommends filtering the services listed in Table 16-4.
| Service | Port Type | Port Number |
|---|---|---|
DNS zone transfers | TCP | 53 |
TFTP daemon (tftpd) | UDP | 69 |
link—commonly used by intruders | TCP | 87 |
SUN RPC | TCP and UDP | 1111 |
NFS | UDP | 2049 |
BSD UNIX r commands (rsh, rlogin, and so forth) | TCP | 512 through 514 |
line printer daemon (lpd) | TCP | 515 |
UNIX-to-UNIX copy program daemon (uucpd) | TCP | 540 |
Open Windows | TCP and UDP | 2000 |
X Windows | TCP and UDP | 6000+ |
In Software Release 9.21, Cisco introduces the ability to assign input access lists to an interface. This allows a network administrator to filter packets before they enter the router, instead of as they leave the router. In most cases, input access lists and output access lists accomplish the same functionality; however, input access lists are more intuitive to some people and can be used to prevent some types of IP address "spoofing" where output access lists will not provide sufficient security.
Figure 16-3 illustrates a host that is "spoofing," or illegally claiming to be an address that it is not. Someone in the outside world is claiming to originate traffic from network 131.108.17.0. Although the address is spoofed, the router interface to the outside world assumes that the packet is coming from 131.108.17.0. If the input access list on the router allows traffic coming from 131.108.17.0, it will accept the illegal packet. To avoid this spoofing situation, an input access list should be applied to the router interface to the outside world. This access list would not allow any packets with addresses that are from the internal networks of which the router is aware (17.0 and 18.0).
If you have several internal networks connected to the firewall router and the router is using output filters, traffic between internal networks will see a reduction in performance created by the access list filters. If input filters are used only on the interface going from the router to the outside world, internal networks will not see any reduction in performance.
In this case study, the firewall communication server has a single inbound modem on line 2:
interface Ethernet0 ip address B.B.13.2 255.255.255.0 ! access-list 10 deny B.B.14.0 0.0.0.255 access-list 10 permit B.B.0.0 0.0.255.255 ! access-list 11 deny B.B.13.2 0.0.0.0 access-list 11 permit B.B.0.0 0.0.255.255 ! line 2 login tacacs location FireWallCS#2 ! access-class 10 in access-class 11 out ! modem answer-timeout 60 modem InOut telnet transparent terminal-type dialup flowcontrol hardware stopbits 1 rxspeed 38400 txspeed 38400 ! tacacs-server host B.B.1.100 tacacs-server host B.B.1.101 tacacs-server extended ! line vty 0 15 login tacacs
In this example, the network number is used to permit or deny access; therefore, standard IP access list numbers (range 1 through 99) are used. For incoming connections to modem lines, only packets from hosts on the internal Class B network and packets from those hosts on the firewall subnetwork are permitted:
access-list 10 deny B.B.14.0 0.0.0.255 access-list 10 permit B.B.0.0 0.0.255.255
Outgoing connections are allowed only to internal network hosts and to the communication server. This prevents a modem line in the outside world from calling out on a second modem line:
access-list 11 deny B.B.13.2 0.0.0.0 access-list 11 permit B.B.0.0 0.0.255.255
Apply an access list to an asynchronous line with the access-class command. In this case study, the restrictions from access list 10 are applied to incoming connections on line 2. The restrictions from access list 11 are applied to outgoing connections on line 2.
access-class 10 in access-class 11 out
It is also wise to use the banner exec global configuration command to provide messages and unauthorized use notifications, which will be displayed on all new connections. For example, on the communication server, you can enter the following message:
banner exec ^C If you have problems with the dial-in lines, please send mail to helpdesk@Corporation X.com. If you get the message "% Your account is expiring", please send mail with name and voicemail box to helpdesk@CorporationX.com, and someone will contact you to renew your account. Unauthorized use of these resources is prohibited.
Most of these systems have their own defined protocol. Some, such as Mosaic, use several different protocols to obtain the information in question. Use caution when designing access lists applicable to each of these services. In many cases, the access lists will become interrelated as these services become interrelated.
Although this case study illustrates how to use Cisco network layer features to increase network security on IP networks, in order to have comprehensive security, you must address all systems and layers.
This section contains a list of publications that provide internetwork security information.
Cheswick, B. and Bellovin, S. Firewalls and Internet Security. Addison-Wesley.
Comer, D.E and Stevens, D.L., Internetworking with TCP/IP. Volumes I-III. Englewood Cliffs, New Jersey: Prentice Hall; 1991-1993.
Curry, D. UNIX System Security—A Guide for Users and System Administrators.
Garfinkel and Spafford. Practical UNIX Security. O'Reilly & Associates.
Quarterman, J. and Carl-Mitchell, S. The Internet Connection, Reading, Massachusetts: Addison-Wesley Publishing Company; 1994.
Ranum, M. J. Thinking about Firewalls, Trusted Information Systems, Inc.
Stoll, C. The Cuckoo's Egg. Doubleday.
Treese, G. W. and Wolman, A. X through the Firewall and Other Application Relays.
RFC 1118. "The Hitchhiker's Guide to the Internet." September 1989.
RFC 1175. "A Bibliography of Internetworking Information." August 1990.
RFC1244. "Site Security Handbook." July 1991.
RFC 1340. "Assigned Numbers." July 1992.
RFC 1446. "Security Protocols for SNMPv2." April 1993.
RFC 1463. "FYI on Introducing the Internet—A Short Bibliography of Introductory Internetworking Readings for the Network Novice." May 1993.
RFC 1492. "An Access Control Protocol, Sometimes Called TACACS." July 1993.
Documents at gopher.nist.gov.
The "Computer Underground Digest" in the /pub/cud directory at ftp.eff.org.
Documents in the /dist/internet_security directory at research.att.com.
Posted: Wed Apr 10 10:46:06 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.