Although NATs frequently require little configuration (unless port forwarding is being used), firewalls usually do, and sometimes they require extensive configu- ration. In most home networks the same device is providing NAT, IP routing, and firewall capabilities and may require some configuration. Although the configu- ration is logically separate for each of these, they are sometimes merged, either in configuration files, command-line interfaces, Web page controls, or other network management tools.
ptg999 Section 7.5 Configuring Packet-Filtering Firewalls and NATs 335
7.5.1 Firewall Rules
A packet-filtering firewall must be given a set of instructions indicating criteria for selecting traffic to be dropped or forwarded. Nowadays when configuring a router, the network administrator usually configures a set of one or more ACLs.
Each ACL consists of a list of rules, and each rule typically contains pattern-match- ing criteria and an action. The matching criteria generally allow the rule to express the values of packet fields at either the network or transport layer (e.g., source and destination IP addresses, port numbers, ICMP type field, etc.) and a direction specification. The direction pattern matches traffic in a direction-dependent man- ner and allows for a different set of rules to apply for incoming versus outgoing traffic. Many firewalls also allow the rules to be applied at a certain point in the order of processing within the firewall. Examples of this include the ability to specify an ACL to be checked prior to or after the IP routing decision process. In some circumstances (especially when more than one interface is used), this flex- ibility becomes important.
When a packet arrives, the matching criteria in the appropriate ACL are con- sulted in order. For most firewalls, the first matching rule is acted upon. Typical actions include a specification to block or forward the traffic and may also adjust a counter or write a log entry. Some firewalls may include additional features as well, such as having some packets directed to applications or other hosts. Each firewall vendor usually has its own method for specifying rules, although Cisco Systems’ ACL format has emerged as a popular format supported by many ven- dors of enterprise-class routers. ACLs for home users are typically configured using a simple Web interface.
One of the popular systems for building firewalls is included with modern versions of Linux and is called iptables, built using a network filtering capa- bility called NetFilter [NFWEB]. It is the evolution of an earlier facility called ipchains and provides stateless and stateful packet-filtering support as well as NAT and NAPT. We shall examine how it works to get a better understanding of the types of capabilities a firewall and modern NAT provide.
iptables includes the concepts of filter tables and filter chains. A table con- tains several predefined chains and may contain zero or more user-defined chains. Three predefined tables are named as follows: filter, nat, and mangle.
The default filter table is for basic packet filtering and contains the predefined chains INPUT, FORWARD, and OUTPUT. These actions correspond to packets destined for programs running on the firewall router itself, those passing through it while being routed, and those originating at the firewall machine. The nat table contains the chains PREROUTING, OUTPUT, and POSTROUTING. The mangle table has all five chains. It is used for arbitrary rewriting of packets.
Each filter chain is a list of rules, and each rule has matching criteria and an action. The action (called a target) may be to execute a special user-defined chain or to perform one of the following predefined actions: ACCEPT, DROP, QUEUE, and RETURN. A packet matching a rule with one of these targets is immediately
ptg999 acted on. ACCEPT (DROP) means the packet is forwarded (dropped). QUEUE
means the packet is delivered to a user program for arbitrary processing, and RETURN means that processing continues in a previously invoked chain, which forms a sort of packet filter chain subroutine call.
The design of a complete firewall configuration can be fairly complex and is specific to the needs of particular users and the types of services they require, so we will not attempt to give one here. Instead, the following examples illustrate only a small number of the possible uses for iptables. The following gives an example Linux firewall configuration file. It is invoked by a shell such as bash:
EXTIF="ext0"
INTIF="eth0"
LOOPBACK_INTERFACE="lo"
ALL="0.0.0.0/0" # matches all
# set default filter table policies to drop iptables -P INPUT DROP
iptables -P OUTPUT DROP iptables -P FORWARD DROP
# all local traffic OK
iptables -A INPUT -i $LOOPBACK_INTERFACE -j ACCEPT iptables -A OUTPUT -i $LOOPBACK_INTERFACE -j ACCEPT
# accept incoming DHCP requests on internal interface iptables -A INPUT -i $INTIF -p udp -s 0.0.0.0 \
--sport 67 -d 255.255.255.255 --dport 68 -j ACCEPT
# drop unusual/suspect TCP traffic with no flags set iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
This example illustrates some of the flexibility one can employ in setting up a filter criteria list. Initially, the chains are given a default policy (-P option), which affects packets that fail to match any rules. Next, traffic to or from the local com- puter (which is delivered using the pseudo interface lo) is given to the ACCEPT target (i.e., it is allowed) for the INPUT and OUTPUT chains in the default filter table. The –j option indicates “jump” to a particular processing target. Next, incoming UDP broadcast traffic originating from IPv4 address 0.0.0.0 and des- tined for local/subnet broadcast using the DHCP port numbers (67, 68) is allowed in via the internal interface. Next, the Flags fields of incoming TCP segments (see Chapter 13) is ANDed with all 1s (ALL) and compared against zero (NONE). A match occurs only if all the Flags fields are 0, which is not a very useful TCP seg- ment (ordinarily all TCP segments after the first one contain a valid ACK bit, and the first one contains a SYN).
While syntax illustrated by this example is specific to the iptables facility, its capabilities are not. Most filtering firewalls are capable of performing similar types of checks and actions.
ptg999 Section 7.5 Configuring Packet-Filtering Firewalls and NATs 337
7.5.2 NAT Rules
In most simple routers, NAT can be configured in conjunction with firewall rules.
In basic Windows systems, NAT is called Internet Connection Sharing (ICS), and in Linux it is called IP masquerading. On Windows XP, for example, ICS has a number of special characteristics. It assigns the “internal” IPv4 address as 192.168.0.1 to the machine running ICS and starts a DHCP server and DNS server. Other computers are assigned addresses in the 192.168.0/24 subnet, with the ICS machine as DNS server. Therefore, ICS should not be enabled on networks where these services are already being provided by another computer or router, or where the addresses might conflict. A registry setting can be used to change the default address range.
Enabling ICS for an Internet connection on Windows XP can be accomplished by using the Network Setup Wizard, or by changing the Advanced properties on an already-operating Internet connection (under Settings | Network Connections).
At this point, the user may also decide to allow other users to control or disable the shared Internet connection. This facility, known as Internet Gateway Device Discov- ery and Control (IGDDC), uses the Universal Plug and Play framework, described in Section 7.5.3, for controlling a local Internet gateway from a client. The functions supported include connect and disconnect, along with reading various status mes- sages. The Windows firewall facility, which works in conjunction with ICS, sup- ports the creation of service definitions. Service definitions are equivalent to port forwarding, as defined previously. To enable it, the Advanced property tab on the Internet connection is selected and a new service may be added (or an existing one edited). The user is then given the opportunity to fill in the appropriate TCP and UDP port numbers, both at the external interface and at the internal server machine. It thus works as a way to configure NAPT for incoming connections.
As with Windows, Linux combines the masquerade capability with its fire- wall implementation. The following script configures masquerading in a simple manner. Note that this script is only for illustration and is not recommended for production use.
EXTIF=”ext0”
echo "Default FORWARD policy: DROP"
iptables -P FORWARD DROP
echo "Enabling NAT on $EXTIF for hosts 192.168.0.0/24"
iptables -t nat -A POSTROUTING -o $EXTIF -s 192.168.0.0/24 \ -j MASQUERADE
echo "FORWARD policy: DROP unknown traffic"
iptables -A INPUT -i $EXTIF -m state --state NEW,INVALID -j DROP iptables -A FORWARD -i $EXTIF -m state --state NEW,INVALID -j DROP
Here, the default policy for the FORWARDING chain in the filter table is set to DROP. The next item arranges for hosts with IPv4 addresses assigned from the 192.168.0.0/24 subnet to have their addresses rewritten for any IPv4 traffic (via
ptg999 NAT, implemented by the nat table and -t nat options) after routing has deter-
mined the external interface to be the appropriate one. Because of the stateful way that NAT works, it is now possible to adjust the filter table’s rules to allow only traffic associated with a connection known to NAT. The last two lines adjust the INPUT and FORWARD chains so that any incoming traffic that is either invalid or unknown (NEW) is dropped. The special operators NEW and INVALID are defined within the iptables command.
7.5.3 Direct Interaction with NATs and Firewalls: UPnP, NAT-PMP, and PCP In many cases, a client system wishes to or needs to interact directly with its fire- wall. For example, a firewall may need to be configured or reconfigured for dif- ferent services by allowing traffic destined for a particular port to not be dropped (establishing a “pinhole”). In cases where a proxy firewall is in use, each client must be informed of the proxy’s identity. Otherwise, communication beyond the firewall is not possible. A number of protocols have been developed for support- ing communication between clients and firewalls. The two most prevalent ones are called Universal Plug and Play (UPnP) and the NAT Port Mapping Protocol (NAT- PMP). The standards for UPnP are developed by an industry group called the UPnP Forum [UPNP]. NAT-PMP is currently an expired draft document within the IETF [XIDPMP]. NAT-PMP is supported by most Mac OS X systems. UPnP has native support on Windows systems and can be added to Mac OS and Linux systems. UPnP is also used in support of consumer electronics device discovery protocols for home networks being developed by the Digital Living Network Alli- ance (DLNA) [DLNA].
With UPnP, controlled devices are configured with IP addresses based first upon DHCP and using dynamic link-local address configuration (see Chapter 6) if DHCP is not available. Next, the Simple Service Discovery Protocol (SSDP) [XIDS]
announces the presence of the device to control points (e.g., client computers) and allows the control points to query the devices for additional information. SSDP uses two variants of HTTP with UDP instead of the more standard TCP. They are called HTTPU and HTTPMU [XIDMU], and the latter uses multicast addressing (IPv4 address 239.255.255.250, port 1900). For SSDP carried on IPv6, the following addresses are used: ff01::c (node-local), ff02::c (link-local), ff05::c (site-local), ff08::c (organization-local), and ff0e::c (global).
Subsequent control and event notification (“eventing”) is controlled by the General Event Notification Architecture (GENA), which uses the Simple Object Access Protocol (SOAP). SOAP supports a client/server remote procedure call (RPC) mecha- nism and uses messages encoded in the Extensible Markup Language (XML), which is commonly used for Web pages. UPnP is used for a wide variety of consumer elec- tronic devices, including audio and video playback and storage devices. NAT/fire- wall devices are controlled using the Internet Gateway Device (IGD) protocol [IGD].
IGD supports a variety of capabilities, including the ability to learn NAT mappings and configure port forwarding. The interested reader may obtain a simple IGD
ptg999 Section 7.6 NAT for IPv4/IPv6 Coexistence and Transition 339
client useful for experimentation from the MiniUPnP Project HomePage [UPNPC].
A second version of UPnP IGD [IGD2] adds general IPv6 support to UPnP.
While UPnP is a broad framework that includes NAT control and several other unrelated specifications, NAT-PMP provides an alternative specifically targeted at programmatic communications with NAT devices. NAT-PMP is part of Apple’s set of Bonjour specifications for zero configuration networking. NAT-PMP does not use a discovery process, as the device being managed is usually a system’s default gateway as learned by DHCP. NAT-PMP uses UDP port 5351. NAT-PMP supports a simple request/response protocol for learning a NAT’s outside address and con- figuring port mappings. It also supports a basic eventing mechanism that notifies listeners when a NAT outside address changes. This is accomplished using a UDP multicast message sent to address 224.0.0.1 (the All Hosts address) when the out- side address changes. NAT-PMP uses UDP port 5350 for client/server interactions and 5351 for multicast event notification. The idea of NAT-PMP can be extended for use with SPNAT, as proposed by the Port Control Protocol (PCP) [IDPCP].