This series of articles covers the development of a Linux-based server that supports a number of workstations running MS Windows in the computer laboratory of a 55+ RV Resort in Mesa, Arizona. The age-old stereotype of senior citizens playing shuffleboard by day and bingo by night is outdated, if ever true. Such activities have their role; however, our residents are equally as likely to be in the computer room, sending and receiving e-mail or browsing the Web to research their latest financial, medical or recreational question. Our facility protects the local machines from inexperienced and/or inept users, but it also offers sophisticated services for the user that needs them.

Prior to beginning this project, I had experience using a wide variety of computer systems; however, my UNIX and Linux experience was minimal. My computer background began in 1963 as a Fortran programmer on mainframes in support of my own scientific research. In the early 1970s, I was a part of a small team that developed real-time software and hardware for interfacing PDP-11's to scientific instruments. In 1981, I became system manager for a VAX-11/780 and ran various systems. At this position, I gained some experience with UNIX and Linux systems until my retirement came in mid 1999. At that time, I became a full-time RV resident, dedicated to the avoidance of cold weather.

In November 1999, we arrived in Mesa, Arizona, and occupied a site in the Mesa Regal RV Resort, which is a 55+ community. Given my long-time involvement with computers, I naturally joined the computer club. It had been established six or seven years earlier, when one of the residents transported his personal computer to a classroom once a week to teach the residents how to use such a machine. The next step was for him and his students to conduct fund-raising and purchase a single PC for teaching purposes.

By the time of my arrival in Mesa, the computer club had expanded from that humble beginning to a dedicated computer room, populated with 8 Windows-based PCs. These machines shared a DSL broadband Internet connection with routing and network address translation services provided by WinGate software running on one of the PCs. This configuration was proposed and implemented by a consultant, as the computer club had no internal expertise in networking.

During my first season in Mesa, the club facilities expanded to 12 computers. The following summer (2000), the RV resort was sold to Cal-Am Properties, Inc., which has a commitment to providing computer access to the residents of its properties. The company's initial contribution was to add ten new workstations and replace the two oldest computers. At this point, however, we ran into a problem: our WinGate license would support only 5 concurrent Internet sessions, which was not nearly enough for 22 workstations. Because I had more networking experience than did the others, I was asked to propose solutions to this problem. I rejected the first option of purchasing additional licenses for the WinGate software, as this would have been relatively expensive. In addition, my real-time background and experiences with Windows made me highly distrustful of using Windows 98 in a mission-critical role.

The second option was to convert one of the recently retired machines, which did not have sufficient resources to run Windows 98, into a router. I learned that Linux could operate nicely on minimal hardware, so I began developing a router on a 133MHz Pentium with 16MB of RAM, a 1.4GB hard drive and two Ethernet interfaces. The resulting system was built from a SuSE 6.4 distribution, employing a 2.2.x kernel. The firewall and network address translation functions were provided by the ipchains facility. Not only was this system built from surplus equipment at no cost for hardware, it clearly could handle all the workstations. It also added firewall functionality. The only "cost" was development time. This system went into service in November 2000 and served us well for more than one year.

In January 2002, the router memory was upgraded from 16MB to 32MB, the kernel was upgraded to the 2.4.x series, and the firewall was rewritten using iptables functionality, which added stateful information regarding each packet. Not only could we block external connection attempts based on TCP or UDP port, we also could pass only those packets that contain information explicitly requested.

In late 2002, a computer with a 400MHz processor, 64MB of RAM and a 6GB hard drive became available. The router system was transferred to this machine, and the previous unit became a cold spare. It never was called on, though, as the newer unit also was stable. It ran until June 2004, with reboots needed only for kernel upgrades and long power failures that exhausted the battery backup unit. At one time, the router had run in excess of one year between reboots.

In the summer of 2004, the resort owners expanded and refurbished the computer room, replacing all the old computer equipment with 39 new Windows XP workstations connected to the Internet by way of a T-1 line. This was a perfect opportunity to upgrade the server using the fastest of our old computers, an AMD Athlon 1800+. It had 256MB of RAM, two disk drives with a storage total of 10GB and two network interfaces. The SuSE 9.1 distribution, which has a 2.6.x kernel, was the basis for the new system. The two hard drives were partitioned using the following scheme:

One of the advantages of Linux is it supports several distinct filesystems, and the user can choose among them. I selected the Reiser filesystem for its journaling capability, which avoids long recovery times in case of system crashes or power failures. It also is more efficient than the Linux-default ext2 filesystem when there are large numbers of small files. Linux also presents multiple disk drives in what appears to be a monolithic filesystem. Even remote filesystems, mounted across a network, are referenced using a path with exactly the same form as local files.

Our current Windows environment consists of 38 user stations, each with a 2.4GHz Celeron processor, 256MB of RAM and a 40GB hard drive. The single instructor's machine has a 3.0GHz P4 processor, 512MB of RAM and and 80GB hard drive. All of the machines have Windows XP Pro, DVD ROM - CD/RW optical drives and 17" flat-screen LCD monitors. Other equipment includes an XGA projector, an HP2300N b/w laser printer, an HP4650N color laser printer and two scanners. We also have several free RJ-45 ports so users can connect to the Internet using personal notebook computers. In addition, free Wi-Fi access is being provided throughout the park. Figure 1 shows a view of part of our computer facility.

Every resident of the RV park is eligible to use the computers; however, during the winter season (Nov. 1 - March 31), only members of the club can use either printer or take classes. During the remainder of the year, access to the color printer is blocked, but the b/w printer is available. In season, the computers are available from 7AM to 9PM, seven days a week, with roughly 25,000 individual user sessions per season. This season, all 38 machines frequently are busy and more users are waiting. Club rules prevent an individual user from installing new programs, storing files on any of the computers or changing any settings. A software program that restores each machine in the middle of each night enforces these rules.

