Introduction

The purpose of this project was to investigate and develop a plan to create a general-purpose, yet easy replicable, server appliance, useful for providing basic network services to a small business. This device that was created as a result of this plan was capable of supporting five to ten client personal computers (PCs), yet did not require any user intervention or regular maintenance. This server appliance provided Internet connectivity, firewall protection for the entire local network, along with file and print services for the client computers.

Return to the Table of Contents

Organization Description and Function

Many small businesses are faced with the problem of establishing a small network for use in their daily operations. A business that started with two or three standalone personal computers can quickly develop to the point where there is a requirement for communications along with the need to share data between workstations. The business’s ability to meet this need is often further complicated by the lack of qualified information technology (IT) personnel.

Many options exist which will allow the small business to meet its data processing needs. A server appliance is useful in that it can fill a multitude of functions and requires little maintenance or user interaction, which results in lower operating costs to the business. Often, the most significant costs for the business relating to information technology are those associated with paying for the personnel to setup and configure the equipment, either through the use of contractors, consultants, or the use of full or part time employees.

Multiple computers are also found in many homes. The requirements for a sophisticated home office are very similar to those experienced by many small businesses. Family members require simultaneous Internet access, along with the ability to share files and a printer, all of which is easily handled by a dedicated server appliance. While the purchase of a commercial appliance is beyond the means of most people, a server that can meet the needs of most networked homes can easily be setup using a discarded PC at a very modest cost

Return to the Table of Contents

Current Situation

PC Magazine (Derfler et al., 2001) defines the multipurpose server appliance as a “network in a box,” providing such capabilities as Internet sharing, firewall services, FTP services, e-mail service, and VPN connections, along the ability to provide print and file server functions and the ability to operate as Web server. These devices use standard computer hardware and commonly use a version of Red Hat(tm) Linux. The cost of these devices ranges from approximately $800.00 to well in excess of $30,000.00. Manufacturers include the large computer makers such as IBM, Gateway, and Compaq, as well as more specialized companies such as Avaya, Cobalt Networks, eSoft, Extended Systems, Rebel Systems, and NETmachines.

Linux is a full-featured POSIX-like operating system originally developed by Linus Torvalds in 1991 (Danesh, 1999). Tovaralds’ goal was to create a Unix clone that would run on an Intel (X86) based platform. Linux is available under the GNU General Public License. As a result, it is generally available at little or no cost to the user. Red Hat™ Linux™ (Red Hat Software, 1998) is a commercial distribution of Linux based on “packages” or separate distinct pieces of software that can be managed by use of a package manager. The use of this package manager greatly facilitates the installation, management, and upgrading of the operating system.

Return to the Table of Contents

The Problem

A small business has the same networking and connectivity requirements as any large business, but usually does not have the networking infrastructure to meet its needs, nor does it have the available personnel to manage its network. A dedicated server appliance, requiring little or no support, can provide the networking infrastructure for this business at a very low cost.

As an example, consider a growing small business having five to ten personal computers in an office environment. These computers currently run a version of Microsoft ™ Windows (Windows 95®, Windows 98®, Windows 2000®, or Windows NT®) and are used for the daily operation of the business. While some of the computers are connected in a peer-to-peer network to allow for limited file and printer sharing between employees, other employees can only share information by swapping floppy disks. Internet access is available by dial-up access only, and only to limited personnel, due to the lack of availability of phone lines. Email is provided directly for each user from the Internet service provider (ISP). This is also a common situation in many small office or home office (SOHO) environments. The addition of the server appliance allows this business to resolve their networking an connectivity requirements.

Return to the Table of Contents

Project Objective

The goal of this project was to develop a server appliance for use in a small network. This server was designed to run unattended without any user intervention or regular management. Initial setup and configuration should be minimal for the user.

Limitations

This server was to provide the following functions to the network and client computers:

· File services (disk storage) for client computers.

· Printer services (for a shared printer) for client computers.

· Internet connectivity for client computers, as well as routing for the local network.

o The server was to have the ability to dial and establish a connection with the ISP as needed.

o A broadband connection (either cable modem or DSL) was supported, if available.

· Firewall protection for the local network.

· Web server for a local intranet, only.

· FTP server for a local intranet, only.

· Primary DNS server for the local network.

Delimitations

The server appliance was not to provide the following services nor function as a:

