阅读了<<Linux Firewalls, Third Edition>>，发觉原来优化下iptables脚本，效率会提高不少。虽然没有对比过，估且相信它吧。现在我摘录下来，以便以后用到，哈哈。
Chapter 5. Firewall Optimization
Chapter 4, "Building and Installing a Standalone Firewall," used the iptables firewall administration program to build a simple, single-system, custom-designed firewall. This chapter introduces firewall optimization. Optimization can be divided into three major categories: rule organization, use of the state module, and user-defined chains. The example in the preceding chapter was shown both with and without the use of the state module. This chapter focuses on rule organization and user-defined chains.
Rule Organization
Little optimization can be done using only the INPUT, OUTPUT, and FORWARD chains. Chain traversal is top to bottom, one rule at a time, until the packet matches a rule. The rules on a chain must be ordered hierarchically, from most general to most specific.
There is no hard-and-fast formula for rule organization. The two main underlying factors are which services are hosted on the machine and the machine's primary purpose, noting especially the heaviest traffic services on the machine. The requirements of a dedicated firewall and packet forwarder are very different from those of a bastion firewall protecting a dedicated web or mail server. Likewise, a site administrator is likely to place different performance priorities on a firewalled machine that serves primarily as a workstation than a firewall that serves as both a residential gateway and a Linux server for a home.
The third underlying factor to consider when preparing to organize rules for firewall optimization is the available network bandwidth, the speed of the Internet connection. Optimization isn't likely to buy much, if anything, for a site with a residential-speed Internet connection. Even for a heavily accessed website, the machine's CPU isn't likely to break a sweat. The bottleneck is the Internet connection itself.
Begin with Rules That Block Traffic on High Ports
As the example in Chapter 4 demonstrated, the bulk of the rules are antispoofing rules, or rules blocking traffic on specific high ports (such as NFS or X Windows). These types of rules must come before the rules allowing traffic to specific services. Obviously, the FTP data channel rules must come near the end of the rule list, even though you'd want the rules to be near the top of the list because FTP transfers tend to be large.
Use the State Module for ESTABLISHED and RELATED Matches
Using the state module's ESTABLISHED and RELATED matches essentially allows for moving all rules for ongoing exchanges to the head of the chains, as well as eliminating the need for specific rules for the server half of a connection. In fact, bypassing filter matching for ongoing, recognized, previously accepted exchanges is one of the two primary purposes of the state module.
The state module's second primary purpose is to serve a firewall-filtering function. Connection-state tracking allows the firewall to associate packets with ongoing exchanges. This is particularly useful for connectionless, stateless UDP exchanges.
Consider the Transport Protocol
The transport protocol that the service runs over is another factor. In a static firewall, the overhead of testing every single incoming packet against all the spoofing rules is a big loss.
TCP SERVICES: BYPASS THE SPOOFING RULES
Even without the state module, for TCP-based services, the rule for the remote server half of a connection can bypass the spoofing rules. The TCP layer will drop incoming spoofed packets with the ACK bit set because the packet won't match any of the TCP layer's established connection states.
The remote client half of a rule pair must follow the spoofing rules, however, because the typical client rule covers both the initial connection request and the ongoing traffic from the client. If the SYN and ACK flags are tested for individually, the rules testing for the ACK flag in packets arriving from remote clients can bypass the spoofing tests. The spoofing tests must apply to only the initial SYN request.
Use of the state module also allows the rule for the remote client's incoming connection request, the initial SYN packet, to be logically separate from the rule for the client's subsequent ACK packets. Only the initial connection request, the initial NEW packet, needs to be tested against the spoofing rules.
UDP SERVICES: PLACE INCOMING PACKET RULES AFTER SPOOFING RULES
Without the state module, for UDP-based services the rule for incoming packets must always follow the spoofing rules. The concept of client and server is maintained at the application level, assuming that it's maintained at all. At the firewall and UDP levels, without connection state, there is no indication of initiator and responder, other than the service port or unprivileged port used. As you saw in Chapter 4, some UDP services use the associated well-known service port for both the client and the server, whereas other services use unprivileged ports for both.
DNS is an example of a connectionless UDP service. Without connection state, there isn't a mapping between the destination address where the client sent a query and the source address in an incoming response packet. One of the reasons DNS cache poisoning is possible is that DNS server implementations do not check whether an incoming packet was a legitimate response from the server previously queried or whether the packet was sent from some other address. Furthermore, some implementations do not even ensure that a client made a request. An incoming, unrequested rogue packet could be used to update the local DNS cache even without an initial query having been made.
TCP VERSUS UDP SERVICES: PLACE UDP RULES AFTER TCP RULES
Overall, UDP rules should be placed later in the firewall chains, after any TCP rules. This is because most Internet services run over TCP, and connectionless UDP services are typically simple, single-packet query-and-response services. Testing the single or UDP packet or a handful of them against the preceding rules for ongoing TCP connections doesn't add noticeable drag to a UDP query and response. A notable exception is streaming media, such as the RealAudio data stream. However, as stated in Chapter 4, multimedia and other bidirectional, multiconnection session protocols are not firewall-friendly to begin with. Such services cannot pass through a firewall or NAT without specific ALG support.
ICMP SERVICES: PLACE THEIR RULES LATE IN THE RULE CHAIN
ICMP is another protocol whose firewall rules can be placed late in the rule chain. ICMP packets are small control and status messages. As such, they are sent relatively infrequently. Legitimate ICMP packets usually consist of a single, nonfragmented packet. With the exception of echo-request, ICMP packets are almost always sent as a control or status message in response to an exceptional outgoing packet of some kind.
Place Firewall Rules for Heavily Used Services as Early as Possible
Generally, there are no hard-and-fast rules for firewall rule placement in a list. Rules for heavily used services, such as the HTTP-related rules for a dedicated web server, should be placed as early as possible. Rules for applications that involve high, ongoing packet counts also should be placed as early as possible. However, as mentioned earlier, the data stream protocols for applications such as FTP and RealAudio require the rules to be placed near the end of the chain, after any other application rules.
Use the Multiport Module to Specify Port Lists
Some small gains can be had by using the multiport module to specify port lists, thereby collapsing several rules into one. Both the number of rules in the list and the number of specific match tests performed are reduced. Effectively, the packets matching one of the ports in the list share a single instance of the tests for the interface, protocol, TCP flags, and source and destination address. The actual amount of gain seen is dependent on the specific services the firewall accepts. Obviously, the services represented by the ports must share identical transport header characteristics to share the specific set of tests the rule represents.
Use Traffic Flow to Determine Where to Place Rules for Multiple Network Interfaces
If the host has multiple network interfaces, rules specific to a given interface should be placed with regard to which interfaces will have the heaviest traffic flow. Rules for those interfaces should precede rules for other interfaces. Interface considerations are probably of little interest to a residential site, but they can have a major impact on throughput for a commercial site.
As a case in point, this issue came up several years ago with a small ISP that had built a firewall based on the ipfwadm and ipchains examples on Bob Ziegler's website. As shown in Figure 5.1 and Figure 5.2, the path that packets take through the operating system is very different between IPFW and Netfilter. Unlike Netfilter and iptables, with ipchains, packets passing between network interfaces are passed from the input chain to the forward chain to the output chain. The examples on the website were intended as examples for people at home. The input and output rules for the LAN were the last rules in the scripts. The rules specific to the local Linux host came first. The ISP's firewall was primarily functioning as a router or gateway. Through experimentation, the ISP found that moving the I/O rules for the LAN interface to the beginning of the input and output chains resulted in more than a megabit-per-second increase in throughput.
User-Defined Chains
The filter table has three permanent, built-in chains: INPUT, OUTPUT, and FORWARD. iptables enables you to define chains of your own, called user-defined chains. These user-defined chains are treated as rule targetsthat is, based on the set of matches specified in a rule, the target can branch off or jump to a user-defined chain. Rather than the packet being accepted or dropped, control is passed to the user-defined chain to perform more specific match tests relative to packets matching the branch rule. After the user-defined chain is traversed, control returns to the calling chain, and matching continues from the next rule in the calling chain unless the user-defined chain matched and took action on the packet.
Figure 5.3 shows the standard, top-down rule traversal using the built-in chains.
User-defined chains are useful in optimizing the ruleset and therefore are often used. They allow the rules to be organized into categorical trees. Rather than relying on the straight-through, top-down check-off list type of matching inherent in the standard chain traversal, packet match tests can be selectively narrowed down based on the characteristics of the packet. Figure 5.4 shows initial packet flow. After initial tests common to all incoming packets are performed, packet matching branches off based on the destination address in the packet.
Branching is based on destination address in this example. Source address matching is done later in relation to specific applications, such as remote DNS or mail servers. In most cases, the remote address will be "anywhere." Matching on destination address at this point distinguishes between unicast packets targeted to this machine, broadcast packets, multicast packets, and (depending on whether it's the INPUT or FORWARD chain) packets targeted to internal hosts.
Figure 5.5 details the user-defined chain for the protocol rules for packets specifically addressed to this host. As shown, user-defined chains can jump to other user-defined chains containing even more specific tests.
This list summarizes the characteristics of user-defined chains from Chapter 3, "iptables: The Linux Firewall Administration Program":
· User-defined chains are created with the -N or --new-chain operations.
· User-defined chain names can be up to 30 characters in length.
· User-defined chain names can contain hyphens (-) but not underscores (_).
· User-defined chains are accessed as rule targets.
· User-defined chains do not have default policies.
· User-defined chains can call other user-defined chains.
· If the packet doesn't match a rule on the user-defined chain, control returns to the next rule in the calling chain.
· The user-defined chain can be exited early, with control returning to the next rule in the calling chain, via use of the RETURN target.
· User-defined chains are deleted with the -X or --delete-chain operations.
· A chain must be empty before it can be deleted.
· A chain cannot have any references to it from other chains to be deleted.
· A chain is emptied specifically by name, or all existing chains are emptied if no chain is specified, with the -F or --flush operations.
The next section takes advantage of user-defined chains and the concepts presented in the section on rule organization to optimize the single-system firewall presented in Chapter 4.
