|Read about Michael|
This month, our router expert walks you through building an http proxy server for a wireless network segment. The...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
construction of the proxy server is quite involved, so we'll cover the process over a few articles. This month we specifically cover the basic Linux distribution install, secure VTY and http text client. Part 2 will cover the kernel build.
Here are links to source code tar balls that we will be adding to the basic Linux distribution install:
There are a number of Linux distributions but Red Hat is by far the most familiar and widely used. (The Fedora project is the new free distribution.) It can be purchased readily in bookstores and office supply stores until it is freely available on the Internet. While I am not endorsing Red Hat (I personally prefer BSD-based Unix/Linux), we will build our proxy server on top of the Red Hat workstation distribution. As far as hardware goes, if you are planning to use this in a production environment, the big factors are processor, bus, and disk speed. They should be as fast as possible -- you can never have too much RAM. The server will also need two network interfaces, which ideally should be the same hardware type.
Being a network administrator does not automatically make you a system administrator -- let alone a Unix system administrator -- so here's a "speed read" through the Red Hat install (the Fedora install is essentially the same):
- Boot off of the install CD and at the BOOT: prompt type: type. This will launch the text based install process.
- Once the install process has loaded, you will be asked to Select Language preference, Keyboard Model and Mouse Model.
- Once the install interface is set you will be asked to partition the drive. For non-Unix folks, everything on the UNIX operating system is a file. There are four file types:
- Regular file, there are two types: user readable ASCII and Binary file, non-human readable executable file (however ASCII files can also be "executed" as shell scripts.
- Directory file, contains files or other directories.
- Symbolic Link, a file that points to another file.
- Device file, "the file" interface to a hardware device such as a printer, modem or disk.
Since everything is a file, Unix uses an inverse tree starting at the "root" indicated by the "/" character. Here is the basic Unix file tree:
The Unix file system is built using disk partitions (that are device "files") "mounted" to directory files on the files system tree. For example, Red Hat places the kernel in the boot directory. So we can create a disk partition that would be the device file /dev/hda* or /dev/sda* that would be mounted to the /boot directory file and would contain the kernel. Alternatively, we could create the /boot directory file on the root file system and the kernel would be stored there. The big difference is that if the root file system became corrupted and the kernel was in a directory only, the kernel could be lost or damaged. If the kernel is stored on the /boot file system and the root partition became corrupted, the root partition could be rebuilt and the kernel would remain unaffected. The best practice for file system layout is to create separate partitions for: /home where users directories exist, /usr/local where "add on" applications are installed, and /var where log and temporary files are installed. That said, when you are presented with the Auto partition option, select it. Let the install build /boot and /, and swap partitions. The / or root file system will be comprised of all of the disk space not used by swap and /boot. The swap partition is what Unix uses as a VM file. Once you have selected the auto partition option, you will be prompted to initialize the disk. Say YES, remove all partitions, and say YES. Red Hat uses the EXT3 journaling file system.
- Once the file system is settled, we move onto the Boot Loader, the small application loads the kernel and gets the system up and running. There are two boot loaders supported by Red Hat, LILO and Grub. LILO is older of the two; Grub is the easier of the two. Choose Grub, not Grub password (unless the server is installed in an unsecured area). You will also be asked if there are any flags or options you want sent to the kernel at boot. If the install provides any options, use them.
- Our next step is the network interface configuration, have the eth0 interface use DHCP and load at boot (we will deal with this later). Ignore, the eth1 configuration, set the hostname manually, proxy.yourdomain.com is a good start. When asked if you want to load the firewall option, the answer is no (again we will get to this later).
- The install prep wraps up with Language support, the servers time zone and setting the root password.
- The last step is Software Install, select the Customize option, there are a number of default options selected, which are oriented towards setting up a workstation. There are some options you want to keep: Editors, Text Internet, Development Tools, and Admin Tools. You need add: Kernel Development, Legacy Software Development, and Systems Tools. Not surprisingly, you will be deselecting: XWindows, Gnome Desktop Environment, Graphical Internet, Sound & Video, Author & Publishing, Graphics, Games, Printer Support.
Then hit return a few times, swap a few CDs, and bang! You're done with your base Linux install. If all went well, the server will reboot after the install. Log in as root and create a directory (in the /root directory):
mkdir src-tree cd src-tree
Now, download the software we need for the build using the wget command:
Now that we have the source code, we need to do some cleanup before we start building secure VTS. The Red Hat workstation distribution comes with OpenSSH installed to provide secure VTY access to and from the Linux server. The SSH implementation, however, is more than likely outdated and functionally limited to only the options built in to the RPM (Red Hat Package Manager) that came with the Install CDs. Depending on the age of your distribution, the packages could be over two years old. Therefore, the first order of business after completing the install is to upgrade SSH.
Before, we get to that, a few words about RPM. RPM is a program distribution tool developed by Red Hat. Instead of compiling UNIX applications and libraries, they can be downloaded in compiled form and installed using the RPM too. RPM is widely supported by many other Linux distributions other than Red Hat and are available for different hardware platforms, PPC, Intel (i386), Alpha, etc. Each RPM package uses a common naming convention starting with the application name, i.e., X11, gcc, openssh, followed by version (1.0), release (1), and architecture, i.e., i386, PPC. Depending on who you talk to, RPM is a blessing or a curse. For non-UNIX folks, RPM is a godsend. It removes the most painful element of supporting a UNIX system, namely building software packages. RPM was one of those great tools developed early on in the Linux revolution that made it possible for just about anyone to run Linux. Now, ask an old-school UNIX system administrator and you can get a very different tune: "RPM is limiting since you only get the options that were built in;" "It makes it hard to upgrade systems because of all of the RPM dependencies;" "RPM are insecure, because you don't know where they come from."
Regardless where you stand on RPM, for our server we are going to build the code, because not everything comes in RPM form, and it provides us with the greatest flexibility. In terms of impact to the build process, we need to uninstall the RPM packages we are replacing with our own builds. Here is a quick overview of the RPM command interface:
To install an RPM package: rpm –ihv <package name>
To upgrade (and also install) an RPM package: rpm –uvh <package name>
To see info about an installed RPM: rpm –q <package name>
To see all the installed RPM packages: rpm –qa
To remove a RPM package: rpm –e <package name>
To remove a RPM package that other RPM's are dependent on use: rpm –e –nodeps <package name>
So, now that we have touched on RPM, let's build SSH. OpenSSH, is dependent of OpenSSL so we start with building OpenSSL, then OpenSSH. The build process for OpenSSL is as follows (starting from the /root/src-tree, directory):
1. tar xvfz openssl-0.9.8.tar.gz 2. cd openssl-0.9.8 3. ./Configure linux-elf --prefix=/usr or ./config --prefix=/usr 4. make 5. rpm -e --nodeps openssl 6. rpm -e --nodeps openssl-devel 7. make install
With OpenSSL built, we move on to OpenSSH. We're building source, rather then using the RPM, to have the ability to utilize some of OpenSSH's additional security enhancement options. The big options to consider with OpenSSH are:
--with-tcp-wrappers[=PATH] Enable tcpwrappers support (optionally in PATH) --with-skey[=PATH] Enable S/Key support (optionally in PATH) --with-md5-passwords Enable use of MD5 passwords --without-shadow Disable shadow password support
S/Key has been replaced with OPIE it provides one time password support, TCP Wrappers provides IP filtering access control for network services. The without-shadow option disables /etc/passwd authentication support for SSH, forcing the user to use public key, S/Key or some other alternative user authentication method. When building servers to provide "secure access" it is a good idea to secure administrative access beyond traditional password support. To define one of the additional options listed above add the flag and source target location to the Configure command. Here are the basic OpenSSH build and install steps (starting from the /root/src-tree, directory):
1. tar xvfz openssh-4.1p1.tar.gz 2. cd openssh-4.1p1 3. ./configure --prefix=/usr 4. make 5. rpm -e --nodeps openssh-clients-3.6.1p2-18 6. rpm -e --nodeps openssh-server-3.6.1p2-18 7. rpm -e --nodeps openssh-3.6.1p2-18 8. make install
When you remove the RPM the sshd binary will be removed and the ssh login service will be disabled. If your connected to the server via SSH, you will remain connected, but no new connections can be made. To start the service manually, run /usr/sbin/sshd. This is only a one time event, when you reboot the server the system will start the sshd service as part of the boot process. During the "make install" process, you may also notice that the key generation process and configuration file install has been skiped because the already exist (from the previous RPM installation). This is not a problem as the configuration supplied by the RPM install is fine. However, if you want a completely new installation you will need to remove the /etc/ssh directory, before running make install.
With secure VTY service out of the way, we only need to build the applications to provide text http support: wget and lynx. The wget, that came as part of the Linux distribution no longer works because it has a dependency on the OpenSSL RPM which we have removed. So we need to build a new app that will use the newly installed OpenSSL libraries. The process is similar to that of OpenSSL and OpenSSH, build the binary, remove the existing RPM install, and install the new code:
1. tar xvfz wget-1.9.tar.gz 2. cd wget-1.9 3. ./configure --prefix=/usr 4. make 5. rpm -e --nodeps wget 6. make install
Lynx is a text-only http browser; it's a handy tool to have for testing the proxy. Lynx is not part of the Red Hat distribution. So there is no RPM removal needed as part of the build and install process:
1. tar xvfz lynx2.8.5.tar.gz 2. cd lynx2-8-5/ 3. ./configure --prefix=/usr 4. make 5. make install
With Lynx installed, we're done with the application build for now and we move on to building our new kernel.