# 5. Security Services

ECS security architecture must meet the requirements for data integrity,
availability, and confidentiality. ECS Security Services meets these
requirements by incorporating a variety of mechanisms to establish and
verify user accounts, issue and verify passwords, audit user activity,
and verify and protect data transfer. Security logs will be monitored
and security reports generated by TO BE DETERMINED. Several FREEWARE
products provide tools for authentication and network and system
monitoring: Kerberos, SATAN, Crack, Secure Shell, TCP Wrapper, and
Tripwire. The Open Software Foundation\'s Distributed Computing
Environment (OSF/DCE) employs Kerberos for authenticating user requests
for network services. (DCE administration tools a are discussed in
Section 3 of this document.) The FREEWARE product, SATAN, monitors
networks and finds system security vulnerabilities. Three FREEWARE
products --- Crack, and Secure Shell --- provide additional password
protection for local system and network access. To monitor and control
access to network services, ECS Security Services uses TCP Wrapper. The
Tripwire monitors changes to files and flags any unauthorized changes.
Security Services also supports detection of, reporting, and recovery
from security breaches. The products used for this tasking are TO BE
DETERMINED.

This section defines step-by-step procedures for M&O personnel to run
the Security Services tools. The procedures assume that the requester\'s
application for a Security process has already been approved by DAAC
Management. It is recommended that access to these tools be controlled
through the root access only.

The Activity Checklist table that follows provides an overview of the
Security process. Column one (Order) shows the order in which tasks are
presented in this section. Column two (Role) lists the
Role/Manager/Operator responsible for performing the task. Column three
(**Task**) provides a brief explanation of the task. Column four
(**Section)** provides the Procedure (P) section number or Instruction
(I) section number where details for performing the task can be found.
Column five (**Complete?**) is used as a checklist to keep track of
which task steps have been completed.

Table 5-1. Security - Activity Checklist

  ------- --------- -------------------------------- ----------- ----------
  Order   Role      Task                             Section     Complete ?

  1       Super     Run Security Log Analyst Program \(P\) 5.0   
          User                                                   

  2       Super     Generate Security Reports        \(P\) 5.1   
          User                                                   

  3       Super     Run Network Authentication       \(P\) 5.2   
          User      Service                                      

  4       Super     Monitor Network Vulnerabilities  \(P\) 5.3   
          User                                                   

  5       Super     Ensure Password Integrity        \(P\) 5.4   
          User                                                   

  6       Super     Monitor Requests for Network     \(P\) 5.5   
          User      Services                                     

  7       Super     Monitor File and Directory       \(P\) 5.6   
          User      Integrity                                    

  8       Super     Report Security Breaches         \(P\) 5.7   
          User                                                   

  9       Super     Initiate Recovery from Security  \(P\) 5.8   
          User      Breaches                                     
  ------- --------- -------------------------------- ----------- ----------

## 5.1 Generating Security Reports

All FREEWARE security products generate reports and log files. These are
available when you run the product. Your System Administrator will be
able to assist you.

## 5.2 Running the Network Authentication Service

Because intruders can monitor network traffic to intercept passwords,
traditional authentication methods are not suitable for use in computer
networks. The use of strong authentication methods that prevent password
disclosure is essential. The Kerberos Network Authentication Service is
well suited for such an environment.

Developed at the Massachusetts Institute of Technology, Kerberos is a
distributed authentication service that allows a client (process that
makes use of a network service) running on behalf of a principal (user
or server) to identify itself to other principals, without sending data
across the network that might allow an intruder to subsequently
impersonate the user. Not knowing the identity of a user who requests an
operation makes it difficult to decide whether the operation should be
permitted.

The principal\'s level of permissions (such as read, create, modify,
destroy) is based on DCE permissions and passwords established for the
user. Kerberos reinforces DCE password security through its use of DES
encryption (secret key) to protect sensitive information on an open
network. In the case of a human user as the principal, the secret key is
based on the user\'s password. However, the principal\'s password is
**never** passed through the network.

Kerberos authentication activities are transparent to the user.
Communication is between servers (principals) and processes (clients).
The principal\'s request must receive a \"ticket\" that will be passed
to each network service that the principal wants to access. The ticket
is a record that helps a client authenticate itself to a server; it
contains the client\'s identity, a session key, a timestamp, and other
information, all sealed using the server\'s secret key. The session key
is a temporary encryption key used between two principals, with a
lifetime limited to the duration of a single login \"session\" (usually
8 hours).

