D7net Mini Sh3LL v1
| Current File : //media/../../usr/share/doc/logsave/../make/../iptables/html/packet-filtering-HOWTO-3.html |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.73">
<TITLE>Linux 2.4 Packet Filtering HOWTO: So What's A Packet Filter?</TITLE>
<LINK HREF="packet-filtering-HOWTO-4.html" REL=next>
<LINK HREF="packet-filtering-HOWTO-2.html" REL=previous>
<LINK HREF="packet-filtering-HOWTO.html#toc3" REL=contents>
</HEAD>
<BODY>
<A HREF="packet-filtering-HOWTO-4.html">Next</A>
<A HREF="packet-filtering-HOWTO-2.html">Previous</A>
<A HREF="packet-filtering-HOWTO.html#toc3">Contents</A>
<HR>
<H2><A NAME="s3">3.</A> <A HREF="packet-filtering-HOWTO.html#toc3">So What's A Packet Filter?</A></H2>
<P>A packet filter is a piece of software which looks at the
<EM>header</EM> of packets as they pass through, and decides the fate
of the entire packet. It might decide to <B>DROP</B> the packet
(i.e., discard the packet as if it had never received it),
<B>ACCEPT</B> the packet (i.e., let the packet go through), or
something more complicated.</P>
<P>Under Linux, packet filtering is built into the kernel (as a kernel
module, or built right in), and there are a few trickier things we can
do with packets, but the general principle of looking at the headers
and deciding the fate of the packet is still there.</P>
<H2><A NAME="ss3.1">3.1</A> <A HREF="packet-filtering-HOWTO.html#toc3.1">Why Would I Want to Packet Filter?</A>
</H2>
<P>Control. Security. Watchfulness.</P>
<P>
<DL>
<DT><B>Control:</B><DD>
<P>when you are using a Linux box to connect your internal
network to another network (say, the Internet) you have an opportunity
to allow certain types of traffic, and disallow others. For example,
the header of a packet contains the destination address of the packet,
so you can prevent packets going to a certain part of the outside
network. As another example, I use Netscape to access the Dilbert
archives. There are advertisements from doubleclick.net on the page,
and Netscape wastes my time by cheerfully downloading them.
Telling the packet filter not to allow any packets to or from the
addresses owned by doubleclick.net solves that problem (there are
better ways of doing this though: see Junkbuster).</P>
<DT><B>Security:</B><DD>
<P>when your Linux box is the only thing between the
chaos of the Internet and your nice, orderly network, it's nice to
know you can restrict what comes tromping in your door. For example,
you might allow anything to go out from your network, but you might be
worried about the well-known `Ping of Death' coming in from malicious
outsiders. As another example, you might not want outsiders
telnetting to your Linux box, even though all your accounts have
passwords. Maybe you want (like most people) to be an observer on the
Internet, and not a server (willing or otherwise). Simply don't let
anyone connect in, by having the packet filter reject incoming packets
used to set up connections.</P>
<DT><B>Watchfulness:</B><DD>
<P>sometimes a badly configured machine on the local
network will decide to spew packets to the outside world. It's nice
to tell the packet filter to let you know if anything abnormal occurs;
maybe you can do something about it, or maybe you're just curious by
nature.</P>
</DL>
</P>
<H2><A NAME="filter-linux"></A> <A NAME="ss3.2">3.2</A> <A HREF="packet-filtering-HOWTO.html#toc3.2">How Do I Packet Filter Under Linux?</A>
</H2>
<P>Linux kernels have had packet filtering since the 1.1 series. The
first generation, based on ipfw from BSD, was ported by Alan Cox in
late 1994. This was enhanced by Jos Vos and others for Linux 2.0; the
userspace tool `ipfwadm' controlled the kernel filtering rules. In
mid-1998, for Linux 2.2, I reworked the kernel quite heavily, with the
help of Michael Neuling, and introduced the userspace tool `ipchains'.
Finally, the fourth-generation tool, `iptables', and another kernel
rewrite occurred in mid-1999 for Linux 2.4. It is this iptables which
this HOWTO concentrates on.</P>
<P>You need a kernel which has the netfilter infrastructure in it:
netfilter is a general framework inside the Linux kernel which other
things (such as the iptables module) can plug into. This means you
need kernel 2.3.15 or beyond, and answer `Y' to CONFIG_NETFILTER in
the kernel configuration.</P>
<P>The tool <CODE>iptables</CODE> talks to the kernel and tells it what
packets to filter. Unless you are a programmer, or overly curious,
this is how you will control the packet filtering.</P>
<H3>iptables</H3>
<P>The <CODE>iptables</CODE> tool inserts and deletes rules from the kernel's
packet filtering table. This means that whatever you set up, it will
be lost upon reboot; see
<A HREF="#permanent">Making Rules Permanent</A> for how to make sure they are restored the next time Linux
is booted.</P>
<P><CODE>iptables</CODE> is a replacement for <CODE>ipfwadm</CODE> and
<CODE>ipchains</CODE>: see
<A HREF="packet-filtering-HOWTO-8.html#oldstyle">Using ipchains and ipfwadm</A> for how to painlessly
avoid using iptables if you're using one of those tools.</P>
<H3><A NAME="permanent"></A> Making Rules Permanent</H3>
<P>Your current firewall setup is stored in the kernel, and thus will
be lost on reboot. You can try the iptables-save and iptables-restore
scripts to save them to, and restore them from a file.</P>
<P>The other way is to put the commands required to set up your rules
in an initialization script. Make sure you do something intelligent
if one of the commands should fail (usually `exec /sbin/sulogin').</P>
<HR>
<A HREF="packet-filtering-HOWTO-4.html">Next</A>
<A HREF="packet-filtering-HOWTO-2.html">Previous</A>
<A HREF="packet-filtering-HOWTO.html#toc3">Contents</A>
</BODY>
</HTML>
AnonSec - 2021 | Recode By D7net