Brian P. Bilbrey
Email Brian
Brian's Website
BTLB Logo Tom Syroid
Email Tom
Tom's Website

Go to the Table Of Contents

Did you read the Preface? Thanks!

21 - Understanding System Security

In This Chapter

Normally, we like to begin a topic by telling you what works, then pointing out the thorny issues and the thin ice. Truth be told, there is no real security. You could unlink and unplug your computer, lock it in a bank vault, and post security guards around the vault. Do you trust the guards?

But seriously, there are solutions - both hardware and software based - to connect your computer to a local network and to the Internet in a reasonably safe manner. However, what works today might not suffice next year or even next week, and you'll need to find a different solution, or upgrade your current setup. There is no such thing as a permanent security fix or patch. Computer security is a process. When it fails (not if, when), you have to count on backups. Keep three steps ahead of most of the bad guys and you'll be all right, most of the time.

Implementing Security

There are several different types and levels of security. These can be separated into two major groups: physical and network security. We'll address each of these in turn. Our basic goal in this chapter is not to cover every possible aspect of system security - there are 900-page books devoted solely to this topic. Instead, we'd like to instill in you the mindset of a paranoid computer user who thinks about risk management on an ongoing basis; the rest flows naturally once a thirst for knowledge is established. To help you get started, a number of references and links are provided in the following pages that hopefully get you pointed in the right direction.

Hackers, Crackers, and Script Kiddies

Is it the woman in the next cubicle or a couple in the Philippines? Who are the bad guys and what are we calling them this week? These are good questions, so let's get some terms defined (courtesy of the Jargon File at

Hacker: A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary.

Cracker: One who breaks security on a system. Coined ca. 1985 by hackers in defense against journalistic misuse of [the term] hacker.

Script Kiddies: The lowest form of cracker; script kiddies do mischief with scripts and programs written by others, often without understanding the exploit.

In fact, many system security breaches are the Internet age's equivalent of joy riding, with kids of all ages going places and doing things just because they can - these are the script kiddies, ready to do opportunistic harm, but rarely after a specific target. The goals here are to deface Web sites, plant root kits (a suite of Trojan horse programs that gives control of your computer and data to an external individual), or to simply hose your system.

Next, there is the specter of the recent DDoS (Distributed Denial of Service) attacks to consider. In this case, a person or persons unknown break into easily accessible, Internet-connected machines and plant what's called zombie programs, which sit quietly in each system, waiting for a signal to start flooding a specific target site with HTTP requests, TCP/IP packets, or the attack of the week.

There is a much smaller group of actually talented crackers who choose to practice their skills by breaking into computer systems and networks just for the challenge, to learn more, or to get hold of information with resale value.

The truth of the matter is that while all of these external sources are potential problems, internal personnel are the most common perpetrators of computer and data theft. Firewalls don't secure a system against authorized users, which is why we emphasize security at the systems level.

Physical and Local Security

When most people think of security and computers, the first thoughts that typically spring to mind are of viruses and Trojan horses, DDoS attacks, and graffiti-strewn Web pages. However, is your data and your machine safe from a precocious six year old? In the workplace, can you guard against a disgruntled employee or the janitorial staff? Sometimes the answer is no.

In the workplace

Secure data is encrypted and sits on password-protected RAID arrays that are rigorously backed up. The hardware is behind locked doors that open to a limited number of personal passwords, or better yet, biometric data like fingerprints or retinal patterns. In such a scenario, your data is as secure as your IT staff can make it, physically. Of course, users need access to that data across a network, but let's not get ahead of the game.

Lock your computer. Many case designs permit locking the case to the chassis, and the whole thing to a desk. Do that, and the computer won't take a hike out the back door with someone, which happens more frequently than most companies would care to admit. Lock down the hard drives as well as the computer BIOS with non-obvious passwords from the BIOS setup screen at boot time, and don't permit booting from any devices except the system hard disks.

Password-protect your logins, and use locking screensavers with short cycle times, as demonstrated in Figure 21-1. Don't choose a screensaver (like SlideScreen or Random) that uses the underlying desktop as art. Work at remembering to lock your station down (select the padlock icon on the KPanel) before departing the work area. This prevents casual walk-by data theft, when you're not physically present.

Setting up the screensaver for password protection and a quick cycle.

Figure 21-1
Setting up the screensaver for password protection and a quick cycle.

For sensitive data that lives on your hard disk, or on any easily accessible disk, encrypt it. Use PGP or GPG, detailed in Chapter 22. 1,024-bit encryption is considered Good Enough (tm) for most commercial purposes, and a good passphrase is several words in conjunction with numbers and punctuation, not personally related to you, and not written down or shared.

A Good Idea
Actually, it might be a good idea to preserve your passphrases and passwords in an encrypted file on a CD-ROM disc. Store the CD-ROM in a safe deposit box, and tell three trusted friends or family members what the password is for the encrypted file. This protects against permanent data loss due to getting hit by an ice cream truck, or other similar unplanned misfortunes.

Lastly, make backups. If you're working on a project and you trust the backup system set in place by IT, more power to you. We use tape drives to back up our systems and servers, and burn critical data to CD-ROM discs locally as well. In some corporate environments this might be frowned upon, so be sure to CYA with the appropriate authorities. Usually reminding them of the value of your work, and the impact of data loss is enough to turn the trick, but get the approval in writing if you think you need it.

In the home

Home security requirements can be perceived as different from those at work. Do you run accounting software that has all of your bank and credit card information loaded in it? Then if you are burgled, your financial life walks out the door with that unsecured computer. Take as many precautions as possible to protect your investment, just as you do with work data.

There is one major distinction between work and home environments - the normal workplace rarely has to cope with children. Putting systems up out of reach of the little hands is usually sufficient for most purposes.

What's in a Password?

Passwords are the front line of defense against unauthorized computer access. Hands up quick, how many people do you know who have one or more passwords on sticky notes attached to their monitor bezels? Not much security there, nor when people choose passwords based on significant personal information. There's a recent stage play that included something like the following lines:

"Hey, everyone! I got a new girlfriend! Her name is Juliana!"
[whispered] "Oh, great, now everybody knows what his new password is!"

Don't fall into this type of trap. Choose long passwords that are not names or words from any dictionary, native or foreign. We know people who have 1.5 million word pre-compiled password files. Passwords should be long because the permutations become computationally difficult at or above eight characters. One way to select a good password is to take a phrase you can remember, and use the first letter or two from each word, and insert some numbers and punctuation to increase the challenge to a would-be cracker.

Use multiple passwords. If you have an account at Yahoo, or Hotmail or any other Web mail service, use a different password from your system passwords and your cash card PIN. This seems obvious, but needs to be said. We generally have several good passwords that are used for various system accounts, secure Web, personal and root. Then we have just one or two junk passwords that are used in the clear on the Internet. These groups don't intermingle.

Most modern Linux distributions use a feature called shadow passwords by default. This is a very good thing. The standard system password file, /etc/passwd simply must be accessible, as there are many user-controlled programs that need access to the list of accounts on the system. Previously, passwords also lived in this world-readable file, easy to copy and check for simple passwords with such programs as Crack or John the Ripper. By contrast, shadow passwords are kept in a root-only file. The programs that need access to this /etc/shadow run as root, and can read and write the data as necessary - no ordinary user can.

Network Security

Secure data is inaccessible. It's not very useful that way, but it's safe. On the premise that you want to do something with your data, here are a few basic principles that apply to securing any system connected to a network:

Security starts at installation. Whether your system is going to be connected to a private network or directly to the Internet, you need a way to ensure that your box isn't cracked on one side while you board up the other. Start and finish your install with the network unplugged. Take all the security measures that are available to you. Then connect and complete the job by getting updated packages as necessary to enable the services you are planning to provide, safely.

Let's start by securing a clean install of OpenLinux eDesktop 2.4. Once the base operating system is up and running, use the lsof command (a utility to list open files, processes, and resources) and grep the results to isolate the running services and port numbers, as shown in the following listing.

The root user must accomplish virtually all of the activities discussed in this section. Type the commands then confirm they're correct prior to pressing Enter. The alternative is the learning experience of repairing a broken installation, or reinstalling from scratch. We can't help you much with the former, so exercise caution.

