GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


archive:computers:unixsec
        IMPROVING THE SECURITY OF YOUR      UNIX SYSTEM
        David A. Curry, Systems Programmer
        Information and Telecommunications Sciences and Technology Division
        ITSTD-721-FR-90-21
        Approved:
        Paul K. Hyder, Manager
        Computer Facility
        Boyd C. Fair, General Manager
        Division Operations Section
        Michael S. Frankel, Vice President
        Information and Telecommunications Sciences and Technology Division
                                                 Final Report o+ April 1990

SRI International 333 Ravenswood Avenue o+ Menlo Park, CA 94025-3493 o+ (415) 326-6200 o+ FAX: (415) 326-5512 o+ Telex: 334486

                                     SECTION 1
                                   INTRODUCTION
        1.1   UNIX SECURITY
               The UNIX operating system, although now in widespread  use
          in  environments  concerned  about  security,  was  not  really
          designed with security in mind [Ritc75].  This  does  not  mean
          that  UNIX  does  not  provide any security mechanisms; indeed,
          several very good ones are available.  However, most  %%out  of
          the  box''  installation  procedures from companies such as Sun
          Microsystems still install the operating  system  in  much  the
          same  way  as  it was installed 15 years ago: with little or no
          security enabled.
               The reasons for this state of affairs are largely histori-
          cal.   UNIX  was  originally designed by programmers for use by
          other programmers.  The environment in which it  was  used  was
          one of open cooperation, not one of privacy.  Programmers typi-
          cally collaborated with each other on projects, and hence  pre-
          ferred  to be able to share their files with each other without
          having to climb over security hurdles.  Because the first sites
          outside  of  Bell  Laboratories to install UNIX were university
          research laboratories, where a similar environment existed,  no
          real need for greater security was seen until some time later.
               In the early 1980s, many universities began to move  their
          UNIX systems out of the research laboratories and into the com-
          puter centers, allowing (or forcing) the user population  as  a
          whole  to  use  this new and wonderful system.  Many businesses
          and government sites began to install  UNIX  systems  as  well,
          particularly  as  desktop workstations became more powerful and
          affordable.  Thus, the UNIX operating system is no longer being
          used only in environments where open collaboration is the goal.
          Universities require their students to use the system for class
          assignments,  yet  they  do not want the students to be able to
          copy from each other.  Businesses use their  UNIX  systems  for
          confidential  tasks  such  as bookkeeping and payroll.  And the
          government uses UNIX systems for various unclassified yet  sen-
          sitive purposes.
               To complicate matters, new features  have  been  added  to
          UNIX  over  the  years,  making security even more difficult to
          control.  Perhaps  the  most  problematic  features  are  those
        _________________________
        UNIX is a registered trademark of AT&T.  VAX is  a  trademark  of
        Digital  Equipment  Corporation.  Sun-3 and NFS are trademarks of
        Sun Microsystems.  Annex is a trademark of Xylogics, Inc.
                                        1
          relating to networking: remote login, remote command execution,
          network  file  systems,  diskless  workstations, and electronic
          mail.  All of these features have  increased  the  utility  and
          usability  of  UNIX  by  untold  amounts.   However, these same
          features, along with the widespread connection of UNIX  systems
          to  the  Internet  and  other networks, have opened up many new
          areas of vulnerability to unauthorized abuse of the system.
        1.2   THE INTERNET WORM
               On the evening of November  2,  1988,  a  self-replicating
          program,  called  a _w_o_r_m, was released on the Internet [Seel88,
          Spaf88, Eich89].  Overnight, this  program  had  copied  itself
          from  machine  to  machine, causing the machines it infected to
          labor under huge loads, and denying service  to  the  users  of
          those  machines.   Although the program only infected two types
          of computers,* it spread quickly, as did  the  concern,  confu-
          sion,  and  sometimes  panic  of  system  administrators  whose
          machines were affected.  While many system administrators  were
          aware that something like this could theoretically happen - the
          security holes exploited by the worm  were  well  known  -  the
          scope  of the worm's break-ins came as a great surprise to most
          people.
               The worm itself did  not  destroy  any  files,  steal  any
          information  (other  than account passwords), intercept private
          mail, or plant other destructive software  [Seel88].   However,
          it did manage to severely disrupt the operation of the network.
          Several sites, including parts of  MIT,  NASA's  Ames  Research
          Center  and  Goddard  Space  Flight  Center, the Jet Propulsion
          Laboratory, and the U. S. Army Ballistic  Research  Laboratory,
          disconnected themselves from the Internet to avoid recontamina-
          tion.  In addition, the Defense Communications  Agency  ordered
          the  connections  between the MILNET and ARPANET shut down, and
          kept them down for nearly 24 hours  [Eich89,  Elme88].   Ironi-
          cally,  this was perhaps the worst thing to do, since the first
          fixes to combat the  worm  were  distributed  via  the  network
          [Eich89].
               This incident was perhaps the most widely  described  com-
          puter  security  problem  ever.   The  worm was covered in many
          newspapers and magazines around the country including  the  _N_e_w
          _Y_o_r_k  _T_i_m_e_s,  _W_a_l_l  _S_t_r_e_e_t  _J_o_u_r_n_a_l,  _T_i_m_e  and  most computer-
          oriented technical publications, as well as on all three  major
        _________________________
          * Sun-3 systems from Sun Microsystems and VAX systems from  Di-
        gital Equipment Corp., both running variants of 4._x BSD UNIX from
        the University of California at Berkeley.
                                        2
          television networks, the Cable News Network, and National  Pub-
          lic  Radio.   In  January  1990, a United States District Court
          jury found Robert Tappan Morris, the author of the worm, guilty
          of  charges  brought  against him under a 1986 federal computer
          fraud and abuse law.  Morris faces up to five years  in  prison
          and  a $250,000 fine [Schu90].  Sentencing is scheduled for May
          4, 1990.
        1.3   SPIES AND ESPIONAGE
               In August  1986,  the  Lawrence  Berkeley  Laboratory,  an
          unclassified  research laboratory at the University of Califor-
          nia at Berkeley,  was  attacked  by  an  unauthorized  computer
          intruder  [Stol88, Stol89].  Instead of immediately closing the
          holes the intruder was using, the system  administrator,  Clif-
          ford  Stoll,  elected  to  watch  the intruder and document the
          weaknesses he  exploited.   Over  the  next  10  months,  Stoll
          watched  the  intruder  attack  over  400  computers around the
          world, and successfully enter about 30.  The  computers  broken
          into  were located at universities, military bases, and defense
          contractors [Stol88].
               Unlike many intruders seen on the Internet, who  typically
          enter  systems  and  browse  around  to see what they can, this
          intruder was looking for something specific.   Files  and  data
          dealing  with the Strategic Defense Initiative, the space shut-
          tle, and other military topics all  seemed  to  be  of  special
          interest.  Although it is unlikely that the intruder would have
          found any truly classified  information  (the  Internet  is  an
          unclassified  network),  it  was  highly probable that he could
          find a wealth of sensitive material [Stol88].
               After a year of tracking the intruder (eventually  involv-
          ing  the FBI, CIA, National Security Agency, Air Force Intelli-
          gence, and authorities in West Germany), five men in  Hannover,
          West  Germany  were  arrested.   In  March  1989, the five were
          charged with espionage: they had been selling the material they
          found  during  their exploits to the KGB.  One of the men, Karl
          Koch (%%Hagbard''), was later found burned to death in an  iso-
          lated  forest  outside  Hannover.   No  suicide  note was found
          [Stol89].  In February 1990, three  of  the  intruders  (Markus
          Hess,  Dirk  Bresinsky,  and  Peter  Carl)  were  convicted  of
          espionage in a German court  and  sentenced  to  prison  terms,
          fines, and the loss of their rights to participate in elections
          [Risk90].  The last of the intruders, Hans Hu"bner  (%%Pengo''),
          still faces trial in Berlin.
                                        3
        1.4   OTHER BREAK-INS
               Numerous other computer security problems have occurred in
          recent  years,  with  varying levels of publicity.  Some of the
          more widely known incidents include break-ins  on  NASA's  SPAN
          network [McLe87], the IBM %%Christmas Virus'' [Risk87], a virus
          at Mitre Corp. that caused the MILNET to  be  temporarily  iso-
          lated from other networks [Risk88], a worm that penetrated DEC-
          NET networks [Risk89a], break-ins on  U.  S.  banking  networks
          [Risk89b], and a multitude of viruses, worms, and trojan horses
          affecting personal computer users.
        1.5   SECURITY IS IMPORTANT
               As the previous stories demonstrate, computer security  is
          an  important  topic.   This  document  describes  the security
          features provided by the UNIX operating system,  and  how  they
          should  be  used.  The discussion centers around version 4._x of
          SunOS, the version of UNIX sold by Sun Microsystems.   Most  of
          the  information  presented  applies equally well to other UNIX
          systems.  Although there is no way  to  make  a  computer  com-
          pletely  secure against unauthorized use (other than to lock it
          in a room and turn it off), by following  the  instructions  in
          this  document  you  can  make  your  system impregnable to the
          %%casual'' system cracker,* and make it more difficult for  the
          sophisticated cracker to penetrate.
        _________________________
          * The term %%hacker,'' as applied to computer users, originally
        had  an honorable connotation: %%a person who enjoys learning the
        details of programming systems and how to stretch their capabili-
        ties - as opposed to most users of computers, who prefer to learn
        only the minimum amount necessary'' [Stee88].  Unfortunately, the
        media  has  distorted this definition and given it a dishonorable
        meaning.  In deference to the true hackers, we will use the  term
        %%cracker'' throughout this document.
                                        4
                                     SECTION 2
                                IMPROVING SECURITY
               UNIX system security can be divided into three main  areas
          of  concern.   Two of these areas, account security and network
          security, are primarily  concerned  with  keeping  unauthorized
          users  from gaining access to the system.  The third area, file
          system security,  is  concerned  with  preventing  unauthorized
          access,  either  by  legitimate  users or crackers, to the data
          stored in the system.  This section describes the UNIX security
          tools  provided to make each of these areas as secure as possi-
          ble.
        2.1   ACCOUNT SECURITY
               One of the easiest ways for a cracker to get into a system
          is by breaking into someone's account.  This is usually easy to
          do, since many systems have old accounts whose users have  left
          the organization, accounts with easy-to-guess passwords, and so
          on.  This section describes methods that can be used  to  avoid
          these problems.
        2.1.1   Passwords
               The password is the most vital part of UNIX account  secu-
          rity.  If a cracker can discover a user's password, he can then
          log in to the system and operate with all the  capabilities  of
          that user.  If the password obtained is that of the super-user,
          the problem is more serious: the cracker  will  have  read  and
          write  access  to  every  file on the system.  For this reason,
          choosing secure passwords is extremely important.
               The UNIX _p_a_s_s_w_d program [Sun88a, 379] places very few res-
          trictions  on  what  may  be used as a password.  Generally, it
          requires that passwords contain five or more lowercase letters,
          or  four  characters  if a nonalphabetic or uppercase letter is
          included.  However, if the  user  %%insists''  that  a  shorter
          password be used (by entering it three times), the program will
          allow it.  No checks  for  obviously  insecure  passwords  (see
          below)  are  performed.   Thus, it is incumbent upon the system
          administrator to ensure that the passwords in use on the system
          are secure.
                                        5
               In [Morr78], the authors describe experiments conducted to
          determine typical users' habits in the choice of passwords.  In
          a collection of 3,289 passwords, 16% of  them  contained  three
          characters or less, and an astonishing 86% were what could gen-
          erally be described as  insecure.   Additional  experiments  in
          [Gram84]  show  that  by  trying  three  simple guesses on each
          account - the login name, the login name in  reverse,  and  the
          two  concatenated  together  -  a  cracker can expect to obtain
          access to between 8 and 30 percent of the accounts on a typical
          system.   A second experiment showed that by trying the 20 most
          common female first names, followed by a single digit (a  total
          of  200  passwords), at least one password was valid on each of
          several dozen machines surveyed.   Further  experimentation  by
          the  author  has  found  that by trying variations on the login
          name, user's first and last names, and a list  of  nearly  1800
          common  first  names, up to 50  percent of the passwords on any
          given system can be cracked in a matter of two or three days.
        2.1.1.1   Selecting Passwords
               The object when choosing a password is to make it as  dif-
          ficult as possible for a cracker to make educated guesses about
          what you've chosen.  This  leaves  him  no  alternative  but  a
          brute-force   search,  trying  every  possible  combination  of
          letters, numbers, and punctuation.  A search of this sort, even
          conducted on a machine that could try one million passwords per
          second (most  machines  can  try  less  than  one  hundred  per
          second),  would require, on the average, over one hundred years
          to complete.  With this as our goal, and by using the  informa-
          tion  in  the  preceding text, a set of guidelines for password
          selection can be constructed:
               o+    _D_o_n'_t  use  your  login  name  in  any  form  (as-is,
                    reversed, capitalized, doubled, etc.).
               o+    _D_o_n'_t use your first or last name in any form.
               o+    _D_o_n'_t use your spouse's or child's name.
               o+    _D_o_n'_t use other  information  easily  obtained  about
                    you.   This includes license plate numbers, telephone
                    numbers, social security numbers, the brand  of  your
                    automobile, the name of the street you live on, etc.
               o+    _D_o_n'_t use a password of all digits, or all  the  same
                    letter.  This significantly decreases the search time
                    for a cracker.
               o+    _D_o_n'_t use a word contained  in  (English  or  foreign
                                        6
                    language)  dictionaries,  spelling  lists,  or  other
                    lists of words.
               o+    _D_o_n'_t use a password shorter than six characters.
               o+    _D_o use a password with mixed-case alphabetics.
               o+    _D_o use  a  password  with  nonalphabetic  characters,
                    e.g., digits or punctuation.
               o+    _D_o use a password that is easy to  remember,  so  you
                    don't have to write it down.
               o+    _D_o use a password that you can type quickly,  without
                    having to look at the keyboard.  This makes it harder
                    for someone to steal your password by  watching  over
                    your shoulder.
               Although this list may seem to restrict  passwords  to  an
          extreme,  there  are several methods for choosing secure, easy-
          to-remember passwords that obey the above rules.  Some of these
          include the following:
               o+    Choose a line or two from a song or poem, and use the
                    first  letter of each word.  For example, %%In Xanadu
                    did Kubla  Kahn  a  stately  pleasure  dome  decree''
                    becomes %%IXdKKaspdd.''
               o+    Alternate  between  one  consonant  and  one  or  two
                    vowels,  up  to eight characters.  This provides non-
                    sense words that are usually pronounceable, and  thus
                    easily  remembered.   Examples  include  %%routboo,''
                    %%quadpop,'' and so on.
               o+    Choose two short words and concatenate them  together
                    with  a punctation character between them.  For exam-
                    ple: %%dog;rain,'' %%book+mug,'' %%kid?goat.''
               The importance of obeying these password  selection  rules
          cannot  be  overemphasized.   The Internet worm, as part of its
          strategy for breaking into new  machines,  attempted  to  crack
          user  passwords.   First, the worm tried simple choices such as
          the login name, user's first and last names, and so on.   Next,
          the  worm  tried each word present in an internal dictionary of
          432 words (presumably  Morris  considered  these  words  to  be
          %%good''  words  to  try).   If all else failed, the worm tried
          going through the system  dictionary,  /_u_s_r/_d_i_c_t/_w_o_r_d_s,  trying
          each  word  [Spaf88].   The password selection rules above suc-
          cessfully guard against all three of these strategies.
                                        7
        2.1.1.2   Password Policies
               Although asking users to select secure passwords will help
          improve  security,  by  itself  it  is  not enough.  It is also
          important to form a set of password  policies  that  all  users
          must obey, in order to keep the passwords secure.
               First and foremost, it is important to  impress  on  users
          the  need  to  keep their passwords in their minds only.  Pass-
          words should never be written down on desk blotters, calendars,
          and  the like.  Further, storing passwords in files on the com-
          puter must be prohibited.  In either case, by writing the pass-
          word  down  on  a  piece  of paper or storing it in a file, the
          security of the user's account  is  totally  dependent  on  the
          security  of  the paper or file, which is usually less than the
          security offered by the password encryption software.
               A second important policy is that users  must  never  give
          out  their  passwords to others.  Many times, a user feels that
          it is easier to give someone else his password in order to copy
          a  file,  rather  than to set up the permissions on the file so
          that it can be copied.  Unfortunately, by giving out the  pass-
          word  to  another person, the user is placing his trust in this
          other person not to distribute the password further,  write  it
          down, and so on.
               Finally, it is important to establish a policy that  users
          must  change  their  passwords  from  time to time, say twice a
          year.  This is difficult to enforce  on  UNIX,  since  in  most
          implementations, a password-expiration scheme is not available.
          However, there are ways to implement  this  policy,  either  by
          using  third-party  software  or by sending a memo to the users
          requesting that they change their passwords.
               This set of policies should be printed and distributed  to
          all  current  users  of the system.  It should also be given to
          all new users when they receive  their  accounts.   The  policy
          usually  carries  more  weight  if you can get it signed by the
          most %%impressive'' person  in  your  organization  (e.g.,  the
          president of the company).
        2.1.1.3   Checking Password Security
               The procedures and policies described in the previous sec-
          tions,  when  properly  implemented,  will  greatly  reduce the
          chances of a cracker breaking into your  system  via  a  stolen
          account.   However,  as  with all security measures, you as the
                                        8
          system administrator must periodically check to  be  sure  that
          the  policies  and procedures are being adhered to.  One of the
          unfortunate truisms of password security  is  that,  %%left  to
          their own ways, some people will still use cute doggie names as
          passwords'' [Gram84].
               The best way to check the security  of  the  passwords  on
          your  system  is to use a password-cracking program much like a
          real cracker would use.  If you succeed in cracking  any  pass-
          words,  those  passwords  should be changed immediately.  There
          are a few freely available password cracking  programs  distri-
          buted  via various source archive sites; these are described in
          more detail in Section 4.  A fairly extensive cracking  program
          is  also  available  from  the  author.  Alternatively, you can
          write your own cracking program, and  tailor  it  to  your  own
          site.   For  a  list  of  things  to check for, see the list of
          guidelines above.
        2.1.2   Expiration Dates
               Many sites, particularly those  with  a  large  number  of
          users,  typically  have several old accounts lying around whose
          owners have since left the organization.  These accounts are  a
          major  security  hole:  not only can they be broken into if the
          password is insecure, but because nobody is using  the  account
          anymore, it is unlikely that a break-in will be noticed.
               The simplest way to prevent unused accounts  from  accumu-
          lating  is to place an expiration date on every account.  These
          expiration dates should be near enough in the future  that  old
          accounts  will  be  deleted  in a timely manner, yet far enough
          apart that the users will not become annoyed.  A good figure is
          usually one year from the date the account was installed.  This
          tends to spread the expirations out over the year, rather  than
          clustering  them  all  at the beginning or end.  The expiration
          date can easily be stored in the password  file  (in  the  full
          name field).  A simple shell script can be used to periodically
          check that all accounts have expiration dates, and that none of
          the dates has passed.
               On the first day of each month, any user whose account has
          expired  should be contacted to be sure he is still employed by
          the organization, and that he is actively  using  the  account.
          Any  user  who  cannot  be  contacted,  or who has not used his
          account recently, should be deleted from the system.  If a user
          is  unavailable  for some reason (e.g., on vacation) and cannot
          be contacted, his account should be disabled by  replacing  the
          encrypted  password in the password file entry with an asterisk
          (*).  This makes it impossible to log in to  the  account,  yet
                                        9
          leaves  the  account  available  to be re-enabled on the user's
          return.
        2.1.3   Guest Accounts
               Guest accounts present still another  security  hole.   By
          their  nature,  these  accounts are rarely used, and are always
          used by people who should only have access to the  machine  for
          the  short period of time they are guests.  The most secure way
          to handle guest accounts is to install  them  on  an  as-needed
          basis,  and delete them as soon as the people using them leave.
          Guest accounts should never be given simple passwords  such  as
          %%guest'' or %%visitor,'' and should never be allowed to remain
          in the password file when they are not being used.
        2.1.4   Accounts Without Passwords
               Some sites have installed  accounts  with  names  such  as
          %%who,''  %%date,'' %%lpq,'' and so on that execute simple com-
          mands.  These accounts are intended to allow users  to  execute
          these  commands without having to log in to the machine.  Typi-
          cally these accounts have no password associated with them, and
          can  thus  be used by anyone.  Many of the accounts are given a
          user id of zero, so that they execute with  super-user  permis-
          sions.
               The problem with these accounts is that they  open  poten-
          tial  security  holes.  By not having passwords on them, and by
          having  super-user  permissions,  these  accounts   practically
          invite  crackers  to  try  to  penetrate them.  Usually, if the
          cracker can  gain  access  to  the  system,  penetrating  these
          accounts  is  simple, because each account executes a different
          command.  If the cracker can replace any one of these  commands
          with one of his own, he can then use the unprotected account to
          execute his program with super-user permissions.
               Simply put,  accounts  without  passwords  should  not  be
          allowed on any UNIX system.
        2.1.5   Group Accounts and Groups
               Group accounts have become popular at many sites, but  are
          actually  a  break-in  waiting to happen.  A group account is a
                                       10
          single account shared by several people, e.g., by all the  col-
          laborators  on a project.  As mentioned in the section on pass-
          word security, users should not share  passwords  -  the  group
          account  concept directly violates this policy.  The proper way
          to allow users to share information, rather than giving them  a
          group  account  to  use,  is to place these users into a group.
          This is done by editing the  group  file,  /_e_t_c/_g_r_o_u_p  [Sun88a,
          1390;  Sun88b, 66], and creating a new group with the users who
          wish to collaborate listed as members.
               A line in the group file looks like
                  groupname:password:groupid:user1,user2,user3,...
          The _g_r_o_u_p_n_a_m_e is the name assigned to the group,  much  like  a
          login  name.   It  may  be the same as someone's login name, or
          different.  The maximum length of a group name is eight charac-
          ters.   The password field is unused in BSD-derived versions of
          UNIX, and should contain an asterisk (*).   The  _g_r_o_u_p_i_d  is  a
          number  from 0 to 65535 inclusive.  Generally, numbers below 10
          are reserved for special  purposes,  but  you  may  choose  any
          unused number.  The last field is a comma-separated (no spaces)
          list of the login names of the users in the group.  If no login
          names  are  listed, then the group has no members.  To create a
          group called %%hackers'' with Huey, Duey, and Louie as members,
          you would add a line such as this to the group file:
                  hackers:*:100:huey,duey,louie
               After the group has been created,  the  files  and  direc-
          tories  the  members  wish to share can then be changed so that
          they are owned by this group, and the group permission bits  on
          the  files  and  directories can be set to allow sharing.  Each
          user retains his own account, with his own password, thus  pro-
          tecting the security of the system.
               For example, to change Huey's %%programs'' directory to be
          owned  by  the new group and properly set up the permissions so
          that all members of the group may  access  it,  the  _c_h_g_r_p  and
          _c_h_m_o_d commands would be used as follows [Sun88a, 63-66]:
                  # chgrp hackers %huey/programs
                  # chmod -R g+rw %huey/programs
        2.1.6   Yellow Pages
               The Sun Yellow Pages system [Sun88b, 349-374] allows  many
                                       11
          hosts to share password files, group files, and other files via
          the network, while the files are stored on only a single  host.
          Unfortunately, Yellow Pages also contains a few potential secu-
          rity holes.
               The principal way Yellow Pages works is to have a  special
          line  in  the  password or group file that begins with a %%+''.
          In the password file, this line looks like
                  +::0:0:::
          and in the group file, it looks like
                  +:
          These lines should only be present in the files stored on  Yel-
          low  Pages  client machines.  They should not be present in the
          files on the Yellow Pages master machine(s).   When  a  program
          reads  the  password  or group file and encounters one of these
          lines, it goes through the network and requests the information
          it wants from the Yellow Pages server instead of trying to find
          it in the local file.  In this way, the data does not  have  to
          be  maintained on every host.  Since the master machine already
          has all the information, there is no need for this special line
          to be present there.
               Generally speaking, the Yellow  Pages  service  itself  is
          reasonably  secure.   There are a few openings that a sophisti-
          cated (and dedicated) cracker could exploit, but Sun is rapidly
          closing  these.   The  biggest problem with Yellow Pages is the
          %%+'' line in the password file.  If the %%+'' is deleted  from
          the  front of the line, then this line loses its special Yellow
          Pages meaning.  It instead becomes a regular password file line
          for an account with a null login name, no password, and user id
          zero (super-user).  Thus, if a  careless  system  administrator
          accidentally  deletes the %%+''.  the whole system is wide open
          to any attack.*
               Yellow Pages is too useful a service to suggest turning it
          off,  although  turning  it  off  would  make  your system more
          secure.  Instead, it is recommended that you read carefully the
          information  in  the  Sun manuals in order to be fully aware of
          Yellow Pages' abilities and its limitations.
        2.2   NETWORK SECURITY
        _________________________
          * Actually, a line like this without a %%+''  is  dangerous  in
        any password file, regardless of whether Yellow Pages is in use.
                                       12
               As trends  toward  internetworking  continue,  most  sites
          will, if they haven't already, connect themselves to one of the
          numerous regional networks springing  up  around  the  country.
          Most  of these regional networks are also interconnected, form-
          ing the Internet [Hind83, Quar86].  This means that  the  users
          of  your  machine  can  access other hosts and communicate with
          other users around the world.   Unfortunately,  it  also  means
          that  other  hosts  and  users from around the world can access
          your machine, and attempt to break into it.
               Before internetworking became  commonplace,  protecting  a
          system  from  unauthorized  access  simply  meant  locking  the
          machine in a room by itself.  Now that machines  are  connected
          by networks, however, security is much more complex.  This sec-
          tion describes the tools and methods  available  to  make  your
          UNIX networks as secure as possible.
        2.2.1   Trusted Hosts
               One of the most convenient features of the  Berkeley  (and
          Sun)  UNIX  networking  software  is the concept of %%trusted''
          hosts.  The software allows the specification  of  other  hosts
          (and  possibly users) who are to be considered trusted - remote
          logins and remote command executions from these hosts  will  be
          permitted without requiring the user to enter a password.  This
          is very convenient, because users do not  have  to  type  their
          password  every  time they use the network.  Unfortunately, for
          the same  reason,  the  concept  of  a  trusted  host  is  also
          extremely insecure.
               The Internet worm made extensive use of the  trusted  host
          concept to spread itself throughout the network [Seel88].  Many
          sites that had already disallowed trusted hosts did fairly well
          against  the  worm  compared  with  those  sites that did allow
          trusted hosts.  Even though it is a security  hole,  there  are
          some  valid  uses  for  the trusted host concept.  This section
          describes how to properly implement the trusted hosts  facility
          while preserving as much security as possible.
        2.2.1.1   The hosts.equiv File
               The file /_e_t_c/_h_o_s_t_s._e_q_u_i_v [Sun88a, 1397] can  be  used  by
          the  system  administrator  to  indicate  trusted  hosts.  Each
          trusted host is listed in the file, one host per  line.   If  a
          user  attempts  to  log  in (using _r_l_o_g_i_n) or execute a command
          (using  _r_s_h)  remotely  from  one  of  the  systems  listed  in
                                       13
          _h_o_s_t_s._e_q_u_i_v,  and  that user has an account on the local system
          with the same login name, access is permitted without requiring
          a password.
               Provided adequate care is taken to allow only local  hosts
          in  the _h_o_s_t_s._e_q_u_i_v file, a reasonable compromise between secu-
          rity and convenience can be achieved.  Nonlocal hosts  (includ-
          ing  hosts  at  remote  sites  of the same organization) should
          never be trusted.  Also, if there  are  any  machines  at  your
          organization that are installed in %%public'' areas (e.g., ter-
          minal rooms) as opposed to  private  offices,  you  should  not
          trust these hosts.
               On Sun systems, _h_o_s_t_s._e_q_u_i_v is controlled with the  Yellow
          Pages  software.   As distributed, the default _h_o_s_t_s._e_q_u_i_v file
          distributed by Sun contains a single line:
                  +
          This indicates that _e_v_e_r_y _k_n_o_w_n _h_o_s_t (i.e., the  complete  con-
          tents  of  the  host file) should be considered a trusted host.
          This is totally incorrect and  a  major  security  hole,  since
          hosts  outside  the local organization should never be trusted.
          A  correctly  configured  _h_o_s_t_s._e_q_u_i_v  should  never  list  any
          %%wildcard''  hosts  (such  as  the  %%+''); only specific host
          names should be used.  When installing a new  system  from  Sun
          distribution  tapes,  you  should be sure to either replace the
          Sun default _h_o_s_t_s._e_q_u_i_v with a  correctly  configured  one,  or
          delete the file altogether.
        2.2.1.2   The .rhosts File
               The ._r_h_o_s_t_s file [Sun88a, 1397] is similar in concept  and
          format  to the _h_o_s_t_s._e_q_u_i_v file, but allows trusted access only
          to specific host-user combinations, rather  than  to  hosts  in
          general.* Each user may create  a  ._r_h_o_s_t_s  file  in  his  home
          directory,  and allow access to her account without a password.
          Most people use this mechanism to allow trusted access  between
          accounts  they have on systems owned by different organizations
          who do not trust each other's  hosts  in  _h_o_s_t_s._e_q_u_i_v.   Unfor-
          tunately,  this  file  presents a major security problem: While
          _h_o_s_t_s._e_q_u_i_v is under the system administrator's control and can
          be  managed  effectively,  any  user  may create a ._r_h_o_s_t_s file
          granting access to whomever  he  chooses,  without  the  system
          administrator's knowledge.
        _________________________
          * Actually, _h_o_s_t_s._e_q_u_i_v may be used to specify host-user combi-
        nations as well, but this is rarely done.
                                       14
               The only secure way to manage ._r_h_o_s_t_s  files  is  to  com-
          pletely  disallow them on the system.  The system administrator
          should check the system often for  violations  of  this  policy
          (see  Section 3.3.1.4).  One possible exception to this rule is
          the %%root'' account; a ._r_h_o_s_t_s file may be necessary to  allow
          network backups and the like to be completed.
        2.2.2   Secure Terminals
               Under newer versions of UNIX, the concept of a  %%secure''
          terminal  has  been  introduced.   Simply  put,  the super-user
          (%%root'') may not log in on a nonsecure terminal, even with  a
          password.   (Authorized  users  may still use the _s_u command to
          become super-user,  however.)  The  file  /_e_t_c/_t_t_y_t_a_b  [Sun88a,
          1478]  is  used  to  control  which  terminals  are  considered
          secure.|- A short excerpt from this file is shown below.
                  console  "/usr/etc/getty std.9600"  sun      off secure
                  ttya     "/usr/etc/getty std.9600"  unknown  off secure
                  ttyb     "/usr/etc/getty std.9600"  unknown  off secure
                  ttyp0    none                       network  off secure
                  ttyp1    none                       network  off secure
                  ttyp2    none                       network  off secure
          The keyword %%secure'' at the end of each line  indicates  that
          the terminal is considered secure.  To remove this designation,
          simply edit the file and delete the %%secure'' keyword.   After
          saving the file, type the command (as super-user):
                  # kill -HUP 1
          This tells the _i_n_i_t process to reread the _t_t_y_t_a_b file.
               The Sun default configuration for _t_t_y_t_a_b  is  to  consider
          all  terminals  secure,  including %%pseudo'' terminals used by
          the remote login software.  This means that %%root'' may log in
          remotely  from  any  host on the network.  A more secure confi-
          guration would consider as secure only directly connected  ter-
          minals,  or  perhaps only the console device.  This is how file
          servers and other machines with disks should be set up.
               The most secure configuration is to remove the  %%secure''
          designation  from  all terminals, including the console device.
          This requires that those users with super-user authority  first
          log in as themselves, and then become the super-user via the _s_u
        _________________________
          |- Under non-Sun versions of Berkeley UNIX, this file is  called
        /_e_t_c/_t_t_y_s.
                                       15
          command.  It also requires the %%root'' password to be  entered
          when  rebooting  in single-user mode, in order to prevent users
          from rebooting their desktop workstations and obtaining  super-
          user  access.   This is how all diskless client machines should
          be set up.
        2.2.3   The Network File System
               The Network File System  (NFS)  [Sun88d]  is  designed  to
          allow  several  hosts  to share files over the network.  One of
          the most common uses of NFS is to allow  diskless  workstations
          to be installed in offices, while keeping all disk storage in a
          central location.  As distributed by Sun, NFS has  no  security
          features enabled.  This means that any host on the Internet may
          access your files via NFS, regardless of whether you trust them
          or not.
               Fortunately, there are several easy ways to make NFS  more
          secure.   The  more commonly used methods are described in this
          section, and these can be used to make your files quite  secure
          from  unauthorized  access  via NFS.  Secure NFS, introduced in
          SunOS Release 4.0,  takes  security  one  step  further,  using
          public-key  encryption  techniques to ensure authorized access.
          Discussion of secure NFS is deferred until Section 4.
        2.2.3.1   The exports File
               The file /_e_t_c/_e_x_p_o_r_t_s [Sun88a, 1377] is perhaps one of the
          most  important  parts  of  NFS configuration.  This file lists
          which file systems are exported (made available  for  mounting)
          to  other  systems.  A typical _e_x_p_o_r_t_s file as installed by the
          Sun installation procedure looks something like this:
                  /usr
                  /home
                  /var/spool/mail
                  #
                  /export/root/client1    -access=client1,root=client1
                  /export/swap/client1    -access=client1,root=client1
                  #
                  /export/root/client2    -access=client2,root=client2
                  /export/swap/client2    -access=client2,root=client2
          The _r_o_o_t= keyword specifies the list of hosts that are  allowed
          to  have  super-user  access  to  the  files  in the named file
          system.   This  keyword  is  discussed  in  detail  in  Section
                                       16
          2.2.3.3.   The  _a_c_c_e_s_s=  keyword  specifies  the  list of hosts
          (separated by colons) that are allowed to mount the named  file
          system.   If no _a_c_c_e_s_s= keyword is specified for a file system,
          any host anywhere on the network may mount that file system via
          NFS.
               Obviously, this presents a major security  problem,  since
          anyone  who can mount your file systems via NFS can then peruse
          them at her leisure.  Thus, it is important that all file  sys-
          tems  listed in _e_x_p_o_r_t_s have an _a_c_c_e_s_s= keyword associated with
          them.  If you have only a few hosts which  must  mount  a  file
          system, you can list them individually in the file:
                  /usr    -access=host1:host2:host3:host4:host5
          However, because the maximum number of hosts that can be listed
          this  way is ten, the _a_c_c_e_s_s= keyword will also allow netgroups
          to be specified.  Netgroups are described in the next section.
               After making any changes to the _e_x_p_o_r_t_s file,  you  should
          run the command
                  # exportfs -a
          in order to make the changes take effect.
        2.2.3.2   The netgroup File
               The file /_e_t_c/_n_e_t_g_r_o_u_p [Sun88a, 1407] is  used  to  define
          netgroups.   This  file is controlled by Yellow Pages, and must
          be rebuilt in the Yellow Pages maps whenever  it  is  modified.
          Consider the following sample _n_e_t_g_r_o_u_p file:
                  A_Group      (servera,,) (clienta1,,) (clienta2,,)
                  B_Group      (serverb,,) (clientb1,,) (clientb2,,)
                  AdminStaff   (clienta1,mary,) (clientb3,joan,)
                  AllSuns      A_Group B_Group
          This file defines  four  netgroups,  called  _A__G_r_o_u_p,  _B__G_r_o_u_p,
          _A_d_m_i_n_S_t_a_f_f,  and  _A_l_l_S_u_n_s.   The _A_l_l_S_u_n_s netgroup is actually a
          %%super group'' containing all the members of the  _A__G_r_o_u_p  and
          _B__G_r_o_u_p netgroups.
               Each member of a netgroup is defined as a  triple:  (host,
          user,  domain).  Typically, the _d_o_m_a_i_n field is never used, and
          is simply left blank.  If either the _h_o_s_t or _u_s_e_r field is left
                                       17
          blank,  then any host or user is considered to match.  Thus the
          triple (host,,) matches any user on the named host,  while  the
          triple (,user,) matches the named user on any host.
               Netgroups are useful when restricting access to  NFS  file
          systems via the _e_x_p_o_r_t_s file.  For example, consider this modi-
          fied version of the file from the previous section:
                  /usr                    -access=A_Group
                  /home                   -access=A_Group:B_Group
                  /var/spool/mail         -access=AllSuns
                  #
                  /export/root/client1    -access=client1,root=client1
                  /export/swap/client1    -access=client1,root=client1
                  #
                  /export/root/client2    -access=client2,root=client2
                  /export/swap/client2    -access=client2,root=client2
          The /_u_s_r file system may now only be mounted by  the  hosts  in
          the _A__G_r_o_u_p netgroup, that is, _s_e_r_v_e_r_a, _c_l_i_e_n_t_a_1, and _c_l_i_e_n_t_a_2.
          Any other host that  tries  to  mount  this  file  system  will
          receive  an %%access denied'' error.  The /_h_o_m_e file system may
          be mounted by any of the hosts in either the _A__G_r_o_u_p or _B__G_r_o_u_p
          netgroups.   The /_v_a_r/_s_p_o_o_l/_m_a_i_l file system is also restricted
          to these hosts, but in this example we used the %%super group''
          called _A_l_l_S_u_n_s.
               Generally, the best way to configure the _n_e_t_g_r_o_u_p file  is
          to make a single netgroup for each file server and its clients,
          and then to make other super groups,  such  as  _A_l_l_S_u_n_s.   This
          allows  you  the  flexibility  to specify the smallest possible
          group of hosts for each file system in /_e_t_c/_e_x_p_o_r_t_s.
               Netgroups can also be used in the password file  to  allow
          access  to a given host to be restricted to the members of that
          group, and they can be used in the _h_o_s_t_s._e_q_u_i_v file to central-
          ize  maintenance  of the list of trusted hosts.  The procedures
          for doing this are defined in more detail in the Sun manual.
        2.2.3.3   Restricting Super-User Access
               Normally, NFS translates the super-user id to a special id
          called %%nobody'' in order to prevent a user with %%root'' on a
          remote workstation from accessing other people's  files.   This
          is  good  for  security,  but  sometimes  a nuisance for system
          administration, since you  cannot  make  changes  to  files  as
          %%root'' through NFS.
               The _e_x_p_o_r_t_s file  also  allows  you  to  grant  super-user
                                       18
          access  to  certain file systems for certain hosts by using the
          _r_o_o_t= keyword.  Following this keyword a  colon-separated  list
          of  up  to  ten  hosts  may  be  specified; these hosts will be
          allowed to access the file system as  %%root''  without  having
          the  user  id  converted  to  %%nobody.''  Netgroups may not be
          specified to the _r_o_o_t= keyword.
               Granting %%root'' access to a  host  should  not  be  done
          lightly.   If a host has %%root'' access to a file system, then
          the super-user on that host will have complete  access  to  the
          file system, just as if you had given him the %%root'' password
          on the server.  Untrusted hosts should never be given  %%root''
          access to NFS file systems.
        2.2.4   FTP
               The File Transfer Protocol, implemented  by  the  _f_t_p  and
          _f_t_p_d  programs  [Sun88a,  195-201,  1632-1634], allows users to
          connect to remote systems and transfer files  back  and  forth.
          Unfortunately,  older  versions  of  these  programs  also  had
          several bugs in them that allowed crackers to break into a sys-
          tem.   These bugs have been fixed by Berkeley, and new versions
          are available.  If your  _f_t_p_d*  was  obtained  before  December
          1988, you should get a newer version (see Section 4).
               One  of  the  more  useful  features   of   FTP   is   the
          %%anonymous''  login.   This  special login allows users who do
          not have an account on your machine to have  restricted  access
          in  order to transfer files from a specific directory.  This is
          useful if you wish to distribute  software  to  the  public  at
          large  without  giving  each  person  who wants the software an
          account on your machine.  In order to securely set up anonymous
          FTP you should follow the specific instructions below:
               1.   Create an account called %%ftp.'' Disable the account
                    by  placing  an  asterisk  (*) in the password field.
                    Give the account a special home  directory,  such  as
                    /_u_s_r/_f_t_p or /_u_s_r/_s_p_o_o_l/_f_t_p.
               2.   Make the home directory owned by %%ftp'' and  unwrit-
                    able by anyone:
                            # chown ftp %ftp
                            # chmod 555 %ftp
        _________________________
          * On Sun systems, _f_t_p_d is stored in the file  /_u_s_r/_e_t_c/_i_n._f_t_p_d.
        On most other systems, it is called /_e_t_c/_f_t_p_d.
                                       19
               3.   Make the directory %_f_t_p/_b_i_n, owned by the  super-user
                    and  unwritable  by  anyone.   Place a copy of the _l_s
                    program in this directory:
                            # mkdir %ftp/bin
                            # chown root %ftp/bin
                            # chmod 555 %ftp/bin
                            # cp -p /bin/ls %ftp/bin
                            # chmod 111 %ftp/bin/ls
               4.   Make the directory %_f_t_p/_e_t_c, owned by the  super-user
                    and  unwritable by anyone.  Place copies of the pass-
                    word and group files in this directory, with all  the
                    password  fields  changed  to asterisks (*).  You may
                    wish to delete all but a  few  of  the  accounts  and
                    groups  from  these files; the only account that must
                    be present is %%ftp.''
                            # mkdir %ftp/etc
                            # chown root %ftp/etc
                            # chmod 555 %ftp/etc
                            # cp -p /etc/passwd /etc/group %ftp/etc
                            # chmod 444 %ftp/etc/passwd %ftp/etc/group
               5.   Make the directory %_f_t_p/_p_u_b,  owned  by  %%ftp''  and
                    world-writable.   Users may then place files that are
                    to be accessible via anonymous FTP in this directory:
                            # mkdir %ftp/pub
                            # chown ftp %ftp/pub
                            # chmod 777 %ftp/pub
               Because the anonymous FTP feature allows anyone to  access
          your  system  (albeit  in a very limited way), it should not be
          made available on every host  on  the  network.   Instead,  you
          should  choose  one  machine (preferably a server or standalone
          host) on which to allow this service.   This  makes  monitoring
          for  security  violations  much easier.  If you allow people to
          transfer files to your machine (using  the  world-writable  _p_u_b
          directory,  described  above),  you should check often the con-
          tents of the directories into which they are allowed to  write.
          Any suspicious files you find should be deleted.
        2.2.4.1   Trivial FTP
               The Trivial File Transfer Protocol, TFTP, is used  on  Sun
                                       20
          workstations  (and others) to allow diskless hosts to boot from
          the network.  Basically, TFTP is a stripped-down version of FTP
          -  there is no user authentication, and the connection is based
          on the User Datagram Protocol instead of the Transmission  Con-
          trol  Protocol.  Because they are so stripped-down, many imple-
          mentations of TFTP have security holes.  You should check  your
          hosts by executing the command sequence shown below.
                  % tftp
                  tftp> connect _y_o_u_r_h_o_s_t
                  tftp> get /etc/motd tmp
                  _E_r_r_o_r _c_o_d_e _1: _F_i_l_e _n_o_t _f_o_u_n_d
                  _t_f_t_p> _q_u_i_t
                  %
          If your version does not respond with %%_F_i_l_e _n_o_t  _f_o_u_n_d,''  and
          instead  transfers the file, you should replace your version of
          _t_f_t_p_d* with a newer one.   In  particular,  versions  of  SunOS
          prior to release 4.0 are known to have this problem.
        2.2.5   Mail
               Electronic mail is one of the main reasons for  connecting
          to outside networks.  On most versions of Berkeley-derived UNIX
          systems,  including  those  from  Sun,  the  _s_e_n_d_m_a_i_l   program
          [Sun88a,  1758-1760;  Sun88b,  441-488]  is  used to enable the
          receipt and delivery of mail.  As with the FTP software,  older
          versions of _s_e_n_d_m_a_i_l have several bugs that allow security vio-
          lations.  One of these bugs was used with great success by  the
          Internet  worm  [Seel88, Spaf88].  The current version of _s_e_n_d_-
          _m_a_i_l from Berkeley is version 5.61, of January 1989.   Sun  is,
          as  of  this  writing, still shipping version 5.59, which has a
          known security problem.  They have, however, made a fixed  ver-
          sion  available.   Section  4 details how to obtain these newer
          versions.
               Generally, with the exception of the security  holes  men-
          tioned  above,  _s_e_n_d_m_a_i_l is reasonably secure when installed by
          most vendors' installation procedures.  There are,  however,  a
          few  precautions  that  should be taken to ensure secure opera-
          tion:
               1.   Remove the %%decode'' alias  from  the  aliases  file
                    (/_e_t_c/_a_l_i_a_s_e_s or /_u_s_r/_l_i_b/_a_l_i_a_s_e_s).
        _________________________
          * On   Sun   systems,   _t_f_t_p_d   is   stored   in    the    file
        /_u_s_r/_e_t_c/_i_n._t_f_t_p_d.    On   most   other  systems,  it  is  called
        /_e_t_c/_t_f_t_p_d.
                                       21
               2.   If you create aliases that allow messages to be  sent
                    to  programs, be absolutely sure that there is no way
                    to obtain a shell or send commands to  a  shell  from
                    these programs.
               3.   Make sure the %%wizard'' password is disabled in  the
                    configuration  file, _s_e_n_d_m_a_i_l._c_f.  (Unless you modify
                    the distributed configuration files,  this  shouldn't
                    be a problem.)
               4.   Make  sure  your  _s_e_n_d_m_a_i_l  does  not   support   the
                    %%debug'' command.  This can be done with the follow-
                    ing commands:
                    % telnet localhost 25
                    220 yourhost Sendmail 5.61 ready at 9 Mar 90 10:57:36 PST
                    debug
                    500 Command unrecognized
                    quit
                    %
                    If your _s_e_n_d_m_a_i_l responds to  the  %%debug''  command
                    with  %%_2_0_0  _D_e_b_u_g  _s_e_t,'' then you are vulnerable to
                    attack and should replace your _s_e_n_d_m_a_i_l with a  newer
                    version.
          By following the procedures above, you can be  sure  that  your
          mail system is secure.
        2.2.6   Finger
               The %%finger'' service, provided  by  the  _f_i_n_g_e_r  program
          [Sun88a,  186-187],  allows  you  to obtain information about a
          user such as her full name, home directory,  last  login  time,
          and  in  some cases when she last received mail and/or read her
          mail.  The _f_i_n_g_e_r_d  program  [Sun88a,  1625]  allows  users  on
          remote hosts to obtain this information.
               A bug in _f_i_n_g_e_r_d was also exercised with  success  by  the
          Internet worm [Seel88, Spaf88].  If your version of _f_i_n_g_e_r_d* is
          older than November 5, 1988, it should be replaced with a newer
          version.  New  versions  are  available  from  several  of  the
          sources described in Section 4.
        _________________________
          * On Sun systems, _f_i_n_g_e_r_d is stored in /_u_s_r/_e_t_c/_i_n._f_i_n_g_e_r_d.  On
        most other systems, it is called /_e_t_c/_f_i_n_g_e_r_d.
                                       22
        2.2.7   Modems and Terminal Servers
               Modems and  terminal  servers  (terminal  switches,  Annex
          boxes,  etc.) present still another potential security problem.
          The main problem with these devices is one of  configuration  -
          misconfigured hardware can allow security breaches.  Explaining
          how to configure every brand of modem and terminal server would
          require  volumes.   However,  the  following  items  should  be
          checked for on any modems or terminal servers installed at your
          site:
               1.   If a user dialed up to a modem hangs  up  the  phone,
                    the  system should log him out.  If it doesn't, check
                    the hardware connections and the kernel configuration
                    of the serial ports.
               2.   If a user logs off, the system should force the modem
                    to hang up.  Again, check the hardware connections if
                    this doesn't work.
               3.   If the connection from a terminal server to the  sys-
                    tem is broken, the system should log the user off.
               4.   If the terminal server is connected  to  modems,  and
                    the  user hangs up, the terminal server should inform
                    the system that the user has hung up.
               Most modem and terminal server manuals cover in detail how
          to  properly connect these devices to your system.  In particu-
          lar you should pay close attention to the  %%Carrier  Detect,''
          %%Clear to Send,'' and %%Request to Send'' connections.
        2.2.8   Firewalls
               One of the newer ideas in network security is  that  of  a
          _f_i_r_e_w_a_l_l.   Basically,  a  firewall is a special host that sits
          between  your  outside-world  network  connection(s)  and  your
          internal  network(s).   This  host  does  not  send out routing
          information about your internal network, and thus the  internal
          network is %%invisible'' from the outside.  In order to config-
          ure a firewall machine, the following considerations need to be
          taken:
               1.   The firewall does not advertise routes.   This  means
                    that users on the internal network must log in to the
                    firewall in order to access hosts on remote networks.
                    Likewise,  in  order  to  log  in  to  a  host on the
                                       23
                    internal network from the outside, a user must  first
                    log  in  to  the  firewall  machine.   This is incon-
                    venient, but more secure.
               2.   All electronic mail sent by your users must  be  for-
                    warded  to  the  firewall  machine  if  it  is  to be
                    delivered  outside  your   internal   network.    The
                    firewall  must  receive all incoming electronic mail,
                    and then redistribute it.  This can  be  done  either
                    with aliases for each user or by using name server MX
                    records.
               3.   The firewall machine should not mount any  file  sys-
                    tems  via NFS, or make any of its file systems avail-
                    able to be mounted.
               4.   Password security on the  firewall  must  be  rigidly
                    enforced.
               5.   The firewall host should not trust  any  other  hosts
                    regardless  of  where  they  are.   Furthermore,  the
                    firewall should not be trusted by any other host.
               6.   Anonymous FTP and other similar services should  only
                    be  provided  by  the firewall host, if they are pro-
                    vided at all.
               The purpose of the firewall is to  prevent  crackers  from
          accessing other hosts on your network.  This means, in general,
          that you must maintain strict and rigidly enforced security  on
          the  firewall,  but  the  other  hosts are less vulnerable, and
          hence security may be somewhat lax.  But  it  is  important  to
          remember  that  the  firewall  is  not  a complete cure against
          crackers - if a cracker can break into the firewall machine, he
          can then try to break into any other host on your network.
        2.3   FILE SYSTEM SECURITY
               The last defense against system crackers are  the  permis-
          sions  offered  by the file system.  Each file or directory has
          three sets of permission bits associated with it: one  set  for
          the  user who owns the file, one set for the users in the group
          with which the file is associated, and one set  for  all  other
          users  (the  %%world''  permissions).   Each set contains three
          identical permission bits, which control the following:
               _r_e_a_d     If set, the file or directory may  be  read.   In
                        the  case  of  a  directory, read access allows a
                        user to see the  contents  of  a  directory  (the
                                       24
                        names of the files contained therein), but not to
                        access them.
               _w_r_i_t_e    If set, the file  or  directory  may  be  written
                        (modified).   In  the  case of a directory, write
                        permission implies the ability to create, delete,
                        and  rename  files.   Note  that  the  ability to
                        remove a file is _n_o_t controlled  by  the  permis-
                        sions  on the file, but rather the permissions on
                        the directory containing the file.
               _e_x_e_c_u_t_e  If set, the file or  directory  may  be  executed
                        (searched).   In the case of a directory, execute
                        permission implies the ability  to  access  files
                        contained in that directory.
               In addition, a fourth permission bit is available in  each
          set  of  permissions.  This bit has a different meaning in each
          set of permission bits:
               _s_e_t_u_i_d  If set in the owner permissions, this bit controls
                       the  %%set  user  id''  (setuid) status of a file.
                       Setuid status means that when a  program  is  exe-
                       cuted,  it  executes  with  the permissions of the
                       user owning the program, in addition to  the  per-
                       missions  of  the user executing the program.  For
                       example, _s_e_n_d_m_a_i_l is setuid %%root,'' allowing  it
                       to  write files in the mail queue area, which nor-
                       mal users are not allowed  to  do.   This  bit  is
                       meaningless on nonexecutable files.
               _s_e_t_g_i_d  If set in the group permissions, this bit controls
                       the  %%set  group  id'' (setgid) status of a file.
                       This behaves in exactly the same way as the setuid
                       bit, except that the group id is affected instead.
                       This bit is meaningless  on  non-executable  files
                       (but see below).
               _s_t_i_c_k_y  If set in the world  permissions,  the  %%sticky''
                       bit  tells  the  operating  system  to  do special
                       things with the text image of an executable  file.
                       It  is  mostly  a  holdover from older versions of
                       UNIX, and has little if any use today.   This  bit
                       is  also  meaningless  on nonexecutable files (but
                       see below).
        2.3.1   Setuid Shell Scripts
             Shell scripts that have the setuid or  setgid  bits  set  on
                                       25
        them  are _n_o_t secure, regardless of how many safeguards are taken
        when writing them.  There are numerous software  packages  avail-
        able  that  claim  to  make  shell  scripts secure, but every one
        released so far has not managed to solve all the problems.
             Setuid and setgid shell scripts should never be  allowed  on
        any UNIX system.
        2.3.2   The Sticky Bit on Directories
             Newer versions of UNIX have attached a new  meaning  to  the
        sticky  bit.   When this bit is set on a directory, it means that
        users may not delete or rename other users' files in this  direc-
        tory.   This  is  typically  useful for the /_t_m_p directory.  Nor-
        mally, /_t_m_p  is  world-writable,  enabling  any  user  to  delete
        another  user's  files.  By setting the sticky bit on /_t_m_p, users
        may only delete their own files from this directory.
             To set the sticky bit on a directory, use the command
                # chmod o+t _d_i_r_e_c_t_o_r_y
        2.3.3   The Setgid Bit on Directories
             In SunOS 4.0, the setgid bit was also given a  new  meaning.
        Two  rules can be used for assigning group ownership to a file in
        SunOS:
             1.   The System V mechanism, which says that a  user's  pri-
                  mary  group id (the one listed in the password file) is
                  assigned to any file he creates.
             2.   The Berkeley mechanism, which says that the group id of
                  a file is set to the group id of the directory in which
                  it is created.
             If the setgid bit  is  set  on  a  directory,  the  Berkeley
        mechanism  is  enabled.   Otherwise,  the  System  V mechanism is
        enabled.  Normally, the Berkeley mechanism is used; this  mechan-
        ism must be used if creating directories for use by more than one
        member of a group (see Section 2.1.5).
             To set the setgid bit on a directory, use the command
                                       26
                # chmod g+s _d_i_r_e_c_t_o_r_y
        2.3.4   The umask Value
             When a file is created by a program, say a text editor or  a
        compiler,  it  is typically created with all permissions enabled.
        Since this is rarely desirable (you don't want other users to  be
        able  to write your files), the _u_m_a_s_k value is used to modify the
        set of permissions a file is created with.  Simply put, while the
        _c_h_m_o_d  command  [Sun88a,  65-66]  specifies  what  bits should be
        turned _o_n, the umask value specifies what bits should  be  turned
        _o_f_f.
             For example, the default umask on most systems is 022.  This
        means  that  write  permission  for the group and world should be
        turned off whenever a file is created.  If instead you wanted  to
        turn  off all group and world permission bits, such that any file
        you created would not be readable,  writable,  or  executable  by
        anyone except yourself, you would set your umask to 077.
             The umask value is specified in the ._c_s_h_r_c or ._p_r_o_f_i_l_e files
        read  by  the  shell  using the _u_m_a_s_k command [Sun88a, 108, 459].
        The %%root'' account should have the line
                umask 022
        in its /._c_s_h_r_c file, in order to prevent the accidental  creation
        of world-writable files owned by the super-user.
        2.3.5   Encrypting Files
             The standard UNIX _c_r_y_p_t command [Sun88a, 95] is not  at  all
        secure.  Although it is reasonable to expect that _c_r_y_p_t will keep
        the casual %%browser'' from reading a file, it will present noth-
        ing  more  than  a  minor  inconvenience to a determined cracker.
        _C_r_y_p_t implements a one-rotor machine along the lines of the  Ger-
        man  Enigma  (broken  in World War II).  The methods of attack on
        such a machine are well known, and a sufficiently large file  can
        usually  be  decrypted  in  a few hours even without knowledge of
        what the file contains [Reed84].   In  fact,  publicly  available
        packages  of  programs designed to %%break'' files encrypted with
        _c_r_y_p_t have been around for several years.
             There are software implementations of another algorithm, the
        Data  Encryption  Standard  (DES),  available  on  some  systems.
                                       27
        Although this algorithm is much more secure than  _c_r_y_p_t,  it  has
        never  been  proven  that  it  is totally secure, and many doubts
        about its security have been raised in recent years.
             Perhaps the best thing to say about encrypting  files  on  a
        computer  system is this: if you think you have a file whose con-
        tents are important enough to encrypt, then that file should  not
        be stored on the computer in the first place.  This is especially
        true of systems with limited security, such as UNIX  systems  and
        personal computers.
             It  is  important  to  note  that  UNIX  passwords  are  _n_o_t
        encrypted  with  the  _c_r_y_p_t program.  Instead, they are encrypted
        with a modified version of the DES that generates one-way encryp-
        tions  (that is, the password cannot be decrypted).  When you log
        in, the system does  not  decrypt  your  password.   Instead,  it
        encrypts  your  attempted  password, and if this comes out to the
        same result as encrypting your real password, you are allowed  to
        log in.
        2.3.6   Devices
             The security of devices is an important issue in UNIX.  Dev-
        ice files (usually residing in /_d_e_v) are used by various programs
        to access the data on the disk drives or  in  memory.   If  these
        device files are not properly protected, your system is wide open
        to a cracker.  The entire list of devices is too long to go  into
        here, since it varies widely from system to system.  However, the
        following guidelines apply to all systems:
             1.   The files /_d_e_v/_k_m_e_m,  /_d_e_v/_m_e_m,  and  /_d_e_v/_d_r_u_m  should
                  never  be  readable  by the world.  If your system sup-
                  ports the notion of the %%kmem'' group (most newer sys-
                  tems  do) and utilities such as _p_s are setgid %%kmem,''
                  then these files should be owned by user  %%root''  and
                  group %%kmem,'' and should be mode 640.  If your system
                  does not support the notion of the %%kmem'' group,  and
                  utilities  such  as  _p_s are setuid %%root,'' then these
                  files should be owned by user %%root'' and mode 600.
             2.   The disk devices, such as /_d_e_v/_s_d_0_a, /_d_e_v/_r_x_y_1_b,  etc.,
                  should  be  owned  by  user %%root'' and group %%opera-
                  tor,'' and should be mode 640.  Note that each disk has
                  eight  partitions  and two device files for each parti-
                  tion.  Thus, the disk %%sd0'' would have the  following
                  device files associated with it in /_d_e_v:
                                       28
                          sd0a     sd0e     rsd0a     rsd0e
                          sd0b     sd0f     rsd0b     rsd0f
                          sd0c     sd0g     rsd0c     rsd0g
                          sd0d     sd0h     rsd0d     rsd0h
             3.   With very few exceptions, all other devices  should  be
                  owned  by  user  %%root.''  One exception is terminals,
                  which are changed to be owned  by  the  user  currently
                  logged  in on them.  When the user logs out, the owner-
                  ship of the terminal is automatically changed  back  to
                  %%root.''
        2.4   SECURITY IS YOUR RESPONSIBILITY
             This section has detailed numerous tools for improving secu-
        rity  provided  by the UNIX operating system.  The most important
        thing to note about these tools is that although they are  avail-
        able,  they  are  typically not put to use in most installations.
        Therefore, it is incumbent on you, the system  administrator,  to
        take the time and make the effort to enable these tools, and thus
        to protect your system from unauthorized access.
                                       29
                                       30
                                    SECTION 3
                               MONITORING SECURITY
             One of the most important tasks in keeping any computer sys-
        tem  secure  is  monitoring  the  security  of  the system.  This
        involves examining system log files for unauthorized accesses  of
        the  system, as well as monitoring the system itself for security
        holes.  This section describes the procedures for doing this.  An
        additional  part  of monitoring security involves keeping abreast
        of security problems found by others; this is described  in  Sec-
        tion 5.
        3.1   ACCOUNT SECURITY
             Account security should be monitored periodically  in  order
        to  check for two things: users logged in when they %%shouldn't''
        be (e.g., late at night, when they're  on  vacation,  etc.),  and
        users  executing  commands  they wouldn't normally be expected to
        use.  The commands described in  this  section  can  be  used  to
        obtain this information from the system.
        3.1.1   The lastlog File
             The file /_u_s_r/_a_d_m/_l_a_s_t_l_o_g [Sun88a, 1485]  records  the  most
        recent  login  time  for  each  user  of the system.  The message
        printed each time you log in, e.g.,
                Last login: Sat Mar 10 10:50:48 from spam.itstd.sri.c
        uses the time stored in the _l_a_s_t_l_o_g file.  Additionally, the last
        login  time reported by the _f_i_n_g_e_r command uses this time.  Users
        should be told to carefully examine this time whenever  they  log
        in,  and  to report unusual login times to the system administra-
        tor.  This is an easy way to detect account break-ins, since each
        user should remember the last time she logged into the system.
        3.1.2   The utmp and wtmp Files
             The file /_e_t_c/_u_t_m_p [Sun88a, 1485] is used to record  who  is
                                       31
        currently  logged  into  the  system.  This file can be displayed
        using the _w_h_o command [Sun88a, 597]:
                % who
                hendra   tty0c   Mar 13 12:31
                heidari  tty14   Mar 13 13:54
                welgem   tty36   Mar 13 12:15
                reagin   ttyp0   Mar 13 08:54   (aaifs.itstd.sri.)
                ghg      ttyp1   Mar  9 07:03   (hydra.riacs.edu)
                compion  ttyp2   Mar  1 03:01   (ei.ecn.purdue.ed)
        For each user, the login name, terminal being used,  login  time,
        and  remote  host  (if the user is logged in via the network) are
        displayed.
             The file /_u_s_r/_a_d_m/_w_t_m_p [Sun88a, 1485] records each login and
        logout  time  for  every  user.   This file can also be displayed
        using the _w_h_o command:
                % who /usr/adm/wtmp
                davy     ttyp4    Jan  7 12:42 (annex01.riacs.ed)
                         ttyp4    Jan  7 15:33
                davy     ttyp4    Jan  7 15:33 (annex01.riacs.ed)
                         ttyp4    Jan  7 15:35
                hyder    ttyp3    Jan  8 09:07 (triceratops.itst)
                         ttyp3    Jan  8 11:43
        A line that contains a login name indicates  the  time  the  user
        logged  in; a line with no login name indicates the time that the
        terminal was logged off.  Unfortunately,  the  output  from  this
        command  is  rarely as simple as in the example above; if several
        users log in at once, the login and logout times  are  all  mixed
        together and must be matched up by hand using the terminal name.
             The _w_t_m_p file may also be examined using  the  _l_a_s_t  command
        [Sun88a,  248].   This command sorts out the entries in the file,
        matching up login and logout  times.   With  no  arguments,  _l_a_s_t
        displays  all  information  in the file.  By giving the name of a
        user or terminal, the output can be restricted to the information
        about  the  user or terminal in question.  Sample output from the
        _l_a_s_t command is shown below.
                % last
                davy      ttyp3  intrepid.itstd.s Tue Mar 13 10:55 - 10:56 (00:00)
                hyder     ttyp3  clyde.itstd.sri. Mon Mar 12 15:31 - 15:36 (00:04)
                reboot    %                       Mon Mar 12 15:16
                shutdown  %                       Mon Mar 12 15:16
                arms      ttyp3  clyde0.itstd.sri Mon Mar 12 15:08 - 15:12 (00:04)
                hyder     ttyp3  spam.itstd.sri.c Sun Mar 11 21:08 - 21:13 (00:04)
                reboot    %                       Sat Mar 10 20:05
                davy      ftp    hydra.riacs.edu  Sat Mar 10 13:23 - 13:30 (00:07)
                                       32
        For each login session, the user name, terminal used, remote host
        (if  the user logged in via the network), login and logout times,
        and session duration are shown.  Additionally, the times  of  all
        system  shutdowns  and  reboots  (generated  by  the _s_h_u_t_d_o_w_n and
        _r_e_b_o_o_t commands  [Sun88a,  1727,  1765])  are  recorded.   Unfor-
        tunately,  system crashes are not recorded.  In newer versions of
        the operating system, pseudo logins such as  those  via  the  _f_t_p
        command  are  also  recorded;  an example of this is shown in the
        last line of the sample output, above.
        3.1.3   The acct File
             The file /_u_s_r/_a_d_m/_a_c_c_t [Sun88a, 1344-1345] records each exe-
        cution of a command on the system, who executed it, when, and how
        long it took.  This information is logged  each  time  a  command
        completes,  but only if your kernel was compiled with the SYSACCT
        option enabled (the option is enabled in  some  GENERIC  kernels,
        but is usually disabled by default).
             The _a_c_c_t file can be displayed using  the  _l_a_s_t_c_o_m_m  command
        [Sun88a,  249].   With  no  arguments, all the information in the
        file is displayed.  However, by giving a command name, user name,
        or  terminal name as an argument, the output can be restricted to
        information about the given command, user, or  terminal.   Sample
        output from _l_a_s_t_c_o_m_m is shown below.
                % lastcomm
                sh         S     root     __         0.67 secs Tue Mar 13 12:45
                atrun            root     __         0.23 secs Tue Mar 13 12:45
                lpd         F    root     __         1.06 secs Tue Mar 13 12:44
                lpr        S     burwell  tty09      1.23 secs Tue Mar 13 12:44
                troff            burwell  tty09     12.83 secs Tue Mar 13 12:44
                eqn              burwell  tty09      1.44 secs Tue Mar 13 12:44
                df               kindred  ttyq7      0.78 secs Tue Mar 13 12:44
                ls               kindred  ttyq7      0.28 secs Tue Mar 13 12:44
                cat              kindred  ttyq7      0.05 secs Tue Mar 13 12:44
                stty             kindred  ttyq7      0.05 secs Tue Mar 13 12:44
                tbl              burwell  tty09      1.08 secs Tue Mar 13 12:44
                rlogin     S     jones    ttyp3      5.66 secs Tue Mar 13 12:38
                rlogin      F    jones    ttyp3      2.53 secs Tue Mar 13 12:41
                stty             kindred  ttyq7      0.05 secs Tue Mar 13 12:44
        The first column indicates the name of  the  command.   The  next
        column  displays certain flags on the command: an %%F'' means the
        process spawned a child process, %%S'' means the process ran with
        the  set-user-id  bit  set, %%D'' means the process exited with a
        core dump, and %%X'' means the  process  was  killed  abnormally.
        The  remaining  columns  show  the  name  of the user who ran the
        program, the terminal he ran it from (if applicable), the  amount
                                       33
        of  CPU  time  used by the command (in seconds), and the date and
        time the process started.
        3.2   NETWORK SECURITY
             Monitoring network security is more difficult, because there
        are  so many ways for a cracker to attempt to break in.  However,
        there are some programs available to aid you in this task.  These
        are described in this section.
        3.2.1   The syslog Facility
             The _s_y_s_l_o_g facility  [Sun88a,  1773]  is  a  mechanism  that
        enables  any command to log error messages and informational mes-
        sages to the system console, as well as to  a  log  file.   Typi-
        cally,  error  messages  are logged in the file /_u_s_r/_a_d_m/_m_e_s_s_a_g_e_s
        along with the date, time, name of the program sending  the  mes-
        sage, and (usually) the process id of the program.  A sample seg-
        ment of the _m_e_s_s_a_g_e_s file is shown below.
                Mar 12 14:53:37 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr
                Mar 12 15:18:08 sparkyfs login: ROOT LOGIN ttyp3 FROM setekfs.itstd.sr
                Mar 12 16:50:25 sparkyfs login: ROOT LOGIN ttyp4 FROM pongfs.itstd.sri
                Mar 12 16:52:20 sparkyfs vmunix: sd2c:  read failed, no retries
                Mar 13 06:01:18 sparkyfs vmunix: /: file system full
                Mar 13 08:02:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst
                Mar 13 08:28:52 sparkyfs su: davy on /dev/ttyp3
                Mar 13 08:38:03 sparkyfs login: ROOT LOGIN ttyp4 FROM triceratops.itst
                Mar 13 10:56:54 sparkyfs automount[154]: host aaifs not responding
                Mar 13 11:30:42 sparkyfs login: REPEATED LOGIN FAILURES ON ttyp3 FROM
                                intrepid.itstd.s, daemon
        Of particular interest in this sample are the messages  from  the
        _l_o_g_i_n  and  _s_u  programs.   Whenever someone logs in as %%root,''
        _l_o_g_i_n logs this information.  Generally, logging in  as  %%root''
        directly,   rather   than   using   the  _s_u  command,  should  be
        discouraged, as it is hard to  track  which  person  is  actually
        using  the  account.   Once  this  ability  has been disabled, as
        described  in  Section  2.2.2,  detecting  a  security  violation
        becomes  a simple matter of searching the _m_e_s_s_a_g_e_s file for lines
        of this type.
             _L_o_g_i_n also logs any case of someone repeatedly trying to log
        in  to  an account and failing.  After three attempts, _l_o_g_i_n will
        refuse to let  the  person  try  anymore.   Searching  for  these
        messages  in  the  _m_e_s_s_a_g_e_s  file  can  alert  you  to  a cracker
                                       34
        attempting to guess someone's password.
             Finally, when someone uses the _s_u command, either to  become
        %%root'' or someone  else, _s_u logs the success or failure of this
        operation.  These messages can be used to check for users sharing
        their  passwords, as well as for a cracker who has penetrated one
        account and is trying to penetrate others.
        3.2.2   The showmount Command
             The _s_h_o_w_m_o_u_n_t command [Sun88a, 1764] can be used on  an  NFS
        file server to display the names of all hosts that currently have
        something mounted from the server.  With no options, the  program
        simply  displays  a  list  of  all the hosts.  With the -_a and -_d
        options, the output is somewhat more useful.  The  first  option,
        -_a,  causes _s_h_o_w_m_o_u_n_t to list all the host and directory combina-
        tions.  For example,
                bronto.itstd.sri.com:/usr/share
                bronto.itstd.sri.com:/usr/local.new
                bronto.itstd.sri.com:/usr/share/lib
                bronto.itstd.sri.com:/var/spool/mail
                cascades.itstd.sri.com:/sparky/a
                clyde.itstd.sri.com:/laser_dumps
                cm1.itstd.sri.com:/sparky/a
                coco0.itstd.sri.com:/sparky/a
        There will be one line of output for each directory mounted by  a
        host.   With  the  -_d  option,  _s_h_o_w_m_o_u_n_t  displays a list of all
        directories that are presently mounted by some host.
             The output from _s_h_o_w_m_o_u_n_t should be checked for two  things.
        First,  only  machines  local  to your organization should appear
        there.  If you have set up proper netgroups as described in  Sec-
        tion  2.2.3,  this  should not be a problem.  Second, only %%nor-
        mal'' directories should be mounted.  If you find unusual  direc-
        tories  being  mounted,  you should find out who is mounting them
        and why - although it is probably innocent, it may indicate some-
        one trying to get around your security mechanisms.
        3.3   FILE SYSTEM SECURITY
             Checking for security holes in the file  system  is  another
        important part of making your system secure.  Primarily, you need
        to check for files that can be modified  by  unauthorized  users,
        files  that  can  inadvertently grant users too many permissions,
                                       35
        and files that can inadvertently grant access to crackers.  It is
        also important to be able to detect unauthorized modifications to
        the file system, and to recover  from  these  modifications  when
        they are made.
        3.3.1   The find Command
             The _f_i_n_d command [Sun88a, 183-185] is a general-purpose com-
        mand  for  searching  the  file system.  Using various arguments,
        complex matching patterns based on a  file's  name,  type,  mode,
        owner,  modification time, and other characteristics, can be con-
        structed.  The names of files that are found using these patterns
        can then be printed out, or given as arguments to other UNIX com-
        mands.  The general format of a _f_i_n_d command is
                % find _d_i_r_e_c_t_o_r_i_e_s _o_p_t_i_o_n_s
        where _d_i_r_e_c_t_o_r_i_e_s is a list of directory names to  search  (e.g.,
        /_u_s_r),  and _o_p_t_i_o_n_s contains the options to control what is being
        searched for.  In general, for the examples in this section,  you
        will  always want to search from the root of the file system (/),
        in order to find all files matching the patterns presented.
             This section describes how to use _f_i_n_d to  search  for  four
        possible security problems that were described in Section 2.
        3.3.1.1   Finding Setuid and Setgid Files
             It is important to check the system often  for  unauthorized
        setuid and setgid programs.  Because these programs grant special
        privileges to the user who is executing them, it is necessary  to
        ensure that insecure programs are not installed.  Setuid %%root''
        programs should be closely guarded - a  favorite  trick  of  many
        crackers  is to break into %%root'' once, and leave a setuid pro-
        gram hidden somewhere that will enable them to regain  super-user
        powers even if the original hole is plugged.
             The command to search for setuid and setgid files is
                # find / -type f -a %( -perm -4000 -o -perm -2000 %) -print
        The options to this command have the following meanings:
             /    The name of the directory  to  be  searched.   In  this
                  case,  we  want to search the entire file system, so we
                  specify /.  You might instead restrict  the  search  to
                                       36
                  /_u_s_r or /_h_o_m_e.
             -type f
                  Only examine files whose type is %%f,''  regular  file.
                  Other  options  include  %%d'' for directory, %%l'' for
                  symbolic link, %%c'' for character-special devices, and
                  %%b'' for block-special devices.
             -a   This specifies %%and.'' Thus, we  want  to  know  about
                  files whose type is %%regular file,'' _a_n_d whose permis-
                  sions bits match the other part of this expression.
             %( -perm -4000 -o -perm -2000 %)
                  The parentheses in this part of the  command  are  used
                  for  grouping.   Thus,  everything  in this part of the
                  command matches a single pattern, and is treated as the
                  other half of the %%and'' clause described above.
                  -perm -4000
                       This specifies a match if the %%4000'' bit (speci-
                       fied as an octal number) is set in the file's per-
                       mission modes.  This is the set-user-id bit.
                  -o   This specifies %%or.'' Thus, we want to  match  if
                       the  file  has  the  set-user-id  bit  _o_r the set-
                       group-id bit set.
                  -perm -2000
                       This specifies a match if the %%2000'' bit (speci-
                       fied as an octal number) is set in the file's per-
                       mission modes.  This is the set-group-id bit.
             -printThis indicates that for  any  file  that  matches  the
                  specified  expression  (is  a  regular file _a_n_d has the
                  setuid _o_r setgid bits set in  its  permissions),  print
                  its name on the screen.
             After executing this command (depending  on  how  much  disk
        space  you have, it can take anywhere from 15 minutes to a couple
        of hours to complete), you will have a list of  files  that  have
        setuid  or setgid bits set on them.  You should then examine each
        of these programs, and determine  whether  they  should  actually
        have  these  permissions.  You should be especially suspicious of
        programs that are _n_o_t in one of the directories (or  a  subdirec-
        tory) shown below.
                /bin
                /etc
                /usr/bin
                /usr/ucb
                /usr/etc
                                       37
             One file distributed with SunOS, /_u_s_r/_e_t_c/_r_e_s_t_o_r_e,  is  dis-
        tributed  with  the  setuid  bit  set  on  it, and should not be,
        because of a security hole.  You should be  sure  to  remove  the
        setuid bit from this program by executing the command
                # chmod u-s /usr/etc/restore
        3.3.1.2   Finding World-Writable Files
             World-writable files, particularly system files,  can  be  a
        security  hole if a cracker gains access to your system and modi-
        fies  them.    Additionally,   world-writable   directories   are
        dangerous,  since  they allow a cracker to add or delete files as
        he wishes.  The _f_i_n_d command to find all world-writable files is
                # find / -perm -2 -print
        In this case, we do not use the  -_t_y_p_e  option  to  restrict  the
        search,  since  we  are  interested in directories and devices as
        well as files.  The -_2 specifies the world write bit (in octal).
             This list of files will be fairly  long,  and  will  include
        some files that _s_h_o_u_l_d be world writable.  You should not be con-
        cerned if terminal devices  in  /_d_e_v  are  world  writable.   You
        should  also  not be concerned about line printer error log files
        being world writable.  Finally, symbolic links may be world writ-
        able  -  the permissions on a symbolic link, although they exist,
        have no meaning.
        3.3.1.3   Finding Unowned Files
             Finding files that are owned by nonexistent users can  often
        be  a clue that a cracker has gained access to your system.  Even
        if this is not the case, searching for these files gives  you  an
        opportunity  to  clean  up files that should have been deleted at
        the same time the user herself was deleted.  The command to  find
        unowned files is
                # find / -nouser -print
        The -_n_o_u_s_e_r option matches files that are owned by a user id  not
        contained   in  the  /_e_t_c/_p_a_s_s_w_d  database.   A  similar  option,
        -_n_o_g_r_o_u_p, matches files owned by nonexistent groups.  To find all
        files  owned by nonexistent users _o_r groups, you would use the -_o
        option as follows:
                                       38
                # find / -nouser -o -nogroup -print
        3.3.1.4   Finding .rhosts Files
             As mentioned in Section 2.2.1.2, users should be  prohibited
        from having ._r_h_o_s_t_s files in their accounts.  To search for this,
        it is only necessary to search the parts of the file system  that
        contain home directories (i.e., you can skip / and /_u_s_r):
                # find /home -name .rhosts -print
        The -_n_a_m_e option indicates that the complete  name  of  any  file
        whose name matches ._r_h_o_s_t_s should be printed on the screen.
        3.3.2   Checklists
             Checklists can be a useful tool for discovering unauthorized
        changes  made  to  system  directories.  They aren't practical on
        file systems that contain users'  home  directories  since  these
        change  all  the time.  A checklist is a listing of all the files
        contained in a group of directories: their sizes, owners, modifi-
        cation  dates, and so on.  Periodically, this information is col-
        lected and compared with the information in the master checklist.
        Files  that  do  not  match in all attributes can be suspected of
        having been changed.
             There are several utilities that implement checklists avail-
        able from public software sites (see Section 4).  However, a sim-
        ple utility can be constructed using only the  standard  UNIX  _l_s
        and _d_i_f_f commands.
             First, use the _l_s command [Sun88a, 285] to generate a master
        list.  This is best done immediately after installing the operat-
        ing system, but can be done at any time provided you're confident
        about the correctness of the files on the disk.  A sample command
        is shown below.
                # ls -aslgR /bin /etc /usr > MasterChecklist
        The file _M_a_s_t_e_r_C_h_e_c_k_l_i_s_t now contains a complete list of all  the
        files  in  these  directories.  You will probably want to edit it
        and delete the lines for files you know will  be  changing  often
        (e.g.,   /_e_t_c/_u_t_m_p,  /_u_s_r/_a_d_m/_a_c_c_t).   The  _M_a_s_t_e_r_C_h_e_c_k_l_i_s_t  file
        should be stored somewhere safe where a cracker  is  unlikely  to
                                       39
        find  it  (since  he could otherwise just change the data in it):
        either on a different computer system, or on magnetic tape.
             To search for changes in the file system, run the  above  _l_s
        command  again,  saving  the  output  in  some  other  file,  say
        _C_u_r_r_e_n_t_L_i_s_t.  Now use the _d_i_f_f command [Sun88a, 150]  to  compare
        the two files:
                # diff MasterChecklist CurrentList
        Lines that are only in the master checklist will be printed  pre-
        ceded  by  a  %%<,''  and lines that are only in the current list
        will be preceded by a %%>.'' If there is one  line  for  a  file,
        preceded  by  a  %%<,'' this means that the file has been deleted
        since the master checklist was created.  If there is one line for
        a  file,  preceded  by a %%>,'' this means that the file has been
        created since the master checklist was created.  If there are two
        lines  for  a single file, one preceded by %%<'' and the other by
        %%>,'' this indicates that some attribute of the file has changed
        since the master checklist was created.
             By carefully  constructing  the  master  checklist,  and  by
        remembering  to update it periodically (you can replace it with a
        copy of _C_u_r_r_e_n_t_L_i_s_t, once you're sure the differences between the
        lists are harmless), you can easily monitor your system for unau-
        thorized changes.  The software packages available from the  pub-
        lic  software  distribution  sites  implement  basically the same
        scheme as the one here, but offer many more options for  control-
        ling what is examined and reported.
        3.3.3   Backups
             It is impossible to overemphasize the need for a good backup
        strategy.   File  system backups not only protect you in the even
        of hardware failure or accidental deletions, but they  also  pro-
        tect  you  against  unauthorized  file  system  changes made by a
        cracker.
             A good backup strategy will dump the entire system at  level
        zero  (a  %%full''  dump)  at  least  once  a month.  Partial (or
        %%incremental'') dumps should be done at least twice a week,  and
        ideally  they  should  be  done daily.  The _d_u_m_p command [Sun88a,
        1612-1614] is recommended over other programs  such  as  _t_a_r  and
        _c_p_i_o.   This is because only _d_u_m_p is capable of creating a backup
        that can be used to restore a disk to the exact state it  was  in
        when  it was dumped.  The other programs do not take into account
        files deleted or renamed between dumps, and do  not  handle  some
        specialized database files properly.
                                       40
        3.4   KNOW YOUR SYSTEM
             Aside from running large monitoring programs such  as  those
        described in the previous sections, simple everyday UNIX commands
        can also be useful for spotting security violations.  By  running
        these  commands often, whenever you have a free minute (for exam-
        ple, while waiting for someone to answer  the  phone),  you  will
        become  used  to  seeing  a specific pattern of output.  By being
        familiar with the processes normally running on your system,  the
        times different users typically log in, and so on, you can easily
        detect when something is out of the ordinary.
        3.4.1   The ps Command
             The _p_s command [Sun88a, 399-402]  displays  a  list  of  the
        processes  running  on your system.  _P_s has numerous options, too
        many to list here.  Generally, however, for the purpose of  moni-
        toring, the option string -_a_l_x_w_w is the most useful.*  On  a  Sun
        system  running  SunOS 4.0, you should expect to see at least the
        following:
             _s_w_a_p_p_e_r, _p_a_g_e_d_a_e_m_o_n
                  System programs that help the virtual memory system.
             /_s_b_i_n/_i_n_i_t
                  The _i_n_i_t process, which  is  responsible  for  numerous
                  tasks,  including bringing up login processes on termi-
                  nals.
             _p_o_r_t_m_a_p, _y_p_b_i_n_d, _y_p_s_e_r_v
                  Parts of the Yellow Pages system.
             _b_i_o_d, _n_f_s_d, _r_p_c._m_o_u_n_t_d, _r_p_c._q_u_o_t_a_d, _r_p_c._l_o_c_k_d
                  Parts of the Network File System (NFS).  If the  system
                  you  are  looking  at  is  not  a file server, the _n_f_s_d
                  processes probably won't exist.
             _r_a_r_p_d, _r_p_c._b_o_o_t_p_a_r_a_m_d
                  Part of the system  that  allows  diskless  clients  to
                  boot.
             Other commands you should expect to  see  are  _u_p_d_a_t_e  (file
        system  updater);  _g_e_t_t_y  (one  per  terminal  and  one  for  the
        _________________________
          * This is true for Berkeley-based systems.  On  System  V  sys-
        tems, the option string -_e_l_f should be used instead.
                                       41
        console); _l_p_d (line printer daemon); _i_n_e_t_d (Internet daemon,  for
        starting other network servers); _s_h and _c_s_h (the Bourne shell and
        C shell, one or more per logged in user).  In addition, if  there
        are  users  logged in, you'll probably see invocations of various
        compilers, text editors, and word processing programs.
        3.4.2   The who and w Commands
             The _w_h_o command, as mentioned previously, displays the  list
        of  users  currently  logged  in  on the system.  By running this
        periodically, you can learn at what times during the day  various
        users  log  in.   Then,  when you see someone logged in at a dif-
        ferent time, you can investigate and make sure that it's  legiti-
        mate.
             The _w command [Sun88a, 588] is somewhat of a  cross  between
        _w_h_o  and  _p_s.   Not  only does it show a list of who is presently
        logged in, but it also displays how  long  they  have  been  idle
        (gone  without  typing  anything),  and  what  command  they  are
        currently running.
        3.4.3   The ls Command
             Simple as its function is, _l_s is actually  very  useful  for
        detecting  file system problems.  Periodically, you should use _l_s
        on the  various  system  directories,  checking  for  files  that
        shouldn't be there.  Most of the time, these files will have just
        %%landed'' somewhere by accident.  However, by  keeping  a  close
        watch on things, you will be able to detect a cracker long before
        you might have otherwise.
             When using _l_s to check for oddities, be sure to use  the  -_a
        option,  which  lists  files whose names begin with a period (.).
        Be particularly alert for files or directories named %%...'',  or
        %%..(space)'',  which  many  crackers  like  to use.  (Of course,
        remember that %%.'' and %%..'' are supposed to be there.)
        3.5   KEEP YOUR EYES OPEN
             Monitoring for security breaches is every bit  as  important
        as  preventing  them  in the first place.  Because it's virtually
        impossible to make a system totally secure, there is  always  the
        chance,  no matter how small, that a cracker will be able to gain
                                       42
        access.  Only by monitoring can this be detected and remedied.
                                       43
                                       44
                                    SECTION 4
                         SOFTWARE FOR IMPROVING SECURITY
             Because security is of great concern to many sites, a wealth
        of software has been developed for improving the security of UNIX
        systems.  Much of this software has been developed  at  universi-
        ties and other public institutions, and is available free for the
        asking.   This  section  describes  how  this  software  can   be
        obtained, and mentions some of the more important programs avail-
        able.
        4.1   OBTAINING FIXES AND NEW VERSIONS
             Several sites on the Internet maintain large repositories of
        public-domain  and  freely  distributable software, and make this
        material available for anonymous  FTP.   This  section  describes
        some of the larger repositories.
        4.1.1   Sun Fixes on UUNET
             Sun Microsystems has contracted  with  UUNET  Communications
        Services,  Inc.  to make fixes for bugs in Sun software available
        via anonymous FTP.  You can access these fixes by using  the  _f_t_p
        command  [Sun88a,  195-201]  to  connect  to the host _f_t_p._u_u._n_e_t.
        Then change into the directory _s_u_n-_f_i_x_e_s, and obtain a  directory
        listing, as shown in the example on the following page.
                                       45
        % ftp ftp.uu.net
        Connected to uunet.UU.NET.
        220 uunet FTP server (Version 5.93 Tue Mar 20 11:01:52 EST 1990) ready.
        Name (ftp.uu.net:davy): anonymous
        331 Guest login ok, send ident as password.
        Password:               _e_n_t_e_r _y_o_u_r _m_a_i_l _a_d_d_r_e_s_s _y_o_u_r_n_a_m_e@_y_o_u_r_h_o_s_t _h_e_r_e
        230 Guest login ok, access restrictions apply.
        ftp> cd sun-fixes
        _2_5_0 _C_W_D _c_o_m_m_a_n_d _s_u_c_c_e_s_s_f_u_l.
        _f_t_p> _d_i_r
        200 PORT command successful.
        150 Opening ASCII mode data connection for /bin/ls.
        total 2258
        -rw-r--r--  1 38       22           4558 Aug 31  1989 README
        -rw-r--r--  1 38       22         484687 Dec 14  1988 ddn.tar.Z
        -rw-r--r--  1 38       22         140124 Jan 13  1989 gated.sun3.Z
        -rwxr-xr-x  1 38       22          22646 Dec 14  1988 in.ftpd.sun3.Z
        .....
        .....
        -rw-r--r--  1 38       22          72119 Aug 31  1989 sendmail.sun3.Z
        -rwxr-xr-x  1 38       22          99147 Aug 31  1989 sendmail.sun4.Z
        -rw-r--r--  1 38       22           3673 Jul 11  1989 wall.sun3.Z
        -rw-r--r--  1 38       22           4099 Jul 11  1989 wall.sun4.Z
        -rwxr-xr-x  1 38       22           7955 Jan 18  1989 ypbind.sun3.Z
        -rwxr-xr-x  1 38       22           9237 Jan 18  1989 ypbind.sun4.Z
        226 Transfer complete.
        1694 bytes received in 0.39 seconds (4.2 Kbytes/s)
        ftp> quit
        _2_2_1 _G_o_o_d_b_y_e.
        %
        The file _R_E_A_D_M_E contains a brief description of what each file in
        this directory contains, and what is required to install the fix.
        4.1.2   Berkeley Fixes
             The University of California at Berkeley  also  makes  fixes
        available via anonymous FTP; these fixes pertain primarily to the
        current release of BSD UNIX (currently  release  4.3).   However,
        even if you are not running their software, these fixes are still
        important, since many vendors (Sun, DEC,  Sequent  ,  etc.)  base
        their software on the Berkeley releases.
             The Berkeley fixes are available for anonymous FTP from  the
        host  _u_c_b_a_r_p_a._b_e_r_k_e_l_e_y._e_d_u  in  the directory _4._3/_u_c_b-_f_i_x_e_s.  The
        file _I_N_D_E_X in this directory describes what each file contains.
             Berkeley also distributes new versions of _s_e_n_d_m_a_i_l and _n_a_m_e_d
        [Sun88a,  1758-1760,  1691-1692] from this machine.  New versions
                                       46
        of these commands are stored in the _4._3 directory, usually in the
        files _s_e_n_d_m_a_i_l._t_a_r._Z and _b_i_n_d._t_a_r._Z, respectively.
        4.1.3   Simtel-20 and UUNET
             The two largest general-purpose software repositories on the
        Internet are the hosts _w_s_m_r-_s_i_m_t_e_l_2_0._a_r_m_y._m_i_l and _f_t_p._u_u._n_e_t.
             _w_s_m_r-_s_i_m_t_e_l_2_0._a_r_m_y._m_i_l is a TOPS-20 machine operated by  the
        U.  S. Army at White Sands Missile Range, New Mexico.  The direc-
        tory _p_d_2:<_u_n_i_x-_c> contains a large amount of UNIX software,  pri-
        marily  taken  from  the  _c_o_m_p._s_o_u_r_c_e_s newsgroups.  The file _0_0_0-
        _m_a_s_t_e_r-_i_n_d_e_x._t_x_t contains a master list and description  of  each
        piece  of  software  available  in the repository.  The file _0_0_0-
        _i_n_t_r_o-_u_n_i_x-_s_w._t_x_t contains information on the mailing  list  used
        to  announce  new software, and describes the procedures used for
        transferring files from the archive with FTP.
             _f_t_p._u_u._n_e_t is operated  by  UUNET  Communications  Services,
        Inc.  in Falls Church, Virginia.  This company sells Internet and
        USENET access to sites all over  the  country  (and  internation-
        ally).   The software posted to the following USENET source news-
        groups is stored here, in directories of the same name:
                comp.sources.games
                comp.sources.misc
                comp.sources.sun
                comp.sources.unix
                comp.sources.x
        Numerous other distributions, such as all the  freely  distribut-
        able  Berkeley  UNIX  source  code, Internet Request for Comments
        (RFCs), and so on are also stored on this machine.
        4.1.4   Vendors
             Many vendors make fixes for bugs in their software available
        electronically,  either  via  mailing lists or via anonymous FTP.
        You should contact your vendor to find out  if  they  offer  this
        service,  and  if  so, how to access it.  Some vendors that offer
        these services include  Sun  Microsystems  (see  above),  Digital
        Equipment  Corp.,  the  University of California at Berkeley (see
        above), and Apple Computer.
                                       47
        4.2   THE NPASSWD COMMAND
             The _n_p_a_s_s_w_d  command,  developed  by  Clyde  Hoover  at  the
        University  of  Texas  at Austin, is intended to be a replacement
        for the standard UNIX _p_a_s_s_w_d command [Sun88a, 379],  as  well  as
        the  Sun _y_p_p_a_s_s_w_d command [Sun88a, 611].  _n_p_a_s_s_w_d makes passwords
        more secure by refusing to allow users to select  insecure  pass-
        words.  The following capabilities are provided by _n_p_a_s_s_w_d:
             o+    Configurable minimum password length
             o+    Configurable to force users to use mixed case or digits
                  and punctuation
             o+    Checking for %%simple'' passwords such  as  a  repeated
                  letter
             o+    Checking against the host name and other  host-specific
                  information
             o+    Checking against the login name, first and last  names,
                  and so on
             o+    Checking for words in various  dictionaries,  including
                  the system dictionary.
             The _n_p_a_s_s_w_d distribution is available for anonymous FTP from
        _e_m_x._u_t_e_x_a_s._e_d_u in the directory _p_u_b/_n_p_a_s_s_w_d.
        4.3   THE COPS PACKAGE
             COPS is a  security  tool  for  system  administrators  that
        checks  for  numerous  common  security problems on UNIX systems,
        including many of the things described in this document.  COPS is
        a  collection  of shell scripts and C programs that can easily be
        run on almost any UNIX variant.  Among other  things,  it  checks
        the  following items and sends the results to the system adminis-
        trator:
             o+    Checks  /_d_e_v/_k_m_e_m   and   other   devices   for   world
                  read/writability.
             o+    Checks  special/important  files  and  directories  for
                  %%bad'' modes (world writable, etc.).
             o+    Checks for easily guessed passwords.
                                       48
             o+    Checks for duplicate user ids, invalid  fields  in  the
                  password file, etc.
             o+    Checks for duplicate group ids, invalid fields  in  the
                  group file, etc.
             o+    Checks all users' home directories  and  their  ._c_s_h_r_c,
                  ._l_o_g_i_n,  ._p_r_o_f_i_l_e, and ._r_h_o_s_t_s files for security prob-
                  lems.
             o+    Checks all  commands  in  the  /_e_t_c/_r_c  files  [Sun88a,
                  1724-1725] and _c_r_o_n files [Sun88a, 1606-1607] for world
                  writability.
             o+    Checks for bad %%root'' paths, NFS file system exported
                  to the world, etc.
             o+    Includes an expert system that checks to see if a given
                  user  (usually %%root'') can be compromised, given that
                  certain rules are true.
             o+    Checks for _c_h_a_n_g_e_s in the setuid status of programs  on
                  the system.
             The COPS package is  available  from  the  _c_o_m_p._s_o_u_r_c_e_s._u_n_i_x
        archive  on  _f_t_p._u_u._n_e_t,  and  also  from the repository on _w_s_m_r-
        _s_i_m_t_e_l_2_0._a_r_m_y._m_i_l.
        4.4   SUN C2 SECURITY FEATURES
             With the release of SunOS 4.0,  Sun  has  included  security
        features  that  allow  the system to operate at a higher level of
        security, patterned after the C2* classification.  These features
        can be installed as one of the options when installing the system
        from the distribution tapes.  The security features added by this
        option include
             o+    Audit trails that record all login  and  logout  times,
                  the  execution of administrative commands, and the exe-
                  cution of privileged (setuid) operations.
             o+    A more secure password file mechanism  (%%shadow  pass-
                  word  file'')  that  prevents crackers from obtaining a
                  list of the encrypted passwords.
        _________________________
          * C2 is one of several security classifications defined by  the
        National  Computer Security Center, and is described in [NCSC85],
        the %%orange book.''
                                       49
             o+    DES encryption capability.
             o+    A (more) secure NFS implementation that uses public-key
                  encryption  to authenticate the users of the system and
                  the hosts on the network, to be sure  they  really  are
                  who they claim to be.
        These security features are described in detail in [Sun88c].
        4.5   KERBEROS
             Kerberos [Stei88] is an authentication system  developed  by
        the  Athena Project at the Massachusetts Institute of Technology.
        Kerberos  is  a  third-party  authentication  service,  which  is
        trusted by other network services.  When a user logs in, Kerberos
        authenticates that user (using a password), and provides the user
        with a way to prove her identity to other servers and hosts scat-
        tered around the network.
             This authentication is then used by programs such as  _r_l_o_g_i_n
        [Sun88a,  418-419]  to  allow  the  user to log in to other hosts
        without a password (in place of the ._r_h_o_s_t_s file).  The authenti-
        cation is also used by the mail system in order to guarantee that
        mail is delivered to the correct person, as well as to  guarantee
        that  the sender is who he claims to be.  NFS has also been modi-
        fied by M.I.T. to work with Kerberos, thereby making  the  system
        much more secure.
             The overall effect of installing Kerberos and  the  numerous
        other  programs  that  go  with  it is to virtually eliminate the
        ability of users to %%spoof'' the system into believing they  are
        someone   else.    Unfortunately,  installing  Kerberos  is  very
        intrusive, requiring the modification or replacement of  numerous
        standard  programs.  For this reason, a source license is usually
        necessary.  There are plans to make Kerberos a part of 4.4BSD, to
        be  released by the University of California at Berkeley sometime
        in 1990.
                                       50
                                    SECTION 5
                           KEEPING ABREAST OF THE BUGS
             One of the hardest things about keeping a system  secure  is
        finding  out  about the security holes before a cracker does.  To
        combat this, there are several sources of information you can and
        should make use of on a regular basis.
        5.1   THE COMPUTER EMERGENCY RESPONSE TEAM
             The Computer Emergency Response Team (CERT) was  established
        in December 1988 by the Defense Advanced Research Projects Agency
        to address computer security concerns of research  users  of  the
        Internet.   It  is operated by the Software Engineering Institute
        at Carnegie-Mellon University.  The CERT serves as a focal  point
        for  the  reporting of security violations, and the dissemination
        of security advisories to the Internet community.   In  addition,
        the  team works with vendors of various systems in order to coor-
        dinate the fixes for security problems.
             The CERT sends out security advisories to the  _c_e_r_t-_a_d_v_i_s_o_r_y
        mailing  list  whenever appropriate.  They also operate a 24-hour
        hotline that can be called to  report  security  problems  (e.g.,
        someone  breaking into your system), as well as to obtain current
        (and accurate) information about rumored security problems.
             To join the _c_e_r_t-_a_d_v_i_s_o_r_y mailing list, send  a  message  to
        _c_e_r_t@_c_e_r_t._s_e_i._c_m_u._e_d_u  and  ask  to be added to the mailing list.
        Past advisories are available for anonymous  FTP  from  the  host
        _c_e_r_t._s_e_i._c_m_u._e_d_u.  The 24-hour hotline number is (412) 268-7090.
        5.2   DDN MANAGEMENT BULLETINS
             The _D_D_N _M_a_n_a_g_e_m_e_n_t _B_u_l_l_e_t_i_n is distributed electronically by
        the  Defense  Data Network (DDN) Network Information Center under
        contract to the Defense Communications Agency.  It is a means  of
        communicating  official policy, procedures, and other information
        of concern to management personnel at DDN facilities.
             The _D_D_N _S_e_c_u_r_i_t_y _B_u_l_l_e_t_i_n is distributed  electronically  by
        the  DDN  SCC (Security Coordination Center), also under contract
        to DCA, as a means of communicating information  on  network  and
                                       51
        host  security  exposures,  fixes,  and  concerns to security and
        management personnel at DDN facilities.
             Anyone may join the mailing lists for these two bulletins by
        sending  a  message to _n_i_c@_n_i_c._d_d_n._m_i_l and asking to be placed on
        the mailing lists.
        5.3   SECURITY-RELATED MAILING LISTS
             There are several other mailing lists operated on the Inter-
        net  that  pertain  directly  or  indirectly  to various security
        issues.  Some of the more useful ones are described below.
        5.3.1   Security
             The UNIX Security  mailing  list  exists  to  notify  system
        administrators  of  security  problems  _b_e_f_o_r_e they become common
        knowledge, and to provide security enhancement  information.   It
        is a restricted-access list, open only to people who can be veri-
        fied as being principal systems people at a  site.   Requests  to
        join  the  list must be sent by either the site contact listed in
        the Network Information Center's  WHOIS  database,  or  from  the
        %%root''  account  on  one  of the major site machines.  You must
        include the destination address you want on the list, an  indica-
        tion  of  whether  you  want  to be on the mail reflector list or
        receive weekly digests, the electronic  mail  address  and  voice
        telephone  number  of  the  site contact if it isn't you, and the
        name, address, and telephone number of your  organization.   This
        information should be sent to _s_e_c_u_r_i_t_y-_r_e_q_u_e_s_t@_c_p_d._c_o_m.
        5.3.2   RISKS
             The RISKS digest is a component of the ACM Committee on Com-
        puters and Public Policy, moderated by Peter G. Neumann.  It is a
        discussion forum on risks to the public in computers and  related
        systems,  and along with discussing computer security and privacy
        issues, has discussed such subjects as the  Stark  incident,  the
        shooting  down of the Iranian airliner in the Persian Gulf (as it
        relates to the computerized weapons systems), problems in air and
        railroad  traffic  control  systems, software engineering, and so
        on.   To  join  the  mailing  list,  send  a  message  to  _r_i_s_k_s-
        _r_e_q_u_e_s_t@_c_s_l._s_r_i._c_o_m.   This  list is also available in the USENET
        newsgroup _c_o_m_p._r_i_s_k_s.
                                       52
        5.3.3   TCP-IP
             The TCP-IP list is intended to act as a discussion forum for
        developers  and maintainers of implementations of the TCP/IP pro-
        tocol suite.  It also discusses network-related security problems
        when  they  involve  programs providing network services, such as
        _s_e_n_d_m_a_i_l.  To join the TCP-IP list, send  a  message  to  _t_c_p-_i_p-
        _r_e_q_u_e_s_t@_n_i_c._d_d_n._m_i_l.   This  list is also available in the USENET
        newsgroup _c_o_m_p._p_r_o_t_o_c_o_l_s._t_c_p-_i_p.
        5.3.4   SUN-SPOTS, SUN-NETS, SUN-MANAGERS
             The SUN-SPOTS, SUN-NETS, and SUN-MANAGERS lists are all dis-
        cussion  groups  for users and administrators of systems supplied
        by Sun Microsystems.  SUN-SPOTS is a fairly  general  list,  dis-
        cussing  everything  from  hardware configurations to simple UNIX
        questions.   To  subscribe,  send   a   message   to   _s_u_n-_s_p_o_t_s-
        _r_e_q_u_e_s_t@_r_i_c_e._e_d_u.   This  list  is  also  available in the USENET
        newsgroup _c_o_m_p._s_y_s._s_u_n.
             SUN-NETS is a discussion list for items pertaining  to  net-
        working  on  Sun  systems.   Much of the discussion is related to
        NFS, Yellow Pages, and name servers.  To subscribe, send  a  mes-
        sage to _s_u_n-_n_e_t_s-_r_e_q_u_e_s_t@_u_m_i_a_c_s._u_m_d._e_d_u.
             SUN-MANAGERS is a discussion list for Sun system administra-
        tors  and  covers  all  aspects of Sun system administration.  To
        subscribe, send a message to _s_u_n-_m_a_n_a_g_e_r_s-_r_e_q_u_e_s_t@_e_e_c_s._n_w_u._e_d_u.
        5.3.5   VIRUS-L
             The VIRUS-L list is a forum for the discussion  of  computer
        virus  experiences, protection software, and related topics.  The
        list is open to the public, and is implemented as a mail  reflec-
        tor,  not  a  digest.  Most of the information is related to per-
        sonal computers, although some of it may be applicable to  larger
        systems.  To subscribe, send the line
                SUB VIRUS-L _y_o_u_r _f_u_l_l _n_a_m_e
        to the address _l_i_s_t_s_e_r_v%_l_e_h_i_i_b_m_1._b_i_t_n_e_t@_m_i_t_v_m_a._m_i_t._e_d_u.
                                       53
                                       54
                                    SECTION 6
                                SUGGESTED READING
             This section suggests some alternate sources of  information
        pertaining to the security and administration of the UNIX operat-
        ing system.
        _U_N_I_X _S_y_s_t_e_m _A_d_m_i_n_i_s_t_r_a_t_i_o_n _H_a_n_d_b_o_o_k
        Evi Nemeth, Garth Snyder, Scott Seebass
        Prentice Hall, 1989, $26.95
             This is perhaps the best general-purpose book on UNIX system
             administration  currently on the market.  It covers Berkeley
             UNIX, SunOS, and System V.  The 26 chapters  and  17  appen-
             dices  cover numerous topics, including booting and shutting
             down the system, the file system,  configuring  the  kernel,
             adding  a  disk,  the line printer spooling system, Berkeley
             networking, _s_e_n_d_m_a_i_l, and _u_u_c_p.  Of particular interest  are
             the  chapters  on  running  as  the super-user, backups, and
             security.
        _U_N_I_X _O_p_e_r_a_t_i_n_g _S_y_s_t_e_m _S_e_c_u_r_i_t_y
        F. T. Grammp and R. H. Morris
        AT&T Bell Laboratories Technical Journal
        October 1984
             This is an excellent discussion of some of the  more  common
             security  problems in UNIX and how to avoid them, written by
             two of Bell Labs' most prominent security experts.
        _P_a_s_s_w_o_r_d _S_e_c_u_r_i_t_y: _A _C_a_s_e _H_i_s_t_o_r_y
        Robert Morris and Ken Thompson
        Communications of the ACM
        November 1979
             An excellent discussion on the problem of password security,
             and  some interesting information on how easy it is to crack
             passwords and why.  This document is  usually  reprinted  in
             most vendors' UNIX documentation.
        _O_n _t_h_e _S_e_c_u_r_i_t_y _o_f _U_N_I_X
        Dennis M. Ritchie
        May 1975
             A discussion on UNIX security from one of the original crea-
             tors  of  the system.  This document is usually reprinted in
             most vendors' UNIX documentation.
        _T_h_e _C_u_c_k_o_o'_s _E_g_g
                                       55
        Clifford Stoll
        Doubleday, 1989, $19.95
             An excellent story of Stoll's experiences tracking down  the
             German  crackers who were breaking into his systems and sel-
             ling the data they found to the KGB.   Written  at  a  level
             that nontechnical users can easily understand.
        _S_y_s_t_e_m _a_n_d _N_e_t_w_o_r_k _A_d_m_i_n_i_s_t_r_a_t_i_o_n
        Sun Microsystems
        May, 1988
             Part of the SunOS documentation,  this  manual  covers  most
             aspects  of  Sun  system  administration, including security
             issues.  A must for anyone operating a  Sun  system,  and  a
             pretty good reference for other UNIX systems as well.
        _S_e_c_u_r_i_t_y _P_r_o_b_l_e_m_s _i_n _t_h_e _T_C_P/_I_P _P_r_o_t_o_c_o_l _S_u_i_t_e
        S. M. Bellovin
        ACM Computer Communications Review
        April, 1989
             An interesting discussion of some of the  security  problems
             with  the  protocols  in  use on the Internet and elsewhere.
             Most of these problems are far beyond  the  capabilities  of
             the  average  cracker, but it is still important to be aware
             of them.  This article is technical in nature,  and  assumes
             familiarity with the protocols.
        _A _W_e_a_k_n_e_s_s _i_n _t_h_e _4._2_B_S_D _U_N_I_X _T_C_P/_I_P _S_o_f_t_w_a_r_e
        Robert T. Morris
        AT&T Bell Labs Computer Science Technical Report 117
        February, 1985
             An interesting article from the author of the Internet worm,
             which  describes  a  method  that  allows  remote  hosts  to
             %%spoof'' a host into believing they  are  trusted.   Again,
             this article is technical in nature, and assumes familiarity
             with the protocols.
        _C_o_m_p_u_t_e_r _V_i_r_u_s_e_s _a_n_d _R_e_l_a_t_e_d _T_h_r_e_a_t_s: _A _M_a_n_a_g_e_m_e_n_t _G_u_i_d_e
        John P. Wack and Lisa J. Carnahan
        National Institute of Standards and Technology
        Special Publication 500-166
             This document  provides  a  good  introduction  to  viruses,
             worms,  trojan horses, and so on, and explains how they work
             and how they are used to attack computer  systems.   Written
             for the nontechnical user, this is a good starting point for
             learning about these security problems.  This  document  can
             be  ordered  for  $2.50  from  the U. S. Government Printing
             Office, document number 003-003-02955-6.
                                       56
                                    SECTION 7
                                   CONCLUSIONS
             Computer security is playing an increasingly important  role
        in our lives as more and more operations become computerized, and
        as computer networks become more widespread.  In order to protect
        your  systems  from snooping and vandalism by unauthorized crack-
        ers, it is necessary to enable  the  numerous  security  features
        provided by the UNIX system.
             In this document, we have covered the major areas  that  can
        be made more secure:
             o+    Account security
             o+    Network security
             o+    File system security.
        Additionally, we have discussed how to monitor for security  vio-
        lations, where to obtain security-related software and bug fixes,
        and numerous mailing lists for finding out about  security  prob-
        lems that have been discovered.
             Many crackers are not interested in breaking  into  specific
        systems, but rather will break into any system that is vulnerable
        to the attacks they know.  Eliminating these well-known holes and
        monitoring  the  system  for other security problems will usually
        serve as adequate defense against all  but  the  most  determined
        crackers.   By using the procedures and sources described in this
        document, you _c_a_n make your system more secure.
                                       57
                                       58
                                   REFERENCES
        [Eich89]  Eichin, Mark W., and Jon A. Rochlis.   _W_i_t_h  _M_i_c_r_o_s_c_o_p_e
                  _a_n_d  _T_w_e_e_z_e_r_s:  _A_n  _A_n_a_l_y_s_i_s  _o_f  _t_h_e _I_n_t_e_r_n_e_t _V_i_r_u_s _o_f
                  _N_o_v_e_m_b_e_r _1_9_8_8.  Massachusetts Institute of  Technology.
                  February 1989.
        [Elme88]  Elmer-DeWitt, Philip.   %%  %The  Kid  Put  Us  Out  of
                  Action.' '' _T_i_m_e, 132 (20): 76, November 14, 1988.
        [Gram84]  Grammp, F. T., and R. H. Morris.  %%UNIX Operating Sys-
                  tem  Security.'' _A_T&_T _B_e_l_l _L_a_b_o_r_a_t_o_r_i_e_s _T_e_c_h_n_i_c_a_l _J_o_u_r_-
                  _n_a_l, 63 (8): 1649-1672, October 1984.
        [Hind83]  Hinden, R., J. Haverty, and A. Sheltzer.   %%The  DARPA
                  Internet:  Interconnecting  Heterogeneous Computer Net-
                  works with Gateways.'' _I_E_E_E _C_o_m_p_u_t_e_r _M_a_g_a_z_i_n_e, 16  (9):
                  33-48, September 1983.
        [McLe87]  McLellan, Vin.  %%NASA Hackers:  There's  More  to  the
                  Story.'' _D_i_g_i_t_a_l _R_e_v_i_e_w, November 23, 1987, p. 80.
        [Morr78]  Morris, Robert, and Ken Thompson.  %%Password Security:
                  A  Case  History.'' _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M, 22 (11):
                  594-597,  November  1979.   Reprinted  in  _U_N_I_X  _S_y_s_t_e_m
                  _M_a_n_a_g_e_r'_s  _M_a_n_u_a_l,  4.3 Berkeley Software Distribution.
                  University of California, Berkeley.  April 1986.
        [NCSC85]  National  Computer  Security  Center.   _D_e_p_a_r_t_m_e_n_t   _o_f
                  _D_e_f_e_n_s_e  _T_r_u_s_t_e_d  _C_o_m_p_u_t_e_r  _S_y_s_t_e_m _E_v_a_l_u_a_t_i_o_n _C_r_i_t_e_r_i_a,
                  Department  of  Defense   Standard   DOD   5200.28-STD,
                  December, 1985.
        [Quar86]  Quarterman, J. S., and J. C. Hoskins.   %%Notable  Com-
                  puter  Networks.''  _C_o_m_m_u_n_i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M, 29 (10):
                  932-971, October 1986.
        [Reed84]  Reeds, J. A., and P. J.  Weinberger.   %%File  Security
                  and  the UNIX System Crypt Command.'' _A_T&_T _B_e_l_l _L_a_b_o_r_a_-
                  _t_o_r_i_e_s _T_e_c_h_n_i_c_a_l _J_o_u_r_n_a_l, 63  (8):  1673-1683,  October
                  1984.
        [Risk87]  _F_o_r_u_m _o_n _R_i_s_k_s _t_o _t_h_e _P_u_b_l_i_c _i_n _C_o_m_p_u_t_e_r_s  _a_n_d  _R_e_l_a_t_e_d
                  _S_y_s_t_e_m_s.  ACM Committee on Computers and Public Policy,
                  Peter G. Neumann, Moderator.   Internet  mailing  list.
                  Issue 5.73, December 13, 1987.
        [Risk88]  _F_o_r_u_m _o_n _R_i_s_k_s _t_o _t_h_e _P_u_b_l_i_c _i_n _C_o_m_p_u_t_e_r_s  _a_n_d  _R_e_l_a_t_e_d
                  _S_y_s_t_e_m_s.  ACM Committee on Computers and Public Policy,
                  Peter G. Neumann, Moderator.   Internet  mailing  list.
                                       59
                  Issue 7.85, December 1, 1988.
        [Risk89a] _F_o_r_u_m _o_n _R_i_s_k_s _t_o _t_h_e _P_u_b_l_i_c _i_n _C_o_m_p_u_t_e_r_s  _a_n_d  _R_e_l_a_t_e_d
                  _S_y_s_t_e_m_s.  ACM Committee on Computers and Public Policy,
                  Peter G. Neumann, Moderator.   Internet  mailing  list.
                  Issue 8.2, January 4, 1989.
        [Risk89b] _F_o_r_u_m _o_n _R_i_s_k_s _t_o _t_h_e _P_u_b_l_i_c _i_n _C_o_m_p_u_t_e_r_s  _a_n_d  _R_e_l_a_t_e_d
                  _S_y_s_t_e_m_s.  ACM Committee on Computers and Public Policy,
                  Peter G. Neumann, Moderator.   Internet  mailing  list.
                  Issue 8.9, January 17, 1989.
        [Risk90]  _F_o_r_u_m _o_n _R_i_s_k_s _t_o _t_h_e _P_u_b_l_i_c _i_n _C_o_m_p_u_t_e_r_s  _a_n_d  _R_e_l_a_t_e_d
                  _S_y_s_t_e_m_s.  ACM Committee on Computers and Public Policy,
                  Peter G. Neumann, Moderator.   Internet  mailing  list.
                  Issue 9.69, February 20, 1990.
        [Ritc75]  Ritchie, Dennis M.  %%On the Security  of  UNIX.''  May
                  1975.   Reprinted  in _U_N_I_X _S_y_s_t_e_m _M_a_n_a_g_e_r'_s _M_a_n_u_a_l, 4.3
                  Berkeley Software Distribution.  University of Califor-
                  nia, Berkeley.  April 1986.
        [Schu90]  Schuman, Evan.  %%Bid to Unhook  Worm.''  _U_N_I_X  _T_o_d_a_y!,
                  February 5, 1990, p. 1.
        [Seel88]  Seeley, Donn.  _A _T_o_u_r _o_f _t_h_e _W_o_r_m.  Department of  Com-
                  puter Science, University of Utah.  December 1988.
        [Spaf88]  Spafford, Eugene H.   _T_h_e  _I_n_t_e_r_n_e_t  _W_o_r_m  _P_r_o_g_r_a_m:  _A_n
                  _A_n_a_l_y_s_i_s.   Technical Report CSD-TR-823.  Department of
                  Computer Science, Purdue University.  November 1988.
        [Stee88]  Steele, Guy L. Jr., Donald R. Woods, Raphael A. Finkel,
                  Mark  R.  Crispin, Richard M. Stallman, and Geoffrey S.
                  Goodfellow.  _T_h_e _H_a_c_k_e_r'_s _D_i_c_t_i_o_n_a_r_y.  New York: Harper
                  and Row, 1988.
        [Stei88]  Stein, Jennifer G., Clifford  Neuman,  and  Jeffrey  L.
                  Schiller.   %%Kerberos:  An  Authentication Service for
                  Open Network Systems.'' _U_S_E_N_I_X _C_o_n_f_e_r_e_n_c_e  _P_r_o_c_e_e_d_i_n_g_s,
                  Dallas, Texas, Winter 1988, pp. 203-211.
        [Stol88]  Stoll, Clifford.  %%Stalking the Wily Hacker.'' _C_o_m_m_u_n_-
                  _i_c_a_t_i_o_n_s _o_f _t_h_e _A_C_M, 31 (5): 484-497, May 1988.
        [Stol89]  Stoll, Clifford.  _T_h_e _C_u_c_k_o_o'_s _E_g_g.  New York:  Double-
                  day, 1989.
        [Sun88a]  Sun Microsystems.  _S_u_n_O_S _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l, Part  Number
                  800-1751-10, May 1988.
        [Sun88b]  Sun Microsystems.  _S_y_s_t_e_m _a_n_d  _N_e_t_w_o_r_k  _A_d_m_i_n_i_s_t_r_a_t_i_o_n,
                                       60
                  Part Number 800-1733-10, May 1988.
        [Sun88c]  Sun Microsystems.  _S_e_c_u_r_i_t_y _F_e_a_t_u_r_e_s _G_u_i_d_e, Part Number
                  800-1735-10, May 1988.
        [Sun88d]  Sun Microsystems.  %%Network  File  System:  Version  2
                  Protocol  Specification.''  _N_e_t_w_o_r_k  _P_r_o_g_r_a_m_m_i_n_g,  Part
                  Number 800-1779-10, May 1988, pp. 165-185.
                                       61
                                       62
                         APPENDIX A - SECURITY CHECKLIST
             This checklist summarizes the information presented in  this
        paper, and can be used to verify that you have implemented every-
        thing described.
        _A_c_c_o_u_n_t _S_e_c_u_r_i_t_y
             []        Password policy developed and distributed to all users
             []        All passwords checked against obvious choices
             []        Expiration dates on all accounts
             []        No %%idle'' guest accounts
             []        All accounts have passwords or %%*'' in the password field
             []        No group accounts
             []        %%+'' lines in _p_a_s_s_w_d and _g_r_o_u_p checked if running Yellow Pages
        _N_e_t_w_o_r_k _S_e_c_u_r_i_t_y
             []        _h_o_s_t_s._e_q_u_i_v contains only local hosts, and no %%+''
             []        No ._r_h_o_s_t_s files in users' home directories
             []        Only local hosts in %%root'' ._r_h_o_s_t_s file, if any
             []        Only %%console'' labeled as %%secure'' in _t_t_y_t_a_b (servers only)
             []        No terminals labeled as %%secure'' in _t_t_y_t_a_b (clients only)
             []        No NFS file systems exported to the world
             []        _f_t_p_d version later than December, 1988
             []        No %%decode'' alias in the aliases file
             []        No %%wizard'' password in _s_e_n_d_m_a_i_l._c_f
             []        No %%debug'' command in _s_e_n_d_m_a_i_l
             []        _f_i_n_g_e_r_d version later than November 5, 1988
             []        Modems and terminal servers handle hangups correctly
        _F_i_l_e _S_y_s_t_e_m _S_e_c_u_r_i_t_y
             []        No setuid or setgid shell scripts
             []        Check all %%nonstandard'' setuid and setgid programs for security
             []        Setuid bit removed from /_u_s_r/_e_t_c/_r_e_s_t_o_r_e
             []        Sticky bits set on world-writable directories
             []        Proper umask value on %%root'' account
             []        Proper modes on devices in /_d_e_v
        _B_a_c_k_u_p_s
             []        Level 0 dumps at least monthly
             []        Incremental dumps at least bi-weekly
                                       63
                       This page intentionally left blank.
                               Just throw it out.
                                      lxiv
                                    CONTENTS
        1      INTRODUCTION...........................................  1
        1.1    UNIX Security..........................................  1
        1.2    The Internet Worm......................................  2
        1.3    Spies and Espionage....................................  2
        1.4    Other Break-Ins........................................  3
        1.5    Security is Important..................................  3
        2      IMPROVING SECURITY.....................................  5
        2.1    Account Security.......................................  5
        2.1.1  Passwords..............................................  5
        2.1.1.1                                                       Selecting Passwords6
        2.1.1.2                                                       Password Policies7
        2.1.1.3                                                       Checking Password Security7
        2.1.2  Expiration Dates.......................................  8
        2.1.3  Guest Accounts.........................................  8
        2.1.4  Accounts Without Passwords.............................  9
        2.1.5  Group Accounts and Groups..............................  9
        2.1.6  Yellow Pages........................................... 10
        2.2    Network Security....................................... 11
        2.2.1  Trusted Hosts.......................................... 11
        2.2.1.1                                                       The hosts.equiv File11
        2.2.1.2                                                       The .rhosts File12
        2.2.2  Secure Terminals....................................... 12
        2.2.3  The Network File System................................ 13
        2.2.3.1                                                       The exports File13
        2.2.3.2                                                       The netgroup File14
        2.2.3.3                                                       Restricting Super-User Access16
        2.2.4  FTP.................................................... 16
        2.2.4.1                                                       Trivial FTP17
        2.2.5  Mail................................................... 18
        2.2.6  Finger................................................. 19
        2.2.7  Modems and Terminal Servers............................ 19
        2.2.8  Firewalls.............................................. 20
        2.3    File System Security................................... 20
        2.3.1  Setuid Shell Scripts................................... 21
        2.3.2  The Sticky Bit on Directories.......................... 22
        2.3.3  The Setgid Bit on Directories.......................... 22
        2.3.4  The umask Value........................................ 22
        2.3.5  Encrypting Files....................................... 23
        2.3.6  Devices................................................ 23
        2.4    Security Is Your Responsibility........................ 24
        3      MONITORING SECURITY.................................... 25
        3.1    Account Security....................................... 25
        3.1.1  The lastlog File....................................... 25
        3.1.2  The utmp and wtmp Files................................ 25
        3.1.3  The acct File.......................................... 26
        3.2    Network Security....................................... 27
                                       iii
                              CONTENTS (continued)
        3.2.1  The syslog Facility..................................27
        3.2.2  The showmount Command................................28
        3.3    File System Security.................................29
        3.3.1  The find Command.....................................29
        3.3.1.1                      Finding Setuid and Setgid Files29
        3.3.1.2                         Finding World-Writable Files31
        3.3.1.3                                Finding Unowned Files31
        3.3.1.4                                Finding .rhosts Files31
        3.3.2  Checklists...........................................32
        3.3.3  Backups..............................................33
        3.4    Know Your System.....................................33
        3.4.1  The ps Command.......................................33
        3.4.2  The who and w Commands...............................34
        3.4.3  The ls Command.......................................34
        3.5    Keep Your Eyes Open..................................34
        4      SOFTWARE FOR IMPROVING SECURITY......................35
        4.1    Obtaining Fixes and New Versions.....................35
        4.1.1  Sun Fixes on UUNET...................................35
        4.1.2  Berkeley Fixes.......................................36
        4.1.3  Simtel-20 and UUNET..................................37
        4.1.4  Vendors..............................................37
        4.2    The npasswd Command..................................37
        4.3    The COPS Package.....................................38
        4.4    Sun C2 Security Features.............................38
        4.5    Kerberos.............................................39
        5      KEEPING ABREAST OF THE BUGS..........................41
        5.1    The Computer Emergency Response Team.................41
        5.2    DDN Management Bulletins.............................41
        5.3    Security-Related Mailing Lists.......................42
        5.3.1  Security.............................................42
        5.3.2  RISKS................................................42
        5.3.3  TCP-IP...............................................42
        5.3.4  SUN-SPOTS, SUN-NETS, SUN-MANAGERS....................42
        5.3.5  VIRUS-L..............................................43
        6      SUGGESTED READING....................................45
        7      CONCLUSIONS..........................................47
        REFERENCES..................................................49
        APPENDIX A - SECURITY CHECKLIST.............................51
                                       iv
                                        v

! * 3:38:37 p.m. ARE YOU STILL THERE ? ! *

3:43:37 p.m. RESPOND OR BE LOGGED OFF ! *** END OF SESSION

DISCONNECTED e5",*Kdlz NO CARRIER

/data/webs/external/dokuwiki/data/pages/archive/computers/unixsec.txt · Last modified: 1999/08/01 17:51 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki