UNIX System Administrator's OS Handbook

One of the most convenient features of the UNIX networking software is the concept of "trusted" hosts. The software allows the specification of other hosts (and possibly users) who are to be considered trusted - remote logins and remote executions from these hosts will be permitted without requiring the user to enter a password. This is very convenient, because users do not have to type their password every time they use the network. Unfortunately, for the same reason, the concept of a trusted host is also extremely insecure.

The file /etc/hosts.equiv can be used by the system administrator to indicate trusted hosts. Each trusted host is listed in the file, one host per line. If a user attempts to login or execute a command remotely from one of the systems listed in hosts.equiv, and that user has an account on the local system with the same login name, access is permitted without requiring a password.

Provided adequate care is taken to allow only local hosts in the hosts.equiv file, a reasonable compromise between security and convenience can be achieved. Nonlocal hosts (including hosts at remote sites of the same organization should never be trusted. Also, if there are any machines at your organization that are installed in "public" areas you should not trust these hosts.

Execute the following command:

%ls -ldgb /etc/hosts.equiv; /bin/more
/etc/hosts.equiv

The following response is displayed:

/etc/hosts.equiv:
No such file or directory.

Check for the presence of /etc/hosts.equiv after each operating system or patch installation.

If the responsible security officer has approved the use of a /etc/hosts.equiv file for a specific purpose, execute the following command:

%ls -ldgb /etc/hosts.equiv; /bin/more /etc/hosts.equiv

The /etc/hosts.equiv file contains a list of trusted hosts, one per line. If a user attempts to log in remotely (using rlogin) or to remotely execute a command (using rsh) from one of the hosts listed in this file, and if that user has an account on the local system with the same login name, the system allows the user to log in without a password. The /etc/hosts.equiv file may have several entries. It should be verified that each entry is appropriate. A line of the form +@host-group makes all of the hosts in the network group hostgroup trusted; likewise, a line which has the form -@anotherhostgroup makes all of the hosts in the networkgroup anotherhostgroup specifically not trusted. The file is scanned from the beginning to the end; the scanning stops after the first match. A single line of + in the hosts.equiv file indicates that every known host is trusted. This can create a serious security problem. It is recommended that the /etc/hosts.equiv file be removed altogether, or that the file be replaced with a correctly configured one.

The .rhosts file is similar in concept and format to the hosts.equiv file, but allows trusted access only to specific host-user combinations, rather than to hosts in general. Each user may create a .rhosts file in his home directory, and allow access to his account without a password. Most people use this mechanism to allow trusted access between accounts they have on systems owned by different organizations that do not trust each other's hosts in hosts.equiv. Unfortunately, this file presents a major security problem: while hosts.equiv is under the system administrator's control and can be managed effectively, any user may create a .rhosts file granting access to whomever he chooses, without the system administrator's knowledge.

The only secure way to manage .rhosts files is to completely disallow them on the system. The system administrator should check the system often for violations of this policy.

As root, execute the following command:

#/bin/find / -name.rhosts \-exec ls -ldb {} \; -exec more {} \;

Cron should be used to periodically check for, report the contents of, and remove .rhosts files.

If there is a genuine need for .rhosts files (e.g., running backups over a network unattended) and their use has been approved by responsible security officer:

the first character of any .rhosts file is not "-".

The permissions of all .rhosts files are set to 600

The owner of each .rhosts file is the account's owner

No .rhosts file contains the symbol "+" on any line

Usage of netgroups within .rhosts does not allow unintended access to this account

Comment out the entries for rshd and rlogind in the inetd.conf file

Because the NFS server maps root to nobody, you can protect files and directories on your server by setting their owner to root and making them not world-writeable or group-writeable.

Browse the /etc/dfs/dfstab file using the following command:

#vi /etc/dfs/dfstab

and for each shared filesystem run the following command:

/bin/find filesystem \( -perm \ -2 -o -perm -20 \) -exec ls -ldg {} \;

In some versions of UNIX, it is possible to turn off the SUID and SGID bits on mounted filesystems by specifying the nosuid option with the mount command. If available, this option should always be specified when a filesystem is mounted unless there is an overriding reason to import SUID or SGID files from the mounted filesystem.

One of the best ways to protect sensitive files and directories is to mount them on read-only disks. It is recommended that the following directories be mounted as read-only partitions: /, /usr/bin, /bin, /etc, /lib, /usr/lib, /usr/ucb (if it exists), /usr/include, /usr/src, /usr/etc (if it exists).

Browse the /etc/vfstab file using the following command:

#vi /etc/vfstab

The flag rw should only exist if a legitimate need exists and the flag nosuid should appear.

Each nfs entry in the /etc/vfstab file should appear similar to the following line:
#device
device mount
FS fsck mount
mount
#to mount
to fsck point
type pass at boot
options
Exporthost:/ExportDirPath
- /mountpoint
nfs - yes
ro,bg,nosuid

OR if mounting the filesystem from the command line use the following command:

example# mount -r -o nosuid,bg serv:/usr/src /usr/src

NFS is a distributed database system that is designed to allow several hosts to share files over the network. One of the most common uses of NFS is to allow diskless workstations to be installed in offices, while keeping all disk storage in a central location. As distributed by Sun, NFS has no security features enabled. This means that any host on the Internet may access your files via NFS, regardless of whether you trust them or not.

Fortunately, there are several easy ways to make NFS more secure. The more commonly used methods are described in this section, and these can be used to make your files quite secure from unauthorized access via NFS.

The file /etc/exports is perhaps one of the most important parts of NFS configuration. This file lists which file systems are exported (made available for mounting) to other systems.

The root= keyword specifies the list of hosts that are allowed to have super-user access to the files in the named file system. The access= keyword specifies the list of hosts (separated by colons) that are allowed to mount the named file system. If no access= keyword is specified for a file system, any host anywhere on the network may mount that file system via NFS.

Obviously, this presents a major security problem, since anyone who can mount your file systems via NFS can then peruse them at his leisure. Thus, it is important that all file systems listed in exports have an access= keyword associated with them. Netgroups can also be specified.

Normally, NFS translates the super-user id to a special id called "nobody" in order to prevent a user with "root" on a remote workstation from accessing other people's files. This is good for security, but sometimes a nuisance for system administrators, since you cannot make changes to files as "root" through NFS.

The exports file also allows you to grant super-user access to certain file systems for certain hosts by using the root= keyword. Following this keyword, a colon-separated list of up to ten hosts may be specified.

Granting "root" access to a host should not be done lightly. If a host has "root" access to a file system, then the super-user on that host will have complete access to the file system, just as if you had given him the "root" password on the server. Untrusted hosts should never be given "root" access to NFS file systems.

Use the following command to ensure that file systems are correctly exported:

/usr/bin/vi /etc/dfs/dfstab

This file will not exist if the computer being tested is not an NFS server.

Only necessary filesystems are exported.

Only authorized hosts are given access to the exported filesystems.

All entries use fully qualified hostnames (Preferably an ip address).

Filesystems are shared using "anon=-1" to disallow accesses that are not accompanied by a user ID.

The NFS server is not self-referenced, either by name or by specification of a 'localhost' entry.

File systems to be exported are shared as read-only, except where specifically approved by the responsible security officer.

Only the minimum access necessary is given on the exported filesystem.

File systems to be exported are shared non-setuid.

The "root = " option should NOT be used.

Access should be granted by netgroup or host.

Execute the following command and ensure that the owner and permissions of the dfstab file are correct:
#/usr/bin/ls -lg /etc/dfs/dfstab

Only necessary filesystems are exported.

Only authorized hosts are given access to the exported filesystems.

All entries use fully qualified hostnames (Preferably an ip address).

Filesystems are shared using "anon=-1" to disallow accesses that are not accompanied by a user ID.

The NFS server is not self-referenced, either by name or by specification of a 'localhost' entry.

File systems to be exported are shared as read-only, except where specifically approved by the responsible security officer.

Only the minimum access necessary is given on the exported filesystem.

File systems to be exported are shared non-setuid.

The "root = " option should NOT be used.

Access should be granted by netgroup or host.

Ensure that the RPC portmapper does not allow proxy requests.
directory1 entry gives root access to client1 root. This should not be done unless absolutely necessary.

directory2 entry gives read and write access to all hosts. This should not be done.

directory3 entry gives read and write access to client1 and client2. Write access should be prohibited if not needed.

directory4 entry gives read only access to client1 and client2. This is the most desirable entry.

#!/bin/sh
share -F nfs -o- rw=client1:client2,root=client1 /directory1_to_export
share -F nfs -o -rw, root=client1 /directory1_to_export
share -F nfs -o -rw=client1:client2 /directory2_to_export
share -F nfs -o ro=client1:client2 /directory3_to_export

AusCert reference 2.8

Execute the following command as a privileged user:

vi /etc/default/login

Ensure the # sign has been removed from the line:

CONSOLE=/dev/console

Ensure the "secure terminals" file is owned by root and the permissions are set to "rw-r--r--".

ls -al /etc/default/login

Verify that the network services are configured securely by browsing the /etc/inetd.conf file using the following command:

#/usr/bin/vi /etc/inetd.conf

Unnecessary network services should be disabled.

A "#" starts each line identifying a disabled service. Verify that the following services are disabled: name, shell, login, exec, comsat, talk, uucp, finger, systat, netstat, admind, rquotad, rusersd, sprayd, walld, rstatd, rexd, and tftpd.

Services to be disabled include:
- name: obsolete name server protocol
- shell: allows remote user via rsh to run processes on this system
- login: allows remote user via rlogin
- exec: allows remote users access via rexec
- comsat: real-time intrusive notification to users that mail has arrived
- talk: remote chat protocol
- uucp: UNIX-to-UNIX copy over TCP
- finger: remote access to local user information
- systat: allows remote users to view the process table
- netstat: allows remote users to view the list of active network connections
- admind: allows remote users to execute remote administrative activities
- rquotad: provides disk quota information to NFS clients
- rusersd: provides local user information
- sprayd: allows remote users to send a stream of IP packets to the host and have them acknowledged
- walld: allows remote users to post messages to system users
- rstatd: allows remote users to view system information such as load
- rexd: obsolete remote execution server with no security
- tftpd: trivial ftp server.

Verify that the permissions of the /etc/inetd.conf file are correct using the following command:
#/bin/ls /etc/inetd.conf

Use the following command to verify that only required and authorized network services are registered with the portmapper. The following command determines which services are registered with the Portmapper:

# /usr/bin/rpcinfo -p localhost

Verify that the permissions and owner of the /etc/inet/services file are correct using the following command:

#/bin/ls /etc/inet/services

Type the following command from a networked host:
% rusers -a

As an unprivileged user execute the following commands:
% tftp
tftp> connect localhost
tftp> get /etc/passwd testfile
tftp> quit
%ls -l testfile
%more testfile
%rm testfile

Type the following command:
% ls -lF /usr/bin/tftp
Verify that the file is not running SUID or SGID.

The mail system should not allow mail to be sent directly to a file. Test whether the system allows mail to be sent to a file with the command sequence:
$ mail /tmp/mailbug
this is a mailbug file test
^D

As a non-privileged user, execute the following command sequences:

$ /usr/bin/uux - mail 'root `/bin/touch /tmp/foo`'
this is a mailbug command test
^D
$ /usr/bin/uux - mail 'root & /bin/touch /tmp/foo'
this is another test
^D

As a non-privileged user, execute the following command sequences:
$ uux – mail 'root & /bin/touch /tmp/foo`'
this is another mailbug command test
^D
$ uux – mail 'root & /bin/touch /tmp/foo'
this is another test
^D

Use the following commands to ensure that uucp is not enabled or installed on the system:
#/usr/ucb/vi /etc/inetd.conf

As root, execute the following command to ensure that uucp is not installed on the system:
/bin/find / \( -user uucp -o -name "*uu*" \) \
-exec ls –ldb {} \;

/bin/find / \( -name uuxqt -o -name uucico -o -name uusched -o -name in.uucpd -o -name uux -o -name uucp \) -exec ls -ldb {} \;

The uucp programs should run SUID uucp, not SUID root. Other than being able to read the spooled UUCP files, the uucp user doesn't have any special privileges. The output should appear similar to the output below:

# /bin/find / \( -name uuxqt -o -name uucico -o -name uusched -o -name in.uucpd -o -name uux -o -name uucp \) -exec ls -ldb {} \;
---s--x--x 1 uucp uucp 64240 Jul 15 1994 /usr/bin/uucp
---s--x--x 1 uucp uucp 68040 Jul 15 1994 /usr/bin/uux drwxr-xr-x
2 uucp uucp 512 Aug 20 16:47 /usr/lib/uucp
---s--x--x 1 uucp uucp 169096 Jul 15 1994 /usr/lib/uucp/uucico
---s--x--x 1 uucp uucp 32016 Jul 15 1994 /usr/lib/uucp/uusched
---s--x--x 1 uucp uucp 81040 Jul 15 1994 /usr/lib/uucp/uuxqt
-r-xr-xr-x 1 uucp uucp 8320 Jul 15 1994 /usr/sbin/in.uucpd
-rw-rw---- 1 uucp mail 376 Oct 14 23:45 /var/mail/uucp
-r--r--r-- 1 root sys 215 Aug 20 16:47 /var/spool/cron/crontabs/uucp
drwxr-xr-x 5 uucp uucp 512 Oct 14 23:45 /var/spool/uucp
drwxr-xr-x 7 uucp uucp 512 Aug 20 16:46 /var/uucp
drwxr-xr-x 2 uucp uucp 512 Aug 20 16:46 /var/uucp/.Log/uucico
drwxr-xr-x 2 uucp uucp 512 Aug 20 16:46 /var/uucp/.Log/uucp
drwxr-xr-x 2 uucp uucp 512 Oct 14 23:45 /var/uucp/.Log/uux
drwxr-xr-x 2 uucp uucp 512 Oct 14 23:45 /var/uucp/.Log/uuxqt
-rwxr--r-- 2 root sys 202 Jul 16 1994 /etc/init.d/uucp
drwxr-xr-x 2 uucp uucp 512 Aug 20 16:46 /etc/uucp
#

There are two types of Permissions file entries:
- LOGNAME Specifies the permissions that take effect when a remote computer logs into (calls) the local computer.
- MACHINE Specifies permissions that take effect when the local computer logs into (calls) a remote host.

When using the Permissions file to restrict the level of access granted to remote computers, the following issues should be considered:
- All login IDs used by remote computers to log in for UUCP communications must appear in one LOGNAME entry.
- Any site that is called whose name does not appear in a MACHINE entry, will have the following default permissions or restrictions:
- Local send and receive requests will be executed.
- The remote computer can send files to the local computer's /var/spool/uucppublic directory.
- The commands sent by the remote computer for execution on the local computer must be one of the default commands, usually rmail.

REQUEST Option When a remote computer calls the local computer and requests a file, this request can be granted or denied. The REQUEST options specifies whether the remote computer can request to set up file transfers from the local computer. The default value is REQUEST=no.

READ and WRITE Options These options specify the various parts of the file system that uucico can read from or write to. The default for both the READ and WRITE options is the uucppublic directory, /var/spool/uucppublic.
COMMANDS Option. The COMMANDS option in MACHINE entries can specify the commands that a remote computer can execute on the local computer. The COMMANDS option should be used with great care as misuse can compromise the security of a computer.

Verify uucp's home directory is in an appropriate directory using the following commands:
$grep uucp /etc/passwd
$ls -ld `grep uucp /etc/passwd \
| awk -F: 'length($6)>0 {print $6}'`

Use the following command to ensure that there is no.rhosts file in the uucp home directory:
#find `grep uucp /etc/passwd \
| awk -F: 'length($6)>0 {print $6}'` \
-name.rhosts -exec ls -ldb {} \;
Ensure that no uucp owned files or directories are world writeable.

As root ensure that no uucp owned files or directories are world writeable using the following command:
find / -user uucp -perm -2 \
-exec ls -ldb {} \;

The "finger" service, provided by the finger program, allows you to obtain information about a user such as her full name, home directory, last login time, and in some cases when she last received mail and/or read her mail. The fingerd program allows users on remote hosts to obtain this information.

A bug in fingerd was also exercised with success by the Internet worm. If your version of fingerd is older than November 5, 1988, it should be replaced with a newer version.

The finger program has two uses: If finger is run with no arguments, the program prints the username, full name, location, login time, and office telephone number of every user currently logged into the local system. If finger is run with a name argument, the program searches through the /etc/passwd file and prints detailed information for every user with a first, last, or user name that matches the name you specified. finger makes it easy for intruders to get a list of the users on the system.

Type in the following command:

user1>finger root@localhost

Execute the following command:

user1>finger @localhost

Execute the following command:
user1>finger
23234123123123123@localhost

Output should be displayed:
Input needed

1. Download the tcp wrappers source code.
2. Untar-gz tcp_wrappers_7.6.tar.gz tar zxvf tcp_wrappers_7.6.tar.gz
3. Compile and Install the wrappers program.

Now you will build and install the program.
cd tcp_wrappers_7.6
make REAL_DAEMON_DIR=/usr/sbin linux
make install <----you'll need to be logged on as root to run this command !

Edit your /etc/hosts.allow and /etc/hosts.deny to limit access to your computer's network services.

The format of the hosts.allow/hosts.deny files is as follows:
service: hostname: banners if needed : options

The second rule follows the same format as the first, it denies access to telnet to all users from "lamers.edu", and sends email to auth.

The third rule allows access to all users from everywhere but email's "auth" with details of the connection.

Each rule goes on it's own unbroken line.

"man 5 hosts_access" for more information.

Here are a few lines of a typical /etc/syslog.conf:

*.err;kern.debug;auth.notice;mail.crit/dev/console
*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
mail.info /var/log/maillog

Here are a few lines of our edited /etc/syslog.conf:
*.err;kern.debug;auth.notice;mail.crit /dev/console

*.notice;kern.debug;lpr.info;mail.crit;news.err;auth.info /var/log/messages
mail.info /var/log/maillog

The following example has the original lines commented (#) out and our modified tcpd lines inserted.
#ftp stream tcp nowait root /usr/sbin/ftpd ftpd -l -a
ftp stream tcp nowait root /usr/sbin/tcpd ftpd -l -a
#telnet stream tcp nowait root /usr/sbin/telnetd telnetd
telnet stream tcp nowait root /usr/sbin/tcpd telnetd
#finger stream tcp nowait nobody /usr/sbin/fingerd fingerd -s

Linux differs from some *unix's in that the file locations aren't quite "standard", so when you install tcp_wrappers the "tcpd" file may be in the "/usr/libexec" directory, in which case you'll have to change "/usr/sbin/tcpd" to "/usr/libexec/tcpd" in the above example.

Type the following command:
#vi /etc/aliases
Search for decode by typing "/decode" and press return.

A message should be printed to the bottom of the window as follows:

Pattern not found

OR the decode alias line appears as follows:
#decode: "|/usr/bin/uudecode"

Type in the following commands:
% telnet localhost 25
wiz
quit

The session should appear similar to the following:
user>telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 ziggy. Sendmail 5.x/SMI-SVR4
ready at Fri, 18 Oct 1996 15:48:03 -
0400
wiz
500 Command unrecognized
quit
221 ziggysol24. closing connection
Connection closed by foreign host.
user>

Type in the following command:
% telnet localhost 25
debug
quit

Sendmail should respond to the debug command with "5nn error return" (e.g., "500 Command unrecognized"). Any response from the server indicating recognition of the command indicates a sendmail vulnerability and sendmail should be replaced.

The session should appear similar to the following:

user>telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 ziggy. Sendmail 5.x/SMI-SVR4
ready at Fri, 18 Oct 1996 15:48:03 -
0400
debug
500 Command unrecognized
quit
221 ziggysol24. closing connection
Connection closed by foreign host.
user>

Type in the following command:
% telnet localhost 25
kill
quit

The session should appear similar to the following:
user>telnet localhost 25
25 Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 ziggy. Sendmail 5.x/SMI-SVR4
ready at Fri, 18 Oct 1996 15:48:03 -
0400
kill
500 Command unrecognized
quit
221 ziggysol24. closing connection
Connection closed by foreign host.
user>

From a command shell, execute the following command:
# /usr/lib/sendmail -d3294967296

Use the following command to verify that the http client applications are not being run as root:

#/usr/bin/find / -name "*osaic*" \ -exec ls -ldb {} \;

#/usr/bin/find / -name \"*etscape*" \ -exec ls -ldb {} \;

#/usr/bin/find / -name "http*" \-exec ls -ldb {} \;

As root, execute the following command:

#/bin/find / -name "*http*" \-exec ls –ldb {} \;

Type the following commands:
ls -lg /etc/ftpusers
more /etc/ftpusers

From a networked host, type the following commands to check for an early FTP bug:
% ftp -n
ftp> open <localhost>
ftp> quote user ftp
ftp> quote user ftp

To ascertain whether you are running anonymous ftp, try to connect to the localhost using anonymous ftp. Be sure to give an RFC822-compliant username (e.g., mcguire@ncr.disa.mil) as the password. Type the following commands to ascertain whether anonymous ftp is enabled:
% ftp <hostname>
name (localhost:idname): anonymous

AusCert reference 4.1

The IT Specialist/System Manager shall manage the creation, use and deletion of user IDs and password to prevent unauthorized access to the system.

Whenever possible, passwords shall be user generated under the supervision of access control software. In facilities where access control software is not available, the IT Specialist/System Manager shall create and distribute user passwords in a controlled manner, and in such a way that an audit record of password date and time of issuance, receipt, use, change, expiration and termination is maintained.

Review the following file:
/etc/default/passwd

The following parameters should be set to appropriate values:
ttys = all
logintimes = 0
logindisable = 0
loginreenable = 0
logininterval = 0
logindelay = 0
logintimeout = 60
maxage = 12
maxrepeat = 2
maxexpired = 4
histexpire = 52
histsize = 8
pwdwarntime = 5
pwdwarntime = 5
minother = 1
minlen = 6
mindiff = 3

To determine the password aging set for individual users, execute the following command:

# logins -x

IT Specialists/System Managers must limit unsuccessful logon attempts from any workstation to three. After three unsuccessful logon attempts, the system shall automatically lock out the workstation. Only the system staff shall be given the capability to reset a workstation after lockout.

The following configuration settings are displayed:

Input needed.

To check the permissions on the NIS/NIS+ passwd table, sites can use:

# niscat -o passwd.org_dir
Object Name : passwd
Owner : myhost.mydomain.org.
Group : admin.mydomain.org.
Domain : org_dir.mydomain.org.
Access Rights : ----rmcdrmcd----
Time to Live : 12:0:0
Object Type : TABLE
Table Type : passwd_tbl
Number of Columns : 8
Character Separator : :
Search Path :
Columns :
[0] Name : name
Attributes :
(SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : r---------------
[1] Name : passwd Attributes : (TEXTUAL DATA) Access Rights : -----m----------
[2] Name : uid Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : r---------------
[3] Name : gid Attributes : (TEXTUAL DATA) Access Rights : r------
[4] Name : gcos Attributes : (TEXTUAL DATA) Access Rights : r---------------
[5] Name : home Attributes : (TEXTUAL DATA) Access Rights : r---------------
[6] Name : shell Attributes : (TEXTUAL DATA) Access Rights : r---------------
[7] Name : shadow Attributes : (TEXTUAL DATA) Access Rights : ----------------

This output shows two types of access rights associated with the NIS/NIS+ passwd table. First, the default access rights for the table, which are given at the start of the output (----rmcdrmcd----). Second, the access rights associated with each column.

In particular, sites should check the access rights on the columns of the NIS/NIS+ passwd table. It should be noted that it appears that individual entries of the passwd table are owned by individual users. The example access rights do not allow a user to modify any part of their passwd table entry besides their own passwd field. For many environments this is acceptable.

However, depending on the local site configuration and requirements, additional access rights may also be needed.

- Sites that have their NIS+ servers running in NIS compatibility mode to serve NIS clients may require (r)ead permission for nobody on the NIS+ passwd table.

- Sites that are using password aging may require additional access rights on the shadow column. The exact access rights will depend on the particular NIS+ version (including patches). Sites are encouraged to check their local documentation for more information.

Sites may set the access rights on the NIS+ passwd table, as shown in the above output, by issuing the following commands as root on the master NIS+ server.

To set the default access rights for the NIS+ passwd table:

# nischmod na-rmcd,og+rmcd passwd.org_dir

To set the column access rights on the NIS+ passwd table:

# nistbladm -u name=na-rmcd,n=r passwd.org_dir
# nistbladm -u passwd=na-rmcd,o=m passwd.org_dir
# nistbladm -u uid=na-rmcd,n=r passwd.org_dir
# nistbladm -u gid=na-rmcd,n=r passwd.org_dir
# nistbladm -u gcos=na-rmcd,n=r passwd.org_dir
# nistbladm -u home=na-rmcd,n=r passwd.org_dir
# nistbladm -u shell=na-rmcd,n=r passwd.org_dir
# nistbladm -u shadow=na-rmcd passwd.org_dir

Try using NIS with the '*' in the password field for example:
+:*:0:0:::

With the '*' removed, try logging in again.

If NIS users can log in AND you can also log in unauthenticated as the user '+', then your implementation is vulnerable.

If NIS users can log in AND you cannot log in as the user '+', your implementation should not be vulnerable to this problem.

Ensure that /etc/rc.local or the equivalent startup procedure is set up to start ypbind with the -s option.

Input needed.

Ensure secure RPC is not enabled.

Input needed.

AusCert reference 4.4

The IT Specialist/System Manager must control access to specialized system software, utilities, and functionality that could be used to gain unauthorized access to application data and program code. The IT Specialist/System Manager must keep access to these resources to the minimum number of authorized users required to accomplish program objectives.

The following permissions are displayed:

-r-------- root sys /etc/shadow

AusCert reference 4.5

IT Specialists/System Managers must assign individual users a minimum three character user-ID. The user-ID shall be unique to each user and shall identify the user to the system. The assignment of more than one user or a phantom user to a user-ID is prohibited. The IT Specialist/System Manager shall ensure that each system user is assigned a valid and appropriate logon procedure to control the processing options available to the system user.

Simply put, accounts without passwords should not be allowed on any system. An account without a password is an easy target for an intruder and subjects the entire system to risk.

As root execute the following command:

# logins -p

There should be no output from this command. This indicates that all accounts have passwords.

NOTE: If a password of is assigned by root, this test does not work as the password field in /etc/shadow contains a value for the password. The only remedy for this is a dictionary search.

AusCert reference 4.6

The IT Specialist/System Manager shall manage the creation, use and deletion of user IDs and password to prevent unauthorized access to the system.

If NOT running NIS, browse the /etc/passwd file to determine if there is a guest account using the following command:

#/usr/bin/vi /etc/passwd

OR if running NIS, determine if there is a guest account on the system by executing the following command:

#/bin/niscat passwd.org_dir

AusCert reference 4.6

The IT Specialist/System Manager shall manage the creation, use and deletion of user IDs and password to prevent unauthorized access to the system.

Attempt to log into each of the following IDs with its default password:

Userid: guest
Password: guest

Userid: root
Password: root
Userid: system
Password: manager

COPS, Tiger, and SPI check for common default passwords.

Browse the following file:

/etc/default/login

The following line should be uncommented in the /etc/default/login file:

CONSOLE=/dev/console

This ensures that root can only log in at the system console, not from any remote terminal.

The file /etc/default/login is owned by root.

The file /etc/default/login has permissions 644.

An entry in the file /etc/default/login determines the root access restrictions. If the following command appears in the file, then root access is restricted to the console:

CONSOLE=/dev/console

Any user who tries to remotely log into the system must first login to his account, and then use the su command to become root. (Security, Performance, and Accounting Administration)

As root execute the following commands:

#echo $PATH

OR

review the root search path found in the /.profile, /.cshrc, and /.login files.

As root, execute the following command:

ls -ldb `echo $PATH | sed 's/:/ /g'`

As root execute the following command:

#/bin/find / -name.netrc \-exec ls -ld {} \; -exec more {} \;

The.netrc file should not exist on a secure system.

If the responsible security officer has approved the use of.netrc files for a specific purpose: Do not store password information in.netrc files. Set Permissions on.netrc files to disallow read and write access by group and world ( i.e., 600).

As root execute the following command:


# /bin/find / -name '.exrc' -exec /bin/cat {} \; -print

As root execute the following command:

# /bin/find / -name '.forward' -exec /bin/cat {} \; -print

As root, execute the following command:

/bin/find /etc \( -perm -2 -o \-perm -20 \) -exec ls -ld {}\;

Type in the following commands:

#showrev -p
#find / -name "*preserve*" \-exec ls -lgdb {} \;

Check to see if the expreserve executable is setuid root. If not, the following procedure won't work:

1. cd into to your home directory
2. Create a file called "bin" containing the following lines:
   # (IFS= should be followed by a single space then return) IFS=' 'cp /bin/sh /the/path/to/your/home/directory/xyzzy chmod 4755 xyzzy
3. After saving the file (and exiting the editor) Type:
   
   % chmod 755 bin
   % /bin/sh
4. From this Bourne shell, type:
   
   IFS=/ vi
5. You should be in vi. Type "a" (return) and then type a couple of lines of random text into the buffer.
6. Type: <Escape> :preserve
7. Next exit the editor using the command:
   
   <Escape> :wq
8. Enter the command:
   
   % ls -l xyzzy

Check to see if the expreserve executable is setuid root. If not, the following procedure won't work:

1. cd into the test working directory.
2. Create a file called "bin" containing the following lines:
   
   # (IFS= should be followed by a single space then return)
   IFS=' '
   cp /bin/sh./xyzzy
   chmod 4755./xyzzy
3. After saving the file (and exiting the editor) Type:
   % chmod 755 bin
   % /bin/sh
4. From this Bourne shell, type:
   
   IFS=/ vi
5. You should be in vi. Type "a" (return) and then type a couple of lines of random text into the buffer.
6. Type: <Escape> :preserve
7. Next exit the editor using the command:
   
   <Escape> :wq
8. Enter the command:
   
   % ls -l xyzzy

In some versions of UNIX, it is possible to turn off the SUID and SGID bits on mounted filesystems by specifying the nosuid option with the mount command. If available, this option should always be specified when a filesystem is mounted unless there is an overriding reason to import SUID or SGID files from the mounted filesystem.

One of the best ways to protect sensitive files and directories is to mount them on read-only disks. It is recommended that the following directories be mounted as read-only partitions: /, /usr/bin, /bin, /etc, /lib, /usr/lib, /usr/ucb (if it exists), /usr/include, /usr/src, /usr/etc (if it exists).One of the best ways to protect sensitive files and directories is to mount them on read-only disks. It is recommended that the following directories be mounted as read-only partitions: /, /usr/bin, /bin, /etc, /lib, /usr/lib, /usr/ucb (if it exists), /usr/include, /usr/src, /usr/etc (if it exists).

Browse the /etc/vfstab file using the following command:

#vi /etc/vfstab

As root, execute the following command:

#/bin/find / \( -type c -o -type \b \) -exec ls -lgdb {} \; | \grep -v "/dev/" | grep -v "/devices/"

Any device outside the /dev and /devices directory should be viewed with GREAT suspicion.

NOTE: ncheck locates SUID files also. The -s parameter of the ncheck command displays special files and files with set-user-ID mode. This parameter can be used to discover concealed violations of security policy. The ncheck command would be run as root and executed as follows:
#/etc/ncheck -s

As root, execute the following command:

/bin/find /dev ! \( -type l \-o -type c -o -type b \) \-exec ls -lgdb {} \;

As root, execute the following command:

#/bin/find / \( -type c -o \
-type b \) ! -user root \
-exec ls -ldb {} \;

# /bin/chmod 644 /etc/utmp
# /bin/chmod 2755 /etc/sm
# /bin/chmod 2755 /etc/sm.bak
# /bin/chmod 644 /etc/state
# /bin/chmod 644 /etc/motd
# /bin/chmod 644 /etc/mtab
# /bin/chmod 644 /etc/syslog.pid

# /bin/chmod 644 /etc
# /bin/chown root /etc
# /bin/chmod 644 /usr/etc
# /bin/chown root /usr/etc
# /bin/chmod 644 /bin
# /bin/chown root /bin
# /bin/chmod 644 /sbin
# /bin/chown root /sbin
# /bin/chmod 644 /usr/sbin
# /bin/chown root /usr/sbin

# /bin/chown root /tmp
# /bin/chown root /var/tmp

# /bin/chgrp 0 /tmp
# /bin/chmod 1777 /tmp
# /bin/chmod 1777 /var/tmp

Obtain a list of all temp directories on the system. A temp directory is any directory that is used to write scratch files. The main temp directories for Solaris 2.5.1 include: /tmp and /var/tmp /usr/tmp. Use the following command to check the permissions on any temp directories:

ls -l <temp dir name>

Output similar to the following should be displayed:

drwxrwxrwt 5 sys sys 846
Apr 15 13:11.

As root, execute the following commands:

# /bin/find / -type f \( -perm \
-2 -o -perm -20 \) -exec ls -lgb {} \;

# /bin/find / -type d \( -perm \
-2 -o -perm -20 \) -exec ls -lgdb {} \;

There are no unexpected world writeable files or directories on your system. Files should be world-writeable only if there is a legitimate requirement.

COPS, Tiger, SPI all provide checking of file permissions.

The following files and directories may safely remain world-writeable:

/tmp and contents
/var/tmp and contents
/var/preserve
/var/mail
(and many more...)

SUID and SGID files allow an unprivileged user to accomplish tasks that require privileges. When a SUID program is run, its effective UID becomes that of the user who created the program, rather than the user who is running it. When a SGID program runs, its effect GID becomes that of the creating user.

Shell scripts that have the setuid or setgid bits set on them are not secure, regardless of how many safeguards are taken when writing them. Setuid and setgid shell scripts should never be allowed on any UNIX system.

As root, execute the following command:

#/bin/find / -type f \( -perm \
-4000 -o -perm -2000 \) \
-exec ls -lgdb {} \;

AusCert reference 5.5

The IT Specialist/System Manager must implement all application controls to ensure users are assigned access rights and privileges consistent with their functional responsibilities and authorities. Access rights and privileges must be based on need-to-know, separation of duties, and management authorization.

The IT Specialist/System Manager shall ensure that controls are implemented which limits access to files, programs, and data to users or groups of users with the same need-to-know. Need-to-know shall be based on functional responsibilities, operational requirements, supervisory responsibilities, or a combination of these factors.

The IT Specialist/System Manager controls and limits computer system access to individuals requiring system access in the performance of their official duties. The IT Specialist/System Manager must limit the access of system users to the minimum level necessary to perform their official duties.

SUID and SGID files allow an unprivileged user to accomplish tasks that require privileges. When a SUID program is run, its effective UID becomes that of the user who created the program, rather than the user who is running it. When a SGID program runs, its effect GID becomes that of the creating user.

Shell scripts that have the setuid or setgid bits set on them are not secure, regardless of how many safeguards are taken when writing them. Setuid and setgid shell scripts should never be allowed on any UNIX system.

As root, execute the following shell script for printing the umask value for each user:

#!/bin/sh
date
uname -a
PATH=/bin:/usr/bin:/usr/etc:/usr/ucb

HOMEDIRS=`cat /etc/passwd | awk -F: 'length($6)>0 {print $6}' | sort -u`
FILES=".cshrc.login.profile "for dir in $HOMEDIRS
do
echo "-----------------------------"
echo Home Directory being
checked is $dir
for file in $FILES
do
ls -ald $dir/$file
if [ -f $dir/$file ]
then
grep -s umask /dev/null
$dir/$file
fi
done
doneecho "-----------------------------"

Utilize the following shell script for viewing the account initialization files for each user:

#!/bin/sh
date
uname -a
PATH=/bin:/usr/bin:/usr/etc:/usr/ucb

HOMEDIRS=`cat /etc/passwd | awk -F: 'length($6)>0 {print $6}' | sort -u`
FILES=".cshrc.login.profile.logout.mwmrc.Xsession.Xdefaults.exrc.forward.rhosts"
for dir in $HOMEDIRS
do
echo "-----------------------------"
echo Home Directory being
checked is $dir
checked is $dir
done
echo "-----------------------------"

All user account initialization files are owned by the user (or root) and have permissions 640.

Ensure the default account initialization files are secure. A shell script for viewing the files follows:

#!/bin/sh
date
#!/bin/sh
date
uname -a
echo ------------------------------
echo /etc/.profile
echo -----------------------------
ls -al /etc/.profile
cat /etc/.profile
echo ---------------------------
echo /etc/skel/local.cshrc
echo ----------------------------
ls -al /etc/skel/local.cshrc
cat /etc/skel/local.cshrc

echo ----------------------------
echo /etc/skel/local.login
echo -----------------------------
ls -al /etc/skel/local.login
cat /etc/skel/local.login
echo -----------------------------
echo /etc/skel/local.profile
echo -----------------------------
ls -al /etc/skel/local.profile
cat /etc/skel/local.profile

echo -----------------------------
echo /etc/profile
echo -----------------------------
ls -al /etc/profile
cat /etc/profile

echo ----------------------------
echo ----------------------------
echo Operating environment initialization files
echo ----------------------------
echo ----------------------------
echo /etc/csh.login
echo ----------------------------
ls -al /etc/csh.login
cat /etc/csh.login

echo ----------------------------
echo /etc/dt/config/sys.dtprofile
echo ----------------------------
ls -al /etc/dt/config/sys.dtprofile
cat /etc/dt/config/sys.dtprofile
echo ----------------------------
echo /h/USERS/local/sysadmin/Scripts/.cshrc
echo ----------------------------
ls -al /h/USERS/local/sysadmin/Scripts/.cshrc
cat /h/USERS/local/sysadmin/Scripts/.cshrc
echo ----------------------------
echo /h/USERS/local/sysadmin/Scripts/.login
echo ----------------------------
ls -al /h/USERS/local/sysadmin/Scripts/.login
cat /h/USERS/local/sysadmin/Scripts/.login

echo ----------------------------
echo /h/OPERATING environment/Scripts/.cshrc.OPERATING environment
echo ----------------------------
ls -al /h/OPERATING environment/Scripts/.cshrc.OPERATING environment
cat /h/OPERATING environment/Scripts/.cshrc.OPERATING environment

echo ---------------------------
echo /h/OPERATING environment/Scripts/.login
.OPERATING environment
echo ---------------------------
ls -al /h/OPERATING environment/Scripts/.login.
OPERATING environment
cat /h/OPERATING environment/Scripts/
.login.OPERATING environment

echo ---------------------------
echo /h/OPERATING environment/Scripts/
.xsession.OPERATING environment
echo ---------------------------
ls -al /h/OPERATING environment/Scripts/.
xsession.OPERATING environment
cat /h/OPERATINGenvironment/Scripts/.
xsession.OPERATING environment

echo ----------------------------
echo $OPERATING environment_HOME/Scripts
echo ----------------------------
ls -alg $OPERATING environment_HOME/Scripts
echo ----------------------------

All default account initialization files that are used if user account initialization files are not present have been reviewed to ensure that only acceptable actions are taken. Acceptable actions include: set user terminal type, check for new e-mail, and set a proper umask (027 or 077). Any other actions should be explicitly approved by the responsible security officer.

As root, execute the following command:

/bin/find / -name ".exrc" -print -exec ls
-ld {} \; -exec /usr/bin/more {} \;

To use a copy of.exrc located in the current directory other than $HOME, set the exrc option in EXINIT or $HOME/.exrc. Options set in EXINIT can be turned off in a local.exrc only if exrc is set in EXINIT or $HOME/.exrc.

AusCert reference 5.6

The IT Specialist/System Manager must implement all application controls to ensure users are assigned access rights and privileges consistent with their functional responsibilities and authorities. Access rights and privileges must be based on need-to-know, separation of duties, and management authorization.

The IT Specialist/System Manager shall ensure that controls are implemented which limits access to files, programs, and data to users or groups of users with the same need-to-know. Need-to-know shall be based on functional responsibilities, operational requirements, supervisory responsibilities, or a combination of these factors.

The IT Specialist/System Manager controls and limits computer system access to individuals requiring system access in the performance of their official duties. The IT Specialist/System Manager must limit the access of system users to the minimum level necessary to perform their official duties.

Various programs have methods of automatic initialization to set options and variables for the user. All startup files should be protected so only the user can write to them. It is particularly important that the startup files the superuser uses are not writeable by others.

As root, execute the following commands from root's home directory and verify from the output that the files listed are writeable only by root:

#ls -ldb /.login
#ls -ldb /.profile
#ls -ldb /etc/profile
#ls -ldb /.cshrc
#ls -ldb /.kshrc
#ls -ldb /.emacs
#ls -ldb /.exrc
#ls -ldb /.forward
#ls -ldb /.rhosts
#ls -ldb /.dtprofile
#ls -ldb /.Xdefaults

As root, execute the following commands from root's home directory to VIEW the files listed below. Also, on any executable that is referenced in the file being viewed execute the "ls -ldb" command to check the permissions of the file.
#/usr/ucb/more /.login
#/usr/ucb/more /.profile
#/usr/ucbmore /etc/profile
#/usr/ucb/more /.cshrc
#/usr/ucb/more /.kshrc
#/usr/ucb/more /.emacs
#/usr/ucb/more /.exrc
#/usr/ucb/more /.forward
#/usr/ucb/more /.dtprofile
#/usr/ucb/more /.Xdefaults

System Administrators should be trained to type in full pathname of files to be executed and to ensure that any executable that is not located in a protected directory is safe to execute.

Type in the following commands:

#ls -lgdb /etc /usr /usr/bin /usr/sbin
/usr/5bin

All executables run by root should be located in a directory where every directory in the path is owned by root and is not group or world writeable. In particular, the following directories should not be group or world writeable: /bin, /etc, /usr/sbin, /usr/bin, /usr/5bin, /usr/ucb. System Administrators should be trained to type in full pathname of files to be executed and to ensure that any executable that is not located in the protected directories listed above are safe to execute.

As root, execute the following commands:

#find /etc -user root \( -perm \
-2 -o -perm -20 \) ! -type l \
-exec ls -lgdb {} \;
#find /usr/bin -user \
root \( -perm -2 -o -perm -20 \) \
! -type l -exec ls -lgdb {} \;
#find /usr/sbin -user root \( -perm \
-2 -o -perm -20 \) ! -type l \
-exec ls -lgdb {} \; #find /usr/5bin -user root \( -perm \
-2 -o -perm -20 \) ! -type l \
-exec ls -lgdb {} \;

All executables run by root should be owned by root and all executables run by root should not be world or group writeable.

AusCert reference 5.7

The IT Specialist/System Manager must control access to specialized system software, utilities, and functionality that could be used to gain unauthorized access to application data and program code. The IT Specialist/System Manager must keep access to these resources to the minimum number of authorized users required to accomplish program objectives.

Verify that the development tools listed in the results are owned by a privileged user and cannot be accessed by an unprivileged user.

For each of the development tools listed, enter "ls -alg <development tool>".

find / -name gcc -exec ls -ld {} \;

The permissions on the tool executables should be 750. The development tools should be assigned to a specific developer's group.

Unprivileged users cannot access the development tools listed below:

/usr/bin/adb
/usr/bin/as
/usr/bin/bc
/usr/lib/compile
/usr/bin/cb
/usr/bin/cflow
/usr/bin/cxref
/usr/bin/dbxtool
/usr/bin/ld
/usr/bin/lex
/usr/bin/m4
/usr/bin/od
/usr/bin/rpcgen
/usr/bin/yacc
/usr/bin/dbx
/usr/bin/gcore
/usr/bin/sccs
/usr/bin/xstr
/usr/openwin/bin/cps
/usr/openwin/bin/makeafb
/usr/5lib/compile/usr/5bin/lint
/usr/5bin/od

xdm bypasses the normal getty and login functions, which means that quotas for the user, ownership of /dev/console and possibly other preventive measures put in place may be ignored.

You should consult your vendor and ask about potential security holes in xdm and what fixes are available.

If you are running a version of xdm earlier than October 1995 then you should update to a newer version. (Refer to CERT Vendor-Initiated Bulletin VB-95:08, see C.8)

Obtain a list of all temp directories on the system. A temp directory is any directory that is used to write scratch files. The main temp directories for Solaris 2.5.1 include: /tmp and /var/tmp /usr/tmp. Use the following command to check the permissions on any temp directories:

ls -l <temp dir name>

X uses a system called xhost to provide a minimal amount of security for window system users. Each X Window Server has a built-in list of hosts from which it will accept connections; connections from all other hosts are refused. The design of the X Window System allows any client that successfully connects to the X Window Server to exercise complete control over the display. If a person can log into a system, they can capture another user's keystrokes no matter how the xhosts is set.

Release 4 of the X Window Protocol has a secure feature on the xterm command that makes the window change its color if it is not receiving its input directly from the keyboard. This is a partial fix, but it is not complete .

Type the following command to produce a list of which hosts are listed in xhost:

% xhost

Operating systems generally maintain a number of log files that keep track of system, security, and application information. These log files form the basis of an operating system's auditing subsystem. Auditing can be enabled or disabled. It should always be enabled for a secure system.

Type in the following command to verify if auditing is enabled:

#auditconfig -getcond

The -getcond option obtains the machine audit condition. The response is one of three possible conditions:
auditing - Auditing is enabled and turned on
no audit - Auditing is enabled but turned off
disabled - The audit module is not enabled
An error message with the format "auditconfig: error = Invalid argument(22)" indicates that the BSM option has not been enabled on the system and the auditconfig command cannot be used.

IT Specialists/System Managers must archive the audit trail to a file with the most stringent access restrictions available. Audit trails containing financial information and transactions must be retained for a period of two years. Audit trails containing information not related to financial information and transactions must be retained for a period of six months.

The audit trail must record at least the following events and any other events deemed appropriate by the Program Manager or EXO: Multiple logon failures; Logons during non-business hours; Program or file access denial; Addition, deletion, or modification of user or program access privileges; and Changes in file access restrictions.

The system operation log must contain a record of all normal daily operations, system power-ups and power-downs, media mounts and dismounts, backup and recovery operations, and general environmental conditions. Installation, removal or modification of system or application software must be noted in the log. Any unusual events or operating conditions must also be noted in the log. Logs shall be maintained, in the central system file for a minimum of six months from the date of the last entry.

Type in the following command:

#/usr/sbin/auditconfig -chkconf

The command "auditconfig -chkconf" should not display any audit mapping inconsistencies. If the mappings are consistent, then the command will execute without printing any message as in the following:

#/usr/sbin/auditconfig -chkconf

Basic Security Module should be installed and turned on.

The -chkconf option of the auditconfig command checks the configuration of kernel audit events to class mappings and reports any inconsistencies.

IT Specialists/System Managers must archive the audit trail to a file with the most stringent access restrictions available. Audit trails containing financial information and transactions must be retained for a period of two years. Audit trails containing information not related to financial information and transactions must be retained for a period of six months. The audit trail must record at least the following events and any other events deemed appropriate by the Program Manager or, EXO: Multiple logon failures; Logons during non-business hours; Program or file access denial; Addition, deletion, or modification of user or program access privileges; and Changes in file access restrictions.

IT Specialists/System Managers must limit unsuccessful logon attempts from any workstation to three. After three unsuccessful logon attempts, the system shall automatically lock out the workstation. Only the system staff shall be given the capability to reset a workstation after lockout.

Verify the following file exists:

/var/adm/loginlog

Attempt to login using an invalid password on a VALID user account. Repeat this step 4 times for a total of 5 times. Browse the /var/adm/loginlog file.

Type the following command:

vi /etc/default/su

The following lines should be uncommented (i.e., should not have a "#" in front of them):

SULOG=/var/adm/sulog
CONSOLE=/dev/console

Entries in the file /etc/default/su determine the default conditions of the su command. The following entry enables a log of each time the su command is used to change to another user:

SULOG=/var/adm/sulog
(Security, Performance, and Accounting Administration)

E551.5.3b para 5f.

IT Specialists/System Managers must archive the audit trail to a file with the most stringent access restrictions available. Audit trails containing financial information and transactions must be retained for a period of two years. Audit trails containing information not related to financial information and transactions must be retained for a period of six months.

Type in and run the following script to determine which users have not logged in within the last month:

#!/bin/sh
date
uname -a
PATH=/bin:/usr/bin;export PATH
umask 077
THIS_MONTH=`date | awk '{print $2}'`
/bin/last | /bin/grep \
$THIS_MONTH | \
awk '{print $1}' | sort -u > users1$$
cat /etc/passwd | \
/bin/awk -F: '{print $1}' | \
/bin/sort -u > users2$$
/bin/comm -13 users[12]$$
/bin/rm -f users[12]$$

The IT Specialist/System Manager shall ensure that password file maintenance shall be restricted to the IT Specialist/System Manager, and passwords shall be screen-suppressed during logon and re-authentication. The IT Specialist/System Manager must control access to specialized system software, utilities, and functionality that could be used to gain unauthorized access to application data and program code. The IT Specialist/System Manager must keep access to these resources to the minimum number of authorized users required to accomplish program objectives.

The following permissions are displayed:

-r-------- root sys /etc/shadow