Firewalling and Proxy Server HOWTO
 David Rudder, [email protected]
 v0.1, 23 April 1995

 This document is designed to teach the basics of setting up a firewall
 on a Linux based PC.  Also covered is the installation and use of
 Proxy Servers to allow greater access to the Internet from behind a
 firewall.

 1.  Introduction

 Firewalls have gained great fame recently as the ultimate in Internet
 Security.  Like most things that gain fame, with that fame has come
 misunderstanding.  This HOWTO will go over the basics of what a
 firewall is, how to set one up, what proxy servers are, how to set up
 proxy servers, and the applications of this technology outside of the
 security realm.


 1.1.  Feedback

 Any feedback is very welcome.  I am particularly looking for feedback
 from people who use Macintosh computers, as the information I have on
 them is scanty.  PLEASE PLEASE PLEASE REPORT ANY INACCURACIES IN THIS
 PAPER!!!  I am human, and prone to making mistakes.  If you find any,
 fixing them is of my highest interest.  I will try to answer all e-
 mail, but I am busy, so don't get insulted if I don't.


 My email address is [email protected].


 1.2.  Disclaimer

 This document is meant as an introduction to how Firewalls and Proxy
 Servers work.  I am not, not do I pretend to be, asecurity expert.  I
 am just some guy who has read to much and likes computers more than
 people.  I AM NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS
 TAKEN BASED ON THIS DOCUMENT.   Please, I am writing this to help get
 people acquainted with this subject, and I am not ready to stake my
 life on the accuracy of what is in here.


 1.3.  Copyright

 Unless otherwise stated, Linux HOWTO documents are copyrighted by
 their respective authors. Linux HOWTO documents may be reproduced and
 distributed in whole or in part, in any medium physical or electronic,
 as long as this copyright notice is retained on all copies. Commercial
 redistribution is allowed and encouraged; however, the author would
 like to be notified of any such distributions.

 All translations, derivative works, or aggregate works incorporating
 any Linux HOWTO documents must be covered under this copyright notice.
 That is, you may not produce a derivative work from a HOWTO and impose
 additional restrictions on its distribution. Exceptions to these rules
 may be granted under certain conditions; please contact the Linux
 HOWTO coordinator at the address given below.

 In short, we wish to promote dissemination of this information through
 as many channels as possible. However, we do wish to retain copyright
 on the HOWTO documents, and would like to be notified of any plans to
 redistribute the HOWTOs.

 If you have any questions, please contact David Rudder
 <[email protected]>.
 1.4.  TODO


 o  Learn how to do this on a Macintosh

 o  Learn different Windows TCP/IP packages

 o  Find a good UDP proxy server that works with Linux


 2.  Understanding Firewalls

 A Firewall is a term derived from a part of a car.  In cars, Firewalls
 are physical objects that separate the engine block from the passenger
 compartment.  They are meant to protect the passenger in case the car
 explodes.

 A Firewall in computers is a logical device that protects a private
 network from the public part.  How they work is:


 1. You take a computer that has routing capabilities (such as a linux
    box)

 2. Put in 2 interfaces (ie Serial ports, Ethernet, Token Ring, etc)

 3. Turn off IP forwarding

 4. Connect the internet to one interface

 5. Connect the protected network to the other interface


 Now, you have two distinct networks, which share a computer.  The
 firewall computer, from now on named "firewall", can reach both the
 protected network and the internet.  The protected network can not
 reach the internet, and the internet can not reach the protected
 network.


 For someone to reach the internet from inside the protected network,
 one must telnet to firewall, and use the internet from there.
 Accordingly, in order to get into the protected network, one must go
 through the firewall first.


 This provides excellent security against attacks from the internet.
 If someone wants to make a concerted attack against the protected
 network, they must go through the firewall first, making it a two-
 step, and thus much harder, attack.  If someone wants to attack the
 protected network via a more common method, such as mail bombing, or
 the infamous "Internet Worm", they will not be able to reach the
 protected network.  This makes for excellent protection.


 2.1.  Drawbacks with Firewalls

 The biggest problem with firewalls is that they greatly inhibit the
 access to the internet from the inside.  Basically, they reduce the
 usage of the internet to that which one would have via a dial-up shell
 account.  Having to login to firewall and then do all internet access
 is a severe restriction.  Programs like Netscape, which require a
 direct internet connection, will not work from behind a firewall.
 Being unable to ftp directly to your computer is another big problem,
 requiring a two step, internet->firewall->protected computer setup.
 The answer to these problems is having a Proxy Server.
 2.2.  Proxy Servers

 Proxy servers are constructs that allow direct internet access from
 behind a firewall.  How they work is they open a socket on the server,
 and allow communication via that socket to the internet.  For example,
 if my computer, drig is inside the protected network, and I want to
 browse the Web using Netscape, I would set up a proxy server on
 firewall.  The proxy server would be configured to allow requests from
 my computer, trying for port 80, to connect to its port 1080, and it
 would then redirect all requests to the proper places.


 Anyone that has used TIA or TERM has seen this concept before.  Using
 these two programs, you can redirect a port.  A friend had TIA setup
 to allow anyone using 192.251.139.21 port 4024 to connect to his Web
 Server.  The proxy server works like this, but backwards.  To connect
 to anyone else's port 80, you must use port 1080 (or whichever port
 you set it for).


 The great thing about proxy servers is that they are completely
 secure, when configured correctly.  They will not allow someone in
 through them.


 3.  Setting This All Up


 3.1.  Hardware requirements

 For our example, the computer is a 486-DX66, 8 megs of memory, 500
 megs Linux partition, with a PPP connection to it internet provider
 over a 14.4 modem.  This setup is your basic Linux box.  To make it a
 firewall, we add one NE2000 Ethernet card.  It is then connected to 3
 PC's running Windows 3.1 with Trumpet Winsock and 2 Suns running SunOS
 4.1.  This setup was chosen because it is a fairly common and they are
 both platforms that I am familiar with.  I imagine much of the same
 stuff that I am talking about here is doable with Macs, but since I
 don't use Macs frequently enough, I don't really know.


 3.2.  Setting up the Software

 So, you have one Linux box connected to the net via a 14.4 PPP line.
 You then have a Ethernet network connected to the Linux box and all
 the other computers.  First, you must recompile the Linux kernel with
 the appropriate options.  At this point, I would look at the Kernel
 HOWTO, the Ethernet HOWTO, and the NET-2 HOWTO.  Then, do a "make
 config":


 1. Turn on Networking Support

 2. Turn on TCP/IP Networking

 3. Turn off IP Forwarding (CONFIG_IP_FORWARD).

 4. Turn on IP Firewalling

 5. Probably turn on IP accounting.  Seems prudent since we are setting
    up a security measure

 6. Turn on Networking Device Support

 7. We turn on PPP and Ethernet support, but that depends on your
    interfaces
 Then, we recompile, reinstall the kernel and reboot.  The interfaces
 should show up in the boot-up sequence, and we should be fine.  If
 not, go over the other HOWTOs again until it is working.


 3.3.  Configuring the Network Addresses

 This is the real interesting part.  Since we do not want the internet
 to have access, we do not need to use real addresses.  One good C
 Class to use is 192.0.2.xxx, which was set aside as a dummy test
 domain.  Thus, no one uses it, and it will not conflict with any
 requests for the outside.  So, in this configuration, only one real IP
 address is needed. The others are free for the taking and will not
 affect the network at all.

 Assign the real IP to the serial port used for the PPP.  Assign
 192.0.2.1 to the Ethernet card on firewall.  Assign all the other
 machines in the protected network some number in that domain.


 3.4.  Testing it out

 First, try to ping the internet from firewall.  I used to use
 nic.ddn.mil as my test point.  It's still a good test, but has proven
 to be less reliable than I had hoped.  If it doesn't work at first,
 try pinging a couple other places that are not connected to your LAN.
 If this doesn't work, then your PPP is incorrectly setup.  Reread the
 Net-2 HOWTO, and try again.

 Now, try pinging between hosts within the protected network.  All the
 computers should be able to ping each other.  If not, go over the
 NET-2 HOWTO again and work on the network some more.

 Then, every machine in the protected network should be able to ping
 firewall.  If not, go back again.  Remember, they should be able to
 ping 192.0.2.1, not the PPP address.

 Then, try to ping the PPP address of firewall from inside the
 protected network.  If you can, then you have not turned off IP
 Forwarding and you will have to recompile the kernel.  Having assigned
 the protected network the 192.0.2.1 domain means that no packets will
 be routed to this network anyway, but it is safer to have IP
 Forwarding turned off anyway.  This leaves the control in your hands,
 not in the hands of your PPP provider.


 Finally, ping each machine within the protected network from firewall.
 By this time, there should be no problems.


 Now, you have your basic firewall setup.


 3.5.  Securing the Firewall

 The firewall is no good if it is left wide open to attacks.  First,
 look at /etc/inetd.conf.  This file is what is called a "super
 server".  It runs a bunch of the server daemons as they are requested.
 Examples are:


 o  Telnet

 o  Talk


 o  FTP

 o  Daytime

 Turn off everything that is not needed.  Definitely turn off netstat,
 systat, tftp, bootp, and finger.  You might also want to turn off
 telnet, and only allow rlogin, or vica-versa.  To turn a service off,
 merely put a # in front of it.  Then, send a SIG-HUP to the process by
 typing kill -HUP <pid>, where pid is the process number of inetd.
 This will make inetd re-read its configuration file (inetd.conf) and
 restart.  Test it out by telneting to port 15 on firewall, the netstat
 port.  If you get an output of netstat, you have not restarted it
 correctly.


 4.  The Proxy Server

 4.1.  Setting up the Proxy Server

 The proxy server requires additional software.  You can get this
 software from
 ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-
 src.tgz.  There is also an example config file in that directory
 called "socks-conf".  Uncompress and untar the files into a directory
 on your system, and follow the instructions on how to make it.  I had
 a couple problems in making it.  Make sure that the Makefiles are
 correct.  Some are, some are not.


 4.2.  Configuring the Proxy Server

 The socks program needs two separate configuration files.  One to tell
 the access allowed, and one to route the requests to the appropriate
 proxy server.  The access file should be housed on the server.  The
 routing file should be housed on every Un*x machine.  The DOS and,
 presumably, Macintosh computers will do their own routing.


 4.2.1.  The Access File

 With socks4.2 Beta, the access file is called "sockd.conf".  It should
 contain 2 lines, a permit and a deny line.   Each line will have three
 entries:

 o  The Identifier (permit/deny)

 o  The IP address

 o  The address modifier

 The identifier is either permit or deny.  You should have both a
 permit and a deny line.

 The IP address holds a four byte address in typical IP dot notation.
 Ie 192.0.2.0.

 The address modifier is also a typical IP address four byte number.
 It works like a netmask.  Envision this number to be 32 bits (1s or
 0s).  If the bit is a 1, the corresponding bit of the address that it
 is checking must match the corresponding bit in the IP address field.
 For instance, if the line is:

 permit 192.0.2.23 255.255.255.255

 then, it will permit only the IP address that matches every bit in
 192.0.2.23, eg, only 192.0.2.3.  The line:
 permit 192.0.2.0 255.255.255.0

 will permit every number within group 192.0.2.0 through 192.0.2.255,
 the whole C Class domain.   One should not have the line:

 permit 192.0.2.0 0.0.0.0

 as this will permit every address, regardless.

 So, first permit every address you want to permit, and then deny the
 rest.  To allow everyone in the domain 192.0.2.xxx, the lines:

 permit 192.0.2.0 255.255.255.0

 deny 0.0.0.0 0.0.0.0

 will work nicely.  Notice the first "0.0.0.0" in the deny line.  With
 a modifier of 0.0.0.0, the IP address field does not matter.  All 0's
 is the norm because it is easy to type.

 More than one entry of each is allowed.

 Specific users can also be granted or denied access.  This is done via
 ident authentication.  Not all systems support ident, including
 Trumpet Winsock, so I will not go into it here.  The documentation
 with socks is quite adequate on this subject.


 4.2.2.  The Routing File

 The routing file in socks is poorly named "socks.conf".  I say "poorly
 named" because it is so close to the name of the access file that it
 is easy to get the two confused.


 The routing file is there to tell the socks clients when to use socks
 and when not to.  For instance, in our network, 192.0.2.3 will not
 need to use socks to talk with 192.0.2.1, firewall.  It has a direct
 connection in via Ethernet.  It defines 127.0.0.1, the loopback,
 automatically.  Of course you do not need socks to talk to yourself.
 There are three entries:

 o  deny

 o  direct

 o  sockd

 Deny tells socks when to reject a request.  This entry has the same
 three fields as in sockd.conf, identifier, address and modifier.
 Generally, since this is also handled by sockd.conf, the access file,
 the modifier field is set to 0.0.0.0.  If you want to preclude
 yourself from calling any place, you can do it here.


 The direct entry tells which addresses to not use socks for.  These
 are all the addresses that can be reached without the proxy server.
 Again we have the three fields, identifier, address and modifier.  Our
 example would have

 direct 192.0.2.0 255.255.255.0

 Thus going direct for any on our protected network.



 The sockd entry tells the computer which host has the socks server
 daemon on it.  The syntax is:

 sockd @=<serverlist> <IP address> <modifier>

 Notice the @= entry.  This allows you to set the IP addresses of a
 list of proxy servers.  In our example, we only use one proxy server.
 But, you can have many to allow a greater load and for redundancy in
 case of failure.


 The IP address and modifier fields work just like in the other
 examples.  You specify which addresses go where through these.


 4.3.  Working With a Proxy Server


 4.3.1.  Unix

 To have your applications work with the proxy server, they need to be
 "sockified".  You will need two different telnets, one for direct
 communication, one for communication via the proxy server.  Socks
 comes with instructions on how to sockify a program, as well as a
 couple pre-sockified programs.  If you use the sockified version to go
 somewhere direct, socks will automatically switch over to the direct
 version for you.  Because of this, we want to rename all the programs
 on our protected network and replace them with the sockified programs.
 "Finger" becomes "finger.orig", "telnet" becomes "telnet.orig", etc.
 You must tell socks about each of these via the include/socks.h file.


 Certain programs will handle routing and sockifying itself.  Netscape
 is one of these.  You can use a proxy server under Netscape by
 entering the server's address (192.0.2.1 in our case) in the SOCKs
 field under Proxies.  Each application will need at least a little
 messing with, regardless of how it handles a proxy server.


 4.3.2.  MS Windows with Trumpet Winsock

 Trumpet Winsock comes with built in proxy server capabilities.  In the
 "setup" menu, enter the IP address of the server, and the addresses of
 all the computers reachable directly.  Trumpet will then handle all
 outgoing packets.


 4.4.  Getting the Proxy Server to work with UDP Packets

 The socks package works only with TCP packets, not UDP.  This makes it
 quite a bit less useful.  Many useful programs, such as talk and
 Archie, use UDP.  There is a package designed to be used as a proxy
 server for UDP packets called UDPrelay, by Tom Fitzgerald
 <[email protected]>.  Unfortunately, at the time of this writing, it is
 not compatible with Linux.


 4.5.  Drawbacks with Proxy Servers

 The proxy server is, above all, a security device.  Using it to
 increase internet access with limited IP addresses will have many
 drawbacks.  A proxy server will allow greater access from inside the
 protected network to the outside, but will keep the inside completely
 unaccessible from the outside.  This means no servers, talk or Archie
 connections, or direct mailing to the inside computers.  These
 drawbacks might seem slight, but think of it this way:
 o  You have left a report you are doing on your computer inside a
    firewall protected network.  You are at home, and decide that you
    would like to go over it.  You can not.  You can not reach your
    computer because it is behind the firewall.  You try to log into
    firewall first, but since everyone has proxy server access, no one
    has set up an account for you on it.

 o  Your daughter goes to college.  You want to email her.  You have
    some private things to talk about, and would rather have your mail
    sent directly to your machine.  You trust your systems
    administrator completely, but still, this is private mail.

 o  The inability to use UDP packets represents a big drawback with the
    proxy servers.  I imagine UDP capabilities will be coming shortly.

 And, proxy servers run slow.  Because of the greater overhead, almost
 any other means of getting this access will be faster.

 Basically, if you have the IP addresses, and you are not worried about
 security, do not use a firewall and/or proxy servers.  If you do not
 have the IP addresses, but you are also not worried about security,
 you might also want to look into using an IP emulator, like Term,
 Slirp or TIA.  Term is available from ftp://sunsite.unc.edu, Slirp is
 available from ftp://blitzen.canberra.edu.au/pub/slirp, and TIA is
 available from marketplace.com.  These packages will run faster, allow
 better connections, and provide a greater level of access to the
 inside network from the internet.  Proxy servers are good for those
 networks which have a lot of hosts that will want to connect to the
 internet on the fly, with one setup and little work after that.


 5.  Advanced Configurations

 There is one configuration I would like to go over before wrapping
 this document up.  The one I have just outlined will probably suffice
 for most people.  However, I think the next outline will show a more
 advanced configuration that can clear up some questions.  If you have
 questions beyond what I have just covered, or are just interested in
 the versatility of proxy servers and firewalls, read on.


 5.1.  A large network with emphasis on security

 Say, for instance, you are the leader of the Milwaukee 23rd Discordian
 Cabal.  You wish to network your site.  You have 50 computers and a
 subnet of 32 (5 bits) IP numbers.  You have various levels of access.
 You tell your disciples different things according to each level.
 Obviously, you would want to protect certain parts of the network from
 the disciples that are not in that level.


 Disclaimer: I am not a member of the Discordians.  I do not know their
 terminology, nor do I really care.  I am using them as an example
 only.  Please send all flames to

 The levels are:

 1. The external level.  This is the level that gets shown to
    everybody.  Basically, this is the ranting and raving about Eris,
    Goddess of Discord, and all the rest of the drivel.

 2. Sage  This is the level of people who have gotten beyond the
    external level.  Here is where you tell them that discord and
    structure are really one, and that Eris is also Jehovah.


 3. Adept  Here is where the real plan is.  In this level is stored all
    the information on how the Discordian Society is going to take over
    the world through a devious, yet humorous, plan involving Newt
    Gingrich, Wheaties Cereal, O.J. Simpson, and five hundred crystals,
    all erroneously marked "6.5 MHz".


 5.1.1.  The Network Setup

 The IP numbers are arranged as:

 o  23 of the 32 IP addresses are allocated to 23 machines that will be
    accessible to the internet.

 o  1 extra IP goes to a linux box on that network

 o  1 extra goes to a different linux box on that network.

 o  2 IP #'s go to the router

 o  5 are left over, but given domain names paul, ringo, john, george
    and billy, just to confuse things a bit.

 o  The protected networks both have the addresses 192.0.2.xxx

 Then, two separate networks are built, each in different rooms.  They
 are routed via Infrared Ethernet so that they are completely invisible
 to the outside room.  Luckily, infrared Ethernet works just like
 normal Ethernet (or so i think), so we can just think of them like
 normal.

 These networks are each connected to one of the linux boxes with an
 extra IP address.

 There is a file server connecting the two protected networks.  This is
 because the plans for taking over the world involves some of the
 higher sages.  The file server holds the address 192.0.2.17 for the
 sage network and 192.0.2.23 for the adept network.  It has to have
 different IP addresses because it has to have different Ethernet
 cards.  IP Forwarding on it is turned off.

 IP Forwarding on both Linux boxes is also turned off.  The router will
 not forward packets destined for 192.0.2.xxx unless explicitly told to
 do so, so the internet will not be able to get in.  The reason for
 turning off IP Forwarding here is so that packets from the sage
 network will not be able to reach the adept network, and vica versa.

 The NFS server can also be set to offer different files to the
 different networks.  This can come in handy, and a little trickery
 with symbolic links can make it so that the common files can be shared
 with all.  Using this setup and another Ethernet card can offer this
 one file server for all three networks.


 5.1.2.  The Proxy Setup

 Now, since all three levels want to be able to monitor the network for
 their own devious purposes, all three need to have net access.  The
 external network is connected directly into the internet, so we don't
 have to mess with proxy servers here.  The adept and sage networks are
 behind firewalls, so it is necessary to set up proxy servers here.

 Both networks will be setup very similarly.  They both have the same
 IP addresses assigned to them.  I will throw in a couple of
 parameters, just to make things more interesting though.

 1. No one can use the file server for internet access.  This exposes
    the file server to viruses and other nasty things, and it is rather
    important, so its off limits.

 2. We will not allow Sage access to the World Wide Web.  They are in
    training, and this kind of information retrieval power might prove
    to be damaging.

 So, the sockd.conf file on the sage linux box will have this line:

 deny 192.0.2.17 255.255.255.255

 and on the adept machine:

 deny 192.0.2.23 255.255.255.255

 And, the sage linux box will have this line

 deny 0.0.0.0 0.0.0.0 eq 80

 This says to deny access to all machines trying to access the port
 equal (eq) to 80, the http port.  This will still allow all other
 services, just deny Web access.

 Then, both files will have:

 permit 192.0.2.0 255.255.255.0

 to allow all the computers on the 192.0.2.xxx network to use this
 proxy server except for those that have already been denied (ie. the
 file server and Web access from the sage network).


 The sage sockd.conf file will look like:

 deny 192.0.2.17 255.255.255.255

 deny 0.0.0.0 0.0.0.0 eq 80

 permit 192.0.2.0 255.255.255.0

 and the adept file will look like:

 deny 192.0.2.23 255.255.255.255

 permit 192.0.2.0 255.255.255.0


 This should configure everything correctly.  Each network is isolated
 accordingly, with the proper amount of interaction.  Everyone should
 be happy.  Now, look out for your 6.5 MHz crystals

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.