Getting Linux at IU

The Unix Systems Support Group has gathered together everything you need to install Linux. The following step by step instructions should help you get through the process. Throughout the document there are references to other Linux resources that you should investigate. Of these documents, one type stands out: the HOWTOs. HOWTOs are documents produced by the Linux Documentation Project that give step by step information on a particular topic. They are a priceless resource that you can get for free.

If you find a part of these instructions that you think is in need of revision please let us know by contacting us.

The USSG mirrors major Linux distributions as well as other software and documentation. These are available in the Linux ftp directory. You will find packages and ISOs from most major distributions here.

CD-ROMs for various Linux distributions are available from the USSG or they can be ordered directly from the company that makes them. Additionally, Linux distribution CD's can frequently be purchased in local bookstores that have software departments.

Deciding if Linux is right for you.

Linux is a powerful and flexible operating system. It can be a useful tool in a large variety of situations. This flexibility also means that things might require a bit more work. Although most software packages on Linux have detailed installation instructions, you might run into problems. Luckily, there are vast amounts of documentation available on the internet. The following documents will help you decide if Linux is right for you.

• The Linux FAQ Document
• The Linux Info Sheet

Choosing a machine

Once you have decided that you want to use Linux you need to pick the machine on which you will install it. For this task it is essential that you read the Hardware Compatibility HOWTO. Without this, you could very easily buy yourself a very snazzy machine and find that something on it is not supported by Linux. The major areas of concern are network cards, SCSI adapters, and video cards. To help decide which of those items are best you should read some of these documents.

• The "What card should I buy for Linux?" section of The Ethernet HOWTO
• The Linux Installation HOWTO
• The Hardware requirements section of The XFree86 HOWTO

General recommendations:

• Processor: This depends on your own needs and preferences. Linux requires at the very least a 386 to run but will also work on 486s and above. Generally Linux makes better use of available resources than other more popular operating systems and seems very fast to first timers. It is probably best to buy at least a Celeron or Pentium 3.
• Memory: Although a scaled down installation of Linux will run in 4MB, such a small amount of memory is not very effective for today's software. It is also difficult to find a machine with this little memory. Depending on your needs, we recommend anywhere from 64MB to 2GB or more of RAM.
• Disk size: A very small, but usable, Linux installation will fit on 40MB of disk. Modern distributions will require between one and three gigabytes of storage space. Authorities in the field suggest that there is a universal law of some sort: No matter how much disk you get your needs will grow to fill the space.
• Disk type: SCSI disks are desirable. Having a SCSI interface in your computer is more flexible than IDE or EIDE and with Linux tends to be faster. All three will work just fine. If you get a SCSI interface for use with your hard drive, save yourself some hassle and get a SCSI CD-ROM drive as well if you intend to buy a CD drive at all. This will save you trying to find compatible CD interface cards.
• Video Card: There are no hard rules to follow with video cards. Find one that has the price and features you want and then check the XFree86 Howto to see if it is supported. ATI and Nvidia cards are popular with Linux people and are generally well supported.
• Network Card: 3Com and SMC cards are very popular with Linux types for general use. Many people suggest staying away from NE2000 clones. This does not apply as much as it used to. Brand name cards will usually work better but an NE2000 clone that uses a well-known chipset is almost as good.

Choosing a Linux distribution

Linux distributions include the Linux operating system kernel that is distributed by Linus Torvalds and a wide variety of software to run on the system. Distributions differ from one another in several ways including:

• the types of hardware on which they run,
• the software that they include,
• the method by which one adds and removes software packages,
• ease of installation,
• the sources from which you can install the system,
• and price.

The best way to find out about what distributions offer is to read information on the web including the The Linux Distribution HOWTO and other sources. You will find that some distributions such as Debian and Slackware use command-line interfaces at which you enter commands to configure the system and install software whereas others such as Red Hat Linux use point-and-click interfaces as much as possible. Sources of installation include floppy disk (wow!), CD-ROM, the network via ftp or networked file systems (NFS), and a hard disk on your own computer that contains a copy of installable software.

Exactly which subset of sources is available depends on which distribution you choose. You can purchase CD-ROMS containing any distribution from sources on the web. Some distributions are now available in local bookstores, computer stores and places as exotic as Sam's Club. The more expensive distributions will be those with the more polished installation interfaces, those that include commercial software, and those that offer support after installation. Most distributions can be legally installed free of charge if you borrow a CD or install over the network. Some distributions have two editions, one containing commercial software for which you must pay and another containing only software that can be freely copied. Free installations do not include support from the vendor that produced the distribution. Check the licensing arrangement of the distribution that you choose.

Getting Help after Installation

If you have problems with Linux after you've installed, or have trouble with the install, please contact the USSG.

Please see our list of linux flavors that we offer. Generally we reccomend Ubuntu for new linux users.

Linux Dial-Up connections at IU

Indiana University Information Technology Services provides dial-up ppp services for the IU community. Several packages exist for configuring ppp connections and dialing in. These include:

