I have written this HOWTO because I didnīt find a similiar document describing
how to set up a firewall which is using IP Masquerading, diald AND dynamic
assigned IP addresses via PPP. The rc.firewall script I wrote however
can be used without diald and with direct connections, often known as
"leased lines". The handling will be described later.
Of course there are various documents describing one or the other issue but not altogether. So I decided to document the way I did it not only for me but the whole Linux community.
Please don't ask me general firewall, IP masquerading or diald related
questions. There are various documents and mailinglists on these subjects (see
Required Knowledge). But feel free to
contact me for rc.firewall* related questions or hints!
I developed and tested the scripts on RedHat 5.2 on intel based PCs with kernel 2.0.36 (ipfwadm) and 2.2.9 (ipchains). Since various distributions should handle startup very similiar there should be no problem using the shell scripts with them.
A version for the newly available kernel 2.2.x is also included but does not make use of the new features introduced with ipchains. This will be added in a future version.
The diald version I use is 0.16.5a. With RedHat there are 2 rpms called
diald-0.16.5a-1.i386.rpm and diald-config-0.16.5a-1.i386.rpm
which can be found at
ftp://contrib.redhat.com.
If you are using SUSE up to version 6.0 you should get the actual diald version because the shipped one is rather old. You can find a rpm at http://rufus.w3.org/.
The ipfwadm version is 2.3.0 and is included in almost every distribution.
The ipchains version is 1.3.8 and should be included in the actual distributions making use of kernel 2.2.x, or can be downloaded from http://rufus.w3.org/ or from RedHatīs contributed site ftp://contrib.redhat.com/.
Here I will briefly describe the types of firewalls, how they work, what they are for and what they are NOT for.
A packet-filtering firewall is used to catch all packets it gets and check them against user-defined rules whether they are allowed to pass the firewall or not.
These rules work on the protocol level thus it is called a packet filter. They consist of a set of IP addresses, protocol names and port numbers. Filtering is done only with these information but not with any included data in the packet. This means that you can only allow or disallow services based on IP addresses and port numbers, e.g. you can allow web access through the packet-filtering firewall using internal IP addresses on port 80, the http port number, but you can not ensure that there is no malicious web site getting access to the pc by exploiting security leaks of the browsers because the packet filter is not able to check any data sent to or from a malicious web site.
Packet-filtering firewalls are normally used in environments with high security needs to block unwanted protocols/services. In addition the packet-filtered stream of data will be forwarded to an application filtering firewall either on the same box or on a second one to try to filter malicious data contents out of the stream.
Often a packet-filtering firewall is implemented on an access router connected to the internet and to the internal net. Obviously linux can do this for you ;)
For a dial-up user a packet-filtering firewall may be sufficient but can not handle already installed trojans like back orifice etc. because these programs are transparent to the firewall.
As stated above application-filtering firewalls make use of a pre-filtered data stream of a packet-filtering firewall to concentrate on the content of the packets and not on the service itself.
With application-filtering firewalls it is possible to filter out a lot of bad content e.g. in web pages, emails or ftp downloaded files. It is possible to check for viruses sent via email or ftp BEFORE the recipient gets it, sending her/him and the adminitrator a message of the intrusion. Also harddisk spoofing via malicious web pages can be detected and blocked BEFORE it occurs and destroys data or sends private information to an unknown address.
In normal configurations the firewalls will be connected on a special LAN segment called the De-Militarized Zone (DMZ) which means that only the firewalls are located in this segment and nothing else. This is done because if someone from outside hacks the packet filter she/he must also hack the application filter to get access on the internal network(s). Sometimes a www and/or ftp server will be connected to the DMZ if it should be accessible on the internet without the need to open the internal network for external access.
Application-Filters make use of special designed programs - so-called proxies - replacing the original unsecure ones with more secure and with special firewall-featured ones. Under linux most often the TIS Firewall Toolkit is used (fwtk, http://www.tis.com/). It replaces various services, adds the possibility for accounting and preserves consistency of the whole system. This is done by proxying the data-stream through the firewall toolkitīs proxies.
Here is a small drawing how packet and application-filtering firewalls work together:
/----------\
| |
| Internet |
| |
\----------/
:
:
/-----\
| ISP |
\-----/
:
:
+-------------+
| Packet |
| Filter |
|-------------|
| Application |
| Filter |
+-------------+
| +---------+
| +--------| |
| | | WWW/FTP |
DMZ | | | Server |
|-----------------| | |
| +---------+
|
/--------\
| Router |
\--------/
|
|
|-----------------|
| |
| |
+-----+ +-----+
| PC1 | | PC2 | ...
+-----+ +-----+
DMZ = De-Militarized Zone
More information on application-filtering firewalls will be added in a future version.
The ipfwadm tool developed by X/OS Experts in Open Systems BV, Amsterdam, The Netherlands, is designed to implement four kinds of rule sets:
The following sketch shows the context between the four rule sets (taken from the ipfwadm documentation):
To Local System From Local System
^ v
| \------/ |
+-------->-------|DeMasq|----------->-----------+
| /------\ |
^ v
| /----\ |
+-------->--------|Forw|------------>-----------+
| \----/ |
| | \----/ |
^ +----->-----|Masq|----->---+
| /----\ v
| |
/----\ /---\
| In | |Out|
\----/ \---/
| |
+----+ +----+
|Acct| |Acct|
+----+ +----+
| |
^ v
From Network Device To Network Device
This part was completely taken from the IPCHAINS-HOWTO. Thanks to Paul Russell, <Paul.Russell@rustcorp.com.au>.
The kernel starts with three lists of rules; these lists are called
firewall chains or just chains. The three chains are
called input, output and forward. When a packet comes
in (say, through the Ethernet card) the kernel uses the input
chain to decide its fate. If it survives that step, then the kernel
decides where to send the packet next (this is called routing).
If it is destined for another machine, it consults the forward
chain. Finally, just before a packet is to go out, the kernel
consults the output chain.
A chain is a checklist of rules. Each rule says `if the packet header looks like this, then here's what to do with the packet'. If the rule doesn't match the packet, then the next rule in the chain is consulted. Finally, if there are no more rules to consult, then the kernel looks at the chain policy to decide what to do. In a security-conscious system, this policy usually tells the kernel to reject or deny the packet.
For ASCII-art fans, this shown the complete path of a packet coming into a machine.
ACCEPT/
REDIRECT ACCEPT
--> C --> S --> ______ --> D --> ~~~~~~~~ --> local ------> _______ -->
h -> a |input | e {Routing } | __|____ -->->|output |
e | n |Chain | m {Decision} | |forward| | |Chain |
c | i |______| a ~~~~~~~~ | |Chain | | |_______|
k | t | s | | |_______| | |
s | y | q | | | | |
u | | v e v | | | v
m | | DENY/ r Local Process| v | DENY/
| | v REJECT a |------- DENY/ | REJECT
| |DENY d | REJECT |
v | e -------+---------------------
DENY| |
------------------------------
Here is a blow-by-blow description of each stage:
This is a test that the packet hasn't been corrupted in some way. If it has, it is denied.
There is actually one of these sanity checks before each firewall chain, but the input chain's is the most important. Some malformed packets might confuse the rule-checking code, and these are denied here (a message is printed to the syslog if this happens).
This is the first firewall chain against which the
packet will be tested. If the verdict of the chain is not DENY
or REJECT, the packet continues on.
If the packet is a reply to a previously
masqueraded packet, it is demasqueraded, and skips straight to the
output chain. If you don't use IP Masquerading, you can mentally
erase this from the diagram.
The destination field is examined by the routing code, to decide if this packet should go to a local process (see Local process below) or forwarded to a remote machine (see forward chain below).
A process running on the machine can receive packets after the Routing Decision step, and can send packets (which go through the output then input chains with interface set to `lo' if they are destined for a local process, otherwise they only traverse the output chain). This is inter-process chain traversal isn't fully shown on the diagram, as it is too icky.
If the packet was not created by a local process, then the forward chain is checked, otherwise the packet goes straight to the output chain.
This chain is traversed for any packets which are attempting to pass through this machine to another.
This chain is traversed for all packets just before they are sent out.
In this paragraph I will give a brief overview of the required information/prerequisits to run the firewall successfully. More details on a single item can be found in the HOWTO belonging to it.
Before trying to set up the linux box as a firewall you should have a working linux system and you should be able to connect to your ISP (either via a dial-up ppp connection or directly via a leased line) and successfully use any service like www, ftp, email etc. on the internet from the linux box.
Then you should set up all your other PCs to at a minimum be able to ping the linux box, that includes setting the appropriate IP addresses (I recommend using addresses of the private ip pool, see IP Masquerading), subnet masks, default gateway and name server entries and of course have your PCs physically connected to your network.
If all this works just fine, go on reading.
Attention: Don't use make mrproper as sometimes read to be
done before compiling the kernel! This command prevents successful compile
of the firewall part! If you have used it, you'll have to reinstall
kernel-headers either from tar.gz or from the rpm
(recommended for RedHat and other rpm based distributions using the rpm
option --force).
Here are the kernel options to be compiled in to get firewall/masquerading support in the kernel:
Donīt be scared of any EXPERIMENTAL items, they work very well and often much better than some "final-declared" software on other operating systems >=)
Put in everything else you want to have in your kernel and recompile it. Don't forget to compile and install the modules!
Edit /etc/lilo.conf according to your new kernel and run
/sbin/lilo if using lilo as your boot loader (more information can be
found in the Kernel-HOWTO.
Attention: Don't use make mrproper as sometimes read to be
done before compiling the kernel! This command prevents successful compile
of the firewall part! If you have used it, you'll have to reinstall
kernel-headers either from tar.gz or from the rpm
(recommended for RedHat and other rpm based distributions using the rpm
option --force).
Here are the kernel options to be compiled in to get firewall/masquerading support in the kernel:
Donīt be scared of any EXPERIMENTAL items, they work very well and often much better than some "final-declared" software on other operating systems >=)
Put in everything else you want to have in your kernel and recompile it. Don't forget to compile and install the modules!
Edit /etc/lilo.conf according to your new kernel and run
/sbin/lilo if using lilo as your boot loader (more information can be
found in the Kernel-HOWTO.
After compiling and installing the kernel the firewall has to be secured. Normally there is no need to run any service like ftpd, httpd or something like that on the firewall. This could result in backdoors for intruders!
Even inetd should be deactivated resulting in a system which can only be administered via the console directly but not from the net via telnet/rlogin. If for some reason inetd canīt be disabled only allow as less services to be started by inetd, especially disable finger and all r-services like rlogin, rexec, etc.!
To completely disable inetd on a RedHat based system remove any entry
in /etc/rc.d/rc3.d named Sxxinetd where xx is a
number between 00 and 99. For other distributions take a look at the
documentation and look for "start scripts" or "boot scripts".
To disable certain services edit /etc/inetd.conf and comment out
every service you do not really need, and be very restrictiv in allowing
services here!
Diald can be used to automatically dial the ISP either via modem or ISDN. It can be configured to only allow certain types of network packets open the connection, e.g. if someone opens a web page located anywhere on the internet while e.g. netbios datagrams (sent from Windows 95/98/NT or samba servers) are ignored.
To allow diald to work you should always use the newest version including all patches. Please follow exactly the setup instructions. If you are having problems please don't ask me but use the diald mailinglist which can be reached at http://www.loonie.net/~eschenk/diald.html#list. It has been very helpful to me!
Don't forget to compile your kernel with SLIP support as stated above in the kernel options kernel section.
On a RedHat and SUSE based system you should create a link
/etc/diald.conf -> /etc/diald/diald.conf because this was
accidently omitted in the rpms.
A helpful option in /etc/diald.conf will be debug 0x31 which
generates various syslog entries about what diald gets and does.
Additionally you may want to use the countRules.pl script to interpret
the syslog entries (see
countRules
).
IP Masquerading is needed when the local IP addresses are the private ones defined in RFC 1918. These are:
All these addresses can be freely used by anyone without the need of registering, hence the addresses are ambiguous which means that the same address can be used more than once in the world but only once in a LAN. To make sure the private IP addresses do not disturb normal internet operation they are not routed on the internet. That means e.g. the ISPs do not allow private IP addresses be routed through their networks. Therefore it is necessary to masquerade them if you use these addresses for your own private LAN and want to participate on the internet via your ISP.
What IP Masquerading does is using the official assigned IP address which you automatically get when connecting to your ISP - either dynamic via ppp or static via a leased line - for all your PCs. The masquerading host will convert the private IP addresses to the official one ensuring all your PCs can be kept apart.
IP Masquerading is done by the kernel so you need to compile masquerading support into the kernel (see the Kernel 2.0.x Options or Kernel 2.2.x Options section above).
For IP Masquerading related documents and a very good mailinglist take a look at http://ipmasq.cjb.net.