iptables tutorial 1_1_19.htm

这是我对防火墙技术的一些见解

<H2 class=SECTION><A name=COMPILINGUSERAPPS>2.3.1. Compiling the user-land 
applications</A></H2>
<P>First of all unpack the <B class=COMMAND>iptables</B> package. Here, we have 
used the <I class=EMPHASIS>iptables 1.2.6a</I> package and a vanilla 2.4 kernel. 
Unpack as usual, using <B class=COMMAND>bzip2 -cd iptables-1.2.6a.tar.bz2 | tar 
-xvf -</B> (this can also be accomplished with the <B class=COMMAND>tar -xjvf 
iptables-1.2.6a.tar.bz2</B>, which should do pretty much the same as the first 
command. However, this may not work with older versions of <B 
class=COMMAND>tar</B>). The package should now be unpacked properly into a 
directory named <TT class=COMPUTEROUTPUT>iptables-1.2.6a</TT>. For more 
information read the <TT class=FILENAME>iptables-1.2.6a/INSTALL</TT> file which 
contains pretty good information on compiling and getting the program to run. 
</P>
<P>After this, there you have the option of configuring and installing extra 
modules and options etcetera for the kernel.The step described here will only 
check and install standard patches that are pending for inclusion to the kernel, 
there are some even more experimental patches further along, which may only be 
available when you carry out other steps. </P>
<DIV class=NOTE>
<P></P>
<TABLE class=NOTE width="100%" border=0>
  <TBODY>
  <TR>
    <TD vAlign=top align=middle width=25><IMG alt=Note hspace=5 src=""></TD>
    <TD vAlign=top align=left>
      <P>Some of these patches are highly experimental and may not be such a 
      good idea to install them. However, there are heaps of extremely 
      interesting matches and targets in this installation step so don't be 
      afraid of at least looking at them. </P>
      <P>To carry out this step we do something like this from the root of the 
      iptables package: </P></TD></TR></TBODY></TABLE></DIV>
<P><B class=COMMAND>make pending-patches KERNEL_DIR=/usr/src/linux/</B> </P>
<P>The variable <TT class=VARNAME>KERNEL_DIR</TT> should point to the actual 
place that your kernel source is located at. Normally this should be <TT 
class=FILENAME>/usr/src/linux/</TT> but this may vary, and most probably you 
will know yourself where the kernel source is available. </P>
<DIV class=NOTE>
<P></P>
<TABLE class=NOTE width="100%" border=0>
  <TBODY>
  <TR>
    <TD vAlign=top align=middle width=25><IMG alt=Note hspace=5 src=""></TD>
    <TD vAlign=top align=left>
      <P>This only asks about certain patches that are just about to enter the 
      kernel anyway. There might be more patches and additions that the 
      developers of Netfilter are about to add to the kernel, but is a bit 
      further away from actually getting there. One way to install these are by 
      doing the following: </P></TD></TR></TBODY></TABLE></DIV>
<P><B class=COMMAND>make most-of-pom KERNEL_DIR=/usr/src/linux/</B> </P>
<P>The above command would ask about installing parts of what in Netfilter world 
is called <B class=COMMAND>patch-o-matic</B>, but still skip the most extreme 
patches that might cause havoc in your kernel. Note that we say ask, because 
that's what these commands actually do. They ask you before anything is changed 
in the kernel source. To be able to install <I class=EMPHASIS>all</I> of the 
<SPAN class=SYSTEMITEM>patch-o-matic</SPAN> stuff you will need to run the 
following command: </P>
<P><B class=COMMAND>make patch-o-matic KERNEL_DIR=/usr/src/linux/</B> </P>
<P>Don't forget to read the help for each patch thoroughly before doing 
anything. Some patches will destroy other patches while others may destroy your 
kernel if used together with some patches from <SPAN 
class=SYSTEMITEM>patch-o-matic</SPAN> etc. </P>
<DIV class=NOTE>
<P></P>
<TABLE class=NOTE width="100%" border=0>
  <TBODY>
  <TR>
    <TD vAlign=top align=middle width=25><IMG alt=Note hspace=5 src=""></TD>
    <TD vAlign=top align=left>
      <P>You may totally ignore the above steps if you don't want to patch your 
      kernel, it is in other words not necessary to do the above. However, there 
      are some really interesting things in the <SPAN 
      class=SYSTEMITEM>patch-o-matic</SPAN> that you may want to look at so 
      there's nothing bad in just running the commands and see what they 
      contain. </P></TD></TR></TBODY></TABLE></DIV>
