An expanded example of packet filtering

Let's look at a more complex example of packet filtering. For this example, I use the configuration shown in Figure 3.13.

Figure 3.13. A screened subnet firewall

This configuration is known as a screened subnet firewall. The goal of this architecture is to allow the hosts in Organization X to access and provide Internet services without directly exposing those hosts to attack. The hosts that we want to protect strongly are connected to Ethernet 1 in networks 192.168.32.0/24 through 192.168.39.0/24. The Internet is connected to

Hosts in networks 192.168.32.0/24 through 192.168.39.0/24 do not access the Internet directly. All contact with the Internet is proxied through hosts in network 192.168.30.0/24. The combination of protecting a set of hosts while proxying all Internet access through another subnet makes packet filtering in the screened subnet firewall more complex.

Let's see how proxy access works, and how it affects packet filtering. Hosts in networks 192.168.32.0/24 through 192.168.39.0/24 access web servers outside the Organization X through the proxy server. Web requests are sent to the proxy on TCP port 911, which gets the requested web pages and sends them back to the requestor. Incoming and outgoing electronic mail is relayed through a mail relay. Mail destined for inside Organization X is sent to the mail relay, which forwards it to Organization X's internal mail servers. Mail from Organization X to the Internet is sent first to the mail relay, which then forwards it on to its final destination. Network services that Organization X provides the Internet, like web and name services, are offered through dedicated web and name servers. Hosts in network 192.168.30.0/24 on do not have full access to Organization X's networks 192.168.32.0/24 through 192.168.39.0/24. They are given only enough access to the internal networks to carry out their proxy functions.

The network 192.168.30.0/24 is called a DMZ, for De-Militarized Zone. The rationale behind this design is that hosts we want to protect must not have direct Internet access. All Internet access is done through hosts in the DMZ, which protects the internal hosts from direct attack. When a significant security weakness in hosts or software is found, Organization X can concentrate first on fixing the weakness in DMZ systems (which typically have far fewer systems). Once the DMZ systems are hardened against the security weakness, crackers on the Internet cannot exploit the weakness against Organization X. If a DMZ system is compromised, access into Organization X's internal networks is controlled. An additional benefit is that Organization X has a central location for tracking its Internet use because all Internet access is proxied through DMZ systems.

In addition to the goals of the screened subnet architecture, let's make other policy decisions that will affect how we define the extended access lists. Internet hosts 192.168.10.4 and 192.168.12.5 will be DNS secondaries for Organization X's domains. This means that these two hosts, existing somewhere out on the Internet, will also provide DNS queries for Organization X's domain. To make that possible, they must be able to copy all of the DNS data about Organization X from the name server on the DMZ, a process known as a zone transfer, so our access lists need to permit zone transfers by only those two nodes. Another policy decision is that Organization X will give relatively small answers to DNS queries. As you may recall, a DNS client that receives a large answer to a DNS query starts a TCP connection to get all of the answer. Keeping DNS answers small eliminates the need for allowing all Internet hosts TCP port 53 connectivity into its name server and speeds response time to queries, since fewer packets are sent for each answer, and no TCP connection is needed. Note that Organization X must implement this policy by being disciplined about the DNS resource records that it creates. In most cases, there is no reason to have extremely large DNS resource records. An exception is for large web sites that do load balancing to large numbers of servers with DNS round robin, a technique that assigns a number of IP addresses to the hostname of a web server.

What about routing? We know exactly which networks are connected to which interface. Network 192.168.30.0/24 is on Ethernet 0, networks 192.168.32.0/24 through 192.168.39.0 are on Ethernet 1, and everything else on the Internet is reached through serial 2. It is easy to

use static, hardcoded routes on the router, so for this example, we won't use dynamic routing protocols. In firewall designs, you should avoid using dynamic routing protocols as much as possible, since they add complexity to access lists, and routing updates can also be spoofed. I'll talk about this in more detail in Chapter 4.

With all the information we have gathered about policy and the screened subnet architecture, let's define how IP packets should flow through Organization X's router:

Deny packets from the Internet that have a source address within an organization (prevent spoofing)

All hosts on the screened subnet can be pinged from all networks

DNS queries should be permitted from the name server to the Internet and vice versa

