Chapter 5. Firewall Technologies
In Part I, we introduced Internet firewalls and summarized what they can and cannot do to improve network security. In this chapter, we present major firewalls concepts. What are the terms you will hear in discussions of Internet firewalls? What are the components that can be put together to build these common firewall architectures? How do you evaluate a firewall design? In the remaining chapters of this book, we’ll describe these components and architectures in detail.
5.1 Some Firewall Definitions
You may be familiar with some of the following firewall terms, and some may be new to you. Some may seem familiar, but they may be used in a way that is slightly different from what you’re accustomed to (though we try to use terms that are as standard as possible). Unfortunately, there is no completely consistent terminology for firewall architectures and components. Different people use terms in different – or, worse still, conflicting – ways. Also, these same terms sometimes have other meanings in other networking fields; the following definitions are for a firewalls context.
Here are some very basic definitions; we describe these terms in greater detail elsewhere:
A component or set of components that restricts access between a protected network and the Internet, or between other sets of networks.
A computer system attached to a network.
A computer system that must be highly secured because it is vulnerable to attack, usually because it is exposed to the Internet and is a main point of contact for users of internal networks. It gets its name from the highly fortified projections on the outer walls of medieval castles.12
A general-purpose computer system that has at least two network interfaces (or homes).
Network address translation (NAT)
A procedure by which a router changes data in packets to modify the network addresses. This allows a router to conceal the addresses of network hosts on one side of it. This technique can enable a large number of hosts to connect to the Internet using a small number of allocated addresses or can allow a network that’s configured with illegal or unroutable addresses to connect to the Internet using valid addresses. It is not actually a security technique, although it can provide a small amount of additional security. However, it generally runs on the same routers that make up part of the firewall.
The fundamental unit of communication on the Internet.
A program that deals with external servers on behalf of internal clients. Proxy clients talk to proxy servers, which relay approved client requests on to real servers, and relay answers back to clients.
12 Marcus Ranum, who is generally held responsible for the popularity of this term in the firewalls professional community, says, “Bastions… overlook critical areas of defense, usually having stronger walls, room for extra troops, and the occasional useful tub of boiling hot oil for discouraging attackers”.
Building Internet Firewalls
The action a device takes to selectively control the flow of data to and from a network. Packet filters allow or block packets, usually while routing them from one network to another (most often from the Internet to an internal network, and vice versa). To accomplish packet filtering, you set up a set of rules that specify what types of packets (e.g., those to or from a particular IP address or port) are to be allowed and what types are to be blocked. Packet filtering may occur in a router, in a bridge, or on an individual host. It is sometimes known as screening.13
A network added between a protected network and an external network, in order to provide an additional layer of security. A perimeter network is sometimes called a DMZ, which stands for De- Militarized Zone (named after the zone separating North and South Korea).
Virtual private network (VPN)
A network where packets that are internal to a private network pass across a public network, without this being obvious to hosts on the private network. In general, VPNs use encryption to protect the packets as they pass across the public network. VPN solutions are popular because it is often cheaper to connect two networks via public networks (for instance, getting them both Internet connections) than via private networks (like traditional leased-line connections between the sites).
The next few sections briefly describe the major technologies associated with firewalls: packet filtering, proxy services, network address translation, and virtual private networks.
There are legitimate questions about how to distinguish between packet filtering and proxying, particularly when dealing with complex packet filtering systems and simple proxies. Many people believe that systems that pay attention to individual protocols and/or modify packets should not be considered packet filters, and may even refer to these systems as transparent proxies. In fact, these systems don’t behave much like older, simpler packet filtering systems, and it’s a good idea not to apply generalizations about packet filtering to them blindly. On the other hand, they don’t behave much like proxying systems, either.
Similarly, a number of proxying systems provide generic proxies, which essentially function like packet filters, accepting all traffic to a given port without analyzing it. It’s advisable to pay close attention to the individual technology a product uses, without making assumptions based on whether it claims to be a packet filter or a proxy. However, many systems still are clearly packet filters or clearly proxies, so it is worth understanding what these technologies are and how they work.
5.2 Packet Filtering
Packet filtering systems route packets between internal and external hosts, but they do it selectively. They allow or block certain types of packets in a way that reflects a site’s own security policy, as shown in Figure 5.1. The type of router used in a packet filtering firewall is known as a screening router.
As we discuss in Chapter 8, every packet has a set of headers containing certain information. The main information is:
• IP source address • IP destination address • Protocol (whether the packet is a TCP, UDP, or ICMP packet) • TCP or UDP source port • TCP or UDP destination port • ICMP message type • Packet size
The router can also look past the packet headers at data further on in the packet; this allows it, for instance, to filter packets based on more detailed information (like the name of the web page that somebody is requesting) and to verify that packets appear to be formatted as expected for their destination port. The router can also make sure that the packet is valid (it actually is the size that it claims to be and is a legal size, for instance), which helps catch a number of denial of service attacks based on malformed packets.
In addition, the router knows things about the packet that aren’t reflected in the packet itself, such as:
• The interface the packet arrives on • The interface the packet will go out on
Finally, a router that keeps track of packets it has seen knows some useful historical facts, such as:
• Whether this packet appears to be a response to another packet (that is, its source was the destination of a recent packet and its destination is the source of that other packet) • How many other packets have recently been seen to or from the same host • Whether this packet is identical to a recently seen packet • If this packet is part of a larger packet that has been broken into parts (fragmented)
To understand how packet filtering works, let’s look at the difference between an ordinary router and a screening router.
An ordinary router simply looks at the destination address of each packet and picks the best way it knows to send that packet towards that destination. The decision about how to handle the packet is based solely on its destination. There are two possibilities: the router knows how to send the packet towards its destination, and it does so; or the router does not know how to send the packet towards its destination, and it forgets about the packet and returns an ICMP “destination unreachable” message, to the packet’s source.
A screening router, on the other hand, looks at packets more closely. In addition to determining whether or not it can route a packet towards its destination, a screening router also determines whether or not it should. “Should” or “should not” are determined by the site’s security policy, which the screening router has been configured to enforce.
Packet filtering may also be performed by devices that pay attention only to “should” and “should not” and have no ability to route. Devices that do this are packet filtering bridges. They are rarer than packet filtering routers, mostly because they are dedicated security devices that don’t provide all the other functions that routers do. Most sites would rather add features to routers that they need anyway, instead of adding a dedicated device. However, being a dedicated device provides advantages for packet filtering bridges; in particular, they are harder to detect and attack than packet filtering routers. They provide the same general features that we discuss for packet filtering routers.
Once it has looked at all the information, a straightforward packet filtering router can do any of the following things:
• Send the packet on to the destination it was bound for. • Drop the packet – just forget it, without notifying the sender. • Reject the packet – refuse to forward it, and return an error to the sender. • Log information about the packet. • Set off an alarm to notify somebody about the packet immediately.
More sophisticated routers might also be able to do one or more of these things:
• Modify the packet (for instance, to do network address translation). • Send the packet on to a destination other than the one that it was bound for (for instance, to force transactions through a proxy server or perform load balancing). • Modify the filtering rules (for instance, to accept replies to a UDP packet or to deny all traffic from a site that has sent hostile packets).
The fact that servers for particular Internet services reside at certain port numbers lets the router block or allow certain types of connections simply by specifying the appropriate port number (e.g., TCP port 23 for Telnet connections) in the set of rules specified for packet filtering. (Chapter 8, describes in detail how you construct these rules.)
Here are some examples of ways in which you might program a screening router to selectively route packets to or from your site:
• Block all incoming connections from systems outside the internal network, except for incoming SMTP connections (so that you can receive electronic mail). • Block all connections to or from certain systems you distrust. • Allow electronic mail and FTP services, but block dangerous services like TFTP, the X Window System, RPC, and the “r” services (rlogin, rsh, rcp, etc.). (See Chapter 13, for more information.)
Packet filtering devices that keep track of packets that they see are frequently called stateful packet filters (because they keep information about the state of transactions). They may also be called dynamic packet filters because they change their handling of packets dynamically depending on the traffic they see. Devices that look at the content of packets, rather than at just their headers, are frequently called intelligent packet filters. In practice, almost all stateful packet filters also are capable of looking at the contents of packets, and many are also capable of modifying the contents of packets, so you may see all these capabilities lumped together under the heading “stateful packet filtering”. However, something can legitimately be called a “stateful packet filter” without having the ability to do advanced content filtering or modification.
A packet filtering system is also a logical place to provide virtual private network or network address translation services. Since the packet filter is already looking at all of the packets, it can easily identify packets that are intended for a destination that is part of the virtual private network, encrypt those packets, and encapsulate them in another packet bound for the appropriate destination.
5.2.1 Advantages of Packet Filtering
Packet filtering has a number of advantages.
22.214.171.124 One screening router can help protect an entire network
One of the key advantages of packet filtering is that a single, strategically placed packet filtering router can help protect an entire network. If only one router connects your site to the Internet, you gain tremendous leverage on network security, regardless of the size of your site, by doing packet filtering on that router.
Building Internet Firewalls
126.96.36.199 Simple packet filtering is extremely efficient
Because simple packet filtering requires paying attention only to a few packet headers, it can be done with very low overhead. Proxying is a fairly time-consuming operation, and adding proxying means directing connections through another program, usually on a machine that otherwise wouldn’t be necessary to the routing process. Packet filtering takes place on a machine that was already in the critical path, and introduces a much smaller delay.
However, there is no free lunch; the more work your packet filters do, the slower they will be. If your packet filters behave like proxies, doing complicated data-driven operations that require keeping track of multiple packets, they will tend to perform like proxies as well.
188.8.131.52 Packet filtering is widely available
Packet filtering capabilities are available in many hardware and software routing products, both commercial and freely available over the Internet. Most sites already have packet filtering capabilities available in the routers they use.
Most commercial router products include packet filtering capabilities. Packet filtering capabilities are also available for a number of general-purpose computers. These are discussed further in Chapter 8.
5.2.2 Disadvantages of Packet Filtering
Although packet filtering provides many advantages, there are some disadvantages to using packet filtering as well.
184.108.40.206 Current filtering tools are not perfect
Despite the widespread availability of packet filtering in various hardware and software packages, packet filtering is still not a perfect tool. The packet filtering capabilities of many of these products share, to a greater or lesser degree, common limitations:
• The packet filtering rules tend to be hard to configure. Although there is a range of difficulty, it mostly runs from slightly mind-twisting to brain-numbingly impossible. • Once configured, the packet filtering rules tend to be hard to test. • The packet filtering capabilities of many of the products are incomplete, making implementation of certain types of highly desirable filters difficult or impossible. • Like anything else, packet filtering packages may have bugs in them; these bugs are more likely than proxying bugs to result in security problems. Usually, a proxy that fails simply stops passing data, while a failed packet filtering implementation may allow packets it should have denied.
220.127.116.11 Packet filtering reduces router performance
Doing packet filtering places a significant extra load on a router. As we discussed previously, more complex filters place more load on the router, but in some cases, simply turning on packet filtering on a given interface can also cost you a lot of performance on some routers, because the filtering is incompatible with certain caching strategies commonly used for performance enhancement. Cisco’s “fastpath” functionality is an example of this; normally, fastpath can perform basic routing functions completely on the interface card, without involving the main CPU, but using some forms of filtering requires involving the main CPU for each packet, which is much slower. What enables/disables fastpath depends on the hardware and software version.
18.104.22.168 Some policies can’t readily be enforced by normal packet filtering routers
The information that a packet filtering router has available to it doesn’t allow you to specify some rules you might like to have. For example, packets say what host they come from but generally not what user. Therefore, you can’t enforce restrictions on particular users. Similarly, packets say what port they’re going to but not what application; when you enforce restrictions on higher-level protocols, you do it by port number, hoping that nothing else is running on the port assigned to that protocol. Malicious insiders can easily subvert this kind of This problem is eased by using more intelligent packet filters; however, in each case, you have to give up some of the advantages of normal packet filtering. For instance, a packet filter can insist that users authenticate themselves before sending packets, and then it can filter packets by username. However, this removes the transparency advantage of normal packet filtering. A packet filter can also do protocol validity checking, but this is less than perfect and also increases filtering overhead.
even on unfiltered connections). In addition, it becomes very difficult to detect forged source addresses. Most such systems have special configurations to deal with forged source addresses, but these are less flexible than the controls you can get by directly specifying rules. In particular, they may protect you from external forgeries without detecting internal forgeries.
8.8.7 It Should Be Able to Log Accepted and Dropped Packets
Make sure the packet filtering router gives you the option of logging all of the packets it drops. You want to know about any packets that are blocked by your packet filtering rules. These rules reflect your security policy, and you want to know when somebody attempts to violate that policy. The simplest way to learn about these attempted violations is through such a log.
You’d also like to be able to log selected packets that were accepted. For example, you might want to log the start of each TCP connection. Logging all accepted packets is going to be too much data in normal operation but may be worth it occasionally for debugging and for dealing with attacks in progress. Although you will probably be doing some logging at the packet destination, that logging won’t work if the destination host has been compromised, and won’t show packets that make it through the packet filter but don’t have a valid destination. Those packets are interesting because they may be probes from an attacker. Without information from the router, you won’t have the complete picture of what the attacker is doing.
The specific information that is logged is also important and packet filtering routers have widely varying capabilities. You will want information about which rule and packet caused the log entry to be made. Ideally, you would like to know the definition of the rule, but a name or other constant identifier would be sufficient. A rule number which changes every time you edit the rule set is the least useful rule identifier, although it’s better than no information at all.
You will also want information about the packet itself. At a minimum you will want to see source and destination IP addresses and protocol. For TCP and UDP packets you will want to see source and destination port numbers (and the flags for TCP packets). For ICMP you will want to see the type and code. Without this information it can be very difficult to debug rulesets or, when you are being attacked, trace or block packets from an unwanted source. In some situations, it is preferable to log the entire packet, instead of a summary.
The logging should be flexible; the packet filter should give you the ability to log via syslog and to a console or a local file. It would also be helpful if the logging included the ability to generate SNMP traps on certain events. Some packet filters also have various alerting capabilities (they can page an administrator or send email). These capabilities are useful but are less flexible than a generalized alerting system based on SNMP. If the packet filtering machine has a modem directly attached, and is capable of completing a page independently, paging capabilities provide a useful alerting mechanism of last resort, where the machine can call for help if it is unable to send any network traffic at all. Otherwise, paging on the packet filter is not of much interest; you would be better served by an alert sent to a general-purpose system.
8.8.8 It Should Have Good Testing and Validation Capabilities
An important part of establishing a firewall is convincing yourself (and others within your organization) that you’ve done the job right and haven’t overlooked anything. To do that, you need to be able to test and validate your configuration. Most of the packet filtering packages currently available have little or nothing in the way of testing and validation capabilities.
Testing and validation come down to two related questions:
• Have you properly told the router to do what you want? • Is the router doing what you’ve told it to?
Building Internet Firewalls
Unfortunately, with many products available today, both of these questions tend to be difficult to answer. In the few products that provide any kinds of testing capabilities, what the test says it will do with a given packet and what it actually does with such a packet are sometimes different, often because of subtle caching and optimization bugs. Some sites (and, we hope, some vendors!) have constructed filtering test beds, where they can generate test packets on one side of a filtering router and watch to see what comes through to the other side, but that’s beyond the capabilities and resources of most sites. About the best you can do is pick something with a good reputation for not having many problems and good support for when it inevitably does have problems.
8.9 Packet Filtering Implementations for General-Purpose Computers
These days, a number of operating systems provide packet filtering features, independent of firewall products. Many Unix variants come with packet filtering, as does Windows NT.
There are two major reasons why you might want to use packet filtering implementations on general-purpose computers. First, you may want to use a general-purpose computer as a router (either providing only packet filtering, or as a single-box firewall that provides both packet filtering and proxying). In this case, you are using the general-purpose computer to provide the same sort of packet filtering services that a router would provide. Second, you may be using the general-purpose computer as a bastion host, and you may want to use packet filtering on the computer as a security measure to protect the computer itself.
8.9.1 Linux ipchains and Masquerading
The Linux kernel includes a packet filtering system called ipchains, which provides powerful packet filtering capabilities. This system provides the same sorts of capabilities that you would get from a modern packet filtering router and is suitable for using where you’d use a router. Because it’s part of the standard Linux kernel source, it should be present in all up-to-date Linux distributions, although it may not be enabled by default.
Earlier Linux kernels used a filtering system called ipfw (which was a port of a BSD filtering system) and a configuration utility called ipfwadm. ipchains is a new filtering system, which provides more functionality than ipfw. ipchains allows you to convert configuration files from ipfwadm to ipchains.
The filtering performed by ipchains is done entirely in the kernel, and it requires only a single external utility to initialize the filtering rules. This means that it is possible to build a complete Linux filtering system that will fit on a single 1.44 MB floppy disk. The Linux Router Project is doing exactly this (see Appendix A, for more information about the Linux Router Project).
Linux also has a facility called masquerading, which is used with ipchains to provide network address translation for both TCP and UDP. Masquerading keeps track of TCP connection state and supports timeout-based UDP requests and responses. Because it must be used with packet filtering, it can be considered a dynamic packet filtering system. In addition to providing straightforward network address translation for simple TCP and UDP protocols, Linux masquerading allows additional kernel modules to be loaded for more complicated protocols (for instance, FTP and RealAudio, which require reverse TCP connections or additional UDP ports).
ipchains is designed around the concept of a chain of rules. Each rule specifies a condition and an action to take if the condition is met, called a target. The rules in a chain are used in order; a packet is checked against each rule in turn, and if the packet matches the condition, the specified action is taken.
There are three standard chains, called the input, output, and forward chains. All packets coming in to the machine are passed through the input chain, and all packets going out of the machine are passed though the output chain. The forward chain is used for packets that need to be sent to a different network interface from the one they were received on. Thus, if a packet is received for the machine, it’s matched against the input chain; if the machine generates a packet, it’s matched against the output chain. If the machine is acting as a router and gets a packet addressed to some other machine, the packet will be matched against all three chains.
The standard chains each have a default policy, which is applied when no rules match. It is also possible to create additional, user-defined, chains. If no rules match when checking a user-defined chain, processing will continue at the point where the chain was called.
Building Internet Firewalls
The conditions in a rule can be based on any of the following:
• The IP protocol number (e.g., TCP, UDP, ICMP, or IGMP). • The source and destination IP addresses. Addresses can be specified as a variable-length subnet (e.g., 192.168.8.0/22) or a network address with a mask, and negation is allowed (you can specify “all addresses except those that match this address and mask”). • The source and destination TCP and UDP port numbers. Port numbers can be specified with ranges or masks, and negation is allowed. • The ICMP type and code. • Whether the packet is an IP fragment. • Whether the packet is a TCP start-of-connection packet. • The network interface. This is the interface the packet came in on for the input chain and the destination interface for the output and forward chains.
Each rule in a chain has a target action that is applied when the rule matches. The target of a rule decides what next happens to a packet. The allowed targets are:
• Deny: Drop the packet without generating a response. • Reject: Don’t process the packet, but generate an ICMP response (which will be passed though the output chain). • Accept: Process the packet. • Masq: Perform masquerading. This target is only valid in the forward chain. • Redirect: Forward the packet to a different port on the local machine. • Return: Apply the default policy for a built-in chain or continue processing at the point where a user- defined chain was called. • A user-defined chain.
Because a user-defined chain can be the target of a rule, it is possible to build complex filters or make ipchains behave like other packet filtering systems.
A rule can also make a log entry, which contains information about the action that was taken, the time, and a summary of the packet headers. Logging is performed by syslog.
22.214.171.124 Testing ipchains rules
ipchains has a very useful feature that allows the kernel-filtering rules to be tested. The ipchains command allows you to specify IP header values to be tested against the currently loaded kernel filtering rules. Using the standard target names, the command prints how the kernel would react if the packet had really been sent to the firewall. At the time of writing, it is not possible to generate and test arbitrary packets.
Linux masquerading is a network address translation system. Because it is capable of working at higher protocol levels, and doing more intricate modifications than simple address changes, it’s also called a transparent proxying system. What it does could be considered either proxying or packet filtering; it’s somewhere in between the two.
The IP address of the firewall is used in communicating with remote services. For simple protocols, masquerading alters only IP header information, including IP addresses, port numbers, and TCP sequence and acknowledgment numbers. Masquerading uses the IP address of the host doing the masquerading as the externally visible address, and maps the port number into one from a pool of 4096 ports starting at 61000. This fixed allocation of ports does limit Linux masquerading to 4096 simultaneous TCP connections and 4096 UDP ports. At the time of writing, Linux kernels allocate only ports less than 32768, so the ports used for masquerading will never conflict with ports used for other purposes.
Linux masquerading is also capable of dealing with more complicated protocols, such as FTP or RealAudio, which might require reverse TCP connections or additional UDP ports. Support for new protocols can be added by dynamically loading new kernel modules.
Building Internet Firewalls
126.96.36.199 How masquerading works
Masquerading works by intercepting packets that are being forwarded by the Linux kernel. Masquerading for simple protocols works much like simple network address translation, as described in Section 5.1. IP addresses and port numbers are modified on outgoing packets. For TCP connections, a new sequence number is generated. The process is reversed for incoming packets. Figure 8.5 is an example of this working for a client connecting to a remote HTTP server, and shows the IP address and ports for each half of the connection. The masquerading firewall will continue to pass packets back to the client as long as the client maintains the outgoing half of the TCP connection. In the case of UDP, the firewall will pass packets back to the client only for a configurable time period, which is typically set to 15-30 second
In addition to handling outgoing traffic, masquerading can be used to forward incoming ports to internal services. The ability to masquerade incoming ports is configured statically for each port that is to be forwarded. Once a port is forwarded, it can no longer be used to connect to a service on the firewall. Figure 8.6 shows a masquerading firewall configured to forward SSH to an internal destination and includes the IP addresses and port numbers for each half of the connection. It’s possible to forward the same port to multiple destinations if the masquerading firewall is configured to listen to multiple IP addresses
For more complicated protocols, masquerading can set up additional listening TCP and UDP ports based upon the contents of packets that have been seen. Masquerading can even rewrite the contents of data packets in order to replace IP addresses and port numbers.
This is best explained by describing how the masquerading module for FTP works. As we discuss in Chapter 17, FTP is a tricky protocol to support through a firewall because it normally involves a connection from the server to the client. An FTP client opens a control channel to a desired FTP server. At the point where data is to be transferred, the client issues a PORT command that contains the client IP address and a port number the client expects to receive the data on. The FTP server uses this information to open a new TCP connection to the client in order to transfer the data.
For masquerading to work, it must intercept the PORT command from the client. The FTP masquerading module does this by listening to the commands sent over all FTP control channels. When it sees a PORT command, it does two things; first, it sets up a temporary port on the masquerading host, which is forwarded to the port the client specified. Next, it rewrites the IP packet containing the PORT command with the IP address of the firewall and the temporary port. When an incoming connection to the temporary port is made, it is forwarded to the client. Figure 8.7 describes this process.
188.8.131.52 Available specialized masquerading modules
A number of specialized masquerading modules are available. At the time of writing, they can be split into three categories: multimedia, games, and access to internal services. An up-to-date list of modules and their availability can be found in the Linux MASQUERADING-HOWTO. See Appendix A, for information on how to obtain Linux HOWTO documents.
184.108.40.206 Using ipchains (including masquerading)
To use ipchains, you must compile it into the kernel you are using. The actual kernel compilation flags for turning it on are different in different Linux releases; you should either consult help for your Linux kernel configuration utility or use the Linux IPCHAINS-HOWTO. See Appendix A for information on obtaining Linux HOWTO documents.
We also recommend that you turn on fragment reassembly. See Chapter 4, for information on IP fragmentation and why this is important.
Masquerading is included as a standard part of Linux 2.1 and 2.2 kernel source code. It does need to be enabled when the kernel is compiled, and it also depends on the Linux firewalling code. The kernel compile-time option for enabling Linux masquerading is CONFIG_IP_MASQUERADE=Y.
In order to use all of the facilities of ipchains and masquerading, you will also need the ipchains and ipmasqadm commands used to define the filtering and masquerading rules.
ipchains rules are built incrementally; when the machine boots, it installs the rules in order, so there will be a brief period while it is initializing when the chain is not fully built, and the default policy will be used before the end of the chain has been configured. If the default policy is to accept packets, you may accept packets that you would otherwise have denied. You should therefore put in an initial explicit default policy that denies packets.
One tempting way to avoid this problem is to build the chains before you actually configure the network interfaces (if you can’t receive the packets, there’s no need to worry about what you do with them). In most situations, this won’t work because rules will be rejected if they refer to network interfaces that haven’t been configured. If you have a configuration of the kind we recommend, you will have to configure the network interface before you can build the chains you are actually going to use. Thus, you will end up using two bootup scripts for the ipchains configuration. The first script will initialize default deny policies for each chain; the second will load the rules you wish to use.
When combined with the network interface configuration scripts, this will result in the following three-stage process:
- Load default deny polices that do not specify an interface. 2. Configure the network interfaces. 3. Load the real ipchains rules you’re going to use.
Since the default policy does not do any logging, it is often useful to duplicate it with a final rule that will also log denied traffic. In other packet filtering situations, we recommend doing this for documentation purposes; in this case, you have already documented the default with the initial default policy, but you need both in order to combine security and logging.
When masquerading is operating, the standard Unix netstat program does not list masqueraded ports. This means that the machine will be accepting packets for ports that don’t show up when you run netstat, which may be disconcerting to experienced network administrators.
Published @ September 29, 2021 1:59 pm