![[Screening router diagram]](screenRouter.gif)
Using a screening router to do packet
filtering
Abstract: Packet filtering is a technique for improving network security that removes packets whose fields match certain patterns. Even though it is called "filtering", packet alteration before accepting is available. This lecture describes how packet filtering is done and presents the setup of a filter based on Linux.
PMpacketFiltering.pptAn IP packet is a sequence of bytes containing
Protocols such as Telnet and SMTP lend themselves to packet filtering. Filtering examines certain details of the packets at the bottom most layer of the network software of an OS. In the case of incoming packets, filtering occurs soon after they are received by the NIC, and in the case of outgoing packets, it occurs just as they are about to be sent out via the NIC. The filtering is also applicable to packets with addresses belonging to the loop back interface (127.0.0.0).
A screening router a packet filtering router. This is the simplest of the firewalls. A screening router, unlike an ordinary router, determines not only whether or not it can route a packet towards its destination, but also whether or not it should. "Should" or "should not" are determined by the site's security policy.
Using a screening router to do packet
filtering
Even though the word "filtering" seems to suggest no changes are made to the packet being examined, there are several well-known manipulations of packets.
"Basic Network Address Translation or Basic NAT is a method by which IP addresses are mapped from one group to another, transparent to end users. Network Address Port Translation, or NAPT is a method by which many network addresses and their TCP/UDP (Transmission Control Protocol/User Datagram Protocol) ports are translated into a single network address and its TCP/UDP ports. Together, these two operations, referred to as traditional NAT, provide a mechanism to connect a realm with private addresses to an external realm with globally unique registered addresses." [RFC 3022]
Address translation substitutes, in an IP packet, one IP address with another consistently. Suppose we have 20 machines, M10 to M19, with private addresses in the range of 192.168.17.10 to 192.168.17.29, but only two validly assigned IP addresses, say A == 130.108.18.111 and B == 130.108.19.222.
In static NAT, any two of the hosts, say MA, and MB statically chosen from the range of M10 to M19 can be given the privilege of communicating with hosts on the Internet by substituting with the A and B addresses when communicating with the Internet. No address translation occurs when MA and MB are communicating with others in the 192.168.*.* network. The NAT server records this "translation" in a table so that when replies to these packets are received, the NAT server knows where to redirect them. We should locate the NAT service on a secure machine where we can disable the NAT translation quickly if needed. Note that assigning the host machines M18 and M19 the IP addresses A and B would have made it impossible for hosts M10 to M17, with their private addresses, connect to A and B.
In dynamic NAT, the NAT server assigns the two addresses A and B that it controls to whichever of the hosts M10 through M19 is about to communicate with the Internet. DNAT is more complex than SNAT in that the NAT server must now decide when a host, say M6, is done communicating with the Internet so that the regular IP address, say B, assigned to it currently can be considered available for other Mx hosts.
Under what may be termed as strict NAT, with two addresses available, as in the above example, only two internal hosts can be communicating with the Internet at any time.
Masquerading (MASQ) substitutes a single IP address, say B, for an entire internal network. Masquerading is a special form of Source NAT. The MASQ server records the original source address of a packet and the destination address, and then replaces the source IP address as B and forwards it out to the Internet. When the remote host replies, the MASQ server is able to recognize this masqueraded packet and do the reverse translation.
Port forwarding refers to the systematic substitution of one port number for another in a packet. Obviously, this is relevant for TCP and UDP packets. Often, the port forwarding is coupled with address translation also. Port forwarding and transparent proxying are special forms of Destination NAT.
Packet filtering can be static by letting desired methods of connecting between the internal and external networks left open at all times. The advantages of static packet filtering are:
Because it does very little work outside of routing traffic, the overhead is extremely low, so near or at hardware speed traffic is likely. The disadvantages of static packet filtering are that it:
Dynamic packet filters open and close "doors" in the firewall based on header information in the data packet. Once a series of packets has passed through the "door" to it’s destination, the firewall closes the door.
Limitations of packet filters include:
Assume that our network consists of an internal network 192.168.17.0/24 (which we call "PRVT"), exposed servers in a separate network 130.108.17.0/24 (called "DMZ" for Demilitarized Zone), and a connection 130.108.17.1 to the Internet (called "EXTRN"). In the following, the interfaces eth0 are used for "outside" connections, and eth1 is used for "internal" connections, and 0-for-o 1-for-i are helpful mnemonic reminders.
eth1 and eth2 are located on the Packet Filter Box (PFB).
External Network (EXTRN)
|
|eth0
|130.108.127.1
---------------
| | Server Network (DMZ)
| PFB |------------------------------------------------
| |130.108.17.250 | | |
| |eth2 | | |
--------------- -------- ------- -------
|eth1 | MAIL | | DNS | | WWW |
|192.168.17.1 -------- ------- -------
| eth0 130.108.17.228 130.108.17.229 130.108.17.230
| eth1 192.168.17.228 192.168.17.229 192.168.17.230
|
|
Internal Network (PRVT)
On the DMZ, we have three separate machines named MAIL, DNS, and WWW, each with two NICs. We have the following security goals.
We will set the PFB as a Linux box in a sequence of three parts. Part 1 is contained in this article. Part 2 is described in the Firewalls article. Part 3 is described in the An Example Firewall Setup.
Linux kernels 2.4.x and later have built-in support for sophisticated filtering of packets. This support, called the The Linux Netfilter Architecture, is generally compiled as "loadable kernel modules" (LKM). The LKMs are inserted into the kernel address space using the insmod (or modprobe) utility. In what follows we are assuming that the Linux is properly configured for packet filtering and appropriate modules have been loaded. At a minimum, lsmod should list the ip_tables module. E.g., in the packet filtering script, we may have:
/sbin/insmod ip_tables /sbin/insmod ip_tables /sbin/insmod iptable_nat /sbin/insmod ip_nat_ftp /sbin/insmod ipt_LOG /sbin/insmod ipt_mac /sbin/insmod ipt_state /sbin/insmod ipt_MASQUERADE /sbin/insmod ip_conntrack /sbin/insmod ip_conntrack_ftp
The full pathname for ip_tables (and other modules) is of the form /lib/modules/2.4.21-0.2mdk/ kernel/net/ipv4/netfilter/ip_tables.o.gz where 2.4.21-0.2mdk is the kernel version string, and the extension .gz indicates that the module is stored as a compressed file.
There are internal data structures, called "firewall chains". Each of these chains is an ordered sequence of rules. Each rule examines the contents of a packet (typically only the headers) and decides on an action such as DROP the packet, or pass it on to the next rule, etc. These chains are interpreted (in the sense of compilers and interpreters) by a piece of code loosely called a hook. If a rule does not match the packet, the next rule in the chain is applied. Finally, when there are no more rules to apply, the kernel obeys the chain policy to decide what to do.
There is a command line program named iptables that inserts, deletes, reorders the rules in the chains.
A packet traverses the netfilter subsystem of Linux as shown in the diagram below. Having passed a few simple sanity checks (e.g., not truncated, IP checksum OK, not a promiscuous receive), packets enter the PRE_ROUTING chain. These packets go through the processing by conntrack, mangle, NAT modules that have hooked themeselves here as shown below each chain. The resulting packets move on to the routing code, which decides whether the packet is destined for another host, or a local process.
--->{PREROUTING}------>ROUTING----->{FORWARD}---------->{POSTROUTING}----->
Mangle | Filter ^ NAT(Src)
Conntrack | | Conntrack
NAT (Dst) | ROUTING
(QDisc) v |
{INPUT} {OUTPUT}
| Mangle, Filter ^ Mangle, Filter
| Conntrack | Conntrack
v | NAT(Dst)
If a packet destination is this host, it is sent to the INPUT hook, which may send the result to the local process (if any). If the packet's destination is another host instead, it is sent to the FORWARD hook. If the kernel does not have forwarding enabled, or it doesn't know how to forward the packet, the packet is dropped. If forwarding is enabled, the packet goes to the FORWARD chain. If it is ACCEPTed, it will move on to POST_ROUTING. The OUTPUT hook is called for packets that are created locally on this host. Routing occurs after this hook is called. Just before leaving the network interfaces of this machine, the packets go through the POST_ROUTING hook.
Kernel modules can register to process the packets at any of these hooks. The functions in the module read/write selected portions of the contents of a packet and can finally do one of five things:
A packet selection subsystem called "IP Tables" is built over the netfilter framework. The packet selection method is of three kinds.
The filter table hooks at INPUT, FORWARD and/or OUTPUT points. A filter does not make changes to a packets internals.
The `nat' table is fed packets from the PREROUTING (for non-local packets) and POSTROUTING. These are for destination and source alterations respectively. This table is different from the `filter' table, in that only the first packet of a new connection will traverse the table. The result of this traversal is then applied to all future packets in the same connection.
The packet mangling table (the `mangle' table) is used for changing portions of a packet. It hooks into netfilter at the PREROUTING and OUTPUT points.
Packet filtering should be set up on the PFB, of course. It should also be setup on the MAIL, DNS and WWW servers. To be even more careful, it should be setup on each of the machines in the private network. Below, we focus only on the PFB.
The command line program named iptables that inserts, deletes, reorders the rules in the chains has a complex syntax for its arguments. To completely understand it, study the tutorial on IP tables and the man pages. There are also many GUI front ends in the open source archives; see, e.g., ShoreWall. Our goal in this lecture is to explain iptables command only as needed in the setup of PFB. Note also that the order in which the rules appear in a chain matters. This order conflicts with that chosen here for pedagogy. So, in the end look at the final script.
Anti-spoofing The Linux kernel has built-in support for checking that IP addresses are not spoofed. We turn on the built-in anti IP-address spoofing for all interfaces as follows. The '*' expands to the names of each of the network interfaces such as lo, eth0 etc.
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f; done
There are several other such initializations. See An Example Firewall Setup.
Set filtering policies. Drop everything until firewall setup is complete.
iptables --flush INPUT iptables --flush OUTPUT iptables --flush FORWARD iptables --policy INPUT DROP iptables --policy OUTPUT DROP iptables --policy FORWARD DROP iptables -t nat --policy PREROUTING DROP iptables -t nat --policy POSTROUTING DROP
Set Up Interfaces This is usually done in the boot scripts. We must make sure the above steps are done before the interfaces are configured, to prevent packet leakage before the rules are set up.
Masquerading. All packets whose source address is in the range 192.168.17.0/24 are sent out of PFB with source address set to that of PFB by causing them to jump to the MASQUERADE chain.
iptables -t nat -A POSTROUTING -s 192.168.17.0/24 -j MASQUERADESource address of packets arriving on eth0 must not be a private address.
iptables -A FORWARD -i eth0 -s 192.168.0.0/16 -j DROP iptables -A FORWARD -i eth0 -s 172.16.0.0/12 -j DROP iptables -A FORWARD -i eth0 -s 10.0.0.0/8 -j DROP iptables -A FORWARD -i eth0 -s 127.0.0.0/8 -j DROP iptables -A FORWARD -i eth0 -s 255.255.255.255/32 -j DROP
At the inside NIC (eth1), allow only our address as source. We may have traitors among us!
iptables -A FORWARD -i eth1 -s ! 192.168.17.0/24 -j DROP iptables -A FORWARD -i eth2 -s ! 130.108.127.0/24 -j DROP
Packets with strange TCP flags should be dropped. The --tcp-flags takes two arguments, each can be a comma separated list of TCP flag names or ALL (referring all of them) and NONE. From the first list, a mask of bits is constructed. The second list lists those that should be a 1 for a match. The target is a chain named logdrop that logs the packet and then DROPs.
# XMAS/NULL packets iptables -A INPUT -p tcp --tcp-flags ALL ALL -j logdrop iptables -A INPUT -p tcp --tcp-flags ALL NONE -j logdrop iptables -A FORWARD -p tcp --tcp-flags ALL ALL -j logdrop iptables -A FORWARD -p tcp --tcp-flags ALL NONE -j logdrop
Packet Filtering for Through Packets We split the FORWARD chain into various user chains depending on source/dest interfaces; this breaks the problem down into manageable chunks.
iptables --new extrn-dmz iptables --new extrn-prvt iptables --new prvt-extrn iptables --new dmz-extrn
ACCEPTing standard error ICMPs is a common thing to do, so we create a chain for it.
iptables --new icmpchain
Set Up Jumps From FORWARD Chain Unfortunately, we only know (in the FORWARD chain) the outgoing interface. Thus, to figure out what interface the packet came in on, we use the source address (the anti-spoofing prevents address faking). Note that we log anything which doesn't match any of these (obviously, this should never happen).
iptables -A FORWARD -d ! 192.168.17.0/24 -i eth1 -j prvt-extrn iptables -A FORWARD -s 130.108.17.0/24 -i eth2 -j dmz-extrn iptables -A FORWARD -d 130.108.17.0/24 -i eth0 -j extrn-dmz iptables -A FORWARD -j DROP -l
Define the icmpchain Chain Packets which are one of the error ICMPs get ACCEPTed, otherwise, control will pass back to the calling chain. There are many more icmp types that should be carefully considered. See An Example Firewall Setup.
iptables -A icmpchain -p icmp --icmp-type destination-unreachable -j ACCEPT iptables -A icmpchain -p icmp --icmp-type time-exceeded -j ACCEPT iptables -A icmpchain -p icmp --icmp-type parameter-problem -j ACCEPT
All work should be carried out in Operating Systems and Internet Security (OSIS) Lab, 429 Russ. Use any of the PCs numbered 19 to 30. No other WSU facilities are allowed.
Objective: Setup a simple packet filter. Become familiar with iptables
This work was supported in part by NSF DUE-9951380.