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:
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide