This document will attempt to provide instructions on building a simple LINUX masquerading proxy server. There are numerous different kinds of LINUX proxy servers in use worldwide.  This model is based upon the proxy servers deployed at Holt Public Schools, and is the type of configuration that we suggest for maximum efficiency and flexibility. There are certainly other ways to create a LINUX proxy server, so you may wish to examine the relative merits of our approach before proceeding.

It is highly suggested that you read ALL of the documentation before starting the installation. Many of the HOWTO and FAQ files referenced by this document contain important information. Failure to read and understand these files may result in a server misconfiguration, or severe security problem.

Within this document are many fulltext configuration files. Although this can be somewhat annoying to experienced users, We have found that having a complete file to put the changes in context really helps. In general, additions or changes to a config file are denoted by bold text.  Eventually, we may replace the fulltext configuration files with HTML links to a different page and provide more in-depth information about various configuration options.

About the authors:

The authors of this document are employees of Holt Public Schools in Holt, Michigan.  This document represents the work that we have done in connecting our district's Wide Area Network to the Internet.  This howto started as an internal document, and has been released to the public in the hopes that it will be useful to others, save much-needed money for educators,  and promote the use of Freeware and LINUX in particular.

Before you start:

The first thing you should do is acquaint yourself with different sources of Linux documentation. The sources that will be refered to all exist on the web, so you will need a WWW browser. First of all, check out the Linux Documentation Project. This site is a good place to get started whenever you are looking for some specific information.

For general information on WHAT a masquerading proxy server is, what it does, and how it is generally put together, you might want to take a look at Mark Lachniet's online tutorial on "Expanding the Internet with Linux." This guide is designed as an introduction to Linux and networking concepts. It gives a general overview of how a Masquerading proxy server works, and what it can do for you. The presentation itself is geared towards K12 education, but has technical information that is valid for everyone.

First of all, you will want to read the "Getting Started" guide by Matt Welsh et. all. This contains all of the information your should need to get your Linux system installed. The HTML version of the guide can be found at http://sunsite.unc.edu/mdw/LDP/gs/gs.html. If this is your first time installing LINUX, pay special attention to the installation procedures!

Next, I suggest that you read up on the two major pieces of software that will be used to create the proxy server: The Squid Internet Object Cache, and IP Masquerading. These two links are home pages for the major software pieces we will use. Also, you will be using a firewall configuration tool that is included in Slackware LINUX called IPFWADM.  There is a very helpful homepage for IPFWADM at: http://www.xos.nl/linux/ipfwadm. To begin with, it will be enough to simply read up on the topic. When the time comes, you will most certainly want to refer to the HOWTO files.

Don't worry about actually performing all of the steps detailed in these help files. An alternate way of installation will be presented in this document.

Getting the software:

The first step is to get the latest version of SLACKWARE Linux. This document assumes that you are using SLACKWARE 3.5.You can download this software via FTP from ftp://sunsite.unc.edu. Alternately, you might wish to order the CD-ROM package (as I do) from Walnut Creek CD-ROM at http://www.cdrom.com. You can install the proxy software packages on other distributions of Linux, but you will have to deal with the OS differences on your own. The instructions for doing this installation on a RedHat slackware, for example, are almost exactly the same but would require the editing of files in a slightly different directory structure.

 Installing the system:

Once you have all the software on hand, and feel comfortable with the different technologies to be utilized, it's time to start your Linux installation.

First of all, it might be a good idea to do a test installation of the system. This document assumes that you will be able to install your own SLACKWARE system. However, there are several different things that could crop up during the install and confuse a new user. For information on installation, refer to the "Getting Started Guide" in the installation section.

While you are doing the installation, you will be asked if you would like to install a number of different packages. For the purposes of simplicity, I have provided a specific list of software packages that you *might* want to install. Please note that these are NOT the only packages you can install - this is only a suggestion, and is based upon the proxy servers that we have personally put together. If all you want is a basic proxy server and you don't want to do any hard thinking, just take my word for it.  If you know what you are doing, by all means install whatever you like.

Install the following packages:
 
 

A

AP

D

F

K

N

TCL

X

XAP

When selecting the packages, there are required options. Leave the required options, and *also* select the following:
 

[A]	[AP]	[D]	[F]	[K]	[N]	[TCL]	[X]	[XAP]
Ide	Manpgs	Binutils	Manyfaqs	Lx2034	Apache	Tcl	X332svga	Fvwm95
Bsdlpr	Groff	Bison	Mini	Linuxinc	Procmail	Tk	<ENTER>	Libgr
Loadlin	Diff	Byacc	Howto1		Ppp	Tclx	Oldlibs5
Pnp	Sudo	Egcs			Mailx		Oldlibs6
Getty	Jed	Gdb			Tcpip1		Lesstif
aoutlibs	Joe	Gcl			Tcpip2		Ltstatic
Cpio	Md	Gmake			Bind		X332doc
Gpm	Quota	Libc			Rdist		X332man
Zoneinfo	Texinfo	Libcinfo			Lynx		X332f100
	Ash	Linuxinc			Elm
	Zsh	M4			Pine
		Ncurses			Sendmail
		Perl			Metamail
		Pmake			Smailcfg
		Rcs			Tin
		Strace			Netpipes
		Terminfo

With this set of installation options, you should have a fully functional Linux machine. However, you will probably need to do some more work to get everything up and running. For now, log into your machine as root, and set a password.

Configuring your ethernet cards and setting up the firewall:

At this point, you probably have a machine with Linux installed, but no networking. Now you will have to compile your OWN kernel to enable IP masqurading. This is a common task for LINUX administrators.  For those who are new to the process, re-compiling the kernel basically allows you to specify exactly which devices and services you will need support for, and actually create a customized system.  This is necessary when you make hardware changes, for example, because one kernel might be set up to support an NE2000 ethernet card, while another might only work with a SMC card.  In any event, you will want to put together your own kernel at this point.  To do this, refer to the "Getting Started Guide" under "Upgrading the Kernel." Make sure that you install a LINUX kernel version 2.0.34 or later because it has many valuable updates. You can download the kernel source from ftp://sunsite.unc.edu/pub/Linux/kernel/v2.0 if you wish. It is a good idea to always run the latest stable kernel.

Make sure that when you are configuring your kernel, you make sure to set up all of the options needed for IP Masquerading! The IP Masquerading howto suggests that you use the following options to enable Masquerading in the kernel:

 Here are the options that you need to compile in:

     Say YES to the following,

    * Prompt for development and/or incomplete code/drivers
      CONFIG_EXPERIMENTAL
      - this will allow you to select experimental ip_masq code compiled
        into the kernel

    * Enable loadable module support
      CONFIG_MODULES
      - allows you to load modules

    * Networking support
      CONFIG_NET

    * Network firewalls
      CONFIG_FIREWALL

    * TCP/IP networking
      CONFIG_INET

    * IP: forwarding/gatewaying
      CONFIG_IP_FORWARD

    * IP: firewalling
      CONFIG_IP_FIREWALL

    * IP: masquerading (EXPERIMENTAL)
      CONFIG_IP_MASQUERADE
      - although it is experimental, it is a *MUST*

    * IP: always defragment
      CONFIG_IP_ALWAYS_DEFRAG
      - highly recommended

    * Dummy net driver support
      CONFIG_DUMMY
      - recommended

Once you have the new kernel in place, reboot the system. Assuming that you have your Ethernet card working, you should be able to communicate over the network. First of all, use the SHFT-PGUP key to scroll through the boot messages. Alternately, you can type 'dmesg' at the command prompt to list boot messages.  If you are lucky, you will see a line that looks similar to this:

NE*000 ethercard probe at 0x300: 00 80 c8 34 2a cf
Eth0: NE2000 found at 0x300, using IRQ 5

Note:  If you are able to connect to your LINUX box but find that it freezes for several minutes before giving you a login prompt, you probably have a network communication error or DNS configuration error

Now that you have gotten your first ethernet card working, you have to get two of them working at the same time. This set can take some time! You will need to configure your two ethernet cards for different IRQ and base address settings. In general, it's best to configure one card at a time, boot with that card, and then verify that it works. Then, boot with the second card, and verify that that one works. If both cards work alone, put them in simultaneously, and see if they work together.

 IMPORTANT: Before Linux can recognize TWO ethernet cards simultaneously, you will have to make a change in your lilo boot config. The easy way to do this is to edit your /etc/lilo.conf file, and add a line which says:

append ="ether=0,0,eth1"

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
boot = /dev/hda
#compact # faster, but won't work on all systems.
delay = 50
vga = normal # force sane state
ramdisk = 0 # paranoia setting
# End LILO global section
# Linux bootable partition config begins
image = /vmlinuz
append = "ether=0,0,eth1"
root = /dev/hda2
label = Linux
read-only # Non-UMSDOS filesystems should be mounted read-only for checking
# Linux bootable partition config ends
# DOS bootable partition config begins
other = /dev/hda1
label = dos
table = /dev/hda
# DOS bootable partition config ends