<P>After this you are finished doing the <SPAN 
class=SYSTEMITEM>patch-o-matic</SPAN> parts of installation, you may now compile 
a new kernel making use of the new patches that you have added to the source. 
Don't forget to configure the kernel again since the new patches probably are 
not added to the configured options. You may wait with the kernel compilation 
until after the compilation of the user-land program <B 
class=COMMAND>iptables</B> if you feel like it, though. </P>
<P>Continue by compiling the <B class=COMMAND>iptables</B> user-land 
application. To compile <B class=COMMAND>iptables</B> you issue a simple command 
that looks like this: </P>
<P><B class=COMMAND>make KERNEL_DIR=/usr/src/linux/</B> </P>
<P>The user-land application should now compile properly. If not, you are on 
your own, or you could subscribe to the <A 
href="http://www.jollycom.ca/iptables-tutorial/iptables-tutorial.html#NETFILTERLIST">Netfilter 
mailing list</A>, where you have the chance of asking for help you with your 
problems. There are a few things that might go wrong with the installation of <B 
class=COMMAND>iptables</B>, so don't panic if it won't work. Try to think 
logically about it and find out what's wrong, or get someone to help you. </P>
<P>If everything has worked smoothly, you're ready to install the binaries by 
now. To do this, you would issue the following command to install them: </P>
<P><B class=COMMAND>make install KERNEL_DIR=/usr/src/linux/</B> </P>
<P>Hopefully everything should work in the program now. To use any of the 
changes in the <B class=COMMAND>iptables</B> user-land applications you should 
now recompile and reinstall your kernel and modules, if you hadn't done so 
before. For more information about installing the user-land applications from 
source, check the <TT class=FILENAME>INSTALL</TT> file in the source which 
contains excellent information on the subject of installation. </P></DIV>
<DIV class=SECTION>
<HR>

<H2 class=SECTION><A name=INSTALLRH71>2.3.2. Installation on Red Hat 
7.1</A></H2>
<P>Red Hat 7.1 comes preinstalled with a 2.4.x kernel that has <SPAN 
class=SYSTEMITEM>Netfilter</SPAN> and <B class=COMMAND>iptables</B> compiled in. 
It also contains all the basic user-land programs and configuration files that 
is needed to run it. However, the Red Hat people have disabled the whole thing 
by using the backward compatible <B class=COMMAND>ipchains</B> module. Annoying 
to say the least, and a lot of people keep asking different mailing lists why <B 
class=COMMAND>iptables</B> don't work. So, let's take a brief look at how to 
turn the ipchains module off and how to install <B class=COMMAND>iptables</B> 
instead. </P>
<DIV class=NOTE>
<P></P>
<TABLE class=NOTE width="100%" border=0>
  <TBODY>
  <TR>
    <TD vAlign=top align=middle width=25><IMG alt=Note hspace=5 src=""></TD>
    <TD vAlign=top align=left>
      <P>The default Red Hat 7.1 installation today comes with an hopelessly old 
      version of the user-space applications, so you might want to compile a new 
      version of the applications as well as install a new and custom compiled 
      kernel before fully exploiting <B class=COMMAND>iptables</B>. 
  </P></TD></TR></TBODY></TABLE></DIV>
<P>First of all you will need to turn off the <B class=COMMAND>ipchains</B> 
modules so it won't start in the future. To do this, you will need to change 
some filenames in the <TT class=FILENAME>/etc/rc.d/</TT> directory-structure. 
The following command should do it: </P>
<P><B class=COMMAND>chkconfig --level 0123456 ipchains off</B> </P>
<P>By doing this we move all the soft links that points to the <TT 
class=FILENAME>/etc/rc.d/init.d/ipchains</TT> script to K92ipchains. The first 
letter which per default would be S, tells the initscripts to start the script. 
By changing this to K we tell it to Kill the service instead, or to not run it 
if it was not previously started. Now the service won't be started in the 
future. </P>
<P>However, to stop the service from actually running right now we need to run 
another command. This is the <B class=COMMAND>service</B> command which can be 
used to work on currently running services. We would then issue the following 
command to stop the <B class=COMMAND>ipchains</B> service: </P>
<P><B class=COMMAND>service ipchains stop</B> </P>
<P>Finally, to start the <B class=COMMAND>iptables</B> service. First of all, we 
need to know which run-levels we want it to run in. Normally this would be in 
run-level 2, 3 and 5. These run-levels are used for the following things: </P>
<P>
<P></P>
<UL>
  <LI>
  <P>2. Multiuser without NFS or the same as 3 if there is no networking. </P>
  <LI>
  <P>3. Full multiuser mode, i.e. the normal run-level to run in. </P>
  <LI>
  <P>5. X11. This is used if you automatically boot into Xwindows. </P></LI></UL>
