Вы находитесь на странице: 1из 46

© SANS Institute 2000 - 2002, Author retains full rights.

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Securing a

Debian Linux Laptop

for

Road Warriors

By Stephanie Thomas

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

for SANS GCUX Certification Version 1.6b, Option 1 April 4, 2001

1

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Table of Contents

Introduction

Assessing

the

Risks

Choosing

the

Right Laptop

BIOS Power On Password

BIOS Supervisor Password

Hard Drive Password

Security Screw for the Hard Drive

Hardware Locks

Debian Operating System Installation

First Thing's First - Partitioning the Hard Drive

Installing the Operating System and Device Driver Modules, Base System

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Configuration

Selecting Packages to Install

Kernel

Securing Network Services

Securing LILO

Setting Password and Login Policies

NTP

Logging

Remote System Administration, File Access (Copy and Transfer) and E-mail

Installation

Setting up the Secure Shell daemon to Start on Boot

Authentication

Setting up Local Tunnels for E-mail

Tightening up Access to Secure Shell

Email and File Confidentiality

'Defensive' Security Measures

TCP Wrappers

Packet Firewall - IPChains

Psionic Portsentry

Tripwire

Updating using apt-get

Backup, Backup, Backup

'Offensive' Security Measures

Nmap

Tiger, Tara, SATAN, SAINT, Sara, and Nessus

Password Cracking Programs

User Education Passwords Hardware Protection Backups

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Other Good Practices

Conclusion

2

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

4

4

5

5

5

6

6

6

6

7

7

7

8

8

10

10

12

13

14

14

15

15

16

17

18

18

18

18

19

19

19

20

21

22

22

23

23

23

23

24

24

24

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Checklist - Securing a Debian Linux Laptop for Road Warriors

25

Appendix

A

29

Appendix

B

32

Appendix

C

45

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

3

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Introduction

For as long as mobile computers have been around, System Administrators have had to

wrestle with the problems of securing them. Having a portable computer, while

immensely advantageous to the user, can present some unique and challenging security

vulnerabilities to the System Administrator.

their computers are exposed to a hostile network. To ensure productivity, remote users

must be able to securely access email and files stored within the company's internal

network. In addition, laptops are easy to steal - there have been numerous cases of laptop

Department

http://www.cnn.com/2000/US/04/17/state.computer.02/

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

All of these demonstrate how vulnerable a laptop containing corporate information can be

- and how very important it is that every available step is taken to protect the data that

these computers contain. While no computer can be completely secure, System

Administrators need to employ all security measures possible - from hardware locks,

BIOS power on, hard drive and supervisor passwords, to properly hardening the

operating system - to ensure that these 'Road Warrior' laptops are not only protected

themselves - but that they do not expose the entire company's network by providing

attackers with valuable information with which to conduct an attack - See:

http://www.zdnet.com/zdnn/stories/news/0,4586,2648861,00.html

theft

Many laptop users work remotely where

at

the

U.S.

State

within

the

past

year

:

Defining the Role of the Computer

Defining the role of the computer will help you to determine what the risks are, as well as

how to limit those risks.

This guide will focus on securing a business laptop with the role of primary workstation

for a user who either works from home or travels and requires remote file and email

access. The laptop will have the latest version of the Debian operating system installed,

which is based on the Linux kernel.

Assessing the Risks

As the user will be working remotely, connection to the company's network will be

essential. The manner in which the user connects to the internet can have an affect on the

level of risk - but each will cause some level of exposure. Each administrator will need

to evaluate the specific situation they face and take the appropriate steps to address the

risks associated with that scenario. access methods.

Following are some of the most common remote

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

The most common access method for remote users is through a ppp, or dial-up modem

connection. Regardless what the user's most frequently used remote access method is, as

4

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

an administrator, you will almost certainly have to provide some sort of dial-up access to the user at one point or another. Even a home DSL user may travel to a customer's site or a conference where they only have modem access from their hotel room. Take steps to secure this type of connection even if it will not be the user's primary remote access method.

DSL and high-speed cable internet providers are becoming very popular access methods.

The access is fast, and the cost is reasonable. These advantages also work in favor of the

hackers - fast, cheap access means more break-in attempts in less time. Cable and DSL

services are known to be popular with the hacker community - see

http://www.zdnet.com/zdnn/stories/news/0,4586,2604170,00.html. In addition, providers

have not always been very responsive to administrators' requests for assistance when

tracking hackers down (same article).

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

ISDN can also provide fast access, but the cost is prohibitive and setup is less than

intuitive. ISDN's popularity has dwindled with the advent of DSL and high-speed cable

internet access.

Some other methods which are gaining ground are Ricochet, which offers wireless

modem access at speeds of up to 128K, and wireless LAN.

Most of these can be made more secure through the use of IPChains or some form of

VPN.

In addition to network access issues, the portability of laptop computers makes them very

easy to steal. Physical security is often very difficult to achieve on something designed

to be easy to carry, but there are measures that System Administrators can take to address

this concern.

Choosing the Right Laptop

When deciding which laptop computer to provide for your remote users, you should look

for the following features:

BIOS Power On Password

Most computers have a BIOS power on password. Although on the majority of

computers this password is easy enough to circumvent, it should still be set to help

prevent the merely curious from gaining access to the computer's data. You should not be able to boot the computer without entering this password. Both the user and the system administrator should have this password.

BIOS Supervisor Password

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

5

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

This password protects the BIOS settings itself, which will help prevent changing of the boot order to enable booting from other media. You may also be able to disable floppy and CDROM access altogether. No one should be able to gain access to the BIOS without entering this password. On some laptops, the security provided by this password

cannot be circumvented by resetting the BIOS or pulling the CMOS battery - if you

forget the password, you must replace the system board to access the BIOS. Take Care

when assigning this password! Only the administrator should have this password.

Hard Drive Password

Some laptop computers also offer an additional password restricting access to the hard

drive itself. This password must be entered before the computer can be booted from the

hard drive. It should not be possible to circumvent the security provided by this

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

password - if you forget the password, you should have to replace the hard drive. This is

probably the single most important of the computer's hardware protections - even if

someone steals the laptop, they should not be able to gain access to the data stored on the

hard drive through conventional means - i.e., even moving the hard drive to a different

computer will not provide access to the data stored on the hard drive. Take Care when

assigning this password! Both the user and the system administrator should have this

password.

Security Screw for the Hard Drive

On some laptops, where there is easy external removal of the hard drive, manufacturers

often offer a special security screw to replace the stock, easy-to -remove coin screw. This

will help make removal of the hard drive much more difficult if someone gains physical

access to the laptop. This screw has a key which should be held by the administrator.

Hardware Locks

Make sure that the laptop has a provision for a hardware lock of some type. Especially

helpful are hardware locks which have motion sensors to detect excessive movement of

the computer. The user and the SystemAdministrator should both have a copy of the key

or know the combination to the hardware lock.

Dell and IBM both offer all of these types of protection in their laptop lines. I was not

able to confirm Toshiba's security offerings.

Debian Operating System Installation

Now that you've selected your hardware, its time to install Debian. version of Debian from the ftp site -ftp://ftp.us.debian.org/debian/

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Installation should be done while not connected to the network.

Obtain the latest

6

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

One important point to consider before starting is disk encryption. This web site http://munitions.polkaroo.net/dolphin.cgi?action=render&category=0503 offers many options for disk encryption. While disk encryption is a good idea, many of the current

implementations do not seem stable enough for real-time deployment. It may be better to

encourage the user to encrypt their data files using GPG or PGP until this technology has

come of age.

First Thing's First - Partitioning the Hard Drive

The proper way to partition a Unix or Linux system is a heated debate. I found so many

conflicting opinions on this subject when researching this paper that I am reluctant to

recommend any one method exclusively. Use your best judgment on this, taking into

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

account the role of the system and the user's needs. Whatever you decide to do, be sure

to document the partition table you set up.

Installing the Operating System and Device Driver Modules, Base System Configuration

Most of the defaults will do for this section of the installation.

NTFS, MSDOS or Samba filesystem support, you can do so under the filesystem device

If you wish to enable

driver module.

You will also be asked to set the hostname of the computer, install and configure the base

system (setting the time zone and hardware clock), and to make Linux bootable (install

LILO). After these selections are complete, the system will reboot. Upon reboot, you

will be asked if you would like to enable MD5 passwords and install shadow passwords.

Answer yes to both of these - they help to secure your user password database by using a

stronger encryption algorithm and locating the passwords in a root-only accessible file.

Next, you will be prompted to set the root password and create a user account. You will

want to create a user account for the end user of the system, as well as an account for the

system administrator.

Selecting Packages to Install

There are literally thousands of applications that come with the Debian operating system.

Some of the important security-related packages already come installed by default - TCP

Wrappers, lprng, and lsof, to name a few. While it is often recommended to not install a

development environment to limit exposure, many of the programs which the user will