Once you have made this change, type lilo at a shell prompt. This will commit the changes you made in lilo.conf. Now, you should be able to reboot and have support for multiple ethernet.

If this doesn't work, your kernel was probably not able to auto-detect the second network card in your system.  In this case, you can force lilo to use specific IRQ and Base Address combinations for your card.  An example of an append that uses 3 network cards (2 ne2000s and a PCI 100mb card) is as follows:

append = "ether=10,0x6000,eth0 ether=5,0x320,eth1 ether=3,0x300,eth2"

If you know what your card resources are, you can specify it in this format - IRQ, base address, and the device name that Linux should call it.

Once you have verified that your system can recognize both cards simultaneously, you will then need to configure the second ethernet card. A default slackware installation puts all of the ethernet configuration commands in a file called /etc/rc.d/rc.inet1. You will need to add a couple of configuration lines at the end of this file:

/sbin/ifconfig eth1 10.0.0.1
/sbin/route add -net 10.0.0.0 eth1

#! /bin/sh
#
# rc.inet1      This shell script boots up the base INET system.
#
# Version:      @(#)/etc/rc.d/rc.inet1  1.01    05/27/93
#
 
HOSTNAME=`cat /etc/HOSTNAME`
 
# Attach the loopback device.
/sbin/ifconfig lo 127.0.0.1
/sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo
 
# IF YOU HAVE AN ETHERNET CONNECTION, use these lines below to configure the 
# eth0 interface. If you're only using loopback or SLIP, don't include the
# rest of the lines in this file.
 
# Edit for your setup.
IPADDR="128.127.50.1"   # REPLACE with YOUR IP address!
NETMASK="255.255.0.0"   # REPLACE with YOUR netmask!
NETWORK="128.127.0.0"   # REPLACE with YOUR network address!
BROADCAST="128.127.255.255"     # REPLACE with YOUR broadcast address, if you
                        # have one. If not, leave blank and edit below.
GATEWAY="128.127.50.1"  # REPLACE with YOUR gateway address!
 
# Uncomment the line below to configure your ethernet card.
/sbin/ifconfig eth0 ${IPADDR} broadcast ${BROADCAST} netmask ${NETMASK}
 
