  Linux Security HOWTO
  Kevin Fenzi, kevin@scrye.com
  v0.9.5, 1 March 1998

  This document is a general overview of security issues that face the
  administrator of linux systems. It covers general security philosophy
  and a number of specific examples of how to better secure your linux
  system from intruders. Also included are pointers to security related
  material and programs. NOTE: This is a beta version of this document.
  Improvements, constructive criticism,  additions and corrections are
  gratefully excepted. Due to my despam filter,  you will need to mail
  me to get a despam key to mail me. Sorry for the  trouble. To avoid
  this make sure you have "linux", "security" or "HOWTO" in the subject
  line of your mail.

  1.  Introduction

  This document covers some of the main security issues that affect
  linux security. General philosophy and net born resources are
  discussed.

  A number of other HOWTO documents overlap with security issues, and
  those have been pointed to wherever appropriate.

  This document is NOT meant to be a up to date exploits document. Large
  numbers of new exploits happen all the time. This document will tell
  you where to look for such up to date information, and some general
  methods to prevent such exploits from taking place.

  1.1.  New versions of this document

  New versions of this document will be periodically posted to
  comp.os.linux.answers.  They will also be added to the various
  anonymous FTP sites who archive such information, including:

  ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO

  In addition, you should generally be able to find this document on the
  Linux Worldwide Web home page via:

  http://sunsite.unc.edu/mdw/linux.html

  Finally, the very latest version of this document should also be
  available in various formats from:

  http://scrye.com/~kevin/lsh/

  1.2.  Feedback

  All comments, error reports, additional information and criticism of
  all sorts should be directed to:

  kevin@scrye.com

  NOTE: I use the despam filter to filter all my mail. This means that
  if you are not known to me, your mail will bounce with a notice to re-
  send with a provided "key" in the subject. I regret the trouble this
  causes, but since I get 20-30 spam mails a day, I have to do
  something. Please re-send your message with the "key" in the subject
  and I will read your mail. You can also avoid this step by making sure
  you put "linux" "security" or "HOWTO" in the subject of your mail.
  http://scrye.com/~kevin/

  1.3.  Disclaimer

  No liability for the contents of this documents can be accepted.  Use
  the concepts, examples and other content at your own risk.
  Additionally, this is an early version, with many possibilities for
  inaccuracies and errors.

  A number of the examples and descriptions use the RedHat(tm) package
  layout and system setup. Your mileage may vary.

  As far as I know, only programs that under certain terms may be used
  or evaluated for personal purposes will be described. Most of the
  programs will be available complete with source under GNU-like terms.

  1.4.  Copyright information

  This document is copyrighted (c)1998 Kevin Fenzi and distributed under
  the following terms:

  ·  Linux HOWTO documents may be reproduced and distributed in whole or
     in part, in any medium physical or electronic, as long as this
     copyright notice is retained on all copies. Commercial
     redistribution is allowed and encouraged; however, the author would
     like to be notified of any such distributions.

  ·  All translations, derivative works, or aggregate works
     incorporating any Linux HOWTO documents must be covered under this
     copyright notice.  That is, you may not produce a derivative work
     from a HOWTO and impose additional restrictions on its
     distribution. Exceptions to these rules may be granted under
     certain conditions; please contact the Linux HOWTO coordinator at
     the address given below.

  ·  If you have questions, please contact Greg Hankins, the Linux HOWTO
     coordinator, at

  gregh@sunsite.unc.edu Finger for phone number and snail mail address.

  2.  Overview

  This document will attempt to explain some procedures and commonly
  used software to help your linux system be more secure.

  The first thing to keep in mind is that there is never any such thing
  as a "completely" secure computer system. All you can do is make it
  increasingly difficult for someone to compromise your system. For the
  average home linux user, not much is required to keep the causal
  cracker at bay. For high profile linux users (banks,
  telecommunications companies, etc) much more work is required.

  Another factor to take into account is that the more you increase your
  system security, the more intrusive your security becomes. You need to
  decide where in this balancing act your system is still usable and yet
  secure for your purposes. For instance, you could require everyone
  dialing into your system to use a call back modem to call them back at
  their home number. This is more secure, but if someone is not at home,
  it makes it difficult for them to login. You could also setup your
  linux system with no network or connection to the Internet, but this
  makes it harder to surf the web. If you are a large to medium sized
  site, you should establish a "Security Policy" stating how much
  security is required by your site and what auditing is in place to
  check it.

  This document has been segregated into several sections. They cover
  several broad kinds of security issues. The first, physical security,
  covers how you need to protect your physical machine from tampering.
  The second describes how to protect your system from tampering by
  local users. The third, network security, describes how to better
  secure your linux system from network attacks. The next discusses what
  to do when you detect a system compromise in progress or detect one
  that has recently happened. Then links to other security resources are
  enumerated, and finally a few closing words.

  The two main points to realize when reading this document are:

  ·  Be aware of your system. Check system logs such as
     /var/log/messages and keep an eye on your system, and

  ·  Two, keep your system up to date by making sure you have installed
     the current versions of software and have upgraded per security
     alerts.  Just doing this will help make your system markedly more
     secure.

  3.  Physical Security

  The first "layer" of security you need to take into account is the
  physical security of your computer systems. Who has direct physical
  access to your machine? Should they? Can you protect your machine from
  their tampering? Should you?

  How much physical security you need on your system is very dependent
  on your situation, and/or budget.

  If you are a home user, you probably don't need a lot (although you
  might need to protect your machine from tampering by children or
  annoying relatives).  If you are in a Lab environment, you need
  considerably more, but users will still need to be able to get work
  done on the machines. Many of the following sections will help out. If
  you are in a Office, you may or may not need to secure your machine
  off hours or while you are away. At some companies, leaving your
  console unsecured is a termination offense.

  Obvious physical security methods such as locks on doors, cables,
  locked cabinets, and video survailance are all a good idea, but beyond
  the scope of this document. :)

  3.1.  Computer locks

  Many more modern pc cases include a "locking" feature. Usually this
  will be a socket on the front of the case that allows you to turn an
  included key to a locked or unlocked position. Case locks can help
  prevent someone from stealing your pc, or opening up the case and
  directly manipulating/stealing your hardware. They can also sometimes
  prevent someone from rebooting your computer on their own floppy or
  other hardware.

  These case locks do different things according to the support in the
  motherboard and how the case is constructed. On many pc's they make it
  so you have to break the case to get the case open. On some others
  they make it so that it will not let you plug in new keyboards and
  mice. Check your motherboard or case instructions for more
  information. This can sometimes be a very useful feature, even though
  the locks are usually very low quality and can easily be defeated by
  attackers with locksmithing.

  Some cases (most notably sparcs and macs) have a dongle on the back
  that if you put a cable through attackers would have to cut the cable
  or break the case to get into it. Just putting a padlock or combo lock
  through these can be a good deterrent to someone stealing your
  machine.

  3.2.  BIOS Security

  The BIOS is the lowest level of software that configures or
  manipulates your x86 based hardware. LILO and other linux boot methods
  access the BIOS to determine how to boot up your linux machine. Other
  hardware that linux runs on has similar software (OpenFirmware on macs
  and new suns, sun boot prom, etc...). You can use your BIOS to prevent
  attackers from rebooting your machine and manipulating your linux
  system.

  Under linux/x86 many pc bioses let you set a boot password. This
  doesn't provide all that much security (bios can be reset, or removed
  if someone can get into the case), but might be a good deterant (ie it
  will take time and leave traces of tampering).

  Many x86 bioses also allow you to specify various other good security
  settings. Check your bios manual or look at it the next time you boot
  up. Some examples are: disallow booting from floppy drives and
  passwords to access some bios features.

  On Linux/Sparc, your SPARC eeprom can be set to require a boot-up
  password. This might slow attackers down.

  NOTE: If you have a server machine, and you setup a boot password,
  your machine will not boot up unattended. Keep in mind that you will
  need to come in and supply the password in the even of a power
  failure. ;(

  3.3.  Boot loader Security

  The various linux boot loaders also can have a boot password set.
  Using lilo take a look at the "restricted" and "password" settings.
  "password" allows you to set a bootup password. "restricted" will let
  the machine boot _unless_ someone specifies options at the lilo:
  prompt (like 'single').

  Keep in mind when setting all these passwords that you need to
  remember them. :) Also remember that these passwords will mearly slow
  the determined attacker.

  If anyone has security related information from a different boot
  loader, I would love to hear it. (grub, silo, milo, linload, etc).

  NOTE: If you have a server machine, and you setup a boot password,
  your machine will not boot up unattended. Keep in mind that you will
  need to come in and supply the password in the even of a power
  failure. ;(

  3.4.  xlock and vlock

  If you wander away from your machine from time to time, it is nice to
  be able to "lock" your console so that no one tampers with or looks at
  your work. Two programs that do this are: xlock and vlock.
  Xlock is a X display locker. It should be included in any linux
  distributions that support X. Check out the man page for it for more
  options, but in general you can run xlock from any xterm on your
  console and it will lock the display and require your password to
  unlock.

  vlock is a simple little program that allows you to lock some or all
  of the virtual consoles on your linux box. You can lock just the one
  you are working in or all of them. If you just lock one, others can
  come in and use the console, they will just not be able to use your
  vty until you unlock it. vlock ships with redhat linux, but your
  mileage may vary.

  Of course locking your console will prevent someone from tampering
  with your work, but does not prevent them from rebooting your machine
  or otherwise disrupting your work.

  3.5.  Detecting Physical Security compromises.

  The first thing to always note is when your machine was rebooted.
  Since linux is a robust and stable OS, the only times your machine
  should reboot is when YOU take it down for OS upgrades, hardware
  swapping, or the like. If your machine has rebooted without you doing
  it, a trouble light should go on. Many of the ways that your machine
  can be compromised require the intruder to reboot or power off your
  machine.

  Check for signs of tampering on the case and computer area. Although
  many intruders clean traces of their presence out of logs, it's a good
  idea to check through them all and note any discrepancy.

  Some things to check for in your logs:

  ·  Short or incomplete logs.

  ·  Logs containing strange timestamps.

  ·  Logs with incorrect permissions or ownership.

  ·  Records of reboots or restarting of services.

  ·  missing logs.

  ·  su entries or logins from strange places.

  Where to look for your log file will depend on your distribution. In
  the standard redhat setup, you will want to look in /var/log/ and
  check messages, mail.log, and others.

  You might also want to configure your log-rotating script or daemon to
  keep logs around longer so you have time to examine them. Take a look
  at the 'logrotate' package un recent redhat distributions. Other
  distributions likely have a similar process.

  4.  Local Security

  The next thing to take a look at is the security in your system
  against attacks from local users. Did I just say _local_ users? yes.

  Getting access to a local user is one of the first things that system
  intruders attempt. With lax local security, they can then "upgrade"
  their normal user access to root access using a variety of bugs and
  poorly setup local services. If you make sure your local security is
  tight, then the intruder will have another hurdle to jump.
  Local users can also cause a lot of havoc with your system even
  (especially) if they really are who they say they are. Providing
  accounts to people you don't know or have no contact information for
  is a very bad idea.

  Before changing permissions on any system files, make sure you
  understand what you are doing. Never change permissions on a file
  because it seems like the easy way to get things working. Always
  determine why the file has that permission before changing it.

  4.1.  Creating new accounts

  You should make sure and provide user accounts with only the minimal
  requirements for the task. If you provide your son (age 10) with an
  account, you might want them to only have access to a word processor
  or drawing program, but be unable to rm everything.

  Several good rules of thumb when allowing other people legitimate
  access to your linux machine:

  ·  Give them the minimal amount of privileges they need.

  ·  Be aware when/where they login from, or should be logging in from.

  ·  Make sure and remove their account when they no longer need the
     access.

  Many local user accounts that are used in security compromises are
  ones that have not been used in months or years. Since no one is using
  them they provide the ideal attack vehicle.

  4.2.  File Permissions

  It's important to insure that your system files are not open for
  casual editing by users and groups who shouldn't be doing such system
  maintance.

  A quick explanation of unix permissions:

  Ownership      - Which user(s) and group(s) retain(s) control of the
  permission settings of the node and parent of the node

  Permissions    - Bits capable of being set or reset to allow certain
  types of access to it.

  Read:

  ·  To be able to view contents of a file

  ·  To be able to read a directory

  Write:

  ·  To be able to add to or change a file

  ·  To be able to delete or move files in a directory

  Execute:

  ·  To be able to run a binary program

  ·  To be able to search in a directory

  You          - The owner of the file

  Group        - The group you belong to

  Everyone     - Anyone on the system

             Examples:
               -rw-r--r--  1 kevin  users         114 Aug 28  1997 .zlogin
               1st bit - directory?             (no)
                2nd bit - read by owner?         (yes, by kevin)
                 3rd bit - write by owner?        (yes, by kevin)
                  4th bit - execute by owner?      (no)
                   5th bit - read by group?         (yes, by users)
                    6th bit - write by group?        (no)
                     7th bit - execute by group?      (no)
                      8th bit - read by everyone?      (yes, by everyone)
                       9th bit - write by everyone?     (no)
                        10th bit - execute by everyone?  (no)

               drwxr-xr-x  3 kevin  users         512 Sep 19 13:47 .public_html/
               1st bit - directory?             (yes, it contains many files)
                2nd bit - read by owner?         (yes, by kevin)
                 3rd bit - write by owner?        (yes, by kevin)
                  4th bit - execute by owner?      (yes, by kevin)
                   5th bit - read by group?         (yes, by users
                    6th bit - write by group?        (no)
                     7th bit - execute by group?      (yes, by users)
                      8th bit - read by everyone?      (yes, by everyone)
                       9th bit - write by everyone?     (no)
                        10th bit - execute by everyone?  (yes, by everyone)

  System configuration files (usually in /etc) are usually mode 644
  (-rw-r--r--), and owned by root. Depending on your sites security
  requirements, you might adjust this. Never leave any system files
  writable by a group or everyone.

  4.3.  Root security

  Another common local user attacker is the admin of your linux box.
  yes, you! ;) Remember that you should only use the root account for
  very short specific tasks and should mostly run as a normal user.
  Running as root all the time is a very very very bad idea.  Just use
  su or sudo to do those tasks you need to do.

  Several tricks to avoid messing up your own box as root:

  ·  When doing some complex command, try running it first in a non
     destructive way...especially commands that use globbing: ie, you
     are going to do a "rm foo*.bak", instead, first do: "ls foo*.bak"
     and make sure you are going to delete the files you think you are.
     Using echo in place of destructive commands also sometimes works.

  ·  Some people find it helpfull to do a "touch /-i" on their systems.
     This will make commands like: "rm -rf *" ask you if you really want
     to delete all the files. (It does this by your shell resolving the
     "-i" file first, and treating it as the -i option to rm.) This will
     not help with rm statements with no * in them. ;(

  ·   Only become root to do single specific tasks. If you find yourself
     trying to figure out how to do something, go back to a normal user
     shell until you are sure what needs to be done by root.

  ·  Always be slow and deliberate running as root. Your actions could
     affect a lot of things. Think before you type!

  If you absolutely positively need to allow someone (hopefully very
  trusted) to have superuser access to your machine, there are a few
  tools that can help. Sudo allows users to use their password to access
  a limited set of commands as root. This would allow you to, for
  instance, let a user be able to eject and mount removable media on
  your linux box, but have no other root privileges. sudo also keeps a
  log of all sudo attempts and successes, allowing you to track down who
  used what command to do what. For this reason sudo works well even in
  places where a number of people have root access, but use sudo so you
  can keep track of changes made.

  4.4.  Trojan Horses

  A Trojan Horse is named after the fabled ploy in Homers great literary
  work. The idea is that you put up a program or binary that sounds
  great, and get other people to download it and run it as root. Then,
  you can compromise their system while they are not paying attention.
  While they think the binary they just pulled down does one thing (and
  it might very well), it also compromises their security.

  You should take care of what programs you install on your machine.
  redhat provides md5 checksums and pgp signed rpm files so you can
  verify you are installing the real thing. Other distributions have
  similar methods. You should never run any binary you don't have the
  source for or a well known binary as root! Few attackers are willing
  to release source code to public scrutiny.

  Although it can be complex, make sure you are getting the source for
  some program from it's real distribution site. If the program is going
  to run as root make sure either you or someone you trust has looked
  over the source and verified it.

  4.5.  Password Security & Encryption

  One of the most important security features used today are passwords.
  It is important for both you and all your users to have secure,
  unguessable passwords. Most of the more recent linux distributions
  include 'passwd' programs that not allow you to set a easily guessable
  password. Make sure your passwd program is up to date and has these
  features.

  In depth discussion of encryption is beyond the scope of this document
  , but a introduction is in order. Encryption is very usefull, possibly
  even nessessary in this day and age. There are all sorts of methods of
  encrypting data, each with their own flaws and drabacks. Some of the
  more common ones you should be aware of:

  unix password encryption: Most unicies (and linux is no exception) use
  the DES (Data Encryption Standard) to encrypt your passwords. This
  encrypted password is then stored in (typically) /etc/passwd (or less
  commonly) /etc/shadow. When you attempt to login, whatever you type in
  is encrypted again and compaired with the entry in the passwd file. If
  they match, it must be the same password and you are allowed access.
  DES is a one-way encryption. DES is know to be pretty weak in these
  days of fast computers. Brute force attacks, such as crack or John the
  ripper (see below) can often guess passwords unless your password is
  sufficently random. PAM modules (see below) allow you to use a
  diffrent encryption routine with your passwords (MD5 or the like).

  4.5.1.  PAM - Pluggable Authentication Modules

  Newer versions of the RedHat linux distribution ship with a thing
  called "PAM". PAM allows you to change on the fly your authentication
  methods and requirements. Without re-compiling any of your binaries.
  Configuration of PAM is beyond the scope of this document, take a look
  at the PAM web site for more information.
  http://www.kernel.org/pub/linux/libs/pam/index.html

  Just a few of the things you can do with PAM:

  ·  Use a non DES encryption for your passwords. (Making them harder to
     brute force decode.

  ·  Set resource limits on all your users so they can't perform denial
     of service attacks (number of processes, amount of memory, etc).

  ·  Enable shadow passwords (see below) on the fly.

  ·  allow specific users to login only at specific times from specific
     places.

  4.5.2.  Shadow Passwords.

  Shadow passwords are a means of keeping your encrypted password
  information secret from normal users. Normally this encrypted password
  is stored in your /etc/passwd file for all to read. They can then run
  password guesser programs on it and attempt to determine what it is.
  Shadow passwords save this information to a /etc/shadow file that only
  privileged users can read. In order to run shadow passwords you need
  to make sure all your utilities that need access to password
  information are recompiled to support it. PAM (above) also allows you
  to just plug in a shadow module and doesn't require re-compilation of
  executables.

  4.5.3.  Crack and John the Ripper

  If for some reason your passwd program is not enforcing non easily
  guessable passwords, you might want to run a password cracking program
  and make sure your users passwords are secure.

  Password cracking programs work on a simple idea. They try every word
  in the dictionary, and then variations on those words. They encrypt
  each one and check it against your encrypted password. If they get a
  match they are in.

  There are a number of programs out there...the two most notable of
  which are "Crack" and "John the Ripper"
  http://www.false.com/security/john/index.html . They will take up a
  lot of your cpu time, but you should be able to tell if an attacker
  could get in using them by running them first yourself and notifying
  users with weak passwords. Note that an attacker would have to use
  some other hole first in order to get your passwd (unix /etc/passwd)
  file, but these are more common than you might think.

  4.6.  Integrity Checking with Tripwire

  Another very good way to detect local (and also network) attacks on
  your system is to run an integrity checker like Tripwire. Tripwire
  runs a number of checksums on all your important binaries and config
  files and compares them against a database of former values. Thus, any
  changes in the files will be flagged.

  It's a good idea to install tripwire onto a floppy, and then
  physically set the write protect on the floppy. This way intruders
  can't tamper with tripwire itself or change the database. Once you
  have tripwire setup, it's a good idea to run it once a day or so and
  check to see if anything has changed.

  You can even add a crontab entry to run tripwire from your floppy
  every night and mail you the results in the morning. Something like:

       # set mailto
       MAILTO=kevin
       # run tripwire
       15 05 * * * root /usr/local/adm/tcheck/tripwire

  will mail you a report each morning at 5:15am.

  Tripwire can be a godsend to detecting intruders before you would
  otherwise notice them. Since a lot of files change on the average
  system, you have to be careful what is cracker activity and what is
  your own doing.

  4.7.  CFS - Cryptographic File System and TCFS - transparent crypto­
  graphic File System.

  CFS is a way of encrypting an entire file system and allow users to
  store encrypted files on them. It uses a NFS server running on the
  local machine. rpms are avail at http://www.replay.com/redhat/ and
  more information on how it all works is at:
  ftp://ftp.research.att.com/dist/mab/

  TCFS improves on CFS, adding more integration with the file system, so
  that it's transparent to any users using the file system that it's
  encrypted. more information at: http://edu-gw.dia.unisa.it/tcfs/

  4.8.  X11, SVGA and display security.

  4.8.1.  X11

  It's important for you to secure your graphical display to prevent
  attackers from doing things like: grabbing your passwords as you type
  them without you knowing it, reading documents or information you are
  reading on your screen, or even using a hole to gain superuser access.
  Running remote X applications over a network also can be fraught with
  peril, allowing sniffers to see all your interaction with the remote
  system.

  X has a number of access control mechanisms. The simplest of them is
  host based. You can use xhost to specify what hosts are allowed access
  to your display. This is not very secure at all. If someone has access
  to your machine they can xhost + their machine and get in easily.
  Also, if you have to allow access from an untrusted machine, anyone
  there can compromise your display.

  When using xdm (x display manager) to login, you get a much better
  access method: MIT-MAGIC-COOKIE-1. A 128bit cookie is generated and
  stored in your .Xauthorty file. If you need to allow a remote machine
  access to your display, you can use the xauth command and the
  information in your .Xauthority file to provide only that connection
  access.

  You can also use ssh (see ssh, above) to allow secure X connections.
  This has the advantage of also being transparent to the end user, and
  means that no un-encrypted data flows across the network.

  Take a look at the Xsecurity man page for more information on X
  security. The safe bet is to use xdm to login to your console and then
  use ssh to go to remote sites you wish to run X programs off of.

  4.8.2.  SVGA

  SVGAlib programs are typically suid root in order to access all your
  linux machines video hardware. This makes them very dangerous. If they
  crash, you typically need to reboot your machine to get a usable
  console back. Make sure any SVGA programs you are running are
  authentic, and can at least be somewhat trusted. Even better, don't
  run them at all.

  4.8.3.  GGI (Generic Graphics Interface project)

  The linux GGI project is trying to solve several of the problems with
  video interfaces on linux. GGI will move a small piece of the video
  code into the linux kernel, and then control access to the video
  system. This means GGI will be able to restore your console at any
  time to a known good state. They will also allow a secure attention
  key, so you can be sure that there is no Trojan horse login program
  running on your console. http://synergy.caltech.edu/~ggi/

  4.9.  identd

  identd is a small program that typically runs out of your inetd. It
  keeps track of what user is running what tcp service, and then reports
  this to whoever requests it.

  Many people misunderstand the usefulness of identd, and so disable it
  or block all off site requests for it. identd is not there to help out
  remote sites. There is no way of knowing if the data you get from the
  remote identd is correct or not. There is no authentication in identd
  requests.

  Why would you want to run it then? Because it helps _you_ out, and is
  another data-point in tracking. If your identd is un compromised, then
  you know it's telling remote sites the user-name or uid of people
  using tcp services. If the admin at a remote site comes back to you
  and tells you user so and so was trying to hack into their site, you
  can easily take action against that user. If you are not running
  identd, you will have to look at lots and lots of logs, figure out who
  was on at the time, and in general take a lot more time to track down
  the user.

  The identd that ships with most distributions is more configurable
  than many people think. You can disable identd for specific users
  (they can make a .noident file), you can log all identd requests (I
  recommend it), you can even have identd return a uid instead of a user
  name or even NO-USER.

  5.  Network Security

  Network security is becoming more and more important as people spend
  more and more time connected. Compromising network security is often
  much easier than physical or local, and is much more common.

  There are a number of good tools to assist with network security, and
  more and more of them are shipping with linux distributions.

  5.1.  Packet Sniffers

  One of the most common ways intruders gain access to more systems on
  your network is by employing a packet sniffer on a already compromised
  host. This "sniffer" just listens on the Ethernet port for things like
  "Password" and "Login" and "su" in the packet stream and then logs the
  traffic after that. This way, attackers gain passwords for systems
  they are not even attempting to break into. Clear text passwords are
  very vulnerable to this attack.

  EXAMPLE: host A has been compromised. Attacker installs a sniffer.
  Sniffer picks up admin logging into host B from Host C. It gets the
  admins personal password as they login to B. Then, the admin does a
  'su' to fix a problem. They now have the root password for Host B.
  Later the admin lets someone telnet from his account to host Z on
  another site. Now the attacker has a password/login on host Z.

  In this day and age, the attacker doesn't even need to compromise a
  system to do this, they could also bring a laptop or pc into a
  building and tap into your net.

  Using ssh or other encrypted password methods thwarts this attack.
  Things like APOP for pop accounts also prevents this attack. (Normal
  pop logins are very vulnerable to this, as is anything that sends
  clear text passwords over the wire.)

  5.2.  System services and tcp_wrappers

  As soon as you put your linux system on ANY network the first thing to
  look at is what services you need to offer. Services that you do not
  need to offer should be disabled so that you have one less thing to
  worry about and attackers have one less place to look for a hole.

  There are a number of ways to disable services under linux. You can
  look at your /etc/inetd.conf file and see what services are being
  offered by your inetd. Disable any that you do not need by commenting
  them out (# at the beginning of the line), and then sending your inetd
  process a SIGHUP.

  You can also remove (or comment out) services in your /etc/services
  file. This will mean that local clients will also be unable to find
  the service (ie, if you remove ftp, and try and ftp to a remote site
  from that machine it will fail with an unknown service message). It's
  usually not worth the trouble to remove services, since it provides no
  additional security. If a local person wanted to use ftp even tho you
  had commented it out, they would make their own client that use the
  common ftp port and would still work fine.

  If you know you are not going to use some particular package, you can
  also delete it entirely. rpm -e under the redhat distribution will
  erase an entire package. Under debian dpkg likely does the same thing.

  You should check your /etc/rc.d/rcN.d, where N is your systems run
  level and see if any of the servers started in that directory are not
  needed. Simply remove the unneeded script(s) and they will not be
  started on your next reboot. If you have BSD style rc files, you will
  want to check /etc/rc* for programs you don't need.

  Most linux distributions ship with tcp_wrappers "wrapping" all your
  tcp services. A tcp_wrapper (tcpd) is invoked from inetd instead of
  the real server. tcpd then checks the host that is requesting the
  service and either launches the program or denies access from that
  host. tcpd allows you to restrict access to your tcp services. You
  should make a /etc/hosts.allow and add in only those hosts that need
  to have access to your machines services. If you are a home dialup
  user, I would suggest you deny ALL. tcpd also logs failed attempts to
  access services, so this can give you an idea that you are under
  attack. If you add new services, you should always tcp wrapper them if
  they are tcp based.

  5.3.  SATAN , ISS, and other network scanners

  There are a number of different software packages out there that do
  port and service based scanning of machines or networks. SATAN and ISS
  are two of the more well known ones. This software connects to the
  target machine (or all the target machines on a network) on all the
  ports it can, and tries to determine what service is running there.
  Based on this information, you could find out the machine is
  vulnerable to a specific exploit on that server.

  SATAN (Security Administrators Tool for Analyzing Networks) is a port
  scanner with a web interface. It can be configured to do light,
  medium, or strong checks on a machine or a network of machines. It's a
  good idea to get SATAN and scan your machine or network, and fix the
  problems it finds. Make sure you get the copy of SATAN from sun-site
  or a reputable FTP or web site. There was a Trojan copy of SATAN that
  was distributed out on the net.
  http://www.trouble.org/~zen/satan/satan.html

  ISS (Internet Security Scanner) is another port based scanner. It is
  faster than Satan, and thus might be better for large networks.
  However, SATAN tends to provide more information.

  Detecting Port scans.

  There are some tools designed to alert you to probes by Satan and ISS
  and other scanning software, However liberal use of tcp_wrappers and
  making sure to look over your log files regularly, you should be able
  to notice such probes. Even on the lowest setting, Satan still leaves
  traces in the logs on a stock Redhat system.

  5.4.  pgp and public key cryptography

  pgp (pretty good privacy) is well supported on linux. versions 2.62
  and 5.0 are known to work well. For a good primer on pgp and how to
  use it, take a look a the pgp FAQ.
  http://www.pgp.com/service/export/faq/55faq.cgi

  5.5.  ssh and stelnet

  ssh (secure shell) and stelnet are programs that allow you to login to
  remote systems and have a encrypted connection.

  Ssh will prevent host spoofing attacks (It expects a specific key back
  from a host it's connected to before), it does compression and X11
  forwarding in addition to encrypting all your communications with the
  remote machines. This is very good to defeat packet sniffer attacks
  (The packet sniffer gets a bunch of encrypted packets). ssh is free
  for personal use, so I would recommend you install it and use it if
  you are at a personal site. http://www.cs.hut.fi/ssh/

  Stelnet is a secure telnet replacement that does encryption over a
  telnet connection.

  5.6.  sendmail, qmail and MTA's.

  One of the most important services you can provide is a mail server.
  Unfortunately, it is also one of the most vulnerable to attack, simply
  due to the number of tasks it must perform and the privileges it
  typically needs.

  If you are using sendmail it is very important to keep up on current
  versions. Sendmail has a long long history of security exploits.
  Always make sure you are running the most recent version.
  http://www.sendmail.org

  If you are tired of upgrading your version of sendmail every week, you
  might consider switching over to qmail. qmail was designed with
  security in mind from the ground up. It's fast and stable and secure.
  http://www.qmail.org

  5.7.  Denial of service attacks.

  A Denial of service attack is one where the attacker tries to make
  some resource too busy to answer legitimate requests, or to deny
  legitimate users access to your machine.

  Denial of service attacks have increased greatly in recent years. Some
  of the more popular and recent ones are listed below. Note that new
  ones show up all the time, so this is just a few examples. Read the
  linux security lists for more current information.

  SYN flooding. SYN flooding is a network denial of service attack. It
  takes advantage of a "loophole" in the way TCP connections are
  created. The newer linux kernels (2.0.30 and up) have several
  configurable options to prevent SYN flood attacks from denying people
  access to your machine or services. CONFIG_SYN_COOKIES and
  CONFIG_RST_COOKIES. Rebuild your kernel with these options to reduce
  your susceptibility to SYN flood attacks.

  Pentium "F00F" bug. It was recently discovered that a series of
  assembly codes send to a genuine Intel Pentium processor would lock
  the machine up totally. This affects every machine with a Pentium
  processor (not clones, not Pentium Pro or PII), no matter what
  operating system it's running. Linux kernel 2.0.32 and up contain a
  work around for this bug, preventing it from locking your machine. If
  you are running on a pentium, you should upgrade now!

  Ping flooding. Ping flooding is a simple brute force denial of service
  attack. Your attacker send a "flood" of ICMP packets to your machine.
  If they are doing this from a host with better bandwidth than yours,
  your machine will be unable to send anything on the network. A
  variation on this attack "smurfing" sends ICMP packets to a host with
  _your_ machines return IP, allowing them to flood you less detectably.
  If you are under a ping flood attack, use a tool like tcpdump to
  determine where the packets are coming from (or appear to be coming
  from), then contact your provider with this information. Ping floods
  can most easily be stopped at the router level.

  5.8.  NFS (Network File System) security.

  NFS is a very widely used file sharing protocol. It allows servers
  running nfsd and mountd to "export" entire filesystems to other
  machines with nfs filesystem support builtin to their kernels (or some
  other client support if they are non linux machines). Mountd keeps
  track of mounted filesystems in /etc/mtab, and can display them with
  'showmount'.

  Many sites use NFS to serve home directories to users, so that no
  matter what machine in the cluster they login to, they will have all
  their home files.

  There is some small amount of "security" allowed in exporting
  filesystems. You can make your nfsd map the remote root user (uid=0)
  to the nobody user, denying them total access to the files exported.
  However, since individual users have access to their own (or at least
  the same uid) files, the remote superuser can login or su to their
  account and have total access to their files. This is only a small
  hindrance to an attacker that has access to mount your remote
  filesystems.

  If you must use NFS, make sure you export to only those machines that
  you really need to export only. Never export your entire root
  directory, export only directories you need to export.

  See the NFS HOWTO for more information on NFS: NFS HOWTO

  5.9.  NIS (Network Information service) (formerly YP).

  Network Information service (formerly YP) is a means of distributing
  information to a group of machines. The NIS master holds the
  information tables and converts them into NIS map files. These maps
  are then served over the network, allowing NIS client machines to get
  login, password, home directory and shell information (all the
  information in a standard /etc/passwd file). This allows users to
  change their password once and have it take affect on all the machines
  in the NIS domain.

  NIS is not at all secure. It was never meant to be. It was meant to be
  handy and usefull. Anyone that can guess the name of your NIS domain
  (anywhere on the net) can get a copy of your passwd file, and use
  crack and john the ripper against your users passwords. Also, it is
  possible to spoof NIS and do all sorts of nasty tricks. If you must
  use NIS, make sure you are aware of the dangers.

  There is a much more secure replacement for NIS, called NIS+.  Check
  out the NIS HOWTO for more information:
  http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html

  5.10.  Firewalls

  Firewalls are a means of restricting what information is allowed into
  and out of your local network. Typically the firewall host is
  connected to the Internet and your local lan, and the only access from
  your lan to the Internet is through the firewall. This way the
  firewall can control what passes back and forth from the Internet and
  your lan.

  There are a number of types and methods of setting up firewalls. Linux
  machines make pretty good low cost firewalls. firewall code can be
  built right into 2.0 and higher kernels. The ipfwadm user space tool
  allows you to change what types of network traffic you allow on the
  fly. You can also log particular types of network traffic.
  Firewalls are a very usefull and important technique in securing your
  network. It is important to realize that you should never think that
  because you have a firewall, you don't need to secure the machines
  behind it. This is a fatal mistake. Check out the very good Firewall-
  HOWTO at your latest sun-site archive for more information on
  firewalls and linux. http://sunsite.unc.edu/mdw/HOWTO/Firewall-
  HOWTO.html

  6.  What to do during and after a breakin

  So you have followed some of the advice here (or elsewhere) and have
  detected a breakin? The first thing to do is to remain calm. Hasty
  actions can cause more harm than the attacker would have.

  6.1.  Security Compromise under way.

  Spotting a security compromise under way can be a tense undertaking.
  How you react can have large consequences.

  If the compromise you are seeing is a physical one, odds are you have
  spotted someone who has broken into your home, office or lab. You
  should notify your local authorities. In a lab setting you might have
  spotted someone trying to open a case or reboot a machine. Depending
  on your authority and procedures, you might ask them to stop, or
  contact your local security people.

  If you have detected a local user trying to compromise your security,
  the first thing to do is confirm they are in fact who you think they
  are. Check the site they are logging in from. Is it the site they are
  normally in from? no? Then use a non electronic means of getting in
  touch. For instance call them on the phone or walk over to their
  office/house and talk to them. If they agree that they are on, you can
  ask them to explain what they were doing or tell them to cease doing
  it. If they are not on, and have no idea what you are talking about,
  odds are this incident requires further investigation. Look into such
  incidents , and have lots of information before making any
  accusations.

  If you have detected a network compromise, the first thing to do (if
  you are able) is to disconnect your network. If they are connected via
  modem, unplug the modem cable, if they are connected via ethernet,
  unplug the ethernet cable. This will prevent them from doing any
  further damage, and they will probably see it as a network problem
  rather than detection.

  If you are unable to disconnect the network (if you have a busy site,
  or you do not have physical control of your machines), the next best
  step is to use something like tcp_wrappers or ipfwadm to deny access
  from the intruders site.

  If you can't deny all people from the same site as the intruder,
  locking the users account will have to do. Note that locking an
  account is not an easy thing. You have to keep in mind .rhosts files,
  FTP access, and a host of backdoors).

  After you have done one of the above (disconnected network, denied
  access from their site, and/or disabled their account), you need to
  kill all their user processes and log them off.

  You should monitor your site well for the next few minutes, as the
  attacker will try and get back in. Perhaps using a different account,
  and/or from a different network address.

  6.2.  Security Compromise has already happened.

  So you have either detected a compromise that has already happened or
  you have detected it and locked (hopefully) the offending attacker out
  of your system. Now what?

  6.2.1.  Closing the Hole

  If you are able to determine what means the attacker used to get into
  your system, you should try and close that hole. For instance, perhaps
  you see several FTP entries just before the user logged in. Disable
  the FTP service and check and see if there is an updated version or
  any of the lists know of a fix.

  Check all your log files, and make a visit to your security lists and
  pages and see if there are any new common exploits you can fix.

  If you don't lock the attacker out, they will likely be back. Not just
  back on your machine, but back somewhere on your lan. If they were
  running a packet sniffer, odds are good they have access to other
  local machines.

  6.2.2.  Assessing the Damage

  The first thing is to assess the damage. What has been compromised?
  If you are running an Integrity Checker like Tripwire you can make a
  tripwire run and it should tell you. If not, you will have to look
  around at all your important data.

  Since linux systems are getting easier and easier to install, you
  might consider saving off your config files and then wiping your
  disk(s) and reinstalling, then restoring your user files from backups
  and your config files. This will insure that you have a new clean
  system.

  6.2.3.  Backups, Backups, Backups!

  Having regular backups is a godsend for security matters. If your
  system is compromised, you can restore the data you need from backups.
  Of course some data is valuable to the attacker to, and they will not
  only destroy it, they will steal it and have their own copies, but at
  least you will still have the data.

  You should check several backups back into the past before restoring a
  file that has been tampered with. The intruder could have compromised
  your files long ago, and you could have made many successful backups
  of the compromised file!!!

  Of course, there are also a raft of security concerns with backups.
  Make sure you are storing them in a secure place. Know who has access
  to them. (If an attacker can get your backups, they can have access to
  all your data without you ever knowing it.)

  6.2.4.  Tracking down the intruder.

  Ok, you have locked the intruder out, and recovered your system, but
  you're not quite done yet. While it is unlikely that most intruders
  will ever be caught, you should report the attack.

  You should report the attack to the admin contact at the site where
  the attacker attacked your system. You can look up this contact with
  "whois" or the internic database. You might send them an email with
  all applicable log entries and dates and times. If you spotted
  anything else distinctive about your intruder, you might mention that
  too. After sending the email, you should (if you are so inclined)
  follow up with a phone call. If that admin in turn spots your
  attacker, they might be able to talk to the admin of the site where
  they are coming from and so on.

  Good hackers often use many intermediate systems. Some (or many) of
  which may not even know they have been compromised. Trying to track a
  cracker back to their home system can be difficult. Being polite to
  the admins you talk to can go a long way to getting help from them.

  You should also notify any security organizations you are a part of
  (cert or similar).

  7.  Security sources

  There are a LOT of good sites out there for unix security in general
  and linux security specifically. It's very important to subscribe to
  one (or more) of the security mailing lists and keep current on
  security fixes. Most of these lists are very low volume, and very
  informative.

  7.1.  FTP sites

  CERT is the Computer Emergency Response Team. They often send out
  alerts of current attacks and fixes. cert.org

  Replay has archives of many security programs. Since they are outside
  the US, they don't need to obey any silly US crypto restrictions.
  replay.com

  Matt Blaze is the author of CFS and a great security advocate.  Matt
  Blaze's stuff

  Sorosis is the home of the linux PAM site. They have lots of modules
  and information on PAM.  Linux PAM ftp site

  tue.nl is a great security ftp site in the Netherlands.
  ftp.win.tue.nl

  7.2.  The Hacker FAQ is a FAQ about hackers: The Hacker FAQ web sites

  The COAST archive has a large number of unix security programs and
  information: COAST

  Rootshell.com is a great site for seeing what exploits are currently
  being used by crackers: rootshell.com exploits

  BUGTRAQ puts out advisories on security issues: BUGTRAQ archives

  CERT, the Computer Emergency Response Team, puts out advisories on
  common attacks on unix platforms: CERT home

  Dan Farmer is the author of SATAN and many other security tools, his
  home site has some interesting security survey information as well as
  security tools: Dan Farmers trouble.org

  The linux security WWW is a good site for linux security information:
  Linux Security WWW

  Reptile has lots of good linux security information on his site:
  Reptiles Linux Security Page

  Infilsec has a vulnerability engine that can tell you what
  vunerabilities affect a specific platform: Infilsec vunerability
  engine

  CIAC sends out periodic security bulitins on common exploits: CIAC
  bulitins

  7.3.  mailing lists

  Bugtraq:  To subscribe to bugtraq, send mail to listserv@netspace.org
  containing the message body subscribe bugtraq. (see links above for
  archives).

  CIAC: Send e-mail to: majordomo@tholia.llnl.gov In the BODY (not
  subject) of the message put (either or both): subscribe ciac-bulletin

  7.4.  Books - printed reading material.

  There are a number of good security books out there. This section
  lists a few of them. In addition to the security specify books,
  security is covered in a number of other books on system
  administration.

  Building Internet Firewalls By D. Brent Chapman & Elizabeth D. Zwicky

  1st Edition September 1995

  ISBN: 1-56592-124-0

  Practical UNIX & Internet Security, 2nd Edition By Simson Garfinkel &
  Gene Spafford

  2nd Edition April 1996

  ISBN: 1-56592-148-8

  Computer Security Basics By Deborah Russell & G.T. Gangemi, Sr.

  1st Edition July 1991

  ISBN: 0-937175-71-4

  Linux Network Administrator's Guide By Olaf Kirch

  1st Edition January 1995

  ISBN: 1-56592-087-2

  PGP: Pretty Good Privacy By Simson Garfinkel

  1st Edition December 1994

  ISBN: 1-56592-098-8

  Computer Crime A Crimefighter's Handbook By David Icove, Karl Seger &
  William VonStorch (Consulting Editor Eugene H. Spafford)

  1st Edition August 1995

  ISBN: 1-56592-086-4

  8.  Conclusion

  By subscribing to the security alert mailing lists, and keeping
  current, you can do a lot towards securing your machine. If you pay
  attention to your log files and run something like tripwire regularly,
  you can do even more.

  A reasonable level of computer security is not difficult to maintain
  on a home machine. More effort is required on business machines, but
  linux can indeed be a secure platform. Due to the nature of linux
  development, security fixes often come out much faster than they do on
  commercial operating systems, making linux an ideal platform when
  security is a requirement.

  9.  Thanks to

  Information here is collected from many sources. Thanks to the
  following that either indirectly or directly have contributed:

       Rob Riggs <rob@DevilsThumb.com>
       S. Coffin <scoffin@netcom.com>
       Viktor Przebinda <viktor@CRYSTAL.MATH.ou.edu>
       Roelof Osinga <roelof@eboa.com>
       Kyle Hasselbacher <kyle@carefree.quux.soltec.net>
       "David S. Jackson" <dsj@dsj.net>

