This page describes the installation and configuration of a dedicated server intended to service the communications of my home network out over the internet via my @home cable modem.   The result at the end should be a fully functional Linux box, which will serve not only as a single point of internet access for my multiple machines, but as an inexpensive and relatively secure firewall.   I'll describe what I did on the first go around and will later post updates on my updates page as I progress and/or further upgrade it.

Red Hat 5.2 install
One of the very first Linux distributions that I had installed by myself as a newbie, was Red Hat's 5.2 version (originally on my Presario 1267 notebook).   I subsequently removed the 5.2 and installed SuSE 6.1 on that notebook.   Shortly after trying the 5.2, Red Hat released its 6.0 and then later, its 6.1 version.   Normally not minding going for the "bleeding edge", I decided however, to stick with the relatively stable 5.2, with kernel 2.036, rather than go for the later versions - at least for this project (I do now have RH 6.0 installed at work and a RH 6.1 variant, ie., Mandrake, installed on my multimedia machine).   The 5.2 version has a number of updates and security fixes that can easily be obtained and installed on the system, all without the need for a reboot.   With those updates and fixes, I have found that so far, my up-to-date 5.2 is pretty rock solid.

The distribution was initially obtained when I purchased the SAMS book "Red Hat Linux Unleashed, 3rd edition", written by David Pitts and Bill Ball.   An enormous and certainly comprehensive book, I regularly use it as one of many reference guides that I've been accumlating.   I later purchased the official distribution, which comes with the Red Hat manuals, source code, and a number of applications.

Since this is a newer machine, it will boot from CDROM, and that is what I did.   You can also boot to floppy by creating one (you would need to do this with the book version, ie., either by using the DOS-based "rawrite" utility and installing a boot image to the floppy or by downloading any one of a number of available boot images from the web... the boxed version of RH 5.2 comes with a bootable install disk).   The install itself is a "typical" Red Hat text-based install, which one will often recognize when installing any of the RH variants, such as Mandrake or TurboLinux... basically, you select your language, keyboard type, install media type (eg., CDROM, hard drive, NFS, FTP), and whether you want a "workstation", "server", or "custom" install.   In most cases, I've chosen "custom" so that I could create my own partitions and mount points, but in this case, I chose the "server" install, and let RH do its thing.   In that mode, RH will assume the entire device belongs to it and will create the partitions and mount points for you, automatically formatting the entire thing for ext2.   Since this machine is 100% windoze-free, that was not a problem.   If you intend to dual-boot with some other OS or distro of Linux, you should select the "custom" install, as RH (noted previously) will take the whole thing for itself, IF you have a single hard drive and choose either the "server" or the "workstation" install.

On this machine, the server install took less than 30 minutes, and RH selected the packages most commonly used in a server configuration.   You need to make a note of and select which services you want automatically started at server boot, and here is where your security research will come in handy.   You must decide whether you want to enable or disable application-level services such as FTP and Telnet, etc.   In addition, all of the "remote" services, such as ruser and other "r" services, should probably be turned off.   If you don't have any Apple products, such as the Macs, on your internal network nor intend to connect to a Novell network, related apps and/or protocols such as netatalk, SAMBA, and IPX should be turned off.   In essence, turn off everything you know that you won't be using.   For example, it is best to let your proxy/firewall be just that - a proxy/firewall, and not also function as say, a file/print server, a Web server, or mail server.   Thus, turn off your Apache and Sendmail (or don't even install those apps).   Sendmail, as useful as it has been over the years, has often been an extremely "exploitable" service that has been known to be the entry point (via its assigned ports) for many a resourceful cracker, so if you really need it for your internal network, enable it on some other machine in your internal network.   Some apps that you do want installed/enabled are "tcpdump" and "tcpwrappers".   These will help to secure your TCP communications.   With the newer distros, these are usually installed and enabled by default.

Often a good rule of thumb is to turn off everything, basically locking your firewall machine completely down, and then gradually turn back on only those services necessary for you to function and/or administer the machine.   As a note, you may want to have "internal" FTP and/or Telnet access to your proxy/firewall from your main workstation, and in that case, you can enable both services, but use the files "hosts.deny" and "hosts.allow" (or the equivalently-named config files in other distros), to disallow all outside access to those services and only permit "internal" access, ie., via your own assigned "restricted" IP addresses, eg., the "192.168.x.x" series.   Properly configured, all external addresses attempting to Telnet, FTP, or HTTP to your firewall will be "refused connection".   Your syslog, with additional help from available supplemental syslog apps out there (to be described later in an update), will allow you to monitor the logging of these unauthorized attempts.

To wrap up this install section, I'll note that RH will allow you to configure an X server for your machine, networking (note that with a proxy/firewall, you will need to configure 2 network cards - the install will do the first one for you and you'll need to know the IPs of your ISP's gateway, DNS, etc., unless you decide to run a DNS internally using BIND, and then you need to refer to it), and will create your root account.   When completed, you will reboot into your new system and it will be ready to configure.

Networking
One thing you will need to determine is whether your proxy/firewall's kernel offers and is enabling what is known as "ip forwarding", ie., the ability to take your internal network's data and forward it out to wherever, eg., the internet, and "ip masquerading", the ability to "mask" your internal machine addresses behind the proxy's "valid" IP address.   For many kernels, ip forwarding is turned off.   You will need to check your kernel to make sure that this feature and all related IP features are turned on.   In addition, you'll need to ensure that "module support" is also turned on.   You can do all of this by decompiling your kernel and checking it's source configuration (if you don't have the source files loaded, then you'll need to go back to your distro and load those files - in RH, they are available as "source" or "development" packages, eg., "kernel-xxx.yyy.rpm").   Once you have your kernel source, go to it's directory and if you don't use X, you can select a console and do a "make config" or "make menuconfig" to begin the kernel decompile process.   In X, you can do the same with a "make xconfig".   I'm not going to go into recompiling a kernel here, but you can use the "Kernel-HOWTO", written by Brian Ward, to find out the details on how to do this!   Once you've confirmed that ip forwarding and masquerading is turned on, you should be ready to go to the next step.

As previously noted, when you create a proxy/firewall, you will need to configure 2 network cards.   Basically, one card will be dedicated to servicing your "internal" network and the 2nd will be assigned your "official", valid IP address on the internet.   Note that many ISPs do not or cannot assign "fixed" IPs and thus you're assigned an address via "DHCP" (Dynamic Host Configuration Protocol), whereby your assigned IP is "renewed" each time you reboot, reconnect, and/or during fixed time intervals, eg., once an hour or once every x number of days.   In my case, my cable modem ISP has assigned me a fixed address, although they say that they will try as much as possible to keep it that way...!   Regardless, this makes it easier for me to manage my proxy/firewall.   In your case (and I have done this myself anyway), you will probably need to install and configure a DHCP client package, eg., "dhcpcd-xxx.yyy.rpm", the newest of which contains both a client and server piece.   Once installed on your proxy/firewall, your proxy/firewall will attempt to query your ISP's DHCP server for an address at boot time (if so configured).   NOTE: You will need to test this with your ISP, as many do not recognize a DHCP query from this package and are often only responsive to windoze or Mac queries.   In those cases, you may be forced to create a windoze-based proxy/firewall machine, and there are applications - commercial, shareware, and freeware, available to do this.   I am fortunate that in my local Comcast@home's case, their DHCP server will respond to my query (although I do have two, paid-for, "assigned" addresses) and Stealth has been consistently assigned the same address in all cases so far - mainly because Comcast appears to be using a "static" DHCP entry and hasn't enabled "dynamic" DHCP as yet.  Configuration-wise this makes things easier, however security-wise, many will correctly argue that a "moving target" is much harder to crack than a stationary one, and I agree.   In any case, one must keep this in mind and weigh the pros and cons of static versus dynamic IP address assignments and adjust the level of security on the proxy/firewall accordingly.

Moving right along to the workstation side of network configurations, be mindful that when you decide to take on a project like this, you will need to do some planning beforehand, ie., configuring your internal network with the restricted IP addresses, eg., the 192.168.0.0 - 192.168.255.255 series for Class C, or 172.16.x.x - 172.31.255.255 for Class B, or 10.0.x.x - 10.255.255.255 for Class A.   Most people at home can easily get by with a Class C home network and usually use the "192" address assignments for their machines.   As such, your proxy's "internal" network card will need to be assigned one of these 192 addresses, which will allow it to become the internet "gateway" for your machines, and many folks assign that card an address such as 192.168.0.1 or 192.168.1.1 - its all up to you.  Whichever address you choose, you must make sure that your other machines (including any windoze, Mac, Sparc, etc.) point to it as their gateway.   It is also useful to create your own network domain name, which will track back to the assigned addresses, eg., something like "myhomenetwork.net".   You could then name one of your machines "Myworkstation" and end up with a "fully qualified domain name" for that particular machine of "Myworkstation.myhomenetwork.net".   As with the numeric IP addresses, make sure that each of your machines is consistently named with whatever domain name you choose.   This can easily be done in a "hosts" file, that is found on every Linux distro and within most other networkable OSs, such as windoze.   Make sure that all versions of the host files, across all of your platforms, contain the same IP --> hostname assignments.

Now... where else can you do all of this configuring?   Well, most of the Linux distros come with a very useful utility called "Linuxconf".   This utility can be run from either a text console or from X.   One of the configuration options is for networking and it is here where you can tweek your intitial network card configuration and add the additional information for your 2nd card.   As noted previously, you'll need to enter info about your assigned internet IP and whether you will use DHCP to get an address, and you'll need to enter any domain name you've decided on for each card, plus enter IP address info for the external gateway(s) and DNS(s) of your ISP.   Once all of this info is entered and saved, you may want to reboot just to make sure everything is intialized properly.   Non-booters can usually do a kill -HUP pid on the various init services to do essentially the same thing or:

ifconfig eth0 down

and then:

ifconfig eth0 up

To double-check whether your proxy/firewall is communicating correctly, you can manually set the IP address and route from it to your ISP's gateway by using the ifconfig and route commands at a console, ie.,

ifconfig ethx {assigned IP} netmask {255.xxx.xxx.xxx} broadcast {xxx.xxx.xxx.255}

route add -net default gw {ip of ISP gateway} dev eth0

which assumes that your "external" network card is device "eth0" and your "internal" card is device "eth1".   Once done, you can simply type:

route

to confirm how your data is being routed.   Then you can check your entire configuration by using the ifconfig command:

ifconfig

and noting the info that is displayed on your network cards.   This is a useful command in that you can manually set the assigned addresses to your various network cards using it, for example:

ifconfig eth0 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255

which would manually assign your proxy/firewall's address to 192.168.1.1 and would provide the other necessary info needed to define your network.   Whether you configure your networking automatically, using Linuxconf, or manually, using route and ifconfig, all of this info is fed or would need to be fed into a file most commonly known as "resolv.conf".   Although some distros warn against manually editing this file, you could still do so to configure your network.   And as a note when manually configuring your network, make sure you use ifconfig first to setup your networking device then use route to configure your path.

Continuing with your network setup, it's often helpful to try to mentally envision the flow of your data from your internal workstations out to the internet, ie., data goes out the internal machine --> proxy/firewall gateway's "internal" network card --> your proxy/firewall's "external" network card --> ISP's gateway/router.   If you have a single, "internal" machine (other than your proxy/firewall), you could technically plug that machine directly into your proxy's "internal" network card and be ready to go to the next step.   If however, you have multiple machines like I do, you will need a network hub for all of your connections.   In my case, I have two hubs, one, a small, 4-port model, that has a UTP cable connected from the cable modem into the designated "uplink" port of the hub (Required!   Make sure that your hubs have an "uplink" port!) and a UTP connection from the proxy/firewall's "external" network card, into another available port on the same hub.   The second hub, an 8-port model, holds all of the UTP connections for my internal machines, and has a UTP connection from the "internal" network card of the proxy/firewall plugged into it as well.   In essence, I have separated the "external" network from my "internal" network by using two hubs and by having the proxy/firewall machine situated between them.   Below is basically how it looks:
 
 

        +---+                   +---+
        |   |    +---------+    | P |
        | A |----|  HUB 2  |--I-| R |      +---------+    +-------+
        |   |    +---------+    | O |-E----|  HUB 1  |----| CABLE |---> ISP
       [_____]          |       | X |      +---------+    +-------+
                     ___|___    | Y |
                    |   B   |  [_____]
                    |_______|



Where "A" & "B" are examples of two internally networked machines and "I" and
"E" denote the "internal" and "external" network cards, respectively.  As you
can see, everything has to go through the proxy server to get out on the
internet. As an alternate to what I have done, you could plug your cable
modem's UTP directly into your proxy's "external" network card and forgo the
extra hub.

Proxying/IP Masquerading
When you use a proxy server, ip masquerading must go hand in hand with it.   That's because your proxy server is "acting on behalf of" you internal machines whenever you wish to go out on the internet with them.   Enabling masquerading must be done due to the fact that you have just assigned your internal machines "restricted" IP addresses, ie., addresses that are, by convention, rejected as being "invalid" by all routers world-wide.   Thus somehow, your internal machine needs to obtain a "valid" address whenever you use it to communicate externally, and this is what ip masquerading will do for you.   Basically, your proxy will encapsulate your commands and/or other data with its own assigned and "valid" IP address and forward that out externally.   It will then keep track of who your machine is, and when it gets a response back for it, it will strip off its own address and then forward that response back to your internal machine's local address.

Generally, enabling ip forwarding and ip masquerading in the kernel will do this minimum function, however, if you need to perform "external" FTPs, you will need to load the module, ip_masq_ftp, which can be done manually at a console each time you boot the proxy using:

/sbin/modprobe ip_masq_ftp

or by putting the same command in the "rc.local" or "boot.local" script file in your distro (check your distro's manual to see which file applies to you and whether the ip_masq_ftp command is available.   Red Hat uses the "rc.local" file and you can place this command at the end of the script.)

This should basically be it for masquerading.   If you'd like to read up on it, look for a "mini-HOWTO" entitled "Linux IP Masquerade mini HOWTO", written by Ambrose Au and David Ranch.

You have in essence created a simple bridge or gateway, passing all of your data packets back and forth between your external and internal networks.  However it is prudent that you don't leave things this way!   You need to do something about "filtering", eg., totally blocking certain packets, and that's what the firewall will do.

Setting up the firewall
I will tell you right now that setting up a firewall manually is a very labor-intensive process, and unless you're really committed to doing it, I would recommend against it and urge you to look for utilities and/or "front end" packages that will do alot of the work for you.

In short, firewalling involves setting up what are known as "rules" that your machine will use to check each and every incoming data packet against, ie., determining whether to either "pass" the packet on or "reject" the packet outright.   In essence, this is what is known as "packet filtering" and the rules can become quite detailed and lengthy, depending on the type of data you transfer.   By default, if you assign the "restricted" IP addresses to all of your local machines but don't have ip masquerading enabled, no data from the "outside" destined for your local machines nor data from those very same machines destined for the "outside", will be passed, whether the firewall is enabled or not!  Of course, that will do you no good, thus make sure that masquerading is on, either on your firewall machine or some other that will serve as your proxy or "gateway".  Also, you will need to make sure that your distro has "ipfwadm" available and installed (for kernels 2.0.x) or the newer replacement, "ipchains" (for later kernels).   You would want to restrict access to the "well known" ports of your firewall machine, but then doing this correctly and comprehensively can be a tricky affair... I am not going to go into manually setting up rules using either of these tools here.  There are some excellent "HOW-TOs" including the "mini" afforementioned IP Masquerading how-to and the "IPCHAINS HOW-TO", written by Paul Russell.   In addition, doing a search on firewalling will turn up a number of sites where folks have manually configured their Linux firewalls with either tool.

Rather than do my configuration manually, I was shown an old system administration front end application by my work buddies, called "Stelias-tools", which gives you "point and click" adminstration of your servers, including adding users, configuring SAMBA, and configuring a basic firewall, ie., it will automatically write the firewall rules for you depending on what you enable or disable using the tool.   The graphical panel, which runs on X, had been released for Infomagic's WGS (Workgroup server - based on RH 4.x) and later updated for RH 5.x.   I haven't seen any further updates for it (the last was ver. 1.63-1) and if you want to use it for general administration in RH 5.2, you'll need to point its "buttons" to the newer locations of the other system administration packages, like "adduser", etc.   The Stelias panel allows you to enable and configure firewalling, eg., plug un-needed ports, disable HTTP access, etc., and can be configured to allow some of my favorite things, like streaming audio/video, to pass through, etc.   Note that with manual configuring of firewall rules, all of these things need to be taken into consideration.   There are a number of other firewall-specific front ends also available and you can go here or here to find some of them.   Most allow you to restrict or "close up" all of those thousands of unused but potentially dangerous ports and offer a graphical or html-based tool to do this.

Whichever method you choose, do choose something so that you can secure your internal network as much as possible.   This will at least give you some piece of mind in that you've done what you could to protect your valuable resources, ie., your machines and data!

In an update, I will evaluate some tools that are commonly used to test firewalls.

Conclusion
I'm hoping that this document has described basically what I've done to setup access to the internet from my home network, via my cable modem.   By enabling ip forwarding and masquerading, disabling un-needed services, assigning restricted addresses to your local machines, implementing some type of packet-filtering rules set, and making sure that your proxy/firewall box has the latest security updates installed, you can surf the web to your heart's content with the multiple machines on your home network and help protect yourself from unauthorized access to those same internet-connected machines.   It's been kinda cool going through this and learning about security, and even cooler when I can put some streaming audio on one machine while writing up and posting the various pages for my web site from another machine, all using a single IP address to access the internet!   :)
 
 

NOTICE:   "Linux" is a trademark of Linus Torvalds.   "Presario", "SAMS", "Mac", "Sparc", "Comcast", "Infomagic", and any other product/company mentioned on this page or at this site, are trademarks and/or copyrights of their respective companies.