Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: Antique Systems :: practica.txt

A Practical Exercise in Securing an OpenVMS System

                      A Practical Exercise in

                    Securing an OpenVMS System

                           Rob McMillan
                          Prentice Centre
                   The University Of Queensland
                    Now at Griffith University
                        Phone: 07 875 6557
             Postal: Information Technology Services
                       Griffith University
                          Nathan Qld 4111
        A Practical Exercise In Securing An OpenVMS System
   OpenVMS  machines have many features that can be used  to
   defend   them  from  attack.  To  properly  defend   your
   machine, you need to make use of these features from  the
   moment of delivery.
   In  this paper, I present the series of steps taken by  a
   typical systems programmer (namely the author) in  tuning
   the   defense  mechanisms  of  an  OpenVMS  machine,  and
   outline  some  non-standard mechanisms  employed  in  the
   defence of this machine.
   All  too often, emphasis is placed on particular accents,
   such  as  access prevention, or reactive examination  and
   monitoring  after  attack. This  paper  attempts  a  more
   holistic  approach  to  the  host-based  mechanisms  that
   could  be  employed to defend a machine.  Access  control
   mechanisms   (such   as  passwords,  user   authorisation
   parameters,  and  access control wrappers)  and  activity
   logging   mechanisms  (such  as  audit  trails,  terminal
   monitors and FAL logging) are considered.
   The information contained in this paper is given freely
   as  an account of my own experience, and may be used by
   the reader as the reader sees fit.
   No  responsibility or liability will be accepted by the
   author for any damages caused by direct or indirect use
   of  the information or functionality described in  this
   1.1 Assumptions
   This paper will discuss some of the features that can  be
   used  to  defend an OpenVMS machine from outside  attack.
   The  ideas presented in this paper are the result  of  an
   exercise   in  configuring  a  machine  in  a  university
   department used for a sensitive research project.
   All  of  the mechanisms I consider in this paper  can  be
   classed  as  host based mechanisms. However, the  defence
   of  an  computer system is not limited to these  measures
   Measures  that  should be used, but that I don't  discuss
   in this paper are:
        * network based security,
        * backups, and
        * physical security.
   This  paper is not intended to present an "expert's view"
   of  securing an OpenVMS machine. The reason for  this  is
   simple  -  whilst  my  knowledge of OpenVMS  security  is
   quite  solid,  I  would not put myself  in  the  "expert"
   category. Therefore this paper should not be seen as  the
   canonical  guide to OpenVMS security - rather, it  should
   be  seen  as  the  series  of measures  that  programmers
   should  typically  consider in defending  their  machine.
   There  is absolutely no substitute for reading the  Guide
   to VAX/VMS System Security manual.
   Finally,  this paper is concerned with the defence  of  a
   machine.  I do not personally make any attempt  to  crack
   machines.  I will not present any information on  how  to
   crack an OpenVMS machine.
   1.2 What This Paper Contains
   The  following  topics  are those considered  during  the
   configuration  of  the machine referred  to  above.  This
   list is not exhaustive.
     * System Mechanisms For Configuring The Machine To
       Control Access :
       * SYS$MANAGER Command Files
       * Welcome Messages
       * Accounts To Disable, Passwords To Change, And
         Objects To Modify
       * System Logicals And Logical Definitions
       * System Passwords
       * The UAF File
       * File Protections
       * ACLs
       * Tailoring UCX
       * Proxies

    * System Mechanisms For Configuring The Machine To Log
      Activity :
       * Accounting
       * Auditing
       * FAL and Poor Man's Routing
     * Using Homegrown Or Publicly Available Software :
       * Wrappers
       * Single Use PINs
       * Terminal Monitors
     * Monitoring The Use of The Machine :
       * The SHOW INTRUSION Command
       * Daily Activities
       * Having a Live Console
                 System Mechanisms For Configuring
                   The Machine To Control Access
   2.1 SYS$MANAGER Command Files
   There  are  three  files  in  SYS$MANAGER:  that  are  of
   importance   in   terms   of   this   paper.   They   are
   left  comments  about  SYLOGICALS.COM  for  Section  2.4,
   System Logicals And Logical Definitions.
   There are several different things to be done here.
   As  discussed in Section 2.5, System Passwords, a  system
   password  should  be installed. A system  password  means
   that  the  user  must enter a password before  the  login
   prompt   appears.  The  procedure  for  doing   this   is
   discussed  in  Section 2.5. However, this is  the  change
   you  could  make  in SYSTARTUP_V5.COM to  ensure  that  a
   console  user  does not need to enter the password.  (The
   console should be located in a physically secure area.)
    $! No system password required for console.
    $ write sys$output "[Modifying console settings]"
   This  ensures  that  should the  user  log  in  from  the
   console,  a  system password will not be  required.  This
   prevents  situations where you are locked  out  from  the
   machine should the password be changed or forgotten.
    $! The following commands turn off account logging and 
    $! delete the account log.
    $! To keep an account log on your system, delete the
    $! following 5 command lines.
   When the operating system is installed, this code is  not
   commented  out. That is, account logging is  not  enabled
   by  default.  It  is  good practice to  use  all  logging
   facilities  available  to you, and system  accounting  is
   one of those facilities that is strongly recommended.
   You  need  accounting to provide an extra audit trail  on
   the  system.  To  enable accounting,  comment  out  these
   lines, as shown on the following page.
    $! The following commands purge the operator and network
    $! logs to two versions.
   Here  the  machine is trying to make a  guess  about  how
   much  information should be saved as current  information
   (the  tradeoff being information currency and  usefulness
   against  disk  space).  A more reasonable  figure  is  10
   versions  (working on the basis of a new file  per  day).
   To implement this, do the following:
      * Comment out the lines above.
       *  Create artificial OPERATOR.LOG and EVL.LOG  files,
          each 1 version higher than the logs currently open
          and in use by the system.
          SET FILE EVL.LOG /VERSION_LIMIT=10.  This is  done
          against the files just created,  as  the  SET FILE
          command will fail against the logs open and in use
          by  the system.  When new files are opened for use
          by the system, they will be created with a version
          number  of  one   higher  than  the  logs  created
          artificially, but will inherit the version limit.
    $! This command defines a message to be displayed before
    $! each user logs in.
    $! This command defines a message or file to be
    $! displayed after each user logs in.
   For  legal reasons, as set out in SERT Advisory  SA-93.03
   (See  Appendix 1, SERT Advisory SA-93.03, Suggested Login
   Banner)  give people fair warning of the consequences  of
   misuse.  The  contents  of  the  files  ANNOUNCE.TXT  and
   WELCOME.TXT   are  discussed  in  Section  2.2,   Welcome
   Messages.  To  make these files appear,  the  definitions
   above are used.
   2.1.2 SYLOGIN.COM
   SYLOGIN.COM  is  a command file executed  when  any  user
   logs  in.  This is the ideal place to install  mechanisms
   to  universally  check  a  user's  credentials  (such  as
   username,  source of login, time, terminal or  knowledge-
   based authenticators).
   The  first  three  lines  of  SYLOGIN.COM  should  be  as
   follows (but aren't in the supplied file).
    $ SET NOON
   This  prevents a user (and hence crackers  in  the  first
   instance)   from   seeing  what   mechanisms   you   have
   installed,  and also interrupting the execution  of  this
   file to avoid these mechanisms.
    $! Place your site-specific LOGIN commands below
    $! If they get this far, then there may have been a breakin,
    $! but at least we can stop them at this point.
    $! Call the wrapper.
    $  IF ($Status .NE. %x10000001)
    $  THEN
    $    STOP/ID=0
    $  ENDIF
   As  the  comments outline, we use a command procedure  at
   this  point  to check credentials. This may  or  may  not
   involve  interactive exchanges. If the person logging  in
   fails  to pass the tests, then they are logged out.  (You
   will   need   to  define  LOCAL$WRAP,  for  example,   in
   2.2 Welcome Messages
   For  legal reasons, as set out in SERT Advisory  SA-93.03
   (See  Appendix 1, SERT Advisory SA-93.03, Suggested Login
   Banner)  give people fair warning of the consequences  of
   misuse.  By default, there is no SYS$WELCOME issued,  and
   SYS$ANNOUNCE welcomes the person logging in.  SYS$WELCOME
   needs   to   be  enabled,  and  point  to  a  file,   and
   SYS$ANNOUNCE  should also point to a file  (as  shown  in
   Section  2.1.1,  SYSTARTUP_V5.COM).  These  files  should
   outline   to   people  conditions  of  use,   and   legal
   consequences of misuse.
   SYS$ANNOUNCE  is  the  message  or  banner  that  appears
   immediately  before  the  login  prompt  (but  after  the
   system  password  has been entered). SYS$WELCOME  is  the
   message  or  banner  that appears immediately  after  the
   person  has logged in. In this way, users should normally
   see this warning before and after logging in.
   This message should appear in SYS$MANAGER:ANNOUNCE.TXT:
   ----- Warning Message -----
             ***** This service is for authorised staff only *****
   *                                                                       *
   * WARNING:   It is a criminal offence to:                               *
   *            i. Obtain access to data without authority                 *
   *                    (Penalty 2 years imprisonment)                     *
   *            ii Damage, delete, alter or insert data without authority  *
   *                    (Penalty 10 years imprisonment)                    *
   *                                                                       *
   The     following     message    should     appear     in

        This is {nodename} (VAX/VMS V5.5-2) - Unauthorised access prohibited!
           ***** This service is for authorised staff only *****
   *                                                                       *
   * WARNING:    It is a criminal offence to:                              *
   *             i. Obtain access to data without authority                *
   *                    (Penalty 2 years imprisonment)                     *
   *             ii Damage, delete, alter or insert data without authority *
   *                    (Penalty 10 years imprisonment)                    *
   *                                                                       *
   2.3 Accounts To Disable, Passwords To Change, And Objects
       To Modify
   2.3.1 Accounts
   VMS  is  supplied with a number of default  accounts.  It
   should   be   assumed  that  crackers  will  attempt   to
   compromise  a  machine using default  account  names  and
   passwords.  This  principle  applies  to  any   operating
   The   following  default  accounts  should   have   their
   passwords  changed,  and the accounts disabled:  DEFAULT,
   The accounts can be disabled thus:
   Depending  upon  how you wish to execute batch  jobs  and
   carry  out  general system administration, you  may  also
   wish  to  either similarly treat the SYSTEM  account,  or
   alternative apply strict access controls on this  account
   on the UAF file (See Section 2.6, The UAF File).
   2.3.2 Objects
   There are several objects that needed tailoring. Some  of
   the  tailoring  is  to prevent simple security  breaches,
   whereas  others  (like the modifications to  PHONE,  TASK
   and  FAL)  are  to prevent breaches that could  occur  in
   whole or in part to Poor Man's Routing (See Section  3.3,
   FAL and Poor Man's Routing).
   In  the  first  stage,  the PHONE and  TASK  objects  are
   In  the  PHONE application, the directory command can  be
   used  to  obtain a directory listing of users  on  remote
   DECNet  nodes.  It  is  essentially a  default  "finger".
   Whilst security through obscurity is no security at  all,
   any  access to system details should be suppressed  where
   The  TASK  object is used to execute jobs  on  your  node
   from  remote  nodes. Since this is not a desired  feature
   on  the  machine used in the preparation of  this  paper,
   this  object  was  disabled.  Alternatively,  the  object
   could  have been loaded with false information  into  the
   permanent database.
   These  objects  are  created at boot time  using  default
   information if there is no information about them in  the
   NCP  permanent  database. Therefore, a  job  can  be  run
   immediately after booting to remove these objects.
   The objects can be removed thus:
   They could alternatively be modified thus:
   In  the second stage below, objects are modified so  that
   they  are  still usable, but subject to tighter  controls
   than the default.
   The  simplest  change  is made to the  MIRROR  object  by
   disabling   the   MIRRO$SERVER  account   in   the   User
   Authorisation File. The MIRROR object should be  kept  to
   allow  loopback  testing should it become necessary.  The
   account  is  disabled since it serves no  useful  purpose
   (other   than  for  loopback  testing),  and  should   be
   disabled unless in use.
   The  MAIL object should be modified thus according to the
   VMS  v5.5-2  release  notes, Section 2.8.7,  to  restrict
   outgoing  access  on  the mail server.  In  v5.5-2,  MAIL
   enables   system  privileges  when  it  opens  a   DECnet
   connection  to  a  remote  mail  server.  By  restricting
   outgoing  access  on the mail server object  (as  below),
   unauthorised    users   are   prevented   from    placing
   connections on the mail server object.
   This  can  be undone by executing the same commands  with
   "NOSYSPRV".  MAIL_SERVER.EXE (the  executable  associated
   with  the  MAIL  object)  is installed  as  a  privileged

   Wrappers  should also be installed for the  FAL  and  NML
   objects.  The  executable  images  for  these   are,   by
   default,   normally  FAL.EXE  and  NML.EXE  respectively.
   Modify the object database as shown below.
   The  contents  of the wrappers are discussed  in  Section
   4.1, Wrappers.

   2.4 System Logicals And Logical Definitions
   SYS$MANAGER:SYLOGICALS.COM   is   used    to    establish
   important  site-specific logical names across the  entire
   system. You can put meaningful local definitions in  here
   as  well  as  the definitions already supplied  with  the
   delivered system.
    $! Undocumented feature to disable poor man's routing
   Poor  Man's Routing is explained in Section 3.3, FAL  and
   Poor Man's Routing.
   That  section  also  explains the  significance  of  this
   definition.  It's  relevance to this  section  is  merely
   that it is centrally defined in SYLOGICALS.COM.
    $! Make network server processes die after 10 seconds
    $! (to give separate NETSERVER.LOG files for
    $! each distinct operation)
   This  forces  network server processes to  die  after  10
   seconds   of   lying   idle,   thus   creating   separate
   NETSERVER.LOG   files   for  each  essentially   distinct
   operation. The tradeoff for these distinct files  is  the
   price  that must be paid in terms of process creation  on
   each network connection.
    $! System databases
   If  these  aren't defined, and a user attempts operations
   on  them,  new  ones can be created by that  user.  These
   definitions  prevent  this.  Note  file  protections  for
   these files in Section 2.7, File Protections.
   Other  system-wide logical symbols (such  as  LOCAL$WRAP)
   would also be defined in this file.
   2.5 System Passwords
   VMS  systems can have what is called a "system password".
   This  is  a password that must be typed BEFORE  the  host
   prompts  you for login information. So when you initially
   connect  to a system with a "system password", you  don't
   get  any prompting on the screen. Once you have typed  in
   the password, the normal prompt message appears.

   The  system password will appear or not depending on  the
   value  of  the sysgen parameter TTY_DEFCHAR2. A value  of
   %X80000   (i.e.   Hex)  enables  system  password.   This
   parameter is not dynamic.
   The  SYSGEN  parameter TTY_DEFCHAR2 (bit  represented  by
   %X80000)  enables  system password  by  default  for  all
   terminals (including LAT, X.25 and telnet terminals).
   The default value for TTY_DEFCHAR2 is 4098 (decimal):
    Parameter Name   Current   Default    Min.    Max.      Unit   Dynamic
    --------------   -------   -------   ------  ------     ----   -------
    TTY_DEFCHAR2        4098      4098     0       -1    Bit-Encode

   The    correct   value   can   be   set   by    modifying
   SYS$SYSTEM:MODPARAMS.DAT, and AUTOGENing the system.  The
   required  value  in MODPARAMS.DAT is set  by  adding  the
   following lines (amongst other values):
    TTY_DEFCHAR2 = %X80000 + %X1000 + %X2  ! = 528386
                 ! %X80000 (bit 19)     TT2$M_SYSPWD   System password
                 ! %X1000  (bit 12)     TT2$M_EDITING  Cmd line editing
                 ! %X2     (bit 1)      TT2$M_AUTOBAUD Autobaud
   The actual system password can be set either by DCL or
   or else by
   Terminals  can  be set /NOSYSPWD /PERM  or  /SYSPWD.  See
   Section 2.1.1 SYSTARTUP_V5.COM for an example.
   2.6 The UAF File
   This  is an extremely useful file for tuning security  on
   an  OpenVMS machine. The UAF file (and associated  files)
   allow  you  to control access to the system and  allocate
   resources to users.
   For  the purposes of this paper, there are several fields
   worth  considering. Specifically, the ones  that  can  be
   used  include (but are not restricted to) access  control
   fields, password control fields and the rights list.
   On  the  particular  machine used in the  preparation  of
   this paper, there are several accounts that are used  for
   specific  purposes,  and  should  be  used  only   within
   specific  time frames. For instance, consider an  account
   (the  "USER1"  account for the purposes of this  example)
   which  should only be used interactively during the hours
   of  8am  to  7pm on primary days (Monday to Friday),  but
   can  run  batch  jobs at any time on any day.  All  other
   access is to be denied.
   This is achieved by the following commands:
         /LOCAL=(PRIMARY:8-18) /REMOTE=(PRIMARY:8-18)

   This  results  in an access control matrix like  the  one
   Primary days:   Mon Tue Wed Thu Fri 
   Secondary days:                     Sat Sun
   Primary   000000000011111111112222  Secondary   00000000001111111111222
   Day Hours 012345678901234567890123  Day Hours   012345678901234567890123
   Network:  -----  No access  ------            -----  No access  ------
   Batch:    ##### Full access ######            ##### Full access######
   Local:    --------###########-----            -----  No access  ------
   Dialup:   -----  No access  ------            -----  No access  ------
   Remote:   --------###########-----            -----  No access  ------

   Full access can be restored using:
   Passwords  are  historically a  weak  point  in  computer
   systems.  A weak password on a single account leaves  the
   entire  system  vulnerable to attack.  (See  Appendix  2,
   SERT  Advisory  SA-93.04,  Guidelines  For  Developing  A
   Sensible Password Policy.)
   You  must  therefore  ensure that  all  accounts  have  a
   minimum  password length of 8 characters, and  that  they
   expire  at  regular  intervals. In  addition,  privileged
   accounts should have password lengths greater than  that,
   and   passwords   should   be  set   using   the   MODIFY
   {accountname} /GENERATE_PASSWORD command.
   The  other  important  use of the  AUTHORIZE  utility  is
   creating  rights  list identifiers  and  using  these  in
   conjunction  with  ACLs to control access  to  files  and
   devices at individual levels.
   For  instance,  on the machine used while preparing  this
   paper, there is a particular device and a directory  that
   should  only ever be accessed by a small group of people.
   This  device  is  used for a research  project,  and  the
   results  are kept in the directory. The entire  group  of
   people  involved with the experiment needed to  read  the
   results  (kept  in  the  DISKE:[EXPERIMENT1]  directory),
   whereas  only  a few people needed write access  to  this
   directory.  Furthermore, because they  were  all  in  the
   same  project  team,  they were all  allocated  the  same
   group  number. Finally, there was a restricted number  of
   people  in  this group who were authorised to access  the
   device used in the experiment in question.
   The  first step in controlling this is to create  various
   rights list identifiers, and granting them to people  who
   should  access  them.  The rights  list  identifiers  are
   created as follows:

   Users  1..10  are  allowed read access  to  the  results;
   users  5,  6 and 7 are allowed write access and  users  6
   and 7 are allowed to control the transducer.

   ACLs  and  protection  are then set  on  the  device  and
   directory as set out in Section 2.8, ACLs.
   Finally,  great care has been taken in the allocation  of
   privileges  to  individual user accounts. In  particular,
   the  default  privileges  must be  kept  to  the  minimum
   2.7 File Protections
   File  protection  is an important aspect in  preventative
   security. Checks should be periodically carried  out  for
   world-writeable  files and directories,  and  appropriate
   action taken.
   In  addition, various sensitive files should be confirmed
   as having the following protection.
    <disk>:[000000]000000.DIR      (S:RWE,O:RWE,G:RE,W:E)
    <disk>:[000000]INDEXF.SYS      (S:RWE,O:RWE,G:RE,W)
       *  This  prevents  unauthorised  users  from  finding
          directory and file names.
    SYS$SYSTEM:NCP.EXE             (S:RWE,O:RWE,G:RWE,W)
      *  This ensures that unauthorised users cannot  change
         the NCP and authorisation databases through the use
         of these  programs.  Note  that  merely  protecting
         these programs does not prevent modification of the
         data  files - it  is imperative that the data files
         themselves are protected.
      *  This ensures that unauthorised users cannot  change
         information   in   these   databases,   nor    gain
         information    about    other   users   or   system
         configuration from these files.
      *  This ensures that unauthorised users cannot  change
         information   in    these   databases,   nor   gain
         information about other users from these files.
   For  more  details  on  File  Protections,  see  Managing
   Security  in  a Multi-Vendor Network by Ron Tencati,  and
   also the Guide to VAX/VMS System Security manual.
   2.8 ACLs
   This  section, is a continuation of the example  supplied
   in  Section 2.6, The UAF File, about access control using
   rights list identifiers.
   In  a  particular  experiment, experimental  results  are
   being  kept  in  the DISKE:[EXPERIMENT1]  directory.  The
   results  are  obtained using a transducer  controlled  on
   device RCD0:.
   Various   rights   list  identifiers  to   read   results
   (EXP1_READ),  write  a  file  to  the  results  directory
   (EXP1_WRITE)  and  control the transducer  (EXP1_CONTROL)
   have  been created. These rights identifiers are used  in
   the  the  creation  of access control  lists  to  enforce
   these access control principles.
   The transducer is the first object so modified:
    {Device details on NODE1$RCD0: deleted}
    device, error logging is enabled.
    Error count                0    Operations completed 26
    Owner process             ""    Owner UIC   [0,0]
    Owner process ID    00000000    Dev Prot    S:RWED,O:RWED,G:RWED,W:RWED
    Reference count            0    Default buffer size   2048
    Density              unknown    Format  {deleted}
    Volume status:  {deleted}
    Device access control list:
   On  the machine used for preparing this paper, the nature
   of  the  device prevented us from changing the protection
   using  the  SET PROTECTION/DEVICE command.  However,  the
   ACL is sufficient to control access to this device.
   The  next  step  is to protect the directory  (and  files
   under  it).  An  ACL  is applied to  the  directory  file
   usinfg the commands on the next page.
    Directory DISKE:[000000]
    EXPERIMENT1.DIR;1     4    17-JUN-1992 11:19:27.01  [SYSTEM] (,,,)
    Total of 1 file, 4 blocks.

   This means that only people who specifically possess  the
   EXP1_WRITE  rights  list identifier  can  write  to  this
   directory.  Users  who  possess the EXP1_READ  identifier
   can  read the contents of the directory as can the SYSTEM
   account  (but  not system privileged accounts  or  system
   UIC group members). All other access is denied.
   Note  that action is taken on the first match of the ACL.
   So,  for example, if the SYSTEM account is being used  to
   access   data  in  DISKE:[EXPERIMENT1],  and  the  system
   account  has  the EXP1_READ right, then SYSTEM  can  read
   the  data by virtue of this right as opposed to being the
   system   account.  The  reason  for  this  is  that   the
   EXP1_READ identifier occurs before [SYSTEM] in the ACL.
   Any  directories  created  in this  directory  after  the
   creation of this ACL will inherit this ACL.
   2.9 SYSGEN Parameters
   There   are  various  SYSGEN  parameters  that  must   be
   considered and/or changed during configuration.  Many  of
   these  are  related  to system performance  and  are  not
   within  the scope of this paper. Parameters that must  be
   considered  from  a  security point of  view  are  listed
   below,  with  extracts from the SYSGEN HELP  facility  on
   their   use.  (See  SYSGEN>  HELP  PARAMETERS  for   more
   TTY_DEFCHAR2: Bit 19 (TT2$M_SYSPWD) is set to  allow  the
   use  of system passwords. The password was set using  the
   AUTHORIZE  utility  (see Section 2.5, System  Passwords),
   and  the  console is modified such that the  password  is
   not  required when logging on from that source (using SET
   2.1.1, SYSTARTUP_V5.COM.) All other terminals must  enter
   the system password before the login prompt is issued.
   This  parameter  (TTY_DEFCHAR2). amongst others,  can  be
   set in SYS$SYSTEM:MODPARAMS.DAT with a single line:
   TTY_DEFCHAR2 = %X80000 + %X1000 + %X2        ! = 528386
                ! %X80000 (bit 19)   TT2$M_SYSPWD   System password
                ! %X1000  (bit 12)   TT2$M_EDITING  Cmd line editing
                ! %X2     (bit 1)    TT2$M_AUTOBAUD Autobaud
   LGI_PWD_TMO: Period of time, in seconds, a  user  has  to
   correctly  enter  the system password on  a  terminal  on
   which the system password is in effect.
   LGI_BRK_TMO:  Specifies  the number  of  seconds  that  a
   user,  terminal, or node is permitted to attempt a  login
   before  the  system  assumes that a  breakin  attempt  is
   occurring and evasive action is required.
   LGI_BRK_LIM:  Specifies the number of failures  that  may
   occur  at  login time before the system will take  action
   against a possible breakin.
   LGI_RETRY_TMO:  Specifies the number of  seconds  allowed
   between login retry attempts after a login failure.
   LGI_RETRY_LIM:  Specifies the number  of  retry  attempts
   allowed for users attempting to login over dialup lines.
   LGI_HID_TIM:   Specifies  the  number  of  seconds   that
   evasive action will persist following the detection of  a
   possible breakin attempt. The evasive action consists  of
   refusing   to  allow  any  logins  during  this   period,
   regardless of whether a valid user name and password  are
   LGI_BRK_DISUSER: When set, turns on the DISUSER  flag  in
   the  UAF  record when an attempted breakin  is  detected,
   thus permanently locking out that account.
   LGI_BRK_TERM: Causes the terminal name to be part of  the
   association  string  for  the terminal  mode  of  breakin
   Note  that if parameters are changed using SYSGEN, modify
   both  the  CURRENT image and the ACTIVE, running  system.
   Leave DEFAULT as it is.

   2.10 Tailoring UCX
   The  machine  being  configured  required  only  incoming
   telnet  access,  and outgoing telnet  and  ftp.  SMTP  is
   handled  by a dedicated mail package (MX). Other services
   like  SNMP,  NFS  and  Berkeley  "r"  commands  are   not
   required (or, in fact, desirable).
   Services not required are shutdown thus:
    $! -- Shutdown what we don't need
    $! -- Disable incoming connections on other services
   In  addition, the relevant UCX accounts are  disabled  in
   the  User Authorization File (using UAF> MODIFY <account>
   /flag=DisUser):  UCX$FTP,  UCX$NFS,  UCX$REXEC,  UCX$RSH,
   UCX$SNMP, UCX_LPD, UCX_SMTP. Telnet (interactive)  access
   should  be  monitored using a wrapper  (as  discussed  in
   Section 4.1, Wrappers).
   2.11 Proxies
   Proxies  should not be allowed if they are not  required!
   If  a  net proxy is required for file transfer, the proxy
   must  be  created on the remote machine, and the required
   command  issued on the local machine. The theory here  is
   that  the  local machine is less likely to be compromised
   than  an  outside  machine, and the use of  proxies  will
   reduce   the   instances  of  access  information   being
   transmitted over a network connection.
   Only  allow  proxy access to a non-privileged account  on
   the target system.
                 System Mechanisms For Configuring
                    The Machine To Log Activity
   There  are  several facilities available  to  the  system
   administrator to achieve effective logging.  Specifically
   these  are  accounting and auditing. There is also  scope
   for  development of local tools. In this section, I  will
   outline  the  use  of  the  standard  facilities,   while
   homegrown  mechanisms  will be  considered  in  the  next
   Firstly,  it  will  be useful to have  a  brief  look  at
   accounting and auditing. System accounting is a  facility
   for  recording information about the use of  the  machine
   from a normal system accounting perspective, whereas  the
   system  audit  logger  records similar  information,  but
   from a system security perspective. Both of these can  be
   used  to  construct audit trails of activity. Information
   from  the  system  audit logger can be gleaned  not  only
   from  the audit journal, but also from the operator  log,
   as the auditor also sends it's messages to OPCOM.
   Consider,  for  example,  a situation  in  which  a  user
   (USER1) has made a modification to USER2's entry  in  the
   User Authorization File.
   The audit logger returns the following information:
    Security alarm (SECURITY) and security audit (SECURITY) on NODE1,
        system id: 1072 / System UAF record modification
    Event time:            27-JUL-1993 12:15:17.47
    PID:                   0000005F
    Username:              USER1
    Image name:            NODE1$DKA0:[SYS0.SYSCOMMON.][SYSEXE]AUTHORIZE.EXE
    Object name:           SYS$COMMON:[SYSEXE]SYSUAF.DAT;1
    Object type:           file
    User record modified:  USER2
    Fields modified:       FLAGS,PRIVILEGES
   The accounting facility contains this:
   AUTHORIZE Image Termination
   Username:         USER1       UIC:               [STAFF,USER1]
   Account:       STAFF       Finish time:       27-JUL-1993 12:15:27.79
   Process ID:    0000005F    Start time:        27-JUL-1993 12:14:51.23
   Owner ID:                  Elapsed time:      0 00:00:36.56
   Terminal name: RTA1:       Processor time:    0 00:00:00.22
   Remote node addr: 1038     Priority:          4
   Remote node name: NODE2    Privilege <31-00>: 10148001
   Remote ID:     USER2       Privilege <63-32>: 00000040
   Queue entry:               Final status code: 00000001
   Queue name:
   Job name:
   Final status text: %SYSTEM-S-NORMAL, normal successful completion
   Page faults:      238         Direct IO:         32
   Page fault reads:   9         Buffered IO:       58
   Peak working set: 631         Volumes mounted:   0
   Peak page file:  1166         Images executed:   244
   Both  facilities  tell us that USER1  ran  the  AUTHORIZE
   utility  successfully under PID 5F at 12:15 pm on 27-Jul-
   1993.  From the accounting, we can see at a glance  where
   USER1  logged in from. The audit logger tells us  exactly
   what USER1 did whilst running this utility.
   Consider  another  example, in which a  computer  cracker
   has  logged in from an X.25 network address in an attempt
   to  maintain anonymity. The audit server has recorded the
   following information in the operator log:
   %%%%%%%%%%%  OPCOM  27-Jul-1993 19:38:23.60  %%%%%%%%%%%
   Message from user AUDIT$SERVER on NODE1
   Security alarm (SECURITY) and security audit (SECURITY) on NODE1,
     system id: 1038
   Auditable event:    Dialup interactive login
   Event time:         27-Jul-1993 19:38:23.59
   PID:                20205316
   Username:           USER1
   Terminal name:      _VTA1514 ({X.25 address deleted})
   The  system accounting record from the same user  logging
   out returns the following information:
   LOGINOUT Image Termination
   Username:      USER1       UIC:  [STAFF,USER1]
   Account:       STAFF       Finish time:     27-Jul-1993 03:36:17.69
   Process ID:    20205316    Start time:      27-Jul-1993 19:38:07.19
   Owner ID:                  Elapsed time:              0 07:58:10.50
   Terminal name: VTA1514     Processor time:            0 00:00:46.14
   Remote node addr:          Priority:                              4
   Remote node name:          Privilege <31-00>:              00108000
   Remote ID:                 Privilege <63-32>:              00000000
   Queue entry:               Final status code:              00000001
   Queue name:
   Job name:
   Final status text: %SYSTEM-S-NORMAL, normal successful completion

   Page faults:       4716        Direct IO:            20927
   Page fault reads:   208        Buffered IO:          85056
   Peak working set:   970        Volumes mounted:      0
   Peak page file:    4813        Images executed:      28
   The  two  records act as a useful cross  check  for  each
   other.  The  audit  logger shows the  X.25  address  from
   which the user logged in from (which is not available  in
   this  accounting record). The accounting  facility  shows
   the  length of time that the user was on the system. When
   this  information is collated with the network accounting
   information,  then  the  cost of the  connection  can  be
   calculated. Furthermore the accounting records and  audit
   records can be examined to aid in determining the  extent
   of the damage caused by the attacker.
   3.1 Accounting
   Confirm that required system accounting is enabled thus:
    $  SET ACCOUNTING /ENABLE[=(Keyword...)]
   The  command  above enables logging of all activities  on
   the  system  in  the accounting file. Accounting  can  be
   enabled to log the following activities.
        PROCESS               any process termination
        IMAGE                 image execution
        INTERACTIVE           interactive job termination
        LOGIN_FAILURE         login failures
        SUBPROCESS            subprocess termination
        DETACHED              detached job termination
        BATCH                 batch job termination
        NETWORK               network job termination
        PRINT                 all print jobs
        MESSAGE               user messages
   Each  day,  a  new accounting file should be  created  in
   order  to keep the accounting files of a manageable size,
   using the command -

   3.2 Auditing
   The  auditor  can  be  configured to  log  the  following
        ACL                 Event requested by an Access Control List Item
        AUTHORIZATION       Modification of the system user authorization file
        BREAKIN             Occurrence of a breakin attempt 
                             (from various sources)
        FILE_ACCESS         File or global section access
                             (by various methods)
        INSTALL             Occurrence of any INSTALL operation
        LOGFAILURE          Occurrence of a login failure
                             (from various sources)
        LOGIN               A login attempt (from various sources)
        LOGOUT              Occurrence of a logout
        MOUNT               Issuance of a mount or dismount request
   This  is  done  using  SET AUDIT /ENABLE=(keyword[,...]).
   The  /ALARM qualifier is also used to raise an  alarm  to
   all terminals enabled as security operators.
   You  can  examine the configuration of your system  audit
   server  using SHOW AUDIT /ALL. The categories that should
   be   carefully   considered  are  the   auditing   server
   characteristics, the alarm failure mode, and the  enabled
   security alarms.
   Note  that  within  the auditing server  characteristics,
   the  default final resource action is to crash the system
   if  the  system  runs out of virtual memory.  This  means
   that  if  the  disk containing the audit journal  log  is
   full, the system will crash, thus exposing the system  to
   denial  of  service attacks. When configuring  the  audit
   server,  you should carefully consider the final resource
   action  parameter.  It can be set  using  the  SET  AUDIT


   (where  action  can  be  one  of  CRASH,  IGNORE_NEW   or

   As  with system accounting, a new audit journal should be
   created each day:

   3.3 FAL and Poor Man's Routing
   In  order  to  properly explain the step  taken  in  this
   phase,  it  is  necessary to understand what  Poor  Man's
   Routing  is,  and how it is linked with the  File  Access
   Listener (FAL) object and the logical FAL$LOG.
   The  FAL  object  (File Access Listener)  is  the  DECnet
   object that allows a remote user to access files on  your
   node.  It  can  be used to browse your node,  or  perform
   file  transfers. For legitimate users, this is  extremely
   useful  - unfortunately, people with malintent also  find
   it useful if your system is not protected.
   In  the  context  of  DECnet networking  operations  (and
   specifically  FAL), "Poor Man's Routing (PMR)  refers  to
   the  technique  of  supplying an  explicit  path  to  the
   required  target,  rather  than letting  assigned  DECnet
   routers  pick the most optimal path" [Tencati]. When  PMR
   is  used,  a process is created on each node in the  path
   to  forward the connection to the next node in the  path.
   Each  of  these  nodes (including the  destination  node)
   only  sees the connection from it's path predecessor.  It
   is   therefore  very  difficult  to  ascertain  from  the
   destination node where the connection originated from.
   The  legitimate use of this is in cases where the  source
   node  may  not  know  anything  about  the  remote  note.
   Unfortunately,  people  with  malintent   can   use   the
   properties  described above to create a  convoluted  path
   to  the  node  they wish to attack (possibly via  several
   timezones and countries) to hide themselves effectively.
   PMR  can  also  be  used to defeat the hiding  of  DECnet
   subnets. There is a parameter in the NCP database  called
   the  maximum  area  (see NCP> HELP SET  EXECUTOR  MAXIMUM
   AREA).  This parameter specifies the largest area  number
   known  to an executor's routing layer. If used carefully,
   this  parameter can be used to hide subnets. PMR  can  be
   used  to  circumvent this technique if the  attacker  has
   appropriate  information about your network design.  (The
   lesson  here is to never trust security through obscurity
   -  always  rely on robust, proactive methods rather  than
   ignorance.) Ron Tencati's Managing Security in  a  Multi-
   Vendor  Network gives a good explanation of PMR, and  the
   use of Area Routing.
   You  can  configure  FAL  by use of  the  logical  symbol
   FAL$LOG. In the machine used in the preparation  of  this
   paper, this logical was configured to do two things:
     * refuse connections made by PMR
     * supply   audit  trail  information  in  NETSERVER.LOG
       files in the case of successful FAL connections.
   The  logical name FAL$LOG translates to a string  of  the
   form xx_yy where:
     * xx  is  a  hexadecimal number representing a longword
       string value
     * yy  is a hexadecimal number specifying how many bytes
       of  each  DAP message are to be displayed in the  log
       file (SYS$OUTPUT:).
   The hexadecimal flags are:
       0001 - log filename/function requests
       0002 - log throughput statistics
       0004 - log individual DAP messages
       0008 - log DAP message packet AST requests (logged at AST level)
       0010 - log DAP message packet QIO requests
       0020 - reserved
       0040 - disable DAP message blocking
       0080 - disable DAP CRC error checking
   In  SYS$MANAGER:SYLOGICALS.COM, FAL$LOG should be defined
   to  be  the character string "03/DISABLE=8" (See  Section
   2.4,   System  Logicals  And  Logical  Definitions).   By
   setting  this  logical to this value,  the  following  is
     * PMR is disabled ("/DISABLE=8")
     * filename/function requests and throughput  statistics
       are  logged (the setting "03" being  the addition  of
       "01" and "02"
   Consider  an  example where NODE1::USER1 is  executing  a
   directory on NODE2::USER2's home directory. In  the  file
   NETSERVER.LOG  in  USER2's directory, we  would  see  the
   following results.
   With no definition for FAL$LOG:
            Connect request received at 28-JUL-1993 15:36:45.78
                  from remote process NODE1::"0=USER1"
                  for object "SYS$COMMON:[SYSEXE]FAL.EXE"
   With   FAL$LOG   defined  to  be  "03/DISABLE=8",   extra
   information is appended:
         Connect request received at 28-JUL-1993 15:55:40.28
         from remote process NODE1::"0=USER1"
         for object "SYS$COMMON:[SYSEXE]FAL.EXE"
         FAL V5.1-D3 started execution on 28-JUL-1993 15:55:41.12
         with SYS$NET = NODE1::"0=USER1" and with FAL$LOG = 03
         Logical link was established on  28-JUL-1993 15:55:41.13
         Requested file access operation: Directory List
         Specified file: DISKE:[USER2]L*.*;*
         Resultant file: DISKE:[USER2]LOGIN.COM;3
         Resultant file: DISKE:[USER2]LWK_PERSONAL.LINKBASE;1
         Logical link was terminated on   28-JUL-1993 15:55:41.18
         Total connect time for logical link was    0 00:00:00.05
         Total CPU time used for connection was     0 00:00:00.02
         File Access Statistics for RECV-Side XMIT-Side Composite
         -------------------------- --------- --------- --------
         # DAP Message QIO Calls            2         2         4
         # DAP Messages Exchanged           2        14        16
         # User Records/Blocks              0         0         0
         NETSERVER.LOG (continued)
         # Bytes of User Data               0         0         0
         # Bytes in DAP Layer              49       310       359
         User Data Throughput (bps)         0         0         0
         DAP Layer Throughput (bps)      7840     49600     57440
         Average Record/Block Size          0         0         0
         % User Data in DAP Layer        0.0%      0.0%      0.0%
         -------------------------- --------- --------- ---------
         Negotiated DAP buffer size           = 1060 bytes
         Buffered I/O count during connection = 13
         Direct I/O count during connection   = 0
         Peak working set size for process    = 470 pages
         Successful Start Transaction Branch  = 0
         Start Transaction Branch loops       = 0
         FAL terminated execution on      28-JUL-1993 15:55:41.21
          Using Homegrown Or Publicly Available Software
   4.1 Wrappers
   A  "wrapper"  is  a  piece of software that  monitors  an
   attempt to use a service, and based on the details  about
   the  source of the attempt (such as remote host and user,
   time,  and connection type), determine whether  to  allow
   the  use of the service or not. This is the feature  that
   a  wrapper  has  available to it over and above  standard
   system  logging  software: the use of the  wrapper  gives
   the  system manager freedom to make decisions whether  to
   allow  the  use  of  the machine from a  remote  site  in
   addition to simply logging that use.
   Wrappers  should  be  constructed for  the  NML  and  FAL
   objects, and also for interactive logins. Section  2.1.2,
   SYLOGIN.COM and Section 2.3.2, Objects gives the  details
   on how to install these wrappers.
   Because  the  NML and FAL wrappers need to handle  DECnet
   connections   only,  they  are  more  simple   than   the
   interactive login wrapper.
   The  DECnet  object wrappers evaluate the  connection  by
   comparing the remote node and user combination against  a
   set  of  rules.  The  set of rules is  described  in  two
     AllowFile which describes which combinations  may  make
               the connection, and
     DenyFile  which describes which combinations  may  not
               make the connection.
   Wildcards are allowed. The general algorithm is:

     Main ()
       RemoteUser = f$trnlnm("SYS$REM_ID")
       RemoteNode = f$trnlnm("SYS$REM_NODE")
       ConnectionOkay = CheckRules(RemoteNode, RemoteUser)
       if (ConnectionOkay = Allow) /* ConnectionOkay = Allow|Deny */
         write successful connection record to wrapper log
         request/to=(network,security) "<Succesful connection details>"
         run SYS$SYSTEM:FAL.EXE
         write failed connection record to wrapper log
         request/to=(network,security) "<Failed connection details>"
     } end Main
     CheckRules (RemoteNode, RemoteUser)
       if ((result = CheckCombination(RemoteNode, RemoteUser)) != Unknown)
         then return result
       if ((result = CheckCombination(RemoteNode, "*"))        != Unknown)
         then return result
       if ((result = CheckCombination("*", "*"))               != Unknown)
         then return result
       return Deny
     }  end CheckRules
     CheckCombination (RemoteNode, RemoteUser)
       Search AllowFile for RemoteNode::RemoteUser
       if found then return Allow
       Search DenyFile for RemoteNode::RemoteUser
       if found then return Deny
       return Unknown
     }  end CheckCombination
   The  search  commands used above should be  such  that  a
   wildcard  search matches the literal "*" in a  file,  not
   any  string  (in  a  similar manner to the  VMS  "SEARCH"
   command).  Hence the wildcard value of "*" is  placed  in
   the  file  by the system manager. The general  philosophy
   that  should  be  adopted is to use a blanket  denial  (a
   single  line  of "*::*" in the deny file)  with  specific
   allowed node::user combinations in the allow file.
   The  interactive connection wrapper is similar, with only
   a slightly more complicated top level algorithm:
     Main ()
   |    Establish RemoteUser
   |    Establish RemoteNode
        ConnectionOkay = CheckRules(RemoteNode, RemoteUser)
        if (ConnectionOkay = Allow) /* ConnectionOkay = Allow|Deny */
          write successful connection record to wrapper log
          request/to=(network,security) "<Succesful connection details>"
   |      exit(Success)
          write failed connection record to wrapper log
          request/to=(network,security) "<Failed connection details>"
   |      exit(Failure)
     } end Main
   The  main  problem here is to establish remote  user  and
   node  identities. Interactive access may take place using
   DECnet,  LAT,  TCP/IP and so on. System  values  used  to
   find this information are:
     * the DECnet database
     * the local terminal type of the connection
     * information from F$TRNLNM("DECW$DISPLAY")
   Connections  are then evaluated not only on  remote  node
   and  user (if provided by the protocol), but also by  the
   protocol    used   for   the   connection    and    local
   characteristics (such as the time).
   It  is  important to note that any reading from AllowFile
   or  DenyFile,  and writing to the wrapper log  should  be
   carried out by installed, protected images, and that  the
   command  file(s)  and executable(s)  used  are  writeable
   only   by   system  privileged  accounts.  This  prevents
   modification  of  behaviour  and  recorded   results   by
   potential attackers.
   Example  code and configuration files appear in  Appendix
   3, Wrapper Example.

   4.2 Single Use PINs
   A  Personal  Identification Number (PIN)  is  simply  the
   numerical equivalent of a text-based password.  Unlike  a
   normal  password system, though, a single use PIN  relies
   on   algorithmic  knowledge  rather  than  static   value
   The  system  works thus: when a user logs in, system  and
   user  passwords must be supplied as described in previous
   sections. A numerical challenge is then issued. The  user
   must  supply the correct reply to this challenge, or  the
   login   will  be  denied.  The  correct  reply  is   some
   permutation  of  the  original challenge.  The  challenge
   must  be randomly generated, so that every time the  user
   logs  in,  a  different numerical challenge is  supplied,
   requiring  a  unique reply - only the algorithm  used  to
   deduce   the   reply  from  the  challenge   is   static.
   Furthermore, this algorithm is different for  each  user.
   The  software which issues the challenge and receives the
   reply  must be robust, so that an attacker cannot  simply
   "crash" the software and hence bypass this mechanism.
   Such systems are available commercially. A smart-card  is
   usually  supplied with such systems. The  user  keys  the
   challenge  supplied by the host into the smartcard  using
   the  keypad.  The smartcard then displays  the  response,
   and the user enters this as the reply to the host.
   A  cheaper alternative is to write such a system locally,
   fulfilling all of these criteria. A usage policy must  be
   in place to effectively manage this system.
   4.3 Terminal Monitors
   Terminal  monitors  are  useful utilities  for  providing
   help to users who may be working remotely, or may not  be
   reachable by telephone and require some type of  help  in
   real-time (i.e. electronic mail would not suffice).
   Where  such  utilities are available on the system,  they
   must  be adequately protected to ensure that unauthorised
   users  can neither use them nor copy them. Care  must  be
   taken  to  ensure that explicit permission is  sought  by
   the  legitimate  users concerned or a relevant  authority
   when such a utility is used.
   Similar  principles apply when using system software  for
   capturing  a process's recall buffer in order to  examine
   the commands issued by that process.
                 Monitoring The Use Of The Machine
   It  is  essential to carry out monitoring on any  machine
   in  order  to  evaluate  the health  of  the  system.  In
   addition  to  checks  that should be  carried  out  on  a
   regular  basis,  steps should be taken to  be  allow  for
   investigation of unusual security related events as  soon
   as possible.
   5.1 The SHOW INTRUSION Command
   Use  the  command SHOW INTRUSION regularly. This  command
   displays   the   contents  of  the   break-in   database,
   providing  a quick technique for checking if  there  have
   been  attempts to break into your system in the immediate
   When  using  the SHOW INTRUSION command, you  must  first
   get  some  idea  if the host has detected  any  potential
    Intrusion       Type       Count  Expiration   Source
    NETWORK       SUSPECT       6    16:32:23.03   NODE2::USER2
    TERM_USER     SUSPECT       3    16:18:14.16   USER1
   In  this  case,  there  are two  suspect  incidents.  The
   records  below  show that the first  was  an  attempt  by
   USER2  on node NODE2 to login as USER1 on the local  host
   (NODE1) via DECnet. The second is an attempt to login  as
   USER1  on  the local host using telnet from NODE3  (which
   in this case was actually the localhost -
   The accounting records show the following:
   Username:      USER1         UIC:            [SYSTEM]
   Account:       <login>       Finish time:    3-AUG-1993 16:02:28.80
   Process ID:    2080D073      Start time:     3-AUG-1993 16:02:19.59
   Owner ID:                    Elapsed time:            0 00:00:09.21
   Terminal name: RTA3:         Processor time:          0 00:00:00.23
   Remote node addr: 1038       Priority:                            4
   Remote node name: NODE2      Privilege <31-00>:            0010C000
   Remote ID:     USER2         Privilege <63-32>:            00000000
   Queue entry:                 Final status code:            10D380FC
   Queue name:
   Job name:
   Final status text: %LOGIN-F-INVPWD, invalid password

   Page faults:             234    Direct IO:                 24
   Page fault reads:          5    Buffered IO:               40
   Peak working set:        287    Volumes mounted:            0
   Peak page file:         1474    Images executed:            1
   Username:      USER1         UIC:            [SYSTEM]
   Account:       <login>       Finish time:    3-AUG-1993 16:03:20.85
   Process ID:    2080D878      Start time:     3-AUG-1993 16:03:11.77
   Owner ID:                    Elapsed time:            0 00:00:09.08
   Terminal name: VTA3959       Processor time:          0 00:00:00.21
   Remote node addr:            Priority                             4
   Remote node name:            Privilege <31-00>:            FFFFFFFF
   Remote ID:                   Privilege <63-32>:            FFFFFFFF
   Queue entry:                 Final status code:            10D380FC
   Queue name:
   Job name:
   Final status text: %LOGIN-F-INVPWD, invalid password

   Page faults:             235    Direct IO:                 18
   Page fault reads:          5    Buffered IO:               41
   Peak working set:        284    Volumes mounted:            0
   Peak page file:         1474    Images executed:            1
   The audit records show the following:
   Security alarm (SECURITY) and security audit (SECURITY) on NODE1,
   system id: 1072 / Remote interactive login failure
   Event time:    3-AUG-1993 16:02:19.59
   PID:                00000D33
   Username:           USER1
   Terminal name:      _RTA1:
   Remote nodename:    NODE2           Remote node id:         1184
   Remote username:    USER2
   Status:             %LOGIN-F-INVPWD, invalid password

   Security alarm (SECURITY) and security audit (SECURITY) on NODE1,
   system id: 1072 / Remote interactive login failure
   Event time:    3-AUG-1993 16:03:11.77
   PID:                00000CB4
   Username:           USER1
   Terminal name:      _TNA7:
   Remote nodename:    127.0.          Remote node id:   2130706433
   Remote username:    TELNET_7F000001
   Status:             %LOGIN-F-INVPWD, invalid password
   Note that the remote nodename is always truncated to  six
   characters.   The   remote  node  id   is   a   numerical
   representation of the remote address.
   Notice  from  the  failed telnet  login  above  that  the
   remote   username  is  given  as  TELNET_7F000001.   This
   equates to the IP address thus:
        7 * 16 + F = 127
        0 * 16 + 0 =   0
        0 * 16 + 0 =   0
        0 * 16 + 1 =   1
   Hence   if  this  attempt  had  come  from  the   Network
   Information   Centre   (,   Internet   address,  the remote username would  have  appeared

   5.2 Daily Activities
   A  batch  file  must  be written in order  to  carry  out
   regular  activities  on  a  daily  basis.  Amongst  these
   activities  should be various checks on log files.  These
   are listed below.
     "Security alarm"/WINDOW=(3,8)
   Any  one  of  these can be used for obtaining information
   about  the  life of the system. The amount  and  type  of
   information  required should be used to determine  which.
   When  any  record from the output of these files  reveals
   an  incident that appears unusual, then further  checking
   is  required. The daily summary returned by  any  one  of
   the  commands above should only be used to indicate  that
   this  action  is required - you should not rely  on  just
   the summary information returned by these commands.
   Check  daily  that the security auditing  characteristics
   you require are in place, and have not been changed.
   Examine  the  error  log daily as  well.  This  will  not
   necessarily  alert  you to a security  incident,  but  it
   will  draw  your  attention to any system  problems  that
   could  potentially hinder your efforts  to  recover  from
   disaster.  (You  could also put the "SHOW ERROR"  command
   in your LOGIN.COM file.)
      /SUBJECT:"Logged interactive logins"
   Wrappers  were  discussed in Section  4.1,  Wrappers.  As
   part   of  your  daily  checking,  you  should  mail   to
   yourself,  and  other  relevant users,  the  output  from
   these  wrappers  on  a  daily basis.  The  example  above
   mentions only output from the interactive wrapper  log  -
   the implication is that all logs should be checked.

   5.3 Having a Live Console
   Don't   rely   simply   on   on-line   sinks   (such   as
   OPERATOR.LOG) for your security oriented output.  In  the
   event of a system compromise, it is quite likely that  an
   attacker will attempt to delete or modify information  in
   system files.
   A  good idea is to enable a security operator's terminal.
   In  addition  to (or even instead of) the  normal  system
   console  (usually  OPA0:), you should  consider  using  a
   security  operator's terminal one that provides  hardcopy
   output and is located in a secure location.
   (A  word  of  caution: even an unsuccessful attack  could
   seriously  disrupt  your system if the  hardcopy  printer
   runs out of paper.)
   Using  the example from the Guide to VMS System  Security
   manual,   consider  an  example  where  such  a  terminal
   (TTA3:)  has  been designated, and security messages  are
   to  be  disabled  on the console. This  can  be  achieved
   You  can, of course, enable other message classes to this
   terminal as well.
   Most  of  the undocumented material in this  paper  is  a
   mixture  of my own work and other material that has  been
   passed  on  to me by various colleagues at The University
   Of  Queensland.  The original idea for  the  wrapper  was
   inspired  by  Ron  Tencati, and  Wietse  Venema's  public
   domain tcp_wrapper for UNIX systems.
   VAX/VMS Documentation manuals:
       DEC TCP/IP Services for VMS System Management
       Guide to VAX/VMS System Security
       Access Control List Editor Utility
       Accounting Utility
       Audit Analysis Utility
       Authorize Utility
       Guide to Maintaining a VMS System
       Network Control Program Manual
       Networking Manual
   Ron Tencati, Ken Coar and E Eugene Schultz
       Managing Security in a Multi-Vendor Network, 1992
                                 Appendix 1
                SERT Advisory SA-93.03, Suggested Login Banner

SA-93:03A			SERT Advisory
			    Suggested Login Banner

On 7-May-1993, the Security Emergency Response Team released Advisory
SA-93:03.  Since then, it has been brought to our attention that the word
"permission" could be considered ambiguous as Unix file systems use
"permission" bits to specify if access is granted to a file or not.

Further advice from the Commonwealth Director of Public Prosecutions

"'Permit' does seem to include a meaning of 'allow or let happen even by
accident or carelessness'."

"'Authority' or 'authorisation' suggest that someone has deliberately
turned their mind to an action and formally approved that action."

"In light of the fact that there does appear to be a difference in meaning
between words 'permit or permission' and 'authority or authorisation' and
the fact that computer scientists refer to 'permission' bits on Unix files,
it does appear desirable that the words 'authority' or 'authorisation' be
used instead of the word 'permission'."

Therefore, the Security Emergency Response Team has reissued SA-93:03 as
SA-93:03A taking into account the new recommendations.  The new Advisory is
included below.

The SERT team wishes to thank Kate Lance at the University of Newcastle for
bringing this problem to our attention.

Body of SERT Advisory SA-93:03A

The Security Emergency Response Team has received information that a
successful prosecution of a computer cracker has taken place in New South
Wales.  The prosecution was aided by the use of an appropriate login
banner.  The following is an extract from a letter by the Australian
Federal Police:

"A major factor, commented upon by the magistrate, was the repeated warning
message displayed at logon to your system.  Your agreement to implement this
feature has certainly started to pay dividends and demonstrates a certain
willingness to accept [that] tertiary institutions are not fair game."

A recommended login banner is:

----- Warning Message -----

	***** This service is for authorised clients only *****

* WARNING:	It is a criminal offence to:				   *
*		i. Obtain access to data without authority		   *
*			(Penalty 2 years imprisonment)			   *
*		ii Damage, delete, alter or insert data without authority  *
*			(Penalty 10 years imprisonment)			   *

This example login banner was supplied to the Australian Federal Police by
the office of the Commonwealth Director of Public Prosecutions.  Legal
opinion from the Commonwealth Director of Public Prosecutions indicates
that this warning will assist in prosecutions of computer crackers for two

"The prosecution in a criminal case must show that the computer hacker's
actions are intentional.  It would be extremely difficult for a hacker to
argue that his actions were by accident or inadvertent when he has to go
past such a warning on the system."

"A hacker may admit that his actions were intentional.  However, upon his
sentence, he may argue that he was ignorant of the law or that he was
unaware that his actions were unauthorised, thereby inducing the court to
mitigate the penalty that it imposes.  If the above warning is used, it
will be extremely difficult for a hacker to present such arguments."

SERT recommends the use of this, or similar banners on ALL systems and
access points into the network (such as a modem pool and ftp access).  This
not only provides forewarning to any crackers that may intrude your system
that certain types of activity are illegal, but also advises any legitimate
users of their obligations relating to acceptable use of the computer

The warning is deliberately general in nature as it has not yet been
established what type of (if any) crime has been committed.  Subsequent
prosecution may be performed under Federal or State law, or handled by
local institution disciplinary procedures.

SERT recommends that any login banner or system initial message should not
imply consent to use the computer services (E.g., words such as "greeting"
or "welcome"), unless it is the express intention that any user is free to
use the system, whether they are authorised or not.

You may wish to include some identification information (such as the
hostname) so that genuine users know that they have connected to the
correct system.  For example,
"You have connected to node FRED at The University of Wooloomooloo"
and follow this with an appropriate warning message.

Examples methods for login messages are:

VMS:	Edit the file SYS$MANAGER:SYSTARTUP_V5.COM and include the line:
then create the file SYS$MANAGER:ANNOUNCE.TXT with the text that you wish
displayed when a user connects to your system.

Note that this has implications for LAT as the default service
identification is the logical SYS$ANNOUNCE (which will translate to
@SYS$MANAGER:ANNOUNCE.TXT).  In this case, you should edit the LAT startup
procedures to explicitly define a LAT service identification.

Unix:	Edit the "message of the day" file, (e.g., /etc/motd) and include
the text that you wish displayed when a user logs in to your system.

This does not cover all ways to connect to a computer (e.g., rlogin,
telnet, SET HOST, ftp), but serves as one point of warning in a number of
cases.  Warnings such as this are a positive step towards providing
adequate notice of the obligations and responsibilities relating to the use
of the computer equipment.  If a person is known to have seen the warning,
they cannot subsequently claim ignorance of their responsibilities.

The SERT team wishes to thank The University of Sydney, the University of
South Australia, the Australian Federal Police, and the Commonwealth
Director of Public Prosecutions for their advice and cooperation in this

If you believe that your system has been compromised, contact SERT or your
representative in FIRST (Forum of Incident Response and Security Teams).

Internet Email:
Facsimile:	(07) 365 4477
Telephone:	(07) 365 4417
		SERT personnel answer during business hours (AEST).

Security Emergency Response Team
Prentice Centre
The University Of Queensland
Qld.  4072.
                            Appendix 2

SERT Advisory SA-93.04, Guidelines For Developing A Sensible Password Policy
SA-93:04                        SERT Advisory
             Guidelines For Developing A Sensible Password Policy

This advisory contains guidelines for developing a sensible password policy. 
Please feel free to extract the contents of this advisory, modify to suit local 
conditions, and then distribute to end users, as it is end users who are 
responsible in the first instance for individual account security.

Without doubt, one of the most popular methods used by computer crackers to
compromise a system is password stealing.

By stealing your username and password an intruder can, with reduced
likelihood of detection, gain access to your system, modify it for his or
her own purposes and use that system as a launchpad for attacks on other
systems throughout the world - and all in your name. Password protection is
one of the most (if not the single most) important principles of system
security. It is uniformly important for ALL users, regardless of system
privileges or computer literacy. It is up to each and every individual to
ensure that their password is safe - a single unsafe password can (and
probably will) lead to a computer cracker violating YOUR system.

Your best line of defence against attack is a secure password. A password
is like a key, and any entry point that allows access by default is not
secure. A bad password is like leaving your front door unlocked.

Do not underestimate the ease with which your password can be stolen. There
are many techniques available to do this. A simple and amazingly successful
password theft technique for the cracker is password guessing (i.e. entering
your username, and simply guessing what your password might be). The aim of
this advisory is to thwart these attempts.

How To Select A Safe Password

Some systems automatically (and autocratically) allocate passwords to
users. Many systems, however, give the user the option of selecting his 
or her own password. The following guidelines should help in selecting a
password which will be sufficiently robust to prevent a cracker from
guessing your password in the majority of cases. 

There are several principles involved in selecting a safe password. These
are covered below.


DO NOT use simple passwords that are easy to remember and are typically 
	not safe. Examples of such passwords are:

	-  your userid (a common, but extremely dangerous practice);

	-  a word which can be associated with you. For example:
		- your car make, model or registration number
		- your child's name
		- your street name, postcode or other address details
		- your medicare number
		- your tax file number
		- any of your bank account numbers;

	-  a word which someone watching could easily spot (qwertyuiop);

	-  any dictionary word (which a cracker with a PC and an on-line 
		dictionary could discover by exhaustive trial);

	-  words from other guessable word sets such as famous names, 
		proper names, colloquial terms (in various spheres of
		life) and so on.

	It is not sufficient to include a single number in the word, or 
	change all O's to 0's and I's or L's to 1's in the word, or to spell 
	the word backwards.

DO NOT leave your account without a password.

DO NOT use your userid as your password.

DO NOT use any word from a dictionary (of any language) as most forms of 
	password attack use dictionaries as a basis for password guessing.

DO NOT use birthdays, car registration numbers, room numbers, department names,
	machine names, locations, wife/husband's names, pet's names,
	children's names and so on. These may be determined as most of this
	information is not confidential.

DO NOT use keyboard patterns, or duplicating characters such as qwerty or

DO NOT use the same password on multiple accounts. If you have many accounts,
	then do not use the same password on each account. If one is broken,
	then all are broken. Also, do not just change one character in the
	password as this may be easily spotted if one of the passwords is

DO NOT allow anyone to watch while you type your password.

DO NOT record your password either on-line. DO NOT write down your 

DO NOT tell anyone what your password is. Do not share your password with
	your partner, your children, your friends. Even telling your dog
	should be considered risky! Do not tell a person verbally, by
	electronic mail or by any other means.

Remember: if someone has your password, they can commit criminal acts using
your account!

SERT staff have been alerted to several security breaches at constituent
sites which have been attributed (in total or in part) to the sharing of 
passwords between husband and wife, parent and child, and between friends.

The DOs

DO use a MINIMUM (not maximum!) of 8 or more characters (system permitting).

DO use mixed case wherever possible. DO NOT choose only the first letter as
	uppercase. (e.g. Mich37bo is not as good as MicH37Bo.)

DO include at least two digits or punctuation characters. DO NOT simply replace
	"o" and "O" with "0", and "I", "l" or "L" with 1. (e.g. fl0pp1mp is
	not as good as fL0$p*Mp.)

DO change passwords frequently, and DO NOT reuse old passwords. Password
	cracking algorithms have been around for quite a while now. By using
	computationally intensive processes, a password can be broken in time.

Applying the techniques outlined above make the length of time required to
break a password prohibitively long. However, the time required to break a
password drops significantly as each letter is guessed, or other
information is known about a password. Passwords should be changed
regularly, so that even if a password is finally guessed, it will be long
out of date. A password should never be reused.

General techniques for generating safe passwords include:

-  using two or three short words that are unrelated;
-  always including some non-alphabetic, non-numeric (i.e. punctuation)
-  deliberately misspelling;
-  taking the first letter from each word of a phrase (a passphrase).

Note that different operating systems have different rules for the
characters that one is allowed to use in a password. Some operating systems
will allow any printable characters, whereas others only allow numeric and
alphabetic (i.e. non-punctuation) characters.

After reading all of that, you may ask "well, what is a good password? What
can I use?". One technique would be to use a two or three word phrase, and
replace the 1st character of the 1st word with a <shift>-1, the 2nd
character of the 2nd word with a <shift>-2, etc, and uppercase every second
character except punctuation. e.g. !Yc@rSm$lLs (my car smells).

Another alternative might be to use the first letter from each word in a
line from a song, have every third letter in upper case, and replace (aeiou) 
with ({}:"?). For example, 'Tie A Yellow Ribbon Round That Old Oak Tree' 
would convert into 't{YrrT""T'.

   'Tie A Yellow Ribbon Round That Old Oak Tree'            => 'tayrrtoot'
   Convert every third letter to upper case                 => 'taYrrTooT'
   Replace lower case vowels                                => 't{YrrT""T')

Note that these examples should NOT be used as they are now published

You should be aware of what characters your system will accept in a
password, the length required for a password, and what time period is
allowed before the password will have to be changed again. You also need to
be aware of the commands used to change passwords.

What System Managers Can Do

Consider using the following techniques.

- Use Crack, a password cracking tool to audit existing passwords. You supply
	a dictionary, and a list of massaging rules. Crack then tests the
	encrypted password against the dictionary and rules list to see which
	passwords it can guess. This is only available for UNIX systems.

- Consider also the use of password shadowing, which places the encrypted
	passwords in a non-world-readable file, not /etc/passwd (which is
	world-readable). Again, this is only applicable for UNIX systems.

- If your system has a facility to enforce rules on minimum password
	content (e.g. "must include at least 1 upper case and at least 1
	numeric"), then use this facility. For UNIX systems which don't
	have this facility, npasswd or passwd+ are good alternatives.

- If your system has a facility to (a) enforce password ageing, and (b) keep
	a history file of passwords and disallow previous passwords, then
	use this facility also.

- Keep passwords for system accounts distributed amongst the smallest group
	of people possible. Change these passwords more frequently than
	passwords for non-privileged accounts.

- Take care with the use of facilities that are available for logins which
	bypass the use of passwords. For instance, on VMS systems, don't
	allow proxy logins for privileged accounts such as "SYSTEM". On UNIX
	machines, remove any .rhosts files (or /etc/hosts.equiv) with "+"
	signs in them.

Login programs (such as /bin/login on UNIX systems) are constructed to 
behave in a certain way. One method used by crackers to obtain passwords is 
to execute a program (a trojan horse) masquerading as the login program. 
The trojan horse will accept your username and password, log it into a 
secret file, and then inform you that the combination entered was 
incorrect, before finally calling the real login program. The user, 
thinking that this was merely a typographical error, will proceed as normal
unaware that his or her password has been logged for later use. This can be 
avoided in some cases by typing <Return> a few times before entering your 
username/password combination.

Finally, system managers should be aware that X display managers (such as 
xdm) may bypass several login and system facilities such as message of 
the day, password ageing etcetera. Depending upon the sensitivity of your 
site, this may present some problems which will need resolution using more 
lateral methods.

If you believe that your system has been compromised, contact SERT or your
representative in FIRST (Forum of Incident Response and Security Teams).

Internet Email:
Facsimile:	(07) 365 4477
Telephone:	(07) 365 4417
		SERT personnel answer during business hours (AEST).

Security Emergency Response Team
Prentice Centre
The University Of Queensland
Qld  4072

                            Appendix 3
                          Wrapper Example
   The  following material is an example of a  wrapper  that
   could conceivably used for protecting the FAL object,  as
   outlined in Section 4.1, Wrappers.
   $ SaveVerify = F$VERIFY(0)
   $! Example Wrapper
   $!             *** NOTE: This file is UNTESTED! ***
   $! Author: Rob McMillan, 1992
   $! Example wrapper for the FAL object. This command file should
   $! specified as the file to execute for the FAL object in the NCP
   $! database. This file is for example purposes only!
   $! Create allow and deny lists in AllowFile and DenyFile. The
   $! format of each file is "HOST::USERNAME.". Note the full stop.
   $! eg
   $!                        NODE1::USER1.
   $! To have blanket values, use an asterisk *. For instance, to
   $! have a blanket denial, but allow all people from NODE2::, and
   $! allow NODE1::USER1, have the following configuration:
   $!                        DenyFile:
   $!                          *::*.
   $!                        AllowFile:
   $!                          NODE2::*.
   $!                          NODE1::USER1.
   $! In the absence of enough information in the configuration
   $! files, or a clash of information (eg denying and allowing
   $! *::*), the default action is to deny a connection.
   $!  -- What object is this wrapper for?
   $ Executable = "SYS$SYSTEM:FAL.EXE"         ! Object executable to use
   $!  -- Constants
   $ WAllowed == %x10000001
   $ WDenied  == %x10000002
   $ WUnknown == %x10000003
   $!  -- Get connection details
   $ LocalNodeName  = F$GETSYI("NODENAME") + "::"
   $ LocalTime      = F$TIME()
   $ LocalUser      = F$GETJPI("","USERNAME")
   $ LocalUser      = F$EXTRACT(0,F$LOCATE(" ",LocalUser),LocalUser)
   $ RemoteNodeName = F$TRNLNM("SYS$REM_NODE")
   $ RemoteUser     = F$TRNLNM("SYS$REM_ID")
   $ WrapperLogInfo = -
     "at ''LocalTime' from ''RemoteNodeName'::''RemoteUser' as ''LocalUser'"
   $!  -- Check wrapper configuration
   $! At this point, we can use any of the following to check
   $! whether we'll allow the connection:
   $!        - LocalNode
   $!        - LocalTime
   $!        - LocalUser
   $!        - RemoteNodeName
   $!        - RemoteUser
   $ ConnectionOkay = WUnknown
   $ CheckFALRules 'LocalNodeName' 'LocalTime' 'LocalUser' -
                   'RemoteNodeName'            'RemoteUser'
   $ ConnectionOkay = $Status
   $ IF (RemoteNodeName .EQS. LocalNodeName)
   $ THEN
   $    ConnectionOkay = WAllowed   ! Failsafe
   $ ENDIF
   $!  -- Log the event and take action
   $ IF (ConnectionOkay .NE. WAllowed)
   $ THEN
   $   WRITE SYS$OUTPUT "Network connect request failed ''WrapperLogInfo'"
   $   WriteFALLog "Network connect request failed ''WrapperLogInfo'"
   $   LOGOUT
   $ ELSE
   $   WRITE SYS$OUTPUT "Network connect request succeeded ''WrapperLogInfo'"
   $   WriteFALLog "Network connect request succeeded ''WrapperLogInfo'"
   $   RUN 'Executable'
   $ ENDIF
   $!  -- Go home now
   $ SaveVerify = F$VERIFY(SaveVerify)
   $ EXIT 'ConnectionOkay'

   For   interactive  connections,  the  section  in   which
   connection   details   are  evaluated   would   be   more
   complicated.  Different mechanisms would be required  for
   finding  out  these  details  based  upon  the  type   of
   connection  (eg  local, DECnet, LAT, telnet).  These  are
   mentioned  in Section 4.1, Wrappers. These command  files
   should  be  world  executable,  but  only  readable   and
   writeable by system privileged users.
   The   two  executables,  CheckFALRules  and  WriteFALLog,
   should  be  similarly protected (eg installed,  protected
   images).  WriteFALLog  is  a very  simple  program  which
   writes  the supplied parameters to the log file for  this
   object.  CheckFALRules  could  look  something  like  the
   following example.
    * CheckFALRules.C
    * Author: Rob McMillan, 1992
    *  Use current connection details to compare with local rules and
    *  return a value describing whether to allow the connection or
    *  not (Allow).
    *  The returned value (Allow) can return one of two values:
    *        WAllowed: allow the connection
    *        WDenied:  refuse the connection
    *  This wrapper configuration tests only upon the basis of
    *  RemoteNodeName and RemoteUser. However, any of the details
    *  supplied below can be used, based upon paranoia levels. To
    *  do this, the following must be modified:
    *           - The CHECK_EXPLICIT_RULE subroutine
    *           - The calls in this subroutine to CHECK_EXPLICIT_RULE
    *           - The header comments at the top of this wrapper
    *            - The allow and deny files.
   #include <ssdef.h>
   #include <stdio.h>
   #include <stdlib.h>
   #include <string.h>
   #include "CheckFALRules.H"
   typedef unsigned int     BOOLEAN;
   #define FALSE       0
   #define TRUE        1
   /* -- Prototypes */
   int                CheckExplicitRule( char *, char *);
   int                ExitHandler(int, char *);
   char *              Salloc(unsigned int);
   char *              SnarfArgument(char *);
   main (argc, argv)
   int                argc;
   char *  argv[];
    char *       localNodeName;
    char *       localTime;
    char *       localUser;
    char *       remoteNodeName;
    char *       remoteUser;
    int     status = WUnknown;
    /* Get and display parameters */
    localNodeName= SnarfArgument(argv[1]);
    localTime         = SnarfArgument(argv[2]);
    localUser         = SnarfArgument(argv[3]);
    remoteNodeName    = SnarfArgument(argv[4]);
    remoteUser        = SnarfArgument(argv[5]);
     if ((localNodeName == (char *)0)      ||
         (localTime == (char *)0)          ||
         (localUser == (char *)0)          ||
         (remoteNodeName == (char *)0)     ||
         (remoteUser == (char *)0)
        ) {
          fprintf( stderr, "Error snarfing check parameters!\n");
          exit( ExitHandler( WDefault, "Error snarfing check
    /* Now evaluate whether to allow the connection */
           /* -- We will only test based on source node and user.
            *    We can check other details if required at a later stage.
            *     Note that the order in which these rules are checked is
            *     important. Below, we check in the order of the most
            *     specific rule to the most general. Once a connection
            *     is found to be explicitly allowed or denied
            *     no further rules are checked.
     status = CheckExplicitRule( remoteNodeName, remoteUser);
     if (status != WUnknown)
       exit( ExitHandler( status, "On node::user combination"));
     status = CheckExplicitRule( remoteNodeName, "*");
     if (status != WUnknown)
       exit( ExitHandler( status, "On node::* combination"));
     status = CheckExplicitRule( "*", "*");
     if (status != WUnknown)
       exit( ExitHandler( status, "On *::* combination"));
          /* No applicable rules were found, or there were a clash of
           * rules, so use the default.
     fprintf(stderr, "Warning! Unable to evaluate connection status!\n");
     exit ( ExitHandler( WDefault, "Default action taken"));
   }     /* end main */
    * CheckExplicitRule
    *  Use the remoteNodeName and remoteUser to return a value
    *  describing whether the proposed connection is explicitly allowed
    *  or denied. The returned value can be one of three values:
    *      WAllowed: explicitly allow the connection
    *      WDenied:  explicitly deny the connection
    *      WUnknown: couldn't evaluate on supplied information
    *       Allowed configurations are set out in ALLOW_FILE.
    *       Disallowed configurations are set out in DENY_FILE.
    *  If the record is found in both files, or the record can't be
    *  found in either file, return WUnknown. Otherwise, return
    *  the result explicitly described by the files.
   CheckExplicitRule( remoteNodeName, remoteUser)
   char *  remoteNodeName;
   char *  remoteUser;
        char          inbuf[132];     /* Should be heaps */
        char *        searchKey;
        BOOLEAN       allow = WUnknown;
        BOOLEAN       foundAllow = FALSE;
        BOOLEAN       foundDeny = FALSE;
        FILE *        fp;
     if ((searchKey = Salloc(strlen(remoteNodeName) + 3 +
                        strlen(remoteUser))) == (char *)0)
          return( WUnknown);
        searchKey = strcpy(searchKey, remoteNodeName);
        searchKey = strcat(searchKey, "::");
        searchKey = strcat(searchKey, remoteUser);
   /* See if there is a matching record in the allow file */
   if ((fp = fopen( ALLOW_FILE, "r")) == (FILE *)NULL) {
     fprintf(stderr, "Error! Cannot open wrapper AllowFile! \n");
     return( WUnknown);
   else {
     /* Search file for matching record */
     while ((foundAllow == FALSE) && (fgets(inbuf, 132, fp) != (char *)NULL))
       if (strncmp(searchKey, inbuf, strlen(searchKey)) == 0)
         foundAllow = TRUE;
   /* Now search deny file as well */
   if ((fp = fopen( DENY_FILE, "r")) == (FILE *)NULL) {
     fprintf(stderr, "Error! Cannot open wrapper DenyFile! \n");
     return( WUnknown);
   else {
     /* Search file for matching record */
     while ((foundDeny == FALSE) && (fgets(inbuf, 132, fp) != (char *)NULL))
       if (strncmp(searchKey, inbuf, strlen(searchKey)) == 0)
         foundDeny = TRUE;
   /* If we get a strict decision, then return the result. If we
    * get two FALSEs or two TRUEs, then there is no decision.
   if ((foundAllow == TRUE) && (foundDeny == FALSE))
     allow = WAllowed;
   if ((foundAllow == FALSE) && (foundDeny == TRUE))
     allow = WDenied;
     return( allow);
   }  /* end CheckExplicitRule */
    * ExitHandler
    * Carry out any cleaning up required whilst exiting.
   ExitHandler( exitCode, diagnostic)
   int             exitCode;
   char *          diagnostic;
   #ifdef DEBUG
     switch (exitCode) {
       case WAllowed:
       fprintf( stdout, "\nConnection allowed: ");
       fprintf( stdout, "%s.\n", diagnostic);
     case WDenied:
       fprintf( stdout, "\nConnection denied: ");
       fprintf( stdout, "%s.\n", diagnostic);
     case WUnknown:
       fprintf( stdout, "\nCan't figure out to allow connection or not: ");
       fprintf( stdout, "%s.\n", diagnostic);
       fprintf( stdout, "\nError. Unknown exit code: ");
       fprintf( stdout, "%s.\n", diagnostic);
    return( exitCode);
   } /* end ExitHandler */
    * Salloc
    * Safe malloc
    * See P321 "C Programming in a UNIX Environment"
    *            by Judy Kay and Bob Kummerfeld,
    *            Addison-Wesley, 1989.
   char *
   unsigned int    size;
       char * result;
       if ((result = malloc(size)) == (char *)0)
         fprintf(stderr, "Cannot malloc %d bytes.\n", size);
       return result;
   } /* end Salloc */
    * SnarfArgument
    * Make a copy of arg string.
   char *
   SnarfArgument( arg)
   char *  arg;
     char * result;
     if ((result = Salloc(strlen(arg)+1)) != (char *)0)
       result = strcpy(result, arg);
     return( result);
   } /* end SnarfArgument */
   The header file for this program would contain the following:
    * CheckFALRules.H
    * Author: Rob McMillan, 1992
    *  See comments in CheckFALRules.C.
   /* -- Define file paths */
   #define DEBUG
   #ifdef  DEBUG
   #define ALLOW_FILE  "{Allow File name here}"
   #define DENY_FILE   "{Deny File name here}"
   #define ALLOW_FILE  "local$wrap:{Allow File name here}"
   #define DENY_FILE   "local$wrap:{Deny File name here}"
   /* -- Define exit values */
   #define WAllowed    0x10000001
   #define WDenied     0x10000002
   #define WUnknown    0x10000003
   #define WDefault    WDenied

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2015 AOH