Several utility programs must be installed on the user\'s workstation to
allow users to obtain Kerberos credentials (kinit), list credentials
(klist), and destroy credentials (kdestroy).

These procedures assume that the site is running MIT Kerberos 5, that
the System Administrator has logged in as a super user, and that the
Kerberos Authentication Server is available.

**1** To login to the Kerberos Service, type **/bin/kinit** then press
\[RETURN\]**.**

**Enter** name and password.

• Acquires a ticket that is valid for the time of the session from the
Kerberos authentication server. Once logged in, you will have access to
the system as permitted by the tickets obtained from the Ticket Granting
Service.

The following options can be used with the **kinit** command:

**-f** This option allows a ticket-granting ticket with a different
network address than the present ticket-granting ticket\'s to be issued
to the principal. For \"forwarding\" tickets to be granted, the
principal\'s account in the registry must specify that the principal can
be granted forwarding (or FORWARDABLE) tickets.

**-v** Specifies that the command should run in verbose mode.

**2** At command line, type **klist** then press \[RETURN\].

• Acquires a list of tickets obtained for this session, for example:

Kerberos Ticket Information:

Ticket cache: /opt/dcelocal/var/security/creds/dcecred_031d6500

Default principal: reginald@edfcell.hitc.com

Server: krbtgt/edfcell.hitc.com@edfcell.hitc.com

valid 96/09/09:10:36:16 to 96/09/09:20:36:16

Server: dce-rgy@edfcell.hitc.com

valid 96/09/09:10:36:21 to 96/09/09:20:36:16

Server: dce-ptgt@edfcell.hitc.com

valid 96/09/09:10:36:25 to 96/09/09:12:36:25

Client: dce-ptgt@edfcell.hitc.com Server:
krbtgt/edfcell.hitc.com@edfcell.

hitc.com

valid 96/09/09:10:36:25 to 96/09/09:12:36:25

Client: dce-ptgt@edfcell.hitc.com Server: dce-rgy@edfcell.hitc.com

valid 96/09/09:10:36:25 to 96/09/09:12:36:25

The following options can be used with the **klist** command:

**-e** Includes expired tickets in the display. Without this option,
only current tickets are displayed.

**-f** Displays option settings on the tickets. The options are:

**D** (postdatable)

**dF** (postdated) (forwardable)

**f** (forwarded)

**I** (initial)

**i** (invalid)

**P** (proxiable)

**p** (proxy)

**R** (renewable)

**3** To logout of Kerberos Service, type **/bin/kdestroy** then press
\[RETURN\].

• Destroys the ticket when the user logs out.

To share and mount files with Kerberos authentication:

**4** Type **share -F nfs -o kerberos /filesystem** then press
\[RETURN\].

• Shares a file system with Kerberos authentication.

**5** Type **mount -F nfs -o kerberos server:resource mountpoint** then
press \[RETURN\].

• Mounts a file system with Kerberos authentication.

**6** To check the Kerberos Authentication Server, type
**/Kerberos/Kerberos.log**.

## 5.3 Monitoring Network Vulnerabilities

The Security Administrator Tool for Analyzing Networks (SATAN) is a
testing and reporting tool that collects a variety of information about
networked hosts. SATAN gathers information about specified hosts and
networks by examining network services (for example, finger, NFS, NIS,
ftp). SATAN also gathers general network information (network topology,
network services run, types of hardware and software being used on the
network). The data is used to point out system vulnerabilities. Data can
be reported in a summary format. Problems are described briefly and
pointers provided to patches or workarounds.

Periodically, the operator will run SATAN as **root**. The procedures
are provided below.

**1** Make sure that **DISPLAY** is set on your workstation. **Note:**
SATAN is run only on the SMC side (mss5hp).

**2** From **/usr/ecs/OPS/COTS/secmgmt/satan-1.1.1** type **./satan**.

**3** From the **SATAN Control Panel**, select **SATAN Configuration
Management**. Set all variables or use the default values.

**4** **Go back** to the **SATAN Control Panel**.

**5** From the **SATAN Control Panel**, select **SATAN Data
Management**. Create the SATAN database if it does not exist. When you
create the database for the first time, you will see a warning message
concerning password disclosures. Take no action and continue. The
database is stored as **satan-data** in the directory

**/satan-1.1.1/results**.

**6** You will be notified when the SATAN finishes creating the database
and scans the system (network or cluster ) for vulnerabilities.

