Creating Static Packet Filters with ACLs

Creating Static Packet Filters with ACLs

You should already have an understanding of the basics of ACLs as covered in CCNA material. This being the case, we can forgo the basics of creating and applying access lists to interfaces (and also vtys) in favor of focusing on examples and recommendations for their use. We will look at some specific examples of their use, both using the CLI and the Cisco SDM.
In this section, we examine the use of interface ACLs in the context of creating a static packet-filtering firewall and examining the relative strengths and weaknesses of this type of firewall. Remember, these are not particularly intelligent firewalls but, as we see, they do have an important role in the Cisco Self-Defending Network.

Threat Mitigation with ACLs

ACLs can mitigate the following types of threats:

• Inbound IP address spoofing
• Outbound IP address spoofing
• DoS and DDoS TCP SYN attacks
• DoS smurf attacks
• Inbound and outbound ICMP messages (used for DoS attacks and reconnaissance)
• Traceroute (used for reconnaissance)

Inbound Versus Outbound

There are two different meanings for “inbound” and “outbound,” depending on the context in which they are used:

• Definition One—Security Zone Context. The words “inbound” and “outbound” are used in the preceding list. What do they mean? Do they indicate directions of packet flow relative to security zones? In this context, yes. Outbound traffic is traffic flowing from a more-trusted zone to a less-trusted zone. Inbound traffic is traffic flowing from a less-trusted zone to a more-trusted zone.
• Inbound. For example, IP packets arriving inbound on an Internetfacing interface should never have a source address of an internal network. Configuring an ACL to check the source addresses would be relatively simple.
• Outbound. Similarly, packets arriving on a LAN interface (or leaving an Internet-facing interface) would constitute outbound traffic, and should only contain source addresses from the organization’s own address space, whether they are network address translated or not.
• Definition Two—Interface ACL Context. “Inbound” and “outbound” can also be relative to the interfaces themselves. This is an important distinction because after you create an interface ACL, you have to apply it either in(bound) or out(bound) on an interface.
• Inbound ACLs. These ACLs check packets as they arrive on an interface from a connected network. For example, a packet that arrives on a LAN interface from the physical network that it is connected to would be inbound. Thus, this traffic has not been routed yet and, in fact, the router hasn’t decided whether to route it or not. Inbound ACLs are more efficient in terms of processing because if a packet is denied by the ACL, no CPU time has been wasted performing a routing table lookup. A permitted packet will be routed.
• Outbound ACLs. These ACLs check the packets after they have been dispatched to the correct interface per the routing table and prior to being forwarded to the connected network. A permitted packet will be sent to the output buffer and a denied packet will be discarded.

Identifying ACLs

Let’s review how to identify ACLs on Cisco IOS routers:

• Numbered ACL:
• The number indicates the protocol that is being filtered.
• The ranges 1–99 and 1300–1999 indicate standard ACLs (filter all of IP, source address only). Cannot create a layer 4 firewall with these.
• The ranges 100–199 and 2000–2699 indicate extended ACLs (filter IP,
  protocols encapsulated in IP, source and destination socket [address and port] as applicable). Can create a layer 4 firewall with these.
• Named ACL:
• Can use custom name for ACL (available from Cisco IOS Release 11.2).
• Rules: Names contain alphanumeric characters but no spaces or punctuation. Must begin with an alphabetic character.
• Can be either standard or extended.
• Can add or delete entries within the ACL.

ACL Examples Using the CLI

We look at two examples of ACLs in action using the CLI. This will be a useful review of basic ACL concepts, as first we create and apply a numbered extended ACL and second, examine the use of established parameters in ACLs, as well as how to edit an existing ACL.

Example 1: Numbered IPv4 ACL

Figure 5.8 illustrates the goals of the ACL we are creating.

The following CLI commands match Figure 5.8. First, we create the ACL and then apply it to the Internet-facing interface, FastEthernet 4. This is a very common and practical use for an ACL. ACLs are usually applied on perimeter devices, such as routers, where simple rules can be used. The idea is to get rid of traffic that is absolutely not allowed as early as possible, leaving whatever is left over for other devices further inside our network. This concept of nesting of perimeters is discussed in Chapter 4. In this example, we create an anti-spoofing rule, ensuring that the source address of any inbound packets to our network do not match our internal network. Then we explicitly permit the traffic that is allowed, namely traffic to the HTTP and SSH servers in the Demilitarized Zone (DMZ).

