mirror of https://github.com/tLDP/LDP
399 lines
16 KiB
Plaintext
399 lines
16 KiB
Plaintext
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
|
|
|
|
<article>
|
|
|
|
<artheader>
|
|
<title>IPTables HOWTO</title>
|
|
|
|
<author>
|
|
<firstname>Matt</firstname>
|
|
<surname>Wright</surname>
|
|
<affiliation>
|
|
<orgname><ulink url="http://www.consultmatt.co.uk">Matt Wright Consulting</ulink></orgname>
|
|
<address>
|
|
<email>matt@consultmatt.co.uk</email>
|
|
</address>
|
|
</affiliation>
|
|
</author>
|
|
|
|
<pubdate>2001-11-21</pubdate>
|
|
|
|
<revhistory>
|
|
<revision>
|
|
<revnumber>v0.1</revnumber>
|
|
<date>2001-11-21</date>
|
|
<authorinitials>mww</authorinitials>
|
|
<revremark>
|
|
Initial writing began.
|
|
</revremark>
|
|
</revision>
|
|
</revhistory>
|
|
|
|
<abstract>
|
|
<para>
|
|
This document describes the main functions of the Netfilter Packet
|
|
filter (IPTables) included in the 2.4.x series kernels.
|
|
</para>
|
|
</abstract>
|
|
|
|
</artheader>
|
|
|
|
<sect1 id="intro">
|
|
<title>Introduction</title>
|
|
<para>
|
|
I felt the need to write this HOWTO because of, what I thought, is the poor
|
|
level of documentation of implementing Packet Filtering firewalls using the 2.4.x Netfilter packet filter. The HOWTO covers using native IPTables commands (ie. not using the ipchains.o) to implement a packet-filter based firewall and the various supported types of NAT.
|
|
</para>
|
|
|
|
<sect2 id="copyright">
|
|
<title>Copyright and License</title>
|
|
<para>
|
|
This document is Copyright 2001 by Matt Wright. Permission is granted
|
|
to copy, distribute and/or modify this document under the terms of
|
|
the GNU Free Documentation License, Version 1.1 or any later version
|
|
published by the Free Software Foundation; with no Invariant
|
|
Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A
|
|
copy of the license is available at
|
|
<ulink url="http://www.gnu.org/copyleft/fdl.html">http://www.gnu.org/copyleft/fdl.html</ulink>
|
|
</para>
|
|
|
|
<para>Send feedback to
|
|
<ulink url="mailto:matt@consultmatt.co.uk"><citetitle>matt@consultmatt.co.uk</citetitle></ulink>.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="author">
|
|
<title>About the author</title>
|
|
|
|
<para> My name is Matt Wright. I'm 16 year-old student in Blackburn,
|
|
Lancashire. I'm a freelance Linux consultant. I am the proud owner of
|
|
a Duron 950Mhz (all I could easily afford) with 256MB SDRAM, Voodoo 4
|
|
Video Card, ATI All-in-Wonder Pro Video Card. I also have a 266Mhz Cyrix
|
|
that runs my USB ADSL connection, of which if you are reading this from
|
|
<ulink url="http://www.consultmatt.co.uk">http://www.consultmatt.co.uk</ulink>
|
|
you will be using. </para>
|
|
|
|
<para>
|
|
You can find me at <ulink url="http://www.consultmatt.co.uk">www.consultmatt.co.uk</ulink>. Or at <ulink url="mailto:matt@consultmatt.co.uk">matt@consultmatt.co.uk</ulink>.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="greetz">
|
|
<title>Acknowledgements</title>
|
|
<para><emphasis>TODO: Insert greetz here</emphasis></para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="whatis">
|
|
<title>What is IPTables</title>
|
|
<para>IPtables (known as Netfilter) was written by Paul Russell and the other
|
|
members of the <ulink url="http://netfilter.samba.org">Netfiler Project
|
|
Team</ulink>. It was meant as a replacement for IPChains that was implemented
|
|
in the 2.2.x series kernels. It offers true 1:1 NAT capabilities, Packet
|
|
filtering and connection tracking.</para>
|
|
|
|
<para>One major upshot of this is that due to the implementation of connection
|
|
tracking you can allow incoming connections by whether or not they relate to
|
|
an established connection. There is still some need for helper modules for
|
|
some conenction types. (FTP and IRC at the moment)</para>
|
|
</sect1>
|
|
|
|
<sect1 id="req">
|
|
<title>Requirements</title>
|
|
<para>You only need a couple of things to get IPTables going, these include:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>A 2.4.x series kernel with the Netfilter modules compiled.
|
|
(I will deal with the Netfilter code as modules but feel free to compile
|
|
them in and ignore the module information.)</para></listitem>
|
|
<listitem><para>The IPTables source code, get it from <ulink
|
|
url="http://netfilter.samba.org">The Netfilter Project</ulink>
|
|
</para></listitem>
|
|
<listitem><para>This HOWTO <emphasis role="strong">does not</emphasis>
|
|
cover compiling and/or installing IPTables. Usually this is pre-installed
|
|
with a 2.4.x distro and if not then please consult the Netfilter website
|
|
for more information.</para></listitem>
|
|
<listitem><para>Basic knowledge about networking; ports, packets, etc.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="commands">
|
|
<title>Essential IPTables commands</title>
|
|
<para>There are tens upon tens of commands and switches for IPTables, this
|
|
section is a must read it shows you the vital commands for use in this HOWTO.
|
|
They are listed below:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>-t <table>: This specifies the table to work on. If
|
|
-t is ommited then the "filter" table is specified.</para></listitem>
|
|
<listitem><para>-L <chain>: List all rules in the specified chain.
|
|
If the chain is not specified it lists all chains and rules in the
|
|
current table.</para></listitem>
|
|
<listitem><para>-F <chain>: Flushes the specified chain of all
|
|
rules. Again, if no chain is specified it flushes all rules in all chains
|
|
in the current table.</para></listitem>
|
|
<listitem><para>-X <chain>: This removes the specified user-defined
|
|
chain. If no chain is specified it deletes all user-defined chains in the
|
|
current table. (Note: You cannot delete a chain referenced to by another
|
|
rule.)</para></listitem>
|
|
<listitem><para>-N <chain>: This creates a new user-defined chain
|
|
for you to add rules to.</para></listitem>
|
|
<listitem><para>-A <chain> <rule>: This appends a rule to the
|
|
end of the specified chain. Rules are explained later.</para></listitem>
|
|
<listitem><para>-D <chain> <number>: Deletes the rule at
|
|
position "number" in the specified chain.</para></listitem>
|
|
<listitem><para>-P <chain> <policy>: Changes the policy for
|
|
"chain" to "policy".</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>That is the main commands outlined, the rest of the commands are
|
|
well documented in the man page IPTABLES(8). It also contains the flags
|
|
for useage in rules. I won't list them here because there are too many.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="tables">
|
|
<title>Tables, Chains and the like</title>
|
|
<para>There are two main definitons that need to be set out here. The first
|
|
is a table. Tables contain a set of chains, either built-in or user-defined.
|
|
The main two tables you will encounter are the "filter" table and the "nat"
|
|
table.</para>
|
|
|
|
<para>Chains are lists of rules that a packet traverses. When a packet enters
|
|
a chain the packet is checked against each criteria, if it is met then the
|
|
packet's fate is determined by the "target" flag. (Explained later in detail).
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>The Filter Table</title>
|
|
<para>I am going to explain each table and chain before I show a diagram of the
|
|
overall system. The is so you can understand what each part does without having
|
|
to refer back to this section while looking at the diagram.</para>
|
|
|
|
<para>The first table we meet is the filter table. This is the table you
|
|
encounter if you type <command>iptables -L</command> (-L means list). If you
|
|
actually enter this command you will encounter a display similar to this:
|
|
</para>
|
|
|
|
<screen>
|
|
[root@enterprise matt]# iptables -L
|
|
|
|
Chain INPUT (policy ACCEPT)
|
|
target prot opt source destination
|
|
|
|
Chain FORWARD (policy ACCEPT)
|
|
target prot opt source destination
|
|
|
|
Chain OUTPUT (policy ACCEPT)
|
|
target prot opt source destination
|
|
</screen>
|
|
|
|
<sect3>
|
|
<title>The INPUT chain</title>
|
|
|
|
<para>We'll start with the INPUT chain first. When packets enter the system
|
|
they are checked for routing, if the packet is inbound to the local machine
|
|
(in this case to <emphasis>enterprise</emphasis>) then the packet is sent
|
|
down the INPUT chain.</para>
|
|
|
|
<para>In it's current state the chain is wide open. This is due to the policy.
|
|
When the Tables are initalised each policy is set to ACCEPT, the policy defines
|
|
what happens when a packet meets none of the rules in the chain. To use an
|
|
analogy it is what happens if it drops off the end of the chain.</para>
|
|
|
|
<para>The case in question has the policy ACCEPT. This is in fact a target that
|
|
can be used in a rule, so as not to repeat myself targets are explain in a
|
|
later section.</para>
|
|
|
|
<para>The INPUT chain is the chain that you will most want to secure on your
|
|
machine. This is the rule to use to block (or open) ports on the local machine.
|
|
Anything accepted in the chain will make it to your network server daemons,
|
|
anything dropped will not.</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>The FORWARD chain</title>
|
|
<para>The FORWARD chain is also an important chain, especially if you plan on
|
|
masquerading or NAT'ing your conenctions. As with the INPUT chain the packets
|
|
appear here after routing but when the routing specifies that the packet is
|
|
bound for a machien on the network other than itself.</para>
|
|
|
|
<para>For instance, if you are using Masquerading and a incoming packet from
|
|
the internet enters the network interface the packet would be processed by the
|
|
routing information and enter the FORWARD chain as it is bound for another
|
|
machine. If the packet is accepted (or is accpeted by policy) then it proceeds
|
|
to the destination (and possibly into its INPUT chain if its running Linux), if
|
|
however it is dropped then it proceeds no further and it is dumped into the
|
|
nearest blackhole.</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>The OUTPUT chain</title>
|
|
<para>The OUTPUT chain is the final built-in chain in the filter table. It
|
|
governs the outgoing packets once they have been transmitted into the network
|
|
layer by the computer daemons. As with the other chains anythign accepted will
|
|
be allowed passage out to the big-wide-world and dropped packets appear
|
|
alongside their rejected brothers (or sisters).</para>
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>The NAT table</title>
|
|
<para>The NAT (Network Address Translation) table is not accessible by default.
|
|
Firstly, if you have the netfilter code compiled as modules then you may have
|
|
to do a <command>modprobe iptable_nat</command>. Secondly to access any of the
|
|
chains in the NAT table iptables must be invoked with the <command>-t
|
|
nat</command> option. Eg:</para>
|
|
|
|
<para><command>iptables -t nat -L</command></para>
|
|
|
|
<para>This table is the other super-handy table that we will use. All packets
|
|
traverse the chains in here before entering the filter table and before the
|
|
packets from the filter table leave the computer. I think a little more
|
|
explanation here is in order. The typical default NAT tables output is listed
|
|
below:</para>
|
|
|
|
<screen>
|
|
[root@enterprise matt]# iptables -t nat -L
|
|
|
|
Chain PREROUTING (policy ACCEPT)
|
|
target prot opt source destination
|
|
|
|
Chain POSTROUTING (policy ACCEPT)
|
|
target prot opt source destination
|
|
|
|
Chain OUTPUT (policy ACCEPT)
|
|
target prot opt source destination
|
|
</screen>
|
|
|
|
<para>I shall concentrate on the PREROUTING and POSTROUTING chains in this
|
|
table (as I'm not yet sure on what the OUTPUT is for, please mail me if you
|
|
can help).</para>
|
|
|
|
<sect3>
|
|
<title>The PREROUTING chain</title>
|
|
<para>The PREROUTING chain....you remember where I said before that all the
|
|
packets are routed then enter the FORWARD/INPUT/OUTPUT chains?? Well the
|
|
PREROUTING chain is where the packets traverse <emphasis role="strong">BEFORE
|
|
</emphasis> they get routed. If for instance you wanted to make all packets
|
|
destined for port 80 on the local machine (10.0.0.1) actually appear on port
|
|
81 of 10.0.0.2 then you would insert the DNAT rule here.</para>
|
|
|
|
<para>This is also the best place to check for simple spoofing, things like
|
|
local, private IP addresses (10.0.0.x, 192.0.0.x, etc) appearing on the
|
|
internet side of your machine is obviously wrong and can be dropped quicker
|
|
than you can say "distributed denial-of-service attack".</para>
|
|
|
|
<para>Finally, this is the ONLY place that incoming NAT (Destination NAT, DNAT)
|
|
can be performed. This is so the packets can be mangled to force then down the
|
|
FORWARD chain instead of the INPUT where they would be lost.</para>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>The POSTROUTING chain</title>
|
|
<para>This chain is also very important, (else why would I mention it!!), it
|
|
governs the handling of packets after they have been routed and are about to be
|
|
spat out of an network adapter.</para>
|
|
|
|
<para>The major use for this chain is to allow IP masquerading or Source NAT.
|
|
There is a slight difference. IP Masquerading is made specially for all us
|
|
people with Dynamic IP address. When the interface is taken down the IP Masq
|
|
tries to make sure all connections are closed, this is logical is it is
|
|
unlikely you will have the same IP when the adapter comes live again.</para>
|
|
|
|
<para>Source NAT is different, it leave ports open. This is made for Static IP
|
|
based conenctions, if for some reason your interface dies then when it goes
|
|
live again it will have to same IP. So, if there have been no timeouts and all
|
|
applications still _assume_ they are connected they carry on as usual.</para>
|
|
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>The Diagram!!</title>
|
|
<screen>
|
|
________ _____ _________
|
|
Incoming / \ / \ / \ Outgoing
|
|
-->|PREROUTING|--->|FORWARD|-------|POSTROUTING|----->
|
|
\________/ \_____/ \_________/
|
|
| |
|
|
v ____
|
|
___ / \
|
|
/ \ |OUTPUT|
|
|
|INPUT| \____/
|
|
\___/ ^
|
|
| |
|
|
-------> Local Process -------->
|
|
|
|
</screen>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Packet Filtering</title>
|
|
<para>This is where you find out how to firewall off you local machine. It will
|
|
involved some of the theory from above to I adive reading it before proceeding.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Target (-j) ACCEPT,DROP,REJECT,etc</title>
|
|
<para>When I was talking above about accepting, dropping and the like I wasn't
|
|
just using a phrase. The -j flag in rules specifies what target the rule has,
|
|
in layman speak (I know I needed it) it's what happens when the packet matches
|
|
the rule concerned. If you had the following command:</para>
|
|
|
|
<para><command>iptables -A INPUT -p tcp --dport 80 -j ACCEPT</command></para>
|
|
<para>This would instruct any packet that has made it to that rule and that is
|
|
on port 80 to be accepted.</para>
|
|
|
|
<sect3>
|
|
<title>Target: ACCEPT</title>
|
|
<para>This is what is says, it allows a matching packet to continue unhindered.
|
|
Also, once a packet has been accpeted it no longer traverses the chain. So if
|
|
the above chain allows a packet it is universally allowed. A moral is in this
|
|
tale!! If you have any mission critical filters to be tested on all packets
|
|
before any are allowed then put them at the top of the chain</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Target: DROP</title>
|
|
<para>This is the exact opposite of ACCEPT, if the packet matches a filter that
|
|
targets to a DROP then the packet is dumped into oblivion and is never seen
|
|
again. Please beware, DROP is a stealth DROP. If a packet is DROPed then NO
|
|
response is returned to say it failed, you program will just sit around till it
|
|
times out.</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Target: REJECT</title>
|
|
<para>This is similar to DROP, firstly in the netfilter code it is created as
|
|
a seperate module (ipt_REJECT.o) and as such needs to be at the very least
|
|
compiled if not modprobe'd. Compared to DROP the only difference it a REJECTed
|
|
packet has a response sent to the originator saying that it failed. I tend to
|
|
use DROP as its stealthy but REJECT has its uses.</para>
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Default Policies</title>
|
|
<para>Policies, Policies!! This could be a major security hole on you machine.
|
|
The default policies come set to ACCEPT andif you've read the above stuff then
|
|
you will find that this means ANY packet can get in, out or through your
|
|
network. </para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
</article> |