need to be productive are open-source, and may not come in binary format. If you have a duplicate environment available on which to compile the programs the user will need, you can set the laptop up without a development environment, and copy over binaries

compiled on the other machine. If this is not feasible, you can remove the development

libraries and compilers after the system is configured. Following are the recommended

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

7

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

packages to remove or install that have security concerns related to this specific scenario - you will need to evaluate other packages as necessary for your environment and the user's specific needs:

REMOVE:

telnet & telnetd - Secure Shell will be used for remote access

finger & fingerd - numerous known security vulnerabilities

nfs-common & nfs-server - numerous known security vulnerabilities

talk & talkd - not necessary, known security vulnerabilities

ftpd - unnecessary, this system will not function as a file server, numerous known

security vulnerabilities

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

ADD:

acct - GNU accounting utilities for login and process accounting

sudo - enable users to execute a command as another user

syslog-ng - provides advanced system logging, adding features that syslogd doesn't

support (configurability, filtering based on content, message integrity/encryption, etc.)

logcheck - looks for anomalies in the system logs and emails them to the administrator

ampd - improved power management for laptops

makepasswd - used to generate true random passwords using /dev/random. Can also

encrypt plaintext passwords given on the command line

The ftp client must be installed to enable use of the Debian operating system update

module, apt-get.

Kernel

Because Debian is a complete operating system, the release cycle takes a bit longer than

other standard Linux distributions. As a result, the kernel in the latest Debian release

may be a bit outdated. The current release at the time of writing, 2.2r2 - code named

'potato' (all of the Debian releases are named after 'Toy Story' characters), uses the

2.2.18pre21 kernel. To obtain the latest kernel-level security fixes, you will want to

compile the latest kernel after installing Debian. Be sure to backup your kernel before

recompiling. See Section 8.5 at http://www.debian.org/releases/potato/i386/ch-post-

install.en.html for information on doing this 'the Debian way'. Also see

http://www.fs.tum.de/~bunk/kernel-24.html for information on running the 2.4 kernel

with the latest release of Debian.

Securing Network Services

The first step after installation will be to secure the network services. Nmap is used here

to scan for open ports, but there are numerous other utilities available for this.

See

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

8

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Appendix A for a listing of other security tools. Here is a list of the open ports reported by nmap after an installation as described above:

# nmap -sT -sU 127.0.0.1

Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )

Interesting ports on testsystem (127.0.0.1):

(The 3067 ports scanned but not shown below are in state: closed)

Port

9/tcp

9/udp

State

open

open

Service

discard

discard

daytime

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

open

13/tcp

open

98/tcp

111/tcp

open

113/tcp

143/tcp

177/udp

512/tcp

513/tcp

514/tcp

515/tcp

1024/tcp open

open

open

open

open

37/tcp

open

open

111/udp

open

open

open

time

linuxconf

sunrpc

sunrpc

auth

imap2

xdmcp

exec

login

shell

printer

kdm

Nmap run completed -- 1 IP address (1 host up) scanned in 3 seconds

To dis able unnecessary services, start with inetd. The configuration file for inetd is

located in /etc/inetd.conf . None of the services started in inetd by default are needed for

this setup. To disable inetd, you can either comment out the /etc/inetd.conf, or comment

out, rename or remove the /etc/init.d/inetd script that is called by the /etc/rc#.d runlevel

scripts. In addition, you will want to entirely comment out or remove the portmap script

in /etc/init.d .

After disabling inetd and commenting out or deleting the portmap script, nmap should

only report the following open ports:

#

nmap -sT -sU 127.0.0.1

Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ ) Interesting ports on testsystem (127.0.0.1):

(The 3078 ports scanned but not shown below are in state: closed)

Port

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

State

Service

9

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

177/udp

open

xdmcp

515/tcp

open

printer

1024/tcp

open

kdm

6000/tcp

open

X11

Nmap run completed -- 1 IP address (1 host up) scanned in 3 seconds

Delete the Berkeley 'r' services and rpc utilities entirely - these services have numerous

know security vulnerabilities and will not be used.

# cd /usr/local/bin

# rm rcp rgrep rjoe rlogin rpcgen rpcclient rsh rstart rstartd rpcinfo

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Set the default login to be text only, not X, using linuxconf.

Securing LILO

Next you will want to password - protect LILO, the Linux Loader. This can be done

either by manually editing the /etc/lilo.conf or from linuxconf. If doing this by manually

editing the /etc/lilo.conf file, you will want to add the following lines after the prompt

line:

password = <your_password_here>

restricted

Be sure to set the permiss ions for the /etc/lilo.conf file to 0600 since the password will be

saved in clear-text.

chmod 0600 /etc/lilo.conf

Setting Password and Login Policies

You will want to specify some basic password and login policies - such as setting a login

banner message, logging all su logins, minimum password length, minimum non-alpha

characters in the password, and setting up the maximum number of days a password can

be used to login. Again, this can be done either manually at the command line, or from

linuxconf. If you prefer doing this from the command line, here is how you go about

doing so:

First, create an /etc/issue file to display a message before login.

usually best, but this is determined by your company's security policy :

Something simple is

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

"Employees of XYZ Corporation only. Unauthorized access prohibited. All connection

attempts are logged."

10

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Next, edit the /etc/login.defs file:

# vi /etc/login.defs

The /etc/login.defs file has several options which can be tweaked to provide extra

protection - here are a few recommended settings:

SULOG_FILE

ISSUE_FILE

UMASK

PASS_MAX_DAYS

PASS_MIN_LEN

/var/log/sulog

/etc/issue

077

60

6

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

PASS_WARN_DAYS

5

There are other ways to implement password expiry - passwd and chage can also be used.

passwd -x 60 -w 5 username

#

OR

#

chage -M 60 -W 5 username

These commands will expire the password for username after 60 days, giving a warning

for 5 days prior to expiration.

To generate strong passwords, use the makepasswd program installed to generate true

If you specify a -minchars of 8, the

random passwords for the user, admin, and root.

password will be at least 8characters:

makepasswd -minchars 8

#

x8xit5Hk

You will also want to remove unnecessary accounts created during installation. Again,

this can be done from linuxconf or from the command line by using the userdel

command. Do a sanity check first and see if the user owns any files:

#

find / -user username_or_ID -print

To remove a user, use the userdel command:

# userdel -r username

The -r option will remove all files in the user's home directory.

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Some user candidates for this are games, majordomo, www-data, gnats, operator, list, irc,

© SANS Institute 2000 - 2002

11

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

uucp, proxy, msql, alias, and possibly news.

Next, you will want to set login access controls on the remaining users. This is done in the /etc/security/access.conf file. I couldn't possibly write a better explanation of how to

configure the file than was already in the file itself, so here's an excerpt of the top of the

file:

#Format of the login access control table is three fields separated by a

# ":" character:

#

#

#

#

permission : users : origins

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

The first field should be a "+" (access granted) or "-" (access denied)

# character.

#

#

#

#

#

#

#

#

#

#

# character).

The second field should be a list of one or more login names, group

names, or ALL (always matches). A pattern of the form user@host is

matched when the login name matches the "user" part, and when the

"host" part matches the local machine name.

The third field should be a list of one or more tty names (for

non-networked logins), host names, domain names (begin with "."), host

addresses, internet network numbers (end with "."), ALL (always

matches) or LOCAL (matches any string that does not contain a "."

Here are examples of restrictions recommended for this file:

This will disable all logins to the console except by the admin and root:

-:ALL EXCEPT admin root :console

Disable remote root logins:

-:root:ALL EXCEPT LOCAL

NTP

NTP, network time protocol, is required to ensure that accurate time is kept on the

system. Why is this SO important? Well, simply put, forensics. If your logs are out of time sync with the server's logs, it will be difficult if not impossible to prosecute in the event of a compromise. In addition, many important security software, such as Kerberos

and most certificate authorities, depend on accurate time. You want to ensure that you

are running an NTP server internally at your network, and you will want to make

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

12

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

provisions for laptop users to use the NTP client to sync their clocks with yours. This web site http://www.eecis.udel.edu/~ntp/ntp_spool/html/build.htm has a very good

tutorial on how to do a basic setup of NTP. It is outside the scope of this guide to discuss how you would set up NTP within your organization. If you would like to read more

about security and NTP, see RFC1305: ftp://sunsite.doc.ic.ac.uk/rfc/rfc1305.txt , section

3.6.

To

http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/

install

NTP

on

the

laptop,

obtain

the

source

code

Compilation is the standard:

$ ./configure

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

$ make

# make install

from:

And you will want to configure your /etc/ntp.conf file as follows:

server IP_of_1st_ntp_server

server IP_of_2nd_ntp_server

server IP_of_3rd_ntp_server

driftfile /etc/ntp.drift

restrict default nomodify

Generally speaking, you will want to have more than one server listed for redundancy.

Logging

Logging is essential to security administration. Logs are one of the most important

places where you will find the trail of clues,should you ever find your system the victim

of an attack, needed to determine the method of attack. Logs can also be used as evidence

if you are able to prosecute.

When choosing to setup syslog-ng at installation-time, Debian very nicely sets up

logging and log rotation for you. You will simply want to review the settings and ensure

that they are as desired for your environment, and add your email address to the syslog-

ng logrotate script.

syslog -ng is configured by default with all the settings that you should need, including defaults to log kern, err, and warn messages. You can also specify filters using syslog-ng.

See the man page for syslog-ng for more information on this. The configuration file for

syslog -ng is /etc/syslog -ng/syslog -ng.conf

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

13

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

logrotate is also already setup, including cron jobs to run it daily and weekly - located, appropriately enough, in /etc/cron.daily and /etc/cron.weekly . You may need to edit these to also rotate the sulog. Add the administrator's email address to the top of the

/etc/logrotate.d/syslog-ng as follows:

mail admin@xyz.corp.com

errors admin@xyz.corp.com

This will email admin@xyz.corp.com with the compressed log files, as well as any

errors. It is also recommend that you set up a log server within your company's network,

if you haven't done so already, and have the laptop log to that. Another good idea is to

scan your logs using a program like Psionic's Logcheck - which checks your logs for

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

anomalies and will email you with alerts. This can help to reduce the amount of data that

you will need to sift through, but will require an initial time investment to tweak the

settings to reduce false alarms. There are many other log scanners that you can use. See

Appendix A for a list of security tools.

Remote System Administration, File Access (Copy and Transfer) and E-mail using

Secure Shell

Since the system will be operated remotely for at least part of the time (hence the need

for a laptop in the first place), you will want to be able to securely administer the machine

from a remote location. Secure Shell accomplishes this nicely, as well as having other

useful features, such as scp, sftp (for remote file copy and transfer) and tunneling (which

will be used to provide the user with secure remote email access).

Installation

You can obtain Secure Shell in source code from ftp://ftp.ssh.com/pub/ssh. Secure Shell

is free for use under a non-commercial license under Linux, NetBSD, FreeBSD, and

OpenBSD. Secure Shell 2.4 is the latest version. SSH1 has been officially deprecated

due to fundamental security vulnerabilities, and its use is not recommended. See

http://www.ssh.com/products/ssh/cert/ and http://www.cert.org/ for information about

these vulnerabilities.

You will need to have Secure Shell installed on both the laptop and on an internal server

which allows connections from outside your network.

your firewall to allow Secure Shell connections from your remote users.

Remember to open port 22 on

It is recommend to set up Secure Shell to support TCP Wrappers at a minimum (--with- libwrap). Even though Secure Shell offers user and host restrictions in the server

configuration file, it is easier to have a central place from which to administer user and

host restrictions. You can also take advantage of TCP Wrappers' advanced logging

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

14

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

features.

On the internal Secure Shell server, you may want to chroot users to restrict shell and sftp access. This decision (and how you go about setting this up) depends on your network

security policies, and also whether the users need access only to their own files, or if they

need to share files with other users. Keep in mind that as of version 2.4, chrooting for

Secure Sh ell is only supported on Linux, AIX and Tru64, and is known to not work on

Solaris or HP-UX. The operating system of your server will be a deciding factor in this

decision. A chrooted environment can be established only if static builds can be made,

when no shared libraries are used. See Appendix B for more information on setting up

chrooting with Secure Shell.

See the README that comes with the distribution for complete installation instructions,

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

as well as the online administrator's guide and Appendix B.

Setting up the Secure Shell daemon to Start on Boot

As an administrator, you want the Secure Shell daemon to start at boot time so that you

can connect to it if you need to do any remote system administration. Secure Shell comes

with a startup script, sshd2.startup, for SYS-V style operating systems (it was specifically

written for Linux). This should work fine for the Debian laptop, but you may need to edit

this for the company's internal Secure Shell server, depending on the operating system.

For the laptop, to start the Secure Shell daemon at boot time, copy the sshd2.startup script

(should be in the source directory after installation) into the /etc/init.d directory. Create

symbolic links to the sshd2.startup script in the /etc/rc#.d directories to start (S#) or stop

(K#) the sshd2 daemon. The # designates the order that the scripts in the rc#.d directories

are started - the higher the number, the later in the boot (or shutdown) process the script

is run. For example:

#

ln -s /etc/init.d/sshd2.startup /etc/rc#.d/K90sshd2

for /etc/rc1.d and /etc/rc6.d and

#

ln -s /etc/init.d/sshd2.startup /etc/rc#.d/S90sshd2

for /etc/rc2.d, /etc/rc3.d, /etc/rc4.d, and /etc/rc5.d

will setup the Secure Shell daemon, sshd2, to start and stop properly on boot and reboot

on a Debian system.

Authentication

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Secure Shell is configured to use password authentication by default. Unless your

company already uses a different method for authentication such as PAM, Kerberos or

15

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

RSA SecurID, the recommendation is public key authentication for both the administrator connecting to the laptop to administer the computer, and for the user authentication to the company's Secure Shell server for remote email and file access.

Setting up public key authentication is fairly simple. Do this in one direction first, then in

the other, to avoid confusion. See Appendix B for information on which authentication

methods are supported, and Appendix C for instructions on setting up public key

authentication in Secure Shell.

Setting up Local Tunnels for E-mail

Secure Shell has the ability to tunnel TCP ports through the secure connection, to the

destination application server specified. This is a very useful feature, and is what will be

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

used to secure the user's email on the laptop. You will want to set up local tunnels from

the client machine for port 25 for smtp, and port 110 for pop or 143 for imap. Local

tunnels 'push' connections from the local port specified, through the Secure Shell server,

to the application server on the port specified. Keep in mind that while the connection

between the Secure Shell client and Secure Shell server is secure, the connection between

the Secure Shell server and the application server is not secured.

accordingly.

Plan your network

Since the ports used for email are privileged ports (25, 143, and 110), the user must start

ssh as root, or they will not have adequate permission to forward the ports. You can

setup tunnels from the command line:

#

ssh2 -L 4025:smtp_server:25 user_name@ssh_server

but the best way to setup tunnels for repeated use such as for email is through the config

file - /etc/ssh2/ssh2_config:

# Tunnels that are set up upon logging in

LocalForward

LocalForward

"25:smtp.xyz.corp.com:25"

"143:imap.xyz.corp.com:143"

Note that the arguments must be enclosed in double quotes ""

Once the tunnels are setup in the config file, the user will still have to execute ssh2 as

root in order to access email, but the command is much shorter:

# ssh2 user_name@ssh_server

Next setup the mail client to point to 127.0.0.1 for smtp and imap servers. Secure Shell

will capture the connections to ports 25 and 143 and forward the connections to the smtp

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

16

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

and imap servers at XYZ Corp.

Tightening up Access to Secure Shell

There are many restrictions you can set in the server config file to limit access to Secure

Shell on both the server and on the laptop. Following are the recommendations for the

laptop /etc/ssh2/sshd2_config file:

MaxConnections

2

This will limit the number of connections to the sshd2 daemon to 2. As only the

administrator should be connecting to the laptop, this is more than sufficient. The default

on this is unlimited.

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

RekeyIntervalSeconds

3600

This tells the server to re-exchange and verify hostkeys after the specified number of

seconds. This provides an extra level of security against hijacking Secure Shell sessions

and man-in-the-middle attacks - but be careful with this one! If the client you are using

to connect does not support re-keying, you will be disconnected after the specified

number of seconds. By default this is commented out, but if your Secure Shell clients

support re-keying, it is a good idea to enable this.

PermitEmptyPasswords

no

This will prevent users with NULL passwords from connecting. This is commented out

by default.

BannerMessageFile

/etc/issue.net

This displays the /etc/issue.net banner before login. This is commented out by default.

AllowedAuthentications

publickey,password

This specifies the authentication methods allowed when connecting to the sshd2 daemon.

PermitRootLogin

no

This prevents direct root logins, which will require the administrator to su for root access when connecting via Secure Shell. This is set to yes by default.

AllowUsers

admin, user

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

This will allow in only users admin and user, and will deny login via Secure Shell to

© SANS Institute 2000 - 2002

17

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

everyone else.

Email and File Confidentiality

The best way for your users to retain email and file confidentiality is through the use of

GPG or PGP for encryption. Many programs, such as StarOffice by Sun Microsystems

(used to write this guide), offer pgp plug-ins for encryption of files and emails.

StarOffice does require Java to be installed before the pgp plug-in will work. Make sure

your users keep a backup copy of both their public and private keyrings. Encourage

through policy and education the use of GPG or PGP by your users.

'Defensive' Security Measures

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Defensive Security measures refers to using available software and good system

administration practices to protect the system from attackers attempting to gain access

and from copying, altering, or deleting important data.

TCP Wrappers

TCP Wrappers enables you to set access controls on network services with the use of two

files - /etc/hosts.deny and /etc/hosts.allow .

TCP Wrappers also has some very nice

logging features. Because we have already disabled all network services except for

Secure Shell, and compiled Secure Shell with TCP Wrappers support, your

/etc/hosts.deny and /etc/hosts.allow files should look like this:

/etc/hosts.deny

ALL:ALL

/etc/hosts.allow

sshd2:.xyz.corp.com

sshdfwd-X11:.xyz.corp.com

This denies access to everyone, then allows access only to those specified in the

/etc/hosts.allow - anyone from the xyz.corp.com domain, in this case.

Packet Firewall - IPChains

Configuring a packet firewall on this machine is essential to keeping out intruders. This

will be the primary defense for this laptop when it is connected remotely. The Linux ipchains How-To is located here: http://www.linu x.org/docs/ldp/howto/IPCHAINS- HOWTO.html . This goes into nauseating detail on how to install and configure ipchains, as well as having several example configurations. An alternative example script

which is best suited to this scenario is the one in the "Securing Linux Step -by -Step" guide

available from www.sans.org, in Appendix D. This script is very well commented,

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

18

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

enabling ease of administration.

Psionic Portsentry

Portsentry is used to detect port scans, and can take configurable action on the scanning

host. You can do all kinds of fun things with Portsentry - such as automatically adding

any scanning host to /etc/hosts.deny, , displaying a banner message to the scanning host,

executing a command directed at the $TARGET$ host, or simply dropping, denying, or

killing the route to the scanning host. This last is the recommended course of action.

Since we've already added ALL:ALL to the /etc/hosts.deny, it is not necessary to add

every scanning host to that file, and executing a command or issuing a warning banner on

a scan attempt can taunt a hostile scanning host, and cause retaliatory action.

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Here is the line you'll want to uncomment in your portsentry.conf:

KILL_ROUTE="/sbin/ipchains -I input -s

Tripwire

$TARGET$ -j DENY -l"

Tripwire is used to detect changes in files. When you initialize Tripwire, it builds a

database of the files on your hard drive. If any of those files is changed, and Tripwire is

run again, you will receive a notice that the file has changed. This is helpful to detect

changed binaries - for example, if your ls command has been substituted with a trojaned

version, Tripwire will detect this. Tripwire also detects permission changes on files.

Tripwire should be the last software you install before turning the system over to the user.

You will want to make sure there is a backup of the Tripwire database on non-changeable

media such as CD-R. Every time an update is applied to the system, you will want to

rebuild the Tripwire database.

You build your Tripwire Database like this (from the directory where Tripwire is

installed):

#

./tripwire --initialize

Change the permissions on some files, and perhaps copy a binary from a different

machine over to this one (rename the original first, of course), then run Tripwire:

# ./tripwire

Tripwire will report all the changes made since the last database was created.

Updating using apt-get

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

apt -get is the Debian answer to obtaining the lat est updates for your system.

© SANS Institute 2000 - 2002

19

As part of GIAC practical repository.

Apt -get is

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

configured in the /etc/apt/apt.conf file. Apt-get uses /etc/apt/sources.list to list locations where updates are obtained. The following web site has a list of 'unofficial' sources, in

addition

http://www.internatif.org/bortzmeyer/debian/apt-sources/

Take care using these sites - they are not sanctioned by Debian and you may want to

ensure that you can trust the sources before installing any software obtained from these

sites.

to

the

'official'

Debian

ones pre-configured:

You can configure apt-get using apt-setup. apt-setup will ask you for sources to add to

the /etc/apt/sources.list .

The first thing to do when running apt -get is to resynchronize the package overview files:

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

# apt-get -update

Next, you'll want to upgrade to the updated packages:

# apt-get -upgrade

If you only want to upgrade a specific package:

#

apt-get -install package_name

If you want to automate this (recommended), write a simple shell script for apt-get -

update and apt-get -upgrade and place both of these scripts in /etc/cron.daily or

/etc/cron.weekly, depending on how often you would like to update. Weekly should be

sufficient for most applications.

You will also want to ensure that whoever the administrator for the laptop, they are

subscribed to the security lists for Debian. You can find information about Debian and

security at the following address:

very good security digest you can subscribe to where you can chose which operating

system flavor you would like to receive security updates on (for Debian chose Linux):

http://www.sans.org/sansnews

SANS also has a

http://www.debian.org/security

.

Backup, Backup, Backup

I personally experienced the immense value of backups AGAIN while working on this

document. StarOffice crashed on me (emulating M$ Office a little too well there :), and

when I reopened the document, it was corrupted. I would have lost the entire thirty-four page document if not for a backup that was made the previous day. Even with daily backups, however, I lost all the changes that had been done that day. I was not a happy

camper. Imagine you user's state of mind if they lose weeks or months of work because

they do not have a current backup. Don't wait for that frantic call before instituting a

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

20

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

backup policy. Another benefit is the ability, through backups, to determine exactly how and when a compromise took place.

How you go about doing backups on this laptop will vary greatly depending on your

user's habits. If your user is in the office most of the time, and only occasionally on the

road, you are probably safe using a networked backup method. Legato and HP-

Openview both offer a free Linux backup client if your company already has the server

software, although it is not supported by either company. If your user is mostly on the

road, however, your backup method will get a bit more complicated. Your user's method

of connecting to the internet can also play a part here - you do not want to send the

backups of your user's home directory over a modem connection to a file server inside

your company network, but if your user connects using DSL, this is a valid option.

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Other options here are external tape drives, CD-R drives, and perhaps even a backup

server at the user's home if the user usually works from home. Some laptops have the

ability to add a second hard drive to the system. This is a very good way to maintain a

mirror of the main hard drive should anything happen. If choosing a method which

involves any type of transmission over a network, ensure that the connection is secured.

Also make sure that the method is automated, through cron jobs usually, preferably in

such a manner as to not interfere with the user's regular schedule.

You will want to do a full backup of the system after all installations and configurations

are done, before turning over the laptop to the user, and again after any major system

updates, as well as on a monthly schedule. Incremental backups are recommended on a

daily basis. Make sure that you also test your backup schedule and the backups

themselves by restoring them before turning the laptop over to the user.

tar (short for tape archive) is the most common method of compressing and archiving

data. This command will backup and compress the user's home directory:

#

tar czf /tmp/home_user.tgz /home/user_name

This file can then be copied to some other media or to a server on the company's network.

Because it was created in the /tmp directory, it will be removed upon shutdown, thus not

using up needed hard drive space.

See http://www.debian.org/doc/manuals/system-administrator/ch-sysadmin-backup.html

for more information.

'Offensive' Security Measures

'Offensive' security measures means taking steps which will help you to assess the

system's vulnerabilities before an attacker does.

the hackers use - such as nmap, as used above, to determine which ports are open, tiger,

This includes applying the same tools

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

21

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

tara or sara, nessus, and password cracking programs.

sanity check on your security measures, and may catch some things you've missed. In general, you will want to install these tools on a different machine, and run them against laptop.xyz.corp.com for a better idea of the true vulnerabilities on the system.

This type of testing is a good

Nmap

Nmap is a port scanner. Nmap supports many different types of scans, TCP, UDP, TCP

SYN (half open), proxy, ICMP, as well as many others. Nmap is be used to conduct

scans on the target system to determine which attack on which ports may be viable. In

the section earlier on Securing Network Services, there are two examples of nmap scans

against the test Debian system.

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Nmap's syntax is very easy to understand. To run a scan on all TCP and UDP ports, you

would issue the following command as root:

#

nmap -sT -sU laptop.xyz.corp.com

See man nmap for more information.

Tiger, Tara, SATAN, SAINT, Sara, and Nessus

There is no shortage of vulnerability scanners to choose from. Understanding the

relationships between them can help you choose which would best suit your environment.

There are links to all of the scanners mentioned here in Appendix A.

Tiger is a program which checks for basic security problems on a Unix system. Tara is

an updated version of Tiger.

SATAN is another software designed to probe for security vulnerabilities. SATAN has

not been updated in some time, which limits it's ability to effectively test for current

threats. SAINT is an expansion on the SATAN project. The original author of SAINT

now works for ARC, and the result is a new vulnerability scanner called Sara, an

evolution of the SATAN and SAINT projects.

Out of all of the vulnerability scanners reviewed, the one which was easiest to use and

easiest to keep up -to -date was Nessus. Nessus functions in client / server mode, and has

a GTK interface, for ease of use and administration. Each of the security tests in Nessus

are designed as plug-ins, which enables you to write your own security checks if desired,

and which enables easy updating of Nessus. When checking the plug-ins page at www.nessus.org, ten plug-ins were added between March 25 th and April 2 nd - demonstrating that the software is under current, active development. Most interesting of

all, however, was that while the software was free of charge to any users, the developers

also offer professional, commercial support for the product - immensely valuable if you

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

22

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

plan to roll this out across your entire network. The commercial support even includes twenty-four custom plug-ins per year, and minor customizations to the software, if desired.

Password Cracking Programs

Password cracking programs are a good idea if you do not use the makepasswd utility to

generate random passwords. This can help ensure that the passwords that are chosen are

not easily broken. Keep in mind that any password can be cracked eventually - your goal

here should be to weed out the EASILY cracked passwords.

Some of the most common password cracking programs are crack, John the Ripper, and

Nutcracker. In general, the larger the dictionary, the better the chances are of cracking

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

the password. http://www.password-crackers.com/crack.html In addition, if you

implement PAM on the system, you can use the password strength checking module

listed here: http://www.openwall.com/passwdqc/

User Education

User education is probably the single most important thing you can do to protect this

system.

security is needed, what the policies are, and what they c an do to limit exposure. As this

is a laptop, and will be operated remotely, your user will be on their own for a portion of

their time - without anyone around to verify that they are actually using that Kensington

lock you provided. The single greatest point of failure of any security policy is personnel

- get yours on your side through education. Most users will cooperate if they understand

how important these measures are, and why they must take the time to enter several

passwords to boot the computer.

Securing any machine is useless unless you educate the end user on why the

Some topics to be sure to cover with your users:

Passwords

Why passwords are important

Why you need multiple passwords

Why all your passwords should NOT be the same

What make good and bad passwords

How to choose a good password (or why to use one generated with makepasswd)

Password management (for a single user, the best method for this might be a PGP

encrypted text file, saved on removable media, not the hard drive)

Hardware Protection

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Impress how vulnerable laptop computers are to theft

© SANS Institute 2000 - 2002

23

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Show the user how to enter the BIOS Poweron and Hard drive Passwords Show the user how to use the hardware locks provided Advise the user to remove, if possible, removable media drives before traveling

Backups

Explain why backups are so necessary, both to protect data and as forensic evidence

Explain what they can do to ease backup administration (save user files only in a specific

directory, notify the administrator if an update is applied so that a full backup can be

made, etc)

Backup before installing any major software packages or updates

Why not to cancel the regularly scheduled backups

If

with

administrator

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

goes

wrong

something

the scheduled

backups, notify

the

immediately

Other Good Practices

Don't leave your laptop logged on without setting a screen saver password AND using

the hardware lock

Don't circumvent any of the established security practices

Have the user review RFC2504 - http://www.faqs.org/rfcs/rfc2504.html

Make sure the user has a copy of your laptop security policy, and make sure you have a

signed copy from them showing that they understand the policy, and agree to comply

with the terms.

Conclusion

While perfect laptop security can never be achieved, there are steps which can be taken to

minimize the risks faced when connecting to the internet, as well as those faced when

using a portable, easy-to-steal computer. These steps include disabling unused services,

setting login and password policies, and employing strategies to help defend against

attacks, as well as using the hacker's own tools to do a vulnerability assessment. The

single most important part of any security plan, however, is user education. Explain to

your users the threats, and what they can do to help. This can help turn your single most

dangerous security

asset.

risk

into

an

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

24

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Checklist - Securing a Debian Linux Laptop for Road Warriors

Laptop prepared for Laptop prepared by

Date

Choosing the Right Laptop

Laptop chosen supports the following:

BIOS poweron password

BIOS supervisor password

Hard drive password

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Security screw for hard drive if drive is externally removable

Hardware lock - Kennsington-type or motion-sensitive (preferred)

IMPORTANT - make sure that all of the above passwords and locks are set and

used!

Laptop Manufacturer

Laptop Model Number

Laptop Serial Number

Operating System Installation

Make sure laptop is not connected to the network during installation

Document partition scheme:

Run the following commands and report the output here:

# fdisk /dev/hda

Using /dev/hda as default device!

Command (m for help): p

Enable MD5 passwords

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Install shadow passwords

Set root password

25

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Create user and admin accounts

Package Selection

Remove the following packages:

telnet & telnetd - Secure Shell will be used for remote access by admin only

finger & fingerd - numerous known security vulnerabilities

nfs-common & nfs-server - numerous known security vulnerabilities

talk & talkd - not necessary, known security vulnerabilities

ftpd - unnecessary, numerous known security vulnerabilities

Add the following packages:

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

acct - GNU accounting utilities for login and process accounting

sudo - enable users to execute a command as another user

syslog-ng - provides advanced system logging

logcheck - looks for anomalies in the system logs and emails them to admin

ampd - improved power management for laptops

makepasswd - used to generate true random passwords using /dev/random

You will most likely have to add other packages as necessary depending on the user's

needs. If the applications that come with the distribution are not the latest version, obtain

and install the latest versions. Document the applications added and the version numbers

here:

Kernel

If the latest version of Debian uses an outdated kernel, backup your kernel, obtain the latest kernel and recompile. Document the kernel version here:

Disabling Network Services

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Disable inetd (either from linuxconf or by commenting out /etc/inetd.conf)

© SANS Institute 2000 - 2002

26

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Disable /etc/init.d/portmap script by commenting out Set default boot mode to text (startx from the command prompt to start Xwindow) Remove the following binaries entirely from /usr/bin: rcp rgrep rjoe rlogin rpcgen rpcclient rsh rstart rstartd rpcinfo

LILO

Password protect LILO by editing the /etc/lilo.conf or from linuxconf

Chmod /etc/lilo.conf to 0600

Password and Login Policies

Set up banner message to display for all logins

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Edit the /etc/login.defs file to enable the following (these are recommended settings - set

these as appropriate for your environment):

/var/log/sulog

SULOG_FILE

ISSUE_FILE

UMASK

PASS_MAX_DAYS

PASS_MIN_LEN

PASS_WARN_DAYS

Or set password to expire using passwd or chage - document max days here

Remove unnecessary users from the system

Edit /etc/security/access.conf to restrict all root logins except from LOCAL and

/etc/issue

077

60

6

5

console logins except from root or admin

NTP

Install and configure ntp client to connect to an internal ntp server

Logging

Review syslog-ng settings and logrotate settings, add email address to

/etc/logrotate.d/syslog-ng (if any changes are made to settings, attach a document

detailing the changes to this checklist)

Remote System Administration, File Access (Copy and Transfer) and Email using

Secure Shell

Install Secure Shell Configure sshd2 to startup on boot Set up public key authentication

Configure Local tunnels in /etc/ssh2/ssh2_config

Tighten up access to the Secure Shell daemon in /etc/ssh2/sshd2_config

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

27

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Email and File Confidentiality

Install and configure pgp - encourage users to use it for file and email encryption

If using StarOffice, install pgp plug-in

'Defensive' Security Measures

Install TCP Wrappers

configure /etc/hosts.deny for ALL:ALL

configure /etc/hosts.allow for sshd2 and sshdfwd-X11 for the internal domain only

Configure IPChains as a packet firewall to filter outbound and inbound traffic.

Attach a copy of the script used to this document

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Install PortSentry

configure PortSentry to kill the route to scanning hosts

Install Tripwire LAST

Build a tripwire database

Store Tripwire database on non-changeable media

Configure apt-get for updating Debian

Setup apt-get to run weekly from a cron job

Subscribe to Debian Security Lists and SANS Security Digests

Develop and deploy a backup plan. Attach a copy of the backup plan to this

document.

'Offensive' Security Measures

Run nmap against the laptop. Turn off any remaining unnecessary services.

Run one or more vulnerability scanners against the laptop. Review the results and

correct any open issues. Rerun the scanner. Review the results again to ensure all

vulnerabilities were addressed.

Run a password cracking program against the /etc/shadow file. If any passwords

were recovered, regenerate the password using makepasswd and rerun the password

cracking program.

User Education

Educate the user on why security policies are in place, and what the security

policies are, and what they can do to minimize exposure.

Have the user sign the security policy, demonstrating understanding and

acceptance

Your Signature, attesting to having completed the

steps listed above

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Date

28

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Appendix A

The Missing Link(s)

Log Checkers / Scanners

Log Scanner

ftp://logscanner.tradeservices.com/pub/logscanner/

Logsurfer

http://www.cert.dfn.de/eng/logsurf/

Logstats

http://www.cise.ufl.edu/~jfh/jst/

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Swatch

http://www.stanford.edu/~atkins/swatch/

WOTS

http://www.tony-curtis.cwc.net/tools/

Psionic Logcheck

http://www.psionic.com/

Port Scanners / Scan Detectors

Psionic PortSentry

http://www.psionic.com/

Nmap

http://www.insecure.org/nmap/

Astaro

http://www.astaro.com

Iplog

http://ojnk.sourceforge.net/

Scan Detect

http://sdetect.sourceforge.net/

Security Scanners

BASS

http://www.securityfocus.com/data/tools/network/bass-1.0.7.tar.gz

Nessus

http://www.nessus.org/index.html

SAINT

http://www.wwdsi.com/saint/

Sara

http://www-arc.com/sara/index.shtml

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

SATAN

http://www.porcupine.org/satan/

29

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Tara

http://www-arc.com/tara/

Firewall / VPN Solutions

FireDog

http://northernlightsgroup.hypermart.net/firewalls.htm

RCF

http://rcf.mvlan.net/

Astaro

http://www.astaro.com/products/index.html

FreeSWAN Linux (IPSec)

http://www.freeswan.org/

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Password Utilities

Automated Password Generator

http://www.adel.nursat.kz/apg/

John the Ripper

http://www.openwall.com/john/

Npasswd

http://www.utexas.edu/cc/unix/software/npasswd/

Nutcracker

http://northernlightsgroup.hypermart.net/nutcracker.html

PAM module for checking passwords

http://www.openwall.com/passwdqc/

Password Cracking Library

http://www.password-crackers.com/pcl.html

List of Password Cracking Software

(sorted by application which you want to crack)

http://www.password-crackers.com/crack.html

Another List of Password Cracking Software

(not sorted by application you would like to crack)

http://neworder.box.sk/box.php3?gfx=neworder&prj=neworder&key=pwdcrax&txt=Pass

word

Debian Linux Sites

Home Page

http://www.debian.org/

Support

http://www.debian.org/support

Installation for Intel x86

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

http://www.debian.org/releases/stable/i386/install.en.html#contents

© SANS Institute 2000 - 2002

30

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Compiling a new Kernel

http://www.debian.org/releases/stable/i386/ch-post-install.en.html#s-kernel-baking

Reporting Bugs http://www.debian.org/Bugs/ Unofficial APT Sources

http://www.internatif.org/bortzmeyer/debian/apt-sources/

Other Interesting Tools and Security Related Sites

SANS

http://www.sans.org

Automatic Security

http://www.automaticsecurityunderlinux.com/

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Bastille (Redhat focused, but maybe they'll get to Debian soon)

http://bastille-linux.sourceforge.net/

Linux Tools for Toshiba Laptops

http://www.buzzard.org.uk/toshiba/

Practical Unix Security in a Networked Environment

http://www.shmoo.com/wp/pract/

Secure Communication with GnuPG on Linux

http://linux.com/sysadmin/newsitem.phtml?sid=113&aid=11408

LILO Security Tips

http://linux.com/security/newsitem.phtml?sid=11&aid=8252

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

31

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Appendix B

SSH2 Quick Setup Reference Guide

Updated March 28, 2001

Table of Contents

1.

2.

3.

4. Installation

About this Document

About Secure Shell

Licensing Questions Answered

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

5.

6.

7.

8. Configuration

9.

Setup for Special Circumstances

File Names and Locations

Authentication Methods

Why NOT to use SSH1 and SSH1 Compatibility

10. Troubleshooting

11. Where to find help

1.

About this Document

This document is designed to assist administrators by explaining some of the uses and

possibilities of SSH Secure Shell, by giving the sequence in which options should be

configured, and by providing a reference for where to find additional information.

This document provides background information and gives links to specific instructions

which are available on the web. This document will not reinvent the wheel: where

information is already available from the Administrator's Guide, you will be linked to the

online Administrator's Guide. This is mostly for administrative purposes: updating

multiple sources with the same information is tedious and error prone, and because online

sources can be updated and edited in a much more timely fashion, enabling us to ensure

that you get the most correct and up-to-date information possible.

Although this document may reference Windows versions of the software, it is intended

as a guide only for Unix and Linux operating systems.

2.

About Secure Shell

From http://www.ssh.com/products/ssh/ :

"SSH Secure Shell is the de facto standard for remote logins, with an estimated three

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

million users in 80 countries. It solves the most important security problem on the Internet: hackers stealing passwords. Typical applications include remote system

32

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

administration, file transfers, and access to corporate resources over the Internet.

SSH Secure Shell is intended as a complete replacement for ftp, telnet, rlogin, rsh, and

rcp. It has additional functionality that Berkeley Services don't include: file transfer, X11

forwarding, and TCP/IP port forwarding.

SSH Secure Shell is based on the SSH2 protocol. The secsh protocol is currently

standardized by IETF and the standards process is in draft stage. You can find the current

versions of the drafts at http://www.ietf.org/ID.html "

3. Licensing Questions Answered

So, you've read the license that comes with SSH Secure Shell, and you are confused: can

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

you legally use SSH Secure Shell? Are you required to purchase a license?

The Required Caveat: This is a summary and simplification of the license terms intended

to help explain them; please see the actual license file for the legal, binding terms and

conditions. This information is provided as a courtesy and is not intended to replace the

LICENSE file that comes with the distribution. This information specifically does NOT

apply to SSH Secure Shell for Windows Servers.

SSH Communications Security classifies licenses in two categories: commercial and non-

commercial (which includes personal use and educational use).

Commercial licenses cover using the software in a business environment, usually for

work for which you will be paid (educational institution employees excepted from this

definition).

Non-commercial licenses cover those using the software for home or personal use, or as

an agent or user of any educational institution.

There are also two versions of the software: commercial and non-commercial. The main

differences in the code include text labels to enable identification of which version is

being used, some license checks for the Windows software, and additional binaries

available for the commercial software which are not distributed freely.

SSH Communications Security does not require payment for non-commercial licenses.

Use of SSH Secure Shell on Linux, NetBSD, OpenBSD, and FreeBSD operating systems is available under a non-commercial license.

IMPORTANT: Please be aware that although SSH Communications Security will gladly

accept bug reports and feature requests, support for installation and configuration is not

provided if you are using the non-commercial license. See section 10 for information on

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

33

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

where to obtain assistance with the non-commercial software.

4. Installation

If you are using the non-commercial version of the software, you have the choice of

source for Unix / Linux, while binaries are available for Redhat, SuSe, and Windows

client software.

Installation Instructions:

Installation

Administrators Guide.

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

SSH Secure Shell for Unix Servers Administrator's Guide

http://www.ssh.com/products/ssh/administrator24

instructions are well documented

in

the SSH Secure Shell for Unix

Please see this location for standard installation instructions for both binaries and source

code.

Following are the standard source code installation instructions.

After unpacking the source code, change to the source directory and do the following:

$ ./configure

$ make

# make install

5.

Setup for Special Circumstances

There are some specific functionality or compatibility options which are not available

through a standard install, and all of them require you to compile the source code. You

can type ./configure --help from the source directory to list all options available at

compile time. This section gives the configure options for the most common special

setup situations. This section is intended to provide a starting point for compilation -

once compiled, please see the Administrator's Guide for full instructions on setting up

these features.

a) Chroot functionality for sftp

b) Kerberos support

c) PAM support

d) RSA SecurID support

e) TCP Wrappers support

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

a) Setting up chroot functionality for sftp:

© SANS Institute 2000 - 2002

34

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

IMPORTANT !!! PLEASE NOTE: This feature is only supported on Linux, AIX and Tru64, and is known to not work on Solaris or HP-UX. A chrooted environment can be established only if static builds can be made as then no shared libraries are used.

$ ./configure --enable-static

$ make

# make install

There are additional steps that must be taken to complete the set up. Please see the

online Secure Shell for Unix Servers Administrator's Guide at (the URL was split into

two lines for typographical purposes):

http://www.ssh.com/products/ssh/administrator24/Using_Chroot_Manager ssh-

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

chrootmgr html

b)

To set up Secure Shell with Kerberos support:

You must already have Kerberos setup on the machine prior to compiling Secure Shell

with Kerberos support. Secure Shell will detect if you have Kerberos5 installed. If for

some reason Kerberos5 is not found, you can specify the location as follows:

$ ./configure --with-kerberos5=[KRB_PREFIX]

$ make

# make install

There are additional steps that must be taken to complete the setup. Please see the online

Secure Shell for Unix Servers Administrator's Guide at:

http://www.ssh.com/products/ssh/administrator24/Kerberos_Authentication.html

c)

