| Previous | Table of Contents | Next |
If you create a criteria statement that explicitly permits all traffic, no statements added later will ever be checked. If you need additional statements, you must delete the access list and retype it with the new entries. When entering or modifying access lists, it is strongly suggested that you do not modify or alter them on-the-fly. You can design them on a TFTP server, in a word processor, or on paper. This author also recommends that you do not save the changes to the router until you are sure the desired security is adequately working. This will allow you a quick and easy back-out plan in case of errors. At the end of every access list is an implied “deny all traffic” criteria statement. Therefore, if a packet does not match any of your criteria statements, the packet will be blocked. Applying Access Lists to Interfaces You can apply only one access list to an interface for a given protocol. With most protocols, you can apply access lists to interfaces as either inbound or outbound. If the access list is inbound, when the router receives a packet, the Cisco IOS software checks the access list’s criteria statements for a match. If the packet is permitted, the software continues to process the packet. If the packet is denied, the software discards the packet. If the access list is outbound, after receiving and routing a packet to the outbound interface, the software checks the access list’s criteria statements for a match. If the packet is permitted, the software transmits the packet. If the packet is denied, the software discards the packet.
TIPS:
For most protocols, if you define an inbound access list for traffic filtering, you should include explicit access list criteria statements to permit routing updates. If you do not, you might effectively lose communication from the interface when routing updates are blocked by the implicit “deny all traffic” statement at the end of the access list.
Additional Resources on Access Lists The guidelines discussed previously apply, in general, to all protocols. However, the specific guidelines for creating access lists and applying them to interfaces vary from protocol to protocol. See the appropriate protocol-specific chapters in the Cisco IOS configuration guides and command references for detailed task information on each protocol-specific access list. Lock-and-Key Security (Dynamic Access Lists) To authorize remote access to local services, a common security solution is to create access lists as discussed previously. However, standard and static extended access lists have the following limitations: - • They can create the opportunity for break-ins by network hackers.
- • They are difficult to manage in a large internetwork.
- • They require the router to do excess processing, depending on entries in the access list.
- • They do not offer a challenge mechanism to authenticate individual users.
An improved security solution is the lock-and-key access feature, which is available only with IP extended access lists. Lock-and-key access enables you to set up dynamic access lists that grant access per user to a specific source/destination host through a user authentication process. You can allow user access through a firewall dynamically, without compromising security restrictions.
TIPS:
Caution: Enhancements to the access-list command are backward compatible; migrating from releases prior to Cisco IOS Release 11.1 converts your access lists automatically. However, releases prior to Cisco IOS Release 11.1 are not upwardly compatible with these enhancements. Therefore, if you save an access list with these images and then use software prior to Cisco IOS Release 11.1, the resulting access list will not be interpreted correctly. This could cause severe security problems. Save your old configuration files before booting these images. In Cisco IOS Release 11.1 software, lock-and-key access is dependent on Telnet. Standard Telnet is the required application on the host platform that activates the authentication process.
Implementation Considerations of Lock-and-Key Access Because lock-and-key access introduces a potential pathway through your network firewall, you need to evaluate the following serious considerations: - • Primary consideration is dynamic access. With dynamic access, there is the possibility that an unauthorized host, spoofing your authenticated address, can gain access behind the firewall. Lock-and-key access does not allow the address spoofing problem. The problem is identified here only as a concern to the user.
- • Performance is affected in the following two situations:
- • Each dynamic access list forces an access-list rebuild on the silicon switching engine (SSE). This causes the SSE switching path to slow down momentarily.
- • Dynamic access lists require the idle timeout facility (even if the timeout is left to default) and, therefore, cannot be SSE switched. These entries must be handled in the protocol fast-switching path.
- • Pay close attention to the border router configurations. Remote users create access list entries on the border router. The access list will grow and shrink dynamically. Entries are dynamically removed from the list after either the idle-timeout or max-timeout period expires. Large access lists degrade packet switching performance.
TIPS:
Caution: Lock-and-key access allows an external event to create an opening in the firewall. After this opening exists, the router is susceptible to source address spoofing. To prevent this, you need to provide encryption support using IP encryption with authentication or encryption. This issue is discussed further in this section. Spoofing is a problem with all existing access lists. Lock-and-key access does not address this problem.
Here are two examples of when you might use lock-and-key access: - • When you want a remote host to be able to access a host in your internetwork via the Internet. Lock-and-key access limits access beyond your firewall on an individual host or net basis.
- • When you want a subset of hosts on a network to access a host on a remote network protected by a firewall. With lock-and-key access, you can enable only a desired set of hosts to gain access by having them authenticate through a TACACS+ server.
| Previous | Table of Contents | Next |
| 