Access the Web Anywhere
What if on every corner, where you now see a pay phone, you could see an inconspicuous terminal for Web access. Feel like checking your e-mail? Just stop at a gas station and do it while filling up. Need to look at movie schedule? Pull over and look up the nearest movie theater web page. Cool, eh? Can you think about a couple of thousand other ways to use Internet access from anywhere you happen to be?
Linux is an ideal candidate to make this scenario not only possible but cheap, too. For under $200, one can setup an inexpensive box that runs Linux and allows only web access. The maintainence cost of such a machine will be low, especially if booting off the CD-ROM drive is used and reliable remote administrations tools are deployed.
The setup of such a system presents a serious challenge. The Internet terminal should be easy to use, stable, easy to maintain (ideally, no maintainence should ever be required) and secure (both to prevent break-ins and the potential to attack other systems). In all described criteria, Linux possesses definite advantages over Windows, which can hardly be made secured enough and is never stable.
Another important requirement is the ease of implementation. For instance, use of a specially modified kernel that prevents the execution of processes other than those specified might sound like a secure solution, but the efforts are probably not justified in this case. The idea is to apply the minimum set of changes to the stock Red Hat distribution and to obtain a secure solution that can be deployed in some public place, like a shopping mall or gas station, without much hassle.
Previous solutions either propose a keyboardless setup suitable for information kiosks, but is not sufficient for the full Internet/webmail access, or they employ outdated software. Securing the system that has a keyboard presents a challenge, however; even a trackball might be sufficient for a determined attacker to cause great damage (think "cut and paste").
The following list outlines some of the technical decisions made when designing the system:
Reduce the installed software list to the absolute bare minimum; the RPM list of a default Red Hat install should be seriously cleaned up. Many of the software packages deployed by default are buggy and can lead to local and sometimes even remote root exploits. If it is not absolutely required for web browsing functionality, then we should remove it.
Simplified X Window System setup: most notably, the absence of a Window manager like GNOME, KDE or fvwm. This removes the potentially less stable (less stable than XFree itself) software and simplifies the securing of the system.
Many minor but still important functions, such as Magic SysRQ keys and LILO boot loader configuration, should be taken care of as well.
Use ssh as a remote administration tool to allow easy upgrades (unless the system is booted off a CD-ROM) and monitoring. No other remote services should be running. Since firewalling the system will not be practical, it will have to rely upon its own defenses.
Some of the executable files that are installed as part of the packages we have to keep (like XFree) also have to be removed. That mostly concerns xterm and rxvt terminal emulators. Their absence will complicate the life of an attacker significantly. However, there WILL be buggy programs on the box: even glibc and Xlib were found to have buffer overflows and format bugs in some versions.
Of course, some other issues surround the deployment of such a system on a large scale. Physical security will have to be addressed to prevent the machine from being carted off or the floppy, CD-ROM or external hard drive from being stolen. It is also nice to have reset button inaccessible to the user. Linux (especially in such vanilla setups) is stable enough to not require reboots.
Let's outline the steps of creation for such a system. (For a full description, see the HOWTO.)
1. First you should install Red Hat Linux on your hardware according to "directions on the package". Use Custom or Workstation mode, although in the latter case you will seriously mess up the install later by manually removing about 300 RPM packages. If using Custom install mode, only select base-system, networked workstation, mail/WWW services and X-related packages. Even in this case you will have to do some RPM-killing.
You will face the partitioning issue during the installation. You must have at least /,/home,/var and /tmp (and swap, of course) partitions. Here is the example scheme if using the 3 GB drive (you don't need more than that):
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 as they will have restricted rights for file execution.
2. Now you should ruthlessly remove (with the rpm -e packagename command) all the RPMs that are not needed. See the HOWTO for the example list and some considerations. This step is also important as many packages are buggy and might be used to get elevated privileges by the user.
3. Now install ssh server. (It is not part of Red Hat 6.x, but I think it was included in Red Hat 7.0.)
4. At this point, making a boot floppy is a good idea since we will be modifying some of the files that might cause the system to fail at boot stage.
5. Now we modify the appropriate configuration files.
In /etc/inittab we add a new runlevel used for X with Netscape browser. For that we will use the 4th runlevel. The changes are along the lines of id:4:initdefault:. Here, we will also disable the Ctrl-Alt-Del combination and restrict the number of gettys to one by having all but 1:2345:respawn:/sbin/mingetty tty1 commented out.
In /etc/fstab we will restrict the execution and file creation rights by having the nodev, noexec , nosuid flags set on /home, /tmp and /var partitions. Those will prevent the creation of device files, set-user-id files and the execution of any files from those partitions, respectively . Now the careful reader will notice that if noexec is set, than nosuid is redundant, but we will set it 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 CD-ROM drives defined here, as they will be removed after the setup is finished.
Now we create the main script that will run the browser and X. Let's go (or should I say, "lets cd"?) to /etc/rc.d/init.d directory and create the main xbrowser script. Its main function will be to invoke X as user root in a loop so that if X server is killed, it is immediately restarted via /usr/X11R6/bin/xinit /root/.xinitrc -- /usr/X11R6/bin/X bc. The system will then enter X upon reboot without any password prompts. The xbrowser file will also be used to clean stale Netscape lock files, and print a message to the system log that X has been restarted via the logger command.
Let's turn to /root/.xinitrc. The main line here is su netscape -c "netscape -no-about-splash -geometry 1024x768+0+0". Before that we will have 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).
Now we are ready to configure LILO, the Linux boot loader, so that it doesn't allow anybody to change run levels. It is achieved by having the line "restricted" in /etc/lilo.conf.
Remember to deactivate the Magic SysRQ keys that allow commands to be sent directly to the kernel by modifying /etc/sysctl.conf to have kernel.sysrq = 0. By default these keys are disabled but it is always wise to check.
The last step will be the removal of some of the "nastier" binaries like xterm and rxvt that can simplify the attackers life. The brutal /bin/rm /usr/X11R6/bin/xterm will take care of that.
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.
If you need more technical information, read the the HOWTO itself. In the References section, you can find links to other sites, including where you can buy some similar systems.
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. He is also the author of 2 Linux HOWTOs:
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development