Chapter 9: Internet Architecture 159 Firewall Rule Set Design Good rule set design can be as important to a firewall as good hardware. Most firewalls work on “first match” when deciding whether to accept or reject a packet. When design - ing a rule set, the “first match” algorithm dictates that the most specific rules be placed at the top of the rule set and the least specific or most general rules be placed at the bottom. This placement guarantees that more general rules do not mask the more specific rules. NOTE: Some firewalls provide a rule set processor that examines the rule set for rules that are masked by other rules. The processor then flags this condition for the firewall administrator before in - stalling the rules on the firewall. While this is a good general guideline, it does not address the performance issue of the firewall. The more rules that must be examined for each packet, the more processing must be done by the firewall. Good rule set design must take this into account to make the firewall more efficient. To do this, look at the expected traffic load of the firewall and rank the traffic types in order. Generally, HTTP traffic will be the largest. To make the firewall more efficient, place the rules pertaining to HTTP at the top of the rule set. In most cases, this means that the rule allowing internal systems to use HTTP to any system on the Internet and the rule allowing external users to access the organization’s Web site should be very near the top of the rule set. The only rules that should be above them will be specific deny rules per- taining to HTTP. NETWORK ADDRESS TRANSLATION At first glance, IP addressing does not seem like a topic for a security book. The address - ing of systems is clearly a network administration issue, of course. Well, not quite. Any organization that plans to install a firewall will have to deal with addressing issues. In fact, addressing that is not well thought out and configured properly can cause many headaches. At the root of the problem is the shortage of IP address space. The familiar 32-bit addresses in the dot notation (xxx.yyy.zzz.aaa) are simply being used up. Because of this, ISPs are reluctant to give out large blocks of addresses to their customers. Most ISPs will provide blocks of 16 or 32 addresses (which actually become 14 or 30 addresses when the broadcast addresses are taken into account). Thirty addresses are not enough for a small organization, never mind a medium or large organization. Most organizations have more than 30 systems. So what do you do? The solution is called network address translation (NAT). What Is Network Address Translation? NAT is just what it sounds like—it translates one or more addresses into other ad - dresses. So how does this help? When we build our networks we use the 30 or so ad - dresses provided by the ISP for systems that must be visible to the Internet. On the inside of the network, we use addresses that are not visible but are translated or NATed for communication to the Internet. In most networks, the firewall performs the NAT function. Routers can also be used for this function if necessary. Application layer firewalls perform NAT as part of their de - sign. Since all connections terminate on the firewall, only the firewall’s address is visible to the outside. Packet filtering firewalls also have this capability but it must be configured during firewall setup. NAT can also provide a security function as the hidden addresses of the internal systems are not visible to the Internet. If the system is not visible, it cannot be addressed and targeted. NOTE: NAT does not provide complete protection from attack and should not be relied upon at the expense of other security measures. If the attacker is within the organization or has direct access to the internal network via a VPN or dial-up connection, for example, NAT is no protection at all. Private Class Addresses So we have this concept of NAT but we still need addresses for the internal network. The choice of internal addresses can cause all types of routing problems if it is not done prop- erly. RFC (that is, Request for Comment, which is how Internet standards are published) 1918 specifies what are called private class addresses. These addresses are intended for use on internal networks behind a firewall that performs NAT. The RFC specifies the following addresses as private class addresses: ▼ 10.0.0.0 – 10.255.255.255 (10.0.0.0 with an 8-bit mask) ■ 172.16.0.0 – 172.31.255.255 (172.16.0.0 with a 12-bit mask) ▲ 192.168.0.0 – 192.168.255.255 (192.168.0.0 with a 16-bit mask) The use of these addresses provides an organization with a lot of flexibility in design - ing its internal addressing scheme. Any of these addresses can be used in any combina - tion within the organization’s internal network. There are no limitations on this. None of these addresses are routable on the Internet. If you attempt to ping to a pri - vate class address, the packets will be returned with a “network unreachable” message. NOTE: Some ISPs use private class addresses on their internal network. There may be some places where a ping response is received to a private class address in this case. If the ISP is using the private class addresses internally, routes to these networks should not be broadcast and thus will not affect an organization’s use of these addresses. 160 Network Security: A Beginner’s Guide TEAMFLY Team-Fly ® Static NAT We architect a network to use private class addresses and we want to use NAT to allow systems to be accessible from the Internet. For this situation, we use what is called static NAT. Static NAT maps a single real address from the organization’s external network to a system on the DMZ. Figure 9-14 shows how this translation works. NOTE: You could map the address to a system on the internal network but the system is then acces - sible from the outside and such systems should be in the DMZ. An obvious question that arises is why bother with NAT? You could just assign real addresses to the DMZ and be done with it. While this is true, there are two issues that come up. First, you would need a second set of addresses to do this or you will need to further subnet the 30 addresses that the ISP is providing. If you wish to place some sys - tems on a second DMZ, yet another set of addresses will be required. Second, not all systems on the DMZ may need real addresses. If you look back to Figure 9-8, you will see an application server on the DMZ. This application server does not require access from the Internet. It is there to process information received by the Web server and to interact with the internal database server. Static NAT is a one-to-one configuration. For each system that must be accessible from the Internet, one real address is used. Static NAT is appropriate for servers in a DMZ but it is not appropriate for desktop client systems. Chapter 9: Internet Architecture 161 Figure 9-14. Static network address translation Dynamic NAT Dynamic NAT differs from static NAT in that many internal addresses are mapped to a single real address (see Figure 9-15) instead of using a one-to-one mapping. Typically, the real address that is used is the external address of the firewall. The firewall then tracks the connections and uses one port for each connection. This creates a practical limit of about 64,000 simultaneous dynamic NAT connections. Keep in mind that a single internal desk - top system may open as many as 32 simultaneous connections when accessing a Web site. Dynamic NAT is especially useful for desktop clients who use Dynamic Host Config - uration Protocol (DHCP). Since systems using DHCP are not guaranteed the same IP ad - dress when the system boots, static NAT will not work. Systems that use dynamic NAT are not addressable from the outside since only the firewall maintains the mappings of ports to systems and the mappings will change regularly. 162 Network Security: A Beginner’s Guide Figure 9-15. Dynamic network address translation PARTNER NETWORKS The design concepts that have been discussed for Internet architectures can also be used when designing networks with partners. Connectivity between organizations has in - creased dramatically as organizations have discovered that it can reduce costs. Use of Partner Networks Partner networks are generally established to exchange certain files or pieces of data be - tween organizations. This translates into a requirement for particular systems within one or - ganization to communicate with particular systems in the other organization. It does not mean that one organization requires unrestricted access to the other organization’s network. If you apply a risk-management approach to a partner network, you’ll see that a risk exists if the two organizations are connected. By connecting the networks of the two orga - nizations, access is now available to the other organization’s employees. Also, remember that two of the agents of threat discussed in Chapter 6 were business customers and sup - pliers. Clearly, some control must be put in place to manage this risk. Setup The security requirements for the partner network differ little from the requirements of an Internet connection. Thus, we can use the same architectures and methodologies. The services necessary for the connection are identified and the systems that provide these services are placed in a DMZ. This is not the same DMZ that is used for the Internet connection, although it may reside off the Internet firewall if sufficient resources are available (see Figure 9-16). When you look at the figure, notice that the firewall added two interfaces: one to the partner DMZ and one to the partner network. Additional rules must be added to the firewall to allow systems at the partner organi - zation as well as internal systems to access the partner DMZ systems. However, there should be no rules that allow systems in the partner organization to connect to the inter - nal network, to the Internet DMZ, or to the Internet. In many firewalls this may require explicit denies. Table 9-5 shows how the rules will change. As you can see from Table 9-5, there are rules at the top of the list that specifically deny access to and from the partner organization’s networks. Since most firewalls work on the first rule that matches, specific deny rules must be placed prior to the global accept rules such as rules 5, 6, 7, 8, and 9. Addressing Issues There is one other issue when dealing with partner networks and that is addressing. Most organizations use private class addresses for internal networks. Because of this you’re very likely to run into a partner using the same addresses as your organization. Organizations that do not pay attention to this problem may end up defining the entire 10.x.x.x network as Chapter 9: Internet Architecture 163 164 Network Security: A Beginner’s Guide belonging to a particular partner only to find out that another partner organization also uses 10.x.x.x. To alleviate this issue, it is good practice to use NAT when connecting to partner net - works. By defining a translation policy for the partner network, you can allow their net - work to become part of your addressing scheme. Figure 9-16. Partner DMZ using the Internet firewall NOTE: The discussion in this section is only intended to bring this issue to your attention. Addressing and the correct routing of interconnected networks is a book-length topic all to itself. Care must be taken when building interconnected networks so that traffic flows in the correct manner and so that ad - ditional security issues are not introduced. Chapter 9: Internet Architecture 165 Rule Number Source IP Destination IP Service Action 1 Partner network Partner DMZ Appropriate for partnership Accept 2 Partner network Any Any Deny 3 Partner DMZ Partner network Appropriate for partnership Accept 4 Any Partner network Any Deny 5 Any Web server HTTP Accept 6 Any Mail server SMTP Accept 7 Mail server Any SMTP Accept 8 Internal network Any HTTP, HTTPS, FTP, Telnet, SSH Accept 9 Internal DNS Any DNS Accept 10 Any Any Any Drop Table 9-5. Rules for Internet Firewall with Partner Network Access This page intentionally left blank. . Service Action 1 Partner network Partner DMZ Appropriate for partnership Accept 2 Partner network Any Any Deny 3 Partner DMZ Partner network Appropriate for partnership Accept 4 Any Partner network. Guide belonging to a particular partner only to find out that another partner organization also uses 10.x.x.x. To alleviate this issue, it is good practice to use NAT when connecting to partner net - works to the partner DMZ and one to the partner network. Additional rules must be added to the firewall to allow systems at the partner organi - zation as well as internal systems to access the partner