source and IP address, destination IP address,
source TCP or User Datagram Protocol [UDP] ports, destination
TCP or UDP ports, or optional protocol type information for
finer granularity of control). The second example in Figure
configures ACL 101 to permit traffic that originates from any
address on the 172.31.9.0/24 network to any destination host
port 80 (http). More information on extended ACLs appears later
in this lesson. Identifying ACLs
Either a
number or a name can identify Cisco ACLs and the protocols that
they filter as shown in Figure . Using numbered ACLs is
effective on smaller networks that do not have as wide a range
of traffic types as do larger networks. Because each ACL type
is limited to an assigned range of numbers, it is easy to
determine the type of ACL that you are using. There can be up
to 99 standard IP ACLs in the range from 1 to 99. The extended
IP ACL number range is assigned from 100 to 199 and from 2000
to 2699. Figure lists the number range and the type of
associated ACL. You can also identify ACLs with an alphanumeric
string (a name) rather than a number. Named ACLs allow you to
configure more ACLs in a router than if you were to use
numbered ACLs alone. Note
If you identify your ACL
with a name rather than a number, the mode and command syntax
for the ACL are slightly different. Currently, only packet and
route filters can use a named ACL. Guidelines for Developing
ACLs
Figure lists recommended methods to follow when
creating effective, easy-to-use, and easy-to-understand ACLs.
Before you start to develop any ACLs, consider these basic
rules: - Base your ACLs on your security
policy: Unless the ACL is anchored in a comprehensive
security policy, you cannot be absolutely certain that the ACL
will effectively control access in the way access needs to be
controlled.
- Write the ACL out: Never sit down
at a router and start to develop an ACL without first spending
some time in design. The best ACL developers suggest that you
write out a list of things you want the ACL to accomplish.
Starting with something as simple as, “This ACL must block all
Simple Network Management Protocol (SNMP) access to the router
except for the SNMP host at 10.1.1.15.”
- Set up a
development system: Whether you use your laptop PC or a
dedicated server, you need a place to develop and store your
ACLs. Word processors or text editors of any kind are suitable,
as long as you can save the files in ASCII text format. Build
yourself a library of your most commonly used ACLs and use the
saved ACLs as sources for new files. ACLs can be pasted into
the router running configuration (requires console or Telnet
access), or can be stored in a router configuration file. The
system you choose should support TFTP to make it easy to
transfer any resulting configuration files to the router.
Note
Hackers love to gain access to router
configuration development systems or TFTP servers that store
ACLs. A hacker can discover a lot about your network from
looking at these easily read text files. For this reason, it is
imperative that the system where you choose to develop and
store your router files be a secure system. - Order
of statements within an ACL is critical: Once a match is
found, no more statements will be checked. For example, “most
restrictive statements should be first.”
-
Test: If possible, test your ACLs in a secure
environment before placing them into production. Testing is a
common-sense approach to any router configuration changes. Most
enterprises maintain their own network test beds. While testing
may appear to be an unnecessary cost, over time testing can
save time and money.
Content 5.7
Mitigating Threats and Attacks with Access Lists
5.7.2 Applying ACLs to Router Interfaces
Packet-filtering ACLs must be applied to a router interface to
take effect. It is important to note that ACLs are applied to
an interface based on the direction of the data flow as shown
in Figure . Figure also shows the very simple concept of how
you apply the ACL to incoming packets (an “in” ACL) or outgoing
packets (an “out” ACL), as follows: - Inbound
(in): The packet filtering ACL applies to packets received
on the router interface.
- Outbound (out): The
packet filtering ACL applies to packets transmitted out of the
router interface. For outbound ACLs, you only need to set up
the filter on one outgoing interface rather than on individual
incoming interfaces. This configuration improves performance
because only the network you are protecting will force a lookup
on the ACL.
Content 5.7 Mitigating
Threats and Attacks with Access Lists 5.7.3
Using Traffic Filtering with ACLs Figure shows a network
with ACLs installed as filters to partition off specific
security zones. Always apply the following general rules when
deciding how to handle router services, ports, and protocols:
- Disable unused services, ports, or protocols. In the
case where no machine, including the router itself, needs to
use an enabled service, port, or protocol, disable that
service, port, or protocol.
- Limit access to services,
ports, or protocols. In the case where a limited number of
users or systems require access to an enabled router service,
port, or protocol, limit access to that service, port, or
protocol using ACLs.
ACLs are important because they
act as traffic filters between the corporate (trusted) network
and the Internet (untrusted network). Using ACLs, the router
enforces corporate security policies by rejecting protocols and
restricting port use. The Blocked Services tables shown in
Figures and contain a list of common router services that can
be used to gather information about your network or, worse, can
be used to attack your network. Unless your network
configuration specifically requires one of these services, the
services should not be allowed to traverse the router. Use ACLs
to block these services inbound to the protected network and
outbound to the Internet. The Denied Services table shown in
Figure contains a listing of common services that reside either
on the corporate protected network or on the router itself. You
should deny these services to untrusted clients using ACLs.
These are two ways to control access to router services:
- Disable the service itself: Once a router service is
disabled, no one can use that service. Disabling a service is
safer and more reliable than attempting to block all access to
the service using an ACL.
- Restrict access to the
service using ACLs: If your situation requires limited
access to a service, build and test appropriate ACLs to apply
to the service.
Content 5.7
Mitigating Threats and Attacks with Access Lists
5.7.4 Filtering Network Traffic to Mitigate
Threats ACLs can be used to mitigate many threats:
- IP address spoofing—Inbound
- IP address
spoofing—Outbound
- Denial of service (DoS) TCP SYN
attacks—Blocking external attacks
- DoS TCP SYN
attacks—Using TCP Intercept
- DoS Smurf attacks
- Filtering Internet Control Message Protocol (ICMP)
messages—Inbound
- Filtering ICMP
messages—Outbound
- Filtering traceroute
Please note that each of the following examples are not
complete solutions and only provide statements to resolve the
specific problem. IP Address Spoofing—Inbound
As a
rule, do not allow any IP packets that contain the source
address of any internal hosts or networks inbound to a private
network. Figure shows ACL 150 for router R2. In this example,
any packets containing these IP addresses in their source field
will be denied: - Addresses from the internal 10.2.1.0
network
- Any local host addresses (127.0.0.0/8)
- Any reserved private addresses (RFC 1918), in this case
with the exception of 10.0.0.0/8, which is used for
addressing
- Any addresses in the IP multicast address