Dual firewalls do increase the cost of the architecture and require additional manage - ment and configuration. FIREWALLS Firewalls have been mentioned a fair amount in the proceeding sections of this chapter (and have been mentioned in various other chapters as well). A firewall is a network ac - cess control device that is designed to deny all traffic except that which is explicitly al - lowed. This definition contrasts with a router, which is a network device that is intended to route traffic as fast as possible. Some will argue that a router can be a firewall. I will agree that a router can perform some of the functions of a firewall but one key difference remains: A router is intended to route all traffic as fast as possible, not to deny traffic. Perhaps a better way to differen - tiate a router and a firewall is to say that a firewall is a security device that can allow ap - propriate traffic to flow while a router is a network device that can be configured to deny certain traffic. In addition to this, firewalls generally provide a more granular level of configuration. Firewalls can be configured to allow traffic based on the service, the IP address of the source or destination, or the ID of the user requesting service. Firewalls can also be con- figured to log all traffic. Firewalls can perform a centralized security management func- tion. In one configuration, the security administrator can define allowed traffic to all systems within an organization from the outside. While this does not alleviate the need to properly patch and configure systems, it does remove some of the risk that one or more systems may be misconfigured and thus open to attack on an inappropriate service. 152 Network Security: A Beginner’s Guide Sensitive Internal Networks Firewalls should not be limited to use only on Internet connections. A firewall is a network access control device that can be used anywhere that access must be con - trolled. This includes internal networks that should be protected from other internal systems. Sensitive internal networks may include systems with extremely impor - tant information or functions or networks that conduct experiments on network equipment. A good example of a sensitive network can be found in banks. Every evening banks communicate with the Federal Reserve System to transfer funds. A failure here can cost the bank large sums of money. The systems that control this communi - cation are very sensitive and important to the bank. A firewall could be installed to restrict access to these systems from other parts of the bank. Types of Firewalls There are two general types of firewalls: application layer firewalls and packet filtering firewalls. The two types start with differing philosophies but with proper configuration both types can perform the required security functions of blocking inappropriate traffic. As we will see in the following sections, the way the two types are implemented does im - pact how the security policy is enforced. Application Layer Firewalls Application layer firewalls (also called proxy firewalls) are software packages that sit on top of general-purpose operating systems (such as Windows NT or Unix) or on firewall ap - pliances. The firewall will have multiple interfaces, one for each network to which it is connected. A set of policy rules defines how traffic from one network is transported to any other. If a rule does not specifically allow the traffic to flow, the firewall will deny or drop the packets. Policy rules are enforced through the use of proxies. On an application layer firewall, each protocol to be allowed must have its own proxy. The best proxies are those that are built specifically for the protocol to be allowed. For instance, an FTP proxy understands the FTP protocol and can determine if the traffic that is flowing is following the protocol and is allowed by the policy rules. With an application layer firewall, all connections terminate on the firewall (see Fig- ure 9-12). As you can see from the figure, a connection starts on the client system and goes to the internal interface of the firewall. The firewall accepts the connection, analyzes the contents of the packet and the protocol to be used, and determines if the policy rules al- low the traffic. If so, the firewall initiates a new connection from its external interface to the server system. Chapter 9: Internet Architecture 153 Figure 9-12. Application layer firewall proxy connections Application layer firewalls also use proxies for inbound connections. The proxy on the firewall will receive the inbound connection and process the commands before the traffic is sent to the destination system. In this way, the firewall can protect systems from some application layer attacks. NOTE: This assumes that the proxy on the firewall is itself not vulnerable to the attack. If the proxy on the firewall is not well written, this may not be the case. Application layer firewalls will have proxies for the most commonly used protocols such as HTTP, SMTP, FTP, and telnet. Other proxies may not be available. If a proxy is not available, the protocol cannot be used across the firewall. The firewall also hides the addresses of systems behind the application layer firewall. Since all connections originate and terminate on the firewall’s interfaces, internal systems are not directly visible to the outside and thus the internal addressing scheme can be hidden. Packet Filtering Firewalls Packet filtering firewalls may also be software packages that sit on top of general- purpose operating systems (such as Windows NT or Unix) or on firewall appliances. The firewall will have multiple interfaces, one for each network to which it is connected. And also like the application layer firewall, a set of policy rules define how traffic from one network is transported to any other. If a rule does not specifically allow the traffic to flow, the firewall will deny or drop the packets. Policy rules are enforced through the use of packet inspection filters. The filters exam- ine the packets and determine whether the traffic is allowed based on the policy rules and the state of the protocol. If the protocol is running over TCP, state determination is rela- tively easy as TCP itself maintains state. If the protocol is running over UDP, the packet filtering firewall cannot use the inher - ent state of the protocol but must track the state of the UDP traffic. Normally, the firewall will see an outbound UDP packet and expect an inbound packet from the destination ad - dress and port of the original packet within a certain time frame. If the packet arrives within the time frame, the packet is accepted. If not, the firewall determines that the UDP traffic is not a response to a request and drops it. With a packet filtering firewall, connections do not terminate on the firewall (see Fig - ure 9-13) but instead travel directly to the destination system. As the packets arrive at the firewall, the firewall will determine if the packet and connection state are allowed by the policy rules. If so, the packet is sent on its way. If not, the packet is denied or dropped. Packet filtering firewalls do not rely on proxies for each protocol and thus can be used with any protocol that runs over IP. As a general rule, they are also capable of handling a greater amount of traffic as they do not have the overhead of extra connection setups and the processing that goes with the proxy software. 154 Network Security: A Beginner’s Guide NOTE: I said “as a general rule” in the last paragraph. Different firewall vendors will compare the per- formance of their firewalls in different ways. Historically, packet filtering firewalls have been able to pro- cess a greater amount of traffic than the application layer firewalls on the same type of platform. This comparison may vary depending on the type of traffic and the number of connections during the test. Strict packet filtering firewalls do not use proxies and thus traffic from a client is sent directly to the server. If an attack is launched against the server on an open service that is allowed by the firewall policy rules, the firewall will not interfere with the attack. Packet filtering firewalls may also allow the internal addressing scheme to be seen from the out - side. Internal addresses do not need to be hidden since the connections do not terminate on the firewall. Hybrids As with many things, firewalls evolved over time. Manufacturers of application layer firewalls realized that they needed some way of handling protocols for which specific proxies did not exist. Thus was born the generic services proxy (GSP). The GSP was cre - ated to allow application layer proxies to handle other protocols needed by security and network administrators. In reality, what the GSP did was to create a way for application layer firewalls to act like packet filtering firewalls. The manufacturers of packet filtering firewalls also added some proxies to their prod - ucts to allow for greater security for some well-known protocols. Many packet filtering firewalls now come with an SMTP proxy, for example. Chapter 9: Internet Architecture 155 Figure 9-13. Traffic through a packet filtering firewall 156 Network Security: A Beginner’s Guide While both types of firewalls still have the basic functionality of the original design (and thus most of the basic weaknesses as well), we now have many hybrid firewalls on the market. It is almost impossible to find a pure application layer or pure packet filtering firewall. This is not a bad turn of events as it allows security administrators to tailor the solution to their particular circumstances. Firewall Configurations Now let’s take a look back at the DMZ architectures that we have covered earlier in the chapter and see how a firewall would be configured specifically for those situations. For this exercise, we will assume that the following systems exist in the DMZ: ▼ Web server offering service on port 80 only. ▲ Mail server offering service on port 25 only. This system accepts all inbound mail and sends all outbound mail. The internal mail server contacts this system periodically to get inbound mail and send outbound mail. There is an internal DNS system that must query Internet systems to resolve names to addresses but the organization does not host its own primary external DNS. The Internet policy for the organization allows internal users to use the following services: ▼ HTTP ■ HTTPS ■ FTP ■ Telnet ▲ SSH Based on this policy, we can construct policy rules for each of the DMZ architectures. Router and Firewall The router and firewall architecture was shown earlier in Figure 9-9. Table 9-1 provides the rules for the firewall. Filtering can be placed on the router to only allow HTTP from the outside to the Web server and SMTP from the outside to the mail server. Single Firewall The single-firewall architecture was shown earlier in Figure 9-10. Table 9-2 provides the rules for the firewall. As you can see from Table 9-2, the rules are very similar to those for the router and firewall architecture. The firewall adds rules that were handled by the router in the previous Chapter 9: Internet Architecture 157 ous architecture. You can also see that there is no explicit rule that allows the internal mail server to connect to the mail server in the DMZ. This is because of rule #2, which allows any system (internal or external) to connect to that system. Dual Firewalls The dual-firewall architecture was shown earlier in Figure 9-11. Table 9-3 provides the rules for firewall #1. Rule Number Source IP Destination IP Service Action 1 Internal mail server Mail server SMTP Accept 2 Internal network Any HTTP, HTTPS, FTP, Telnet, SSH Accept 3 Internal DNS Any DNS Accept 4 Any Any Any Drop Table 9-1. Firewall Rules for the Router and Firewall Architecture Rule Number Source IP Destination IP Service Action 1 Any Web server HTTP Accept 2 Any Mail server SMTP Accept 3 Mail server Any SMTP Accept 4 Internal network Any HTTP, HTTPS, FTP, Telnet, SSH Accept 5 Internal DNS Any DNS Accept 6 Any Any Any Drop Table 9-2. Firewall Rules for the Single-Firewall Architecture As you can see from Table 9-3, the rules are the same as those of the firewall in the single-firewall architecture. However, there is a second firewall. The rules for firewall #2 can be found in Table 9-4. NOTE: These examples are very simple but they serve to get the point across as to how the firewalls work to only allow appropriate access. 158 Network Security: A Beginner’s Guide Rule Number Source IP Destination IP Service Action 1 Any Web server HTTP Accept 2 Any Mail server SMTP Accept 3 Mail server Any SMTP Accept 4 Internal network Any HTTP, HTTPS, FTP, Telnet, SSH Accept 5 Internal DNS Any DNS Accept 6 Any Any Any Drop Table 9-3. Firewall Rules for Firewall #1 in the Dual-Firewall Architecture Rule Number Source IP Destination IP Service Action 1 Internal mail server Mail server SMTP Accept 2 Internal network Any HTTP, HTTPS, FTP, Telnet, SSH Accept 3 Internal DNS Any DNS Accept 4 Any Any Any Drop Table 9-4. Firewall Rules for Firewall #2 in the Dual-Firewall Architecture 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). . important to the bank. A firewall could be installed to restrict access to these systems from other parts of the bank. Types of Firewalls There are two general types of firewalls: application layer. is not a bad turn of events as it allows security administrators to tailor the solution to their particular circumstances. Firewall Configurations Now let’s take a look back at the DMZ architectures. the DMZ: ▼ Web server offering service on port 80 only. ▲ Mail server offering service on port 25 only. This system accepts all inbound mail and sends all outbound mail. The internal mail server