Internet hosts 192.168.10.4 and 192.168.12.5 should be able to do DNS zone transfers from name server

Web access is permitted to the web server from all networks

FTP, Telnet, and web access out to the Internet is permitted from the proxy server

FTP, Telnet, and web proxy access on TCP port 911 from the internal networks is permitted to the proxy server

The mail relay has SMTP access to all networks and can receive SMTP connections from all networks

No direct connectivity is permitted between the Internet and the internal networks

3.2.12.1 Defining what access lists are necessary

The first policy entry states that packets from the Internet with the organization's address as the source IP address are denied entry. This policy rule is designed to stop source IP address spoofing, and as I mentioned in a previous section, inbound access lists are the network administrator's tools for spoof protection. Access list 100, shown below, implements the anti- spoof policy:

access-list 100 deny ip 192.168.30.0 0.0.0.255 any access-list 100 deny ip 192.168.32.0 0.0.7.255 any access-list 100 permit ip any any

Organization A uses networks 192.168.30.0/24 in its DMZ and networks 192.168.32.0/24 through 192.168.39.0/24 in the core of its network. The first entry in access list 100 denies packets from the Internet that have source addresses of the DMZ network 192.168.30.0/24. The next line denies packets from internal networks 192.168.32.0/24 through 192.168.39.0/24. We can express this in a single statement by using a network mask. After

will be used to do the rest of the filtering). Access list 100 is applied as an inbound access list to the interface facing the Internet:

interface serial 2 access-group 100 in

Are there any other interfaces that require inbound access lists? Any system that exchanges packets directly to the Internet is a possible point of compromise. What if a DMZ system, which does exchange packets directly with the Internet, were compromised by crackers? That system could be used as a base for launching attacks against other Internet sites or against the internal networks. To prevent a DMZ from potentially being used for spoofing attacks, we can create access list 101 that permits only DMZ packets from that segment:

access-list 101 permit ip 192.168.30.0 0.0.0.255 any

The implicit deny of access list 101 stops spoofed packets. This access list is applied to interface Ethernet with:

interface Ethernet 0 access-group 101 in

You might question whether we need to put an incoming access list on Ethernet 1 to prevent spoofing attacks from Organization X's employees. Since we are going to prevent the internal networks from talking directly to the Internet, it may not seem necessary. But attacks by disgruntled insiders are a real threat. Hosts on the internal network could potentially spoof packets with addresses from the DMZ in order to get them out onto the Internet. To take care of spoofing attacks on the DMZ and stop accidental traffic, we can build another very simple inbound access list 102:

access-list 102 permit ip 192.168.32.0 0.0.7.255 any

which allows packets from the internal networks only into the router. This is then applied with:

interface Ethernet 1 access-group 102 in

Although we made a decision not to use dynamic routing protocols, the way that I have used inbound access lists for anti-spoofing purposes in this example allows us to use dynamic routing protocols on the serial interface without changing our access lists. In other words, as long as the IP addresses on both ends of the serial link do not use the internal IP addresses or DMZ addresses, the router allows routing updates into the serial interface. Similarly, as long as the routers off Ethernet 1 use internal IP addresses, route updates are permitted on that interface. Using inbound access lists for anti-spoofing purposes gives us this flexibility.

Now that we are done with the inbound access lists, we need to work on the outbound access lists. Since we have policies applying to networks attached to all three interfaces of the router, let's define outgoing access list numbers as follows:

• 103—Outgoing access list on interface serial 2 (to the Internet)

• 105—Outgoing access list on Ethernet 1 (to internal networks)

With access list numbers defined, we can start creating access lists entries for each of the packet-forwarding rules:

Deny packets from the Internet that have a source address within an organization (prevent spoofing)

We handled this policy with our inbound access lists. All hosts on the screened subnet can be pinged from all networks

To implement this policy statement, we need to allow ICMPecho-reply packets out to the Internet and internal user networks. For the outgoing serial interface access list, we have:

access-list 103 permit icmp 192.168.30.0 0.0.0.255 any echo-reply We need the same leading into the internal segments:

access-list 105 permit icmp 192.168.30.0 0.0.0.255 192.168.32.0 0.0.7.255 echo-reply