**7** From this screen, you can click on \"Continue with Reporting and
Analysis\" or you can return to the **SATAN Control Panel**, to make
this selection. Select the reports that you want to review.

## 5.4 Ensuring Password Integrity

One aspect of system security is discretionary access control based on
user passwords. Passwords should be so unique that they are virtually
impenetrable to unauthorized users. A **FREEWARE** products provide
utilities to create effective password practices. \"Crack\" detects weak
passwords that could be easily bypassed.

Crack provide comprehensive dictionary, which can shared. These
\"source\" dictionaries provide lists of words, which if used, would
create vulnerable passwords. You can add other dictionaries, for
example, acronym lists, to eliminate commonly used terms from being used
as passwords.

Crack is installed in a secure location, that is, **root access only**.
Such precautions are particularly apt when running Crack, which gives
the administrator access to everyone\'s password that he/she penetrates.

### 5.4.1 Detecting Weak Passwords

Running Crack against a system's password file will enable a system
administrator to assess how vulnerable the file is to unauthorized users
and how well authorized users select secure passwords. Crack is designed
to find standard Unix eight-character DES-encrypted passwords by
standard guessing techniques.

Crack takes as its input a series of password files and source
dictionaries. It merges the dictionaries, turns the password files into
a sorted list, and generates lists of possible passwords from the merged
dictionary or from information gleaned about users from the password
file. It does not attempt to remedy the problem of allowing users to
have guessable passwords, and it should NOT be used in place of getting
a really good, secure password program replacement.

The instructions provided in the following sections are general in
nature because how you configure Crack and how you run it depends on the
platforms on which it resides and on the local security requirements
established for your site. M&O personnel should be familiar with these
tasks to:

1\. Configure the Crack shellscript and config.h files based on the
README file and on requirements established for your site. See Section
"Configuring Crack" below.

2\. Run Crack based on requirements established for your site. See
"Running Crack", below.

3\. Customize the dictionaries. See Section "Creating Dictionaries",
below.

#### 5.4.1.1 Configuring Crack

Although Crack should already be configured for your system, the
instructions are provided should you have to reconstruct the makefile as
a result of file corruption. Crack has two configuration files: the
Crack shellscript, which contains all the installation-specific
configuration data, and the file Sources/conf.h, which contains
configuration options specific to various binary platforms.

**1** In the Crack shellscript, edit the CRACK_HOME variable to the
correct value. This variable should be set to an absolute path name
through which the directory containing Crack may be accessed on ALL
machines on which Crack will be run. (Path names relative to username
are acceptable as long as you have some sort of csh.)

There is a similar variable, CRACK_OUT, which specifies where Crack
should put its output files --- by default, this is the same as
\$CRACK_HOME.

**2** Edit the file Sources/conf.h and establish which switches to
enable. Each #define has a small note explaining its purpose.
Portability of certain library functions, should not be a problem.

**3** If using Crack -network (see Section Options, below), generate a
Scripts/ **network.conf** file. This file contains a list of hostnames
to rsh to, what their binary type is (useful when running a network
Crack on several different architectures), an estimate of their relative
power (take your slowest machine as unary, and measure all others
relative to it), and a list of per-host flags to add to those specified
on the Crack command line, when calling that host. There is an example
of such a file provided in the Scripts directory.

**4** To specify a more precise figure as to the relative power of your
machines, play with the **command make** tests in the source code
directory. This can provide you with the number of fcrypt()s that your
machine can do per second, which is a number that you can plug into your
**network.conf** as a measure of your machines\' power (after rounding
the value to an integer).

#### 5.4.1.2 Running Crack

Crack is a self-installing program. Once the necessary configuration
options for the Crack shellscript and config.h have been set, the
executables are created via **make** by running the Crack shellscript.

**Notes for Yellow Pages (NIS) Users:**

> To get Crack running from a YP password file, the simplest way is to
> generate a passwd format file by running:-
>
> ypcat passwd \> passwd.yp

and then running Crack on this file.

To launch Crack:

**1** From **/usr/ecs/OPS/FREEWARE/secmgmt/crack**, at the command line
type: **./Crack**

**2** For the single platform version:

./Crack \[options\] \[bindir\] /etc/passwd \[\...other passwd files\]

**3** For the network version:

./Crack -network \[options\] /etc/passwd \[\...other passwd files\]

For a brief overview of the \[options\] available, see Section
"Options", below. Section "Crack Support Scripts" briefly describes
several very useful scripts.