# If the line above is uncommented, the code below can also be uncommented.
# It sees if the ethernet was properly initialized, and gives the admin some
# hints about what to do if it wasn't.
if [ ! $? = 0 ]; then
cat << END
Your ethernet card was not initialized properly. Here are some reasons why this
may have happened, and the solutions:
1. Your kernel does not contain support for your card. Including all the 
network drivers in a Linux kernel can make it too large to even boot, and
sometimes including extra drivers can cause system hangs. To support your
ethernet, either edit /etc/rc.d/rc.modules to load the support at boottime,
or compile and install a kernel that contains support.
2. You don't have an ethernet card, in which case you should comment out this
section of /etc/rc.d/rc.inet1. (Unless you don't mind seeing this error...)
END
fi
 
# Uncomment these to set up your IP routing table.
/sbin/route add -net ${NETWORK} netmask ${NETMASK} eth0
if [ ! "$GATEWAY" = "" ]; then
/sbin/route add default gw ${GATEWAY} netmask 0.0.0.0 metric 1
fi
 
/sbin/ifconfig eth1 10.0.0.1
/sbin/route add -net 10.0.0.0 eth1
 
# End of rc.inet1

NOTE: This is a default slackware configuration - only the last two commands have been added since the original installation.

Once you have set your lilo configuration, and have added your configuration commands for the second ethernet card, you should be ready to utilize the second ethernet card. Reboot your machine, and watch the boot messages. In particular, you should see messages saying that each of the ethernet cards was found, and that they were assigned as eth0 and eth1. I suggest that you label which card is which in some way. I use a label maker to do this, but you could do it with a pencil or something.

Now, log into your Linux box, and check your network config using the ifconfig command. You should see output similar to the following:
 

lo Link encap:Local Loopback 
        inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
        UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
        RX packets:56 errors:0 dropped:0 overruns:0
        TX packets:56 errors:0 dropped:0 overruns:0
 
eth0 Link encap:10Mbps Ethernet HWaddr 00:80:C8:34:2A:CF
        inet addr:128.127.50.1 Bcast:128.127.255.255 Mask:255.255.0.0
        UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
        RX packets:1723 errors:0 dropped:0 overruns:0
        TX packets:148 errors:0 dropped:0 overruns:0
        Interrupt:5 Base address:0x300 
 
eth1 Link encap:10Mbps Ethernet HWaddr 00:80:C8:34:2A:D1
        inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0
        UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
        RX packets:104 errors:0 dropped:0 overruns:0
        TX packets:75 errors:0 dropped:0 overruns:0
        Interrupt:10 Base address:0x320

If you see that your eth1 card is configured, you are in good shape. If the card is plugged into an active network, you should see the packet count increment as well.

As you have noticed, we have configured eth1 for the tcp/ip address 10.0.0.1. This IP network address is one of the few reserved for experimentation and internal networks. By using this IP address for your "private" network, you will ensure that you don't accidentally use a REAL IP address, and thereby mess someone up. I repeat, do not use a real IP address. If you have real IP addresses that you want to use, you don't really need to use masquerading - you can just make a simple firewall. In any event, using 10.0.0.1 keeps things safe and consistent. When you are configuring your TCP/IP clients for the inside of the firewall (win'95, mac, Unix, etc.) you will want to use the following parameters:
 
 
 

Netmask	255.0.0.0
Broadcast	10.255.255.255
Network	10.0.0.0
IP address	10.X.X.X	(whatever you want, but don't use #'s 1,255, or the IP of the firewall)
Gateway	10.0.0.1	(points all traffic not for local net to the linux box for masquerading)

 

Once you have verified that eth1 is working you will want to test your configuration. First, plug your eth1 card into a hub, and configure a machine (your win95 workstation?) to use the 10.0.0.0 network. Once you have done this, you should be able to ping, and log into your linux box over eth1. If all goes well, it should work just fine. While you are logged in through eth1, you should then be able to telnet out to the real Internet.

NOTE: This kind of configuration is what is known as a "dual-homed" firewall. That is to say, it has two different homes or realms: the REAL (and hostile) Internet, and the FAKE (and safe) private network. Many people stop here, and use this configuration for their firewall. This is an adequate way of configuring a firewall if you don't need true TCP/IP on the workstations in your private network. However, because your private network is segmented from the real Internet, workstations cannot directly access the Internet. All they can do is log into your linux box, and then hop out the net from there. The main problem with this configuration is that you need complete faith in your users not to abuse the firewall and/or cause a security breech on it.

The next step is to configure the firewall machine to pass traffic from the private network to the Internet. Again, I suggest you read up on how masquerading works before you continue with the next steps. All of the functionality needed for setting up masquerading is included by default in the Slackware distribution. We will need to add some commands to configure the masquerading. I suggest creating a file called /etc/rc.d/rc.firewall to contain your configuration commands. My /etc/rc.d/rc.firewall file looks like this:

• chmod u+x /etc/rc.d/rc.firewall

echo "Configuring firewall..."
/etc/rc.d/rc.firewall

This will cause the rc.firewall file to be run every time your system boots. Now, reboot your system once again. This time, you will want to test the setup by telneting from the computer on your 10.0.0.0 network out to a real internet host. If all of your configurations are correct, you should be able to telnet from the fake network out, as if you had a real IP address!

Please be aware that there are a LOT of different ways to configure your firewall software. The configuration that I have given above simply denies outside access to your private network, and gives unlimited outgoing access to your clients. You have a great deal of flexibility in how you configure this. For example, you may wish to have computer labs follow different rules than administrative machines. At the end of this document, I will discuss some of the different configuration options you might want to consider. At this point, you now have a masquerading firewall! You should be able to start plugging machines into your 10.0.0.0 network and start happily accessing the Internet.

The next step in creating a masquerading proxy server is to set up the proxy component. In this case, we will use the Squid Internet Object Cache. I highly suggest you read the web pages first, but in general, the object cache allows us to cache and proxy HTTP, FTP, WAIS, and Gopher data from the Internet, and thereby improve our access times. The best thing about the Squid Cache is that once any client on your network accesses a page (for example the Netscape welcome) it is committed to cache. The next person who tries to access that page will then pull it directly from the proxy server, instead of going out to fetch it from the Internet. This greatly improves the speed at which you can get a document, and also has the very positive side effect of reducing traffic on the net itself. Thus, using a cache is not only good for your organization, it's good for everyone else, too!

Installing the Squid Internet Object Cache:

Now that you have your masquerading firewall set up, you will want to install the Squid Internet Object Cache. This will allow you to efficiently proxy HTTP, FTP, and other types of traffic. Squid also allows a certain amount of control over who can access information, and what they can see.

First of all, you will need to download the latest stable Squid software. You can get the sources from: ftp://squid.nlanr.net/pub. Once you have the binary, unzip it and compile the software with the following steps. It's a good idea to read the README files before continuing with the configure and make steps. In particular, if you know ahead of time that you will want to enable authorization support for the proxy, you will want to read up the instructions at the end of this document. These instructions work for the version I downloaded without authorization support, but there is no guarantee they will work with later (or earlier) versions. Obviously, you will need to replace the version numbers with whatever you download. We used squid-1.1.22-src.tar.gz as an example.

• mkdir /development
• cp squid-1.1.22-src.tar.gz /development
• cd /development
• tar -xzf squid-1.1.22-src.tar.gz
• cd squid-1.1.22
• configure --prefix=/usr/local/squid
• make all
• make install

# TAG: cache_effective_user
# If the cache is run as root, it will change its effective/real
# UID/GID to the UID/GID specified below. The default is not to
# change UID/GID.
#
#cache_effective_user nobody nogroup

You will want to uncomment (remove the # from) that last line, so that your line now reads:

# TAG: cache_effective_user
# If the cache is run as root, it will change its effective/real
# UID/GID to the UID/GID specified below. The default is not to
# change UID/GID.
#
cache_effective_user nobody nogroup

This will allow you to start the Squid cache as root, and have the program itself run as the user nobody. If you do not do this, Squid will complain and stop running. Since you have just changed the account that Squid runs as, you will also need to change the directory rights over to that user. In addition, you will need to use the 'squid -z' command to create your cache directories.  I suggest the following commands to do this:

• cd /usr/local
• chown -R nobody:nogroup squid
• cd squid/bin
• squid -z
• cd ..
• chown -R nobody:nogroup cache
• cd ..
• chmod -R o-rwx squid

echo "Running Squid Cache..."
/usr/local/squid/bin/RunCache &

IMPORTANT:  You WILL need to configure an ACL (Access Control List) within Squid if you wish to keep your proxy server private and limited to clients on your private firewalled network.  If you do not do this, external users will be able to use your cache which can not only hog your bandwidth but also make intrusive web use appear to come form your system!  There are many more features in the Squid cache program. I highly suggest you read the documentation and configure it correctly. Be very cautious when using this program! If it is misconfigured, it can easily be used to access information on your private firewalled network, and pass it to the outside world!

Also, Squid has many options for setting the cache parameters and tuning performance.  Please consult the Squid home page for more information on making your cache run efficiently.

At this point, your Masquerading proxy server should be more or less set up. All of the basic functionality is there, but there is still a lot more you can do with it. Again, read up on the different abilities of the software for more information.
 

Requiring a user to use the Squid Cache:

Once you have gotten the basic functions working, you will probably want to modify your proxy server configurations. There are various things that you might want to change.

First of all, you might wish to enforce some kind of security on your proxy server. The server, as it stands, allows anyone from the fake network to use all of its functions. But say, for example, that you wanted to require a password to access the world wide web. This is fairly easy to do. Because Squid is able to require authentication to use the cache, you can easily do this. First of all, you will need to disallow HTTP traffic through the firewall. Because most web traffic uses port 80, this is fairly easy to do. You will need to add a line to your /etc/rc.d/rc.firewall file which reads:

ipfwadm -F -a deny -P tcp -S 10.0.0.0/255.0.0.0 -D 0.0.0.0/0 80

ipfwadm -F -f
ipfwadm -I -f
ipfwadm -O -f
ipfwadm -F -p deny
ipfwadm -F -a deny -P tcp -S 10.0.0.0/255.0.0.0 -D 0.0.0.0/0 80
ipfwadm -F -a masquerade -P tcp -S 10.0.0.0/255.0.0.0 -D 0.0.0.0/0
ipfwadm -F -a masquerade -P udp -S 10.0.0.0/255.0.0.0 -D 0.0.0.0/0

This will stop all traffic which uses port 80 at the firewall. From the workstation, it will appear as if there is simply no connection to the internet. Thus, it will be necessary for a user to use the Squid Cache to get HTTP data. This is good for a number of reasons. First of all, this makes sure that users have to use the cache for their data and don't have the ability to hog bandwidth by not using the cache. Secondly, of course, you can require a username/password combination which is assigned by a system administrator. Thirdly, all of the transactions through the Squid cache can be logged, allowing you to see what and where people have gone on the web. Lastly, the Squid cache can be configured to filter certain web sites, such as those deemed unacceptable by your organization.

Once you have filtered the traffic at the firewall, you will need to set up your password file. For this, you will need to have the htpasswd program on your machine. You can download a linux version of htpasswd from my web site at http://scnc.holt.k12.mi.us/~lachniet/proxy/htpasswd. If you prefer, you can get the source code from http://scnc.holt.k12.mi.us/~lachniet/proxy/htpasswd.c and compile it yourself. Download that program, and copy it to /usr/local/squid/etc. Also, you might need to make it executable and restrict its use by other users. To do this, type:

• chmod u+x /usr/local/squid/etc/htpasswd
• chmod o-rwx /usr/local/squid/etc/htpasswd

#proxy_auth /dev/null

proxy_auth /usr/local/squid/etc/access.list

AUTH_OPT = # -DUSE_PROXY_AUTH=1

AUTH_OPT = -DUSE_PROXY_AUTH=1

Note:  I have noticed that on some occasions, Squid will fail to re-install correctly, and give an error about not running the program as root (even though you aren't.) Hopefully this will not happen, but if it does you will probably want to wipe out the whole Squid directory and start again. If you follow the below steps, you will copy your squid.conf to a safe directory (in this case /development) before nuking it, and then copy it back afterwards. To do this, follow these instructions

• cp /usr/local/squid/etc/squid.conf /development
• rm -R /usr/local/squid
• cd /development/squid-1.1.22
• make clean install
• chown -R nobody:nogroup /usr/local/squid
• su nobody
• cd /usr/local/squid/bin
• squid -z
• exit
• chown -R nobody:nogroup /usr/local/squid/cache
• chmod -R o-rwx /usr/local/squid
• cp /development/squid.conf /usr/local/squid/etc

Now, you need to set up your htpasswd file. To do this, we will create a temporary test user:

• cd /usr/local/squid/etc
• htpasswd -c access.list test (type in the password twice)

Securing your Proxy Server:

DON'T TAKE MY WORD FOR IT!

I have to say this before we go any further.  Securing a Linux box is just about impossible if you give out accounts to people.  Read up on issues of security on your own.  My precautions may not be enough, or worse, may be wrong.

What you will definitely want to do is to secure your proxy server. There are a lot of variables when it comes to securing Linux boxes. In general, the best way to secure a linux box is to turn off all of the services and deny access to TCP/IP services to every machine except for one. Obviously, this isn't going to work if you are running a lot of applications on your server. However, I highly suggest that you set up a dedicated Linux box for nothing more than a firewall and proxy server. If nothing else, it reduces the load on your server.

The first thing you will want to do is to restrict access to the TCP/IP services on the machine. The simplest way to do this is to modify your /etc/hosts.deny file, and add a line which reads:

ALL:ALL

Thus, your complete /etc/hosts.deny file should look like this:
 

# hosts.deny    This file describes the names of the hosts which are
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# Version:      @(#)/etc/hosts.deny     1.00    05/28/93
#
# Author:       Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org
#
#
ALL:ALL
# End of hosts.deny.

Unless you don't mind going to your servers every time you need to make a change, you will probably want to allow access to SOME machine on your network for management purposes. To do this, you can add entries to your /etc/hosts.allow table for a certain workstation (such as your Win'95 workstation.) This looks very similar to the hosts.deny, but instead type:

ALL:10.0.0.2

#
# hosts.allow   This file describes the names of the hosts which are
#               allowed to use the local INET services, as decided by
#               the '/usr/sbin/tcpd' server.
#
# Version:      @(#)/etc/hosts.allow    1.00    05/28/93
#
# Author:       Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org
#
#
ALL:10.0.0.2
# End of hosts.allow.

Bear in mind that using the hosts.allow and hosts.deny files will only work with programs that are called by TCPD. If you are running server daemons, such as a web server or SAMBA, you will have to disable these as well. In general, you will want to remove any programs which are not absolutely essential from your /etc/rc.d/rc.M and /etc/rc.d/rc.local (on a Slackware system) files. I would certainly comment out sendmail, lpd, and httpd.

One way to do this is to simply put a hash mark (#) in front of the actual command that calls the program. For example, this is a copy of a working (but secured) /etc/rc.d/rc.M file:

#!/bin/sh
#
# rc.M          This file is executed by init(8) when the system is being
#               initialized for one of the "multi user" run levels (i.e.
#               levels 1 through 6).  It usually does mounting of file
#               systems et al.
#
# Version:      @(#)/etc/rc.d/rc.M      2.02    02/26/93
#
# Author:       Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org
#               Heavily modified by Patrick Volkerding <volkerdi@ftp.cdrom.com
#

# Tell the viewers what's going to happen...
echo "Going multiuser..."

# Screen blanks after 15 minutes idle time.
/bin/setterm -blank 15

# Look for a CD-ROM in a CD-ROM drive, and if one is found,
# mount it under /cdrom.  This must happen before any of the
# binaries on the CD are needed.
#
# If you don't have a CD-ROM and want to disable this, set the
# /etc/rc.d/rc.cdrom permissions to non-executable: chmod 644 /etc/rc.d/rc.cdrom
#
if [ -x /etc/rc.d/rc.cdrom ]; then
  . /etc/rc.d/rc.cdrom
fi

# Start crond (Dillon's crond):
# If you want cron to actually log activity to /var/adm/cron, then change
# -l10 to -l8 to increase the logging level.
/usr/sbin/crond -l10 /var/adm/cron 2&1

# If there's no /etc/HOSTNAME, fall back on this default:
if [ ! -r /etc/HOSTNAME ]; then
 echo "darkstar.frop.org" /etc/HOSTNAME
fi

# Set the hostname.  This might not work correctly if TCP/IP is not
# compiled in the kernel.
/bin/hostname `cat /etc/HOSTNAME | cut -f1 -d .`

# Initialize the NET subsystem.
if [ -x /etc/rc.d/rc.inet1 ]; then
  . /etc/rc.d/rc.inet1
  . /etc/rc.d/rc.inet2
else
  if [ -x /usr/sbin/syslogd ]; then
    /usr/sbin/syslogd & # Backgrounded to avoid an ugly notice from bash-2.0
    /usr/sbin/klogd
  fi
#  if [ -x /usr/sbin/lpd ]; then
#    /usr/sbin/lpd
#  fi
fi

# Remove stale locks (must be done after mount -a!)
/bin/rm -f /var/spool/locks/* /var/spool/uucp/LCK..* /tmp/.X*lock /tmp/core 1 /dev/null 2 /dev/null

# Remove stale hunt sockets so the game can start.
if [ -r /tmp/hunt -o -r /tmp/hunt.stats ]; then
  echo "Removing your stale hunt sockets from /tmp..."
  /bin/rm -f /tmp/hunt*
fi

# Ensure basic filesystem permissions sanity.
chmod 755 /
chmod 1777 /tmp /var/tmp

# Update all the shared library links automatically
/sbin/ldconfig

# Start the sendmail daemon:
#if [ -x /usr/sbin/sendmail ]; then
#  echo "Starting sendmail daemon (/usr/sbin/sendmail -bd -q 15m)..."
#  /usr/sbin/sendmail -bd -q 15m
#fi

# Load a custom screen font if the user has an rc.font script.
if [ -x /etc/rc.d/rc.font ]; then
  . /etc/rc.d/rc.font
fi

# iBCS Emulation for Linux
# The Intel Binary Compatibility Specification, or iBCS, specifies the
# interfaces between application programs and the surrounding operating
# system environment for i386 based systems. There are however several
# flavours of iBCS in use - SVR4, SVR3 plus several vendor specific
# extensions to SVR3 which are slightly different and incompatible. The
# iBCS emulator for Linux supports all flavours known so far.
if [ -x /etc/rc.d/rc.ibcs2 ]; then
  . /etc/rc.d/rc.ibcs2
fi

# Start Web server:
#if [ -x /etc/rc.d/rc.httpd ]; then
#  . /etc/rc.d/rc.httpd
#fi

# Load a custom keymap if the user has an rc.keymap script.
if [ -x /etc/rc.d/rc.keymap ]; then
  . /etc/rc.d/rc.keymap
fi

# Start the local setup procedure.
if [ -x /etc/rc.d/rc.local ]; then
  . /etc/rc.d/rc.local
fi

# All done.

I would also suggest that you disable some of the other servers, such as the NFS servers that are called from /etc/rc.d/rc.inet2. An example of a crippled rc.inet2 file is as follows:

#!/bin/sh
#
# rc.inet2      This shell script boots up the entire INET system.
#               Note, that when this script is used to also fire
#               up any important remote NFS disks (like the /usr
#               distribution), care must be taken to actually
#               have all the needed binaries online _now_ ...
#
# Author:       Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org
#

# Constants.
NET="/usr/sbin"
IN_SERV="lpd"
LPSPOOL="/var/spool/lpd"

# At this point, we are ready to talk to The World...
echo "Mounting remote file systems..."
/sbin/mount -a -t nfs           # This may be our /usr runtime!!!

echo -n "Starting daemons:"

# Start the SYSLOGD/Klogd daemons.  These must come first.
if [ -f ${NET}/syslogd ]; then
  echo -n " syslogd"
  ${NET}/syslogd & # Backgrounded to avoid an ugly notice from bash-2.0
  echo -n " klogd"
  ${NET}/klogd
fi

# Start the SUN RPC Portmapper.
#if [ -f ${NET}/rpc.portmap ]; then
#   echo -n " portmap"
#   ${NET}/rpc.portmap
#fi

# Start the INET SuperServer
if [ -f ${NET}/inetd ]; then
  echo -n " inetd"
  ${NET}/inetd
else
  echo "no INETD found.  INET cancelled!"
  exit 1
fi

# # Start the NAMED/BIND name server.
# if [ -f ${NET}/named ]; then
#   echo -n " named"
#   ${NET}/named
# fi

# # Start the ROUTEd server.
# if [ -f ${NET}/routed ]; then
#   echo -n " routed"
#   ${NET}/routed -g -s
# fi

# # Start the RWHO server.
# if [ -f ${NET}/rwhod ]; then
#   echo -n " rwhod"
#   ${NET}/rwhod -t -s
# fi

# Start the various INET servers.
for server in ${IN_SERV} ; do
  if [ -f ${NET}/${server} ]; then
    echo -n " ${server}"
    ${NET}/${server}
  fi
done

# # Start the various SUN RPC servers.
#if [ -f ${NET}/rpc.portmap ]; then
#  # Start the NFS server daemons.
#  if [ -f ${NET}/rpc.mountd ]; then
#    echo -n " mountd"
#    ${NET}/rpc.mountd
#  fi
#  if [ -f ${NET}/rpc.nfsd ]; then
#    echo -n " nfsd"
#    ${NET}/rpc.nfsd
#  fi
#  # Fire up the PC-NFS daemon(s).
#  if [ -f ${NET}/rpc.pcnfsd ]; then
#    echo -n " pcnfsd"
#    ${NET}/rpc.pcnfsd ${LPSPOOL}
#  fi
#  if [ -f ${NET}/rpc.bwnfsd ]; then
#    echo -n " bwnfsd"
#    ${NET}/rpc.bwnfsd ${LPSPOOL}
#  fi
#fi # Done starting various SUN RPC servers.

# The 'echo' below will put a carriage return at the end
# of the list of started servers.
echo

# # Setting up NIS:
# # (NOTE: For detailed information about setting up NIS, see the
# #  documentation in /usr/doc/yp-clients and /usr/doc/ypserv)
# #
# # First, we must set the NIS domainname.  NOTE: this is not
# # necessarily the same as your DNS domainname, set in 
# # /etc/resolv.conf!  The NIS domainname is the name of a domain
# # served by your NIS server.
#
# if [ -r /etc/defaultdomain ]; then
#   domainname `cat /etc/defaultdomain`
# fi
#
# # Then, we start up ypbind.  It will use broadcast to find a server.
#
# if [ -d /var/yp ] ; then
#   echo "Running ypbind..."
#   /usr/sbin/ypbind 
# fi

# Done!

Another way to manage services on your LINUX box is to by editing your /etc/inetd.conf file.  This file tells the inetd program which services to provide.  This feature is documented in the system man pages - try 'man inetd' for more information.

When all of this is done, you should have a relatively secure proxy server.  Again, don't take my word for it!  There is a program out there called chkexploit which might help you.  It is a sophisticated bourne script which will check your box for known hacks.  Pay careful attention to exploits which can be remotely exploited (like IMAPD) or pay attention to ALL exploits if you give out accounts of any kind on your firewall machine. Also, I highly suggest you consider joining a security listserv such as bug-traq at http://netspace.org.

Lastly, give thanks to all of the people who made this wonderful software available to you.  They are the ones who did all of the hard work and continue to make LINUX the beauty of an OS that it is.  Together we will improve the world with FreeWare!

 NOTE FROM THE AUTHORS: We have done our best to make this document logical, readable, and technically correct. However, if you see any errors in my instructions, or if you have suggestions about anything therein, please send us a quick E-Mail at the addresses listed at the begining of this document.