<P></P>
<P>To make <B class=COMMAND>iptables</B> run in these run-levels we would do the 
following commands: </P>
<P><B class=COMMAND>chkconfig --level 235 iptables on</B> </P>
<P>The above commands would in other words make the <B 
class=COMMAND>iptables</B> service run in run-level 2, 3 and 5. If you'd like 
the <B class=COMMAND>iptables</B> service to run in some other run-level you 
would have to issue the same command in those. However, none of the other 
run-levels should be used, so you should not really need to activate it for 
those run-levels. Level 1 is for single user mode, i.e, when you need to fix a 
screwed up box. Level 4 should be unused, and level 6 is for shutting the 
computer down. </P>
<P>To activate the <B class=COMMAND>iptables</B> service, we just run the 
following command: </P>
<P><B class=COMMAND>service iptables start</B> </P>
<P>There are no rules in the <B class=COMMAND>iptables</B> script. To add rules 
to an Red Hat 7.1 box, there is two common ways. Firstly, you could edit the <TT 
class=FILENAME>/etc/rc.d/init.d/iptables</TT> script. This would have the 
undesired effect of deleting all the rules if you updated the iptables package 
by RPM. The other way would be to load the rule-set and then save it with the <B 
class=COMMAND>iptables-save</B> command and then have it loaded automatically by 
the rc.d scripts. </P>
<P>First we will describe the how to set up <B class=COMMAND>iptables</B> by 
cutting and pasting to the <B class=COMMAND>iptables</B> init.d script. To add 
rules that are to be run when the computer starts the service, you add them 
under the start) section, or in the start() function. Note, if you add the rules 
under the start) section don't forget to stop the start() function in the start) 
section from running. Also, don't forget to edit a the stop) section either 
which tells the script what to do when the computer is going down for example, 
or when we are entering a run-level that doesn't require <B 
class=COMMAND>iptables</B>. Also, don't forget to check out the restart section 
and condrestart. Note that all this work will probably be trashed if you have, 
for example, Red Hat Network automatically update your packages. It may also be 
trashed by updating from the <B class=COMMAND>iptables</B> RPM package. </P>
<P>The second way of doing the set up would require the following: First of all, 
make and write a rule-set in a shell script file, or directly with <B 
class=COMMAND>iptables</B>, that will meet your requirements, and don't forget 
to experiment a bit. When you find a set up that works without problems, or as 
you can see without bugs, use the <B class=COMMAND>iptables-save</B> command. 
You could either use it normally, i.e. <B class=COMMAND>iptables-save &gt; 
/etc/sysconfig/iptables</B>, which would save the rule-set to the file <TT 
class=FILENAME>/etc/sysconfig/iptables</TT>. This file is automatically used by 
the <B class=COMMAND>iptables</B> rc.d script to restore the rule-set in the 
future. The other way is to save the script by doing <B class=COMMAND>service 
iptables save</B>, which would save the script automatically to <TT 
class=FILENAME>/etc/sysconfig/iptables</TT>. The next time you reboot the 
computer, the <B class=COMMAND>iptables</B> rc.d script will use the command <B 
class=COMMAND>iptables-restore</B> to restore the rule-set from the save-file 
<TT class=FILENAME>/etc/sysconfig/iptables</TT>. Do not intermix these two 
methods, since they may heavily damage each other and render your firewall 
configuration useless. </P>
<P>When all of these steps are finished, you can deinstall the currently 
installed <B class=COMMAND>ipchains</B> and <B class=COMMAND>iptables</B> 
packages. This because we don't want the system to mix up the new <B 
class=COMMAND>iptables</B> user-land application with the old preinstalled <B 
class=COMMAND>iptables</B> applications. This step is only necessary if you are 
going to install <B class=COMMAND>iptables</B> from the source package. It's not 
unusual that the new and the old package to get mixed up, since the rpm based 
installation installs the package in non-standard places and won't get 
overwritten by the installation for the new <B class=COMMAND>iptables</B> 
package. To carry out the deinstallation, do as follows: </P>
<P><B class=COMMAND>rpm -e iptables</B> </P>
<P>And why keep <B class=COMMAND>ipchains</B> lying around if you won't be using 
it any more? Removing it is done the same way as with the old <B 
class=COMMAND>iptables</B> binaries, etc: </P>
<P><B class=COMMAND>rpm -e ipchains</B> </P>
<P>After all this has been completed, you will have finished with the update of 
the <B class=COMMAND>iptables</B> package from source, having followed the 
source installation instructions. None of the old binaries, libraries or include 
files etc should be lying around any more. </P></DIV></DIV></DIV>
<DIV class=CHAPTER>
<HR>

<H1><A name=TRAVERSINGOFTABLES>Chapter 3. Traversing of tables and 
chains</A></H1>
<P>In this chapter we'll discuss how packets traverse the different chains, and 
in which order. We will also discuss the order in which the tables are 
traversed. We'll see how valuable this is later on, when we write our own 
specific rules. We will also look at the points which certain other components, 
that also are kernel dependent, enter into the picture. Which is to say the 
different routing decisions and so on. This is