Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
When you create numbered ACLs, you enter an ACL number as the first argument of the global
ACL statement. The test conditions for an ACL vary depending on whether the number identifies
a standard or extended ACL.
You can create many ACLs for a protocol. Select a different ACL number for each new ACL within
a given protocol. However, you can apply only one ACL per protocol, per direction, and per
interface.
Specifying an ACL number from 1 to 99 or 1300 to 1999 instructs the router to accept numbered
standard IPv4 ACL statements. Specifying an ACL number from 100 to 199 or 2000 to 2699
instructs the router to accept numbered extended IPv4 ACL statements.
212 Chapter 6: Managing Traffic with Access Control Lists
Table 6-1 lists the different ACL number ranges for each protocol.
1 XNS = Xerox Network Services
2 IPX = Internetwork Packet Exchange
3 SAP = Service Advertisement Protocol
4 VINES = Virtual Integrated Network Service
As of Cisco IOS Software Release 12.0, IPv4 ACLs have been expanded. The table shows that standard IPv4 ACLS have
been expanded to include the numbers 1300 to 1999, and the extended IPv4 ACLs have been expanded to include the
numbers 2000 to 2699.
Table 6-1 Protocol ACL Numbers
Protocol Range
IP 1–99
Extended IP 100–199
Ethernet type code 200–299
Ethernet address 700–799
Transparent bridging (protocol type) 200–299
Transparent bridging (vendor code) 700–799
Extended transparent bridging 1100–1199
DECnet and extended DECnet 300–399
XNS1 400–499
Extended XNS 500–599
AppleTalk 600–699
Source-route bridging (protocol type) 200–299
Source-route bridging (vendor code) 700–799
IPX2 800–899
Extended IPX 900–999
IPX SAP3 1000–1099
Standard Banyan VINES4 1–100
Extended Banyan VINES 101–200
Simple Banyan VINES 201–300
Standard IP (expanded) 1300–1999
Extended IP (expanded) 2000–2699
Access Control List Operation 213
The named ACL feature enables you to identify IP standard and extended ACLs with an
alphanumeric string (name) instead of the numeric representations. Named IP ACLs give you
more flexibility in working with the ACL entries.
IP access list entry sequence numbering has several benefits:
■ You can edit the order of ACL statements.
■ You can remove individual statements from an ACL.
Where additions are placed in an ACL depends on whether you use sequence numbers. There is
no support for sequence numbering in software versions earlier than Cisco IOS Software Release
12.3; therefore, all the ACL additions for earlier software versions are placed at the end of the
ACL.
IP access list entry sequence numbering is a new edition to Cisco IOS Software that enables you
to use sequence numbers to easily add, remove, or reorder statements in an IP ACL. With Cisco
IOS Software Release 12.3 and later, additions can be placed anywhere in the ACL based on the
sequence number.
Earlier than Cisco IOS Software Release 12.3, only named ACLs enable the removal of individual
statements from an ACL using the following command:
no {deny | permit} protocol source source-wildcard destination destination-wildcard
The protocol source source-wildcard destination destination-wildcard parameters match the line
you are trying to remove. With numbered ACLs, you would have to remove the whole list and recreate
it with the desired statements. With Cisco IOS Software Release 12.3 and later, you can also
use the no sequence-number command to delete a specific access list entry.
Well-designed and well-implemented ACLs add an important security component to your
network. Follow these general principles to ensure that the ACLs you create have the intended
results:
■ Based on the test conditions, choose a standard or extended, numbered, or named ACL.
■ Only one ACL per protocol, per direction, and per interface is allowed. Multiple ACLs are
permitted per interface, but each must be for a different protocol or different direction.
■ Your ACL should be organized to enable processing from the top down. Organize your ACL
so that the more specific references to a network or subnet appear before ones that are more
general. Place conditions that occur more frequently before conditions that occur less
frequently.
214 Chapter 6: Managing Traffic with Access Control Lists
■ Your ACL contains an implicit deny any statement at the end:
— Unless you end your ACL with an explicit permit any statement, by default, the ACL
denies all traffic that fails to match any of the ACL lines.
— Every ACL should have at least one permit statement. Otherwise, all traffic is
denied.
■ You should create the ACL before applying it to an interface. With most versions of Cisco IOS
Software, an interface that has an empty ACL applied to it permits all traffic.
■ Depending on how you apply the ACL, the ACL filters traffic either going through the router
or going to and from the router, such as traffic to or from the vty lines.
■ You should typically place extended ACLs as close as possible to the source of the traffic that
you want to deny. Because standard ACLs do not specify destination addresses, you must put
the standard ACL as close as possible to the destination of the traffic you want to deny so the
source can reach intermediary networks.
Additional Types of ACLs
Standard and extended ACLs can become the basis for other types of ACLs that provide additional
functionality. These other types of ACLs include the following:
■ Dynamic ACLs (lock-and-key)
■ Reflexive ACLs
■ Time-based ACLs
Dynamic ACLs
Dynamic ACLs depend on Telnet connectivity, authentication (local or remote), and extended
ACLs. Lock-and-key configuration starts with the application of an extended ACL to block traffic
through the router. Users who want to traverse the router are blocked by the extended ACL until
they use Telnet to connect to the router and are authenticated. The Telnet connection is then
dropped, and a single-entry dynamic ACL is added to the extended ACL. This permits traffic for
a particular period; idle and absolute timeouts are possible. Figure 6-6 shows an example of
dynamic access lists.
Figure 6-6 Dynamic ACL
1) Use Telnet to connect to
router and authenticate.
2) Use FTP, HTTP, and so
on to connect to server.
Access Control List Operation 215
Some common reasons to use dynamic ACLs are as follows:
■ Use dynamic ACLs when you want a specific remote user or group of remote users to access
a host within your network, connecting from their remote hosts via the Internet. Lock-andkey
authenticates the user and permits limited access through your firewall router for a host
or subnet for a finite period.
■ Use dynamic ACLs when you want a subset of hosts on a local network to access a host on a
remote network that is protected by a firewall. With lock-and-key, you can enable access to
the remote host only for the desired set of local hosts. Lock-and-key requires the users to
authenticate through a TACACS+ server, or other security server, before it allows their hosts
to access the remote hosts.
Dynamic ACLs have the following security benefits over standard and static extended ACLs:
■ Use of a challenge mechanism to authenticate individual users
■ Simpler management in large internetworks
■ In many cases, reduction of the amount of router processing that is required for ACLs
■ Reduction of the opportunity for network break-ins by network hackers
■ Creation of dynamic user access through a firewall, without compromising other configured
security restrictions
Although the entire configuration for a dynamic ACL is outside the scope of this course, the
following example shows the steps that are required to configure a dynamic ACL. The goal of a
dynamic ACL is to provide a means for some users on a network to have access through the router
without knowing exactly what devices they will be connecting from. This type of list requires the
end user to log in to the router from the device to set up a temporary access list to permit the traffic.
The following configuration creates a login name and password for authentication. The idle
timeout is set to 10 minutes.
RouterX(config)#username test password test
RouterX(config)#username test autocommand access-enable host timeout 10
The following configuration enables users to open a Telnet connection to the router that is to be
authenticated and blocks all other traffic:
RouterX(config)#access-list 101 permit tcp any host 10.1.1.1 eq telnet
RouterX(config)#interface Ethernet0/0
RouterX(config-if)#ip address 10.1.1.1 255.255.255.0
RouterX(config-if)#ip access-group 101 in
216 Chapter 6: Managing Traffic with Access Control Lists
The following configuration creates the dynamic ACL that will be automatically applied to the
existing access-list 101. The absolute timeout is set to 15 minutes.
RouterX(config)#access-list 101 dynamic testlist timeout 15 permit ip 10.1.1.0
0.0.0.255 172.16.1.0 0.0.0.255
The following configuration forces users to authenticate when they open a Telnet connection to
the router:
RouterX(config)#line vty 0 4
RouterX(config-line)#login local
After you have done these configurations, when the user at 10.1.1.2 successfully makes a Telnet
connection to 10.1.1.1, the dynamic ACL is applied. The connection is then dropped, and the user
can access the 172.16.1.x network.
Reflexive ACLs
Reflexive ACLs allow IP packets to be filtered based on upper-layer session information such as
TCP port numbers. They are generally used to allow outbound traffic and limit inbound traffic in
response to sessions that originate from a network inside the router. Reflexive ACLs contain only
temporary entries. These entries are automatically created when a new IP session begins, for
example, with an outbound packet, and the entries are automatically removed when the session
ends. Reflexive ACLs are not applied directly to an interface but are “nested” in an extended
named IP ACL that is applied to the interface.
Reflexive ACLs provide a truer form of session filtering than an extended ACL that uses the
established parameter. Reflexive ACLs are much harder to spoof because more filter criteria must
match before a packet is permitted through; for example, source and destination addresses and port
numbers, not just acknowledgment (ACK) and reset (RST) bits, are checked. Figure 6-7 illustrates
how the reflexive access list operates.
Figure 6-7 Reflexive Access Lists
Inbound Traffic
Initiated Outside
S0
Inbound Traffic
Initiated Inside
X
Access Control List Operation 217
Reflexive ACLs are an important part of securing your network against network hackers and can
be included in a firewall defense. Reflexive ACLs provide a level of security against spoofing and
certain denial of service (DoS) attacks. Reflexive ACLs are simple to use and, compared to basic
ACLs, provide greater control over which packets enter your network.
Although the entire configuration for reflexive ACLs is outside the scope of this course, the
following example shows the steps that are required to configure a reflexive ACL. The example is
of a reflexive ACL that permits Internet Control Message Protocol (ICMP) outbound and inbound
traffic, while it permits only TCP traffic that has initiated from inside. All other traffic is denied.
The following configuration causes the router to keep track of traffic that was initiated from inside:
RouterX(config)#ip access-list extended outboundfilters
RouterX(config-ext-nacl)#permit icmp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255
RouterX(config-ext-nacl)#permit tcp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255 reflect
tcptraffic
The next configuration creates an inbound policy that requires the router to check incoming traffic
to see whether it was initiated from inside and ties the reflexive ACL part of the outboundfilters
ACL, called tcptraffic, to the inboundfilters ACL:
RouterX(config)#ip access-list extended inboundfilters
Router(config-ext-nacl)#permit icmp 172.16.1.0 0.0.0.255 10.1.1.0 0.0.0.255 evaluate
tcptraffic
The configuration in Example 6-1 applies to both an inbound and an outbound ACL to the
interface.
Reflexive ACLs can be defined only with extended named IP ACLs. They cannot be defined with
numbered or standard named IP ACLs or with other protocol ACLs.
Time-Based ACLs
Time-based ACLs are similar to extended ACLs in function, but they allow for access control
based on time. To implement time-based ACLs, you create a time range that defines specific times
of the day and week. The time range is identified by a name and then referenced by a function.
Therefore, the time restrictions are imposed on the function itself. For example, in Figure 6-8, a
user is blocked from transmitting HTTP traffic after 7:00 p.m.
Example 6-1 Applying Inbound and Outbound ACLs to an Interface
RouterX(config)#interface Ethernet0/1
RouterX(config-if)#ip address 172.16.1.2 255.255.255.0
RouterX(config-if)#ip access-group inboundfilters in
RouterX(config-if)#ip access-group outboundfilters out
218 Chapter 6: Managing Traffic with Access Control Lists
Figure 6-8 Timed Access Lists
Time-based ACLs have many benefits:
■ The network administrator has more control over permitting or denying a user access to
resources. These resources could be an application, identified by an IP address and mask pair
and a port number; policy routing; or an on-demand link, identified as interesting traffic to the
dialer.
■ Network administrators can set time-based security policies such as the following:
— Perimeter security using the Cisco IOS Firewall feature set or ACLs
— Data confidentiality with Cisco Encryption Technology or IP security (IPsec)
■ Policy-based routing and queuing functions are enhanced.
■ When provider access rates vary by time of day, it is possible to automatically reroute traffic
cost effectively.
■ Service providers can dynamically change a committed access rate (CAR) configuration to
support the QoS service-level agreements (SLA) that are negotiated for certain times of day.
■ Network administrators can control logging messages. ACL entries can log traffic at certain
times of the day but not constantly. Therefore, administrators can simply deny access without
analyzing the many logs that are generated during peak hours.
Although the entire configuration for time-based ACLs is outside the scope of this course, the
following example shows the steps that are required to configure a time-based ACL. In the
example, a Telnet connection is permitted from the inside network to the outside network on
Monday, Wednesday, and Friday during business hours.
The following configuration defines the time range to implement the ACL and names it:
RouterX(config)#time-range EVERYOTHERDAY
RouterX(config-time-range)#periodic Monday Wednesday Friday 8:00 to 17:00
Use HTTP to Connect
to Server X
7 p.m.
Access Control List Operation 219
The following configuration applies the time range to the ACL:
RouterX(config)#access-list 101 permit tcp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255
eq telnet time-range EVERYOTHERDAY
The following configuration applies the ACL to the interface:
RouterX(config)#interface Ethernet0/0
RouterX(config-if)#ip address 10.1.1.1 255.255.255.0
RouterX(config-if)#ip access-group 101 in
The time range relies on the router system clock. The router clock can be used, but the feature
works best with Network Time Protocol (NTP) synchronization.
No comments:
Post a Comment