This section I think is one of the most important you have to deal with when putting a server online. The data stored on any server
must be protected from the in/outside world at all times. Not only do you have to protect your own network but also the server.
Here it is essential to think about what services, daemons, ports & IP addresses are in use to ensure that the server is as
secure as you can make it.
Not only do we need a firewall to block any traffic that is not allowed, but also you also have to maintain the software running on the
server. A firewall will not stop anyone getting into the machine when you are using a software package with a known bug or exploit. That
very programme can be used against you to gain control of the server. Therefore it’s a good idea to check at the web site for your
distribution to see if there are any updates for the software you are using. On top of that I subscribed to a Linux security email
(http://www.linuxsecurity.com) which sends either daily or weekly mails with all of the security bugs & exploits, for many
distributions & loads of important software. This will help you keep up to date with your software. In combination with a
good firewall you will be well armed, there is no point making it easy for anyone huh :o)
I think there is also more "inbuilt" protection on a Linux system compared to a Windows one. It may be the software,
maybe the platform itself. It may also be that a great many people get lost very quickly when they see a Linux machine, think
of all the times you’ve wandered round a ftp server looking for ........ well anything really, & not knowing where you are.
Before I had the server I had a firewall installed on my Windows machine & was constantly being "attacked" by people
pinging my machine, trying to plant viruses, looking for a way in. Since I put the server infront of all the traffic, the firewall
hardly ever gives me a message, makes me wonder if it’s still working at times :o) The proof for me that my firewall is stopping the
"bad boys".
I think I mentioned earlier that because of the ADSL modem there are 2 network cards in the server. This gives a good separation
that is necessary to protect the internal network. The network cards are labelled eth0 & eth1 on a Linux system
& their IP addresses are important to keep the network "transparent" (easy to keep clear in your head).
The most common type of firewall under Linux is based on packet filtering. Packet filtering is feature of the Linux kernel
& simply means that data packets are allowed to pass through the system (or not) based sets of rules that govern which
type of data packets are allowed to pass & which are not. This packet filtering feature is utilised by many firewalls,
one of the most widely known is ipchains, & is based on an IP address & port number, source & destination
packet filtering system.
Many other firewall programmes generate a firewall based on questions asked about what types of communication are OK &
which are not. The question is do you use a "pre-made" firewall package or is there another way? A firewall written
by someone else has it’s pros & cons, but the cons outweigh the pros. The only "positive" aspect is that you get
something that "might" protect your machine without any great effort. Personally I see that as being negative,
how are you supposed to know if the firewall is safe if you don’t know how it works & what it’s letting through. What
if something doesn’t work, do you know how to fix it? Believe me I have been down this road before, & I have tried out
firewall packages, & something’s worked & lots didn’t. In the end I wrote my own firewall & although it may have
been a bit confusing at first, it is the ONLY way to go.
The firewall that I wrote showed me how all this information was sent around the internet & also the server, & is
basically a script that contains a list of the set rules for the data packets that are to be accepted. Have a look at this
diagram to see how the network looks & the network cards should be configured, & then we’ll have a look at a few basics of a firewall.
A firewall has two basic default policies for handling data packets, either accept or deny.
The accept policy will allow all data packets to pass unless it finds a rule to say that it should reject the packets,
whereas the deny policy blocks all data packets unless it finds a matching rule for that type of communication enabling
it to pass through. Naturally if you want a secure server you chose the deny policy.
Here you can see how the default policy (-P) for the 3 types of rules input, forward, & output is set.
A packet filtering rule basically states: a device (eth0 or eth1....), a source IP address & port number (wild cards possible),
a destination IP address & port number (wild cards possible), a protocol type (tcp, udp...), & whether this communication
should be accepted or denied. For every single type of communication between the server & the internet, between the internal
network through the server to the internet, or from the internal network to the server MUST have a rule set for it, otherwise it
will simply be rejected (if you’re default policy is set to deny)! Don’t forget that you have to also consider all the packets
that you send out will come back with an answer! These rules can be likened to a chain where each link in the chain corresponds
to a rule. If a data packet goes through the chain & doesn’t find a rule to match it, it will be discarded. Hence the name
for the most popular firewall programme ipchains. Ipchains
is perfect for my needs because it is run from the
command line & a script can easily be written to set multiple rules.
This is why you have to think about which daemons are on which ports accepting communication from the outside world, & what
services you are running & do they need access through special port numbers. Time spent writing down all this information
will save you hours when writing the firewall.
Here’s a look at the basic " default system " ipchains firewall, without your "system specific" services &
ports taken into consideration.
You can see that there are a lot variables ($REMOTEIP, $INTNET) that are used instead of the actual
IP addresses, this makes it much easier to change the whole firewall if something is wrong, also helps eliminate typing mistakes.
Here’s some of the variables set at the start of the script.
Variables can be set for any type of address or device. For example add the variables for your email service provider.
SMTP=mail.gmx.net
POP=pop.gmx.net
<br>
The finished firewall script is nothing but a batch file, which when started executes all the ipchains commands & saves the
rules into the system memory for the kernel to use for the filtering. The –A
option for ipchains means that you want
to append the default policy of deny for this particular rule. The --dport 1024:or --sport 80
are wild cards which refer to all possible IP addresses going to that particular port, either source or destination.
The 1024: means all ports from port 1024 & above. You can also see the device or interface ppp0, this is
the DSL modem & basically the last (or first :o) point of contact with the server. If you used another type of modem, ISDN for example, you
would enter isdn0 for the interface.
You can slowly see that many of the topics that we have discussed so far are slowly all coming together. Scripting,
piping, ports....... it’s all in there :o) Trust me, by the time we’ve got to the last chapter your server will be pretty much up & running.
Now take a look at the same network table again, but this time with a bit more information on it that we need to help show the
data flow to help us write the firewall.
You can see that there are a few pieces of information that have been added. I think it helps to visualise
what happens with the data packets & ultimately helps you to write an ipchains firewall that works.
When I was first confronted with writing my own firewall I was given the advice that it is easier to write when you "consider
each COMPLETE data transaction for each service (port number, ftp, http, pop..) from the data packets point of view". That may
sound a bit confusing, but think what happens when you enter www.highasakite.net in your
browser on "computer 1" & the server is also your gateway (a machine that connects your network to the internet).
Getting my web site displayed on your screen requires 2 different services, a DNS lookup & a http web server request for the
index.html stored at www.highasakite.net. That means the 2 ports numbers over which the
communication takes place are port 53 for the DNS lookup & port 80 for the http request. The important thing to see here is
that for many "operations" there are many different ports required for the complete transaction. A connection to a ftp
server requires 3 different ports.
Lets take this "transaction" idea a bit further, you send a data packet from "computer 1" out to a web site
on the internet. Can you see it’s chain of events? From computer 1 it travels to the input of eth1, gets transferred to the input
of ppp0, & then out to it’s final destination from the output of ppp0. The web site answers with a data packet to the input of
ppp0, it gets transferred through the server from the output of ppp0 to the input of eth1, & then from the output of eth1 back
to computer 1. There we have a complete transaction, request & answer. The inputs & outputs naturally depend on which
direction (to which device) the data packet is to be sent.
You may be thinking that "he’s left a few bits out there.... eth0..." well the data transaction chain for all
data packets sent from the internal network to the internet is a bit simpler but there is one more thing to take into
consideration, IP masquerading. Masquerading is when a data packet from an internal network (i.e. an IP address that
can’t be routed into the internet) receives the IP address that you were given from your ISP when you logged on, naturally
this address can be routed into the internet. This masquerading process is also a part of the firewall ( & the kernel) &
helps simplify the firewall rules. Here’s an example of the complete "data transaction" rule to cover all DNS server lookups.
These 5 lines is all it takes to find out where www.highasakite.net is located.
If you look at the whole transaction you see that a request is inputted into eth1 from the internal network heading for the
internet. It is then transferred (forwarded) to the device that connects us to the internet, ppp0, & the packet assumes
ppp0’s IP address. The packet is then sent from the output of ppp0 out to the internet. The answer arrives on the input of
ppp0 & is automatically transferred to eth1, where it is sent from the output of eth1 back into the internal network to
the computer that requested it. You may also have noticed that when a packet is sent from the output of ppp0 to the internet
the source (-s) of the packet is the IP address of ppp0 itself. This is obvious because ppp0 is the only device in our network
that has an IP address that can be used in the internet, naturally the answer will also be directed to the input of ppp0 with
the packets destination (-d) being the IP address of ppp0.
If you get used to writing & visualising the flow of information in this way then you will have no problem in
writing your own firewall that is perfectly tailored for your requirements.
Take a look at the complete firewall script in the "detailed web server" section for more ideas &
information on typical services on the server. To sum up here’s a short list of the common ipchains options.
-A append chain
-D delete chain
-P set default policy
-F flush chain (clear)
-L list rules in chain
-p protocol (by name)
-s source IP address
-d destination IP address
-i interface (eth0, eth1, ppp0....)
-j jump to target on port number #
--sport source port wild card, means all IP addresses with port
--dport destination port wild card.
-l log rule (default to /var/log/firewall)
! answer to a request