To set up Secure Shell with PAM support:

No special options are required during the compile to enable PAM support, but this

feature is not available from binaries. A standard install will work (from the ssh source

directory):

$ ./configure

$ make

# make install

There are additional steps that must be taken to complete the setup. Please see the online Secure Shell for Unix Servers Administrator's Guide at (the URL was split into two lines for typographical purposes):

http://www.ssh.com/products/ssh/administrator24/Pluggable_Authentication_Modules

PAM

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

html

35

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

d) To set up Secure Shell with RSA SecurID support:

From the ssh source directory:

$

$ make

# make install

./configure --with-serversecurid=/PATH --with-clientsecurid

Replace /PATH with the absolute PATH to the directory containing the

following files:

sdclient.a

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

sdacmvls.h

sdconf.h

sdi_authd.h

sdi_size.h

sdi_type.h

sdi_defs.h

The above files are normally in /top/ace/examples

Note: If you do not want to make the compilation as root, make sure that all the above

files are readable.

There are additional steps that must be taken to complete the setup. Please see the online

Secure

http://www.ssh.com/products/ssh/administrator24/SecurID.html

Unix

at:

Shell

for

Servers

Administrator's

Guide

To enable TCP Wrappers support within Secure Shell:

$ ./configure --with-libwrap=/path/to/libwrap.a

