106 lines
5.6 KiB
HTML
106 lines
5.6 KiB
HTML
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<meta name="Author" content="JC Pollman">
|
|
<meta name="GENERATOR" content="Mozilla/4.61 [en] (X11; I; Linux 2.2.11 i686) [Netscape]">
|
|
</head>
|
|
<body bgcolor=#ffffff>
|
|
|
|
<center><b><font size=+1>IP Chains</font></b></center>
|
|
|
|
<p>In order to understand how to configure a firewall, you need to understand
|
|
how the data moves from one computer to another. The best explanation I
|
|
have seen comes from the<a href="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/IPCHAINS-HOWTO">
|
|
IP Chains HOWTO</a>:
|
|
<blockquote>All traffic through a network is sent in the form of packets.
|
|
For example, downloading this package (say it's 50k long) might cause you
|
|
to receive 36 or so packets of 1460 bytes each, (to pull numbers at random).</blockquote>
|
|
|
|
<blockquote>The start of each packet says where it's going, where it came
|
|
from, the type of the packet, and other administrative details. This
|
|
start of the packet is called the header. The rest of the packet,
|
|
containing the actual data being transmitted, is usually called the body.
|
|
<p>Some protocols, such TCP, which is used for web traffic, mail, and remote
|
|
logins, use the concept of a `connection' -- before any packets with actual
|
|
data are sent, various setup packets (with special headers) are exchanged
|
|
saying `I want to connect', `OK' and `Thanks'. Then normal packets are
|
|
exchanged.
|
|
<p>A packet filter is a piece of software which looks at the header of
|
|
packets as they pass through, and decides the fate of the entire packet.
|
|
It might decide to deny the packet (i.e.. discard the packet as if it had
|
|
never received it), accept the packet (i.e.. let the packet go through),
|
|
or reject the packet (like deny, but tell the source of the packet that
|
|
it has done so).
|
|
<p>Under Linux, packet filtering is built into the kernel, 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>One problem is that the same tool (``ipchains'') is used to control
|
|
both masquerading and transparent proxying, although these are notionally
|
|
separate from packet filtering (the current Linux implementation blurs
|
|
these together unnaturally, leaving the impression that they are closely
|
|
related).</blockquote>
|
|
So, ipchains looks at the to, from, and port request in the header of the
|
|
packet and then looks at its rules to decide what to do with it. Examining
|
|
a rule is the easiest way to understand what it is doing. Here is what
|
|
I use for the pop3 part of my firewall:
|
|
<p><tt>ipchains -A input -p tcp -j ACCEPT -s 192.168.124.0/24 -d 0.0.0.0/0
|
|
110</tt>
|
|
<br><tt>ipchains -A input -p tcp -j DENY -d 0.0.0.0/0 -s 192.168.124.0/24
|
|
110</tt>
|
|
<p><b>-A input:</b> append this rule to the other input rules (i.e. do
|
|
not erase the other rules)
|
|
<br><b>-p tcp:</b> using the tcp protocol
|
|
<br><b>ACCEPT/DENY:</b> exactly what they say
|
|
<br><b>-s: </b>the source of the data packet
|
|
<br><b>-d:</b> the destination of the data packet. 0.0.0.0/0 means: from
|
|
anywhere, and 192.168.124.0/24 are my network addresses.
|
|
<p>The 1st rule above says: accept any data from the local network going
|
|
anywhere else for port 110. The second rule says: deny any packet
|
|
coming from anywhere else going to the local network on port 110.
|
|
<p>This sounds simple, but what if you do not know what your ip address
|
|
is - like when you dial up to the internet? And setting up each port can
|
|
take a while. Fortunately there is help. <a href="mailto:manuka@nerdherd.net">Ian
|
|
Hall-Beyer</a> has put together 3<a href="http://www.nerdherd.org/ipchains/ipchains-firewall-1.6.tar.gz">
|
|
outstanding scripts</a> that you can put right
|
|
into your box with a minimum of configuring. Here is his Readme file:
|
|
<br>
|
|
<blockquote>1) Pick the script that is appropriate to your particular network
|
|
setup:
|
|
<p> <a href="masquerade">masquerade</a>:
|
|
<br> For systems on an internal RFC1918 network.
|
|
<p> <a href="standalone">standalone:</a>
|
|
<br> Single machines connected to the net, wanting strong
|
|
security.
|
|
<p> <a href="routable">routable:</a>
|
|
<br> For systems gatewaying a standard network with a
|
|
routable subnet.
|
|
<p>2) Copy the appropriate script into /usr/sbin. Edit your script variables
|
|
<br> as follows:
|
|
<p> LOCALIF: http://linux.freediskspace.com/files/42180/(Masquerade/Standalone)
|
|
<br> This is the interface with which you are connected
|
|
to the IP network.
|
|
<br> For modems and serial port ISDN TA's, this is usually
|
|
ppp0. Otherwise,
|
|
<br> use the ethernet interface your access device is
|
|
connected to.
|
|
<p> INTERNALNET: (Routable/Masquerade)
|
|
<br> Set this to the *network* address and hostmask of
|
|
the network you're
|
|
<br> gatewaying. bitmasks or dotquadded masks are acceptable.
|
|
<p>3) If you're on a dialup, add an entry into ip-up to call the script
|
|
after
|
|
<br> you've connected. If you're on a permanent connection,
|
|
call it from
|
|
<br> rc.local.
|
|
<p><font color="#330000">4) Change the permissions on the file:</font><font color="#330000"></font>
|
|
<p><i><font color="#330000">
|
|
chmod 755 /etc/masquerade[Enter]</font></i></blockquote>
|
|
After you edit the files, run the one you need. For the Masquerade/Standalone,
|
|
I recommend you run it from /etc/ppp/ip-up (or ip-up.local for Redhat
|
|
based systems.) Ian is working on a making it even easier with<a href="http://www.nerdherd.org/ipchains/">
|
|
perl and a gtk interface</a>.
|
|
</body>
|
|
</html>
|