#### 5.4.1.3 Creating Dictionaries

Crack works by making many individual passes over the password entries
that you supply to it. Each pass generates password guesses based upon a
sequence of rules, supplied to the program by the user. The rules are
specified in a simplistic language in the files gecos.rules and
dicts.rules, located in the Scripts directory (see Section "Crack
Support Scripts", below).

Rules in Scripts/gecos.rules are applied to data generated by Crack from
the pw_gecos and pw_gecos entries of the user\'s password entry. The
entire set of rules in gecos.rules is applied to each of these words,
which creates many more permutations and combinations, all of which are
tested. After a pass has been made over the data based on gecos
information, Crack makes further passes over the password data using
successive rules from the Scripts/dicts.rules by loading the whole of
Dicts/bigdict file into memory, with the rule being applied to each word
from that file. This generates a resident dictionary, which is sorted
and uniqued so as to prevent wasting time on repetition. After each pass
is completed, the memory used by the resident dictionary is freed up,
and re-used when the next dictionary is loaded.

Crack creates the Dicts/bigdict dictionary by merging, sorting, and
uniq\'ing the source dictionaries, which are to be found in the
directory DictSrc and which may also be named in the Crack shellscript,
via the \$STDDICT variable. (The default value of \$STDDICT is
/usr/dict/words.)

The file DictSrc/bad_pws.dat is a dictionary which is meant to provide
many of those common but non-dictionary passwords, such as 12345678 or
qwerty.

To create your own dictionary:

**1** Copy your dictionary into the DictSrc directory (use compress on
it if you wish to save space; Crack will unpack it while generating the
big dictionary).

**2** Delete the contents of the Dicts directory by running
Scripts/spotless. Your new dictionary will be merged in on the next run.

#### 5.4.1.4 Options

**-f** Runs Crack in foreground mode, i.e., the password cracker is not
backgrounded, and messages appear on stdout and stderr as you would
expect. This option is only really useful for very small password files,
or when you want to put a wrapper script around Crack.

> Foreground mode is disabled if you try running Crack-network -f on the
> command line, because of the insensibility of rshing to several
> machines in turn, waiting for each one to finish before calling the
> next. For more information, read the section about Network Cracking
> without NFS/RFS in the README.NETWORK file.

**-v** Sets verbose mode, whereby Crack will print every guess it is
trying on a per-user basis. This is a very quick way of flooding your
filestore, but useful if you think something is going wrong.

**-m** Sends mail to any user whose password you crack by invoking
Scripts/nastygram with their username as an argument. The reason for
using the script is so that a degree of flexibility in the format of the
mail message is supplied; i.e., you don\'t have to recompile code in
order to change the message.

**-nvalue** Sets the process to be nice()ed to value, so, for example,
the switch -n19 sets the Crack process to run at the lowest priority.

**-network** Throws Crack into network mode, in which it reads the
Scripts/network.conf file, splits its input into chunks which are sized
according to the power of the target machine, and calls rsh to run Crack
on that machine. Options for Crack running on the target machine may be
supplied on the command line (for example, verbose or recover mode), or
in the network.conf file if they pertain to specific hosts (e.g., nice()
values).

**-r\<pointfile\>**

> This is only for use when running in recover mode. When a running
> Crack starts pass 2, it periodically saves its state in a pointfile,
> with a name of the form Runtime/P.\* This file can be used to recover
> where you were should a host crash. Simply invoke Crack in exactly the
> same manner as the last time, with the addition of the **-r** switch
> (for example, **-rRuntime/Pfred12345**). Crack will startup and read
> the file, and jump to roughly where it left off. If you are cracking a
> very large password file, this can save a lot of time after a crash.

#### 5.4.1.5 Crack Support Scripts

The Scripts directory contains a small number of support and utility
scripts, some of which are designed to help Crack users check their
progress. The most useful scripts are briefly described below.

**Scripts/shadmrg**

> This is a small script for merging /etc/passwd and /etc/shadow on
> System V style shadow password systems. It produces the merged data to
> stdout, and will need redirecting into a file before Crack can work on
> it.

**Scripts/plaster**

> This is a simple frontend to the Runtime/D\* diefiles that each copy
> of the password cracker generates. Invoking Scripts/plaster will kill
> off all copies of the password cracker you are running, over the
> network or otherwise. Diefiles contain debugging information about the
> job, and are generated so that all the jobs on the entire network can
> be called quickly by invoking Scripts/plaster. Diefiles delete
> themselves after they have been run.

**Scripts/status**

> This script rshes to each machine mentioned in the
> Scripts/network.conf file, and provides some information about
> processes and uptime on that machine. This is useful when you want to
> find out just how well your password crackers are getting on during a
> Crack -network.

**Scripts/{clean,spotless}**

These are really just frontends to a makefile. Invoking Scripts/clean
tidies up the Crack home directory, and removes probably unwanted files,
but leaves the pre-processed dictionary bigdict intact. Scripts/spotless
does the same as Scripts/clean but obliterates bigdict and old output
files, too, and compresses the feedback files into one.

**Scripts/nastygram**

This is the shellscript that is invoked by the password cracker to send
mail to users who have guessable passwords, if the **-m** option is
used. Edit it to suit your system.

**Scripts/guess2fbk**

This script takes your out\* files as arguments and reformats the
\'Guessed\' lines into a slightly messy feedback file, suitable for
storing with the others.

An occasion where this might be useful is when your cracker has guessed
many peoples\' passwords, and then died for some reason (a crash?)
before writing out the guesses to a feedback file. Running
Scripts/guess2fbk out\* \>\> Runtime/F.new will save the work that has
been done.

#### 5.4.1.6 Checking the Log

Crack loads dictionaries directly into memory, sorts and uniques them,
before attempting to use each of the words as a guess for each users\'
password. If Crack correctly guesses a password, it marks the user as
done and does not waste further time on trying to break that user\'s
password.

Once Crack has finished a dictionary pass, it sweeps the list of users
looking for the passwords it has cracked. It stores the cracked
passwords in both plain text and encrypted forms in a feedback file in
the directory **Runtime**. Feedback files have names of the form
**Runtime/F\***. The purpose of this is so that when it is next invoked,
Crack can recognize passwords that it has successfully cracked
previously, and filter them from the input to the password cracker. This
provides an instant list of crackable users who have not changed their
passwords since the last time Crack was run. This list appears in a file
with name **out\*** in the **\$CRACK_OUT** directory, or on **stdout**,
if foreground mode (**-f**) is invoked (see Section "Options", above).

Similarly, when a Crack run terminates normally, it writes out to the
feedback file all encrypted passwords that it has NOT succeeded in
cracking. Crack will then ignore all of these passwords next time you
run it.

Obviously, this is not desirable if you frequently change your
dictionaries or rules, and so there is a script provided,
**Scripts/mrgfbk**, which sorts your feedback files, merges them into
one, and optionally removes all traces of \"uncrackable\" passwords, so
that your next Crack run can have a go at passwords it has not succeeded
in breaking before.

**mrgfbk** is invoked automatically if you run **Scripts/spotless** (see
Section "Crack Support Scripts", above).

### 5.4.2 Enforcing Strong Passwords (Secure Shell)

The security risks involved in using "R" commands such as rlogin, rsh,
rexec and rcp are well known but their ease of use has made their use
tempting in all but the most secure of environments. Ssh is an
easy-to-use, drop in replacement for these commands developed by Tatu
Ylonen. Ssh is a "user" level application. No changes to the host kernel
are required. The UNIX server is available as freeware on the Internet
but ECS will have a support agreement in place to minimize risk to the
program in the event of a product defect.

There are four programs that users use that should be put in /tools/bin
for each architecture:

-   ssh - replaces rsh, rlogin and rexec for interactive sessions

-   scp - replaces rcp for interactive file transfer

-   ssh-add - add access to a specific ssh host

-   ssh-keygen - generates keys for the local host based on a passcode
    (long password)

There are three system programs that should be local to each system:

-   sshd - the ssh daemon started in /etc/rc2.d NOT in inetd.conf

-   ssh-agent - the key management agent started in /etc/rc2.d

-   make-ssh-known-hosts - perl script to generate keys for known ssh
    systems

Several files are generated on installation and when running and are
installed locally:

-   /etc/ssh_config - system-wide configuration for the ssh client

-   /etc/ssh_host_key - contains the long number used for one of the
    keys

-   /etc/ssh_host_key.pub - contains the key known to the public

-   /etc/ssh_random_seed - base number used in generating keys

-   /etc/sshd.pid - the process number of the sshd currently running

-   /etc/sshd_config - defines the local security policy

The amount of disk space that the programs and the configurations files
takes is less than 6 MB. NOTE: To compile the source requires about 30MB
of disk space.

#### 5.4.2.1 The SSH Encryption Mechanism[^1]

Each host has a host-specific RSA key (normally 1024 bits) used to
identify the host. Additionally, when the daemon starts, it generates a
server RSA key (normally 768 bits). This key is normally regenerated
every hour if it has been used, and is never stored on disk.

Whenever a client connects the daemon, the daemon sends its host and
server public keys to the client. The client compares the host key
against its own database to verify that it has not changed. The client
then generates a 256 bit random number. It encrypts this random number
using both the host key and the server key, and sends the encrypted
number to the server. Both sides then start to use this random number as
a session key which is used to encrypt all further communications in the
session. The rest of the session is encrypted using a conventional
cipher. Currently, IDEA, DES, 3DES, ARCFOUR, and TSS (a fast home-grown
algorithm) are supported. IDEA is used by default. The client selects
the encryption algorithm to use from those offered by the server.

Next, the server and the client enter an authentication dialog. The
client tries to authenticate itself using .rhosts authentication,
.rhosts authentication combined with RSA host authentication, RSA
challenge- response authentication, TIS challenge response
authentication, or password based authentication.

Rhosts authentication is normally disabled because it is fundamentally
insecure, but can be enabled in the server configuration file if
desired. System security is not improved unless rshd(8), rlogind(8),
rexecd(8), and rexd (8) are disabled (thus completely disabling
rlogin(1) and rsh(1) into that machine).

If the client successfully authenticates itself, a dialog for preparing
the session is entered. At this time the client may request things like
allocating a pseudo-tty, forwarding X11 connections, forwarding TCP/IP
connections, or forwarding the authentication agent connection over the
secure channel.

#### 5.4.2.2 How a User uses Secure Shell

(TBD)

#### 5.4.2.3 Configuration of Secure Shell

(TBD)

#### 5.4.2.4 Administration of Secure Shell

(TBD)

### 

5.5 Monitoring Requests for Network Services

With TCP Wrapper, you can monitor and filter incoming requests for
network services, such as SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH,
EXEC, TFTP, and TALK.

TCP Wrapper provides small daemon wrapper programs that can be installed
without any changes to existing software or to existing configuration
files. The wrappers report the name of the client host and the name of
the requested service; the wrappers do not exchange information with the
client or server applications, and impose no overhead on the actual
conversation between the client and server applications. The usual
approach is to run one single daemon process that waits for all kinds of
incoming network connections. Whenever a connection is established, this
daemon runs the appropriate server program and goes back to sleep,
waiting for other connections.

M&O personnel will monitor requests for these network services:

  ----------------------- ------------------------ ----------------------
  Client                  Server                   Application

  telnet                  telnetd                  remote login

  ftp                     ftpd                     file transfer

  finger                  fingerd                  show users

  rlogin                  rlogind                  remote login

  TFTP                    TFTPd                    Triviac FTP
  ----------------------- ------------------------ ----------------------

You will monitor the **syslog** file. To view syslog, at the command
line type

more/var/log/syslog

Standard Unix commands can be added, such as vi, emacs, or lp -d:

more/var/log/syslog \| lp -d \[printer name\]

The syslog file provides information concerning who tried to access the
network service. TCP Wrapper blocks any request made by unauthorized
users. TCP Wrapper can be configured to send a message to any
administrator whose request is rejected.

### 5.5.1 INSTALLATION, CONFIGURATION, and TESTING for Wrappers 

Become root on the server that you would like to install wrappers

Note: This documentation is written for sun servers; however, you can
replace

the package \"wrappers_sun.7.4.tar\" for other OS and proceed using the
steps below.

\(1\) Go to any SMC servers with root priveledge

cd /tools/admin/install_pkgs

ftp wrappers_sun.7.4.tar to the server that you would like to install

(put it in /tmp so it does not interfere with others)

\(2\) cd /etc

cp /etc/inetd.conf /etc/inetd.conf.orig

tar xvf /tmp/wrappers_sun.7.4.tar

\(3\) Create /etc/hosts.allow if it does not exist. Using the template

shown below.

/etc/hosts.allow

================

\# Added for HIPPI network. Do Not Delete!

ALL: 192.168.1.: BANNERS /etc/wrappers/banners : ALLOW

ALL: 198.118.: BANNERS /etc/wrappers/banners : ALLOW

ALL: 198.118.192.: BANNERS /etc/wrappers/banners : DENY

ALL: 192.150.28.: BANNERS /etc/wrappers/banners : ALLOW

ALL: 38.177.222.: BANNERS /etc/wrappers/banners : ALLOW

ALL: 128.183.: BANNERS /etc/wrappers/banners : ALLOW

ALL: ALL: BANNERS /etc/wrappers/banners : DENY

\(4\) Insert the following lines into /etc/inetd.conf (usually right
after the current

ftp and telnet declaration entries):

ftp stream tcp nowait root /etc/wrappers/tcpd in.ftpd

telnet stream tcp nowait root /etc/wrappers/tcpd in.telnetd

and then comment the existing ftp and telnet entries there.

This is what it should look like:

#ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd

#telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd

ftp stream tcp nowait root /etc/wrappers/tcpd in.ftpd

telnet stream tcp nowait root /etc/wrappers/tcpd in.telnetd

\(5\) Make sure these lines are commented out from /etc/inetd.conf (as
shown):

\###########################################################################

\#

\# This is the original inetd.conf configuration

\#

\###########################################################################

#shell stream tcp nowait root /usr/sbin/in.rshd in.rshd

#login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind

#exec stream tcp nowait root /usr/sbin/in.rexecd in.rexecd

#comsat dgram udp wait root /usr/sbin/in.comsat in.comsat

#talk dgram udp wait root /usr/sbin/in.talkd in.talkd

\#

\(6\) Insert this block of lines to /etc/inetd.conf (usually right after
the

block in step 5):

\###########################################################################

\#

\# This is the setup associated with the configuration of TCP WRAPPERS

\#

\###########################################################################

shell stream tcp nowait root /etc/wrappers/tcpd in.rshd

login stream tcp nowait root /etc/wrappers/tcpd in.rlogind

exec stream tcp nowait root /etc/wrappers/tcpd in.rexecd

comsat dgram udp wait root /usr/sbin/in.comsat in.comsat

talk dgram udp wait root /etc/wrappers/tcpd in.talkd

\(6\) ps -ef \|grep inetd;

kill -HUP \"inetd process number\"

\(7\) Test to make sure that you can login from the existing host and
also from another

host on a different subnet. If it all goes well, that concluded the
installation. Otherwise,

go back to step (1) and doublecheck your steps.

\(8\) chmod 755 /etc/hosts.allow

touch /var/log/wrappers

chmod 755 /var/log/wrappers

rm /tmp/wrappers_sun.7.4.tar

rm /etc/inetd.conf.orig

### 

### 5.6 Monitoring File and Directory Integrity

Tripwire is a tool that aids in the detection of unauthorized
modification of files resident on Unix systems. Tripwire is
automatically invoked at system startup. This utility checks file and
directory integrity by comparing a designated set of files and
directories against information stored in a previously generated
database. Tripwire flags and logs any differences, including added or
deleted entries. When run against system files regularly, Tripwire spots
any changes in critical system files, records these changes into its
database, and notifies system administrators of corrupted or tampered
files so that they can take damage control measures quickly and
effectively. With Tripwire, system administrators can conclude with a
high degree of certainty that a given set of files remain free of
unauthorized modifications if Tripwire reports no changes.

**Note:** Since system files should not change and users\' files change
constantly, Tripwire should be used to **monitor only system files**.
The list of system files you want to monitor is stored in
**./configs**/**tw.conf**.

Tripwire is configured to mail the system administrator any output that
it generates. However, some files on your system may change during
normal operation, and this necessitates updating the Tripwire database.

### 5.6.1 Installation of TRIPWIRE 

Note: This is written for Solaris; however, Tripwire install for other
OS (e.g. HP and SGI) is the same.

\(1\) Go to any SMC servers with root privilege.

cd /tools/admin/install_pkgs

ftp tripwire_sun.1.2.tar to the server that you would like to install

(put it in /tmp so it does not interfere with others)

\(2\) cd /etc

cp /etc/inet/inetd.conf /etc/inet/inetd.conf.orig

tar xvf /tmp/tripwire_sun.1.2.tar

\(3\) To setup:

/etc/tripwire-1.2/src/tripwire -init

This will create a database file resided in

/etc/tripwire-1.2/src/databases/tw.db\_\"whatever_the_hostname\"

\(4\) To test: touch /etc/intruder

/etc/tripwire-1.2/src/tripwire -v \> /tmp/tw.report

This should reports the present of /etc/intruder. It works !!! Yeah !!!

\(5\) rm /etc/intruder

rm /tmp/tw.report

rm /tmp/tripwire_sun.1.2.tar

### 5.6.2 Updating the Tripwire Database

You can update your Tripwire database in two ways. The first method is
interactive, where Tripwire prompts the user whether each changed entry
should be updated to reflect the current state of the file, while the
second method is a command-line driven mode where specific files/entries
are specified at run-time.

#### 5.6.2.1 Updating Tripwire Database in Interactive mode

Running Tripwire in Interactive mode is similar to the Integrity
Checking mode. However, when a file or directory is encountered that has
been added, deleted, or changed from what was recorded in the database,
Tripwire asks the user whether the database entry should be updated.

For example, if Tripwire is run in Interactive mode and a file\'s
timestamp changed, Tripwire will print out what it expected the file to
look like, what it actually found, and then prompt the user whether the
file should be updated. For example,

/etc/hosts equiv

st_mtime: Wed May 5 15:30:37 1993 Wed May 5 15:24:09 1993

st_ctime: Wed May 5 15:30:37 1993 Wed May 5 15:24:09 1993

\-\--\> File: /etc/hosts equiv

\-\--\> Update entry? \[YN(y)nh?\] y

You could answer yes or no, where a capital \'Y\' or \'N\' tells
Tripwire use your answer for the rest of the files. (The \'h\' and \'?\'
choices give you help and descriptions of the various inode fields.)

While this mode may be the most convenient way of keeping your database
up-to-date, it requires that the user be \"at the keyboard.\" A more
conventional command-line driven interface exists, and is described
next.

#### 5.6.2.2 Updating Tripwire Database in Database Update Mode 

Tripwire supports incremental updates of its database on a
per-file/directory or tw.config entry basis. Tripwire stores information
in the database so it can associate any file in the database with the
tw.config entry that generated it when the database was created.

Therefore, if a single file has changed, you can:

tripwire -update /etc/newly.installed.file

Or, if an entire set of files that made up an entry in the tw.config
file changed, you can:

tripwire -update /usr/local/bin/Local_Package_Dir

In either case, Tripwire regenerates the database entries for every
specified file. A backup of the old database is created in the
**./databases** directory.

Tripwire can handle arbitrary numbers of arguments in Database Update
mode.

The script **twdb_check.pl** script is an interim mechanism to ensure
database consistency. Namely, when new entries are added to the
tw.config file, database entries may no longer be associated with the
proper entry number. The twdb_check.pl script analyzes the database, and
remaps each database entry with its proper tw.config entry.

### 5.6.3 Configuring the tw.config file

Edit your **tw.config** file in the **./configs** directory, or whatever
filename you defined for the Tripwire configuration file, and add all
the directories that contain files that you want monitored. The format
of the configuration file is described in its header and in the \"man\"
page. Pay especially close attention to the select-flags and omit-lists,
which can significantly reduce the amount of uninteresting output
generated by Tripwire. For example, you will probably want to omit files
like mount tables that are constantly changed by the operating system.

Run Tripwire with **tripwire -initialize**. This will create a file
called **tw.db\_\[hostname\]** in the directory you specified to hold
your databases (where \[hostname\] will be replaced with your machine
hostname).

Tripwire will detect changes made to files from this point on. You
**\*must\*** be certain that the system on which you generate the
initial database is clean; however, Tripwire cannot detect unauthorized
modifications that have already been made. One way to do this would be
to take the machine to single-user mode, reinstall all system binaries,
and run Tripwire in initialization mode before returning to multi-user
operation.

This database must be moved someplace where it cannot be modified.
Because data from Tripwire is only as trustworthy as its database,
choose this with care. It is recommended to place all the system
databases on a read-only disk (you need to be able to change the disk to
writeable during initialization and updates, however), or exporting it
via read-only NFS from a \"secure-server.\" (This pathname is hardcoded
into Tripwire. Any time you change the pathname to the database
repository, you must recompile Tripwire. This prevents a malicious
intruder from spoofing Tripwire into giving a false \"okay\" message.)

We also recommend that you make a hardcopy printout of the database
contents right away. In the event that you become suspicious of the
integrity of the database, you will be able to manually compare
information against this hardcopy.

Once you have your database set up, you can run Tripwire in Integrity
Checking mode by typing **tripwire** on the command line from the
directory in which Tripwire has been installed.

## 5.7 Reporting Security Breaches 

TO BE SUPPLIED.

## 5.8 Initiating Recovery from Security Breaches

TO BE SUPPLIED.

# 

[^1]: From the *sshd* man page