The DMZ segment itself needs to receive ICMP echo requests:

access-list 104 permit icmp any 192.168.30.0 0.0.0.255 echo DNS queries should be permitted to and from the name server

We need to allow DNS packets in and out of the DMZ segment for DNS queries. As I mentioned in our web server example, DNS queries come into a name server with a UDP destination port of 53 and a source port of either 53 or greater than 1023. Large queries use TCP on destination port 53. With this information, we generate the following access lists:

! access list out to the Internet (serial 2)

access-list 103 permit udp host 192.168.30.3 eq domain any eq domain access-list 103 permit udp host 192.168.30.3 gt 1023 any eq domain access-list 103 permit udp host 192.168.30.3 eq domain any gt 1023 access-list 103 permit tcp host 192.168.30.3 any eq domain

! access list out to the DMZ (Ethernet 0)

access-list 104 permit tcp any host 192.168.30.3 established

access-list 104 permit udp any eq domain host 192.168.30.3 eq domain access-list 104 permit udp any eq domain host 192.168.30.3 gt 1023 access-list 104 permit udp any gt 1023 host 192.168.30.3 eq domain The name server at IP address 192.168.30.3 can send any DNS query out to the Internet because the first line and second lines of access list 103 permit UDP packets with a destination port of 53 and a source port of 53 or greater than 1023. Should the name server require TCP to get a large DNS answer, the fourth line of access list 103 permits that type of connection. The first line of access list 104 allows return packets from that TCP connection, and the second and third lines of access list 104 permit responses to the name server's queries to go back to the name server.

The name server also needs to answer queries from the Internet The second and third lines of access list 104 permit the name server to receive any DNS query. The first and third lines of access list 103 permit responses to DNS queries. Since we explicitly decided that all DNS answers about Organization X would be small, connection to TCP port 53 is not allowed.

Internet hosts 192.168.10.4 and 192.168.12.5 should be able to do DNS zone transfers from name servers

We implement this policy statement by first setting up an established TCP access list entry on the outgoing serial interface to the Internet:

access-list 103 permit tcp host 192.168.30.0 0.0.0.255 any established

We make it generic to all of the DMZ so we can also catch all TCP connections going out of the DMZ that have already been set up. Hosts 192.168.10.4 and 192.168.12.5 are permitted to do zone transfers from the name server. Zone transfers use TCP port 53. So in the access list going to the DMZ, we have:

access-list 104 permit tcp host 192.168.10.4 host 192.168.30.3 eq domain

access-list 104 permit tcp host 192.168.12.5 host 192.168.30.3 eq domain

Since both zone transfers and DNS queries with large answers use TCP port 53, we'll have to require all DNS answers from those name servers small enough to not require a TCP connection. Otherwise, there would be no way to allow zone transfers from only the designated secondary DNS servers as we would have had to allow TCP port 53 to be open to all on the Internet.

Web access is permitted to the web server from all networks

We need to allow web protocols to have access on port 80 into the web server at 192.168.30.2. This is done with:

access-list 104 permit tcp any host 192.168.30.2 eq www

Return packets to the Internet are covered by the established access list entry in list 103. We need a similar entry going into the internal networks (list 105):

access-list 105 permit tcp 192.168.30.0 0.0.0.255 192.168.32.0 0.0.7.255 established

FTP, Telnet, and web access out to the Internet is permitted from the proxy server

We add an established statement to list 104 to handle return traffic on a connection set up from the proxy server to the Internet. Since the other servers on the DMZ will be making and receiving connections to the Internet too, it is safe to make the established connection apply to the rest of the DMZ:

access-list 104 permit tcp any host 192.168.30.0 0.0.0.255 established

Since web servers can live on a number of ports, we need to add generic TCP access going out to the Internet from the proxy server:

access-list 103 permit tcp host 192.168.30.1 any

To make FTP work, we need TCP ports greater than 1023 going to the proxy server from source port 20:

access-list 104 permit tcp any eq ftp-data host 192.168.30.1 gt 1023 FTP, Telnet, and web access from the internal networks is permitted to the proxy server

This is similar to the previous policy statement, but we can be much more specific about what networks can talk to the proxy server:

