FIREWALL: "Fireproof wall to prevent spread of fire." - Concise Oxford Dictionary.
P.C. SCADA LINK
Supervisory Control and Data Acquisition
A Talk Designed for Linux Users of Victoria
This discussion is brought to you by a novice, not an expert so some things here may seem a little incorrect to the wizards of Linux. When I learn a little more I hope to update this talk to suit. (Probably by then it will have all changed anyway).
This talk aims at showing the basics of firewalling a linux network. It will not cover every possible scenario but should cover enough information to get a network up and running with a firewall in place.
In computer terms, a firewall will stop any network activity on one network from being passed on to another network.
In most systems the Linux kernel is compiled with IP forwarding set to yes. What this means is that if the computer has more than one network connected to it then network information will be passed directly from one network to the other as if it was physically connected.
If you were to compile the kernel with IP forwarding set to no and Firewalling set to yes then the two networks will appear to be separated.
This means that any user on the firewall computer can communicate with both networks.
However, anyone on a system other than the firewall, connected to either of the networks can only communicate within their own network.
In this discussion I will cover what I have done with my own system. The basic idea is to show people the steps that I took to create a firewall and what was required to allow the systems on my local network to use the facilities on the Internet.
First lets take a look at the network layout. My system is small, so it will be a lot easier to follow.
To start with I have an old 386 that I wish to use as the firewall. In the 386 there is a modem for connecting to an internet provider and an NE2000 network card.
I also have another system which is my main workstation (a pentium 133). In it I have an NE2000 network card and other irrelevant hardware that makes the workstation worthwhile. In future I hope to expand my network to have another system but for now this small network is perfect for this discussion.
As you may see from this diagram I have given each computer an IP address and a simple name. Of course you can change these to suite your own system. The IP addresses have been taken directly from the Firewalling HOWTO found on most Linux distributions.
From reading the Firewall HOWTO I decided to use the "socks" program as a proxy server. We'll discuss proxy servers a bit later.
To get the socks program login as root and ftp the source from
Move the file to /usr/src and type
tar -zxvf socks-linux-src.tgz
Leave it there for later.
All the other software needed for this exercise I was able to find on my Linux distribution disk.
First set up the firewall computer. To do this recompile the kernel with the following settings:
Linux Kernel v2.0.27 Configuration ---------------------------------------------------------- ------------------ Networking options ------------------------ Arrow keys navigate the menu. <Enter> selects submenus --->. Highlighted letters are hotkeys. Pressing <Y> includes, <N> excludes, <M> modularizes features. Press <Esc><Esc> to exit, <?> for Help. Legend: [*] built-in [ ] excluded <M> module < > module capable ---------------------------------------------------------- [*] Network firewalls [ ] Network aliasing [*] TCP/IP networking [ ] IP: forwarding/gatewaying [ ] IP: multicasting [*] IP: firewalling [ ] IP: firewall packet logging [ ] IP: accounting --- (it is safe to leave these untouched) [ ] IP: PC/TCP compatibility mode ----------------------------------------------------------- <Select> < Exit > < Help > -----------------------------------------------------------
Some people might like to set IP accounting or IP firewall packet logging but for an initial test these settings will do fine.
When compiled and rebooted check that the system is set up correctly.
Check these files on "myfirewall.org".
127.0.0.1 localhost localhost.localdomain 192.168.2.1 myfirewall.org myfirewall 192.168.2.2 mysystem.org mysystem 22.214.171.124 vicnet.net.au vicnet (my PPP internet provider)
loopback 127.0.0.0 localnet 192.168.2.0 vicnet 126.96.36.199
domain org nameserver 188.8.131.52
NETWORKING=yes HOSTNAME=myfirewall.org DOMAINNAME=org GATEWAY=184.108.40.206 (or your internet providers gateway) GATEWAYDEV=ppp0
When all of this is checked and verified you should be able to ftp or telnet over the internet and to your "mysystem.org" computer from the "myfirewall.org" computer. If this is the case then so far so good.
Now set up "mysystem.org". If this system has been working fine before hand then there is no need to recompile the kernel but we do need to check the networking setup files.
Check these files on "mysystem.org":
127.0.0.1 localhost localhost.localdomain 192.168.2.2 mysystem.org mysystem 192.168.2.1 myfirewall.org myfirewall
loopback 127.0.0.0 localnet 192.168.2.0
NETWORKING=yes HOSTNAME=mysystem.org DOMAINNAME=org
When all of this is checked and verified you should be able to ftp or telnet to the "myfirewall.org" computer. But you will not be able to contact anything on the internet directly from "mysystem.org". If this is the case then you have successfully installed a firewall. No one can get directly to "mysystem.org" and "mysystem.org" cannot get directly to anything past the firewall.
This seems pretty silly because now I can't use the internet from my main system. Or can I?
Earlier I acquired the "socks" program. This program is what will gain the internet back for my small network.
A firewall effectively puts all of its systems inside a fort with the door closed.
The socks program can be thought of as an intelligent sentinel that checks IP addresses as they pass through the firewall. If an illegal origin IP address comes up to the firewall and tries to enter the network, then the socks program will deny the entry and even warn the super user of the intended intrusion.
Now comes the fun part. Setting up socks.
The socks program that I downloaded was version 4.2 and although it was labeled as a Linux distribution, it did not take long to realize that it still needed configuring.
The distribution has a directory tree like this....
/usr/src/socks42b /usr/src/socks42b/doc /usr/src/socks42b/include/ /usr/src/socks42b/lib/ /usr/src/socks42b/libident/ /usr/src/socks42b/rfinger/ /usr/src/socks42b/rftp/ /usr/src/socks42b/rtelnet/ /usr/src/socks42b/sockd/
Reading through the documentation I soon discovered that this distribution had source code for the firewall computer as well as code for the clients or in my case "mysystem.org".
So to make life easier I only compiled what was required on each individual system. This meant that the source file socks-linux-src.tgz needed to be copied from "myfirewall.org" to "mysystem.org" before I went to far (I used ftp).
These are the steps that I took to set up the 386 firewall.
Step 4a: Edit /usr/src/socks42b/Makefile
Change the PWD variable to equal /usr/src/socks42b.
The optimal compilation flags are given for a Linux system and in this file it should be uncommented to look like this....
# LINUX should use CC=gcc RANLIB=ranlib RESOLV_LIB= OTHER_CFLAGS=-DLINUX $(GETCWD) $(FASCIST) $(SHORTENED_RBIND) -DCOMPAT OS=linux INSTALL=install GETPASS=getpass.o
Step 4b: Edit
/usr/src/socks42b/doc/Makefile /usr/src/socks42b/include/Makefile /usr/src/socks42b/lib/Makefile /usr/src/socks42b/libident/Makefile /usr/src/socks42b/rfinger/Makefile /usr/src/socks42b/rftp/Makefile /usr/src/socks42b/rtelnet/Makefile /usr/src/socks42b/sockd/Makefile
Yes just go through them all and check that they are all set and ready for the Linux operating system.
Step 4c: Edit /usr/src/socks42b/include/socks.h
Change the following lines to equate to your firewall system.
#define SOCKS_DEFAULT_SERVER "myfirewall.org" #define SOCKS_DEFAULT_NS "192.168.2.1" #define SOCKS_DEFAULT_DNAME "org"
Step 4d: Compile and install
Change directory to /usr/src/socks42b/, and at the prompt type:
# make server # make install.server
Once complete there is only one or two more things to do.
Step 4e: Setting up the proxy server
Edit /etc/services, add the line
Edit /etc/inetd.conf, add the line
socks stream tcp nowait nobody /usr/etc/sockd sockd -i
Create a file called /usr/local/etc/sockd.conf, add the line
permit 192.168.2.2 255.255.255.0
This line allows the data with a source IP address of 192.168.2.2 to pass the firewall.
Other lines of use are ...
deny 0.0.0.0 0.0.0.0 : /usr/bin/finger @%A | /bin/mail -s 'SOCKS: rejected %u@%A to %Z (%S)' root root@%A
Typed in as one continuous line this will email email@example.com and root@the offending system letting both system administrators know that someone is up to no good.
#NO_IDENT: /bin/mail -s 'Please run identd on host %A' %u@%A root@%A
This will email the user and the users system administrator to ask them to set up identd on their system.
Socks can be set up to allow particular users to enter through the firewall. In our example permit line above we could have specified particular users access through myfirewall.org. This has not been done to make life a little easier for now. What socks does is check for a user i.d. as well as an IP address before making any decisions and if there is no user i.d. or if the user i.d. does not match in the sockd.conf file then the mail program can be executed.
#BAD_ID: /usr/bin/finger @%A | /bin/mail -s '%U pretends to be %u on %A' root root@%A
This will email the system administrator on the offending system and on myfirewall.org that someone is trying to to use someone elses i.d.
I don't know how accurate or fireproof any of this is but it is some form of protection.
Create a file called /usr/local/etc/sockd.route, add the line
220.127.116.11 0.0.0.0 0.0.0.0
where 18.104.22.168 is the network address of your internet provider. This file is used after sockd.conf to let the socks program know which network to use for a given IP address. If I were to add my next system to my small network then the IP address of my local network would be added before the line above.
Step 4f: Testing the proxy server setup
There is a nifty little program that comes with socks called test_sockd_conf. This program uses your sockd.conf file to give you diagnostics as to whether IP addresses will be stopped etc. This program can be used even though mysystem.org has not been set up yet.
To test the sockd.conf type the following as superuser:
# cd /usr/local/etc # ./test_sockd_conf phil 192.168.2.2 321.312.32.4 telnet
This will or should give the following response.
USER:phil, SRC:192.168.2.2, DST:255.255.255.255, PORT:23 Line 1: permit 192.168.2.2 255.255.255.0 ==== Checking routing file (/usr/local/etc/sockd.route)... Line 1: 22.214.171.124 0.0.0.0 0.0.0.0
This does not tell you the full story. To find out whether your test passed or failed type...
# echo $?
The response should be:
This test should fail:
# ./test_sockd_conf phil 126.96.36.199 321.312.32.4 telnet USER:phil, SRC:188.8.131.52, DST:255.255.255.255, PORT:23 *** No match with any line. Access denied. # echo $? 0
With this result, confidence starts to build up. But we are only half way.
Step 4e: Setting up the clients
Yes all the systems inside the firewall need to know that there is something in the way.
It is possible to compile everything on one system and then copy the files to each system but I chose to copy the source code to my client computer "mysystem.org" and compile from scratch. This of course means that socks.h and each Makefile must be edited again but this is not too difficult.
Make sure that the socks.h file has the following line...
#define ORIG_FINGER /usr/bin/finger.orig
This will be the new name for the regular existing finger program that you should already have.
#make clients # make install.clients
Rename /usr/bin/finger to /usr/bin/finger.orig. This finger.orig program will be used as a local network finger.
Create a file called /etc/socks.conf, add the following lines.
direct 192.168.2.0 255.255.255.0 sockd @=192.168.2.1 255.255.255.255 0.0.0.0
These lines tell the client programs whether to use the socks program on the firewall or to not bother with the firewall and go directly to a local networked system.
The client programs are now installed and ready.
Step 4f: Testing the clients
Dial up the internet provider with the firewall system and make sure that you can ping known systems on the net. e.g.,
ping vicnet.net.au ping www.luv.asn.au
Now jump to mysystem.org and try the same thing.
If you can ping to these systems on the internet then something is wrong. It should fail.
If you ping myfirewall.org then it should work. This proves that the local network is working and that the firewall is doing its job.
To check if my socks program works I tried to telnet to my provider from mysystem.org by typing:
$ telnet > open host> vicnet
As soon as I received the login prompt I escaped straight away because I don't have a shell account with them but this proved that the socks program was working.
All the setting up and testing has gone well so far but at this point trying telnet from mysystem.org to any system beyond gave me no joy. It took me a while to find but as usual once I found the problem, it made sense.
Any client system trying to communicate through a firewall does not have access to any DNS on the other side of the firewall. This makes it difficult to use web browsers like Netscape that require a DNS. To overcome this shortfall make sure that the firewall is also a DNS. I won't cover setting up a DNS in this talk because it can be covered more fully in another talk but you should get the general idea.
Programs like Netscape need to know about the firewall and proxy server (socks) so be sure to set them up also.
O.K. not everyone is going to do it this way. Some people will enhance their firewall to the n'th degree but for a startup system this should get you started.
On the system described here, there is no real necessity for security. The main purpose for socks in this case is to allow my small network to have multiple workstations access the internet at the same time without having to register a new internet IP address for each station. Having one dial in internet connection with one internet IP address given to my system from my provider meant that I could only use one computer at a time to access the internet. A firewall with Socks came to the call allowing more than one station internet access.
But for a larger network with unruly people connecting in and trying all kinds of weird tricks, a more complicated and secure setup for socks is required.
The best way to achieve the desired goal is to take a close look at the configuration files and look at all the manual pages that comes with socks:
Detailed explanations of the fields used in each line of these config files can be found here (examples included).
Reading through the Firewall-HOWTO is a help also.
By reading through these useful documents I do believe that some questions may be answered that are not covered here. Like allowing only individuals to gain access through the firewall and using the firewall within an organisation rather than on the internet.
I hope that this discussion has been interesting for you and given you ideas for your future projects. I have enjoyed composing this talk and building a small firewall in my office. it gave me great pleasure in achieving the goal that I set out to do.