CiscoISR(config) #access- list 1 01 remark — - anti- spoofing rule
CiscoISR(config) #access- list 1 01 deny ip 1 0. 1 0. 1 0. 0 0. 0. 0. 255 any
CiscoISR(config) #access- list 1 01 remark — — permit HTTP and SSH to inside
CiscoISR(config) #access- list 1 01 permit tcp any 1 0. 1 0. 1 0. 0 0. 0. 0. 255 eq 80
CiscoISR(config) #access- list 1 01 permit tcp any 1 0. 1 0. 1 0. 0 0. 0. 0. 255 eq 22
CiscoISR(config) #interface FastEthernet 4
CiscoISR(config-if) #ip access- group 1 01 in
You can review the access-list and the matches against the ACEs with the show access-list command. Note that the remarks do not display with the show
access-list command output. You can only see them when you view the runningconfig:
CiscoISR#show access- list 1 01
Extended IP access list 101
10 deny ip 10.10.10.0 0.0.0.255 any (109 matches)
20 permit tcp any 10.10.10.0 0.0.0.255 eq www (11532 matches)
30 permit tcp any 10.10.10.0 0.0.0.255 eq 22 (23453 matches)
CiscoISR(config)#

Note that the show access-list 101 command displays sequence numbers (10, 20, 30, and so on) in the numbered ACL. As of Cisco IOS Software Release 12.3, you can delete and insert ACEs using these sequence numbers. For example, if we wanted to delete sequence 10 (the anti-spoofing ACE), we could enter these CLI commands:

CiscoISR(config) #ip access- list extended 1 01
CiscoISR(config-ext-nacl) #no 1 0
CiscoISR(config-ext-nacl) #
This deletes ACE 10, but does not re-sequence the ACL:
CiscoISR#show access- list 1 01
Extended IP access list 101
20 permit tcp any 10.10.10.0 0.0.0.255 eq www (11989 matches)
30 permit tcp any 10.10.10.0 0.0.0.255 eq 22 (23492 matches)
CiscoISR(config)#

You can use similar logic to insert ACEs too. Let’s combine that thought with the established parameter in the next example.

Example 2: Established Command and Inserting ACEs

The second example covers the two concepts of established command and inserting ACEs. A static packet filtering router will never be stateful. That said, what if you want to make sure that applying an ACL to an interface does not drop existing TCP sessions? The established parameter in an ACE allows the router to examine the flags in the TCP header and permit TCP segments that have the RST or ACK bit set because only active TCP sessions would have at least one or the other of these bits set. Continuing with the previous example (also refer to Figure 5.8), if you wanted to ensure that all existing TCP sessions remain active, you could enter this CLI command to put it at the beginning of access-list 101:

CiscoISR(config) #ip access- list extended 1 01
CiscoISR(config-ext-nacl) #5 permit tcp any any established
CiscoISR(config-ext-nacl) #do show access- list 1 01
Extended IP access list 101
5 permit tcp any any established (96 matches)
20 permit tcp any 10.10.10.0 0.0.0.255 eq www (12032 matches)
30 permit tcp any 10.10.10.0 0.0.0.255 eq 22 (25000 matches)
CiscoISR(config-ext-nacl)#

Of course, we don’t know what existing TCP sessions are being permitted across our firewall, so best practices dictate that we would specify minimally the port number of the established protocol that is being permitted. For example, if the HTTP server in the DMZ were somehow hijacked by a hacker, it might try to initiate a connection out to the Internet using some other protocol, perhaps Telnet (TCP Port 23). If we left ACL 101 as is, the hijacked server could initiate a Telnet connection (SYN) outbound to the Internet and the reply (SYN, ACK) would be allowed back through the firewall on the established ACE in the ACL. Not good!

You can verify that an ACL is applied on an interface and what direction it is applied in by using the show ip interface command:

CiscoISR#show ip interface FastEthernet 4
FastEthernet4 is up, line protocol is up
Internet address is 192.168.99.218/25
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is 101
Proxy ARP is disabled
[output omitted]