• linuxconf graphical system administration tool that is independent of both linux distribution and desktop management scheme.
• kppp which is part of the KDE desk top.
• GnomePPP which is part of the GNOME desktop.
• Home-made scripts that you write yourself.

On this page, we provide configuration data that is necessary to make ppp connections to IU's modem pools. If you find information that you think is in need of revision please let us know by sending mail to webmaster@www.uwsg.iu.edu/.

Configuration data

You'll need these data if you use any method other than our ppp-iu scripts.

Parameter	IUB	IUPUI
phone number - 1 hr global	--	278-5621 V.90 or 56Kflex
- 2 hr global	856-5200 33.6Kbps or 56Kbps	--
- 4 hr global	856-5201 33.6Kbps	278-5620 V.90 or 56Kflex
- 8 hr global	856-5202 33.6Kbps	--
authentification	PAP	PAP
domain name	indiana.edu	iupui.edu
your IP address	dynamically assigned	dynamically assigned
primary dns	129.79.1.1	134.68.1.9
secondary dns	129.79.5.100	134.68.1.2
search	ucs.indiana.edu, indiana.edu	iupui.edu, it.iupui.edu
SMTP server	mail-relay.indiana.edu	mail-relay.iupui.edu
POP mail	varies among users	varies among users
IMAP	imap.indiana.edu	--
NNTP server	news.indiana.edu	news.iupui.edu

Software

You will be presented with blanks that you fill in, using information in the table above. Note that the mail and news parameters will not be used to configure the ppp link, and that they will be used to configure individual applications such as netscape, pine or slrn.

To make use of the variety of phone numbers and connection times, you might configure a separate ISP for each phone number that you want to use.

How do I get the USSG VPN Script?

The latest version of the ipsec / l2tp IU VPN connection script can be found here:

• http://www.ussg.iu.edu/vpn/ipsec/

To Install, run the following commands:

gunzip -c iu-vpn-ipsec-VERSION.FOO.tar.gz | tar xvf -

cd iu-vpn-ipsec-VERSION.FOO

make install (run this as root)

vpn-config-ipsec (run this as root)

After this, everything is installed and ready to use.

To connect to the VPN, simply type (as root):

iu-vpn-ipsec start

To stop the connection, type (as root):

iu-vpn-ipsec stop

To uninstall:

cd iu-vpn-ipsec-VERSION.FOO
make uninstall (run this as root)

Requires:

• Openswan ( http://www.openswan.org/ )
  Distros with package: Fedora, Gentoo, Suse, Ubuntu, Debian, Others?
  How do I install it? - Just simply download it from the website, and type the following commands:

  • tar xzvf <openswanfilename.tar.gz>
  • cd <openswan directory >
  • make programs
  • make programs install (as root)

  RHEL and Mandriva do not install gmp.h with the standard "devel" groups. Mandriva needs libgmp3-devel-VERSION-FOO.rpm installed (libgmp3-devel doesn't come on the install DVD, but is in install repos like USSG's mirror). RHEL need gmp-devel-VERSION-BAR.rpm
• xl2tpd ( http://www.xelerance.com/software/xl2tpd/ )
  Distros with package: Fedora, Gentoo, Debian, Others?
  How do I install it? - Just simply download it from the website, and type the following commands:

  • tar xzvf <xl2tpdfilename>.tar.gz
  • cd <xl2tpd directory >
  • make
  • make install (as root)
• pppd, ppp kernel modules (FYI, most distros except gentoo include these by default)
• Other Kernel Modules (FYI, most distros except gentoo include these by default):
  • Networking --->
    • Networking Options --->
      • (M) PF_KEY sockets
      • (M) IP: AH transformations
      • (M) IP: ESP transformations
      • (M) IP: IPComp transformations
      • (M) IP: tunnel transformations
      • (M) IPsec user configuration interface
  • Throw in the following crypto modules for good measure:
    • Cryptographic API --->
      • (M) Blowfish cipher algorithm
      • (M) SHA256 digest algorithm
      • (M) DES and Triple DES EDE cipher algorithms
      • (M) MD5 digest algorithm
      • (M) SHA1 digest algorithm

Tested with Red Hat, other flavors may need slight adjustment in the procedures section.

Configuration Files

/etc/samba/smb.conf

workgroup = ADS
winbind separator = +
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes
security = ADS
realm = ADS.IU.EDU
password server = ads.iu.edu
encrypt passwords = yes

/etc/krb5.conf

[libdefaults]
default_realm = ADS.IU.EDU
default_etypes = des-cbc-crc des-cbc-md5 default_etypes_des =
des-cbc-crc des-cbc-md5
[realms]
ADS.IU.EDU = {
kdc = ads.iu.edu:88
}

/etc/nsswitch.conf

passwd: files winbind
shadow: files
group: files winbind

Procedures

In addition to the above configuration you will need to have the smbd, nmbd, and winbind services running. These services can be started manually by running the following:

/etc/init.d/smb start
/etc/init.d/winbind start

nmbd will be started automatically when you start smbd. If want to set the above service to start automatically on boot, the easiest way in Red Hat is to run "ntsysv" as root and turn on the services you need.

Once you have everything configured and running you will want to join the ADS. To do this you will want to run the following command as root:

net -U username ads join

You will want to replace username with a valid ADS username that you would use to join a windows machine to ADS. It will ask for your password and then join your machine to the domain. It might take a minute or so for this to run and might displace some warnings. This is normal.

Once you have joined the domain you can add a share as follows. This is meant to be a general outline of how to define a share that uses ADS for authentication. Share are defined in your /etc/samba/smb.conf file.

[sharename]
path = /path/to/share
valid users = "ADS+username","ADS+username2"
public = no
writeable = yes

You will want to put this at the end of your smb.conf file. Replace sharename with the name of the share. You will also want to replace username and username2 with actual ADS usernames. It is very important to have the double quotes areound each individual username and to seperate them with commas. Also, if you want to give access to a group you can do so as follows:

valid users = @"ADS+Domain Users"

You can replace Domain Users with the name of any group within ADS. The Domain Users group will allow anyone with a valid ADS account to access your share.

Once you have set everything up you should be able to access your share from a windows machine by using \\machinename\sharename

Any time you make changes to your smb.conf you will want to restart samba by running

/etc/init.d/smb restart

What is Postfix?

Postfix is an easy to administer, secure Mail Transfer Agent, written by Wietse Venema. Postfix is designed to be a replacement for sendmail, but also provides an excellent sendmail compatability layer. This means that system administrators do not have to modify existing scripts that call sendmail for mail services. Postfix may be installed on a variety of Unix and Linux packages, and may be obtained in both binary and source formats. Postfix has the following features:

• destination-based routing, via transport maps
• Spam controls, including RBL support, and HELO/sender controls
• virtual domain support

Further information may be obtained at the Postfix Homepage. Details on installing Postfix, including replacing an existing sendmail installation are contained in the "INSTALL" file included in the source tarball. Even if you are installing a binary package, you should read this file, to ensure that currently queued mail being handled by your sendmail installation will be delivered.

Configuring Postfix for use at IU

Send-only Configuration

1. You MUST point the alias for root to a local user. This may be done by performing the following steps:
   • Open the file referenced in the variable alias_maps in /etc/postfix/main.cf
   • Change the right side of the root alias to a local user.
   • Regenerate the alias database:
     

     # postalias /path/to/aliases

   • Reload postfix:
     

     # postfix reload

2. All accounts that send mail MUST have corresponding IU email accounts.
3. In /etc/postfix/main.cf, uncomment and set myorigin to iupui.edu or indiana.edu
4. In /etc/postfix/master.cf, comment out the line listed below:
   

   smtp      inet  n       -       n        -      -       smtpd

5. Reload postfix:
   

   # postfix reload

USSG Recommended Listening Configuration

This will allow you to send email to the outside world, but all email being delivered to your system will pass through the IU relays, allowing you to leverage their spam and virus countermeasures. Communications between your mail server and the internal-relays will be limited via firewall rules.

1. change DNS MX record for all domains and hosts to point at external-relay.(indiana | iupui).edu
2. Utilize firewall rules to limit communication with internal-relay.(indiana | iupui).edu (following are provided as examples)
   • IPTables on Linux
     

     iptables -A INPUT -i $INT -p tcp \
     -s internal-relay.(indiana | iupui).edu -d $YOURIP\
     --dport 25 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

   • IPFilter on Solaris
     

     pass in quick on $INT proto tcp from\
     internal-relay.(indiana | iupui).edu to $YOURIP port = 25

What are Transport Maps?

Postfix Transport Maps specify mappings from email addresses to message delivery transports and/or relay hosts. We will be using transport maps to deliver IU addressed mail to the IU relays, and handle delivery of all other mail via the local machine. The following steps will guide you through this process, and assumes that you already have a functioning Postfix installation. If you do not have Postfix installed, you may wish to take a look at the following document, which provides an overview and some IU specific documentation.

1. In /etc/postfix/transport (create this file if it doesn't already exist), add the following:

   indiana.edu smtp:[internal-relay.indiana.edu]
   iu.edu smtp:[internal-relay.indiana.edu]
   iupui.edu smtp:[internal-relay.indiana.edu]
   iuk.edu smtp:[internal-relay.indiana.edu]
   iun.edu smtp:[internal-relay.indiana.edu]
   iusb.edu smtp:[internal-relay.indiana.edu]
   iuse.edu smtp:[internal-relay.indiana.edu]
   

   Note: the square brackets surrounding "internal-relay.indiana.edu" are important, and required for proper DNS resolution.
2. Determine the supported map types on your system:

   #postconf -m

   Look for "hash" or "dbm". You are likely to use "hash" on Linux, and "dbm" on Solaris.
3. Create a mapfile from your original transport map. (This allows postmap to efficiently lookup values in the transport file).

   # postmap hash:/etc/postfix/transport

4. Add, or uncomment and edit the following in /etc/postfix/main.cf:

   transport_maps = hash:/etc/postfix/transport

5. Restart postfix

   # postfix reload

After making these changes, send an email to an IU account, and an email to an outside account, such as yahoo.com. Your mail log should have entries similar to those below. The relay fields in the log entries below indicate that the first message was sent to internal-relay, and the second was delivered to mx1.mail.yahoo.com. This shows that the destination based routing is functioning correctly.

Mar 4 23:16:04 pequod postfix/smtp[29624]: CC531D7B:
to=<user@iupui.edu>,relay=internal-relay.iupui.edu[129.79.1.65],
delay=1, status=sent (250 2.0.0 i254ItxI013021 Message accepted for delivery)

Mar 4 23:22:08 pequod postfix/smtp[29630]: E4C65D7B:
to=<user@yahoo.com>, relay=mx1.mail.yahoo.com[64.157.4.79],
delay=2, status=sent (250 ok dirdel)

Mail Server Software Recommendations & Policy

The USSG recommends the use of central mail services whenever possible, and strongly discourages the use of a listening mail server, except in circumstances where it is the only viable solution. This recommendation is made after consideration of the dangers involved in listening mail services, and in accordance with IU mail recommendations.

The USSG recommends the use of Postfix when sending or receiving mail services are required. We provide IU specific documentation and support for the installation and use of Postfix. Other Unix/Linux mail server software, such as qmail or sendmail, will receive limited support.

You may find an overview, and migration document focused on IU in this document: here.

IU SMTP requirements

Mail relaying to non-IU addresses from within the IU network will require a user to authenticate. This is only required if a user wishes to send email to any domain other than the following: iu.edu , indiana.edu , iupui.edu , iun.edu , iusb.edu , iuse.edu, iuk.edu . Currently TLS, or SSL style encryption are supported, and "PLAIN" or "LOGIN" authentication is acceptable. GSS API, allowing kerberos credentials to be used, will be made available as soon as possible.

Unix Mail Clients Supporting SMTP AUTH

Most GUI Unix mail clients support SSL-based SMTP authentication. The USSG has specifically tested current versions of Mozilla Mail, KMail, and Evolution, and noted no problems. mh and mail, common console-based mail clients, do not support ssl, and would require workarounds to continue operating within the IU mail environment, such as using an ssl proxy.

GNU Privacy Guard (GPG)

[Portions of this text courtesy of GnuPG.org]

GnuPG is a complete and free replacement for PGP. Because it does not use the patented IDEA algorithm, it can be used without any restrictions. GnuPG is a RFC2440 (OpenPGP) compliant application.

GPG is a program that gives your electronic mail something that it otherwise doesn't have: Privacy. It does this by encrypting your mail so that nobody but the intended person can read it. When encrypted, the message looks like a meaningless jumble of random characters. Additonally, GPG can be used to encrypt datafiles on your machine, protecting sensitive information (such as passwords) from prying eyes.

GPG can also be used to apply a digital signature to a message without encrypting it. This is normally used in public postings, such as Usenet, where you don't want to hide what you are saying, but rather want to allow others to confirm that the message actually came from you. Once a digital signature is created, it is impossible for anyone to modify either the message or the signature without the modification being detected by GPG.

Where to Get GPG

GPG is available from GnuPG.org. Installation instructsion are available there also. Additionally, most Linux distributiion include GPG in their standard installation media.

Configuring GPG

After installation you will have an executable file called "gpg".

Once GPG is successfully installed, the first thing you should do is create your unique public/private key pair.Here are the steps to do this:

1. Enter gpg --gen-key at the command line.
   You will see the following output:
   

   gpg (GnuPG) 1.2.2; Copyright (C) 2002 Free Software Foundation, Inc.
   This program comes with ABSOLUTELY NO WARRANTY.
   This is free software, and you are welcome to redistribute it
   under certain conditions. See the file COPYING for details.
   
   Please select what kind of key you want:
   (1) DSA and ElGamal (default)
   (2) DSA (sign only)
   (5) RSA (sign only)
   Your selection?
   

2. Choose 1. Next you will see:
   

   DSA keypair will have 1024 bits.
   About to generate a new ELG-E keypair.
   minimum keysize is 768 bits
   default keysize is 1024 bits
   highest suggested keysize is 2048 bits
   What keysize do you want? (1024)
   

3. Enter the size(in bits) that you would like your GPG key to be. Generally the default of 1024 is fine. Next you will see:
   

   Please specify how long the key should be valid.
   0 = key does not expire
   = key expires in n days
   w = key expires in n weeks
   m = key expires in n months
   y = key expires in n years
   Key is valid for? (0)
   

4. Enter the expirtation period you would like for your key. For example, entering 3w would set the expiration period for 3 weeks.You will be asked to confirm your choice. Next next you will see:

   You need a User-ID to identify your key; the software constructs the user id from Real Name, Comment and Email Address in this form: "Heinrich Heine (Der Dichter) "

5. Enter the information as requested. The information you entered will be display and you will be given a chance to change it if needed. If you satisfied with the information press choose O to save it and continue.
6. You will be prompted to create and confirm a passphrase.Your pass phrase can be any sentence or phrase and may have many words, spaces,punctuation, or any other printable characters. Next you will see:

   We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy.

Follow the suggestions on your screen to ensure that your key is based on truly random numbers. Generating your keys can take up to several minutes. Congratulations! You have successfully created a public/private key pair.

Summary of GPG Commands

The following is a list of GPG commands that you might find useful:

• Encryption / decryption commands
  • To encrypt a plaintext file with the recipient's public key:

    gpg -e -r recipient_userid textfile

  • To sign a plaintext file with your secret key:

    gpg -s textfile

  • To sign a plaintext file with your secret key and have the output readable to people without running GPG first:

    gpg --clearsign textfile

  • To sign a plaintext file with your secret key, and then encrypt it with the recipient's public key:

    gpg -se -r recipient_userid

  • To decrypt an encrypted file, or to check the signature integrity of a signed file:

    gpg [-o outputfile] ciphertextfile

• Key management commands
  • To generate your own unique public/secret key pair:

    gpg --gen-key

  • To add a public or secret key file's contents to your public or secret key ring:

    gpg --import keyfile

  • To extract (copy) a key from your public or secret key ring:

    gpg -ao keyfile --export userid

    or

    gpg -ao keyfile --export-secret-key

  • To view the contents of your public key ring:

    gpg --list-keys

  • To view the "fingerprint" of a public key, to help verify it over the telephone with its owner:

    gpg --fingerprint userid

  • To view the contents and check the certifying signatures of your public key ring:

    gpg --check-sigs

  • To edit a key:

    gpg --edit-key userid

  • To remove a key or just a userid from your public key ring:

    gpg --delete-key userid

  • To sign and certify someone else's public key on your public key ring:

    gpg --sign-key userid

  • To permanently revoke your own key, issuing a key compromise certificate:

    gpg --gen-revoke userid

  • To disable or re-enable a public key on your own public key ring:

    gpg --batch --edit-key userid disable

    or

    gpg --batch -edit-key userid enable

• Esoteric commands:
• To create a signature certificate that is detached from the document:

  gpg -sb textfile

• To detach a signature certificate from a signed message

  gpg -b ciphertextfile

• Command options that can be used in combination with other command options (sometimes even spelling interesting words!):
  • To produce a ciphertext file in ASCII format, just add the -a option when encrypting or signing a message or extracting a key:

    gpg -sea textfile

  • To specify a recipient, add the -r option followed by a user id:

    gpg -se -r recipient textfile

  • To specify an output file, add the -o option followed by a filename:

    gpg -d -o outputfile textfile

What is tcp_wrappers?

tcp_wrappers is a very useful network access control facility written by Wietse Venema (who also wrote the SATAN package and maintains Postfix). It is very easy to configure and use.

Where to Get tcp_wrappers

Most Linux distributions, including Mac OSX, have tcp_wrappers configured to run out of the box.

In case you want to compile it yourself, the source distribution is available at ftp://ftp.porcupine.org/pub/security/.

Configuring tcp_wrappers

See the README included in the source for details on installing tcp_wrappers. The following sections provide details on using tcp_wrappers with inetd.conf. You may be able to skip this section as daemons such as ssh may already cooperate with tcpd.

Once installed, tcpd will do all its logging to wherever your /etc/syslog.conf is sending your mail logs. The standard locations are:

• aix - /var/adm/messages
• dunix - /var/adm/syslog.dated/[DATE]/mail.log
• hpux9 - /usr/spool/mqueue/syslog
• hpux10 - /usr/spool/mqueue/syslog
• irix - /var/adm/SYSLOG
• linux - /var/log/messages
• solaris - /var/log/syslog
• sunos - /var/log/syslog

The next step is editing inetd.conf.

In order to wrap a service (such as SSH), you simply change its entry in inetd.conf from

ssh stream tcp nowait root /usr/sbin/in.sshd in.sshd

to

ssh stream tcp nowait root /usr/sbin/sshd in.sshd

In other words, you change the full pathname to a daemon to the pathname to tcpd, leaving everything else untouched.

Install access control files

Next you need to install files which determine who can and who cannot access the wrapped services. This is accomplished by two files: hosts.allow and hosts.deny which you install in /etc.

Sample /etc/hosts.deny and /etc/hosts.allow files below:

/etc/hosts.deny

ALL: ALL: DENY # end of /ets/hosts.deny

/etc/hosts.allow

# IU subnets ssh access sshd: 129.79. 156.56. 134.68. 149.159. 149.160.: ALLOW sshd: 149.161. 149.162. 149.163. 149.164. 149.165.: ALLOW sshd: 149.166. 10. 192.168. 140.182. 192.239.50.: ALLOW # total access from 192.168.1.2 ALL: 192.168.1.2: ALLOW # safety line, add all entries above this line ALL: ALL: DENY # end of /etc/hosts.allow

They allow incoming ssh traffic only from the IU subnets. They also allow all traffic in from the 192.168.1.2 IP address. Do not use names in this file, DNS resolution is not as secure as actual IP addresses in this file. For people accessing your box from outside of the IU subnets, you should add each individual machine explicitly whenever possible. For example, say Prof. Smith is traveling to France and needs to be able to ssh back. If he has a specific host (say foo.bar.fr) from which he will be connecting, you can add it to hosts.allow (remember to use the IP, not the name for foo.bar.fr):

sshd: 1.2.3.4: ALLOW

If you want to further customize the access control list (ACL), we recommend reading the hosts_access(5) manpage included in the tcp_wrappers source package. There are many advanced ACL options such as having separate ACLs for each individual wrapped service, etc.

Have inetd Reread inetd.conf

In order to make the wrapper start its work, you simply send a HUP command to inetd. To do this, find the PID of inetd:

ps -ef | fgrep inetd (or ps aux | fgrep inetd on bsdi/linux/netbsd/sunos)

Which will print something like:

root 121 1 0 Apr 30 ? 0:00 /usr/sbin/inetd -s

Do a 'kill -HUP 121' to have inetd reread its configuration file (inetd.conf).

Test tcpd Functionality

Try to access your machine using whichever services you have chosen to wrap. Ensure that

1. tcpd is logging every access by looking at the appropriate syslog file, and
2. tcpd is controlling access according to how you have configured /etc/hosts.allow and /etc/hosts.deny.

This document lists the network services defined in /etc/inetd.conf on most systems along with recommendations for or against their use from a network/system security perspective.

We highly recommend the use of the publicly available package called tcp_wrappers. When a potentially insecure service must be used, tcp_wrappers should be utilized to "wrap" it. The wrapper software simply acts as a better logging and access control facility by "wrapping" itself around normal network daemons configured in inetd.conf. Here is a description of how to install and use tcp_wrappers.

Common Services

These services (listed alphabetically) are common to most vendor implementations:

• bootp, bootps : used for bootp services. We recommend disabling it unless you are running a bootp server.
• comsat : used for incoming mail notification via biff. We recommend disabling it unless you rely heavily on biff.
• echo, daytime, discard, chargen: These services are used largely for testing and are largely unnecessary. We recommend disabling them.
• exec : allow remote users to execute commands on a host without needing to log in. Exposes remote user passwords on the network, thus highly insecure. We recommend disabling the service.
• finger : allows remote users to use the finger utility to obtain information about arbitrary users on a host. Consindered highly insecure. We recommend disabling the service or using a more secure version such as cfinger.
• ftp : allows remote users to transfer files to/from a host using ftp. Since user passwords are easily sniffable (they are trasmitted over the wire in cleartext), we recommend disabling the service and using instead a secure file transfer mechanism which encrypts the entire session (such as kerberized ftpd or SSH). If ftp access is a must, the service should be wrapped.
• login : allows remote users to use the Berkeley rlogin utility to log in to a host without supplying a password (via the .rhosts mechanism). Considered highly insecure. We recommend disabling the service and using SSH instead. If rlogin access is a must, the service should be wrapped.
• netstat : designed to provide network status information about a host to remote hosts. Considered a potential secucrity hazard. We recommend disabling the service.
• shell : allows remote users to run arbitrary commands on a host via the Berkeley rsh utility (via the trusted hosts mechanism using the .rhosts file). Considered highly insecure. We recommend disabling the service and using SSH instead. If rsh access is a must, the service should be wrapped.
• systat : designed to provide status information about a host. Considered a potential secucrity hazard. We recommend disabling the service.
• telnet : allows remote users to connect to a host via telnet. Since user passwords are trasmitted over the wire in plain text and can therefore be easily sniffed, we recommend disabling the service and using instead a secure terminal access mechanism which encrypts the entire session (such as kerberized telnetd or sshd). If telnet access is a must, the service should be wrapped.
• talk, ntalk : allows remote users to use talk to have a real time conversation with a user on a host. Considered a security hazard. We recommend disabling the service.
• tftp : allows remote users to tranfer files from a host without requiring login. Used primarily by X-terminals and routers. Considered insecure. We recommend disabling the service. If tftp access is desired, we recommend that the "-s" option be used and that the service be wrapped.
• time: Used for clock synchronization. We recommend disabling the service and using xntp to synchronize your system clock to WWV.
• uucp : allows remote users to transfer files to/from a host using the UUCP protocol. Unless you use UUCP, we recommend disabling the service.

Services based on RPC

RPC based services such as NFS and NIS are considered major security hazards unless you are using secure RPC (under DCE, for example). Our general recommendation is therefore against the use of NIS or NFS unless the physical network segments are protected either physically or via the use of switched hubs. All RPC based services should be disabled in inetd.conf (unless NFS/NIS must be used).

Alternatives to NIS are:

• The use of Sun Microsystem's NIS+ (however, availability is currently limited to only a handful of vendors).
• the user of rdist along with SSH to distribute /etc/passwd, /etc/group, etc. to clients from a central server.

We are currently evaluating ways to secure NFS.

Common RPC based services defined in inetd.conf are:

• rexd : allows remote users to run RPC programs on a host. Can be used to run an arbitrary shell on the host, thus highly insecure. We recommend disabling the service.
• rquotad : returns quotas for a user of a local file system which is mounted by a remote machine over the NFS. We recommend disabling it.
• rstatd : extracts performance statistics from the kernel for use by programs such as perfmeter. We recommend disabling it.
• ruserd : is used to return a list of users on a network. We recommend disabling it.
• sprayd : records the packets sent by spray, and sends a response to the originator of the packets. We recommend disabling it.
• walld : used for handling rwall and shutdown requests. We recommend disabling it.
• ypupdated : used for updating NIS information. Since we recommend against the use of NIS in general, this service should be disabled.

Vendor-Specific Services

• DEC (Digital UNIX)
  • cfgmgr : used to locally or remotely manage dynamically configurable or loadable kernel subsystems via kloadsrv. Used by clients such as sysconfig. Since the trust mechanism is based on host (DNS) names (which is insecure), we recommend disabling the service.
  • kdebug : allows the debugging on a running kernel. The process involves running the kernel code to be debugged on a test system while the dbx debugger runs on a remote build system. We recommend disabling it unless it is explicitly being used.
  • rpc.cmsd : is the calendar daemon used by CDE.
  • rpc.ttdbserverd : used by the the TookTalk messaging service and for file name mapping.
• Hewlett-Packard (HP-UX)
  • printer : handles remote print spool requests. It can be disabled unless the host is configured to accept remote print requests.
  • recserv : used by the optional HP SharedX software subsystem to allow sharing of windows without explicitly performing any xhost commands. Disable it unless SharedX is installed and being used.
  • rwdaemon : used by HP's Remote Watch product and is no longer supported. We recommend disabling it if now already disabled.
  • spc : subprocess control for the SoftBench system. It used to control local and remote processes. Disable it unless you are using SoftBench.
• Linux
  • auth : the IDENT user identification protocol server. Usually disabled by default. If not, we recommend disabling it unless you explicitly use IDENT.
  • imap : the IMAP4 remote mail access protocol server. We recommend disabling it unless you intend to run an IMAP server.
  • nntp : the NNTP news server. We recommend disabling it unless you intend to run a news server.
  • pop-2, pop-3 : the POP-2, POP-3 remote mail access servers. We recommend disabling these unless you intend to run a POP-2 or POP-3 mail server.
  • smtp : the SMTP mail server. Disabled by default.
• Sun Microsystems (SunOS, Solaris)
  • name : The TCP/IP trivial name service protocol. Unnecessary. Disable.
• Non-inetd.conf Insecure Network Services
  • statd : provides status monitoring for crash and recovery functions in NFS. We recommend disabling it in initialization scripts (it is usually invoked as rpc.statd) unless you are using NFS. If you choose to use it, be sure to apply an appropriate vendor patch, if available.

SSH, and other such RSA key-based encryption programs, are packaged with exhaustive documentation, detailing how it works and how to use it. However, as that is a lot of reading material to wade through, here we present the quick-start guide for the SSH user, less the frills and jargon. You can find more exhaustive information from ITSO.

Where do I begin?

Assuming that SSH is already installed on your host machine, you must first create your key. Enter the command ssh-keygen. When prompted for a file in which to save the key, accept the default.

You are then prompted to enter a passphrase. Use something more complex than your Unix system password. SSH accepts all printable characters (letters, numbers, punctuation, etc.).

After you've entered your passphrase, you'll receive an output of your public key, called identity.pub. Create a file called authorized_keys, and read the contents of identity.pub into it. (The simple way to do it: cp indentity.pub authorized_keys)

Now I have my key. Now what?

Let's say you want to use SSH to connect to copper or your shakespeare account from your local machine, foobar. As both copper and the shakespeare machines alredy have SSH installed, you can ssh into them with the command: ssh hostname. But then the remote machine prompts you with (username)'s password: So when do I use my key? You have to take the key with you, if you wish to use it.

In the home directory of your remote accounts, create a ".ssh" directory, change to that directory, and create another "authorized_keys" file. Cut and paste into it your identity.pub from your local host. Make sure to preserve line length, as your SSH key is all one line.

Once this is done, it's a matter of deciding whether you want to type your SSH passphrase as a substitute for your UNIX password. More than likely, you'd prefer to type it once, and be done with it. Enter the following commands to do so:

1. ssh-agent /bin/bash (substitute the name of your favorite command shell)
2. ssh-add, and then type your SSH passphrase
3. ssh machine-name

Voila! You connect without using a passphrase or password. You can then connect likewise until you end your initial session.

What else can I do?

There's also a handy means to start up your Xwindows session within ssh-agent. Replace your Xwindow manager command line in your .xsession, .xinitrc, or .Xclients with something like:

ssh-agent bash -c "ssh-add < /dev/null && fvwm &> /dev/console"

Make sure to substitute your actual window manager command for fvwm. This will open a prompt for you to enter your SSH passphrase prior to the acutal launching of your window manager.

SSH also has its complentary rcp substitute, scp (secure copy). It behaves much like scp. Using it is relatively simple. Commands are in the structure scp user@host:filename localdir/newfile. For example, to copy your authorized_keys file over from one machine to another, you would issue the following command:

scp username@host:.ssh/authorized_keys .ssh/authorized_keys

If you have not utilized ssh-agent, you will be prompted for the password of the account on the remote machine (username@host). You can also copy multiple files, copy recursive directories, and copy between two remote hosts, utilizing the local host only to issue the command. However, as this is an introductory document, please see the scp man page for futher details.

X11 Connection Forwarding

X11 forwarding serves two purposes: it is a convenience to the user because there is no need to set the DISPLAY variable, and it provides encrypted X11 connections. The author couldn't think of any other easy way to make X11 connections encrypted; modifying the X server, clients or libraries would require special work for each machine, vendor and application. Widely used IP-level encryption does not seem likely for several years. Thus what we have left is faking an X server on the same machine where the clients are run, and forwarding the connections to a real X server over the secure channel.

X11 forwarding works as follows. The client extracts Xauthority information for the server. It then creates random authorization data, and sends the random data to the server. The server allocates an X11 display number, and stores the (fake) Xauthority data for this display. Whenever an X11 connection is opened, the server forwards the connection over the secure channel to the client, and the client parses the first packet of the X11 protocol, substitutes real authentication data for the fake data (if the fake data matched), and forwards the connection to the real X server.

If the display does not have Xauthority data, the server will create a unix domain socket in /tmp/.X11-unix, and use the unix domain socket as the display. No authentication information is forwarded in this case. X11 connections are again forwarded over the secure channel. To the X server the connections appear to come from the client machine, and the server must have connections allowed from the local machine. Using authentication data is always recommended because not using it makes the display insecure. If XDM is used, it automatically generates the authentication data.

One should be careful not to use "xin" or "xstart" or other similar scripts that explicitly set DISPLAY to start X sessions in a remote machine, because the connection will then not go over the secure channel. The recommended way to start a shell in a remote machine is

xterm -e ssh host &

and the recommended way to execute an X11 application in a remote machine is

ssh -n host emacs &

If you need to type a password/passphrase for the remote machine,

ssh -f host emacs

may be useful.

Securing your workstation from xhost vulnerabilities that may be present

If you have a good reason to run X programs from a remote computer, you should be doing this within an encrypted tunnel, such as via an ssh connection.

X11 can listen for, and accept connections from remote machines, however, this offers little authentication, and no encryption of the data. As well, if X11 is configured to accept connections from anywhere, an attacker could potentially log keystrokes from your system, or obtain screenshots. If X11 is listening, but not accepting connections, a malicious attacker may still be able to degrade performance of X Windows by pushing data at port 6000.

The ITSO has recently had reports of systems being compromised via this method, therefore it is important to ensure the security of your X Windows systems.

How to Tell if X is listening and/or accepting connections:

• netstat -l
• lsof

Disable X11 listening:

Modify the startx script to call X11 w/ "--no-listen", or (depending on your version) set the args variable to defaultserverargs="-nolisten tcp".
In XDM, do the same in xserver file

Workaround:

The only acceptable workaround for remote X11 sessions is to tunnel it through ssh. In order to accomplish this, one must modify sshd_config on the system from which you wish to run X11. Change X11Forwarding no to X11Forwarding yes and restart your ssh daemon. You may need to ask your system administrator to do this for you.

Connect to the remote system using

ssh -X [hostname]

You do not have to manually set the $DISPLAY variable, as ssh handles this for you. Once you have connected you may run your X applications, and they will display on your local machine. Alternatively, one can set the ForwardX11 variable to yes in the $HOME/.ssh/config file:

ForwardX11 yes

Lockdown the local machine:

At your prompt, type in the command xhost without any arguments, it should hopefully return the following string:

access control enabled, only authorized clients can connect

Below that may be a list of authorized clients. This is usually a list of trusted clients. It should only contain the entry LOCAL: as your connections should be coming in over ssh and not via xforwarding by itself. X11 has been shipping with xhost - as the default for several years now.

If your xhost command returned the following line:

access control disabled, clients can connect from any host

You have a vulnerable X server. Anyone can connect and take screen shots or log keystrokes. If this is the case, you should immediately enable access control, this is achieved by typing in xhost - at the prompt.

To add your localhost as a valid client for xhost, type in the following string:

xhost + local:

Firewalls

As a rule, your firewall should only allow in connections that are vital to the performance of your machine, in most cases this will be none, or will only be port 22 for ssh. If you are blocking all other ports, then you will be safer with this added line of defense. You should still make sure your xhost access control is enabled and you are only allowing connections from LOCAL:. xforwarding is not tcp_wrappers aware at the present time.

This PDF file is widly known as the Solaris 80/20 document. This is because it contains the 20 percent of Solaris knowledge you need to solve 80 percent of your Solaris problems.

It is available for download right here.

You can find the official documentation at http://docs.sun.com/.

The USSG has a copy of Revolution OS for checkout.

Revolution OS is a documentary about the evolution of Linux, GNU and the Open Source movement. Includes interviews with; Linus Torvalds, Richard Stallman, Bruce Perens, Eric Raymond, Brian Behlendorf, Michael Tiemann, Larry Augustin, Frank Hecker, and Rob Malda.