$ make

# make install

The typical approach is to set up /etc/hosts.deny to refuse everyone, and /etc/hosts.allow

to only allow in trusted hosts as follows:

/etc/hosts.deny

ALL:ALL

/etc/hosts.allow

sshd2:.ssh.com foo.bar.fi

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

sshdfwd-X11:.ssh.com foo.bar.fi

36

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Secure Shell will now use these files to filter access. Based on the files above, users coming from any host in the ssh.com domain or from the host foo.bar.fi are allowed access, while anyone else is denied access. See the documentation for TCP Wrappers for

more information on the /etc/hosts.allow and /etc/hosts.deny files and their format.

6.

Secure Shell File Names and Locations

The server configuration

sshd2_config .

file

is

located

in

the /etc/ssh2 directory and

is

named

The server binary is located in the /usr/local/sbin directory and is named sshd2 .

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

The system client configuration file is located in the /etc/ssh2 directory and is named

ssh2_config .

The client binaries are located in the /usr/local/bin directory and consist of the following

files: ssh2, scp2, sftp2, sftp-server2, ssh-add2, ssh-agent2, [ssh-askpass2], ssh-chrootmgr,

ssh-keygen2, [ssh-pam-client], ssh-probe2, ssh-pubkeymgr, ssh-signer2

[The bracketed files exist only in some configurations.]

