(presented at Linuxfest 2000, Kansas City, June 22, 2000)
Luby Liao
Department of Mathematics/Computer Science
University of San Diego
San Diego, CA 92110
liao@sandiego.edu
http://www.sandiego.edu/~liao
Abstract. To super-charge your teaching, consider setting up Linux servers to host students' accounts and for easy installation of software. In this paper, the author talks about his most positive experience of setting up Linux servers in his office to free himself from having to rely on Academic Computing for student and course support, and for software development, since 1998. While it does not require an expert to manage Linux servers, care must be taken to secure them against crackers. The paper offers a simple shell script to safeguard these servers.
In the spring of 1998, I started preparing for a Client/Server Programming class that I was scheduled to teach in the Fall. I expected students to program in Java and Perl using the current versions of the software. I wanted to provide them with web server machines that also run database servers to enable them to host Java applets that have database connectivity. I wanted to make tools like emacs/xemacs available to them. I chose to build a Linux server to make this happen.
I spent about $600 to buy components, and with the help of two staff members of Academic Computing, Reuben Valdez and Daniel Kramarsky, assembled the components and turned it into a Red Hat Linux 5.0 machine running on a 200 MHz Pentium MMX CPU. Because of the nature of the Red Hat Linux distribution and installation, the software I anticipated using was installed at the outset, or could be easily installed later on. For example, Perl, Python, tcl/tk was installed when the Linux was installed. Additional Perl modules were installed easily using CPAN. Apache web server was running when the Linux started. Xemacs, MySQL database and a newer version of JDK was installed in no time.
In the first week of the fall semester of 1998, I wrote an Expect script
to create about 40 student accounts for my Client/Server
Programming class and upgraded the memory from 64 MB to 196 MB. The
Linux system worked smoothly except when many students logged in before
a project was due. Some students were inspired to set up their own
Linux boxes and programmed on their own machines, further lightening the
load on the server, code-named dragon, or dragon.acusd.edu
in this article. For those students setting up their own Linux boxes,
dragon served as a model and provided guiding examples for them.
Students loved this machine, saying it had all the programs they needed.
After dragon was running, we were very self-sufficient. I did
not need to ask Academic Computing for any software support for this
course.
In spring 1999, I recruited myself to teach a programming I
section because, as the chair of the department, I was unable to find an
instructor for that section. I decided that Java by itself was too
mysterious and difficult for beginners and decided to use Python as the
primary and Java as a complementary language. At that time, my only
experience with Python was a quick reading of a Python tutorial from
Mark Lutz's Programming Python book[1]. Dragon proved to
be very valuable: Python was already installed and ready to be
experimented. I also quickly installed and played with JPython[2] (a
Python implementation written in 100% Java). The ease of installing and
experimenting with software was pivotal to the great success of this
experiment of using Python in CS1 instruction[3].
In the fall of 1999, I taught a class in Web Programming. One of the
students' projects was to set up their own Linux servers. As a result,
many students started using their own servers instead of using dragon.
I consider this a great contribution to the students' growth.
Starting in the fall of 1998, I set up accounts for my computer science
students on dragon. In the spring semester of 1999, Jane
Friedman, a colleague, and I formed the USD Web Group to provide a service
learning experience for computer science students and to provide
programming service to the USD community. Students meet weekly for
seminars. Concurrently, they help people on campus with their
web-related problems[4]. All group members were also given accounts on
dragon and urged to set up their own Linux machines.
Since 1998, I have made fewer service requests to the Academic Computing
largely because of dragon. Everybody benefited: the students
enjoyed working on what they believed to be the best server on campus,
Academic Computing received few requests from me, and I was able to do
more in a shorter period of time. To illustrate, it took me less than
one minute to configure a Red Hat Linux 6.2 server
goddess.acusd.edu to print to a network printer
clare.acusd.edu. It is not realistic or reasonable to ask
Academic Computing to provide such speedy and spontaneous service owing
to their manpower, work schedule, policy and priority.
dragon got cracked into
One day during the winter break of 2000, dragon lost connection
to the outside world, while my office Sun Sparc and PC still were
connected. Subsequently, Academic Computing showed me email messages
from other universities complaining that dragon was probing their
computers for entry. Academic Computing immediately placed
dragon behind a firewall, blocking all packets to and from
non-USD destinations to prevent more damage. They suggested that I reformat
the hard drive and reinstall Linux on dragon.
Interruption of service was unpleasant. But I felt the event was positive. First of all, this motivated me to secure the server. Next, it motivated me to build more servers.
I received a message from an associate director of the Career Services,
wondering why he suddenly stopped receiving mailed-in filled-out web
forms on the Career Services' web site. He experimented with accessing
the form from his office and filled out the form himself. He was able
to receive his own form. So, 'why have visitors to the web site stopped
filling out these forms?', he asked. Soon, he received complaints from
companies saying that they could not access the page that contained the
form. The problem was that Career Services' Web Group student helpers
used dragon for web development and hosting, and the form was
served from dragon. Why did students choose dragon to do
web development and hosting? Because it was more convenient than using
other web servers. I suggested that they serve all the web pages from
Academic Computing's web servers. The students were willing but
reported that there were difficulties. For example, some pages were
Python CGIs that were not supported by their web servers.
At this point, I decided to have more servers in my office. There are two obvious advantages. First, if student accounts are distributed among many servers, the load is shared among all the servers, improving the performance of each. Next, any of the web-group assisted web pages that use any of my servers can be easily relocated to another server, reducing potential down-time.
A Web Group student Jeff Wagner volunteered to build a Linux server out
of components. He did an excellent job building a Pentium II, 400 MHz
machine with 256 MB and installed Red Hat Linux 6.1 on it. I quickly
set up student accounts on this new machine code-named goddess.
Web Group students quickly moved their web pages from dragon to
goddess. Everything was working smoothly again. Meanwhile, we
took the time to rebuild dragon.
What must have helped crackers is the fact that when the Red Hat Linux was installed, many server processes were automatically configured to run, giving crackers doors of entry from remote computers.
Michael Chiles, a most amiable, helpful and competent system operator from Academic Computing took up the task of securing all the server class machines in my office. The idea was to turn off all except the absolutely necessary system services for remote access that serve my purposes. For example, since the users all have email access using other machines, my Linux servers do not need to provide email service, so we can turn off sendmail. Likewise, since all users have accounts on other USD machines, we can allow telnet only from USD machines. A cracker from New York will need to access another USD machine before she can attempt to crack a Linux server in my office.
To harden my Linux servers, Michael first downloaded toaster[5], a shell script originated from the University of California at Irvine. Toaster was designed to secure a number of different UNIX based installations by disabling any daemons or services which communicate across network ports, including httpd, ftp, and telnet. This is done by modifying or moving run control scripts that activate network daemons, and by disabling all services activated through the inetd daemon.
The script was modified to be less stringent in shutting down daemons and services. Those run control scripts that activate desirable daemons were left untouched by commenting out toaster code which shuts them down. Inetd services were re-instated using a simple sed script which accepts a list of services to recover and processes the inetd.conf file to uncomment those lines that removes these services. For the modified code, please see [6].
Linux is enabling. I use it to run servers to host student accounts and to support all my computer science courses including Client/Server Programming, Programming I and II, and Web Programming since 1998. These servers also support the USD Web Group that we formed in 1999 to provide a service learning experience for computer science students and to provide programming service to the USD community. Everybody benefits from these Linux servers: my students have wonderful servers on which to do their programming (many choose to build their own Linux machines), Academic Computing is freed from my frequent requests for service because these Linux servers are self-sufficient, and I am able to do more in a shorter period of time. Although one of my Linux servers had been compromised, it motivated me to have more servers and to secure them. A simple solution to secure servers is provided in [6].
[1] Mark Lutz, Programming Python, ORA 1996
[2] http://www.jpython.org
[3] Luby Liao, Python as the Pascal of 2000's, ORA Open Source
Convention, August 1999. See
http://conferences.oreilly.com/cd/presentations/lliao/python.pdf
[4] Luby Liao & Jane Friedman, USD's Web Group, a service learning experience in
Computer Science, International Conference on Mathematics/Science
Education & Technology, February 2000. See
http://www.acusd.edu/~liao
[5] http://www.oac.uci.edu/support/dcs/security/toaster.html
[6] http://www.acusd.edu/~liao/USDtoaster
This document was generated on 28 September 2000 using the texi2html translator version 1.52.