ACL Guidelines

Table 5.1 outlines Cisco’s general best practices for the use of ACLs.

Using the Cisco SDM to Configure ACLs

Using the Cisco SDM to configure ACLs follows the same rules as using the CLI. First, you create the ACL, and then you apply it to the interface in the correct direction.

In this example, we create an extended ACL (if you master this, you can easily do a standard ACL) called “inside-servers” that will permit HTTP and SSH to the DMZ. In fact, this ACL will follow the example we just completed in the CLI.

1. Choose Configure->Additional Tasks->ACL Editor->Access Rules.
2. Click Add. The Add a Rule window appears.
3. Enter a name or number for the ACL in the Add a Rule window (following the rules for names and number ranges, of course!). We’ll give it the name inside-servers.
4. Confirm that Extended Rule is selected in the drop-down list. You can also put in a rule description (optional).
5. Click Add. The Add an Extended Rule Entry window appears.
   Figure 5.9 illustrates the addition of an extended ACL entry using the Cisco SDM.
   
6. Choose Permit or Deny from the Select an action drop-down list. You can also add a description (fewer than 100 characters) in the Description field. We will choose Permit.
7. You have a choice of either using Any IP Address (that is, the default) for the address, or you can construct the IP addresses by selecting the address type in the Type drop-down list. The Type drop-down list gives you three choices:
   • A Network
   • A Host Name or IP Address
   • Any IP Address (selected by default)
     In the Destination Host/Network list, we choose A Network in this example. Enter the IP address of the network and a wildcard mask as required (10.10.1.0 and 0.0.0.255, respectively, in our example).
8. For the Source Host/Network, we choose Any IP Address because we don’t know what the source address will be of the Internet users of our DMZ servers.
9. We’re not done yet! Click the radio button in the Protocol and Services section that corresponds to the protocol that is being filtered—TCP, in our case.
10. Again, we can’t be too specific about the source port because we don’t know what dynamic port number the Internet client will choose, so we’ll leave it at the default, which is = and any.
11. We can be specific for the destination port because it is a WWW server, so we choose = and www, respectively, for the destination port. You can also manually enter the destination port number or name.
12. If our security policy dictates that we need to log access to the DMZ server, we can check the Log matches against this entry check box.
13. Click OK when finished. This will return you to the Add a Rule window.
14. Repeat the preceding steps, but for the SSH server too (which is at Destination Port = 22). You can either click Add and go through all the steps again, or you can click the Clone button that will clone the selected entry and then you can simply edit the Destination Port number in the resultant Add an Extended Rule Entry window.
15. The ACL doesn’t do anything by itself. It now must be associated with an interface. Click the Associate button and select the interface and direction in the Associate with an Interface window.

Figure 5.10 illustrates the dialog box for associating an ACL to an interface in the Cisco SDM.

16. Alternatively you can choose Configure->Interfaces and Connections and select the interface you want to associate the ACL with. In the
Interface Feature Edit Dialog window, put in the ACL name or number in the Inbound or Outbound access rule fields, as shown in Figure 5.11.

Using ACLs to Filter Network Services

You may recall from Chapter 4 that there were a number of services that run on the router by default, which would be useful to lock down. Some of these services could be used by an attacker for reconnaissance. Some others might make the router vulnerable to DoS attacks. In this example, we are configuring the router so it will only accept RIP, EIGRP, and OSPF routing table updates from IP address 192.168.99.129, a neighbor router. This will mitigate the possibility that a knowledgeable attacker could engineer routing packets that inject erroneous routing table information into the router. Neither OSPF nor EIGRP use TCP or UDP for transport. They are services that use their own protocol IDs and are encapsulated directly into the IP packet header. The protocol ID field in the IP packet header identifies what protocol is inside the IP packet. An OSPF router, for example, would ignore IP packets with protocol ID 88 because that protocol ID identifies EIGRP. Some useful numbers to remember are as follows:

• ICMP: protocol ID 1
• TCP: protocol ID 6
• UDP: protocol ID 17
• GRE: protocol ID 47 (used by Microsoft VPNs and others)
• ESP: protocol ID 50 (used by IPsec VPNs)
• EIGRP: protocol ID 88 (proprietary Cisco routing protocol)
• OSPF: protocol ID 89 (open standard routing protocol)