The optional user-specific configuration file is located in the $HOME/.ssh2 directory,

and is named ssh2_config

Each system's own host keypair is located in the /etc/ssh2 directory, and consists of the

following files: hostkey, hostkey.pub

When each user connects to a server for the first time, they are asked if they would like to

accept the server's public host key. These keys are stored in the $HOME/.ssh2/hostkeys

directory. The user will have a separate key for each machine they have connected to.

Please see the appropriate man pages for more information on each of the binaries and

Files which are specific to authentication are discussed in the

configuration files.

Secure

http://www.ssh.com/products/ssh/administrator24/ under the setup instructions for the

authentication.

Shell

for

Unix

Servers

Administrator's

Guide:

7.

Authentication Methods

Secure Shell has many different authentication methods. The choice of which authentication method(s) to use depends on your environment, your network's setup, and sometimes, what you are trying to accomplish with Secure Shell.

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Following are brief descriptions of the different authentication methods supported by

© SANS Institute 2000 - 2002

37

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Secure Shell. For setup instructions on each of these, please see the online Secure Shell

for

http://www.ssh.com/products/ssh/administrator24/

:

Unix

Servers

Administrator's

Guide

at

Password

Password authentication is the default authentication method, and is already setup when

Secure Shell is installed. Password authentication can use either the /etc/passwd file or

the /etc/shadow file. This authentication method almost always requires user interaction.

User Public Key

User Public Key authentication must be setup on a per-user basis. Each user generates a

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

public keypair, copies the public key of the keypair over to the server to their ~/.ssh2

directory on the server, and then may need to edit the /etc/ssh2/ssh2_config file on the

client to add publickey to the AllowedAuthentications line. The system administrator of

the server may also need to edit the /etc/ssh2/sshd2_config file. An identification file on

the client, and an authorization file on the server also need to be created. Once that is

done, each user authenticates to the server by providing the passphrase they selected

when generating the keypair. Users can also use ssh-agent2 and ssh-add2 to store their

identities in memory so that they do not have to repeatedly type their passphrase. When

ssh-agent2 and ssh-add2 are used, public key authentication can be used for non-

interactive logins if the identities are already stored in the ssh-agent2.

Hostbased Authentication

Hostbased authentication uses the client machine's public hostkey to authenticate the user

to the server. Hostbased authentication requires copying the client's hostkey over to the

server, editing both the client's /etc/ssh2/ssh2_config and the server's /etc/sshd2_config,

Hostbased

authentication, once set up, can be completely n on -interactive - this is the easiest

and creating a .shosts file in the user's home directory on the server.

authentication method to use for scripting and automation of tasks (such as backups run

through cron jobs).

PAM

Pluggable Authentication Module support has been added to Secure Shell for Unix as of

version 2.4.

RADIUS, can also be used with Secure Shell via plug-ins for PAM. Setting up PAM requires compiling the source code, some edits to the Secure Shell server and client config files, and edits to the PAM config file.

PAM support means that many other forms of authentication, such as

Kerberos

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

38

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Kerberos authentication is also available for Secure Shell. Setup may require compiling the source code and changing the Secure Shell server and client config files. Kerberos is mainly used in educational institutions.

RSA SecurID

RSA SecurID support was added to Secure Shell as of version 2.4. SecurID support will

require compiling the source code, as well as various other setup procedures. SecurID

support adds a strong One-Time-Password authentication method to Secure Shell.

8. Configuration

The purpose of this section is to explain some of the options available for configuring

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Secure Shell to suit your environment. For specific instructions on how to set up some of

these options, please see the online Secure Shell for Unix Servers Administrator's Guide

at:

http://www.ssh.com/products/ssh/administrator24/

You can also check the man pages for the config files, man ssh2_config and man

sshd2_config, as well as the man pages on the commands themselves for further

information.

Client and Server Configuration Options

The following options are available in both the client config file,

/etc/ssh2/ssh2_config, and in the server config file, /etc/ssh2/sshd2_config.

AllowedAuthentications

This option is used to specify which authentication method(s) you would like to allow.

Order is important here - the methods are attempted in the order in which they are listed.

Please see the man page for the config file for descriptions of the values permitted.

Ciphers

Ciphers is where the cipher can be specified that you would like to use to encrypt the

connection.

permitted.

Please see the man page for the config file for descriptions of the values

MACs

MACs is where you can specify the message authentication code used. Please see the man page for the config file for descriptions of the values permitted.

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Server Only Configuration Options

© SANS Institute 2000 - 2002

39

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

The following options are only available in the server config file, /etc/ssh2/sshd2_config.

RequiredAuthentications

RequiredAuthentications defines which authentication methods are required before a

connection is permitted. This works in conjunction with AllowedAuthentications. Please

see the man page for the config file for descriptions of the values permitted.

AllowGroups, AllowHosts, AllowShosts, AllowUsers, DenyGroups, DenyHosts,

DenyShosts, DenyUsers, AllowTcpForwarding, AllowTcpForwardingForUsers,

AllowTcpForwardingForGroups, DenyTcpForwarding, DenyTcpForwardingForUsers,

DenyTcpForwardingForGroups

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

These can all be used to filter access to the sshd2 daemon and to filter TCP forwarding

access in a fashion similar to TCP Wrappers. Please see the man page for the config file

for descriptions of the values permitted.

BannerMessageFile

BannerMessageFile specifies the path to the message sent to the client before

authentication. The default is /etc/ssh2/ssh_banner_message , but you can change this to

/etc/issue or /etc/issue.net if you already have that set up.

PermitRootLogin

PermitRootLogin is where you can chose to accept or deny remote root logins to Secure

Shell. You can also chose nopwd, which means that only a user who has set up non-

password authentication (such as hostbased or public key) between their username (user

or root) on the client, and root on the server can login.

9. Why NOT to use SSH1 and SSH1 Compatibility

SSH Communications Security officially deprecated the SSH1 software as of January

2001 due to various security issues with the software and protocol.

From http://www.ssh.com/products/ssh/cert/deprecation.html :

"SSH Communications Security considers the SSH1 protocol deprecated and does not recommend the use of it.

As of 1 May 2001, SSH Secure Shell 1.x will no longer be available from this site. Please

modify your product plans accordingly. The SSH2 protocol is in the process of becoming

an IETF standard and is not subject to the security

vulnerabilities found in SSH1.

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

40

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Therefore, we will continue to focus on the newer SSH2 protocol as we offer, update, upgrade and maintain SSH Secure Shell 2.x (and higher) of the software. If you have any questions, please contact your SSH representative. "

Other sites which contain information related to the security problems with SSH1 :

http://www.ssh.com/products/ssh/cert/

http://www.cert.org/ (simply type ssh or ssh1 in the search there)

http://www.sans.org

10. Troubleshooting

Troubleshooting procedures vary depending on what type of problem you are attempting

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

to resolve. The most common problems are broken down into the following categories:

Installation

Configuration

Connection / Authentication

File Copy and Transfer Issues

For almost all troubleshooting (installation excepted, of course), your first step should be

to start the server in verbose mode, then try connect with the client running in verbose

mode. T his will give you more information on what is happening before you continue

with resolving the problem. Redirect the output of both commands to a text file for later

viewing.

Client:

$ ssh2 -v server_name > ssh2_output 2>&1

Server:

# kill -9 `cat /var/run/sshd2_22.pid`

# sshd2 -v > sshd2_output 2>&1

Note that the sshd2 daemon will only accept one connection when running in verbose

mode, then will die and must be restarted.

Installation

When troubleshooting installation problems, you will need to check the following:

DO YOU HAVE THE LATEST VERSION OF SECURE SHELL? Often we find that many people having installation problems have an older copy of the software and

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

are running into issues that have been resolved in the latest version of Secure Shell.

Please check ftp://ftp.ssh.com/pub/ssh for the latest version number and ensure that

41

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

you are using it.

Are your platform and operating system supported?

If

http://www.ssh.com/products/ssh/portability.html to help answer these questions.

Are you

corresponding installation instructions?

Have you checked the README for installation instructions for source code or

the

See

installing

via source code, are you

via binary

using

the correct

compiler?

installing

or source code?

Are you

following

binaries?

installation instructions.

See http://www.ssh.com/products/ssh/administrator24/

for

complete

Are you having trouble getting a specific option to compile in? Have you

checked ./configure --help for more information on which compile-time options

are available and their format?

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Some options are only available via source code - have you checked to ensure that

the option you are trying to use is available with your chosen installation method?

Check the online Secure Shell for Unix Servers Administrator's

Guide at:

http://www.ssh.com/products/ssh/administrator24/

Configuration

If the configuration you are attempting to setup requires special installation-time

instructions, are you sure they were completed? If installed via source code,

check the source directory for the config.status to see what options were enabled

at compile-time.

Have you checked the config file on the server, /etc/ssh2/sshd2_config and the

system-wide config file on the client, /etc/ssh2/ssh2_config, as well as any user-

specific client config files, which are located in the user's home directory,

~/.ssh2/ssh2_config to ensure that all config files have the option you are trying to

configure enabled (if appropriate)? Try man sshd2_config and man ssh2_config

for a very good description of what each option in the config files does.

If you made changes to the server config file, /etc/ssh2/sshd2_config, did you

HUP the sshd2 daemon?

Have you walked back through the configuration steps to ensure that they were all

completed?

Connection / Authentication

Have you started the client and server in verbose mode and reviewed the output?

This is the best way to discover what is causing Connection / Authentication

problems.

Check the client and server config files to ensure that the authentication method you are attempting is enabled.

Did you compile Secure Shell with support for TCP Wrappers? If so, did you

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

verify that your client is listed in the server's/etc/hosts.allow? Was Secure Shell compiled with support for PAM? Check your PAM config file.

42

© SANS Institute 2000 - 2002

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

If the authentication you are attempting involves copying keys over to the server, verify that the keys were not modified during the copying by checking the fingerprints of both keys. They should match. See man ssh-keygen2 for more information.

If you are trying to setup hostbased authentication, and the setup looks correct, but you

still are being prompted for a password - check your DNS.

incorrectly setup DNS is why hostbased authentication fails if the setup was done

Nine times out of ten an

correctly. If you are u nsure if this is the problem, and the verbose output is not helpful,

you may want to run the client and server in a higher debug level by using a command

line option: -d 5 or -d 7 should be sufficient.

File Copy / Transfer Issues

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

If ssh2 works but scp2 or sftp2 is failing, you may want to check your PATH. Make sure

that /usr/local/bin is in the path for the user trying to copy files over. If the problem is

sftp2 and you do not wish to add /usr/local/bin to the PATH, then you can edit the

/etc/ssh2/sshd2_config file on the server to add the full path to the sftp-server at the

bottom. So,

subsystem-sftp

should change to

subsystem-sftp

sftp-server

/usr/local/bin/sftp-server

Remember to HUP the daemon after changing the config file.

11.

Where to Find Help with Secure Shell

While the software is free to use, and non -commercial users of Secure Shell are welcome

to submit bug reports and feature requests, non-commercial users are not entitled to

support from SSH Communications Security. The good news is that Secure Shell has

been around since 1995, and there are many users in the open-source community who are

already very familiar with Secure Shell, and many web sites containing information about

Secure Shell.

Web resources for all users:

Cryptography A-Z http://www.ssh.com/tech/crypto/ SSH Secure Shell for Unix Servers Administrator's Guide:

http://www.ssh.com/products/ssh/administrator24/

IETF secsh drafts:

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

43

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

http://www.ssh.com/tech/archive/secsh.html List of Supported Platforms for SSH Secure Shell:

http://www.ipsec.com/products/ssh/portability.html FTP site for non-commercial downloads:

ftp://ftp.ssh.com/pub/ssh

Note: the following three links are for submissions only - you will not receive a response

to emails sent using these forms.

Compilation Success / Failure Reports:

http://www.ssh.com/tech/ssh_query.html/

Bug Reports:

http://www.ssh.com/support/toolkits/bug-report.html

Feature Requests:

http://www.ssh.com/support/toolkits/feature-request.html

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

Non-SSH Communications Security web sites

There are numerous web sites out there about Secure Shell, but many of them are SSH1

specific. Here are a few that are SSH2 or both:

Archives of the old Secure Shell public mailing list (ssh@clinet.fi):

http://www.mail-archive.com/ssh@clinet.fi/

The Secure Shell FAQ:

http://www.employees.org/~satch/ssh/faq/

The Secure Shell secsh IETF working group:

http://www.ietf.org/html.charters/secsh-charter.html

If you are a non-commercial user and you require assistance, please check the mailing list

archives (listed above) first. If you are not able to find an answer to your problem, you

can send a message to the Secure Shell mailing list:

ssh@clinet.fi

There are many helpful people on the list who are very knowledgeable about Secure

Shell, including some of the Secure Shell developers from SSH.

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

44

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

Appendix C

Setting up Public Key Authentication for Secure Shell

Secure Shell Generated Keys

1.Ensure that on the client, the /etc/ssh2/ssh2_config file contains the line:

AllowedAuthentications

publickey, password, hostbased

2.Create a keypair on the client using the ssh-keygen2 command:

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

$ ssh-keygen2

You will be asked to enter a passphrase twice. Please choose a passphrase that is difficult

to guess - spaces and special characters are OK. This will create a public key (.pub) and a

private key (no extension). The default file names are id_dsa_1024_a.pub and

id_dsa_1024_a (both assuming you don't change the filenames or key size, and this is the

first keypair you have generated).

3.Copy the public key to the server, to the ~/.ssh2 directory for the user.

4.On the client, in the ~/.ssh2 directory for the user, make sure there is an identification

file that contains the following:

idkey id_dsa_1024_a

or whatever your private key's filename is.

5.Ensure that on the server, the /etc/ssh2/sshd2_config file contains the line:

AllowedAuthentications

publickey, password, hostbased

6.On the server, in the ~/.ssh2 directory for the user, make sure there is an authorization

file that contains the following:

key id_dsa_1024_a.pub

or whatever your public key's filename is.

That should be all you need to do to set up public key authentication for Secure Shell. If you have problems, start both the client and server in verbose mode (-v) to see what is

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

happening when the connection is attempted.

© SANS Institute 2000 - 2002

45

As part of GIAC practical repository.

Author retains full rights.

© SANS Institute 2000 - 2002, Author retains full rights.

PGP Keys

SSH Secure Shell only supports the OpenPGP standard and the PGP programs that use it. GnuPG is used in the following instructions. If you use PGP, the only difference is that the file extension is pgp instead of gpg.

1.Copy your private keyring (secring.gpg) to the ~/.ssh2 directory on the client.

2.Create an identification file in your ~/.ssh2 directory on the client if you don't

already have one. Add any ONE of the following lines to the identification file:

PgpSecretKeyFile <the filename of the user's private keyring>

IdPgpKeyName <the name of the OpenPGP key in PgpSecretKeyFile>

IdPgpKeyFingerprint <the fingerprint of the OpenPGP key in PgpSecretKeyFile>

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

IdPgpKeyId <the id of the OpenPGP key in PgpSecretKeyFile>

3.Copy your public keyring (pubring.gpg) to the .ssh2 sub-directory in the user's home

directory on the server:

scp2 pubring.gpg user@server:/home/user_name/.ssh2/

4.Create an authorization file in your .ssh2 sub-directory in the user's home directory on

the server. Add any ONE of the following lines to the authorization file:

PgpPublicKeyFile <the filename of the user's public keyring>

PgpKeyName <the name of the OpenPGP key>

PgpKeyFingerprint <the fingerprint the OpenPGP key>

PgpKeyId <the id of the OpenPGP key>

Now you should be able to login to the server from the client using public key

authentication.

Try to login:

client>ssh server_name

Passphrase for pgp key "user (comment)<user@client>":

Enter your passphrase for the key. A Secure Shell connection will be established.

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2000 - 2002

46

As part of GIAC practical repository.

Author retains full rights.