Email Brian
Brian's Website
Email Tom
Tom's Website
|
Email Brian Brian's Website |
|
Email Tom Tom's Website |
Did you read the Preface? Thanks!
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.
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.
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 http://www.tuxedo.org/~esr/jargon/).
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.
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.
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.
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.
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.
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.
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:
Tip
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.
Warning
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).
Hint
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, <[email protected]>
# #
# # Modified for Debian Linux by Ian A. Murdock <[email protected]>
# #
# # Modified for RHS Linux by Marc Ewing <[email protected]>
# #
# # Further modified by Olaf Kirch <[email protected]> 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: Xserv.ws.cpp,v 1.3 93/09/28 14:30:30 gildea Exp $
# $Id: Xserv.ws.cpp,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
# [email protected]
# 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 <[email protected]>
##
* * *
## Example Permissions
##
## # All operations allowed except those specifically forbidden
## DEFAULT ACCEPT
##
## #Reject connections from hosts not on subnet 130.191.0.0
## # or Engineering pc's
REJECT SERVICE=X NOT REMOTEIP=192.168.0.0/255.255.0.0
## 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 http://www.kernel.org 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 www.kernel.org 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 (http://www.calderasystems.com/support/security/), shown in Figure 21-2.
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.
-----BEGIN PGP SIGNED MESSAGE-----
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
LPRng-3.5.3-3
OpenLinux eServer 2.3 All packages previous to
and OpenLinux eBuilder LPRng-3.5.3-3
OpenLinux eDesktop 2.4 All packages previous to
LPRng-3.5.3-3
3. Solution
Workaround:
None known. The proper solution is to upgrade to the fixed
packages.
4. OpenLinux Desktop 2.3
4.1 Location of Fixed Packages
The upgrade packages can be found on Caldera's FTP site at:
ftp://ftp.calderasystems.com/pub/updates/OpenLinux/2.3/current/RPMS/
The corresponding source code package can be found at:
ftp://ftp.calderasystems.com/pub/updates/OpenLinux/2.3/current/SRPMS
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:
ftp://ftp.calderasystems.com/pub/updates/eServer/2.3/current/RPMS/
The corresponding source code package can be found at:
ftp://ftp.calderasystems.com/pub/updates/eServer/2.3/current/SRPMS
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:
ftp://ftp.calderasystems.com/pub/updates/eDesktop/2.4/current/RPMS/
The corresponding source code package can be found at:
ftp://ftp.calderasystems.com/pub/updates/eDesktop/2.4/current/SRPMS
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:
http://www.calderasystems.com/support/security/index.html
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.
______________________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5z26t18sy83A/qfwRAjkWAJsEORYSmrklimqWj43UvZKGaTD+WACfa63O
rF00C5hA+uS3XuNHIRw6v2A=
=kBzt
-----END PGP SIGNATURE-----
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 ftp://ftp.calderasystems.com/, 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.
Hint
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.
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.
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 http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html). 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 http://www.linux-firewall-tools.com/linux/firewall/index.html.
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.
Tip
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.
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