mirror of https://github.com/tLDP/LDP
474 lines
20 KiB
XML
474 lines
20 KiB
XML
<!-- $Id$ -->
|
|
|
|
<chapter id="ch-packetfilter">
|
|
<title>Packet Filtering</title>
|
|
<para>
|
|
It is not an uncommon story today to hear how people were first exposed to
|
|
linux. Many people found linux an excellent and reliable
|
|
masquerading firewall in the mid-1990s and slowly became more
|
|
and more accustomed to working with linux as a result of the low total
|
|
cost of ownership.
|
|
</para>
|
|
<para>
|
|
The capabilities of packet filtering tools available under linux today
|
|
dwarfs that of early linux (<command>ipfwadm</command>, anybody?) yet
|
|
retains the reliability and expressive flexibility of the older tools.
|
|
</para>
|
|
<para>
|
|
For networks and machines directly connected to the Internet, packet
|
|
filtering is no longer an option, but a need. This chapter will introduce
|
|
the packet filtering tools available under kernels 2.2 and 2.4. Since
|
|
there is much available documentation on packet filtering, host protection
|
|
and masquerading with a packet filter, this chapter will refer liberally
|
|
to external resources.
|
|
</para>
|
|
<para>
|
|
This chapter begins with an
|
|
<link linkend="pf-intro">introduction to
|
|
and the history of packet filtering with linux</link>. After covering
|
|
some of the
|
|
<link linkend="pf-weakness">weaknesses of packet filtering</link>, it will
|
|
cover
|
|
<link linkend="pf-netfilter">the netfilter architecture</link>, and then
|
|
delve into
|
|
<link linkend="pf-netfilter-iptables">using
|
|
<command>iptables</command></link>. An introduction to the use of
|
|
<link linkend="pf-ipchains"><command>ipchains</command></link> will follow
|
|
along with introductions to
|
|
<link linkend="pf-host">host</link> and
|
|
<link linkend="pf-network">network protection</link>. The chapter will
|
|
close with an overview of
|
|
<link linkend="pf-further">further resources</link>.
|
|
</para>
|
|
<para>
|
|
</para>
|
|
<section id="pf-intro">
|
|
<title>Rationale for and Introduction to Packet Filtering</title>
|
|
<para>
|
|
Packet filtering refers to the technique of conditionally allowing
|
|
or denying packets entering or exiting a network or host based on
|
|
the characteristics of that packet. There are two fundamental types of
|
|
packet filters. A static packet filter is a set of rules against which
|
|
every packet is checked, and allowed or denied.
|
|
A dynamic packet filter keeps track of the connections currently passing
|
|
the firewall. This is usually described as a stateful or dynamic packet
|
|
filtering engine. Netfilter provides the capability for linux (2.4+) to
|
|
operate as a stateful packet filtering device.
|
|
</para>
|
|
<para>
|
|
For a brief digression, consider the term <wordasword>stateful packet
|
|
inspection</wordasword>. This term has been used in two distinctly
|
|
different meanings. At least one commercial security company
|
|
differentiates between stateful packet filtering and stateful packet
|
|
inspection
|
|
<footnote>
|
|
<para>
|
|
See the following
|
|
<ulink url="http://www.netmaster.com/products/ggos-dpf.pdf">PDF</ulink>
|
|
from NetMaster Digital Security. Although I may disagree with their
|
|
use of terms, I can appreciate their clear attempt to explain their
|
|
use of these two terms.
|
|
</para>
|
|
</footnote>.
|
|
Supposedly, a stateful packet inspection engine is able to examine the
|
|
contents of a packet and make a limited guess as to the legitimacy of
|
|
the application layer content. While I would call this an application
|
|
layer proxy, I do not use the product. For the purposes of this
|
|
documentation, the terms stateful packet inspection and stateful packet
|
|
filtering are synonomous.
|
|
</para>
|
|
<para>
|
|
Packet filtering, the network layer portion of a firewall solution, is
|
|
one part of a good security stance. As the embodiment and manifestation
|
|
of an organizational security policy for network layer traffic, the
|
|
packet filter restricts traffic flows between networks and hosts. There
|
|
is tremendous value from a security perspective in enforcing these
|
|
traffic flows, instead of allowing arbitrary traffic flow.
|
|
</para>
|
|
<para>
|
|
The use of packet filtering to enforce these traffic flows is not
|
|
restricted to routers and firewalls alone. Standalone servers and
|
|
workstations can use these same tools to protect themselves. There
|
|
are a couple of common approaches to packet filtering. Generally,
|
|
network security professionals subscribe to the notion that the
|
|
filtering policy should deny or drop all traffic and selectively allow
|
|
desired traffic. An alternate, more open, policy suggests allowing
|
|
everything, selectively blocking undesirable traffic.
|
|
</para>
|
|
<para>
|
|
The languages used in most packet filtering tools for describing IP
|
|
packets allow for a great deal of specifity when identifying traffic.
|
|
This specifity enables an administrator a great deal of flexibility for
|
|
protecting resources and limiting traffic flows.
|
|
</para>
|
|
<section id="pf-history">
|
|
<title>History of Linux Packet Filter Support</title>
|
|
<para>
|
|
Packet filtering under linux has a long history, punctuated by major
|
|
alterations in the packet filtering systems included in the kernel. In
|
|
the mid- and late-1990s, <command>ipfwadm</command> exposed the three
|
|
packet filtering chains of kernel 2.0 to the user: in, forward, and out.
|
|
Individual entries added to these chains would be traversed in order in
|
|
each ruleset. The first matching rule in each chain would be used, and
|
|
every packet passing through a router would traverse these three
|
|
chains.
|
|
</para>
|
|
<para>
|
|
With the advent of linux 2.2, users could create their own chains and
|
|
chain structures. The kernel architecture was different from that of
|
|
the earlier kernel, but from the user's perspective, the manner in
|
|
which the rules were written was only slightly different. Rule
|
|
chains, traversed rather like subroutines and manipulated with
|
|
<command>ipchains</command>, could be arbitrarily complex and nested.
|
|
The built-in packet filtering chains had names: input, output and
|
|
forward. The first matching rule in any chain called from one of the
|
|
built-in chains would be used. Every packet passing through a router
|
|
would traverse (at least) the three built-in rule chains. There is
|
|
backward compatible support for <command>ipfwadm</command> syntax via
|
|
a wrapper shell script which converts the command to an
|
|
<command>ipchains</command> syntax.
|
|
</para>
|
|
<para>
|
|
In kernel 2.4, the
|
|
<link linkend="pf-netfilter">netfilter architecture</link>
|
|
which provides functionality other than packet filtering, allows users
|
|
to create the arbitrary chains and chain structures similar to those
|
|
supported by linux 2.2. The built in chains are INPUT, FORWARD, and
|
|
OUTPUT. A major difference in the use of chains was introduced in
|
|
linux 2.4; packets passing through a router will traverse the FORWARD
|
|
chain only. User-defined <command>iptables</command> chains resemble
|
|
branches rather than subroutines. Under linux 2.4,
|
|
<command>ipchains</command> compatibility is maintained with a kernel
|
|
module. For <command>ipfwadm</command> compatibility, the kernel
|
|
module and the aforementioned wrapper shell script function
|
|
adequately.
|
|
</para>
|
|
<para>
|
|
The packet filtering support under linux has grown increasingly
|
|
complex and mature with successive kernels and development efforts on
|
|
the user space tools. The netfilter architecture of linux 2.4
|
|
represented a tremendous step forward in the packet filtering
|
|
capabilities of linux with support for stateful packet filtering.
|
|
</para>
|
|
</section>
|
|
</section>
|
|
<section id="pf-shortcomings">
|
|
<title>Limits and Weaknesses of Packet Filtering</title>
|
|
<para>
|
|
Although the functionality offered by linux kernels for protecting
|
|
network resources with packet filtering allows tremendously specific
|
|
network layer access control and auditing capability, it alone cannot
|
|
successfully and completely protect network resources. There are
|
|
weaknesses in and limits to the usefulness of packet filters.
|
|
</para>
|
|
<section id="pf-limits">
|
|
<title>Limits of the Usefulness of Packet Filtering</title>
|
|
<para>
|
|
In cases where a packet filter restricts access to a resource based on
|
|
the source IP address attempting to access that resource, the packet
|
|
filter cannot verify whether the packets originate from the real
|
|
device or from a host or router spoofing this source address.
|
|
A transparent proxy illustrates this problem perfectly. A transparent
|
|
proxy frequently runs on a masquerading or NAT host which is connected
|
|
to the Internet. This machine intercepts outbound connections for a
|
|
particular protocol (e.g, HTTP), and simulates the real server to the
|
|
client. The client may have a packet filter limiting outbound
|
|
connections to a single IP and port pair, but the transparent proxy
|
|
will still operate on the outbound connection.
|
|
</para>
|
|
<para>
|
|
This is an innocuous example, indeed. A potentially more threatening
|
|
example is an ssh server which accepts connections only from an IP
|
|
range. Any router between the two endpoints which can
|
|
<link linkend="adv-nonlocal-bind">spoof IP packets</link> will be able
|
|
to pass the packet filter, whether it is a stateful or a
|
|
static packet filter. This should underscore the importance of
|
|
solid application layer security in addition to the need for
|
|
judiciously employed packet filtering.
|
|
</para>
|
|
<para>
|
|
A packet filter makes no effort to validate the contents of a data
|
|
stream, so data passed over a packet filter may be bogus, invalid or
|
|
otherwise incorrect. The packet filter only verifies that the network
|
|
layer datagrams are correctly addressed and well-formed
|
|
<footnote>
|
|
<para>
|
|
In truth, there is some examination of data inside the network
|
|
layer datagram. Almost all packet filtering engines allow the
|
|
user to distinguish between the different IP protocol types, such
|
|
as GRE, TCP, UDP, ICMP, and even attributes of these datagrams and
|
|
segments. The important thing to realize is that a
|
|
<emphasis>packet filter</emphasis> makes no effort to examine the
|
|
data stream.
|
|
</para>
|
|
</footnote>.
|
|
Many security devices, such as firewalls, include support for proxies,
|
|
which are application aware. These are security mechanisms which can
|
|
validate data streams. Proxies are often integrated with packet
|
|
filters for a tight network layer and application layer firewall.
|
|
</para>
|
|
<para>
|
|
Tunnels are one of the most common ways to subvert a packet filter.
|
|
They come in wide varieties: ssh tunnels which allow users to
|
|
transport TCP sessions into or out of a network; GRE tunnels, which
|
|
allow arbitrary packets to be encapsulated in an IP packet; UDP
|
|
tunnels; VPN tunnels; TAP/TUN tunnels; and application layer transport
|
|
tunnels, such as RPC over HTTP/HTTPS. Some of these tunnels are very
|
|
difficult to prevent with packet filtering, while others are trivial to
|
|
block.
|
|
</para>
|
|
<para>
|
|
Perhaps it is apparent, why **FIXME** adversarial relationship between
|
|
packet filters and content....limitation of packet filter....hence
|
|
proxies...blah blah blah.
|
|
</para>
|
|
<para>
|
|
Use of ICMP, when to block ICMP; tunneling through lax packet filters
|
|
with ICMP (trinoo, ICMPchat).
|
|
</para>
|
|
<para>
|
|
Another area of network security which is not addressed by packet
|
|
filtering is encryption. Encryption can be used at a number of
|
|
different layers in a networked environment. Compare IPSec, encrypted
|
|
packets, with Secure Sockets Layer (SSL), which encrypts a single
|
|
application layer session. IPSec operates at layer 3, while SSL
|
|
operates above layer 4. Packet filtering does not directly address
|
|
the issue of encryption in any way. Both are tools used in an
|
|
ongoing effort to maintain and secure a network.
|
|
</para>
|
|
<para>
|
|
There are a few good starting place for those needing
|
|
guidelines on securing machines. First, the
|
|
<ulink url="http://tldp.org/HOWTO/Security-Quickstart-HOWTO/index.html">Security
|
|
Quickstart HOWTO</ulink> is a good place to begin. There is also the
|
|
<ulink url="http://tldp.org/HOWTO/Security-HOWTO/">Security
|
|
HOWTO</ulink>. These and several other good general security
|
|
resources are also available via
|
|
<ulink url="http://www.linuxsecurity.com/docs/">linuxsecurity.com's
|
|
documentation area</ulink>.
|
|
</para>
|
|
<para>
|
|
Much of the previous discussion applies to packet filtering
|
|
in general, and linux suffers from the same limitations of packet
|
|
filtering. It is folly to assume that a good packet filter makes a
|
|
network immune from security issues.
|
|
</para>
|
|
</section>
|
|
<section id="pf-weakness">
|
|
<title>Weaknesses of Packet Filtering</title>
|
|
<para>
|
|
The weaknesses of static (or stateless) packet filters and stateful
|
|
packet filters are different in a few ways. Stateless packet filters
|
|
frequently block SYN scans of networks, but ....
|
|
</para>
|
|
<para>
|
|
Stateless packet filters. (cf. iptables connection tracking), cf. state
|
|
vs. stateless discussion.
|
|
</para>
|
|
<para>
|
|
</para>
|
|
<para>
|
|
confounded application layer protocols like FTP, H323
|
|
</para>
|
|
<para>
|
|
Because of the nature of connection tracking and state awareness,
|
|
stateful packet filters are vulnerable to resource exhaustion and
|
|
deliberate attempts to trip rate-limiting features.
|
|
</para>
|
|
<para>
|
|
DoS on connection tracking packet filters
|
|
DoS on rate limiters ?
|
|
</para>
|
|
<para>
|
|
</para>
|
|
<para>
|
|
</para>
|
|
</section>
|
|
<section id="pf-weakness-stateless">
|
|
<title>Complex Network Layer Stateless Packet Filters</title>
|
|
<para>
|
|
</para>
|
|
</section>
|
|
</section>
|
|
<section id="pf-icmp">
|
|
<title>General Packet Filter Requirements</title>
|
|
<para>
|
|
minimum ICMP required to meet the networking needs; xref PMTU discussion
|
|
</para>
|
|
<para>
|
|
source quench
|
|
</para>
|
|
<para>
|
|
parameter problem
|
|
</para>
|
|
<para>
|
|
inbound destination unreachable
|
|
</para>
|
|
<para>
|
|
outbound destination unreachable fragmentation needed
|
|
</para>
|
|
<para>
|
|
optional: echo request and echo reply
|
|
</para>
|
|
<para>
|
|
optional: outbound destination unreachable
|
|
</para>
|
|
<para>
|
|
optional: time exceeded
|
|
</para>
|
|
</section>
|
|
<section id="pf-netfilter">
|
|
<title>The Netfilter Architecture</title>
|
|
<para>
|
|
packet filtering engine in kernel 2.2 (skip history, adequately
|
|
documented elsewhere)
|
|
</para>
|
|
<para>
|
|
packet filtering engine as part of netfilter in kernel 2.4, backwards
|
|
compatible support for ipchains
|
|
</para>
|
|
<para>
|
|
differences between the packet traversal in ipchains and iptables.
|
|
link to Stef Coene's KPTD (kernel 2.4). Anybody know of a link to a
|
|
KPTD for kernel 2.2?
|
|
</para>
|
|
<para>
|
|
</para>
|
|
<para>
|
|
</para>
|
|
<section id="pf-netfilter-iptables">
|
|
<title>Packet Filtering with <command>iptables</command></title>
|
|
<para>
|
|
selecting on interface
|
|
</para>
|
|
<para>
|
|
different chains, INPUT, OUTPUT, FORWARD
|
|
</para>
|
|
<para>
|
|
big picture; how chains are traversed
|
|
</para>
|
|
<para>
|
|
selecting on interface -i -o
|
|
</para>
|
|
<para>
|
|
targets; ACCEPT, DROP, REJECT....
|
|
</para>
|
|
</section>
|
|
</section>
|
|
<section id="pf-ipchains">
|
|
<title>Packet Filtering with <command>ipchains</command></title>
|
|
<para>
|
|
the three builtin chains, input, output, forward
|
|
</para>
|
|
<para>
|
|
policy per chain, see targets
|
|
</para>
|
|
<para>
|
|
jumping from chain to chain, -j $TARGET; wher TARGET=chain
|
|
</para>
|
|
<para>
|
|
the big picture; how chains are traversed
|
|
</para>
|
|
<para>
|
|
targets (other than chains) ACCEPT, DENY, REJECT....
|
|
</para>
|
|
<para>
|
|
selecting on interface
|
|
</para>
|
|
<para>
|
|
</para>
|
|
<para>
|
|
</para>
|
|
<section id="pf-ipchains-mangling">
|
|
<title>Packet Mangling with <command>ipchains</command></title>
|
|
<para>
|
|
</para>
|
|
<para>
|
|
</para>
|
|
<para>
|
|
</para>
|
|
</section>
|
|
</section>
|
|
<section id="pf-host">
|
|
<title>Protecting a Host</title>
|
|
<para>
|
|
Host protection in the past was typically performed with application
|
|
layer checks on the originating IP or hostname. This was (and still is)
|
|
frequently accomplished with libwrap, which verifies whether or not to
|
|
allow a connection based on the contents of the system wide
|
|
configuration files <filename>/etc/hosts.allow</filename> and
|
|
<filename>/etc/hosts.deny</filename>.
|
|
</para>
|
|
<para>
|
|
Host protection is one part of protecting a host, by preventing inbound
|
|
packets from reaching higher layers. This is no substitute for tight
|
|
application layer security. Strong network and host-level packet
|
|
filters mitigate a host's exposure when it is connected to
|
|
a network.
|
|
</para>
|
|
<para>
|
|
</para>
|
|
<example id="ex-pf-iptables-reject">
|
|
<title>Blocking a destination and using the <option>REJECT</option>
|
|
target, cf. <xref linkend="ex-tools-ip-route-add-prohibit"/></title>
|
|
<programlisting>
|
|
<prompt>[root@masq-gw]# </prompt><userinput>iptables -I FORWARD -p tcp -d 209.10.26.51 --dport 22 -j REJECT</userinput>
|
|
<prompt>[root@tristan]# </prompt><userinput>ssh 209.10.26.51</userinput>
|
|
<computeroutput>ssh: connect to address 209.10.26.51 port 22: Connection refused</computeroutput>
|
|
<prompt>[root@masq-gw]# </prompt><userinput>tcpdump -nnq -i eth2</userinput>
|
|
<computeroutput>tcpdump: listening on eth2
|
|
22:16:59.111947 192.168.99.35.51991 > 209.10.26.51.22: tcp 0 (DF)
|
|
22:16:59.112270 192.168.99.254 > 192.168.99.35: icmp: 209.10.26.51 tcp port 22 unreachable (DF) [tos 0xc0]</computeroutput>
|
|
</programlisting>
|
|
</example>
|
|
<para>
|
|
</para>
|
|
</section>
|
|
<section id="pf-network">
|
|
<title>Protecting a Network</title>
|
|
<para>
|
|
</para>
|
|
<para>
|
|
</para>
|
|
<para>
|
|
</para>
|
|
<para>
|
|
</para>
|
|
</section>
|
|
<section id="pf-further">
|
|
<title>Further Resources</title>
|
|
<para>
|
|
The use of linux packet filtering features is mature and
|
|
well-documented in many places throughout the Internet. One of the most
|
|
thorough introductions to the use of <command>iptables</command> has
|
|
been collected by Oskar Andreasson at his
|
|
<ulink url="http://iptables-tutorial.frozentux.net/">Iptables
|
|
tutorial</ulink>. For further reference material on the use of
|
|
<command>iptables</command> consult this resource.
|
|
</para>
|
|
<para>
|
|
For those continuing to use <command>ipchains</command> the
|
|
<ulink url="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html">ipchains
|
|
HOWTO</ulink> courtesy of TLDP provides an introduction to the world of
|
|
<command>ipchains</command>.
|
|
</para>
|
|
<para>
|
|
For kernel 2.4, understanding the sequence of packet mangling, filtering
|
|
and network address translation is key. The
|
|
<ulink url="http://www.docum.org/stef.coene/qos/kptd/">kernel packet
|
|
traveling diagram</ulink> provides a visual representation of the path a
|
|
packet takes through the kernel. Here you will see the netfilter hooks,
|
|
traffic control, and routing stages. A similar picture of kernel 2.4's
|
|
packet path is available in a single page PDF entitled
|
|
<ulink url="http://open-source.arkoon.net/kernel/kernel_net.png">Linux
|
|
Kernel 2.4 Packet handling</ulink>.
|
|
</para>
|
|
<para>
|
|
See also
|
|
<xref linkend="links-ipchains"/> and
|
|
<xref linkend="links-netfilter"/> in the appendices for a more complete
|
|
set of references and links.
|
|
</para>
|
|
</section>
|
|
</chapter>
|