[root@gwydion /root]# lsof -n | grep ":"
rpc.portm  599 root    3u  IPv4        342              UDP *:sunrpc 
rpc.portm  599 root    4u  IPv4        343              TCP *:sunrpc (LISTEN)
inetd      605 root    4u  IPv4        348              TCP *:discard (LISTEN)
inetd      605 root    5u  IPv4        349              UDP *:discard 
inetd      605 root    6u  IPv4        350              TCP *:daytime (LISTEN)
inetd      605 root    7u  IPv4        351              UDP *:daytime 
inetd      605 root    8u  IPv4        352              TCP *:time (LISTEN)
inetd      605 root    9u  IPv4        353              UDP *:time 
inetd      605 root   10u  IPv4        354              TCP *:ftp (LISTEN)
inetd      605 root   11u  IPv4        355              TCP *:telnet (LISTEN)
inetd      605 root   12u  IPv4        356              TCP *:shell (LISTEN)
inetd      605 root   13u  IPv4        357              TCP *:login (LISTEN)
inetd      605 root   14u  IPv4        358              TCP *:exec (LISTEN)
inetd      605 root   15u  IPv4        359              UDP *:talk 
inetd      605 root   16u  IPv4        360              UDP *:ntalk 
inetd      605 root   17u  IPv4        361              TCP *:pop2 (LISTEN)
inetd      605 root   18u  IPv4        362              TCP *:pop3 (LISTEN)
inetd      605 root   19u  IPv4        363              TCP *:imap2 (LISTEN)
inetd      605 root   20u  IPv4        364              TCP *:uucp (LISTEN)
inetd      605 root   21u  IPv4        365              TCP *:finger (LISTEN)
inetd      605 root   23u  IPv4        368              TCP *:auth (LISTEN)
inetd      605 root   24u  IPv4        369              TCP *:swat (LISTEN)
amd        634 root    4u  IPv4        405              UDP *:1023 
amd        634 root    5u  IPv4        406              TCP *:811 (LISTEN)
amd        634 root    6u  IPv4        407              UDP *:812 
amd        634 root    7u  IPv4        408              UDP *:1022 
lpd        654 root    4u  IPv4        432              TCP *:printer (LISTEN)
sendmail   684 root    4u  IPv4        458              TCP *:smtp (LISTEN)
rpc.rstat  698 root    3u  IPv4        470              UDP *:876 
calserver  730 root    3u  IPv4        494              TCP *:907 (LISTEN)
keyserver  732 root    3u  IPv4        498              TCP *:908 (LISTEN)
kdm        820 root    4u  IPv4        563              UDP *:xdmcp 
kdm        820 root    5u  IPv4        564              TCP *:1024 (LISTEN)
X          823 root    0u  IPv4        567              TCP *:6000 (LISTEN)
kdm       1141 root    5u  IPv4        564              TCP *:1024 (LISTEN)

Every line displayed from this command is an opening into the system. Now we'll start showing you how to brick in most of those entry points. Observe in the first column that a large number of processes are being run and monitored by the inetd service, so let's start there.

The good news is that none of the worst offenders (the remote commands like rlogin) are enabled by default, but there are too many unnecessary services running. Our goal for the inetd superserver is to start and monitor just one service: identd, which implements a user identification protocol that identifies your machine properly when requested. This is an innocuous service that has not had serious security problems associated with it. Also, identd is usually necessary if you're planning on connecting to IRC (Internet Relay Chat).

If you don't need identd either, then don't run that service either. Anytime you can plug a hole in your system, it's a good thing.