Now that I have become more familiar with Linux, I would like to offer one or more systems with a Linux desktop; however, I don't think our user base would support this. In fact, many of our users operate the computer by rote and are lost if even a desktop icon is missing.

The most important functions of the Linux box in the current setup are to act as the gateway for the Windows workstations, perform network address translation for them and protect the network from outside intrusion. These tasks are accomplished by using a boot-time script that utilizes the iptables facility of Linux. The first step is to make certain the necessary kernel modules are loaded. These probably would be autoloaded; however, these instructions generate an error if any of these modules are missing.

modprobe ip_tables
modprobe ip_nat_ftp
modprobe ip_conntrack_ftp

The next step is to turn off packet forwarding and turn on route verification on all interfaces to prevent IP spoofing. This syntax is appropriate for the bash shell. N.B. /proc is a pseudo filesystem containing information that describes and controls drivers and processes.

echo 0 > /proc/sys/net/ipv4/ip_forward
for i in /proc/sys/net/ipv4/conf/*/rp_filter 
do
  echo 1 > $i
done

The next set of commands defines the symbol IPTABLES as the absolute path of the iptables binary, deletes all existing rules and removes all user-defined chains.

IPTABLES="/usr/local/sbin/iptables"
$IPTABLES -F                            # delete all the rules
$IPTABLES -X                            # delete all user-defined chains

We now set the policies for the standard chains. Incoming packets are dropped unless we have a rule that accepts them; whereas outgoing and forwarded packets are accepted unless a rule drops them.

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT

We now establish network address translation (NAT). This rule will source NAT everything heading out the eth1 (external) interface to the IP of that interface. This form is correct for a dynamic IP.

$IPTABLES -t nat -A POSTROUTING -o eth1 -j MASQUERADE

We now create three logging chains and a silent chain to drop packets that will be identified by rules entered later. Packets are dropped rather than rejected to hide our existence from a potential intruder. To help prevent any denial-of-service attack from succeeding, the maximum rate at which log entries are generated is limited. The backslash (\) character is used to continue a command onto a new line.

$IPTABLES -N firewall
$IPTABLES -A firewall -m limit --limit 15/minute -j LOG \
      --log-prefix "*** Firewall:"
$IPTABLES -A firewall -j DROP
$IPTABLES -N dropwall
$IPTABLES -A dropwall -m limit --limit 15/minute -j LOG \
      --log-prefix "*** Dropwall:"
$IPTABLES -A dropwall -j DROP
$IPTABLES -N badflags
$IPTABLES -A badflags -m limit --limit 15/minute -j LOG \
      --log-prefix "*** Badflags:"
$IPTABLES -A badflags -j DROP
$IPTABLES -N silent
$IPTABLES -A silent -j DROP

The local loopback device (127.0.0.1 or lo) and the internal Ethernet interface (eth0) are deemed to be trusted, and any packets destined for the outside are routed without further inspection. This assumption may not be appropriate for your network, depending on your users.

$IPTABLES -A INPUT  -i lo -j ACCEPT
$IPTABLES -A OUTPUT -i lo -j ACCEPT
$IPTABLES -A INPUT  -i eth0 -j ACCEPT
$IPTABLES -A OUTPUT -i eth0 -j ACCEPT

All packets originating from our nameservers, which are external, are accepted.

$IPTABLES -A INPUT -i eth1 -s 198.6.1.4 -j ACCEPT
$IPTABLES -A INPUT -i eth1 -s 198.6.1.5 -j ACCEPT
$IPTABLES -A INPUT -i eth1 -s 198.6.1.195 -j ACCEPT

The next set of rules catches all malformed packets that have illegal combinations of flags and places them on the badflags chain, which logs and drops them.

$IPTABLES -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j badflags
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j badflags
$IPTABLES -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG \
       -j badflags
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j badflags
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j badflags
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j badflags

The next section silently drops packets that generate a lot of log entries but are not deemed harmful, including the netbios stuff that Windows machines generate.

$IPTABLES -A INPUT -i eth1 -s 167.216.187.186 -j silent
$IPTABLES -A INPUT -p udp --sport 137 --dport 137 -j silent

Most icmp packets are dropped. Only type 8 (ping) and type 0 (ping reply) are accepted. Pings are limited to one per second.

$IPTABLES -A INPUT -p icmp --icmp-type 8 -m limit \
       --limit 1/second -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type 0 -j ACCEPT
$IPTABLES -A INPUT -p icmp -j firewall

Secure-shell packets coming in on eth1 are accepted only from networks 10.10.x.0.

$IPTABLES -A INPUT -i eth1 -s 10.10.0.0/16 -p tcp --dport 22 -j ACCEPT

Any remaining packets coming from the external interface (eth1) are dropped unless their state is ESTABLISHED or RELATED. No external computer can create a connection to any computer on the inside.

$IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

The final rule is to send anything still on INPUT to the dropwall chain. That way we don't get silent drops.

$IPTABLES -A INPUT -j dropwall

The final step is to turn on packet forwarding and echo an appropriate line to the console.

echo 1 > /proc/sys/net/ipv4/ip_forward
echo "The MRCC Firewall is up and running."

The above rules have protected our network from external attacks for nearly four years now.

My next article will cover basic support functions provided by the Linux system for our network, including a Web server for our local intranet, a cache-only name server and a DHCP server.

Firewalling - iptables by Kyle Wheeler.

Linux ISO, a Listing of CD Images for Numerous Linux distributions

"Tools for Desktop Success"

"Desktop Guerrilla Tactics: a Portable Thin Client Approach"