|
Introduction
Marketing companies are currently trumpeting the possibility of connecting to the Internet from anywhere. We hear a certain big company tantalizing us, urging us to "Imagine being able to access the Internet from anywhere." However, this vision of ubiquitous connectivity demands that you have to carry a laptop with a cellular modem or a nice new web-enabled cell-phone with a fancy 1.5 inch black and white screen - just enough to really get excited about a stock quote!
What if this vision is wrong?
What if on every corner, where we now see a pay phone, you also see an inconspicuous terminal for web access? Need to check your email in the middle of a long commute? Just stop at a gas station. Need to look at movie schedule? Just stop by and look up the nearest movie theatre web page on the Internet terminal on the corner. There are a thousand other ways to use publicly-accessible Internet terminals.
Recently, the Federal Government of Costa Rica approved a plan to install publicly-accessible terminals in post offices throughout the country that will allow all citizens to use email and access the Internet. While the benefits of such a plan are many and valuable, such a plan is not without concerns. In addition to costs of overhead, maintenance and operations, the security of information transmitted along public terminals would be a major consideration.
Linux may offer an affordable, effective and efficient solution to these security concerns. Network administrators can set up a system that runs on Linux and can only be used for web access for under $200. In addition to bolstering security, maintenance costs of such a machine would be very attractive to Network operators, especially if the system is able to boot off the CD-ROM and reliable remote administration tools are deployed.
In this article, we will discuss creating a viable, affordable system of Internet kiosks using RedHat Linux. This will include discussion of how to implement such a system, and will also touch upon some of the various aspects of security that one should consider when implementing such a system.
Set-up
The set-up of such a system presents a serious challenge. In order to be effective, the Internet terminals must be easy to use, stable and easy to maintain - ideally, no maintenance would ever be required. They must also be affordable and secure. It is vital that the terminals be protected from break-ins or intrusion and that they not be used by attackers to conduct attacks such as DoS or other attacks. (Imagine the public relations nightmare a government would endure if publicly-accessible terminals that it had established and maintained were used as a base for wide-spread damaging attacks!) For each of these necessities, Linux offers definite advantages over Windows operating systems, which are very difficult to secure and are rarely, if ever, stable.
In addition to the need for a secure system, another important requirement that Linux satisfies is ease of implementation. While the use of a specially-modified kernel to prevent the execution of non-specified explicitly permitted processes might sound like a secure solution, the efforts and costs required to implement such a system in a public-access terminal network are prohibitive. The idea is to obtain a secure solution that can be deployed in public places, such as shopping malls or gas stations with a minimum of expense and hassle. Administrators can obtain this by applying the minimum set of changes to the stock RedHat Linux distribution.
Previous solutions to this problem have either proposed a keyboardless setup that is suitable for information kiosks but is not sufficient for the full Internet/Webmail access or they have used outdated software. While securing a system that utilizes a keyboard may present a challenge, even a trackball may be sufficient for a determined attacker to cause great damage (think "cut and paste"!).
Design Ideas
Public access terminals are complicated to establish and administer. While designing the system, the network architects and administrators must make some difficult and important choices. Amongst these choices, some decisions that may want to be implemented include:
a. Reducing the installed software list to the absolute bare minimum. This means that the RPM list of a default RedHat install should be seriously cleaned up. Many of the software packages deployed by default are buggy and can lead to local and remote root exploits. If a default software is not absolutely required for web browsing functionality, it should be removed.
b. Simplifying X Window system setup, most notably, by removing unneeded Window Managers and Desktop Environments (like GNOME, KDE or fvwm). This removes potentially less stable (than XFree itself) software and simplifies the securing of the system.
c. Securing the many minor but still important things such as Magic SysRQ keys and lilo boot loader configuration should also be considered. A system may be hardened at the OS level, but it's still highly possible to take control of the system if things such as hardware settings and special key sequences are not disabled.
d. Using SSH as a remote administration tool to allow easy upgrading (unless the system is booted off a CDROM) and monitoring. The necessity for remote services is minimal - in which case, few should be running. Since firewalling the system may not be practical, it should have defenses such as a hardened operating system and rigid security policy. This is by no means a good substitute for a firewall with a restrictive rule-set capable of providing adequate protection.
e. Removing unneeded executables that are installed as part of the packages that we have to keep (such as XFree). This primarily concerns xterm and rxvt, as well as other terminal emulators. Their absence will complicate the life of an attacker significantly. However, there WILL still be buggy programs on the system: even glibc and Xlib were found to have buffer overflows and format bugs in some versions. Security through obscurity is never a good policy, and only serves to provide a false sense of well-being. However, leaving a system with few programs that provide no other functionality than intended will bolster our efforts in hardening the system for public usage.
Of course, there are some other issues that must be taken into account while deploying such a system on a large scale. Physical security will have to be addressed to prevent the machine from being booted off floppy, CDROM, external hard drive or from it being stolen. Linux (especially in such vanilla setup) offers the advantage of being is stable enough to not require reboots. It is also nice to have reset button that is not accessible to the user.
An Implementation Proposal
Once the design decisions have been made, all that is left to the system developers is to implement the design. There are essentially five steps in the implementation process. They are as follows:
1) First, the network developer should install RedHat Linux on the system hardware according to standard installation procedures. This step should utilize the Custom or Workstation mode, although in the latter case the installation will need to be drastically altered later by manually removing about 300 RPM packages. While it's possible to do this via scripts, it still requires some element of administrative interaction.
If using custom install mode, the developer need only check base-system, networked workstation, mail/www services and X-related packages. Even in this case, some rpm-killing will need to take place.
During the installation process, the partitioning issue must be addressed. It will be necessary to have atleast /,/home,/var and /tmp (and swap, of course) partitions. Here is the example scheme if using the 3 GB drive (which is all that will be required):
Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda1 1571528 184184 1307512 12% / /dev/hda7 300603 309 284773 0% /home /dev/hda6 300603 20 285062 0% /tmp /dev/hda5 809556 4640 763792 1% /var
Separate /tmp, /home and /var partitions are absolutely essential for security reasons since they will have restricted rights for file execution.
Another topic that should be addressed is redundancy. To provide maximum reliability and performance, having redundancy within the system such as mirrored drives and other assets should also be a consideration.
2. Now the installer should ruthlessly remove (by rpm -e packagename command) all the RPMs that are not needed. (See How-To's in 'related links' at the end of this article for the example list and some considerations.) A partial list for the candidates for removal include:
MAKEDEV-2.5.2-1 SysVinit-2.78-5 X11R6-contrib-3.3.2-11 XFree86-100dpi-fonts-3.3.6-20 XFree86-3.3.6-20 XFree86-75dpi-fonts-3.3.6-20 XFree86-S3-3.3.6-20 XFree86-SVGA-3.3.6-20 XFree86-VGA16-3.3.6-20 XFree86-libs-3.3.6-20 XFree86-xfs-3.3.6-20 Xconfigurator-4.3.5-1 apmd-3.0final-2 ash-0.2-20 at-3.1.7-14 audiofile-0.1.9-3 authconfig-3.0.3-1 basesystem-6.0-4 bash-1.14.7-22 bc-1.05a-5 bdflush-1.5-11 binutils-2.9.5.0.22-6 bzip2-0.9.5d-2 chkconfig-1.1.2-1 chkfontpath-1.7-2 console-tools-19990829-10 cracklib-2.7-5 cracklib-dicts-2.7-5 crontabs-1.7-7 dev-2.7.18-3 diffutils-2.7-17 e2fsprogs-1.18-5 ed-0.2-13 eject-2.0.2-4 etcskel-2.3-1 file-3.28-2 filesystem-1.3.5-1 fileutils-4.0-21 findutils-4.1-34 freetype-1.3.1-5 gawk-3.0.4-2 gd-1.3-6 gdbm-1.8.0-3 getty_ps-2.0.7j-9 glib-1.2.6-3 glib10-1.0.6-6 glibc-2.1.3-15 gmp-2.0.2-13 gpm-1.18.1-7 grep-2.4-3 groff-1.15-8
This step is also important as great many packages are buggy and might be used by the public terminal users to get elevated privileges. This is only a partial list. A more comprehensive list can be found in the Linux Web Browser Station How-To included in 'Related Links' at the end of this article.)
3. An SSH server should be installed if it is not a part of the RedHat version being installed. RedHat Linux versions 6.2 and previous did not include this as part of their standard installation, although the recent release of RedHat Linux 7.0 contains the OpenSSH server and client.
4. At this point, it is recommended that the person performing the installation make a boot floppy, as he or she will be modifying some of the files that might cause the system to fail at boot stage.
5. The person performing the installation must now modify the appropriate configuration files. This entails the following steps:
a) in /etc/inittab new runlevel used for running the X with Netscape browser must be added. For that we will use the 4-th runlevel. The changes are along the lines of:
id:4:initdefault:
It is also recommended to disable the Ctrl-Alt-Del combination and restrict the number of gettys to 1 by having all but
1:2345:respawn:/sbin/mingetty tty1
commented out.
b) In /etc/fstab, the execution and file creation rights should be restricted by having the nodev,noexec,nosuid flags set on /home, /tmp and /var partitions. Those specifications will prevent the creation of device files, set-user-id files and the execution of any files from those partitions respectively . If noexec is set, than nosuid is redundant; however, it should be set anyway, if only for the sake of clarity. / partitions will be mounted readonly.
The sample /etc/inittab looks like: /dev/hda1 / ext2 defaults,ro 1 1 /dev/hda7 /home ext2 defaults,nodev,noexec,nosuid 1 2 /dev/hda6 /tmp ext2 defaults,nodev,noexec,nosuid 1 2 /dev/hda5 /var ext2 defaults,nodev,noexec,nosuid 1 2 none /proc proc defaults 0 0 none /dev/pts devpts gid=5,mode=620 0 0 /dev/hda8 swap swap defaults 0 0
There are no floppy and CDROM drives defined here as they will be removed after the set-up is finished.
c. It is now necessary to create the main script that will run the browser and X Window system. The installer should go to /etc/rc.d/init.d directory and create the main xbrowser script. Its main function will be to invoke X Window system as user root in a loop so that if X server is killed it is immediately restarted (That is by itself is a minor point of concern)via
/usr/X11R6/bin/xinit /root/.xinitrc -- /usr/X11R6/bin/X bc
The system will enter X Windows upon reboot without any password prompts. The xbrowser file will also be used to clean stale Netscape lock file and print a message to the system log that X server is restarted via logger command.
d) Let's now turn to /root/.xinitrc. The main line here is
su netscape -c "netscape -no-about-splash -geometry 1024x768+0+0"
Before that it will be necessary to use the "xhost +thisboxname" command to allow the access to root X server by the non-root Netscape (Netscape runs as a special user with less privileges).
e) The installer should next create the user and then configure Netscape with restricted privileges. He or she should then disable Java (which is known to have big risks, including big holes recently discovered in Netscape Java implementation), JavaScript (which has some risks with associated with password stealing and web mail hijacking), page caching (some Java bugs will access cache objects and then bypass JVM restrictions), cookies, and all launches of non-standard applications (ideally-all applications) with file types (by going to Netscape->Edit->Preferences->Navigator->Applications). It is also vital to set history length set to 0, so that the next user on the public access terminal can't see what previous user was doing - an especial risk lies in the possibility of seeing URL-encoded passwords.
The administrator or installer can safely chown the new Netscape user home directory to root so that the user cannot write to it.
f) It is now necessary to configure lilo, the Linux boot loader, so that it doesn't allow anybody to change run levels. This is accomplished by having the line "restricted" in /etc/lilo.conf.
g) The installer or administrator should remember to deactivate the Magic SysRQ keys that allow sending commands directly to the kernel by modifying /etc/sysctl.conf to have kernel.sysrq = 0. These keys are disabled by default, but it is always wise to check.
h) The last step of the implementation process will be the removal of some of the "nastier" binaries like xterm and rxvt that can simplify an attacker's life. The brutal
/bin/rm /usr/X11R6/bin/xterm
will take care of that.
Conclusion
To complete the picture, some nice remote log management system and host-based IDS (like Tripwire or any of its open clones) should be deployed.
Anton Chuvakin is a last-year graduate student at SUNY Stony Brook. Upon completing his PhD he intends to pursue a career in information security. Linux is one of his hobbies.
|