Email Tom
Tom's Website
Email Brian
Brian's Website
|
Email Tom Tom's Website |
|
Email Brian Brian's Website |
Did you read the Preface? Thanks!
An Author's Note
Well, you'll note that the In This Chapter bit, just above, is full of one-word section titles, corresponding to the program names. Our editors insisted upon having phrases there, in place of something brief and useful, leading to such wonders as "Implementing effective detection with Tripwire" and my least favorite, "Graduating to OpenSSH". Huh?!? I've tried to eradicate some of the twaddle from this chapter, but if the names don't always coincide ... sorry! [bpb]
Continuing forward from Chapter 21, there several additional programs that can be employed to significantly enhance your system's security. They include PortSentry, which monitors network ports not in use and does its best to lock out any unauthorized users. We also look at Tripwire and its Open Source competition, AIDE; both are file integrity checkers commonly configured as intrusion detection systems. These tools are best installed before your system is connected to a network.
On the privacy front, there are a variety of options, with competing commercial and Open Source software at every step. First, we'll look at GnuPG (a version is installed with eDesktop), and the commercial alternative, PGP. These are compatible public key based encryption packages which tie into several e-mail utilities, as well as providing a host of other personal and system privacy features. Finally, there's SSH (for Secure Shell) and its GPL competition, OpenSSH. Both products provide secure, encrypted network communications.
We do not have the time, space, or resources to provide a comprehensive survey of the various third-party security and privacy packages that can be installed with OpenLinux. Look online for the best resources, as this is one of the fastest evolving fields in computing with Darwinian selection happening on a daily basis. Keep an eye on http://www.securityportal.com/, http://linuxsecurity.com/, and http://www.securityfocus.com/, among others. Now let's have a look at some security software.
Many network-based attacks begin with a scan of the TCP and UDP ports on target systems to determine which are open and vulnerable to attack. Well-known and readily available programs like Nmap (a dedicated port scanner) are easily applied to the task of finding open holes in a system or network.
Note
TCP (Transmission Control Protocol) is the primary method for creating connections between host machines on Internet Protocol links. There is a system maximum of 65,535 TCP ports in Linux on the x86 architecture. Additionally, there is a parallel set of for User Datagram Protocol (UDP) ports. UDP ports and connections are applied to a variety of temporary uses, from FTP to various instant-messaging services.
PortSentry is a configurable utility to detect and block unauthorized entry into your computer via a network connection. It is part of the Abacus suite of system security products available from Psionic Software (http://www.psionic.com/abacus/).
Initially written by Craig Rowland, PortSentry and its companion programs (Logcheck, LogSentry, and HostSentry) are free, but do not have a license that complies with the Open Source definition. This mostly impacts re-distribution efforts, so if you're planning on selling your own Linux distribution and including the Abacus tools, you'll want to talk to Psionic first.
Installing PortSentry is straightforward. Go to http://www.psionic.com/download/, and get at least the PortSentry software (we like LogCheck, too), as well as the PGP signatures for each package you download, plus Craig Rowland's signature file. Later in this chapter, we'll show you how to verify a signature using both PGP and GnuPG, but for the moment, bear with us as we walk through the steps to check the validity of the downloaded package. This is always an especially good idea with security software, because it's the ideal package to Trojan from a cracker's perspective.
First, add Craig's public key to your PGP public keyring. Then use PGP to check the signature on the downloaded file(s).
[bilbrey@gwydion bilbrey]$ pgp -ka crowland.asc
* * *
[bilbrey@gwydion bilbrey]$ pgp portsentry-1.0.tar.gz
Pretty Good Privacy(tm) Version 6.5.8
(c) 1999 Network Associates Inc.
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Export of this software may be restricted by the U.S. government.
File 'portsentry-1.0.tar.gz.asc' has signature, but with no text.
Text is assumed to be in file 'portsentry-1.0.tar.gz'.
Good signature from user "Craig H. Rowland <[email protected]>".
Signature made 1999/12/02 03:10 GMT
WARNING: Because this public key is not certified with a trusted
signature, it is not known with high confidence that this public key
actually belongs to: "Craig H. Rowland <[email protected]>".
Once that's done, copy the gzipped tarball to a suitable location (we use /usr/local/src to keep and compile sources that aren't part of OpenLinux). Then extract the archive as shown below:
[root@gwydion bilbrey]# cp portsentry-1.0.tar.gz /usr/local/src
[root@gwydion bilbrey]# cd /usr/local/src
[root@gwydion src]# tar zxvf portsentry-1.0.tar.gz
portsentry-1.0/
portsentry-1.0/CHANGES
portsentry-1.0/CREDITS
portsentry-1.0/LICENSE
portsentry-1.0/Makefile
portsentry-1.0/README.COMPAT
portsentry-1.0/README.install
portsentry-1.0/README.methods
portsentry-1.0/README.stealth
portsentry-1.0/ignore.csh
portsentry-1.0/portsentry.c
portsentry-1.0/portsentry.conf
portsentry-1.0/portsentry.h
portsentry-1.0/portsentry.ignore
portsentry-1.0/portsentry_config.h
portsentry-1.0/portsentry_io.c
portsentry-1.0/portsentry_io.h
portsentry-1.0/portsentry_tcpip.h
portsentry-1.0/portsentry_util.c
portsentry-1.0/portsentry_util.h
[root@gwydion src]# cd portsentry-1.0
Scan each of the README files carefully. Security measures function best when they are understood properly and setup correctly. Otherwise they rarely accomplish the task at hand: that of securing your system.
Next, open and edit the configuration files as directed by the README.install file. The first, portsentry_config.h, rarely needs changing, but it's a good idea to see where various PortSentry files are going to be installed.
The second file, portsentry.conf, requires at least one edit: a choice of which KILL_ROUTE method to use. The premise is that once an external host has been detected doing unauthorized, nasty, or just plain stupid things at your network connection, you want to be able to shut him or her off at the gates permanently. README.install discusses the various options - we select and uncomment the recommended variety, adding the attacker's address to our IPChains firewall by uncommenting the appropriate line in the portsentry.conf file. This step is shown in the upcoming listing.
Finally, modify the portsentry.ignore file, adding all of the IP addresses that are assigned to the protected machine. Make sure to add all real and virtual IP numbers. In our example, with only one card on a local net, we just add one address.
[root@gwydion portsentry-1.0]# vi portsentry_config.h
* * *
[root@gwydion portsentry-1.0]# vi portsentry.conf
* * *
#
# New ipchain support for Linux kernel version 2.102+
KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -l"
#
[root@gwydion portsentry-1.0]# vi portsentry.ignore
# Put hosts in here you never want blocked. This includes the IP addresses
# of all local interfaces on the protected host (i.e virtual host, mult-home[CT1])
# Keep 127.0.0.1 and 0.0.0.0 to keep people from playing games.
192.168.0.5
127.0.0.1
0.0.0.0
The next step is to build and install the software. There are make options for many different types of host system (linux, bsd, solaris, hpux, hpux-gcc, freebsd, openbsd, netbsd, bsdi, aix, osf, generic), so one of these needs to be specified on the command line, as shown.
[root@gwydion portsentry-1.0]# make linux
SYSTYPE=linux
Making
cc -O -Wall -DLINUX -DSUPPORT_STEALTH -o ./portsentry ./portsentry.c \
./portsentry_io.c ./portsentry_util.c
[root@gwydion portsentry-1.0]# make install
Creating psionic directory /usr/local/psionic
Setting directory permissions
chmod 700 /usr/local/psionic
Creating portsentry directory /usr/local/psionic/portsentry
Setting directory permissions
chmod 700 /usr/local/psionic/portsentry
Copying files
cp ./portsentry.conf /usr/local/psionic/portsentry
cp ./portsentry.ignore /usr/local/psionic/portsentry
cp ./portsentry /usr/local/psionic/portsentry
Setting permissions
chmod 600 /usr/local/psionic/portsentry/portsentry.ignore
chmod 600 /usr/local/psionic/portsentry/portsentry.conf
chmod 700 /usr/local/psionic/portsentry/portsentry
Edit /usr/local/psionic/portsentry/portsentry.conf and change
your settings if you haven't already. (route, etc)
WARNING: This version and above now use a new
directory structure for storing the program
and config files (/usr/local/psionic/portsentry).
Please make sure you delete the old files when
the testing of this install is complete.
PortSentry is now installed and ready to be started. There are three options each for monitoring both the TCP and UDP ports on a system: standard, stealth, and advanced stealth. README.install warns that the advanced stealth method is the most sensitive and prone to false alarms. However, our preference is to use this most sensitive method. We'd rather check out a false alarm than find out that the machine has been cracked and used as a warez (illegal software) site or that our activities and passwords have been logged and passed to a third party. To use PortSentry in this mode, add the following lines (along with comment lines similar to those shown) to the bottom of the /etc/rc.d/rc.local system boot file:
[root@gwydion portsentry-1.0]# vi /etc/rc.d/rc.local
* * *
# The following lines start the PortSentry monitoring. Keep these lines
# at the *bottom* of the rc.local file, so that all other in-use ports are
# configured and running prior to starting Portsentry. Then Portsentry
# detects the bound ports and excludes them from monitoring. BPB 10/2000
/usr/local/psionic/portsentry/portsentry -atcp
/usr/local/psionic/portsentry/portsentry -audp
Strongly Suggested
The README.install file has all the directions needed to correctly use PortSentry in all of its modes. As usual, RTFM ("Read The Fine Manual") is an excellent piece of advice. Please do so.
From another Linux box on the network, we installed and ran nmap in a stealth scan mode. Prior to PortSentry, we tested the system and found ports 22, 113, and 515 open. This was expected, as the system runs SSH, auth (identd), and a printer daemon (lpd). The full XMAS stealth scan took just seven seconds. To enable PortSentry without rebooting, type each line shown in the previous listing at the command line as root. Once that's done, you can test your system.
We re-ran Nmap in a variety of modes. With the system's network connections monitored (and blocked as necessary) by PortSentry, the port scanner's pace drops to a crawl, which in itself is enough to send most uninvited guests on to the next potential target. Nmap finally returns after two minutes, having scanned the same 1,523 ports that we checked in the first pass. Virtually everything shows as a false positive for open ports. The acid test is to then try and connect to the same system via a legitimate program (in this case, SSH). Once a system is blocked, it is completely shut out from all services, even those that were previously available. No joy, network access from our scanning box to the OpenLinux installation is gone, just as it should be in the current situation.
Messages about the attack and its effects are found in the /var/log/messages file (root user access only). Open the file using less and search for the word "attack" by typing /attack. Following our test scan, we find the following output in the file (manually indented for ease of reading):
[root@gwydion portsentry-1.0]# less /var/log/messages
* * *
Oct 10 15:26:10 gwydion portsentry[1588]: attackalert: XMAS scan from host:
192.168.0.9/192.168.0.9 to TCP port: 897
Oct 10 15:26:10 gwydion portsentry[1588]: attackalert: Host 192.168.0.9 has
been blocked via wrappers with string: "ALL: 192.168.0.9"
Oct 10 15:26:10 gwydion portsentry[1588]: attackalert: Host 192.168.0.9 has
been blocked via dropped route using command: "/sbin/ipchains -I input -s
192.168.0.9 -j DENY -l"
Oct 10 15:26:10 gwydion kernel: Packet log: input DENY eth0 PROTO=6
192.168.0.9:37022 192.168.0.5:314 L=40 S=0x00 I=38367 F=0x0000 T=43 (#1)
Each log entry begins with a date/time stamp. The first line correctly identifies the type of scan, the following two entries block the attacker by adding the IP to the /etc/hosts.deny file, and then using IPChains to block the IP address yet again. The fourth log item shows the IPChains logger noting that an attempted connection is being dropped. There are several hundred of these in a row, a result of the full scan. PortSentry has done its job.
Reset
Had this been an actual attack, we could add the attacking IP address to the /etc/rc.d/rc.firewall script for a permanent block. However, in this case, we want to allow the test box to have legitimate access again. To do so, manually remove the IP address from /etc/hosts.deny. Then re-run your firewall script to clear the modifications made by PortSentry and reload the firewalling rules. When that's done, the ways are open again.
At the beginning of this section, we mentioned Psionic's program Logcheck. This tool is another member of the Abacus suite. It is used to monitor system logs and send e-mail to the system administrator upon detecting specified events (like scan attacks). This is quite useful for the admin who is responsible for numerous different systems, or even for single system/small network operators. The e-mail can be examined and forwarded to the appropriate "authorities," usually an "[email protected]" address for the originating network. Logcheck is easy to install and use - we leave that as an exercise for the reader.
If an attacker does make it past the ramparts via an exploit that isn't covered by IPChains or PortSentry, you'll still want to know, even after the fact. This is an important point to cover. Assume the black hats get in somehow. Effective detection is the key to being able to respond appropriately. This is the task for the next utility, Tripwire.
The idea behind Intrusion Detection Systems (IDS) is a simple one: find a set of markers that can be reliably used to determine whether the system has been modified, and check them for change on a regular basis. Sounds simple in theory, but there are a number of wrinkles to applying this in practice.
When a system is broken into, often the first action of the cracker is to plant a tool called a root kit or similar nasty software. The goal of an IDS is to provide a secure method of determining that files (programs or data) are clean. Secure is important, because there could be a tool that provides a Trojan version of the checking program or database. So installing Tripwire or any other intrusion detection software properly is a combination of correct configuration and secure installation, as we shall demonstrate.
More Info
An attack using a root kit replaces common system executables likelogin,ls,du,pswith substitutes. The Trojan versions either act as entry points and backdoors for the cracker, or serve to hide the unauthorized activities from legitimate users including the system administrator. Additionally, the "tool" removes the entries documenting the attack from various system logs and revises the checksum/time stamp information for the replaced binaries.
There are currently two different versions of Tripwire available at http://www.tripwire.com/downloads/. There is early version called the Academic Source Release (or ASR) that is free, but unsupported. The latest version, Tripwire 2.2.1, is commercial software and free for non-commercial use as of this writing. Our understanding with the good folks at the headquarters is that by the time you're reading this, Tripwire will be a GPL licensed product, with sources and binaries available from http://www.tripwire.org/. Commercial support and add-on products will still be available from Tripwire, of course. Let's have a look at the current release.
We downloaded all of the documentation (in PDF format), as well as the binary installation file, Tripwire_221_for_Linux_x86.tar.gz. The User Guide, a 2.9MB file called tw_221_unixusrgde.pdf, contains the installation and usage instructions in 131 tightly written pages. As with all other non-distribution specific installations, we work in the /usr/local sub-tree of the OpenLinux filesystem. Copy the Tripwire files into a new directory (/usr/local/tw, for example), and then unpack the archive.
[root@gwydion syroid]# cd /usr/local/tw
[root@gwydion tw]# tar zxvf Tripwire_221_for_Linux_x86.tar.gz
License.txt
README
Release_Notes
install.cfg
install.sh
pkg/
pkg/bin.pkg
pkg/man.pkg
pkg/policy.pkg
[root@gwydion tw]# vi install.cfg
Following the directions in the User Guide, edit install.cfg using vi or your text editor of choice. The only change we want to make is to place the Tripwire root directory under /usr/local, so the applicable line in the file should now read:
TWROOT="/usr/local/TSS"
All the other directories specified in install.cfg are placed relative to TWROOT. Next, choose two passphrases. One is the site keyfile passphrase, used to protect the installation and configuration of Tripwire. The second is called the local keyfile passphrase. It is used to protect the contents of the Tripwire database and optionally, reports. Passphrases should be unique, long, and difficult (and not written on a sticky note pasted to your monitor!). Now install the Tripwire software. Excerpts from this process are shown.
[root@gwydion tw]# ./install.sh install.cfg
Installer program for:
Tripwire(R) 2.2.1 for Unix
Copyright (C) 1998-2000 Tripwire (R) Security Systems, Inc. Tripwire (R)
is a registered trademark of the Purdue Research Foundation and is
licensed exclusively to Tripwire (R) Security Systems, Inc.
* * * * Warning * * * *
The uname command, which tells what operating system is running on this
machine, returned a result that this installation script did not expect.
Tripwire 2.2.1 for Unix is supported on the following configurations:
Hewlett-Packard HP-UX 10.20
Hewlett-Packard HP-UX 11.0
IBM AIX 4.2
IBM AIX 4.3
Sun Solaris - Sparc 2.6
Sun Solaris - Sparc 7.0
Sun Solaris - Intel 2.6
Sun Solaris - Intel 7.0
Redhat Linux 5.2
Redhat Linux 6.0
SGI Irix 6.5
Compaq Tru64 Unix 4.0
Continue with installation? [y/n] y
* * *
The installation is known to function on many different distributions of Linux, including OpenLinux. Enter "y" as shown previously. In the 2.2.1 version, you must accept a license to complete the installation. Once that's done, the installer lists the locations to confirm the entries in the install.cfg file.
* * *
This program will copy Tripwire files to the following directories:
TWROOT: /usr/local/TSS
TWBIN: /usr/local/TSS/bin
TWMAN: /usr/local/TSS/man
TWPOLICY: /usr/local/TSS/policy
TWREPORT: /usr/local/TSS/report
TWDB: /usr/local/TSS/db
TWSITEKEYDIR: /usr/local/TSS/key
TWLOCALKEYDIR: /usr/local/TSS/key
CLOBBER is false.
Continue with installation? [y/n] y
* * *
"Clobber is false" is a notification that older report files are not going to be overwritten. We generally prefer to keep a few older reports around, and purge them at our leisure. The Tripwire documentation contains instructions on modifying this feature. Accept and continue if the locations are correct, or press Ctrl + C to bail out if you want to change anything. Following this question, all of the directories are created, and the binaries and initial configuration files written.
Then it is time to enter the passphrases. We use "fiddle" and "faddle" for our examples. However, use good passphrases when playing for keeps.
* * *
----------------------------------------------.
The Tripwire site and local passphrases are used to
sign a variety of files, such as the configuration,
policy, and database files.
Passphrases should be at least 8 characters in length
and contain both letters and numbers.
See the Tripwire manual for more information.
----------------------------------------------.
Creating key files...
(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)
Enter the site keyfile passphrase: fiddle
Verify the site keyfile passphrase: fiddle
Generating key (this may take several minutes)...Key generation complete.
(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)
Enter the local keyfile passphrase: faddle
Verify the local keyfile passphrase: faddle
Generating key (this may take several minutes)...Key generation complete.
* * *
Once the passphrases are entered, and the keys generated, the initial configuration files are created using the keys. This requires entering the site passphrase twice more, as shown in the following listing:
----------------------------------------------.
Generating Tripwire configuration file...
----------------------------------------------.
Creating signed configuration file...
Please enter your site passphrase: fiddle
Wrote configuration file: /usr/local/TSS/bin/tw.cfg
A clear-text version of the Tripwire configuration file
/usr/local/TSS/bin/twcfg.txt
has been preserved for your inspection. It is recommended
that you delete this file manually after you have examined it.
----------------------------------------------.
Customizing default policy file...
----------------------------------------------.
Creating signed policy file...
Please enter your site passphrase: fiddle
Wrote policy file: /usr/local/TSS/policy/tw.pol
A clear-text version of the Tripwire policy file
/usr/local/TSS/policy/twpol.txt
has been preserved for your inspection. This implements
a minimal policy, intended only to test essential
Tripwire functionality. You should edit the policy file
to describe your system, and then use twadmin to generate
a new signed copy of the Tripwire policy.
----------------------------------------------.
The installation succeeded.
Please refer to /usr/local/TSS/Release_Notes
for release information and to the printed user documentation
for further instructions on using Tripwire 2.2.1 for Unix.
Inspecting /usr/local/TSS/bin/twcfg.txt confirms that the installation reflects the choices from the initial install.cfg file. So, as the procedure advises, we delete the text file. After that, it's time to edit the /usr/local/TSS/policy/twpol.txt file and customize the monitoring policy to the system.
The User Guide provides some help on creating policy file rules, and further recommends that the initial twpol.txt file be used as an example. One very nice feature of the Tripwire installation is that an initial backup copy of the twpol.txt file is created when the system is first installed. This is very useful, should you need to return to a known state and forget to create a backup of the original file manually.
We've found that the default policy file is quite good. However, we want to be able to use e-mail notification, so we want to encase all of the rules in an "emailto" block. To do so, modify the policy file to read as follows:
@@section GLOBAL
TWROOT="/usr/local/TSS";
TWBIN="/usr/local/TSS/bin";
TWPOL="/usr/local/TSS/policy";
TWDB="/usr/local/TSS/db";
TWSKEY="/usr/local/TSS/key";
TWLKEY="/usr/local/TSS/key";
TWREPORT="/usr/local/TSS/report";
HOSTNAME=gwydion.orbdesigns.com;
@@section FS
SEC_CRIT = $(IgnoreNone)-SHa; # Critical files - we can't afford to miss any changes.
SEC_SUID = $(IgnoreNone)-SHa; # Binaries with the SUID or SGID flags set.
SEC_TCB = $(ReadOnly); # Members of the Trusted Computing Base.
SEC_BIN = $(ReadOnly); # Binaries that shouldn't change
SEC_CONFIG = $(Dynamic); # Config files that are changed infrequently but accessed often.
SEC_LOG = $(Growing); # Files that grow, but that should never change ownership.
SEC_INVARIANT = +pug; # Directories that should never change permission or ownership.
SIG_LOW = 33; # Non-critical files that are of minimal security impact
SIG_MED = 66; # Non-critical files that are of significant security impact
SIG_HI = 100; # Critical files that are significant points of vulnerability
(emailto = bilbrey)
{
# Tripwire Binaries
(rulename = "Tripwire Binaries", severity = $(SIG_HI))
{
$(TWBIN)/siggen -> $(ReadOnly);
$(TWBIN)/tripwire -> $(ReadOnly);
$(TWBIN)/twadmin -> $(ReadOnly);
$(TWBIN)/twprint -> $(ReadOnly);
}
*** REST OF RULES ALREADY DEFINED HERE
}
Below the @@global and @@section, add the "(emailto...)" line, with a left curly bracket following. Then, at the bottom of the file, add a closing, right curly bracket. This encloses all of the defined rules in an "emailto" block. We'll demonstrate the use of this feature shortly.
To clean up the contents of the policy file, parts of which don't match the OpenLinux distribution, create the initial database and watch for errors during the database creation. These are marked with "###" as shown in the following listing. Then edit the policy file to comment out files that don't need to be checked (because they don't exist on OpenLinux) or modify the rule to match the appropriate file, and update the policy file accordingly. This process is demonstrated in the following listing.
[root@gwydion bin]# ./twadmin --create-polfile ../policy/twpol.txt
Please enter your site passphrase: fiddle
Wrote policy file: /usr/local/TSS/policy/tw.pol
[root@gwydion bin]# ./tripwire --init
Please enter your local passphrase: faddle
Parsing policy file: /usr/local/TSS/policy/tw.pol
Generating the database...
*** Processing Unix File System ***
### Warning: File system error.
### Filename: /usr/tmp
### No such file or directory
* * *
### Continuing...
Wrote database file: /usr/local/TSS/db/gwydion.orbdesigns.com.twd
The database was successfully generated.
In editing the policy file to conform to OpenLinux, pay attention to whole blocks of errors that are generated by differences between in the directory structures assumed by Tripwire, and those used by Caldera. For example, the policy file looks for all of the rc* files (system boot scripts) directly in the /etc directory. Under OpenLinux, the correct directory is /etc/rc.d. So in this case, we make the following changes to the Boot Scripts rule in twpol.txt:
[root@gwydion bin]# vi ../policy/twpol.txt
* * *
(rulename = "Boot Scripts")
{
/etc/rc.d/rc -> $(SEC_CONFIG);
/etc/rc.d/rc.boot -> $(SEC_CONFIG);
/etc/rc.d/rc.gui -> $(SEC_CONFIG);
/etc/rc.d/rc.local -> $(SEC_CONFIG);
/etc/rc.d/rc.modules -> $(SEC_CONFIG);
/etc/rc.d/rc.serial -> $(SEC_CONFIG);
/etc/rc.d/unconfigured.sh -> $(SEC_CONFIG);
/etc/rc.d/rc.firewall -> $(SEC_CONFIG);
}
* * *
Now update the policy configuration, then run a check to ensure everything was modified correctly. It usually requires several passes to make sure all the entries in the policy file are correct, since we do want to check the correct things, rather than just blindly comment out file checks and rules that don't work on the first or second pass.
[root@gwydion bin]# ./tripwire -m p ../policy/twpol.txt
Parsing policy file: /usr/local/TSS/policy/twpol.txt
Please enter your local passphrase: faddle
Please enter your site passphrase: fiddle
======== Policy Update: Processing section Unix File System.
======== Step 1: Gathering information for the new policy.
### Error: Policy Update Added Object.
### An object has been added since the database was last updated.
### Object name: /usr/local/TSS/db/gwydion.orbdesigns.com.twd
### Error: Policy Update Changed Object.
### An object has been changed since the database was last updated.
### Object name: Conflicting properties for object /usr/local/TSS/policy/tw.pol
### > Modify Time
### > CRC32
### > MD5
======== Step 2: Updating the database with new objects.
======== Step 3: Pruning unneeded objects from the database.
Policy update failed; policy and database files were not altered.
As you can see from the end of the policy update, for some reason our update failed. As this is the beginning of the process, and we have the machine in a known state, we'll just start from scratch with the revised policy file, as follows. [Late Translation - We don't know why the database update process failed, we had to keep going, so we punted. Starting from scratch works. "Just Works" has lots going for it, even in this latter day and age. 05/2001, bpb]
[root@gwydion bin]# ./twadmin --create-polfile ../policy/twpol.txt
Please enter your site passphrase: fiddle
Wrote policy file: /usr/local/TSS/policy/tw.pol
[root@gwydion bin]# ./tripwire --init
Please enter your local passphrase:
Parsing policy file: /usr/local/TSS/policy/tw.pol
Generating the database...
*** Processing Unix File System ***
Wrote database file: /usr/local/TSS/db/gwydion.orbdesigns.com.twd
The database was successfully generated.
Checking the system
No errors, no problems. Now to test things out, we'll create a problem and use Tripwire to check the system. Since we're currently working in the executables directory, we'll modify the date of the tripwire binary using touch, then run a system check. On the command line, "-m" precedes a command (like "c" to check or "u" to update), and "-M" activates the emailto feature we added to the policy file. "-t 2" specifies the type and verbosity of the mailed report.
[root@gwydion bin]# touch tripwire
[root@gwydion bin]# ./tripwire -m c -M -t 2
Parsing policy file: /usr/local/TSS/policy/tw.pol
*** Processing Unix File System ***
Performing integrity check...
Beginning email reporting...
Emailing the report to: bilbrey
Wrote report file: /usr/local/TSS/report/gwydion.orbdesigns.com-20001011-182529.twr
Tripwire(R) 2.2.1 Integrity Check Report
Report generated by:
Report created on: Wed Oct 11 18:25:29 2000
Database last updated on: Never
===============================================================================
Report Summary:
===============================================================================
Host name: gwydion.orbdesigns.com
Host IP address: Unknown IP
Host ID: 0
Policy file used: /usr/local/TSS/policy/tw.pol
Configuration file used: /usr/local/TSS/bin/tw.cfg
Database file used: /usr/local/TSS/db/gwydion.orbdesigns.com.twd
Command line used: ./tripwire -m c -M -t 2
===============================================================================
Rule Summary:
===============================================================================
---------------------------------------------------------------------.
Section: Unix File System
---------------------------------------------------------------------.
Rule Name Severity Level Added Removed Modified
--------- -------------- ----- ------- -------- .
Invariant Directories 66 0 0 0
Tripwire Data Files 100 0 0 0
Temporary directories 33 0 0 0
Critical devices 100 0 0 0
* Tripwire Binaries 100 0 0 1
User binaries 66 0 0 0
setuid/setgid 100 0 0 0
Libraries 66 0 0 0
OS executables and libraries 100 0 0 0
Shell Binaries 0 0 0 0
Critical configuration files 100 0 0 0
Configuration Files 0 0 0 0
Security Control 0 0 0 0
Boot Scripts 0 0 0 0
Login Scripts 0 0 0 0
Critical system boot files 100 0 0 0
(/boot)
* Root config files 100 0 0 1
(/root)
Total objects scanned: 15027
Total violations found: 2
===============================================================================
Object Summary:
===============================================================================
---------------------------------------------------------------------.
# Section: Unix File System
---------------------------------------------------------------------.
---------------------------------------------------------------------.
Rule Name: Tripwire Binaries (/usr/local/TSS/bin/tripwire)
Severity Level: 100
---------------------------------------------------------------------.
Modified:
"/usr/local/TSS/bin/tripwire"
---------------------------------------------------------------------.
Rule Name: Root config files (/root)
Severity Level: 100
---------------------------------------------------------------------.
Modified:
"/root/.bash_history"
===============================================================================
Error Report:
===============================================================================
No Errors
---------------------------------------------------------------------.
*** End of report ***
Copyright (C) 1998-2000 Tripwire(R) Security Systems, Inc.
Tripwire(R) is a registered trademark of the Purdue Research
Foundation and is licensed exclusively to Tripwire(R) Security
Systems, Inc.
Integrity check complete.
The listing that follows the Tripwire invocation is identical to the report mailed to user account bilbrey. It shows two policy violations, one of the /usr/local/TSS/bin/tripwire binary, which was caused by touching the file. The second is a modification to /root/bash_history, which is expected, since we're working as root. The database can be updated via the following command.
[root@gwydion bin]# ./tripwire -m u -r ../report/gwydion.orbdesigns.com-20001011-182529.twr
vi, where specific items can be selected for updating, as the next excerpt shows:
------------------------------------------------------------------.
Rule Name: Tripwire Binaries (/usr/local/TSS/bin/tripwire)
Severity Level: 100
------------------------------------------------------------------.
Remove the "x" from the adjacent box to prevent updating the database
with the new values for this object.
Modified:
[x] "/usr/local/TSS/bin/tripwire"
***
Once the file has been edited, write out the changes by pressing Esc (to terminate edit mode), followed by typing :wq to write the file and quit. Then Tripwire prompts for the local passphrase, and with a correct entry, updates the database.
We've taken a lot of space with the Tripwire software. However, this is a complex package with many options and methods for validating file integrity. And we've barely scratched the surface. However, most of what we showed you in this section is worthwhile, and should continue to apply in the next Tripwire - the Open Source version.
Now for three hints that make Tripwire or any intrusion detection system effective. First, if you have to update the database frequently, you're monitoring the wrong items and need to change your policies. Second, setup a cron job to automatically run integrity checks at whatever interval makes sense for the machine being protected. Finally, the most secure configuration of an ID system (IDS) involves having the binaries and database on a read-only filesystem, a CD-ROM for instance. This requires some careful configuration, but guards against your IDS being compromised. Next, let's see how the best Open Source competitor stacks up against the commercial market leader. The question, of course, is what happens when Tripwire is also a GPL product. Our fervent hope is that there can be a cross-pollination of good ideas from both packages, yielding two strong products. Take a look at AIDE.
The Advanced Intrusion Detection Environment (AIDE) makes use of a variety of message digest algorithms to provide crosschecks for the integrity of selected files on the system. AIDE is available for download from http://www.cs.tut.fi/~rammer/aide.html. Other resources at the Web site include a four-page user manual. Additional digest functions (recommended by the author of AIDE) are made available by installing a custom library, mhash, found at http://mhash.sourceforge.net/.
Note
Message Digest Algorithms (MDA), like MD5 and its kin, are functions that can take in a stream of input data, of arbitrary length. The output of the algorithm is a character string of fixed length. For any given message, the algorithm is designed to return a unique output string. For example, suppose that Brian writes Tom a message, and calculates the MD5 sum on the file. Then Brian can email the message to Tom, and send the short verifying MD5 string by another route (say over a telephone call). In receipt of the message, Tom can verify that the message Brian sent is the one he's got, since the MDA output is unique. After retrieving the two source packages, un-archive them in /usr/local/src.
First we'll walk through building the mhash library. The steps are as follows: use tar to extract the program sources, cd to the source directory, configure the build, make (compile) the library, and finally make install mhash.
[root@gwydion etc]# cd /usr/local/src
[root@gwydion src]# tar zxf mhash-0.8.2.tar.gz
[root@gwydion src]# cd mhash-0.8.2
[root@gwydion mhash-0.8.2]# ./configure
loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
* * *
[root@gwydion mhash-0.8.2]# make
make all-recursive
make[1]: Entering directory `/usr/local/src/mhash-0.8.2'
* * *
[root@gwydion mhash-0.8.2]# make install
Making install in lib
make[1]: Entering directory `/usr/local/src/mhash-0.8.2/lib'
make[2]: Entering directory `/usr/local/src/mhash-0.8.2/lib'
* * *
--------------------------------------------------------------.
Libraries have been installed in:
/usr/local/lib
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
--------------------------------------------------------------.
* * *
Once the mhash library has been built and installed, we need to add it to the list of libraries so other programs running under OpenLinux can locate and access it. Accomplish this minor feat of prestidigitation by editing /etc/ld.so.conf to add the installation library directory, then run ldconfig to register the changes.
[root@gwydion mhash-0.8.2]# vi /etc/ld.so.conf /usr/X11R6/lib /opt/kde/lib /lib/gnulibc1=libc5 /usr/X11R6/lib/gnulibc1=libc5 /usr/openwin/lib/gnulibc1=libc5 /usr/lib/gnulibc1=libc5 /opt/kde/lib/gnulibc1=libc5 /usr/lib/qt2/lib /usr/local/lib # add this line to /etc/ld.so.conf [root@gwydion mhash-0.8.2]# ldconfig
Now that the recommended additional digest functions are installed and accessible, we can compile and install AIDE. Note that we use a different invocation of tar in the following listing - the "v" in the option string requests verbose operation, listing each file as it is extracted, as shown.
[root@gwydion mhash-0.8.2]# cd ..
[root@gwydion src]# tar zxvf aide-0.7.tar.gz
aide-0.7/
aide-0.7/Makefile.in
aide-0.7/README
* * *
[root@gwydion src]# cd aide-0.7
By typing ./configure --help, we get a list of the available compilation options, from installation directories to additional libraries. In this manner, we determine the correct command option for making use of the just-installed mhash library.
[root@gwydion aide-0.7]# ./configure --with-mhash
creating cache ./config.cache
* * *
checking for mhash_get_block_size in -lmhash... yes
* * *
[root@gwydion aide-0.7]# make
make all-recursive
* * *
[root@gwydion aide-0.7]# make install
Making install in src
The next step in setting up AIDE is editing the configuration file to perform the desired checks on specified files and directories. Although the file formats are different, AIDE rules are very similar to those in Tripwire. Here is a simple configuration designed from the sample file that comes with AIDE. The comments provide explanation for each block. For more information, type man aide.conf at the command line to access the manual page.
#
# AIDE 0.7 configuration file // bilbrey 11/09/2000
# Base directory defined
@@define TOPDIR /usr/local
# Input (INIT) database location
database=file:@@{TOPDIR}/tmp/aide.db
# Output database location
database_out=file:@@{TOPDIR}/tmp/aide.db.new
# Where to write output : STDOUT by default
report_url=stdout
# Definitions of check types
#p: permissions
#i: inode
#n: number of links
#u: user
#g: group
#s: size
#b: block count
#m: mtime
#a: atime
#c: ctime
#S: check for growing size
#md5: md5 checksum
#sha1: sha1 checksum
#rmd160: rmd160 checksum
#tiger: tiger checksum
#R: p+i+n+u+g+s+m+c+md5
#L: p+i+n+u+g
#E: Empty group
#>: Growing logfile p+u+g+i+n+S
#The following are available if you have mhash support enabled.
#haval: haval checksum
#gost: gost checksum
#crc32: crc32 checksum
# A rule to check files with: Let's be paranoid!
# Look at inode, ctime, size, number of links, block count,
# and 4 distinct hashes: md5, sha1, rmd160 and tiger
Norm=i+c+s+n+b+md5+sha1+rmd160+tiger
# Places to check, and rule to check by.
# Fully recursive, unless ! or = (stop or restrict)
/etc Norm
/bin Norm
/sbin Norm
/usr/sbin Norm
/usr/bin Norm
/usr/local/sbin Norm
/usr/local/bin Norm
The seven directories specified previously are a good basis for intrusion detection, though you might want to add more locations depending on your specific configuration and needs.
Once you've got a good configuration file (which takes some iterative testing, just like Tripwire), then initialize and test AIDE. The basic premise is to run the software once using the --init option to build the first database. Then rename the database to match the name of the input database as given in the aide.conf file. Finally, use touch to modify a monitored file, run a check, and watch the output. (AIDE usage is well documented; type man aide to learn more).
[root@gwydion local]# bin/aide -c /usr/local/etc/aide.conf --init
[root@gwydion local]# mv tmp/aide.db.new tmp/aide.db
[root@gwydion local]# touch /bin/dd
[root@gwydion local]# bin/aide -c /usr/local/etc/aide.conf --check
AIDE found differences between database and filesystem!!
Start timestamp: 2000-10-12 14:25:52
Summary:
Total number of files=2880,added files=0,removed files=0,changed files=1
Changed files:
changed:/bin/dd
Detailed information about changes:
File: /bin/dd
Ctime: old = 2000-10-04 11:25:36, new = 2000-10-12 14:25:45
End timestamp: 2000-10-12 14:26:31
Set up AIDE to run in a cron job and the output will be mailed to the root user at regular intervals. Here is a sample crontab entry that runs AIDE once a day, at 5:05 AM.
5 5 * * * /usr/local/bin/aide -c /usr/local/etc/aide.conf --check
Extra Security
For even more security, consider logging your messages to a remote host. The logging computer has to havesyslogdrunning with the "-r" option to enable receipt of remote log data. Additionally, rules need to be configured in the local /etc/syslog.conf file to send the data (of the form "*.* @loghost"). Typeman syslog.conffor more details.
As with Tripwire, the most secure installation requires having the AIDE binary, configuration, and database files mounted on a read-only filesystem. In a head-to-head competition, AIDE currently lacks encrypted format configuration and database signing, which might make a difference in selecting IDS software. This capability is slated for an upcoming release, along with Internet access for databases and reporting. <sarcasm>In a burst of outright cheerfulness</sarcasm>, Rami Lehti (author of AIDE) closes the user manual with the following:
General Guidelines for Security
1. Do not assume anything
2. Trust no-one, nothing
3. Nothing is secure
4. Security is a trade-off with usability
5. Paranoia is your friend
Moving forward with the "Paranoia" theme, there are many utilities available for assisting people with achieving and keeping privacy while computing. We'll start off by looking at GnuPG, the GNU Project's version of PGP, which is installed with eDesktop 2.4.
GnuPG is the acronym for the GNU Privacy Guard, an Open Source replacement for PGP (which we'll look at later in this chapter). GnuPG complies with the OpenPGP (RFC2440) proposed Internet standard. It is not vulnerable to the latest (as of Fall, 2000) hacker exploit: fake ADK (Additional Decryption Key) attacks. It does not include the patented IDEA algorithm, but the latest version uses the newly freed RSA. Coming soon is support for the new AES (American Encryption Standard) selection, Rijndael. For information and links on GnuPG, look to the Web site: http://www.gnupg.org/.
We'll start by removing version 1.0.1 (installed by default on OpenLinux 2.4). Upgrading to the current version (1.0.3 or better) adds RSA and MDC encryption packet support, and there are compatibility enhancements that make GnuPG more capable of working with current and upcoming versions of PGP. So first, remove the default GnuPG package, then point your browser (or use FTP) to ftp://ftp.gnupg.org/pub/gcrypt/gnupg/ and get gnupg-version.tar.gz and gnupg-version.tar.gz.sig (where version is the latest).
Extra Information
RSA and MDC are two different types of encryption algorithms that are commonly used in secure communications. These two specific tools were previously patent-encumbered, but are now in the public domain.
[root@gwydion /root]# rpm -e gnupg
[root@gwydion /root]# ftp -i ftp.gnupg.org
* * *
Name (ftp.gnupg.org:bilbrey): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password: [email protected]
* * *
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd pub/gcrypt/gnupg
250 CWD command successful.
ftp> mget gnupg-1.0.3*
local: gnupg-1.0.3.tar.gz remote: gnupg-1.0.3.tar.gz
200 PORT command successful.
150 Opening BINARY mode data connection for gnupg-1.0.3.tar.gz (1690521 bytes).
226 Transfer complete.
1690521 bytes received in 20.4 secs (81 Kbytes/sec)
local: gnupg-1.0.3.tar.gz.sig remote: gnupg-1.0.3.tar.gz.sig
200 PORT command successful.
150 Opening BINARY mode data connection for gnupg-1.0.3.tar.gz.sig (65 bytes).
226 Transfer complete.
65 bytes received in 0.000297 secs (2.1e+02 Kbytes/sec)
ftp> exit
221 Goodbye.
[root@gwydion /root]# mv gnupg-1.0.3.tar.gz* /usr/local/src
[root@gwydion /root]# cd /usr/local/src
[root@gwydion src]# tar zxf gnupg-1.0.3.tar.gz
[root@gwydion src]# cd gnupg-1.0.3
[root@gwydion gnupg-1.0.3]# less README
Following the instructions in the README file, we next check the md5sum of the downloaded source tarball and compare it with a variety of sources, including the GnuPG site, mailing lists, and Usenet announcements.
[root@gwydion gnupg-1.0.3]# md5sum ../gnupg-1.0.3.tar.gz
ef42c679df7a555e23ebe3c8d14a9124 ../gnupg-1.0.3.tar.gz
This MD5 hash result checks with the README file, the main GnuPG Web site, and the announcement of the release, found through http://lists.gnupg.org/.
Moving forward, build and install the program, using the now-familiar routine:
[root@gwydion gnupg-1.0.3]# ./configure
* * *
[root@gwydion gnupg-1.0.3]# make
* * *
[root@gwydion gnupg-1.0.3]# make install
* * *
Once installation is complete, the next step is to generate some keys and other related files. As a first time user, you should begin by generating a fresh set of keys, both for signing and encryption. There may be a directory left behind from the OpenLinux installation of GnuPG. Delete that, create a new, empty directory, and give it restrictive permissions (owner only).
[bilbrey@gwydion bilbrey]$ rm -rf .gnupg
[bilbrey@gwydion bilbrey]$ mkdir .gnupg
[bilbrey@gwydion bilbrey]$ chmod 700 .gnupg/
To generate a key pair, invoke gpg and read all of the prompts carefully. The "...insecure memory!" warning is caused bygpg running as a user process. The potential danger is that the memory containing your keys can get swapped out to disk. The solution (which presents its own dangers) is to make the program suid by typing chmod +s /usr/local/bin/gpg as root. The drawback to this approach is that if the binary is changed to a Trojan version, it would be running with root privileges. The security requirements at each installation dictate the choice here.
The default keysize of 1,024 bits is an effective computational deterrent for data that needs to remain secure for a period of years (using known technology - tomorrow ???). We go though the process, accepting most defaults and entering the required information. Expressly, we have set the key to expire in one year, which is a reasonable timeframe. Too short a cycle and you'll have to generate keys frequently. Too long, and the keys could still be valid for use when you've moved on to better or more secure methods.
The passphrase is very important. With it, you identify yourself to the application, making your private key useful. If you forget the passphrase, there is no way of reconstructing it. If it's too simple, then someone might be able to effectively impersonate you in a way that would be difficult to rectify. Use a good passphrase.
[bilbrey@gwydion bilbrey]$ gpg --gen-key
gpg (GnuPG) 1.0.3; Copyright (C) 2000 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
gpg: Warning: using insecure memory!
gpg: /home/bilbrey/.gnupg/secring.gpg: keyring created
gpg: /home/bilbrey/.gnupg/pubring.gpg: keyring created
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) ElGamal (sign and encrypt)
Your selection? 1
DSA keypair will have 1024 bits.
About to generate a new ELG-E keypair.
minimum keysize is 768 bits
default keysize is 1024 bits
highest suggested keysize is 2048 bits
What keysize do you want? (1024) 1024
Requested keysize is 1024 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1y
Key expires at Fri Oct 12 18:59:28 2001 PDT
Is this correct (y/n)? y
You need a User-ID to identify your key; the software constructs the user id
from Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <[email protected]>"
Real name: Brian Bilbrey
Email address: [email protected]
Comment: NPS
You selected this USER-ID:
"Brian Bilbrey (NPS) <[email protected]>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.
Enter Passphrase: u5e_a/g00d&passphrase
Repeat Passphrase: u5e_a/g00d&passphrase
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++++++++++++++++++++++++++++++++++++++++++.+++++++++++++++.
+++++++++++++++.+++++.+++++++++++++++++++++++++.++++++++++.++++
++++++.+++++>++++++++++....>+++++.....................................+++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
.++++++++++.+++++++++++++++.++++++++++.+++++.+++++...++++++++++.+
++++++++++++++.+++++++++++++++.+++++++++++++++++++++++++.++++
+..+++++++++++++++>+++++.............................+++++^^^
public and secret key created and signed.
Now create a backup revocation certificate, in case the private key is lost or compromised, or the passphrase is forgotten. Start a script file first to record the output for ease of printing down the road... Please note, this is not a real revocation certificate for a key that has ever been publicly used. It is a demonstration for the purposes of this book only.
[bilbrey@gwydion bilbrey]$ script revoke-session
Script started, file is revoke-session
[bilbrey@gwydion bilbrey]$ gpg --gen-revoke [email protected]
gpg: Warning: using insecure memory!
sec 1024D/CFC46714 2000-10-13 Brian Bilbrey (NPS) <[email protected]>
Create a revocation certificate for this key? y
Please select the reason for the revocation:
1 = Key has been compromised
2 = Key is superseded
3 = Key is no longer used
0 = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
> Stock revocation certificate in case I am stupid
> and forget the passphrase
>
Reason for revocation: Key has been compromised
Stock revocation certificate in case I am stupid
and forget the passphrase
Is this okay? y
You need a passphrase to unlock the secret key for
user: "Brian Bilbrey (NPS) <[email protected]>"
1024-bit DSA key, ID CFC46714, created 2000-10-13
Enter Passphrase: u5e_a/g00d&passphrase
ASCII armored output forced.
Revocation certificate created.
Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable. But have some caution: The print system of
your machine might store the data and make it available to others!
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org
Comment: A revocation certificate should follow
iJAEIBECAFAFAjnmctVJHQJTdG9jayByZXZvY2F0aW9uIGNlcnRpZmljYXRlIGlu
IGNhc2UgSSBhbSBzdHVwaWQgYW5kIGZvcmdldCB0aGUgcGFzc3BocgAKCRAF80M6
z8RnFML6AJ47of5PUh+6nzPgRqNszpct0ZKnGACeIJcNXlOCMi1gKdulHJe4h39y
dnE=
=2xTs
-----END PGP PUBLIC KEY BLOCK-----
[bilbrey@gwydion bilbrey]$ exit
exit
Script done, file is revoke-session
Mystery Being
A mysterious being called "Mallory" is referenced in the listing for creating a revocation certificate. Mallory is the fictitious person who executes man-in-the-middle attacks on cryptographic communications. The name Mallory is mnemonic to help readers remember the role of the player (Middle). Oh, and again, the certificate shown is garbage, generated from keys created for this book alone. If you need the public keys of the authors, please contact them directly.
Now the keys are ready for use. However, there are a couple of housekeeping chores to attend to first. Print, then overwrite and delete the revoke-session file created. Make a copy of your ~/.gnupg directory onto two floppies, and test the copies. Wrap the floppies up in the printout of the revocation certificate, and put them in a safe deposit box or a locked fire safe, for example. With this level of backup, you can safely grind a hard drive and not worry about losing your keys.
Some e-mail clients can directly use GnuPG.kmail isn't one of these products. At http://devel-home.kde.org/~kmail/download.html we find a link to a patch for KMail to add GnuPG support. It requires patching and recompiling KMail from sources. We didn't test this. However, you can directly encrypt and sign files from the command line, and attach the files to unencrypted e-mail messages. Now let's look at key management.
First, we'll add pair of keys, and then list the public keys on our keyring.
[bilbrey@gwydion bilbrey]$ pgp --import Tom_Syroid.asc
gpg: Warning: using insecure memory!
gpg: key 717C967A: public key imported
gpg: Total number processed: 1
gpg: imported: 1
[bilbrey@gwydion bilbrey]$ pgp --import crowland.asc
gpg: Warning: using insecure memory!
gpg: key 98ABFE7D: public key imported
gpg: Total number processed: 1
gpg: imported: 1
[bilbrey@gwydion bilbrey]$ pgp --list-keys
gpg: Warning: using insecure memory!
/home/bilbrey/.gnupg/pubring.gpg
--------------------------------
pub 1024D/CFC46714 2000-10-13 Brian Bilbrey (NPS) <[email protected]>
sub 1024g/967083A6 2000-10-13 [expires: 2001-10-13]
pub 1024D/717C967A 2000-04-30 Tom Syroid <[email protected]>
sub 2048g/D84E5CE2 2000-04-30
pub 1024R/98ABFE7D 1996-08-25 Craig H. Rowland <[email protected]>
uid Craig H. Rowland <[email protected]> Key Expires 8/31/97
To ensure that you actually have the correct public key, get a fingerprint of the key, and confirm it with the owner of the key. Alternatively, you can accept the signature of someone you do trust to sign the key, verifying that indeed the public key bearing such-and-such a fingerprint is known to belong to the actual person. These "webs of trust" are documented in the GnuPG User Guide at http://www.gnupg.org/docs.html#guides.
[bilbrey@gwydion bilbrey]$ pgp --fingerprint tom
gpg: Warning: using insecure memory!
pub 1024D/717C967A 2000-04-30 Tom Syroid <[email protected]>
Key fingerprint = C5FE 7FE0 EB64 7EE9 A8D6 CAE4 F34D 3CC1 717C 967A
sub 2048g/D84E5CE2 2000-04-30
If Tom's fingerprint can be verified, then Brian can sign his public key, specifying the level of trust he places in the key, as follows:
[bilbrey@gwydion bilbrey]$ gpg --edit tom
gpg (GnuPG) 1.0.3; Copyright (C) 2000 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
gpg: Warning: using insecure memory!
pub 1024D/717C967A created: 2000-04-30 expires: never trust: -/q
sub 2048g/D84E5CE2 created: 2000-04-30 expires: never
(1) Tom Syroid <[email protected]>
Command> sign
pub 1024D/717C967A created: 2000-04-30 expires: never trust: -/q
Fingerprint: C5FE 7FE0 EB64 7EE9 A8D6 CAE4 F34D 3CC1 717C 967A
Tom Syroid <[email protected]>
Are you really sure that you want to sign this key
with your key: "Brian Bilbrey (NPS) <[email protected]>"
Really sign? y
You need a passphrase to unlock the secret key for
user: "Brian Bilbrey (NPS) <[email protected]>"
1024-bit DSA key, ID CFC46714, created 2000-10-13
Enter Passphrase: u5e_a/g00d&passphrase
Command> trust
pub 1024D/717C967A created: 2000-04-30 expires: never trust: -/q
sub 2048g/D84E5CE2 created: 2000-04-30 expires: never
(1) Tom Syroid <[email protected]>
Please decide how far you trust this user to correctly
verify other users' keys (by looking at passports,
checking fingerprints from different sources...)?
1 = Don't know
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
s = please show me more information
m = back to the main menu
Your decision? 4
pub 1024D/717C967A created: 2000-04-30 expires: never trust: f/q
sub 2048g/D84E5CE2 created: 2000-04-30 expires: never
(1) Tom Syroid <[email protected]>
Command> quit
Save changes? y
In this way, Tom's public key is signed and verified. Now, if Brian is a trusted signer for some third party, then Brian can export Tom's key and send it to them. In this way, they can get a good public key from someone they don't know personally. Now we'll use GnuPG to encrypt and sign files.
In our example, ch20.txt is the input file, ch20.gpg is the output file, the specified recipients are Tom and Brian (both names associated with unique public keys on the local keyring), and "-s" signs the document with Brian's private key. Note that in order for Brian to decrypt the document, he needs to be listed as a recipient.
[bilbrey@gwydion bilbrey]$ gpg -o ch20.gpg -r Tom -r Brian -s ch20.txt
gpg: Warning: using insecure memory!
You need a passphrase to unlock the secret key for
user: "Brian Bilbrey (NPS) <[email protected]>"
1024-bit DSA key, ID CFC46714, created 2000-10-13
Enter Passphrase: u5e_a/g00d&passphrase
Next, we show that the signature can be immediately verified. Additionally, Tom can verify that Brian signed with a valid private key, as long as he has the matching public key. In this way, Tom can be assured that Brian was the signer and performed the encryption of the document. Barring loss of private key and passphrase, the exchange is fully secure.
[bilbrey@gwydion bilbrey]$ gpg --verify ch20.gpg
gpg: Warning: using insecure memory!
gpg: Signature made Thu Oct 12 21:07:34 2000 PDT using DSA key ID CFC46714
gpg: Good signature from "Brian Bilbrey (NPS) <[email protected]>"
Type man gpg at the command line for more details about configuration and usage of GnuPG. Using encryption and signing also has social and legal implications. You can't use it if the people that you correspond with don't also use it. Additionally, there is a patchwork of conflicting and strange laws that govern the use of strong encryption. Using GnuPG (or PGP) might well be illegal in your geographic location. Consult the appropriate sources, such as http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm, for more information on this topic.
There are many reasons that you might choose to use GnuPG or its non-free counterpart, PGP. These range from keeping your e-mail from casual prying eyes to protecting industrial or governmental/military data. Properly used, either of these tools meets the requirements.
GnuPG and PGP are both programs for securing data by use of public key cryptography. Public key systems make use of one or more pairs of keys, one public and the other private. The public key is freely distributed, and often published in easily accessibly key servers. The public key is a composite of two large prime numbers. A one-way trapdoor function is used with the public key to create an encrypted message or file. The private key is required to decrypt the message. As an added level of security, private keys should be protected by passphrases, to prevent them from being improperly used.
Some versions PGP and GnuPG are not completely compatible - http://www.gnupg.org/docs.html#guides has links to information on coping with the differences. GnuPG can use DSA keys generated by PGP 5.x.
Revocation certificates can be generated for keys, and expiration dates can be placed directly in the keys (both good ideas). Additionally, keys can be placed in escrow, although this is a source of controversy in the encryption community based on a lack of trust in the organizations involved. For a solid presentation on the technology and use of encryption tools, consult Applied Cryptography by Bruce Schneier (John Wiley & Sons). An excellent reference for PGP (much of which applies to GnuPG usage equally) is PGP: Pretty Good Privacy by Simson Garfinkel (O'Reilly & Associates).
PGP is fundamentally similar to GnuPG, which is entirely unsurprising, since PGP came first in a chronological sense. PGP stands for Pretty Good Privacy. Phil Zimmerman, who came under criminal investigation as a result of his work, wrote the software. It was deemed a violation of US export restrictions to produce strong cryptography. Phil's company, PGP, Inc. has since been purchased by Network Associates, which continues to market PGP and related products. PGP is free for non-commercial use; it is available from http://web.mit.edu/network/pgp.html through MIT.
Some of the recent barriers to acceptance for PGP have come down with the termination of patent protection for the main RSA algorithm, of which PGP makes heavy use. For a number of years, the international and USA internal versions of PGP were different due to the RSA patent. Although the MIT site still shows the older restrictions, and "requires" acceptance of the RSA usage and license documents, we anticipate some changes there soon. Getting the sources requires a browser that handles cookies to make it through the security maze surrounding PGP Freeware. It's not difficult, just onerous, given that the license restrictions don't exist anymore. Alternatively, you can get either the international (without RSA) or regular versions of PGP through http://www.pgpi.org/.
Warning
Not all of RSA Security's patents have expired. If you plan on using these products in a business setting, research the issue yourself. It may pay to either use GPG exclusively, or purchase PGP, to avoid potential legal entanglements. You have been warned.
There's an interesting problem with the downloaded file. If you execute the normal "tar zxvf..." command on pgpsrc658unix.tar.gz, the file appears to self-destruct as the tar command fails. This is a result of having a gzipped file in the archive of exactly the same name as the archive. Either un-tar the file from another sub directory, or gunzip the file separately. After un-tarring the archive, the resulting source archive can be un-archived normally, as shown in the following listing.
[root@gwydion src]# cp /home/bilbrey/pgpsrc658unix.tar.gz .
[root@gwydion src]# gunzip pgpsrc658unix.tar.gz
[root@gwydion src]# tar xvf pgpsrc658unix.tar
pgpsrc658unix.tar.gz
pgpsrc658unix.tar.gz.sig
[root@gwydion src]# tar zxf pgpsrc658unix.tar.gz
Once the sources are installed, change to the source directory and start the build script. This is a departure from the normal steps for compiling software. It's necessary because there are a variety of architecture-dependent features that need to be managed across several different configure scripts.
[root@gwydion src]# cd pgpsrc
[root@gwydion pgpsrc]# ./build.sh
As the build progresses, many compiler warnings are displayed on the rapidly scrolling terminal window. This is due to differences in compiler features, and is acceptable. There were no actual errors during our tests. If you have problems, then you may need to resort to the PGP technical support resources at http://www.pgp.com/. Oddly, after all the work that the build script automates, it doesn't actually put the PGP executable in a useful location. To install pgp, follow these steps:
[root@gwydion pgpsrc]# cd clients/pgp/cmdline
[root@gwydion pgpsrc]# make install
unix/config/install-sh pgp /usr/local/bin
Now PGP is ready to use. Although the commands and some of the default selections and options are different than GnuPG, familiarity with one package means a short learning curve with the other. There's a good primer on cryptography paired with a tutorial for PGP found at http://www.pgpi.org/doc/pgpintro/. A complete User's Guide can be found at http://www.pgpi.org/doc/guide/6.5/.
[bilbrey@gwydion bilbrey]$ pgp -kg
Pretty Good Privacy(tm) Version 6.5.8
(c) 1999 Network Associates Inc.
Export of this software may be restricted by the U.S. government.
Choose the public-key algorithm to use with your new key
1) DSS/DH (a.k.a. DSA/ElGamal) (default)
2) RSA
Choose 1 or 2: 1
Choose the type of key you want to generate
1) Generate a new signing key (default)
2) Generate an encryption key for an existing signing key
Choose 1 or 2: 1
Pick your DSS ``master key'' size:
1) 1024 bits- Maximum size (Recommended)
Choose 1 or enter desired number of bits: 1
Generating a 1024-bit DSS key.
You need a user ID for your public key. The desired form for this
user ID is your name, followed by your E-mail address enclosed in
<angle brackets>, if you have an E-mail address.
For example: John Q. Smith <[email protected]>
Enter a user ID for your public key: Brian Bilbrey <[email protected]>
Enter the validity period of your signing key in days from 0 - 10950
0 is forever (the default is 0): 365
You need a pass phrase to protect your DSS secret key.
Your pass phrase can be any sentence or phrase and may have many
words, spaces, punctuation, or any other printable characters.
Enter pass phrase: u5e_a/g00d&passphrase
Enter same pass phrase again: u5e_a/g00d&passphrase
PGP will generate a signing key. Do you also require an
encryption key? (Y/n) y
Pick your DH key size:
1) 1024 bits- High commercial grade, secure for many years
2) 2048 bits- "Military" grade, secure for forseeable future
3) 3072 bits- Archival grade, slow, highest security
Choose 1, 2, 3, or enter desired number of bits: 1
Enter the validity period of your encryption key in days from 0 - 365
0 is forever (the default is 365): 365
Note that key generation is a lengthy process.
PGP needs to generate some random data. This is done by measuring
the time intervals between your keystrokes. Please enter some
random text on your keyboard until the indicator reaches 100%.
Press ^D to cancel
100% of required data
Enough, thank you.
.******* ................................................................******* .
Make this the default signing key? (Y/n) y
......................******* ........................................................*******
Key generation completed.
Unlike GnuPG, which permits creation of a revocation certificate, PGP merely allows users to revoke their signatures (on keys and certificates). A key with a revoked signature is invalid and suspect. Additionally, PGP strongly recommends that keys be generated with expiration dates, even though the software defaults to "forever." Type pgp -k to get help on key management functions. Keys can be added by typing pgp -ka and viewed with pgp -kv, as illustrated in the following listing.
[bilbrey@gwydion bilbrey]$ pgp -ka Tom_Syroid.asc
Pretty Good Privacy(tm) Version 6.5.8
(c) 1999 Network Associates Inc.
Export of this software may be restricted by the U.S. government.
Looking for new keys...
DSS 2048/1024 0x717C967A 2000/04/30 Tom Syroid <[email protected]>
sig? 0x717C967A (Unknown signator, can't be checked)
keyfile contains 1 new keys. Add these keys to keyring ? (Y/n) Y
New userid: "Tom Syroid <[email protected]>".
New signature from keyID 0x717C967A on userid Tom Syroid <[email protected]>
Keyfile contains:
1 new key(s)
1 new signatures(s)
1 new user ID(s)
Summary of changes :
New userid: "Tom Syroid <[email protected]>".
New signature from keyID 0x717C967A on userid Tom Syroid <[email protected]>
Added :
1 new key(s)
1 new signatures(s)
1 new user ID(s)
[bilbrey@gwydion bilbrey]$ pgp -kv
Pretty Good Privacy(tm) Version 6.5.8
(c) 1999 Network Associates Inc.
Export of this software may be restricted by the U.S. government.
Type bits keyID Date User ID
DSS 1024/1024 0x89AD55BC 2000/10/14 expires 2001/10/14
*** DEFAULT SIGNING KEY ***
Brian Bilbrey <[email protected]>
DSS 2048/1024 0xF23950A9 2000/10/10 Brian Bilbrey <[email protected]>
DSS 2048/1024 0x717C967A 2000/04/30 Tom Syroid <[email protected]>
3 matching keys found.
Normal operations of encryption, signing, and verification can be found by typing pgp -h. The task of encrypting and signing a file is shown in the following listing:
[bilbrey@gwydion bilbrey]$ pgp -es ch20.txt Tom Brian
Pretty Good Privacy(tm) Version 6.5.8
(c) 1999 Network Associates Inc.
Export of this software may be restricted by the U.S. government.
A secret key is required to make a signature.
Recipients' public key(s) will be used to encrypt.
You need a pass phrase to unlock your secret key.
Key for user ID "Brian Bilbrey <[email protected]>"
Enter pass phrase: u5e_a/g00d&passphrase
Passphrase is good
Key for user ID: Tom Syroid <[email protected]>
1024-bit DSS key, Key ID 0x717C967A, created 2000/04/30
WARNING: Because this public key is not certified with a trusted
signature, it is not known with high confidence that this public key
actually belongs to: "Tom Syroid <[email protected]>".
Are you sure you want to use this public key (y/N)?y
Key for user ID: Brian Bilbrey <[email protected]>
1024-bit DSS key, Key ID 0xF23950A9, created 2000/10/10
Key can sign.
Key for user ID: Brian Bilbrey <[email protected]>
1024-bit DSS key, Key ID 0x89AD55BC, created 2000/10/14, expires 2001/10/14
Key can sign.
Ciphertext file: ch20.txt.pgp
Since Tom's key had not yet been formally certified, the software questions its validity. The default choice in this circumstance is to not use the public key, so we override the default and create the encrypted, signed file. Either Tom or Brian can decrypt the file using the following command:
[bilbrey@gwydion bilbrey]$ pgp ch20.txt.pgp
Pretty Good Privacy(tm) Version 6.5.8
(c) 1999 Network Associates Inc.
Export of this software may be restricted by the U.S. government.
File is encrypted. Secret key is required to read it.
Key for user ID: Brian Bilbrey <[email protected]>
1024-bit DSS key, Key ID 0xF23950A9, created 2000/10/10
Key can sign.
Key for user ID: Brian Bilbrey <[email protected]>
1024-bit DSS key, Key ID 0x89AD55BC, created 2000/10/14, expires 2001/10/14
Key can sign.
You need a pass phrase to unlock your secret key.
Enter pass phrase: u5e_a/g00d&passphrase
Good signature from user "Brian Bilbrey <[email protected]>".
Signature made 2000/10/14 03:04 GMT
Output file 'ch20.txt' already exists. Overwrite (y/N)? N
Enter new file name: test20
Plaintext filename: test20
We've looked at two different tools for encrypting and signing files. While in the most recent revisions the keys are compatible (that is, they can be imported into keyrings in both GnuPG and PGP), the tools and the files they create are not. What is encrypted and signed by PGP must be checked and decrypted by PGP. There's good news, though: It is easy to keep and both tools on your system. Now let's examine our last set of utilities: SSH and OpenSSH.
SSH is the acronym for Secure SHell, a suite of tools that provides secure login servers and clients. The company behind the product is SSH Communications Security, located online at http://www.ssh.com/about/company/index.html. SSH also incorporates such tools as scp (secure copy) and sftp (secure FTP), which both operate over encrypted SSH tunnels over any network. SSH is a commercial product that is licensed as "free for use in evaluation, educational, and non-commercial settings." This is not, however, an Open Source license. The download page, which lists a variety of sites, is http://www.ssh.com/products/ssh/download.html.
SSH is designed to replace a variety of insecure services and clients. The services telnet, ftp, rlogin, rsh, and rcp send login and password information in clear text across the network, whether private or public. This puts your information at grave risk of being "sniffed" or captured by any party between your current location and the destination host. SSH provides a secure, encrypted channel, multiple methods of authentication, and (optionally) the ability to tunnel X11 (GUI) sessions.
Downloading, compiling, and installing SSH is simple. From the download URL shown above, choose a mirror site, get the most recent release, and get a GnuPG or PGP distribution key from a different mirror (to minimize the likelihood of getting a Trojan version) or from the master FTP site at ftp.ssh.com/pub/ssh/. Then import the key and check the signature on the download.
[bilbrey@gwydion bilbrey]$ gpg --import SSH2-DISTRIBUTION-KEY-DSA.asc
gpg: Warning: using insecure memory!
gpg: key 83FB127C: public key imported
gpg: Total number processed: 1
gpg: imported: 1
[bilbrey@gwydion bilbrey]$ gpg --verify ssh-2.3.0.tar.gz.sig-gpg ssh-2.3.0.tar.gz
gpg: Warning: using insecure memory!
gpg: Signature made Fri Aug 25 00:39:14 2000 PDT using DSA key ID 83FB127C
gpg: Good signature from "Ssh 2 Distribution Key <[email protected]>"
gpg: aka "Ssh 2 Distribution Key <[email protected]>"
Could not find a valid trust path to the key. Let's see whether we
can assign some missing owner trust values.
No path leading to one of our keys found.
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
gpg: Fingerprint: A348 205D F1D8 2297 0A46 D961 ED7B 28CD 83FB 127C
While we don't actually "trust" the public key, we know that a good signature matching the key from another location is a good indicator that everything is kosher.
Now we can setup the sources, compile, and install the software following the same pattern we've used throughout this chapter.
[bilbrey@gwydion bilbrey]$ su
Password: root_password
[root@gwydion bilbrey]# cp ssh-2.3.0.tar.gz /usr/local/src
[root@gwydion bilbrey]# cd /usr/local/src
[root@gwydion src]# tar zxf ssh-2.3.0.tar.gz
[root@gwydion src]# cd ssh-2.3.0
[root@gwydion ssh-2.3.0]# ./configure
* * *
[root@gwydion ssh-2.3.0]# make
* * *
[root@gwydion ssh-2.3.0]# make install
* * *
The last step installs the following SSH components (under the /usr/local directory tree by default):
sshd2 is the SSH server.ssh2 is the SSH client, used to provide a secure remote login session.ssh-agent2 is a dynamic authentication key utility, run to provide transparent access to correctly configured remote resources.ssh-add2 is used to enter keys for ssh-agent2.ssh-keygen2 generates and manages authentication keys for ssh2.scp2 is the secure copy client (which invokes a single-use session of sftp2).sftp2 is a secure ftp client.sftp-server2 is invoked by sshd2 when an sftp request is received.ssh-probe2 broadcasts a request to the specified subnet, and listens for SSH servers to respond.Additionally, ssh-signer2 and ssh-askpass2 are installed - to the best of our knowledge other software packages execute these utilities. All of the programs are also symbolically linked to filenames without the trailing "2" for ease of use (meaning that when you type ssh, you're invoking /usr/local/bin/ssh2). For each of the programs in the prior list, there is a corresponding manual page that provides a usage reference.
Have a look at SSH server configuration file, /etc/ssh2/sshd2_config. For more information, type man sshd2_config from the command line. Some key elements in the file to pay attention to are as follows:
su to root. Change this to "no" unless you have some extraordinary need.To provide SSH services, use a text editor to add /usr/loca/sbin/sshd on a separate line to /etc/rc.d/rc.local, near the bottom of the file. It should be started before PortSentry, if you have that installed. sshd listens on TCP and UDP port 22. As root, type /usr/local/sbin/sshd to manually start the SSH server daemon. The line in rc.local starts it automatically for future reboots.
The SSH client is remarkably easy to use. Here are some examples of using ssh, scp, and sftp for remote login, secure copies, and file transfer respectively.
First, we'll login to a remote server, conveniently located in our local network. The first time you connect to a remote host, a new host key must be accepted. In ensuing sessions, the host key is compared with the one stored from this session. If it changes, dire warnings are displayed. In such scenarios you can accept the key, but it is advisable to check with the administrator for the host in question and confirm that a new host key was generated. Otherwise you might be logging onto a compromised (or different) computer.
Once the key is accepted, then enter your password. Once the password is verified, login is complete, and a command prompt from the remote system is displayed. To terminate the session, type exit.
[syroid@gwydion syroid]$ ssh gryphon.orbdesigns.com
Host key not found from database.
Key fingerprint:
xozev-feluz-funeh-lifoh-dugog-dityr-dibus-gedys-kysit-nuzos-dyxux
You can get a public key's fingerprint by running
% ssh-keygen -F publickey.pub
on the keyfile.
Are you sure you want to continue connecting (yes/no)? yes
Host key saved to /home/syroid/.ssh2/hostkeys/key_22_gryphon.orbdesigns.com.pub
host key for gryphon.orbdesigns.com, accepted by syroid Sat Oct 14 2000 19:04:12 -0700
syroid's password: a_good_password
Authentication successful.
Last login: Sat Oct 14 2000 19:04:28 -0700
No mail.
[syroid@gryphon syroid]$ ls
Desktop/ tmp/
[syroid@gryphon syroid]$ exit
logout
scp and sftp are both secure, encrypted methods of moving files from the local machine to an SSH-enabled remote host. sftp is fundamentally similar in action and behavior to FTP, so we'll leave that out. Usually, we find ourselves using scp anyway. Let's use scp to recursively copy a pair of sub-directories from Gwydion to Gryphon (host names for two of the machines on our test network):
[syroid@gwydion syroid]$ ls
Desktop ch19 ch20
[syroid@gwydion syroid]$ scp -r ch* gryphon:.
syroid@gryphon's password: a_good_password
ch19/History/4670-8 ch19.r1.doc | 235kB | 234.5 kB/s | TOC: 00:00:01 | 100%
ch19/4670-8 ch19.r3a.doc | 246kB | 245.5 kB/s | TOC: 00:00:01 | 100%
ch19/4670-8 fg1901.tif | 1.4MB | 234.7 kB/s | TOC: 00:00:06 | 100%
ch19/4670-8 fg1902.tif | 1.4MB | 234.7 kB/s | TOC: 00:00:06 | 100%
ch19/4670-8 fg1903.tif | 1.4MB | 281.6 kB/s | TOC: 00:00:05 | 100%
ch19/4670-8 ch19.r1b.doc | 244kB | 243.5 kB/s | TOC: 00:00:01 | 100%
ch19/4670-8 ch19.r2d.doc | 258kB | 258.0 kB/s | TOC: 00:00:01 | 100%
ch20/4670-8 ch20.r1c.doc | 168kB | 168.0 kB/s | TOC: 00:00:01 | 100%
ch20/~$70-8 ch20.r1c.doc | 162B | 0.2 kB/s | TOC: 00:00:01 | 100%
ch20/~WRL2474.tmp | 160kB | 159.5 kB/s | TOC: 00:00:01 | 100%
ch20/~WRL2653.tmp | 144kB | 143.5 kB/s | TOC: 00:00:01 | 100%
ch20/4670-8 ch20.r1.doc | 143kB | 142.5 kB/s | TOC: 00:00:01 | 100%
ch20/4670-8 ch20.r1b.doc | 142kB | 142.0 kB/s | TOC: 00:00:01 | 100%
[syroid@gwydion syroid]$ ssh gryphon
syroid's password: a_good_password
Authentication successful.
Last login: Sat Oct 14 2000 19:10:51 -0700
No mail.
[syroid@gryphon syroid]$ ls
Desktop/ ch19/ ch20/ tmp/
[syroid@gryphon syroid]$ exit
We cheated a bit in that one - Gryphon is in the local /etc/hosts file, as both gryphon.orbdesigns.com and gryphon. So either usage works. In using scp, the -r tells the command to copy the objects recursively, which applies only to directories. The display as each file is copied is dynamic. Observe that the copy speeds are fairly low for a 10-Megabit Ethernet connection. This is due to the encryption overheads. While encryption can be disabled once authentication is completed, that rather defeats the purpose.
Reference Info
The most complete reference we found for Secure Shell is the SSH Frequently Asked Questions (FAQ) at http://www.employees.org/~satch/ssh/faq/ssh-faq.html. Also, using authentication keys in conjunction with ssh-agent is quite useful, but not well documented. There's a marvelous tongue-in-cheek introduction to the use of SSH keys located at http://www.rescomp.berkeley.edu/about/HOWTO/SSH-Keys-HOWTO/SSH-Keys-HOWTO.html.
There is an Internet Engineering Task Force (IETF) draft standard for the secure shell protocol. In order to "graduate" to RFC status, there needs to be other implementations of the protocol. Now let's have a look at OpenSSH, the GPL implementation of SSH.
The home page of the OpenSSH project Point can be found at: http://www.openssh.com/. There is some critical information for using OpenSSH here, especially in the FAQ at http://www.openssh.com/faq.html. This document describes the implementation of secure shell and compatibility issues with the commercial SSH product. Explicitly, sftp and sftp-server are not part of the draft standard and work is in progress to reverse-engineer that functionality. Additionally, OpenSSH can have difficulty working with the leftover configuration files from a prior installation of SSH. Read the FAQ for more details.
OpenSSH was written for OpenBSD, then ported to other operating systems including Linux. The download and information location is http://www.openssh.com/portable.html. Select the openssh-version.tar.gz version that best matches your system architecture and download the file. Then follow the link to the "Installation instructions," which takes you to http://www.openssh.com/install.html. Print these out or keep the page open and handy since building and installing OpenSSH is a bit more convoluted than SSH due to requirements for third-party packages that are not included with OpenLinux.
Aside from the OpenSSH sources, the instructions say that Zlib and OpenSSL are needed for operation. While Red Hat RPMS are mentioned, we have run into occasional problems installing the RPMS from a different distribution under OpenLinux, and for greatest compatibility recommend that installing from scratch. Get Zlib from ftp://ftp.freesoftware.com/pub/infozip/zlib/zlib.html (note that this is an HTML page on an FTP site). Then go to http://www.openssl.org/source/ and get the latest release there (the correct version is marked with "[LATEST]" in bright red).
To begin the process, first uninstall SSH (skip this step if you don't have SSH installed on your system):
[syroid@gwydion syroid]$ su
Password: a_root_password
[root@gwydion syroid]# cd /usr/local/src/ssh-2.3.0
[root@gwydion ssh-2.3.0]# make uninstall
* * *
[root@gwydion ssh-2.3.0]# ps ax | grep sshd
932 ? S 0:00 /usr/sbin/sshd
1484 pts/0 S 0:00 grep sshd
[root@gwydion ssh-2.3.0]# kill -9 932
Although the uninstall purports to work as advertised, we had to remove the ssh*, scp*, and sftp* binaries from our system (located in the /usr/bin, /usr/sbin and /usr/local/bin directories, respectively) manually, then restart a new login session before we could use OpenSSH.
Running the output of the ps command through a grep filter and searching for "sshd" shows that the sshd daemon is still running. You can leave it running for the time being, if necessary. Later, you'll want to terminate the process (demonstrated with the kill command) and restart using the new OpenSSH version. The next step is to copy the sources to /usr/local/src, and extract them from their respective archives.
[root@gwydion src]# cp /home/syroid/zlib.tar.gz .
[root@gwydion src]# tar zxf zlib.tar.gz
[root@gwydion src]# cp /home/syroid/openssl-0.9.6.tar.gz .
[root@gwydion src]# tar zxf openssl-0.9.6.tar.gz
[root@gwydion src]# cp /home/syroid/openssh-2.2.0p1.tar.gz .
[root@gwydion src]# tar zxf openssh-2.2.0p1.tar.gz
Since OpenSSH requires Zlib and OpenSSL, these need to be built and installed first. Start with Zlib, which is a lossless compression/decompression library that doesn't use any patent-encumbered algorithms. The README file in the zlib-1.1.3/ directory describes the compilation and installation process, and refers us to the top of the Makefile for additional input. There's nothing special about the process, but the make test step is new; it provides a way of verifying that the compile worked properly before installation. So the steps for Zlib are as follows:
Note
When working with images, there are two types of compression: lossless and lossy. Lossy compression means that exact data replication is sacrificed in order to achieve greater compression ratios. For data files, lossless compression is important. When you compress, then decompress a file that contains the Magna Carta, for instance, you want it to say the exact same thing after as before.
[root@gwydion zlib-1.1.3]# ./configure
* * *
[root@gwydion zlib-1.1.3]# make test
* * *
[root@gwydion zlib-1.1.3]# make install
* * *
Next is OpenSSL, an Open Source implementation of the Secure Sockets Layer (thus SSL), Transport Layer Security, and a general-purpose cryptography library. Change to the OpenSSL source directory, read the README and INSTALL files, then get to work.
[root@gwydion zlib-1.1.3]# cd ../openssl-0.9.6
[root@gwydion openssl-0.9.6]# less README
OpenSSL 0.9.6 24 Sep 2000
* * *
[root@gwydion openssl-0.9.6]# less INSTALL
INSTALLATION ON THE UNIX PLATFORM
---------------------------------
* * *
In configuring OpenSSL, we'll leave out the RC5 and IDEA cipher algorithms, since these are patented by RSA and Ascom, respectively. If they must be used, then you may need to make licensing arrangements with the firms in question. Once configuration is done, then make, test, and install the library. If errors appear, there are troubleshooting instructions in the INSTALL file. By the way, the make step takes long enough to get a cup of coffee and catch a little football on the tube - several minutes, at least, depending on your system.
[root@gwydion openssl-0.9.6]# ./config no-rc5 no-idea
* * *
[root@gwydion openssl-0.9.6]# make
* * *
[root@gwydion openssl-0.9.6]# make test
* * *
[root@gwydion openssl-0.9.6]# make install
* * *
Once that's done, OpenSSH itself is a snap:
[root@gwydion openssl-0.9.6]# cd ../openssh-2.2.0p1
[root@gwydion openssh-2.2.0p1]# ./configure
* * *
[root@gwydion openssh-2.2.0p1]# make
* * *
[root@gwydion openssh-2.2.0p1]# make install
* * *
With OpenSSH is installed, you can easily login to remote hosts exactly as you would with commercial SSH. Configuring and setting up the sshd server is identical to the process used for SSH. However, using scp requires that SSH1 compatibility be compiled and configured into the SSH2 server, or that the remote machine also be running an OpenSSH server.
[syroid@gwydion syroid]$ ssh gryphon
The authenticity of host 'gryphon.orbdesigns.com' can't be established.
DSA key fingerprint is 2f:cc:d5:c0:e6:f4:7c:74:cc:99:8c:29:50:92:5a:6a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gryphon.orbdesigns.com,192.168.0.9' (DSA) to the list of known hosts.
[email protected]'s password: a_good_password
Last login: Sun Oct 15 2000 11:21:39 -0700
No mail.
[syroid@gryphon syroid]$ ls
Desktop/ a_new_file ch19/ ch20/ tmp/
[syroid@gryphon syroid]$ rm a_new_file
rm: remove `a_new_file'? y
[syroid@gryphon syroid]$ exit
logout
For connections going the other direction - from an SSH2 client to an OpenSSH server - login sessions also work fine. However, scp2 fails in this direction as well. The incompatibility might be addressed in an upcoming version. OpenSSH is fully compatible with SSH1 for both ssh and scp operations.
Either SSH or OpenSSH can meet your needs if login sessions are your only requirement. Evaluate the hosts that you are working with to determine compatibility issues. If you are using SSH in a commercial environment, then licensing fees are required.
There are many different products and solutions for adding security and privacy capabilities to OpenLinux. These are rapidly evolving fields, and what works today to keep the bad guys out needs to be updated or replaced as new exploits and vulnerabilities are discovered. Here, we presented seven tools for covering some of these bases, with overlapping capabilities and differing licenses. This chapter covered the following points:
sftp functionality is reserved for a future release.Go to the Table Of Contents