443 lines
18 KiB
HTML
443 lines
18 KiB
HTML
<!--startcut ==========================================================-->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<title>Secure Public Access Internet Workstations LG #25 </title>
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#A000A0"
|
|
ALINK="#FF0000">
|
|
<!--endcut ============================================================-->
|
|
|
|
<H4>
|
|
"Linux Gazette...<I>making Linux just a little more fun!</I>"
|
|
</H4>
|
|
|
|
<P> <HR> <P>
|
|
<!--===================================================================-->
|
|
|
|
<center>
|
|
<H1>Secure Public Access Internet Workstations </H1>
|
|
<H4>By <a href="mailto:ssinger@interlog.com">Steven Singer </a></H4>
|
|
</center>
|
|
<P> <HR> <P>
|
|
|
|
<h2>Introduction.</h2>
|
|
<p>
|
|
|
|
Linux is the perfect operating system to deploy in a hostile environment, the built in security
|
|
features combined with the customization most window managers allow make Linux ideally
|
|
suited to this task. Recently a local career planning agency wanted to deploy a dozen public
|
|
access Internet workstations at various locations in the community including libraries and
|
|
hospitals. Linux was chosen as the operating system for the task. This article provides details
|
|
about how to setup Linux so that it can safely be deployed as a public access workstation.<p>
|
|
|
|
<p>
|
|
|
|
<h3></h3>
|
|
<h3>Why Linux</h3>
|
|
<p>
|
|
|
|
When it came time to decide on how to setup the workstations various solutions were
|
|
considered. It was decided before hand that the hardware would be Intel-based PC's. That
|
|
essentially left us to consider the various Microsoft offerings or Unix. The licensing costs for
|
|
NT would have added significantly to the projects budget. Even after buying NT licenses for
|
|
each workstation, an experienced administrator would have had to spend time configuring and
|
|
securing each NT machine. It was determined that NT was an option, but an expensive one.
|
|
Win95 is significantly cheaper than NT, but lacks the built in security features of a more
|
|
advanced operating system. Our biggest fear with Win95, was that we would frequently have
|
|
people walking in and messing up the systems setup. Linux offered us a solution to all of
|
|
these problems. The flexibility of X-Windows, combined with Linux's basic security features
|
|
allowed us to setup the workstations such that we did not have to fear hostile users. The
|
|
licensing costs were essentially non-existent, and setting up each workstation became a
|
|
manner of following a simple routine.<p>
|
|
|
|
<p>
|
|
|
|
<h2>The Installation Procedure.</h2>
|
|
<p>
|
|
|
|
When you have to setup a bunch of Linux workstations with essentially the same
|
|
configuration, there are two approaches you can take. The first one consists of setting up and
|
|
testing the first machine, then dupilicate the entire hard disk onto each workstation. (If you
|
|
are doing this remember that you will most likely have to re-run Lilo on each workstation).
|
|
The second method is to manually set-up each workstation by following a standard check-list.
|
|
We opted for the second method due to logistical reasons. However, the installation
|
|
procedure was automated by re-using config files, and running scripts where possible. <p>
|
|
|
|
We used RedHat 4.3 as our distribution, installing from the RedHat PowerCD set. I
|
|
suspect any decent Linux distribution would have worked equally as well. By the time we
|
|
had finished the installation of the first machine, I had established a step by step checklist of
|
|
things to do during the install. As we went along, we occasionally revised the check-lists
|
|
which required us to go back to the original few machines and make some changes after the
|
|
fact. <p>
|
|
|
|
<p>
|
|
|
|
<b><p>
|
|
|
|
</b><h3>OS Installation & Networking.</h3>
|
|
<p>
|
|
|
|
The installation started out as a standard Red-Hat install, the machines had plenty of hard
|
|
disk space so we were quite liberal in what packages we installed. This included any
|
|
networking stuff we felt was relevant, and X-windows. We had to manually install<p>
|
|
|
|
ipfwadm since there wasn't an explicit option for it.<p>
|
|
|
|
<p>
|
|
|
|
<h4>Dial-out-on demand.</h4>
|
|
The machines were to be connected to the Internet via a modem, we used the dial-out-on
|
|
demand PPP support that is built into the 2.x series of kernels. We placed a chat script
|
|
containing the pertinent information in /etc/ppp and insured that only <i>root</i> had any sort of
|
|
access to it.(mode 700) For more details on setting up dial-out on demand networking see the
|
|
kernel 2.0 documentation and the PPP FAQ. The Networking HOWTO should also contain
|
|
some useful information. We then tested the network connection to insure it worked. <p>
|
|
|
|
<p>
|
|
|
|
<p>
|
|
|
|
<h2>X-Windows.</h2>
|
|
<p>
|
|
|
|
<h3>XF86Config</h3>
|
|
<p>
|
|
|
|
The XF86Config file is the configuration file for the XFree86 X server. We created this file
|
|
as we would have for a normal Linux workstation running X except added the lines
|
|
"DontZap" and "DontZoom". DontZap prevents a user from killing the X-server with a break
|
|
key sequence. DontZoom prevents dynamic changing of resolutions. Both of these options
|
|
prevent a hostile user from making the machine look somehow different for the next person
|
|
that comes along. Further details about this file can be found in the XF86Config man page.<p>
|
|
|
|
<p>
|
|
|
|
<h3>Xdm.</h3>
|
|
Xdm is a log in manager for X-windows. Instead of the standard text-based login prompt you
|
|
normally get at the Linux console, Xdm is a X based program that asks the user for a user-name and password. The user is then logged in with X-windows running. <p>
|
|
|
|
<p>
|
|
|
|
The following files are located in xdm go in /usr/X11R6/lib/X11/xdm.<p>
|
|
|
|
<p>
|
|
|
|
<h4>Xsession </h4>
|
|
We used a standard Xsession file, however we made sure that it loaded fvwm as our window
|
|
manager(Other window managers will also work, however we decided to use fvwm)<p>
|
|
|
|
<p>
|
|
|
|
<h4>XResources</h4>
|
|
<p>
|
|
|
|
The XResources file controls settings for xdm's log in process. We used the standard
|
|
XResource file but added/changed the following lines. They all effect the apperence of the
|
|
login window, with the exception of the last line which allows our <i>guest</i> account to work
|
|
without a password. <p>
|
|
|
|
<p>
|
|
|
|
<TT><BLOCKQUOTE><CODE><I>
|
|
xlogin*greeting: Welcome, please log in as 'guest', with no
|
|
password.<BR>
|
|
xlogin*namePrompt: login:\xlogin*fail: Login incorrect, please use the username 'guest'
|
|
with no password<BR>
|
|
xlogin*allowNullPasswd: true<p>
|
|
</TT></BLOCKQUOTE></CODE></I>
|
|
|
|
and removed the following from the translations section to a user from getting around XDM.<p>
|
|
|
|
<p>
|
|
|
|
<TT><BLOCKQUOTE><CODE><I>
|
|
Ctrl<Key>R: abort-display()\n\ <p>
|
|
</TT></BLOCKQUOTE></CODE></I>
|
|
|
|
<p>
|
|
|
|
<h4>XSetup</h4>
|
|
The XSetup file is called once the user logs in, any programs you want to run upon login can
|
|
be started from this file. this is where we would place an <i>xsetroot</i> command or something
|
|
similar. The default version of XSetup might start Xconsole(a program that displays the text-output of the Xserver in a small window) we did not want this information to be visible so
|
|
we commented that line out.<p>
|
|
|
|
<p>
|
|
|
|
<h3>FVWM setup.</h3>
|
|
<p>
|
|
|
|
We choose fvwm as our window manger as a matter of personnel preference and familiarity,
|
|
most other window managers will require similar changes. All configuration information for
|
|
a users fvwm setup is stored in a file named <i>.fvwmrc</i> located in their home directory. A
|
|
system-default version of the config file is often located in
|
|
<i>/usr/X11R6/lib/X11/fvwm/system.fvwmrc</i>. We will use this file as our base, and outline the
|
|
important things you will have to check for. Since there is no "standard" base fvwm
|
|
configuration, I will only outline the changes to make, and will assume familiarity with the
|
|
format of an fvwmrc file. <p>
|
|
|
|
<p>
|
|
|
|
<h4>The Popup Menu's.</h4>
|
|
<p>
|
|
|
|
The config file you use as your base will most likely start off with some pop-up menu's
|
|
predefined. You will want to remove many of the predefined menu items.. I would
|
|
recommend only leaving two items, "netscape" and "exit".<p>
|
|
|
|
<p>
|
|
|
|
<h4>Paging.</h4>
|
|
<p>
|
|
|
|
It is a good idea to disable paging, this will avoid some unnecessary user confusion. <p>
|
|
|
|
This can be done with a line saying.<p>
|
|
<TT><BLOCKQUOTE><CODE>
|
|
<i>PagingDefault 0</i><p>
|
|
</TT></BLOCKQUOTE></CODE>
|
|
|
|
It is also a good idea to remove the "<i>Pager"</i> line if one exists. <p>
|
|
|
|
<p>
|
|
|
|
<p>
|
|
|
|
<h4>GoodStuff</h4>
|
|
<p>
|
|
|
|
The GoodStuff program that comes with Fvwm places a "Button-bar" at a predetermined
|
|
location on the screen. This button bar allows for easy launching of applications. GoodStuff
|
|
is a flexible program that can be tailored to your taste. I chose a button bar consisting of a
|
|
single row located at the top-left of the desktop. The following are the relevant lines. <p>
|
|
|
|
<p>
|
|
<TT><BLOCKQUOTE><CODE><I>
|
|
|
|
*GoodStuffRows 1*GoodStuff Netscape netscape.xpm Exec "Netscape"
|
|
/usr/local/netscape/netscape*GoodStuff Logout mini.exit.xpm Quit-Verify
|
|
</TT></BLOCKQUOTE></CODE></I>
|
|
|
|
I created a pixmap file named netscape.xpm containing the netscape logo to be used as my
|
|
icon. Pixmaps are usually stored in <i>/usr/X11R6/include/pixmaps</i>. <p>
|
|
|
|
<p>
|
|
|
|
<h4>Startup commands.</h4>
|
|
<p>
|
|
|
|
Fvwm allows you to execute certain programs upon start-up. Since any guest users logging
|
|
onto the machine would be using the Internet, we decided ensure that the modem starts to
|
|
dial as soon as possible. We added an Initfunction section to the end of the fvwmrc file. If
|
|
the PPP link already happens to be up, the ping will be successful, otherwise the kernel
|
|
should start the connection process. Replace router.myisp.ca with the hostname of a machine
|
|
located at your ISP.<p>
|
|
|
|
<p>
|
|
|
|
<TT><BLOCKQUOTE><CODE><I>
|
|
Function "InitFunction" Exec "I" /bin/ping -c 1 router.myisp.ca &
|
|
EndFunction<p>
|
|
|
|
</TT></BLOCKQUOTE></CODE></I>
|
|
<p>
|
|
|
|
<h2> Security Considerations.</h2>
|
|
<p>
|
|
|
|
<h3>BIOS Setup.</h3>
|
|
<p>
|
|
|
|
In a situation where the console is publicly accessible the BIOS is your first line of defense
|
|
against hostile intent. Most modern BIOS's support password protection of some sort. It is
|
|
recommended that a boot-up password be set. In our setup, we decided that we only wanted
|
|
to allow "trusted" people to be able to boot the machine. Otherwise someone could boot the
|
|
machine using a floppy disk as the root file system,(thus they will be able to gain root
|
|
privledges), or alternatively boot into DOS and format the hard-disk. In addition to the boot-up password we also installed a password to protect the BIOS setup, and disabled booting
|
|
from the floppy drive.<p>
|
|
|
|
<p>
|
|
|
|
<h3>Inittab</h3>
|
|
<p>
|
|
|
|
<i>/etc/inittab </i>is the configuration file for the "init" process. Since we wanted our workstations
|
|
to work only in X-Windows, we changed the initial runlevel to 5. It is done with the
|
|
following line. This means that when the machine boots, The X-server and Xdm are started
|
|
automatically. <p>
|
|
|
|
<TT><BLOCKQUOTE><CODE>
|
|
<i>id:5:initdefault: </i><p>
|
|
|
|
</TT></BLOCKQUOTE></CODE>
|
|
<p>
|
|
|
|
"Init" is also responsible for handling the "getty"'s or terminal monitors which handle text-based logins from the console or other terminals physically connected to the machine. The
|
|
default <i>inittab</i> file should have a section that looks similar to this.<p>
|
|
|
|
<p>
|
|
|
|
<TT><BLOCKQUOTE><CODE><I>
|
|
1:12345:respawn:/sbin/mingetty tty1<BR>
|
|
2:2345:respawn:/sbin/mingetty tty2<BR>
|
|
3:2345:respawn:/sbin/mingetty tty3<BR>
|
|
4:2345:respawn:/sbin/mingetty tty4<BR>
|
|
5:2345:respawn:/sbin/mingetty tty5<BR>
|
|
6:2345:respawn:/sbin/mingetty tty6 <p>
|
|
</TT></BLOCKQUOTE></CODE></I>
|
|
|
|
You should remove the "5" from the second section of each line. The result should look
|
|
something like this.<p>
|
|
|
|
<p>
|
|
|
|
<TT><BLOCKQUOTE><I><CODE>
|
|
1:1234:respawn:/sbin/mingetty tty1<BR>
|
|
2:234:respawn:/sbin/mingetty tty2<BR>
|
|
3:234:respawn:/sbin/mingetty tty3<p>
|
|
|
|
</TT></BLOCKQUOTE></I></CODE>
|
|
This means that when the system is in runlevel 5(The runlevel where X-windows starts up to
|
|
handle log-ins.) A user is unable to login from the text-based console. Before making this
|
|
change it is a good idea to insure that X-windows and XDM are working properly. Disabling
|
|
text-based logins is not essential to security, but we felt that it would confuse users who
|
|
would walk up to a machine that was left logged in text mode. If for some reason X-windows
|
|
stops working after you disable text-based logins, you will have to boot the machine into
|
|
single user mode in order to login. This can be done by passing an option to the kernel from
|
|
the lilo command prompt.<p>
|
|
|
|
<p>
|
|
|
|
<h3>S90Console.</h3>
|
|
<p>
|
|
|
|
RedHat uses the SVR4 style init-scripts to manage the boot-up process. The basic idea is that
|
|
there is a directory for each runlevel under /etc/rc.d. When <i>init</i> switches runlevels it goes
|
|
into the appropriate directory and executes each file that starts with a 'S' in ascending order.
|
|
Eg on my RedHat system, when my system enters runlevel 3(multi-user) first
|
|
/etc/rc.d/rc3.d/S10network is executed, and lastly /etc/rc.d/rc3.d/S99local is executed. <p>
|
|
|
|
Even though we disabled the getty's for the console, a user could still press CTRL-ALT-F1
|
|
(or another function key) to switch to another virtual console from X-windows. I am unaware
|
|
of a way of preventing this (short of kernel modifications). So in the event that a user
|
|
accidently ended up switching virtual consoles we decided to leave the user instructions on
|
|
how to get back into X-windows. We created the file S90Console and placed it in
|
|
/etc/rc.d/rc5.d and gave root execute permissions to it. The file looks as follows.<p>
|
|
|
|
<TT><BLOCKQUOTE><CODE><I>
|
|
#!/bin/shD="Press Ctrl+Alt+F2 to use this computer"<BR>
|
|
echo $D>/dev/tty1<BR>
|
|
echo $D>/dev/tty3<BR>
|
|
echo $D>/dev/tty4<BR>
|
|
echo $D>/dev/tty5<BR>
|
|
echo $D>/dev/tty6<BR>
|
|
echo $D>/dev/tty7 <p>
|
|
</TT></BLOCKQUOTE></CODE></I>
|
|
Since getty does not run on any virtual-consoles, the X-server uses the second virtual console
|
|
by default. <p>
|
|
|
|
<p>
|
|
|
|
<p>
|
|
|
|
<h3>inetd.conf</h3>
|
|
<p>
|
|
|
|
The file /etc/inetd.conf is the configuration file for the inetd daemon. This daemon is
|
|
responsible for starting daemons that provide network services when needed. Not all daemons
|
|
are started by inetd. Many, such as sendmail and httpd can either run in standalone mode, or
|
|
under inetd. If your machine is only being used as a workstation, and is not providing
|
|
network services to anyone then you should disable all unnecessary daemons. To disable a
|
|
daemon that is currently being started by inetd, just added a '#' sign at the beginning of the
|
|
relevant line to comment it out. I would recommend disabling finger, pop, ntalk, talk, and
|
|
any other daemons that are not being used. We decided to leave telnet and ftp enabled to
|
|
allow for remote administration. However if you are doing this remember to keep an eye out
|
|
for security advisories that deal with problems associated with these packages(and any other
|
|
program that is running on your system.) Usually fixing a bug is just a question of upgrading
|
|
to the newest version of the program in question.<p>
|
|
|
|
<p>
|
|
|
|
<h3>Firewalling Issues.</h3>
|
|
<p>
|
|
|
|
The Linux kernel can be configured to support IP Firewalling. This allows you to specify
|
|
what packets the kernel should ignore, for example you can instruct the kernel to refuse to
|
|
route any packets from the local machine destined to TCP port 25(of any machine). You must
|
|
enable IP Firewalling, when compiling your kernel if you want to use this feature. You
|
|
control the firewall parameters with the "<i>ipfwadm</i>" command, usually located in <i>/sbin</i>. We
|
|
added the following lines to /etc/rc.d/rc5.d/S99local. <p>
|
|
|
|
<p>
|
|
<TT><BLOCKQUOTE><CODE>
|
|
|
|
<i>/sbin/ipfwadm -I -f<p>
|
|
|
|
/sbin/ipfwadm -O -f<p>
|
|
|
|
/sbin/ipfwadm -O -a deny -P tcp -D 0.0.0.0/0.0.0.0 25<p>
|
|
|
|
/sbin/ipfwadm -O -a deny -P tcp -D 0.0.0.0/0.0.0.0 119 </i><p>
|
|
|
|
</TT></BLOCKQUOTE></CODE>
|
|
<p>
|
|
|
|
This restricts all outgoing traffic to port 25 (The mail port) so users can not send mail. Since
|
|
anyone could walk up and use our workstations, we felt that it would be a bad idea to allow
|
|
them to send mail. Likewise we restricted port 119(the news port) so usenet access is not
|
|
allowed. Ideally we would have liked to allow read-only usenet access from Netscape,
|
|
however I could not figure out how to do this so decided to be safe and restrict all usenet
|
|
access.<p>
|
|
|
|
<p>
|
|
|
|
<h3>Permissions.</h3>
|
|
<p>
|
|
|
|
In order to insure that your setup stays, you will want to change the permissions on various
|
|
files located inside the <i>guest</i> users home directory. By this point you should have already
|
|
created a <i>guest</i> user. You should also run netscape for the first time as the guest user before
|
|
making these changes. <p>
|
|
|
|
<p>
|
|
|
|
<TT><BLOCKQUOTE><CODE><I>
|
|
chown root /home/guestchmod 555 /home/guestchown root /home/guest/.fvwmrc /home/guest/.bash_profile
|
|
chown root /home/guest/.Xdefaults /home/guest/.bashrc
|
|
/home/guest/.bash_logoutchmod 555 /home/guest/.fvwmrc /home/guest/.bash_profile
|
|
/home/guest/.Xdefaults /home/guest/.bashrc
|
|
/home/guest/.bash_logoutchmod 444 /home/guest/.netscape/preferences
|
|
/home/guest/.netscape/bookmarks.htmlchown root /home/guest/.netscape/preferences
|
|
/home/guest/.netscape/bookmarks.htm<p>
|
|
|
|
</TT></BLOCKQUOTE></CODE></I>
|
|
The commands above were executed, first we gave root ownership of the users home
|
|
directory. Changing ownership prevents the user from changing the permissions back. Then
|
|
we removed write access to the home directory. Next we changed ownership and removed
|
|
write access to the .fvwmrc file, the .bash_profile, .Xdefaults, .bash_logout, and .bashrc. This
|
|
prevents a user from changing aspects of his environment. Finally we secured the netscape
|
|
preferences file, and the bookmarks file. A user can still change the settings in netscape,
|
|
however they will not be saved, so the next person to login will be presented with the default
|
|
settings.<p>
|
|
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<center><H5>Copyright © 1998, Steven Singer <BR>
|
|
Published in Issue 25 of <i>Linux Gazette</i>, February 1998</H5></center>
|
|
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<A HREF="./index.html"><IMG ALIGN=BOTTOM SRC="../gx/indexnew.gif"
|
|
ALT="[ TABLE OF CONTENTS ]"></A>
|
|
<A HREF="../index.html"><IMG ALIGN=BOTTOM SRC="../gx/homenew.gif"
|
|
ALT="[ FRONT PAGE ]"></A>
|
|
<A HREF="./vermeer.html"><IMG SRC="../gx/back2.gif"
|
|
ALT=" Back "></A>
|
|
<A HREF="./hughes.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
|
|
<P> <hr> <P>
|
|
<!--startcut ==========================================================-->
|
|
</BODY>
|
|
</HTML>
|
|
<!--endcut ============================================================-->
|