Securing a Debian Linux Laptop for Road Warriors

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.

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 As part of GIAC practical repository. Author retains full rights.

1

Securing a Debian Linux Laptop

for Road Warriors

By Stephanie Thomas for SANS GCUX Certification

Version 1.6b, Option 1 April 4, 2001

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



2

Table of ContentsIntroduction.............................................................................................................................4 Assessing the Risks.................................................................................................................4 Choosing the Right Laptop...................................................................................................5

BIOS Power On Password..................................................................................................5 BIOS Supervisor Password.................................................................................................5 Hard Drive Password..........................................................................................................6 Security Screw for the Hard Drive.....................................................................................6 Hardware Locks...................................................................................................................6

Debian Operating System Installation................................................................................6 First Thing's First - Partitioning the Hard Drive................................................................7 Installing the Operating System and Device Driver Modules, Base System Configuration.......................................................................................................................7 Selecting Packages to Install...............................................................................................7

Kernel.......................................................................................................................................8 Securing Network Services ...................................................................................................8 Securing LILO ......................................................................................................................10 Setting Password and Login Policies.................................................................................10 NTP .........................................................................................................................................12 Logging...................................................................................................................................13 Remote System Administration, File Access (Copy and Transfer) and E-mail .........14

Installation..........................................................................................................................14 Setting up the Secure Shell daemon to Start on Boot.....................................................15 Authentication....................................................................................................................15 Setting up Local Tunnels for E-mail ................................................................................16 Tightening up Access to Secure Shell..............................................................................17

Email and File Confidentiality...........................................................................................18 'Defensive' Security Measures............................................................................................18

TCP Wrappers ...................................................................................................................18 Packet Firewall - IPChains................................................................................................18 Psionic Portsentry..............................................................................................................19 Tripwire..............................................................................................................................19 Updating using apt-get ......................................................................................................19 Backup, Backup, Backup..................................................................................................20

'Offensive' Security Measures............................................................................................21 Nmap..................................................................................................................................22 Tiger, Tara, SATAN, SAINT, Sara, and Nessus.............................................................22 Password Cracking Programs...........................................................................................23

User Education......................................................................................................................23 Passwords...........................................................................................................................23 Hardware Protection..........................................................................................................23 Backups..............................................................................................................................24 Other Good Practices ........................................................................................................24

Conclusion..............................................................................................................................24

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



3

Checklist - Securing a Debian Linux Laptop for Road Warriors ................................25 Appendix A ............................................................................................................................29 Appendix B ............................................................................................................................32 Appendix C ............................................................................................................................45

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



4

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. Many laptop users work remotely where 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 theft at the U.S. State Department within the past year : http://www.cnn.com/2000/US/04/17/state.computer.02/ 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 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. Following are some of the most common remote access methods. 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



5

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). 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



6

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 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 System Administrator 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. Obtain the latest version of Debian from the ftp site -ftp://ftp.us.debian.org/debian/ Installation should be done while not connected to the network.

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



7

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 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. If you wish to enable NTFS, MSDOS or Samba filesystem support, you can do so under the filesystem device 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



8

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 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



9

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 [email protected] ( 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 State Service 9/tcp open discard 9/udp open discard 13/tcp open daytime 37/tcp open time 98/tcp open linuxconf 111/tcp open sunrpc 111/udp open sunrpc 113/tcp open auth 143/tcp open imap2 177/udp open xdmcp 512/tcp open exec 513/tcp open login 514/tcp open shell 515/tcp open printer 1024/tcp open kdm Nmap run completed -- 1 IP address (1 host up) scanned in 3 seconds To disable 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 [email protected] ( 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 State Service

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



10

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 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 permissions 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. Something simple is usually best, but this is determined by your company's security policy : "Employees of XYZ Corporation only. Unauthorized access prohibited. All connection attempts are logged."

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



11

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 /var/log/sulog ISSUE_FILE /etc/issue UMASK 077 PASS_MAX_DAYS 60 PASS_MIN_LEN 6 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 random passwords for the user, admin, and root. If you specify a -minchars of 8, the 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. Some user candidates for this are games, majordomo, www-data, gnats, operator, list, irc,

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



12

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 # # The first field should be a "+" (access granted) or "-" (access denied) # 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 "." # character). 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



13

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 install NTP on the laptop, obtain the source code from: http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ Compilation is the standard: $ ./configure $ make # make install 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



14

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 [email protected] errors [email protected] This will email [email protected] 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 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. Remember to open port 22 on your firewall to allow Secure Shell connections from your remote users. 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



15

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 Shell 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, 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 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



16

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 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. Plan your network accordingly. 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 "25:smtp.xyz.corp.com:25" LocalForward "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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



17

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. 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 This will allow in only users admin and user, and will deny login via Secure Shell to

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



18

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 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.linux.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,

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



19

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. Here is the line you'll want to uncomment in your portsentry.conf: KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -l" Tripwire 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 apt-get is the Debian answer to obtaining the latest updates for your system. Apt-get is

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



20

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 to the 'official' Debian ones pre-configured: 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. 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: # 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: http://www.debian.org/security . SANS also has a 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 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



21

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. 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. This includes applying the same tools the hackers use - such as nmap, as used above, to determine which ports are open, tiger,

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



22

tara or sara, nessus, and password cracking programs. This type of testing is a good 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. 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. 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 25th and April 2nd - 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



23

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 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. Securing any machine is useless unless you educate the end user on why the security is needed, what the policies are, and what they can 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. 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 Impress how vulnerable laptop computers are to theft

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



24

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 something goes wrong with the scheduled backups, notify the administrator 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 risk into an asset.

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



25

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 ____ 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 ____ Install shadow passwords ____ Set root password

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



26

____ 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: ____ 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 ____ Disable inetd (either from linuxconf or by commenting out /etc/inetd.conf)

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



27

____ 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 Edit the /etc/login.defs file to enable the following (these are recommended settings - set these as appropriate for your environment): ____ SULOG_FILE /var/log/sulog ____ ISSUE_FILE /etc/issue ____ UMASK 077 ____ PASS_MAX_DAYS 60 ____ PASS_MIN_LEN 6 ____ PASS_WARN_DAYS 5 ____ 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 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



28

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 ____ 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 __________ Date

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



29

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/ 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 SATAN http://www.porcupine.org/satan/

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



30

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/ 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=Password Debian Linux Sites Home Page http://www.debian.org/ Support http://www.debian.org/support Installation for Intel x86 http://www.debian.org/releases/stable/i386/install.en.html#contents

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



31

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/ 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



32

Appendix B SSH2 Quick Setup Reference Guide Updated March 28, 2001 Table of Contents 1. About this Document 2. About Secure Shell 3. Licensing Questions Answered 4. Installation 5. Setup for Special Circumstances 6. File Names and Locations 7. Authentication Methods 8. Configuration 9. 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 million users in 80 countries. It solves the most important security problem on the Internet: hackers stealing passwords. Typical applications include remote system

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



33

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 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



34

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 instructions are well documented in the SSH Secure Shell for Unix Administrators Guide. SSH Secure Shell for Unix Servers Administrator's Guide http://www.ssh.com/products/ssh/administrator24 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 a) Setting up chroot functionality for sftp:

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



35

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-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_.html

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



36

d) To set up Secure Shell with RSA SecurID support: From the ssh source directory: $ ./configure --with-serversecurid=/PATH --with-clientsecurid $ make # make install Replace /PATH with the absolute PATH to the directory containing the following files: sdclient.a 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 Shell for Unix Servers Administrator's Guide at: http://www.ssh.com/products/ssh/administrator24/SecurID.html 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 sshdfwd-X11:.ssh.com foo.bar.fi

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



37

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 file is located in the /etc/ssh2 directory and is named sshd2_config . The server binary is located in the /usr/local/sbin directory and is named sshd2 . 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 configuration files. Files which are specific to authentication are discussed in the Secure Shell for Unix Servers Administrator's Guide: http://www.ssh.com/products/ssh/administrator24/ under the setup instructions for the authentication. 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. Following are brief descriptions of the different authentication methods supported by

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



38

Secure Shell. For setup instructions on each of these, please see the online Secure Shell for Unix Servers Administrator's Guide at : http://www.ssh.com/products/ssh/administrator24/ 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 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, and creating a .shosts file in the user's home directory on the server. Hostbased authentication, once set up, can be completely non-interactive - this is the easiest 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. PAM support means that many other forms of authentication, such as 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. Kerberos

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



39

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 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. Please see the man page for the config file for descriptions of the values permitted. 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. Server Only Configuration Options

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



40

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 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.

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



41

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 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. This 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 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

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



42

you are using it. • Are your platform and operating system supported? • If installing via source code, are you using the correct compiler? See

http://www.ssh.com/products/ssh/portability.html to help answer these questions. • Are you installing via binary or source code? Are you following the

corresponding installation instructions? • Have you checked the README for installation instructions for source code or

binaries? See http://www.ssh.com/products/ssh/administrator24/ for complete installation instructions.

• 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?

• 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 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.

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



43

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. Nine times out of ten an incorrectly setup DNS is why hostbased authentication fails if the setup was done correctly. If you are unsure 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 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 sftp-server should change to subsystem-sftp /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:

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



44

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 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 ([email protected]): http://www.mail-archive.com/[email protected]/ 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: [email protected] There are many helpful people on the list who are very knowledgeable about Secure Shell, including some of the Secure Shell developers from SSH.

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



45

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:

$ 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 happening when the connection is attempted.

© S

AN

S In

stitu

te 2

000

- 200

2, A

utho

r ret

ains

full

righ

ts.



46

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> 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.

Documents

Securing a Debian Linux Laptop for Road Warriors