· Email server for the local domain, (although it is capable of forwarding Email to clients.

· DHCP server for the client computers. Fixed Internet protocol (IP) addresses were used for all computers on he network, using IP addresses from the 16-bit block reserved for private (Rekhter et al. 1996).

· VPN services for the client computers.

· Encrypted passwords. Plain text passwords were used for user authentication.

Return to the Table of Contents

Justification

The addition of a server appliance to the situation outlined in the Problem, above, would generally solve the IT related problems experienced by a growing business. Internet service would be available to all employees. File and printer services would enable all employees to share files and utilize a shared printer. Security was enhanced by allowing backup copies of files to be stored on the server, and by the utilization of a firewall on the server which protected the local network from outside intrusions or hacking attempts.

Additionally, an Intranet became available for the storage and posting of documents routinely used by all of the employees. These documents included letters and memorandums regarding policy or procedure, information needed by the employees to conduct their daily business, reference works, and any other similar information. Access to these documents was easily available to all employees simply by using a Web browser or FTP client.

Project Scope and Environment

This project created one such server appliance as described above. It was deployed on a small network in a SOHO environment. The network consisted of three client computers, a printer (connected directly to the server appliance’s parallel port), and an 8-port Ethernet hub. Internet access was obtained through a dialup ISP. Traditional Ethernet networking protocols were used, along with Category 5 cable for all connections.

The local network used the domain name of JOHNSON1-PBJ1.NET, consisted of 5 users: PJ1, PMJ, AMJ, RCJ, and SJ. The host name for the server appliance was server1, and two of the clients are named PBJMMPC and BP120PC. The third client computer was not be a registered client, but was used to verify security of the system during the final testing and validation.

Return to the Table of Contents

Problem Solving Methodology

The methodology used in this project was the System Development Life Cycle (SDLC), which is the standard method for implementing any new system. Figure 1 shows the SDLC as it was used in this project.

Figure 1 - The System Development Life Cycle

For purposes of this project, the SDLC consisted of the following steps:

1. Planning – Identify the scope of the problem. Set limitations and delimitations.

2. Analysis – Examine the current environment, as well as the available software and hardware that is available to provide a solution.

3. Design – Design the new system.

4. Implementation – Construct and test the new system. Configure the software as needed to support the network in which it will be used.

5. Support – Maintain and improve the system as needed. Identify areas for future enhancement.

Use of the SDLC resulted in a disciplined approach to solving the problem. The SDLC is applicable to any system or process that is being developed or modified, and will generally enhance the success of the project.

Return to the Table of Contents

Cost-Benefit Analysis

Costs associated with the project are shown in Table 1. Note that a battery backup unit was included, as the unit was designed to run continuously and without user intervention.

Table 1 - Costs Associated with the Project

Costs Associated with the Project
Item	Cost	Remarks
PC for use as Server Appliance	$400	Used Pentium Class Computer, with keyboard and monitor. Computer has a 166Mhz processor, 32 Megs of memory, a NIC, and a 56K modem.
Battery Backup Unit	$125	APC Back UPS 500
Network Hub and Category 5 Network Cables	$ 50	Generic 8-port hub, and miscellaneous cables as needed.
Software	$ 30	Red Hat™ Linux 6.2
Total Cost	$605

Table 2 shows other Network operating systems (NOS), which could have been used, along with their resulting limitations that precluded them from selection. Linux becomes the best choice for an operating system, when the cost of licensing is considered.

Table 2 - Consideration of the Network Operating System

Consideration of the Network Operating System

Network Operating System

Cost

Considerations

Windows 98®

$90.00

$200.00

· Limited and untested Modem Sharing

· Weak Network Management support

· Unstable – Crashes frequently

Windows NT® or Windows 2000®

$450.00

$1,200.00

· Cost prohibitive user licensing

· Will not run on available hardware

Linux

$30.00

(Free to $180.00)

· Capable of meeting all objectives

· Low cost

· Runs on available hardware

Novell ™ NetWare®

$300.00

$500.00

· Cost prohibitive

· Will not run on available hardware

The experienced and perceived benefits of the system justify its creation when the increased productivity of the personnel who use it is considered. As an example of the increased productivity, assume that a business deploys a server appliance, which frees up one hour per week for each of its two employees. This could easily be done through avoiding the use of floppy disks to transfer files, and by allowing both employees to share an Internet connection, rather than wait for a phone line to become free. If the hourly rate for the employees is $20.00, then the cost of fielding the system is recouped in approximately three to four months. As more employees use the system, an even greater benefit is shown. Additional cost savings are realized by implementing the security features of the system. Given the low cost of creating the system, this system is a very worthwhile addition to the SOHO environment.

The hardware chosen for this project represented the minimum hardware configuration that would allow for successful completion of the project. It was chosen partially because it represents the type of hardware that is discarded as a business’s systems are upgraded. The use of this older, yet still functional, equipment results in an additional cost benefit for the business. However, moving to a more robust hardware platform would not be a significant increase in cost, yet would result in a significantly more powerful system, and one that would more easily allow for future upgrades as needed.

Return to the Table of Contents

System Design and Construction

The design and construction of the system consisted of assembling and configuration of the necessary hardware, installation of the operating system, and finally, configuration of the software necessary to meet the goals of the project as stated previously. Initial installation and configuration of the operating system took approximately three hours, while the remaining system configuration took approximately 20 to 30 hours, depending on the speed of the machine, and any problems that were encountered. As successful configuration files were created and documented, these files could generally be used again during the construction of subsequent machines, depending on the hardware used. This greatly reduced the time involved for the final system configuration.

Selection of Hardware and Software

Red Hat ™ Linux Version 6.2 was selected as the operating system for the server appliance due to its availability and cost, along with its stability and the feature set provided. Additionally, this is the most prevalent OS used in commercially available server appliances (Derfler et al., 2001). A computer running Linux is normally referred to as a “host” as is done with UNIX.

Table 3 shows a comparison of three hardware platforms that were tested for the project. The Cyrix P166+ was the final choice for this specific project, as it represented the minimum hardware platform that could successfully be used. Additionally, as businesses replace machines that are 3 to 4 years old, the older machines are increasingly discarded or sit idly in storage. Use of these older machines as a server appliance provides a mechanism to increase the usefulness of these older machines, thereby extending their life cycle. Naturally, if a machine is to be constructed or purchased specifically for use as a server appliance, then the use of a more powerful processor and more memory should be considered.

Table 3 - Comparison of Hardware Platforms Tested

Comparison of Hardware Platforms Tested
Platform	Processor and Memory	Comments
1	Intel 486 (66 MHz) with 16 megabytes of memory	Would not run Linux 6.2 properly Did not meet the requirements for the project
2	Cyrix P166+ (166 MHz) with 32 megabytes of memory	Minimum configuration which met all requirements for the project GUI environment was extremely slow, but was not needed for the project Readily available by many small businesses
3	AMD K6-2 (450 MHz) with 64 megabytes of memory	Easily met all requirements for the project Ability to run a GUI a potential benefit for future expansion and upgrades BIOS allows for larger hard drive usage

Other hardware considerations included:

· No soundcard is needed in a server, nor should one be used. Avoiding the presence of a soundcard prevents potential conflicts and free up needed IRQs and DMA channels.

· Linux in not compatible with “Win-Modems” or modems designed specifically for the Windows™ operating system. Either a conventional external modem should be used, or a better quality internal modem which will allow all settings and configuration to be made through the use of jumpers rather than through software.

· As this machine will run unattended for long periods of time, the power supply must be capable of providing adequate power and cooling to the system. If an older machine was to be used, then consideration should be given to replacing the power supply, as well as adding additional fans in the case to provide additional cooling.

· The largest hard drive possible should be used, especially if the system is going to be used for file storage. The size and speed of the hard drive will be one of the key factors in the number of clients that can be served, as well as the throughput of the printing services. Linux 6.2 also supports many commercial RAID drives and configurations, which should be considered if the server appliance is going to be used extensively as a file server. Use of a RAID configuration will greatly improve the reliability of the system, yet represents a significant cost factor.

· Linux does not support Universal Serial Buss (USB) ports at the present time; USB devices are not compatible with Linux.

· If the server is going to be used with a broadband Internet connection, then an additional network interface card (NIC) is needed. If this is anticipated as an eventuality, installation of the second network card prior to the installation of the operating system will prevent many potential problems in the future. Ensue that the NICs are compatible with each other.

· If the server appliance is to run with out a keyboard and monitor attached, ensure that the BIOS on the selected motherboard will allow the system to be booted without an attached keyboard. This is actually a viable option, as after the initial setup and configuration a keyboard and monitor is not needed. Any maintenance can be done using a Web browser, a telnet client, or both.

· A CD-ROM is necessary it install the operating system. A system BIOS that allows the machine to be booted directly from the CD-ROM further simplifies this installation.

Return to the Table of Contents

Installation of Operating System

Red Hat™ Linux, version 6.2, was installed from a distribution CD ROM, using the default setup program. Additional information regarding installation is available from The Official Red Hat Linux Installation Guide (Red Hat Software, 2000). The operating system was installed by providing the following responses during the initial setup:

· Selecting “US English” as the language.

· Specifying the “Server System,” using the automatic partition configuration, and allowing “writing of the new partition table to disk immediately.”

· Specifying that the hostname for the server is “server1.johnson1-pbj1.net.”

· Specifying that the mouse is a “Generic 2 button Mouse (emulate 3 buttons),” using the port “/dev/ttyS0 (COM1 under DOS).”

· Specifying that the time is “US/Eastern.”

· Specifying the root password, and accounts for two users. The root user in Linux is the “superuser” or the system administrator.

· Allowing the system to create the log file at “/tmp/install.log.”

Using the default server installation installed the necessary software components for the system to function as desired.

Basic Server and Network Configuration

Red Hat ™ provides the linuxconf utility for both the initial and any subsequent host configuration. This utility is available to the root user (system administrator) as a GUI application, a console (or text based) application, or as an Internet application, accessed using a Web browser. A significant portion of the remaining setup of the host configuration and the network configuration was quickly completed using this utility. Items were set using linuxconf as shown in Table 4. Figure 2 shows an example of linuxconf in use.

Figure 2 - Using linuxconf

Table 4 - Items Set Using linuxconf

Items Set Using linuxconf

Basic host Info:

· Host name: server1.johnson1-pbj1.net

· Adapter 1: Primary Name: server1.johnson1-pbj1.net

Aliases : server1 server1.johnson1

IP Addr: 192.168.1.1 (This is the IP for this machine)

Net Mask: 255.255.255.0

Manual configuration of the Ethernet card was required:

Io = 0x300 IRQ = 12

· Resolver Configurator – DNS Setup:

DNS usage – required

Default domain – johnson1-pbj1.net

DNS 1 192.168.1.1

DNS 2 (Use a DNS as provided by the ISP)

DNS 3 (Use a DNS as provided by the ISP)

· Routing and Gateways:

Default Gateway (none specified – leave blank)

Enable Routing (enabled – checked)

· Host name search path:

Multiple Ips for one host (enabled – checked)

Hosts,dns (Selected)

· PPP/SLIP/PLIP: Configure ppp0:

Hardware:

Use hardware flow control (enabled – checked)

Abort connection on well-known errors (enabled – checked)

Allow any user to (de)activate (enabled – checked)

Line speed 115200

Modem port /dev/modem

Communication:

Modem init string ATZ

Modem dial command ATDT

Phone Number [telephone number of ISP]

Debug connection (enabled – checked)

Chat:

name: [username to logon to ISP account]

word: [password to logon to ISP account]

Timeout: 5

Config – Misc – Linuxconf network access

· linuxconf html access control

Enable network access

Log access (enabled – checked) (in /var/log/htmlaccess.log

Network or host 192.168.1.2

Config – Boot Configuration – LILO

· Present the LILO boot: prompt (Disabled – unchecked)

The entry in “Config-Misc-Linuxconf network access” allows a user using a host with an IP address of 192.168.1.2 to access linuxconf using their Web browser. Port 98 must be specified in the URL. The complete URL used is http://192.168.1.1:98. The entry in “Config-Boot Configuration-LILO” is needed for automatic booting of the host upon turning on the system. Completion of network configuration required that five additional files be created or modified as shown in Table 5.

Table 5 - Additional Files needed for Network Configuration

Additional Files needed for Network Configuration

/etc/hosts

127.0.0.1 localhost.localdomain localhost

192.168.1.1 server1.johnson1-pbj1.net server1 server1.johnson1

192.168.1.2 pbjmmpc.johnson1-pbj1.net pbjmmpc pbjmmpc.johnson1

192.168.1.3 bp120pc.johnson1-pbj1.net bp120pc bp120pc.johnson1

/etc/hosts.allow

# 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.

ALL: 192.168.1.

ALL: 127.0.0.

ALL: 160.150.31.56

/etc/hosts.deny

# 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.

ALL: ALL

/etc/host.conf

order hosts, bind

multi on

nospoof on

trim johnson1.pbj1.net

/etc/resolv.conf

search johnson1-pbj1.net

nameserver 127.0.0.1

nameserver 206.153.8.5

nameserver 206.153.8.8

These files provided the system information regarding other hosts on the network and setup permissions regarding access to the system. Information regarding other hosts on the local network for a UNIX or Linux computer is found in the file /etc/hosts. These were the computers that will be using the server appliance, and either this file or the Domain Name Sever (DNS) system must be updated as other computers are added to the network. For a small network of very few computers, this location was the logical choice. The information in the file /etc/hosts.conf ensured that when looking up IP addresses, the information in /etc/hosts is consulted prior to using the DNS system. Assuming that most of the network traffic is for the local network, this results in greater system efficiency. The “nospoof “ option forces the system to log the activity of the remote systems using the DNS services, and is done for security reasons. Name servers for the system were specified in the file /etc/resolv.conf. The first address (127.0.0.1) is the “loopback” address of the server, which tells the server to attempt to resolve addresses internally. The other two addresses are for the DNS from the ISP.

The remaining two files establish the primary security for the system. The file, /etc/hosts.deny, creates a general policy that no other host may access the server. The file, /etc/hosts.allow, creates an exception to that policy, allowing a host with one of the designated IP addresses to access the server.

Return to the Table of Contents

Samba Configuration

Providing file and printer services to Windows™ based computers is one of the primary reasons for having the server appliance. Craig Hunt (Hunt, 1999) states Microsoft® uses the Server Message Block (SMB) protocol to share files across a Windows ™ bases network. SMB is also the NetBIOS protocol used by Windows NT™ servers to share files with Windows™ based clients. Samba is used by Linux to provide SMB services to its clients, and generally causes the Linux server to emulate a Windows NT™ server. Samba is part of the default installation of Red Hat™ Linux 6.2.

The Samba server on a Linux system needs two files. These are /etc/smbusers, which provides a listing of the names of the users and their Linux account logins, and etc/smb.conf, which provides the configuration information needed for Samba. Table 6 shows the contents of /etc/smbusers and Table 7 shows the /etc/smb.conf file as was used on the server appliance. Access to two CD-ROMs was provided to the Samba clients in this particular configuration, as an example of the capabilities and usefulness of the system.

Table 6 - The /etc/smbusers Samba Configuration File

The /etc/smbusers Samba Configuration File

root = administrator admin

nobody = guest pcguest smbguest

pj1 = "Philips B. Johnson" pbj pbj1

sj1 = "Sylvia Johnson" sj sj1

rcj = "Robert Johnson" rcjj

amj = "Andres Johnson" amj

pmj = "Philips M. Johnson" pmj

Table 7 - The /etc/smb.conf Samba Configuration File

The /etc/smb.conf Samba Configuration File

# smb.conf

# Samba configuration file for ///johnson1//server1

# The Johnson Family workgroup server.

# Modified on November 19, 2000

#======= Global Settings ================

[global]

workgroup = johnson1

server string = Samba Server (for ///johnson1//server1)

hosts allow = 192.168.1.1 192.168.1.2 192.168.1.3 127.0.0.1

# Use a separate log file for each machine that connects

log file = /var/log/samba/log.%m

# Put a capping on the size of the log files (in Kb).

max log size = 50

# Security mode.

security = user

# Password Level allows matching of _n_ characters of the password for

# all combinations of upper and lower case.

password level = 8

username level = 8

# Unix users can map to different SMB User names

username map = /etc/smbusers

# Printer Support

load printers = yes

printcap name = /etc/printcap

# Most people will find that this option gives better performance.

# See speed.txt and the manual pages for details

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

#Browser Configuration

local master = yes

os level = 33

; domain master = yes

preferred master = yes

dns proxy = yes

# Case Preservation

; preserve case = no

; short preserve case = no

# Default case is normally upper case for all DOS files

; default case = lower

# Be very careful with case sensitivity - it can break things!

; case sensitive = no

#========= Share Definitions ================

[homes]

comment = Home Directories

browseable = no

writable = yes

# [printers] commented out so that only the HP DJ932C is available

;[printers]

; comment = All printers

; path = /var/spool/samba

; public = yes

; writable = no

; printable = yes

# Printer HP DeskJet 932CIIP on Server1

[hp_dj932c]

comment = HP DeskJet 932C on Server1

path = /var/spool/samba

public = yes

browseable = yes

printable = yes

printer driver = HP DeskJet 932C

# Temp directory access

[temp]

comment = Temporary file space

path = /home/temp

public = yes

read only = no

# MS Bookshelf95 -- Copy of Dist CD - Available to all users

[bookshelf2000]

comment = MS Bookshelf 2000

path = /home/bkshelf2k

public = yes

writable = no

printable = no

# MS Encarta97 -- Copy of Dist CD - Available to all users

[encarta97]

comment = MS Encarta 97

path = /home/encarta97

public = yes

writable = no

printable = no

Each user must have an account on the Linux server to use the Samba server. The user name and password on the Windows™ client must match the information in the /etc/smbusers file, and this file must be updated as new users are added to the network. By default, Samba does not use encrypted passwords. Current versions of the Microsoft products do use encrypted passwords as the default setting, which results in Samba not being able to parse the passwords as forwarded by the client. To resolve this problem, the registry on each of the client machines was edited to allow for sending unencrypted passwords. This was done by using REGedit in Windows™ to modify the registry by adding a new DWORD of EnablePlainTextPassword with a value of 1 (set either 01 decimal or 0001 hex) for following key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Vxd\VNETSUP

On larger networks Samba could be configured to use encrypted passwords, to avoid making this modification to each of the client machines.

Return to the Table of Contents

Pppd and Diald Configuration

The server connected to the Internet by using a dial-up connection to the ISP and establishing a Point-to-Point Protocol (physical layer) connection using the serial port and modem. The program, pppd, is the component Linux uses to manually establish this connection. As one of the stated goals of the project was that no user intervention should be required of the server appliance, another program, diald, was used to automate the dialing process. A connection script is always used to execute pppd, and Table 8 shows the connection script written to connect to LogicSouth, Inc., the ISP which was used for this project. Notice that this script calls the program chat, which handles the passing of the user information and password to the remote host. This information will be used again when constructing the scripts used to automate the process using diald.

Table 8 - pppd Script used to Connect to the ISP

Pppd Script used to Connect to the ISP

!/bin/sh

/usr/sbin/pppd /dev/modem 115200 connect \

'/usr/sbin/chat -v "" ATDT2528899 CONNECT "" name: philxxx \

word: xxxxxx' noipdefault defaultroute crtscts debug

To avoid having to manually execute the pppd script each time connection to the Internet is desired, the program diald was used to automate the process. Originally written by Eric Schenk, and currently maintained by Mike Jagdis, the program is available for download at http://diald.unix.ch. This program provides a similar function to that of the Dial-up-Networking (DUN) component in Microsoft® Windows™. Configuration of diald is done through the use of a brief chat script and a configuration file. These files are shown in Table 9. Additionally an extensive packet-filtering file is found in the directory /usr/lib/diald, which defines the rules for initiation and termination of the connection. This file may require modification as necessary.

Table 9 - Files Used to Configure diald

Files Used to Configure diald

/etc/diald.conf

# /etc/diald.conf modified by Philips B. Johnson on June 04, 2000

mode ppp

connect /etc/ppp/logicsouth1.chat

device /dev/modem

speed 115200

modem

lock

crtscts

local 192.168.0.1

remote 192.168.0.2

dynamic

defaultroute

pppd-options noauth noipdefault

include /usr/lib/diald/pbjserver1.filter

/etc/ppp/logicsouth1.chat

#!/bin/sh

/usr/sbin/chat "" ATDT2528899 CONNECT "" name: philxxx word: xxxxx

IP Masquerading and Firewall Configuration

Construction and configuration of a firewall is potentially one of the most complex and demanding tasks associated with the construction and configuration of a network, and its associated servers. The tool used to create a firewall under Linux 6.2 is ipchains. This program replaced ipfwadm, which was found in version 5.2 and earlier. Setup and configuration of the firewall using ipchains is done by entering “rules” which determine the action of each IP packet entering or leaving the system. Additionally, ipfwadm is used to enable Linux to function as a proxy server, or to translate IP addresses to provide Internet access to the client computers. “Masquerading” is the term Linux uses for network translation

A script was written to automatically start IP masquerading, and made part of the System V configuration information. In addition to executing the commands to start masquerading, the script ensures that any necessary kernel modules (comparable to device drives in Windows™) are loaded. The contents of this Masquerade script are shown in Table 10.

Table 10 - The Masquerade Script (/etc/rc.d/init.d/masquerade)

/etc/rc.d/init.d/masquerade

#!/bin/sh

# This shell script starts IP Masquerade (IP Forwarding) for Server1

# Created by Philips B. Johnson on June 04, 2000

echo Starting IP Masquerading Services

# Load all required IP MASQ modules

/sbin/depmod -a

/sbin/modprobe ip_masq_ftp

/sbin/modprobe ip_masq_raudio

/sbin/modprobe ip_masq_irc

# /sbin/modprobe ip_masq_quake

# /sbin/modprobe ip_masq_cuseem

# /sbin/modprobe ip_masq_vdolive

# Enable IP Forwarding

echo "1" > /proc/sys/net/ipv4/ip_forward

# Enable automatic IP defragmenting

echo "1" > /proc/sys/net/ipv4/ip_always_defrag

# Needed for dynamic IP address configuration

echo "1" > /proc/sys/net/ipv4/ip_dynaddr

# MASQ timeouts

# 2 hr timeout for TCP sessioon; 10 sec timeout for traffic after TCP/IP "FIN"

# packet; 160 sed fimeout for UDP traffic

/sbin/ipchains -M -S 7200 10 160

# Enable IP forwarding and masquerading

/sbin/ipchains -P forward DENY

/sbin/ipchains -A forward -s 192.168.1.1/24 -j MASQ

Rick Johnson has simplified the task of configuring a firewall with the program PMFirewall, available for download on the Internet at http://www.pointman.org. Once installed, PMFirewall runs as part of the System V configuration, requiring no user intervention, yet provides the needed security for the network. The rules generated by PMFirewall are shown in Table 11.

Table 11 - Firewall Rules generated by PMFirewall

Firewall Rules generated by PMFirewall

Chain input (policy ACCEPT):

target prot opt source destination ports

ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a

ACCEPT tcp !y---- 0.0.0.0/0 208.150.162.214 * -> *

DENY all ------ 10.0.0.0/8 208.150.162.214 n/a

DENY all ------ 127.0.0.0/8 208.150.162.214 n/a

DENY all ------ 172.16.0.0/12 208.150.162.214 n/a

DENY all ------ 192.168.0.0/16 208.150.162.214 n/a

DENY tcp ----l- 0.0.0.0/0 208.150.162.214 * -> 31337

DENY udp ----l- 0.0.0.0/0 208.150.162.214 * -> 31337

DENY tcp ----l- 0.0.0.0/0 208.150.162.214 * -> 12345:12346

DENY udp ----l- 0.0.0.0/0 208.150.162.214 * -> 12345:12346

DENY tcp ----l- 0.0.0.0/0 208.150.162.214 * -> 1524

DENY tcp ----l- 0.0.0.0/0 208.150.162.214 * -> 27665

DENY udp ----l- 0.0.0.0/0 208.150.162.214 * -> 27444

DENY udp ----l- 0.0.0.0/0 208.150.162.214 * -> 31335

DENY all ------ 224.0.0.0/8 0.0.0.0/0 n/a

DENY all ------ 0.0.0.0/0 224.0.0.0/8 n/a

DENY udp ------ 0.0.0.0/0 0.0.0.0/0 * -> 67:68

ACCEPT tcp ------ 192.168.1.0/24 208.150.162.214 * -> 20

ACCEPT tcp ------ 192.168.1.0/24 208.150.162.214 * -> 21

ACCEPT tcp ------ 192.168.1.0/24 208.150.162.214 * -> 23

ACCEPT tcp ------ 192.168.1.0/24 208.150.162.214 * -> 25

ACCEPT tcp ------ 0.0.0.0/0 208.150.162.214 * -> 53

ACCEPT udp ------ 192.168.1.0/24 208.150.162.214 * -> 53

ACCEPT tcp ------ 192.168.1.0 208.150.162.214 * -> 79

ACCEPT tcp ------ 192.168.1.0/24 208.150.162.214 * -> 80

ACCEPT tcp ------ 192.168.1.0/24 208.150.162.214 * -> 110

ACCEPT tcp ------ 0.0.0.0/0 208.150.162.214 * -> 113

ACCEPT udp ------ 0.0.0.0/0 208.150.162.214 * -> 113

ACCEPT tcp ------ 192.168.1.0/24 208.150.162.214 * -> 119

ACCEPT tcp ------ 192.168.1.0/24 208.150.162.214 * -> 123

ACCEPT udp ------ 192.168.1.0/24 208.150.162.214 * -> 123

ACCEPT tcp ------ 192.168.1.0/24 0.0.0.0/0 * -> 137:139

ACCEPT udp ------ 192.168.1.0/24 0.0.0.0/0 * -> 137:139

ACCEPT tcp ------ 192.168.1.0/24 208.150.162.214 * -> 143

ACCEPT udp ------ 0.0.0.0/0 0.0.0.0/0 * -> 520

ACCEPT tcp ------ 192.168.1.0/24 0.0.0.0/0 * -> 2049

ACCEPT udp ------ 192.168.1.0/24 0.0.0.0/0 * -> 2049

ACCEPT tcp ------ 192.168.1.0/24 0.0.0.0/0 * -> 5999:6003

ACCEPT udp ------ 192.168.1.0/24 0.0.0.0/0 * -> 5999:6003

ACCEPT udp ------ 0.0.0.0/0 0.0.0.0/0 67 -> *

ACCEPT udp ------ 0.0.0.0/0 0.0.0.0/0 68 -> *

ACCEPT all ------ 192.168.1.0/24 0.0.0.0/0 n/a

ACCEPT icmp ------ 0.0.0.0/0 208.150.162.214 * -> *

ACCEPT tcp ------ 0.0.0.0/0 208.150.162.214 * -> 1023:65535

ACCEPT udp ------ 0.0.0.0/0 208.150.162.214 * -> 1023:65535

DENY all ----l- 0.0.0.0/0 0.0.0.0/0 n/a

Chain forward (policy DENY):

target prot opt source destination ports

ACCEPT all ------ 192.168.1.0/24 192.168.1.0/24 n/a

ACCEPT all ------ 208.150.162.214 0.0.0.0/0 n/a

MASQ all ------ 192.168.1.0/24 0.0.0.0/0 n/a

Chain output (policy ACCEPT):

target prot opt source destination ports

ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a

ACCEPT all ------ 192.168.1.0/24 0.0.0.0/0 n/a

- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 80

- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 22

- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 23

- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 21

- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 110

- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 25

- tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> 20

ACCEPT icmp ------ 192.168.1.0/24 0.0.0.0/0 * -> *

ACCEPT icmp ------ 208.150.162.214 0.0.0.0/0 * -> *

ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a

Return to the Table of Contents

Installation of the Battery Backup and Power Monitoring Software

To ensure continuous unattended operation, a battery backup was provided, along with the necessary monitoring and shutdown software. An APC^® BackUPS 500 was selected. This unit will provide approximately 15 to 20 minutes of battery power to the server in the event of power loss. The APC^® software is available on the Internet at http://www.apcc.com. This software monitors the battery backup through a serial port connection, and after power loss will perform a controlled shutdown of the system following approximately ten minutes of battery usage.

DNS Configuration

The DNS software used by Linux is the Berkeley Internet Name Domain (BIND), and includes the actual name server, named, which is started as part of the System V configuration when the system is started. DNS is responsible for mapping names to IP addresses, and is used extensively during Internet access. The other method Linux uses to retrieve names is to examine the contents of the file, /etc/hosts, which was shown in Table 5, and contains the names and IP addresses for hosts on the local network. The server is configured to examine this file prior to querying DNS for network names and IP addresses.

Two configuration files are needed to configure the named, along with “zone” files, which provide the actual lookup information for the DNS. These configuration files show the location of the zone files, and are shown in Table 12.

Zone files are created corresponding to the entries in the configuration files, which contain the actual lookup information for the zone or network, that allow the mapping or translation of names to IP addresses. Entries in the named.conf file ending with “.in-addr.arpa” refer to reverse lookup tables, which are used to translate an IP address back to a name. It is imperative that the data in reverse lookup tables accurately match that found in the corresponding zone files. The zone files as used on the server are found in Table 13, and the reverse lookup file is shown in Table 14.

Table 12 - Configuration Files used by the DNS Server

Files Needed for Configuration of the DNS Server

/etc/named.boot

; Nameserver for johnson1-pbj1.net

directory /var/named

cache named.ca

primary 0.0.127.in-addr.arpa named.local

primary johnson1-pbj1.net named.johnson1-pbj1.net

primary 1.168.192.in-addr.arpa named.192.168.1

/etc/named.conf

options {

directory "/var/named";

};

zone "." {

type hint;

file "named.ca";

};

zone "johnson1-pbj1.net"{

type master;

file "named.johnson1-pbj1.net";

notify no;

allow-transfer {none;};

};

zone "0.0.127.in-addr.arpa"{

type master;

file "named.local";

};

zone "1.168.192.in-addr.arpa"{

type master;

file "named.192.168.1";

notify no;

};

Table 13 - Zone Files Used by the DNS Server

Zone Files Used by the DNS Server

/var/named/named.local

@ IN SOA localhost. root.localhost. (

1997022700 ; serial

28800 ; refresh

14400 ; retry

3600000 ; expire

86400 ; default_ttl

)

@ IN NS localhost.

1 IN PTR localhost.

/var/named/named.johnson1-pbj1.net

; Zone file for johnson1-pbj1.net

@ IN SOA server1.johnson1-pbj1.net. philipsj.pbj1.net. (

2000111305 ; serial

8H ; refresh

2H ; retry

1W ; expire

1D ) ; minimum TTL

; end of the SOA record

IN A 192.168.1.1

IN NS ns

TXT "johnson1-pbj1.net -- A pbj1.net network!"

; **** Mail Exchangers not configured at this time ******************

; MX 10 mail.server1.johnson1-pbj1.net.

; ; Primary Mail Exchanger

; MX 20 mail2.server1.johnson1-pbj1.net.

; ; Secondary Mail exchanger

; Definitons for Hostnames within johnson1-pbj1.net

localhost IN A 127.0.0.1

server1 IN A 192.168.1.1

TXT "The Johnson Family Network Server"

pbjmmpc IN A 192.168.1.2

TXT "Phil's AMD K6-2 450Mhz PC"

bp120pc IN A 192.168.1.3

ns IN A 192.168.1

TXT "Nameserver for johnson1-pbj1.net"

; *** nameserver is server1 ***

www IN CNAME server1

ftp IN CNAME server1

Table 14 - Reverse Lookup Zone File Used on the DNS Server

Reverse Lookup Zone File Used on the DNS Server

/var/named/named.192.168.1

@ IN SOA server1.johnson1-pbj1.net. philipsj.pbj1.net. (

2001020112 ; serial

28800 ; refresh

14400 ; retry

3600000 ; expire

86400 ; default TTL

) ; end of SOA record

;

@ IN NS server1.johnson1-pbj1.net.

1 IN PTR server1.johnson1-pbj1.net.

2 IN PTR pbjmmpc.johnson1-pbj1.net.

3 IN PTR bp120pc.johnson1-pbj1.net.

The other file used by the BIND software is the named.ca file. This file contains the addresses of the “top level” name servers and is normally supplied with the BIND software. Alternately the latest version (currently dated August 1997) can be obtained from Internic at: ftp://rs.internic.net/domain/named.cache.

Return to the Table of Contents

Final Configuration

One of the goals of the project was that the system runs unattended, with little or no user intervention. In order to achieve this goal, all of the various system components were started automatically during the power-up sequence. In order to power down, Linux requires that the system administrator log-on and issue the shutdown command: shutdown –h now. As this was not considered a practical solution in a SOHO environment, a simple method of initiating the shutdown sequence was desired, and be done by a person with no computer expertise or special skills. In order to simplify this procedure, the keyboard non-maskable interrupt (NMI) was mapped to the shutdown command. The keyboard NMI is generated by pressing the [CTRL], [ALT], and [DELETE] keys on the keyboard at the same time. To implement this, the /etc/inittab file is modified to execute the shutdown command upon pressing the [CTRL] - [ALT] - [DELETE] keys. The necessary modification is shown in Table 15.

Table 15 - Modifications to /etc/inittab needed for Shutdown

Modifications to /etc/inittab needed for System Shutdown

# Trap CTRL-ALT-DELETE

# Modified by Philips B. Johnson on June 06, 2000 to

# shutdown the computer on keyboard NMI

ca::ctrlaltdel:/sbin/shutdown -t3 -h now

Finally, the /etc/issue file was modified to identify the server and display any desired warning messages to the potential user. The contents of the /etc/issue file are displayed prior to the system logon prompt. As the /etc/issue file is rewritten on every boot sequence, modifications to it are made by modifying the /etc/rc.d/rc.local script which is executed during the initial startup. The modified /etc/rc.d/local file is shown in Table 16, and the resulting logon screen is shown in Figure 3.

Table 16 - The Modified /etc/rc.d/rc.local File

The Modified /etc/rc.d/rc.local File

#!/bin/sh

# This script will be executed *after* all the other init scripts.

# Modified by Philips B. Johnson on November 13, 2000

# Modifications go here to avoid the full Sys V style init stuff.

if [ -f /etc/redhat-release ]; then

R=$(cat /etc/redhat-release)

arch=$(uname -m)

a="a"

case "_$arch" in

_a*) a="an";;

_i*) a="an";;

esac

NUMPROC=`egrep -c "^cpu[0-9]+" /proc/stat`

if [ "$NUMPROC" -gt "1" ]; then

SMP="$NUMPROC-processor "

if [ "$NUMPROC" = "8" -o "$NUMPROC" = "11" ]; then

a="an"

else

a="a"

# This will overwrite /etc/issue at every boot.

# /etc/issue is displayed on the login screen.

echo "" > /etc/issue

echo "Welcome to the Johnson Family Network Server" >> /etc/issue

echo "server1.johnson1-pbj1.net 192.168.1.1 pbj1.net" >> /etc/issue

echo "FOR USE BY AUTHORIZED PERSONNEL ONLY" >> /etc/issue

echo " " >> /etc/issue

echo "$R" >> /etc/issue

echo "Kernel $(uname -r) on $a $SMP$(uname -m)" >> /etc/issue

cp -f /etc/issue /etc/issue.net

echo >> /etc/issue

Figure 3 - The Login Screen

Return to the Table of Contents

Implementation

Implementation of the system consisted of the actual construction and installation of both the hardware and software. As stated earlier, three trials were conducted using different hardware platforms, and each trial required from 20 to 30 hours to complete. Most of this time was spent in correcting the unique problems to each hardware platform, and compatibility problems that arose during software configuration.

The final version was constructed using a Cyrix P166+ (166 MHz) processor with 32 megabytes of memory. The reasons this platform was chosen were:

· It represented the lowest level of hardware available that would meet the goals of the project.

· With the limited number of clients that were tested, and that will be present in the final implementation, there was no significant increase in the performance of the network with the more advanced hardware platform.

The steps used to implement the final solution were as follows:

1. Construction and modification of the hardware,

2. Installation of the Operating System,

3. Network configuration and client configuration as needed,

4. Further configuration of the individual packages needed to provide file and printer services (Samba),

5. Further configuration of the individual packages needed to provide Internet connectivity and security to the clients

6. Installation of the battery backup system along with configuration of the appropriate software,

7. Final customization of the system,

8. Testing of the various functions of the system,

9. Copying the needed files to create the Web Page and FTP directory for the system,

10. Checking with the OS vendor to acquire any needed or recommend software or security updates, installing these upgrades to the operating system as needed, and

11. Installing the system along, with the needed cabling and other connections, in its final location.

The final system is currently located under a desk in the living room of the Johnson house, and is used to provide network services to the household. A photograph of the system created as the final product of this project is shown in Figure 4.

Figure 4 - The Completed Network Appliance

Return to the Table of Contents

Validation, Verification, and Evaluation

Validation is the process of checking that the system works as intended, verification if the process of checking that all of the original design goals were met, and evaluation is the process of having an external agent verify that the system meets its expectations and works as intended. Validation of the completed system was accomplished by checking each of the sub-systems, which had required specific configuration, to ensure that each of these sub-systems had been configured correctly and was functioning properly. Complete validation of the security aspects of the system were delayed until the final testing, to allow the system to be deployed as quickly as possible.

Usage of the system on site verified that all of the initial requirements for the system were met. Specifically, external file storage and printer support were provided to the client computers, along with Internet connectivity as needed. After the initial installation, almost no user or system administrator intervention has been required.

To evaluate the system, all of the users were given an opportunity to use the system from their client computers. The main areas of concern to the uses were the ability to print documents on the printer, and the ability to use the Internet. As a result, their emphasis was on these areas, and all users were extremely happy with the system. The users did, however, test all aspects of the system as defined in the initial goals for the project, and demonstrate that all of these goals had been met, to include the use of the Web based Intranet and file services, using both a FTP client and the Samba subsystem. An unexpected benefit was the success encountered when sharing two CD-ROMs using the Samba file services. Figure 5 shows a client browsing files on the server using the Windows® Network Neighborhood. Figure 6 shows the homepage for the local Intranet, hosted by the server appliance.

Figure 5 - Browsing Files using Network Neighborhood

Figure 6 - The Intranet Homepage

Return to the Table of Contents

Testing

After it was clear that the server appliance was functioning properly and that the initial goals of the project had been met, system testing focused primarily on the security of the system, as well as the efficiency and throughput of the system.

Security Testing

The security was verified through attempts to access the system in an “unauthorized manner” and examination of the system logs. Attempts were made to enter the system both externally, using the Internet, and internally using an additional computer that was directly connected to the Ethernet hub. This testing showed that all of the desired security outcomes were achieved to include:

· Users with valid accounts on the system could access the file server resources from a client on the local network, however users without valid accounts were rejected.

· Any user, with or without an account could use the printer from any client machine on the local network.

· Neither file services nor printer services were available outside of the local network.

· The Web-based Intranet was available to all clients on the local network, but was not available to any machines outside of the local network, even when the routing information for the local network was known, the PPP link was up and active, and access to the server was attempted using the remote or local IP addresses provided by the ISP.

· The firewall was effective in preventing probes from outside of the local network, regardless of the IP port that was probed.

· All “unusual” activity was logged to the appropriate system log.

Surprisingly, an examination of the system logs revealed several attempted attacks or other probes from other outside sources occurred during the testing. As the system has been implemented, these attacks occur with increasing frequency. Table 7 shows entries the system logs for some of this activity.

Table 17 - System Log Extract Showing Denied Attacks or Probes

System Log Extract Showing Denied Attacks or Probes

Jan 7 11:07:15 server1 kernel: Packet log: input DENY ppp0 PROTO=6 135.90.152.228:21 208.150.162.116:21 (Attempted FTP Server Access)

L=40 S=0x00 I=39426 F=0x0000 T=34 SYN (#46)

Jan 8 21:19:37 server1 kernel: Packet log: input DENY ppp0 PROTO=17 212.116.147.140:137 208.150.162.87:137 (Attempted NETBIOS Name Access)

L=78 S=0x00 I=31328 F=0x0000 T=110 (#46)

Jan 9 23:12:50 server1 kernel: Packet log: input DENY ppp0 PROTO=17 198.41.3.101:53 208.150.162.171:1025 (Query on Network Blackjack)

L=132 S=0x00 I=62936 F=0x0000 T=47 (#46)

Jan 11 20:48:58 server1 kernel: Packet log: input DENY ppp0 PROTO=17 63.100.129.195:137 208.150.162.36:137 (Attempted NETBIOS Name Access)

L=78 S=0x00 I=62593 F=0x0000 T=116 (#46)

Jan 11 20:49:00 server1 kernel: Packet log: input DENY ppp0 PROTO=17 63.100.129.195:137 208.150.162.36:137 (Attempted NetBIOS Name Access)

L=78 S=0x00 I=21640 F=0x0000 T=116 (#46)

Jan 24 10:30:47 server1 kernel: Packet log: input DENY ppp0 PROTO=17 208.184.4.142:63318 208.150.162.155:53 (Attempted DNS Server Access)

L=74 S=0x00 I=1 F=0x0000 T=48 (#46)

Jan 24 10:31:32 server1 kernel: Packet log: input DENY ppp0 PROTO=17 208.184.4.142:1434 208.150.162.155:53 (Attempted DNS Server Access)

L=45 S=0x00 I=1 F=0x0000 T=48 (#46)

Jan 27 16:26:54 server1 kernel: Packet log: input DENY ppp0 PROTO=6 211.99.196.50:21 208.150.162.23:21 (Attempted FTP Server Access)

L=40 S=0x00 I=39426 F=0x0000 T=25 SYN (#46)

Jan 30 12:11:46 server1 kernel: Packet log: input DENY ppp0 PROTO=17 194.242.151.49:137 208.150.162.98:137 (Attempted NETBIOS Name Access)

L=78 S=0x00 I=24641 F=0x0000 T=108 (#46)

Return to the Table of Contents

Performance Testing

In order to ensure usability of the system, a very significant part of the testing procedures was focused on ensuring that the performance or response of the system was satisfactory. Services occurring solely within the local network were considered satisfactory by the users. However, when multiple clients were accessing the Internet simultaneously, the initial response time for Internet access was not acceptable. The original design did not call for the configuration of the DNS server as part of the server appliance. Examination of router activity showed that a significant number of packets through the router were related to DNS traffic, using port 53, and designated for the ISP’s name server. This led to the decision to implement the full DNS server as discussed above, and was the only significant change made to the system during testing.

After implementation of the DNS server, a significant decrease in the number of port 53 packets that were routed externally occurred, along with a significant increase in traffic to and from the localhost (using the loopback address of 127.0.0.1). Perhaps the most significant comments came from the users who commented on how much faster the system had suddenly become, without having been told that any changes had occurred to the system.

Conclusion and Summary

This project focused on the need to provide network support to a small business in a SOHO environment. The solution was to create a “server appliance” which would provide the needed network support and connectivity. This network appliance was constructed, and it successfully met all of the goals that were initially set forth for the project. However, the feasibility of the small business constructing its own server appliance as the optimum solution to the problem should be evaluated further.

Conclusion

This project demonstrated that the construction of a network appliance to meet its network requirements is a viable option for the small business. The appliance can easily be constructed at a very modest cost, especially when the benefits of using the appliance are considered. If older, unused hardware is available that is capable of being used, then the hardware costs involved become negligible. The most significant factor involved in the project is the time investment needed for the initial configuration of the operating system and related software. With major vendors announcing significant price reductions, and beginning to introduce pre-configured network appliances in the $1000 to $2000 price range, the real question becomes whether to build or buy. An examination of the commercially available options is an area worthy of more study by a small business considering this solution.

Areas for Further Research

Limitations and delimitations were decided upon at the beginning of this project to limit the scope of the project to what was viable, and what could be successfully completed. Working with the server appliance showed that the device is capable of more functionality, and could easily be expanded by adding or enabling additional services, resulting in a greater benefit to the business. Table 18 shows some of the items that should be considered for further development of the device.

Table 18 - Areas for Further Development

Areas for Further Development
Area for Enhancement	Benefit	Associated Costs and/or Requirements
Addition of mail services	Email available to all employees No longer relying on an outside ISP for Email	Requires full time connection to the Internet Requires system administrator management
Addition of a broadband connection	Faster Internet access to all users Provides full time connection to the ISP	High cost Could require hardware upgrades
Automated backup	Increased security for the business Allows for implementation of disaster recovery plans	Cost Requires hardware upgrades Configuration of the appropriate software Training for personnel on usage
Increased disk space	· Increased storage for the users Increased security as users make network storage their primary storage medium	Cost Requires hardware upgrades Training for personnel on usage
Management by GUI	Easier for System Administrator GUI tools are generally more advanced than console based tools	Cost Requires significant hardware upgrades Configuration of the software involved
Support for more clients	Allows for expansion of the network and	Cost Requires hardware upgrades
Use of DHCP to support the clients	Allows for support for more clients Easier setup for client machines	Requires more involvement by system administrator Network requires routine maintenance
Increased testing	· Increased reliability and functionality of the system	Costs Requires significant commitment by management for the resources

All of these areas for future development become more relevant as the business expands and more personnel need network access. As the functionality of the server is increased, so do the hardware requirements. The point is reached when the requirements on networking infrastructure demand the deployment of a departmental or workgroup server. These requirements then drive the requirements for the necessary support personnel to manage it.

This project focused on the construction of a network appliance to meet the networking requirements for a small business or a SOHO environment. The basic requirement was to provide file and printer services along with Internet connectivity to a small number of client machines, with very specific limitations and delimitations, which included that the resulting device run unattended, with little or no support or management requirements.

A plan for the construction of this device using the system development life cycle methodology was developed, and the network appliance was constructed and implemented in an actual SOHO environment. Validation, verification, and evaluation of the system showed that the device met all of the original goals for the project, and the users were quite satisfied with the result. Finally, the need for the business to conduct a thorough “build or buy” analysis was discussed, along with areas for future development of the system and further research.

Return to the Table of Contents

Abstract

Justification

Problem Solving Methodology

Cost-Benefit Analysis

Item

Cost

Remarks

Network Operating System

Cost

Considerations

System Design and Construction

Platform

Processor and Memory

Comments

Installation of Operating System

/etc/hosts

/etc/hosts.allow

/etc/hosts.deny

/etc/host.conf

/etc/resolv.conf

Samba Configuration

Pppd and Diald Configuration

/etc/diald.conf

/etc/ppp/logicsouth1.chat

Installation of the Battery Backup and Power Monitoring Software

/etc/named.boot

/etc/named.conf

/var/named/named.local

/var/named/named.johnson1-pbj1.net

/var/named/named.192.168.1

Final Configuration

Validation, Verification, and Evaluation

Testing

Performance Testing

Area for Enhancement

Benefit

Associated Costs and/or Requirements

Other Reading and Non-Cited References