# # # set -n # Uncomment to check syntax without ANY execution # set -x # Uncomment to debug this script SCRIPT_NAME=$(basename $0) ############################################ function usage { echo “\n***************************************” echo “\nUSAGE: $SCRIPT_NAME [Number_Of_Meg_Bytes]” echo “\nEXAMPLE: $SCRIPT_NAME 5” echo “\n\nWill Find Files Larger Than 5 Mb in, and below” echo “the Current Directory ” echo “\n\n\t EXITING ” echo “\n***************************************” } ############################################ function trap_exit { echo “\n**********************************************” echo “\n\n EXITING ON A TRAPPED SIGNAL ” echo “\n\n**********************************************\n” } ############################################ # Set a trap to exit. REMEMBER - CANNOT TRAP ON kill -9 trap ‘trap_exit; exit 2’ 1 2 3 15 ############################################ # Check for the correct number of arguments if [ $# -ne 1 ] then usage exit 1 fi ###################################### # Check for an integer case $1 in Listing 18.1 findlarge.ksh shell script listing. (continued) 468 Chapter 18 +([0-9])) : # no-op Do Nothing! ;; *) usage exit 1 ;; esac ###################################### # Check for an integer greater than zero if [ $1 -lt 1 ] then usage exit 1 fi ############################################ # Define and initialize files and variables here THISHOST=`hostname` # Hostname of this machine DATESTAMP=$(date +”%h%d:%Y:%T”) # Date/Time Stamp SEARCH_PATH=$(pwd) # Top-level directory to search (CURRENT DIR!) MEG_BYTES=$1 # Number of MB for file size trigger OUTFILE=”/tmp/largefiles.out” # Output user file cat /dev/null > $OUTFILE # Initialize to a null file HOLDFILE=”/tmp/temp_hold_file.out” # Temporary storage file cat /dev/null > $HOLDFILE # Initialize to a null file ############################################ # Prepare the Output File Header echo “\nSearching for Files Larger Than ${MEG_BYTES}Mb Starting in:” echo “\n==> $SEARCH_PATH” echo “\nPlease Standby for the Search Results ” echo “\nLarge Files Search Results:” >> $OUTFILE echo “\nHostname of Machine: $THISHOST” >> $OUTFILE echo “\nTop Level Directory of Search:” >> $OUTFILE echo “\n==> $SEARCH_PATH” >> $OUTFILE echo “\nDate/Time of Search: `date`” >> $OUTFILE echo “\nSearch Results Sorted by File Modification Time” >> $OUTFILE ############################################ Listing 18.1 findlarge.ksh shell script listing. (continues) Finding “Large” Files 469 # Search for files > $MEG_BYTES starting at the $SEARCH_PATH # find $SEARCH_PATH -type f -size +${MEG_BYTES}000000c \ -print > $HOLDFILE # How many files were found? if [ -s $HOLDFILE ] # File greater than zero bytes? then NUMBER_OF_FILES=`cat $HOLDFILE | wc -l` echo “\nNumber of Files Found: ==> $NUMBER_OF_FILES\n\n” >> $OUTFILE # Append to the end of the Output File ls -lt `cat $HOLDFILE` >> $OUTFILE # Display the Time Sorted Output File more $OUTFILE echo “\nThese Search Results are Stored in ==> $OUTFILE” echo “\nSearch Complete EXITING \n” else cat $OUTFILE # Show the header information! echo “\n\nNo Files were Found in the Search Path that” echo “are Larger than ${MEG_BYTES}Mb\n” echo “\n\t EXITING \n” fi rm -f $HOLDFILE # Remove the temp. file # End of the findlarge.ksh Script Listing 18.1 findlarge.ksh shell script listing. (continued) Let’s review the findlarge.ksh shell script in Listing 18.1 in a little more detail. We added two functions to our script. We always need a usage function, and in case CTRL-C is pressed we added a trap_exit function. The trap_exit function is executed by the trap for exit signals 1, 2, 3, and 15 and will display EXITING ON A TRAPPED SIGNAL before exiting with a return code of 2. The usage function is exe- cuted if any of our three previously discussed data tests fail and the script exits with a return code of 1, one, indicating a script usage error. In the next block of code we query the system for the hostname, date/time stamp, and the search path (the current directory!) for the find command. All of this system data is used in the file header for the $OUTFILE. For the search path we could have just 470 Chapter 18 used a dot to specify the current directory, but this short notation would result in a relative pathname in our report. The full pathname, which begins with a forward slash (/), provides much clearer information and results in an easier-to-read file report. To get the full pathnames for our report, we use the pwd command output assigned to the SEARCH_PATH variable. We define two files for processing the data. The $HOLDFILE holds the search results of the find command’s output. The $OUTFILE contains the header data, and the search results of the find command are appended to the end of the $OUTFILE file. If the $HOLDFILE is zero-sized, then the find command did not find any files larger than $MEG_BYTES, which is the value specified in $1 on the command line. If the $HOLDFILE is not empty, we count the lines in the file with the command NUMBER_OF_ LINES=`cat $HOLDFILE | wc -l`. Notice that we used back tics for command sub- stitution, `command`. This file count is displayed along with the report header informa- tion in our output file. The search data from the find command, stored in $HOLDFILE, consists of full pathnames of each file that has exceeded our limit. In the process of appending the $HOLDFILE data to our $OUTFILE, we do a long listing sorted by the modification time of each file. This long listing is produced using the ls -lt $(cat $HOLDFILE) command. A long listing is needed in the report so that we can see not only the modification date/time but also the file owner and group as well as the size of each file. All of the data in the $OUTFILE is displayed by using the more command so that we display the data one page at a time. The findlarge.ksh shell script is in action in Listing 18.2. Searching for Files Larger Than 1Mb starting in: ==> /scripts Please Standby for the Search Results Large Files Search Results: Hostname of Machine: yogi Top Level Directory of Search: ==> /scripts Date/Time of Search: Thu Nov 8 10:46:21 EST 2001 Search Results Sorted by File Modification Time: Number of Files Found: ==> 4 -rwxrwxrwx 1 root sys 3490332 Oct 25 10:03 /scripts/sling_shot621.tar Listing 18.2 findlarge.ksh shell script in action. (continues) Finding “Large” Files 471 -rwxrwxrwx 1 root sys 1280000 Aug 27 15:33 /scripts/sudo/sudo- 1.6.tar -rw-r r 1 root sys 46745600 Jul 27 09:48 /scripts/scripts.tar -rw-r r 1 root system 10065920 Apr 20 2001 /scripts/exe/exe_files.tar These Search Results are Stored in ==> /tmp/largefiles.out Search Complete EXITING Listing 18.2 findlarge.ksh shell script in action. (continued) The output in Listing 18.2 is a listing of the entire screen output, which is also the contents of the $OUTFILE. The user is informed of the trigger threshold for the search, the top-level directory for the search, the hostname of the machine, the date and time of the search, and the number of files found to exceed the threshold. The long listing of each file is displayed that has the file owner and group, the size of the file in bytes, the modification time, and the full path to the file. The long listing is very helpful in large shops with thousands of users! Other Options to Consider The findlarge.ksh shell script is simple and does all of the basics for the system reporting, but it can be improved and customized for your particular needs. I think you will be interested in the following ideas: 1. The first thing you probably noticed is that the script uses the current directory as the top-level directory for the search path. You may want to add a second command-line argument so that you can specify a search path other than the current directory. You could add this user-supplied search path as an option, and if a search path is omitted you use the current directory to start the search. This adds a little more flexibility to the shell script. 2. Each time we run the findlarge.ksh shell script, we overwrite the $OUTFILE. You may, however, want to keep a month’s worth of reports on the system. An easy way to keep one month of reports is to use the date command and extract the day of the month, and then add this value as a suffix to the $OUTFILE file name definition. The following command will work: OUTFILE=”/tmp/largefiles.out.$(date +%d)” Over time our script will result in filenames largefile.out.01 through largefiles.out.31. 472 Chapter 18 3. When searching large filesystems the search may take a very long time to com- plete. To give the user feedback that the search process is continuing you may want to add one of the progress indicators studied in Chapter 4. Two of the studied progress indicators would be appropriate, the rotating line and the series of dots. Look in Chapter 4 for details. 4. When we specify our search value we are just adding six zeros to the user- supplied integer value. But we are back to a basic question: Is one MB equal to 1,000,000 or 1,024,000? Because a System Administrator may not be the one reading the report, maybe a manager, I used the mathematical 1,000,000 and not the system-reported power-of-2 value. This is really a toss-up, so you make the decision on the value you want to use. The value is easy to change by doing a little math to multiply the user-supplied value by 1,024,000. 5. If you need to look for newly created files when a filesystem has just filled up, you can add the following command as a cross reference to find the true cause of the filesystem filling up: find $SEARCH_PATH -mtime 1 -print This command will find all files that have been modified, or created, in the last 24 hours. You can redirect this output to a file and do a cross-reference to dis- cover the files, and users, that actually caused the filesystem to fill up. Summary In this chapter we have shown how to search the system for large files and create a machine-specific report. As stated in the previous section, there are many ways to do the same task, and as always we have other options to consider. This chapter, along with filesystem monitoring in Chapter 5, can help keep filesystem surprises to a minimum. In the next chapter we are going to study techniques to capture a user’s keystrokes. Capturing keystrokes has many uses, from giving you an audit trail of all root access to keeping track of a problem contractor or user. I use this technique to keep an audit trail of all root access to the systems. I hope you gained some knowledge in this chap- ter, and I will see you in the next chapter! Finding “Large” Files 473 475 In most large shops there is a need, at least occasionally, to monitor a user’s actions. You may even want to audit the keystrokes of anyone with root access to the system or other administration type accounts, such as oracle. Contractors on site can pose a par- ticular security risk. Typically when a new application comes into the environment one or two contractors are on site for a period of time for installation, troubleshooting, and training personnel on the product. I always set up contractors in sudo (see Chapter 14 for more details on sudo) to access the new application account, after I change the pass- word. sudo tracks only the commands that were entered with a date/time stamp. The detail of the command output from stdout and stderr does not get logged so you do not have a complete audit trail of exactly what happened if a problem arises. To get around this dilemma you can track a user’s keystrokes from the time he or she accesses a user account until the time he or she exits the account, if you have the space for the log file. This little feat is accomplished using the script command. The idea is to use sudo to kick off a shell script that starts a script session. When the script session is running, all of the input and output on the terminal is captured in the log file. Of course, if the user goes into some menus or programs the log file gets a little hard to read, but we at least have an idea what happened. This monitoring is not done surrep- titiously because I always want everyone to know that the monitoring is taking place. When a script session starts, output from the script command informs the user that a session is running and gives the name of the session’s log file. We can also set up mon- Monitoring and Auditing User Key Strokes CHAPTER 19 itoring to take place from the time a user logs in until the user logs out. For this moni- toring we do not need sudo, but we do need to edit the $HOME/.profile or other login configuration file for the particular user. Syntax Using the script command is straightforward, but we want to do a few more things in the shell script. Giving a specific command prompt is one option. If you are auditing root access you need to have a timeout set so that after about five minutes (see the TMOUT environment variable) the shell times out and the root access ends. On a shell timeout, the session is terminated and the user is either logged out or presented with a command prompt, but we can control this behavior. We have many options for this set of shell scripts. You are going to need to set up sudo, super-user-do, on your machine. The full details for installing and configuring sudo are in Chapter 14. We want sudo to be configured with the names of each of the shell scripts that are used for this moni- toring effort, as well as the specific users that you will allow to execute them. We will get to these details later. The script command works by making a typescript of everything that appears on the terminal. The script command is followed by a filename that will contain the cap- tured typescript. If no filename is given the typescript is saved in the current directory in a file called typescript. For our scripting we will specify a filename to use. The script session ends when the forked shell is exited, which means that there are two exits required to completely log out of the system. The script command has the follow- ing syntax: script [filename] As the script session starts, notification is shown on the terminal and a time stamp is placed at the top of the file, indicating the start time of the session. Let’s look at a short script session as used on the command line in Listing 19.1. [root:yogi]@/# more /usr/local/logs/script/script_example.out Script command is started on Wed May 8 21:35:27 EDT 2002. [root:yogi]@/# cd /usr/spool/cron/crontabs [root:yogi]@/usr/spool/cron/crontabs# ls adm root sys uucp [root:yogi]@/usr/spool/cron/crontabs# ls -al total 13 drwxrwx 2 bin cron 512 Feb 10 21:36 . drwxr-xr-x 4 bin cron 512 Jul 26 2001 -rw-r r 1 adm cron 2027 Feb 10 21:36 adm -rw 1 root cron 1125 Feb 10 21:35 root -rw-r r 1 sys cron 864 Jul 26 2001 sys Listing 19.1 Command-line script session. 476 Chapter 19 -rw-r r 1 root cron 703 Jul 26 2001 uucp [root:yogi]@/usr/spool/cron/crontabs# cd / [root:yogi]@/usr/spool# ls -l total 12 drwxrwsrwt 2 daemon staff 512 Sep 17 2000 calendar drwxr-xr-x 4 bin cron 512 Jul 26 2001 cron drwxrwxr-x 7 lp lp 512 Mar 23 15:21 lp drwxrwxr-x 5 bin printq 512 May 01 20:32 lpd drwxrwxr-x 2 bin mail 512 May 06 17:36 mail drwxrwx 2 root system 512 May 06 17:36 mqueue drwxrwxr-x 2 bin printq 512 Apr 29 11:52 qdaemon drwxr-xr-x 2 root system 512 Jul 26 2001 rwho drwxrwsrwx 2 bin staff 512 Jul 26 2001 secretmail drwxr-xr-x 11 uucp uucp 512 Mar 13 20:43 uucp drwxrwxrwx 2 uucp uucp 512 Sep 08 2000 uucppublic drwxrwxr-x 2 root system 512 Apr 16 2001 writesrv [root:yogi]@/usr/spool# exit Script command is complete on Wed May 8 21:36:11 EDT 2002. [root:yogi]@/# Listing 19.1 Command-line script session. (continued) Notice that every keystroke is logged as well as all of the command output. At the beginning and end of the log file a script command time stamp is produced. These lines of text are also displayed on the screen as the script session starts and stops. These are the user notifications given as the monitoring starts and stops. Scripting the Solution There are three different situations in which you want to use this type of monitor- ing/auditing. In this first instance we have users that you want to monitor the entire session. In the next situation you want to monitor activity only when a user wants root access to the system. Our systems have direct, remote, and su root login disabled, so to gain root access the user must use sudo to switch to root using the broot script. The third script is a catch-all for other administrative user accounts that you want to audit. The first script is covering end-to-end monitoring with the script execution starting at login through the user’s $HOME/.profile. Before we actually start the script session, there are some options to consider. Because we are executing a shell script from the user’s .profile we need to ensure that the script is the last entry in the file. If you do not want the users to edit any .profile files, then you need to set the ownership of the file to root and set the user to read-only access. Monitoring and Auditing User Key Strokes 477 [...]... pdisk8 pdisk9 pdisk10 pdisk11 pdisk12 pdisk13 pdisk14 pdisk15 Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available Available 34- 08- 5B91-01-P 34- 08- 5B91-02-P 34- 08- 5B91-03-P 34- 08- 5B91-04-P 24- 08- 5B91-05-P 24- 08- 5B91-07-P 24- 08- 5B91-06-P 24- 08- 5B91- 08- P 24- 08- 5B91-09-P 24- 08- 5B91-10-P 24- 08- 5B91-11-P 24- 08- 5B91-12-P... mailx -s “$TS - $LOGNAME Audit Report” $LOG_MANAGER < ${LOGDIR}/${LOGFILE} ;; Listing 19.2 log_keystrokes.ksh shell script listing (continues) 481 482 Chapter 19 esac compress ${LOGDIR}/${LOGFILE} 2>/dev/null fi exit } # Set a trap trap ‘cleanup_exit’1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 26 ########################################################## ################ DEFINE VARIABLES HERE... a look at this shell script in Listing 19.5, and pay particular attention to the boldface type #!/bin/ksh # # SCRIPT: “Banybody” boracle - This time # # AUTHOR: Randy Michael # DATE: 05/ 08/ 2002 # REV: 1.0.P # PLATFOEM: Any Unix # # PURPOSE: This shell script is used to capture all “$EFF_USER” # access by capturing all of the terminal data in a log # file using the script command This shell script is... log_keystrokes.ksh # # AUTHOR: Randy Michael Listing 19.2 log_keystrokes.ksh shell script listing Monitoring and Auditing User Key Strokes # DATE: 05/ 08/ 2002 # REV: 1.0.P # PLATFOEM: Any Unix # # PURPOSE: This shell script is used to monitor a login session by # capturing all of the terminal data in a log file using # the script command This shell script name should be # the last entry in the user’s $HOME/.profile... this entry beginning with a “dot”, which means to execute the following file, as the last entry in the $HOME/.profile If you added execution of $HOME/ profile into the shell script you end up executing the log_keystrokes.ksh shell 485 486 Chapter 19 script recursively When you run the script like this you fill up the buffers and you get an error message similar to the following output: ksh: : 0403-059... KILL=/usr/bin/kill ORACLE_SU=/usr/bin/su - oracle TCPDUMP=/usr/sbin/tcpdump ERRPT=/usr/bin/errpt SVRMGRL=/oracle/product /8. 0.5/bin/svrmgrl # User privilege specification root ALL=(ALL) ALL ROOTADMIN LOCAL=BROOT NORMAL LOCAL=MNT,UMNT,EXP_FS Listing 19.4 Example /etc/sudoers file (continues) 487 488 Chapter 19 ADMIN LOCAL=BROOT,MNT,UMNT,KILL,ORACLE_SU,TCPDUMP,ERRPT: \ LOCAL=EXP_FS ORACLE LOCAL=SVRMGRL # Override... same type of shell that we used in the previous sections, but this time we will use sudo instead of a profile entry I call this script broot because it is a short name for “I want to be root” In this section let’s look at the shell script in Listing 19.3 and go through the details at the end #!/bin/ksh # # SCRIPT: broot # # AUTHOR: Randy Michael # DATE: 05/ 08/ 2002 # REV: 1.0.P # PLATFOEM: Any Unix # #... Listing 19.5 boracle shell script listing (continues) 489 490 Chapter 19 # accounts by just changing the EFF_USER variable # and the script name # # set -n # Uncomment to check syntax without any execution # set -x # Uncomment to debug this shell script # # ################# DEFINE EFFECTIVE USER ################## # This EFF_USER is the username you want to be to execute # a shell in An su command... script Refer to your sudo notes # # USAGE: sudo broot # # REV LIST: # # # set -n # Uncomment to check syntax without any execution # set -x # Uncomment to debug this shell script # Listing 19.3 broot shell script listing (continues) 483 484 Chapter 19 ############# DEFINE AUDIT LOG MANAGER ################### # # # # This user receives all of the audit logs by email This Log Manager can have a local... 34- 08- 5B91-02-P 34- 08- 5B91-03-P 34- 08- 5B91-04-P 24- 08- 5B91-05-P 24- 08- 5B91-07-P 24- 08- 5B91-06-P 24- 08- 5B91- 08- P 24- 08- 5B91-09-P 24- 08- 5B91-10-P 24- 08- 5B91-11-P 24- 08- 5B91-12-P 34- 08- 5B91-13-P 34- 08- 5B91-14-P 34- 08- 5B91-16-P 34- 08- 5B91-15-P SSA160 SSA160 SSA160 SSA160 SSA160 SSA160 SSA160 SSA160 SSA160 SSA160 SSA160 SSA160 SSA160 SSA160 SSA160 SSA160 Physical Physical Physical Physical Physical Physical . Randy Michael Listing 19.2 log_keystrokes.ksh shell script listing. 480 Chapter 19 # DATE: 05/ 08/ 2002 # REV: 1.0.P # PLATFOEM: Any Unix # # PURPOSE: This shell script is used to monitor a login session. End of the findlarge.ksh Script Listing 18. 1 findlarge.ksh shell script listing. (continued) Let’s review the findlarge.ksh shell script in Listing 18. 1 in a little more detail. We added two. 1 fi ###################################### # Check for an integer case $1 in Listing 18. 1 findlarge.ksh shell script listing. (continued) 4 68 Chapter 18 +([0-9])) : # no-op Do Nothing! ;; *) usage exit 1 ;; esac ###################################### #