While constructing an ACL in the Cisco SDM, you can click on the ellipse beside the IP Protocol field to see a list of the built-in protocol IDs in the Cisco SDM. You can also manually enter the protocol ID number if it is not in the list.
Figure 5.12 shows the Protocol window in the Add an Extended Rule Entry window.

Here are the resulting CLI commands in the configuration generated by the Cisco SDM for the named extended IP ACL inbound-routing:

ip access-list extended inbound-routing
remark SDM_ACL Category=1
permit ospf host 192.168.99.129 any
permit eigrp host 192.168.99.129 any
permit udp host 192.168.99.129 any eq rip
interface FastEthernet 4
ip access-group inbound-routing in

FIGURE 5.12 Protocol window in the Add an Extended Rule Entry window of the Cisco SDM.

Using ACLs to Mitigate IP Address Spoofing Attacks

As indicated in Figure 5.8 and in the accompanying subsection, “ACL Examples Using the CLI,” ACLs can be very effective in mitigating IP address spoofing attacks. We will examine their use in mitigating both inbound IP address spoofing and outbound IP address spoofing.

Inbound IP Address Spoofing

In general, the source IP address in packets arriving inbound (that is, from a less-trusted network) should not be the same as an internal network’s IP address range. That said, there are other source IP addresses that have no business being in these inbound packets. Here are guidelines for other IP addresses that normally should not be in the source address field, particularly when this Internet is connected to the Internet and therefore public, routable IP address space:

• Local addresses. 127.0.0.0/8 (used for loopback testing, for example).
• Reserved private addresses. Defined in RFC 1918, Address Allocation for Private Internets.
• IP multicast addresses. 224.0.0.0/4.
• Any address starting with a 0. 0.0.0.0/24 (for example, DHCP uses 0.0.0.0 in the source address field for DHCP requests).
• All 1’s source IP addresses. 255.255.255.255.
  Remember ACL 101 that we created earlier to permit traffic to the DMZ and only to the HTTP and SSH servers there? Let’s take the opportunity to put a few key points together and modify it. We will follow the guideline of most specific ACEs first that we covered in a previous section, which means that we have a problem already. If we start adding ACEs to the existing numbered ACL 101, the new ACEs will go to the bottom of the ACL.

First, use the show access-list 101 command to verify the existing ACL:

CiscoISR(config)#do show access-list 101 Extended IP access list 101
10 permit tcp any 10.10.10.0 0.0.0.255 eq www
20 permit tcp any 10.10.10.0 0.0.0.255 eq 22
CiscoISR(config)#

Then, use the new features of Cisco IOS Software version 12.3 and later that enable you to use sequence numbers to add statements to an existing numbered ACL. We must insert these new lines ahead of the existing sequence number 10:

CiscoISR(config) #ip access- list extended 1 01
CiscoISR(config-ext-nacl) #1 deny ip 0. 0. 0. 0 0. 255. 255. 255 any
CiscoISR(config-ext-nacl) #2 deny ip 1 0. 0. 0. 0 0. 255. 255. 255 any
CiscoISR(config-ext-nacl) #3 deny ip 1 27. 0. 0. 0 0. 255. 255. 255 any
CiscoISR(config-ext-nacl) #4 deny ip 1 72. 1 6. 0. 0 0. 1 5. 255. 255 any
CiscoISR(config-ext-nacl) #5 deny ip 1 92. 1 68. 0. 0 0. 0. 255. 255 any
CiscoISR(config-ext-nacl) #6 deny ip 224. 0. 0. 0 1 5. 255. 255. 255 any
CiscoISR(config-ext-nacl) #7 deny ip host 255. 255. 255. 255 any

Why stop there? Still following the guideline of most specific tests first, why don’t we insert ACEs that will allow EIGRP and OSPF from 192.168.99.129/32, per the example in the section “Using ACLs to Filter Network Services,” in this chapter (we would put RIP in there too, but we’ve run out of room if we want to insert it ahead of ACE 10!):

CiscoISR(config-ext-nacl)#8 permit eigrp host 192.168.99.129 any CiscoISR(config-ext-nacl)#9 permit ospf host 192.168.99.129 any