Everything else gets shut off by commenting it out of the file /etc/inetd.conf. Commenting a command out of a script or configuration file is fairly easy, just add a hash mark (#) to the front of the line. When there are many lines, this is a pain, but most text editors have global search and replace tools that make this chore relatively simple. In the listing that follows, we make a backup copy of the file, then use sed (the Stream Editor) to add a "# " to every line except the one containing auth (which is the identd service line).

[root@gwydion /etc]# cp inetd.conf inetd.conf.old

[root@gwydion /etc]# sed '/auth/!s/^/# /' inetd.conf.old > inetd.conf

[root@gwydion /etc]# cat inetd.conf
# #
# # inetd.conf	This file describes the services that will be available
# #		through the INETD TCP/IP super server.  To re-configure
# #		the running INETD process, edit this file, then send the
# #		INETD process a SIGHUP signal.
# #
# # Version:	@(#)/etc/inetd.conf	3.10	05/27/93
# #
# # Authors:	Original taken from BSD UNIX 4.3/TAHOE.
# #		Fred N. van Kempen, <>
# #
# # Modified for Debian Linux by Ian A. Murdock <>
# #
# # Modified for RHS Linux by Marc Ewing <>
# #
# # Further modified by Olaf Kirch <> for Caldera Open Linux
# #
# # <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
# #
# # Echo, discard, daytime, and chargen are used primarily for testing.
# #
# # To re-read this file after changes, just do a 'killall -HUP inetd'
# #
# # Note: builtin UDP services now silently drop packets from ports < 512.
# #echo	stream	tcp	nowait	root	internal
# #echo	dgram	udp	wait	root	internal
# discard	stream	tcp	nowait	root	internal
# discard dgram	udp	wait	root	internal
# daytime	stream	tcp	nowait	root	internal
# daytime dgram	udp	wait	root	internal
# #chargen stream	tcp	nowait	root	internal
# #chargen dgram	udp	wait	root	internal
# time	stream	tcp	nowait	root	internal
# time	dgram	udp	wait	root	internal
# #
# # These are standard services.
# #
# ftp     stream  tcp     nowait  root    /usr/sbin/tcpd in.ftpd -l -a
# telnet  stream  tcp     nowait  root    /usr/sbin/tcpd in.telnetd
# #
# # Mail and news
# #
# # Do not uncomment either unless you *really* know what you are doing.
# # Both are started as standalone daemons from the /etc/rc.d scripts.
# #smtp	stream  tcp 	nowait  root    /usr/bin/smtpd	smtpd
# #nntp	stream	tcp	nowait	root	/usr/sbin/tcpd	in.nntpd
# #
# # Shell, login, exec and talk are BSD protocols.
# #
# shell   stream  tcp     nowait  root    /usr/sbin/tcpd in.rshd
# login   stream  tcp     nowait  root    /usr/sbin/tcpd in.rlogind
# exec    stream  tcp     nowait  root    /usr/sbin/tcpd in.rexecd
# talk    dgram   udp     wait    nobody.tty /usr/sbin/tcpd in.talkd
# ntalk   dgram   udp     wait    nobody.tty /usr/sbin/tcpd in.ntalkd
# #dtalk	stream	tcp	wait	nobody.tty	/usr/sbin/tcpd	in.dtalkd
# #
# # Pop and imap mail services et al
# #
# pop2    stream  tcp     nowait  root    /usr/sbin/tcpd ipop2d
# pop3    stream  tcp     nowait  root    /usr/sbin/tcpd ipop3d
# imap    stream  tcp     nowait  root    /usr/sbin/tcpd imapd
# #
# # The Internet UUCP service.
# #
# uucp	stream	tcp	nowait	uucp	/usr/sbin/tcpd	/usr/sbin/uucico -l
# #
# # Tftp service is provided primarily for booting.  Most sites
# # run this only on machines acting as "boot servers." Do not uncomment
# # this unless you *need* it.  
# #
# #tftp	dgram	udp	wait	root	/usr/sbin/tcpd	in.tftpd
# #bootps	dgram	udp	wait	root	/usr/sbin/tcpd	bootpd
# #
# #  This is for the finger service
# # 
# finger  stream  tcp     nowait  nobody  /usr/sbin/tcpd in.fingerd -u
#/var/run/.ppp_socket stream unix nowait root /usr/sbin/ppp-envoy ppp-envoy -da
# #
# # Finger, systat and netstat give out user information which may be
# # valuable to potential "system crackers."  Many sites choose to disable 
# # some or all of these services to improve security.
# #
# #systat	stream	tcp	nowait	nobody	/usr/sbin/tcpd	/bin/ps	-auwwx
# #netstat stream	tcp	nowait	nobody	/usr/sbin/tcpd	/bin/netstat --inet
# #
# # Authentication
# #
auth    stream  tcp     nowait  root    /usr/sbin/in.identd in.identd
# swat    stream  tcp     nowait.400 root    /usr/sbin/tcpd swat
# #
# # End of inetd.conf

[root@gwydion /etc]# /etc/rc.d/init.d/inetd restart

In the resulting /etc/inetd.conf file, you can see that most lines have two hash marks. These were either pre-existing comments, or services that were disabled by default by Caldera. The items with only one hash mark are all previously enabled services that are now disabled. Well, ready to be disabled - that's accomplished by the closing command in the above listing - it restarts the inetd server, which forces a re-read of the configuration file. One set of holes stopped up... there are more windows and doors to board up, though.

Next, as we first discussed at the end of Chapter 3, use COAS to disable many of the services that are not monitored by the inetd TCP superserver. Select K --> Settings --> COAS --> System --> Daemons. From the resulting System Services dialog box, we begin by disabling everything except Print server (LPD), Network devices, Basic IP service dispatcher, System loggers, and Cron daemon. Functionally, we've disabled NFS, NIS, Samba, the Apache Web server, and more.

Another area we need to immediately address is the section at the very bottom of the lsof listing: the kdm and X lines. These are present as network services to provide remote access to the KDE desktop and to the underlying X server. We regard this as bad behavior, to be banished. This is accomplished in two steps. First we'll edit the file /etc/X11/kdm/xdm-config, and add a line to prevent kdm from presenting itself to the world, then we'll do the same thing for X in the file /etc/X11/kdm/Xservers. Each file listing shows the changes in bold. (A horizontal ellipsis "* * *" indicates material removed to save space.)

[root@gwydion /etc]# cd /etc/X11/kdm

[root@gwydion kdm]# cp xdm-config xdm-config.old

[root@gwydion kdm]# vim xdm-config
  * * *

[root@gwydion kdm]# cat xdm-config
! $XConsortium: xdm-conf.cpp,v 1.2 93/09/28 14:30:32 gildea Exp $
! $Id: xdm-conf.cpp,v 1.3 1998/09/30 21:20:31 bieker Exp $
DisplayManager.requestPort:	none
DisplayManager.errorLogFile:	/etc/X11/kdm/xdm-errors
DisplayManager.pidFile:		/etc/X11/kdm/xdm-pid
DisplayManager.keyFile:		/etc/X11/kdm/xdm-keys
DisplayManager.servers:		/etc/X11/kdm/Xservers
DisplayManager.accessFile:	/etc/X11/kdm/Xaccess
DisplayManager._0.authorize:	true
DisplayManager._0.setup:	/etc/X11/kdm/Xsetup_0
DisplayManager._0.startup:	/etc/X11/kdm/Xstartup
DisplayManager._0.reset:	/etc/X11/kdm/Xreset
DisplayManager*resources:	/etc/X11/kdm/Xresources
DisplayManager*session:		/etc/X11/kdm/Xsession
DisplayManager*authComplain:	false

[root@gwydion kdm]# cp Xservers Xservers.old

[root@gwydion kdm]# vim Xservers
  * * *

[root@gwydion kdm]# cat Xservers
# $XConsortium:,v 1.3 93/09/28 14:30:30 gildea Exp $
# $Id:,v 1.2 1998/09/30 21:20:28 bieker Exp $
# Xservers file, workstation prototype
# This file should contain an entry to start the server on the
# local display; if you have more than one display (not screen),
# you can add entries to the list (one per line).  If you also
# have some X terminals connected which do not support XDMCP,
# you can add them here as well.  Each X terminal line should
# look like:
#       XTerminalName:0 foreign
:0 local /usr/X11R6/bin/X :0 -nolisten tcp vt08

The change to the Xservers file is just an addition to the existing line. Taken together with the transformed xdm-config, these two changes take the kdm and X processes off the networked process list. Finally, if there's a printer connected, then we want to restrict access to it. This is done by modifying the /etc/lpd.perms file. This is a bit longer, and our activity here is to uncomment a bit of sample permissions and alter it to meet our needs. The listing below is just an excerpt of a much larger file.

[root@gwydion /etc]# 

cp lpd.perms lpd.perms.old

[root@gwydion /etc]#

vim lpd.perms

[root@gwydion /etc]#

cat lpd.perms

########################################################################### # LPRng - An Extended Print Spooler System # # Copyright 1988-1995 Patrick Powell, San Diego, CA # # See LICENSE for conditions of use. # ########################################################################### # MODULE: TESTSUPPORT/lpd.perms.proto # PURPOSE: prototype printer permissions file # lpd.perms,v 3.7 1998/03/24 02:43:22 papowell Exp ########################################################################## # Printer permissions data base ## # ## LPRng - An Enhanced Printer Spooler ## lpd.perms file ## Patrick Powell <> ## * * * ## Example Permissions ## ## # All operations allowed except those specifically forbidden ## DEFAULT ACCEPT ## ## #Reject connections from hosts not on subnet ## # or Engineering pc's REJECT SERVICE=X NOT REMOTEIP= ## REJECT SERVICE=X NOT REMOTEHOST=engpc* ## * * *

The amendment of /etc/lpd.perms involves uncommenting the bolded "REJECT SERVICE..." line, and modifying the IP address range to match our local network, preventing external machines from accessing the service. If there's just your machine, then you can always put your IP address alone on that line. Now we're just about done.

Close all your running programs, then from the command line, as root, type telinit 1. This performs a reset down to runlevel 1 (maintenance mode). The KDE desktop closes, X stops, and you are treated to a console screen full of the expected service shutdown messages. When they are done, you are presented with a choice:

Give root password for maintenance
(or type Control-D for normal startup):

Type Ctrl + D, which completes the reset and restarts all of the system and network services anew. Effectively, this is a reboot without power cycling or warm booting the system. It's much faster than a full reboot, and can be used to reinitialize the system after just about anything except adding a new kernel. (The current party line is that rebooting is for hardware and kernel changes only. Power outages are not discussed.)

Once the machine is back up, login as root, open a terminal window, and revisit the lsof command to double-check your handiwork.

[root@gwydion /root]# lsof -n | grep ":"
inetd     1574 root    4u  IPv4       1612               TCP *:auth (LISTEN)
lpd       1588 root    4u  IPv4       1628               TCP *:printer (LISTEN)

Not a bad job at all. From 35 openings in the castle wall to just two, in four edits and a dialog box. This box can now be connected to a network and brought online (or if you're on dialup, used with Kppp). But don't relax just yet, the work's not over.

Point your browser to and update eDesktop to Linux kernel 2.2.16 or 2.2.17, as discussed in Chapter 7. There are important security feature upgrades and patches incorporated in the latest 2.2 series kernels.

The Latest Info - May, 2001
While the 2.4.x kernel has been out since January 2001, there are a number of packages that need upgrading to make this new version work. However, the 2.2.x series has not lain fallow - the latest version there is 2.2.19, and you can get it from today. There are significant security advantages to upgrading to the 2.2.19 kernel, so get going, already!

Security updates

There are a plethora of resources for keeping track of system vulnerabilities, from news groups to mailing lists to Web sites. Your first stop should always be the Security Advisories page on the Caldera site (, shown in Figure 21-2.

The Caldera Security Advisories Web page shows recent vulnerabilities.

Figure 21-2
The Caldera Security Advisories Web page shows recent vulnerabilities.

On the second line, observe the warning about LPRng, one of the two services we left exposed in the preceding "system lockdown" exercise. The following listing is the full text of this Caldera Security Advisory. Each message describes the bug or vulnerability, the versions of software affected, and where package updates can be found.

Hash: SHA1

                   Caldera Systems, Inc.  Security Advisory

Subject:                format bug in LPRng
Advisory number:        CSSA-2000-033.0
Issue date:             2000 September, 25
Cross reference:

1. Problem Description

   There is a format bug in the LPRng printer daemon that could
   possibly be exploited to obtain root privilege. This problem
   is particulary [CT8]severe because it can be exercised remotely.
   We are not aware of any exploits for this bug yet.

2. Vulnerable Versions

   System                       Package
   OpenLinux Desktop 2.3        All packages previous to

   OpenLinux eServer 2.3        All packages previous to
   and OpenLinux eBuilder       LPRng-3.5.3-3

   OpenLinux eDesktop 2.4       All packages previous to

3. Solution


   None known. The proper solution is to upgrade to the fixed

4. OpenLinux Desktop 2.3

   4.1 Location of Fixed Packages

       The upgrade packages can be found on Caldera's FTP site at:

       The corresponding source code package can be found at:

   4.2 Verification

       3ad5e8e8ab42d2ed1cce0627ca2a0f45  RPMS/LPRng-3.5.3-3.i386.rpm
       61f4d3aef6757c68ba73cc1cc8bbcf27  RPMS/LPRng-doc-3.5.3-3.i386.rpm
       ebd7e8ec09ef4d92397f608b1125ff82  RPMS/LPRng-doc-ps-3.5.3-3.i386.rpm
       c53c9a83c0791030297b6079d7b9fcd9  RPMS/LPRng-lpd-3.5.3-3.i386.rpm
       d266aed344873c9ff6aab2a409d760b4  SRPMS/LPRng-3.5.3-3.src.rpm

   4.3 Installing Fixed Packages

       Upgrade the affected packages with the following commands:

          rpm -Fhv LPRng-*.i386.rpm

       Stop and restart the lpd service using
          /etc/rc.d/init.d/lpd stop
          /etc/rc.d/init.d/lpd start

5. OpenLinux eServer 2.3 and OpenLinux eBuilder for ECential 3.0

   5.1 Location of Fixed Packages

       The upgrade packages can be found on Caldera's FTP site at:
       The corresponding source code package can be found at:

   5.2 Verification

       9cb7089adcadcf29ee2cb8268acc46c1  RPMS/LPRng-3.5.3-3.i386.rpm
       77e9edbf336837a9957c3fc62167aee4  RPMS/LPRng-doc-3.5.3-3.i386.rpm
       558a98c48558538bc15f86ca9a555e68  RPMS/LPRng-doc-ps-3.5.3-3.i386.rpm
       62c39c60197447be1b4de85f81bcd5a0  RPMS/LPRng-lpd-3.5.3-3.i386.rpm
       d266aed344873c9ff6aab2a409d760b4  SRPMS/LPRng-3.5.3-3.src.rpm

   5.3 Installing Fixed Packages

       Upgrade the affected packages with the following commands:

          rpm -Fhv LPRng-*.i386.rpm

       Stop and restart the lpd service using
          /etc/rc.d/init.d/lpd stop
          /etc/rc.d/init.d/lpd start

6. OpenLinux eDesktop 2.4

   6.1 Location of Fixed Packages

       The upgrade packages can be found on Caldera's FTP site at:

       The corresponding source code package can be found at:

   6.2 Verification

       7ec1973e306bbcaa3e27b770b463e6fe  RPMS/LPRng-3.5.3-3.i386.rpm
       f373e0a2389c64e207b84293d2afc177  RPMS/LPRng-doc-3.5.3-3.i386.rpm
       4560b0415dc7dbf7bde284173a49c6f6  RPMS/LPRng-doc-ps-3.5.3-3.i386.rpm
       994f2204ba1e743725fe69cecb47dac5  RPMS/LPRng-lpd-3.5.3-3.i386.rpm
       d266aed344873c9ff6aab2a409d760b4  SRPMS/LPRng-3.5.3-3.src.rpm

   6.3 Installing Fixed Packages

       Upgrade the affected packages with the following commands:

          rpm -Fhv LPRng-*.i386.rpm

       Stop and restart the lpd service using
          /etc/rc.d/init.d/lpd stop
          /etc/rc.d/init.d/lpd start

7. References

   This and other Caldera security resources are located at:
   This security fix closes Caldera's internal Problem Report 7877.

8. Disclaimer

   Caldera Systems, Inc. is not responsible for the misuse of any of the
   information we provide on this website and/or through our security
   advisories. Our advisories are a service to our customers intended to
   promote secure installation and use of Caldera OpenLinux.

9. Acknowledgements

   Caldera Systems wishes to thank Chris Evans for finding and
   reporting this bug.

Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see


Each section of a Caldera Security Advisory has a specific purpose. An important feature to note is that the entire document is a downloadable text file that is PGP/GPG signed (see Chapter 22 for more on these utilities). After checking this signature, you can be sure that the MD5 sums given for the updated software packages are correct. Why is this important? Suppose someone broke into the Caldera FTP server and put up a modified version of a key system RPM file. This allows you to confirm that the package is in the same condition it was when it left the engineer's workstation inside the labs at Caldera.

In every Advisory, the problem or vulnerability is described, the affected distributions are listed, and the updated packages are shown for each version. Also included are instructions for checking the updates and installing them, including restarting affected services so that they incorporate the changed code or configuration.

In the case of the listed Security Advisory above, there is a problem with LPRng, so it's time to get and install an update. Using FTP or a browser, log into, navigate to the correct directory, and download all of the LPRng RPM files. Check the MD5 sums and install the new packages using the options shown ("-F" means to freshen, updating only installed packages, "vh" displays the installation progress hash marks), then stop and start the daemon. Finally, after upgrading a package, it's always good policy to check the associated configuration file, especially if you've previously edited the file for security - package upgrades have been known to overwrite an existing configuration and return it to default settings. In the previous example, upgrading the LPRng daemon does not modify the security changes we made to the lpr.perms file.

Now we return to the Security Alerts page, and go down the list, from the current date back to a time two months before our current version (eDesktop 2.4, in this case) was released. That pretty much covers the bases. Reading each advisory, we can decide whether or not it applies to us, and apply the requisite updates as necessary.

Because Caldera counsels installing security update RPMS with the freshen (-F) option, it's generally advisable to install all of the security updates for your system. If you don't have a specific package installed, then an update is unnecessary, so RPM doesn't do the install. There is one drawback. You might not want to upgrade specific packages. In that case, it's best to review the RPMS prior to updating.

For example, many advisories are providing notification of vulnerable programs that a malicious user can exploit. As the sole user of a system, you can gloss over many such warnings. As a system administrator running a server, you must heed those warnings. We generally try to behave as a sysadmin would; it's safer. The best advice we can offer is this: If you see a Security Advisory for a package, and you use the software, package, or service, then get and install the updates. If you don't use it, then use RPM to remove the vulnerable package from your system.

Securing Servers versus Workstations

In the world of Microsoft Windows, the line of demarcation between workstation and server is fairly clear (quibbles about Internet Connection Sharing with Windows 98 aside). But the true difference between an OpenLinux workstation and an OpenLinux server is the installed software.

The rules for securing a server box are much more stringent than for battening down the hatches on a workstation. As far as services go, we strongly recommend that you play by server rules everywhere. If you aren't going to be Web serving, then remove the Apache packages, and so on.

By following the strictest security procedures that you are willing to accept, you make your box much less likely to be broken into, used as a pawn in a DDoS attack, or wiped out by an unauthorized visitor.

Using Firewalls

A firewall is a specific implementation of a security policy. If the policy is fuzzy, then the implementation is also likely to be incomplete. There are two basic reasons to firewall a machine or a network (thanks to Mark Grennan and the Firewall and Proxy Server HOWTO at The first is more commonly thought of - to keep people out (crackers, script kiddies, and the competition). The second, which is coming more into play in recent years, is to keep people in (employees or children).

Additionally, there are two different styles of firewalls to consider. One protects only the machine it lives on, and is often referred to as a personal firewall. The second provides protection for an entire network, firewalling the LAN from the Internet. Both methods use IPChains, which is a tool that was introduced with the 2.2 series of Linux kernels. This utility allows the administrator to define rules for what traffic, from which addresses, on which ports, are allowed. IPChains is a simple tool that requires a bit of study , but can easily build up complex sets of rules for protecting a system or a network.

Use the above URL as a good starting point for more information, along with the book Linux Firewalls by Robert Ziegler (New Riders Publishing). Additionally, he has an automated script-building site at

We use hand-modified versions of the basic script that's generated by the Q&A session from Ziegler's site. Why not show it to you? Well, each location is fairly custom, and a basic script runs better than 600 lines - over 10 pages worth. We figure you can get a copy personalized for your own system and study that. The output scripts are sprinkled with comments to make clear the activity that's being permitted or blocked in each section. If we were to show part of our scripts, some readers might take them as a complete solution.

The Latest & Greatest
IPChains functionality has been rewritten and upgraded for the soon-to-be-released Linux 2.4 kernel. The new tool is called IPTables. It is designed to be both more secure and easier to use. When and if you upgrade your system to a 2.4 kernel, you'll need to learn about the Netfilter project (aka IPTables) and upgrade your security as well. While the documentation of an evolving beta product is often spotty or non-existent, there is a HOWTO for IPTables. Look for changes and updates on a regular basis. Additionally, a firewall box may perform the functions of a router using a form of Network Address Translation (NAT) called IP Masquerading. IP Masquerading translates requests from the non-routable internal addresses, coordinates traffic between external and internal machines, and is set up in IPChains. Configured as a firewall to prevent unwanted connections, a Linux box is a powerful solution for many common private and corporate network requirements.

The fundamental premise of a good firewall design is to block everything, selectively open only those ports that are necessary for operation, and then protect those open ports. Keep that principle in mind and you'll have a successful installation.

We like the belt-and-suspenders approach to firewalling a network. Presuming a DSL or cable modem, use a single or multi-port firewall/router designed for the purpose. These are available from LinkSys, D-Link, and other vendors. Then, between the router and the network, park a single-purpose Linux box that translates to a second IP subnet, to provide a second-tier firewall. People breaking in through the first layer of defenses are faced with a different and potentially far more formidable layer to cope with.

Evaluating Your Security Systems

When all is said and done, you have to find and plug all the holes in your system. The bad guys only have to find one. You know whom the odds favor. So prepare against the day when your defenses fail. If they never do, then you're still covered against floods, fires, and any other acts of nature. Make backups of key data then test the backups for integrity. If you have servers with sensitive data on them, write firewall rules that prevent any data from those machines from being routed out to the Internet. They aren't workstations and don't need external access.

The following message bears repeating: Using computer resources involves compromising security. Usually, ease of use and security are diametrically opposed goals. If a resource is too hard to use, then one of two results is certain: either the users (including you) will circumvent the protections, or the resource remains untouched and useless. Each step of the way, you should think about the compromises between security and functionality, and make a conscious decision. Or leave yourself open to attacks. It's your call. The advantage that Linux offers is that you can control the system and the software that protects you, instead of counting solely on the mostly proprietary solutions that are available for other systems.

Once you've secured your computer or network, you can start to look at providing services. Do you need to run a Web server, a mail server, or something else? Study each service, the available alternatives, and the security alerts for the packages in question. Install the software, incorporating it into your security plan. Make sure to add the package to your list of monitored items for security purposes.

All of this sounds like a lot of work. Actually, it is, at first. However, once things are set up right, they just keep working. Monitor your system, keep an eye on the security sites and update lists, and enjoy a level of computing that is far safer than that practiced by 99 percent of all computer users today.

Early in this chapter, we mentioned several security utilities (PortSentry, Tripwire, and Aide), which provide added levels of protection for a system connected to a network, private or public. These are the topic of Chapter 22, along with other security and privacy related software like PGP, GPG, and SSH. So stay tuned.


The art of securing computer systems, including Linux, is a dance of compromise. Fully secure data is inaccessible and unusable. Easy-to-access data is often insecure. The happy medium lies somewhere between these two points, based upon your requirements and the sensitivity of the data in question. This chapter covered the following points:

Go to the Table Of Contents

Licenced under the Open Content License ver. 1

All Content Copyright © 2001 - Brian P. Bilbrey & Tom Syroid All Rights Reserved.