First of all unpack the iptables package.
Here, we have used the iptables 1.2.6a package and a
vanilla 2.4 kernel. Unpack as usual, using bzip2 -cd
iptables-1.2.6a.tar.bz2 | tar -xvf - (this can also be
accomplished with the tar -xjvf
iptables-1.2.6a.tar.bz2, which should do pretty much the same as
the first command. However, this may not work with older versions of
tar). The package should now be unpacked properly into
a directory named iptables-1.2.6a. For
more information read the iptables-1.2.6a/INSTALL
file which contains pretty good information on compiling and getting the
program to run.
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.
 | 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.
To carry out this step we do something like this from the root
of the iptables package:
|
make pending-patches KERNEL_DIR=/usr/src/linux/
The variable KERNEL_DIR should point to the actual place that
your kernel source is located at. Normally this should be
/usr/src/linux/ but this may vary, and most probably you
will know yourself where the kernel source is available.
The above command 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 is by
doing the following:
make most-of-pom KERNEL_DIR=/usr/src/linux/
The above command would ask about installing parts of what in
Netfilter world is called patch-o-matic, 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
all of the patch-o-matic
stuff you will need to run the following command:
make patch-o-matic KERNEL_DIR=/usr/src/linux/
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 patch-o-matic
etc.
| 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
patch-o-matic that you may want to look at so there's
nothing bad in just running the commands and see what they contain.
|
After this you are finished doing the
patch-o-matic 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 iptables if you feel like it, though.
Continue by compiling the iptables user-land application. To
compile iptables you issue a simple command that looks like
this:
make KERNEL_DIR=/usr/src/linux/
The user-land application should now compile properly. If not,
you are on your own, or you could subscribe to the Netfilter mailing list, where you have the
chance of asking for help with your problems. There are a few things
that might go wrong with the installation of iptables,
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.
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:
make install KERNEL_DIR=/usr/src/linux/
Hopefully everything should work in the program now. To use any
of the changes in the iptables 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 INSTALL file in
the source which contains excellent information on the subject of
installation.
Red Hat 7.1 comes preinstalled with a 2.4.x kernel that has
Netfilter and iptables
compiled in. It also contains all the basic user-land programs and
configuration files that are needed to run it. However, the Red Hat people
have disabled the whole thing by using the backward compatible
ipchains module. Annoying to say the least, and a lot
of people keep asking different mailing lists why
iptables doesn't work. So, let's take a brief look at how
to turn the ipchains module off and how to install
iptables instead.
| The default Red Hat 7.1 installation today comes with a
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
iptables.
|
First of all you will need to turn off the ipchains modules
so it won't start in the future. To do this, you will need to change some
filenames in the /etc/rc.d/ directory-structure. The
following command should do it:
chkconfig --level 0123456 ipchains off
By doing this we move all the soft links that points to the
/etc/rc.d/init.d/ipchains 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.
However, to stop the service from actually running right now we need to run
another command. This is the service command which can be
used to work on currently running services. We would then issue the following
command to stop the ipchains service:
service ipchains stop
Finally, to start the iptables 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:
2. Multiuser without NFS or the same as 3 if there is no networking.
3. Full multiuser mode, i.e. the normal run-level to run in.
5. X11. This is used if you automatically boot into Xwindows.
To make iptables run in these run-levels we would do the
following commands:
chkconfig --level 235 iptables on
The above commands would in other words make the iptables
service run in run-level 2, 3 and 5. If you'd like the
iptables 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.
To activate the iptables service, we just run the following
command:
service iptables start
There are no rules in the iptables script.
To add rules to an Red Hat 7.1 box, there is two common ways. Firstly, you
could edit the /etc/rc.d/init.d/iptables 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 iptables-save command and
then have it loaded automatically by the rc.d scripts.
First we will describe the how to set up
iptables by cutting and pasting to the
iptables 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
iptables. 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
iptables RPM package.
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
iptables, 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
iptables-save command. You could either use it
normally, i.e. iptables-save > /etc/sysconfig/iptables,
which would save the rule-set to the file
/etc/sysconfig/iptables. This file is automatically
used by the iptables rc.d script to restore the rule-set
in the future. The other way is to save the script by doing
service iptables save, which would save the script
automatically to /etc/sysconfig/iptables. The next
time you reboot the computer, the iptables rc.d script
will use the command iptables-restore to restore the
rule-set from the save-file /etc/sysconfig/iptables.
Do not intermix these two methods, since they may heavily damage each
other and render your firewall configuration useless.
When all of these steps are finished, you can deinstall the currently
installed ipchains and iptables packages.
This because we don't want the system to mix up the new
iptables user-land application with the old preinstalled
iptables applications. This step is only necessary if you
are going to install iptables from the source package.
It's not
unusual for 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 iptables package.
To carry out the deinstallation, do as follows:
rpm -e iptables
And why keep ipchains lying around if you
won't be using it any more? Removing it is done the same way as with the
old iptables binaries, etc:
rpm -e ipchains
After all this has been completed, you will have finished with
the update of the iptables 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.