access-list 105 permit tcp host 192.168.30.1 eq ftp-data 192.168.32.0 0.0.7.255 gt 1023

We need to permit the proxied services of FTP, Telnet, and Web into the proxy server from the internal segments:

access-list 104 permit tcp 192.168.32.0 0.0.7.255 host 192.168.30.1 range ftp-data ftp

access-list 104 permit tcp 192.168.32.0 0.0.7.255 host 192.168.30.1 eq telnet

access-list 104 permit tcp 192.168.32.0 0.0.7.255 host 192.168.30.1 eq 911

The mail relay has SMTP access to all networks and can receive SMTP connections from all networks

SMTP uses port 25 as a destination port. We already have established statements, so we need the following statements:

access-list 103 permit tcp host 192.168.30.4 any eq smtp access-list 104 permit tcp any host 192.168.30.4 eq smtp

access-list 105 permit tcp host 192.168.30.4 192.168.32.0 0.0.7.255 eq smtp

No direct connectivity is permitted between the Internet and the internal networks

This is taken care of by the explicit permit entries and implicit deny entry at the end of the access lists.

3.2.12.2 Optimizing the order of access list entries

We now have a large collection of access list entries. What is the best way to arrange them? You want to have the most frequently used access list entry at the top, followed by the next most frequently used entry, and so on. As mentioned earlier, doing this minimizes the impact that access lists have on a router. The most frequently used access list entry in environments that use TCP-based services such as HTTP, SMTP, and FTP is the established entry. It is almost always a good idea to put a very general established entry at the top of a list because the vast majority of traffic will match the first line of an access list and the router will not have to process other access list entries. Next, you typically want to use DNS statements since most Internet services use hostnames and not just IP addresses, thus requiring a DNS lookup.

ping is used frequently on the Internet. Finally, the other permit entries for TCP services and other services should be covered. Bear in mind, these are general guidelines, and utilization of access list entries may be different, depending on your needs and traffic patterns. Whatever order you choose, be careful about moving deny entries in an access list or permit statements ahead of deny entries. This kind of movement in particular can completely change the policy you are trying to implement, denying entries you did not intend to deny or permitting services you did.

In this case, the final version of access list 103, the outbound access list going to the Internet, becomes:

! access list out to Internet through serial interface 0

access-list 103 permit tcp host 192.168.30.0 0.0.0.255 any established access-list 103 permit udp host 192.168.30.3 eq domain any eq domain access-list 103 permit udp host 192.168.30.3 gt 1023 any eq domain access-list 103 permit udp host 192.168.30.3 eq domain any gt 1023 access-list 103 permit tcp host 192.168.30.3 any eq domain

access-list 103 permit icmp 192.168.30.0 0.0.0.255 any echo-reply access-list 103 permit tcp host 192.168.30.1 any

access-list 103 permit tcp 192.168.32.0 0.0.7.255 host 192.168.30.1 access-list 103 permit tcp host 192.168.30.4 any eq smtp

while access list 104, the access list leading to the DMZ segment, is as follows: ! access list out to DMZ through Ethernet interface 0

access-list 104 permit tcp any 192.168.30.0 0.0.0.255 established access-list 104 permit udp any eq domain host 192.168.30.3 eq domain access-list 104 permit udp any eq domain host 192.168.30.3 gt 1023 access-list 104 permit udp any gt 1023 host 192.168.30.3 eq domain access-list 104 permit icmp any 192.168.30.0 0.0.0.255 echo

access-list 104 permit tcp any host 192.168.30.2 eq www

access-list 104 permit tcp 192.168.32.0 0.0.7.255 host 192.168.30.1 range ftp-data ftp

access-list 104 permit tcp 192.168.32.0 0.0.7.255 host 192.168.30.1 eq telnet

access-list 104 permit tcp 192.168.32.0 0.0.7.255 host 192.168.30.1 eq 911 access-list 104 permit tcp any eq ftp-data host 192.168.30.1 gt 1023

access-list 104 permit tcp any host 192.168.30.4 eq smtp

access-list 104 permit tcp host 192.168.10.4 host 192.168.30.3 eq domain access-list 104 permit tcp host 192.168.12.5 host 192.168.30.5 eq domain (I have moved the entries that permit zone transfers toward the end since the zone transfer