Verify ACL 101:

CiscoISR(config-ext-nacl) #do show access- list 1 01
Extended IP access list 101
1 deny ip 0.0.0.0 0.255.255.255 any (50 matches)
2 deny ip 10.0.0.0 0.255.255.255 any
3 deny ip 127.0.0.0 0.255.255.255 any
4 deny ip 172.16.0.0 0.15.255.255 any
5 deny ip 192.168.0.0 0.0.255.255 any
6 deny ip 224.0.0.0 15.255.255.255 any (99937 matches)
7 deny ip host 255.255.255.255 any
8 permit eigrp host 192.168.99.129 any (2232 matches)
9 permit ospf host 192.168.99.129 any (156 matches)
10 permit tcp any 10.10.10.0 0.0.0.255 eq www (11345 matches)
20 permit tcp any 10.10.10.0 0.0.0.255 eq 22
CiscoISR(config-ext-nacl)#

Outbound IP Address Spoofing

Generally speaking, the source address in IP packets that are leaving your network should belong to your address space, whether the addresses are RFC 1918 addresses or publicly routable. In this example, we create an ACL named nospoof-out and apply it to the Vlan1 interface (default LAN interface on a Cisco 800 series ISR) in the inbound direction. Figure 5.13 illustrates the effects of the cumulative example we have been working on.

Figure 5.13 illustrates the net, cumulative effect of all the previous ACL examples.

CiscoISR(config) #ip access- list extended no- spoof- out
CiscoISR(config-ext-nacl) #permit ip 1 0. 1 0. 1 0. 0 0. 0. 0. 255 any
CiscoISR(config-ext-nacl) #exit
CiscoISR(config) #interface Vlan 1
CiscoISR(config-if) #ip access- group no- spoof- out in
CiscoISR(config-if) #

Using ACLs to Filter Other Common Services

If ACLs were only as straightforward in practice as our examples are so far! Chances are good that there are other services that will need to be allowed through the static packet-filtering firewall. For example, if your security policy allows it, you may need to be able to ping (that is, ICMP echo request) devices on the inside of your network in the DMZ from the outside for network management reasons. Speaking of network management, you may have some devices that need to be managed by SNMP. In the example that we have been working on, neither ICMP nor SNMP are allowed through the firewall because they are being denied by the implicit rules. Not only do you have to allow these protocols inbound, but their replies need to be allowed outbound. You have to ensure that existing ACLs will allow these responses.

ICMP
We could create an ACE in ACL 101 that would allow all ICMP inbound, but do we really want to do this? Our security policy dictates which protocols are required for business reasons. Because in the last chapter we agreed that ICMP (and other services) can be used for reconnaissance and DoS attacks, it makes good sense to only allow specific messages through the firewall. In this example, we would want to allow ICMP echoes through the firewall to the DMZ and allow the replies back out. Certainly this will allow an attacker to determine live IP hosts in the DMZ, and also engineer an ICMP flood. If we don’t allow other ICMP commands through (such as ICMP redirects, which can be used for certain exploits), then this may be a reasonable tradeoff.

The following CLI command adds a rule that will allow ICMP echoes from any IP address to 10.0.0.0/8. Note the use of the inverse mask, 0.0.0.255, being the
inverse of 255.0.0.0:

CiscoISR(config)#access-list 101 permit icmp any 10.10.10.0 0.0.0.255 echo

Because we didn’t insert this command with a sequence number, it will be added to the end of the existing ACL 101 before the implicit deny.

Here’s a list of some useful ICMP messages you may want to filter:

• Echo. Allows pinging to IP hosts.
• Echo-reply. Replies to pinging.
• Unreachable. Reply indicating that a host cannot be reached.
• Redirect. Command to alter a routing table.
• parameter-problem. Invalid/problem packet header.
• Packet-too-big. Required for Maximum Transmission Unit (MTU) path discovery.
• Source-quench. Throttles traffic as necessary.

Filtering Other Miscellaneous Services
The CLI and the Cisco SDM have built-in keywords for the following common and router service traffic:
Common Services. domain, smtp, ftp.

• Router Service Traffic. telnet, syslog, snmptrap.

• CCNA Security Study Notes