SNAPSHOT V1.2 June 1, 1984 Written by: Eric S. Zipp Technology Development of California 621 Six Flags Drive Arlington, Tx. 76011 (817) 461-1242 SYSTEM SNAPSHOT Page 1 1.0 SCOPE: ______ There always exists a problem with insuring the security of a processing system and the integrity of the data which is stored on that system. In most cases the responsibility fall on the shoulders of the System Manager to 'insure' that the System is not compromised in any way and even be aware if an attempt has been made to breach the security measures which have been put in place on that System. The problem is compounded when there often exists a need to give a number of users privileges, in support of job related activities, which allow them to circumvent most if not all system level checks and safeguards. SNAPSHOT attempts to act as a passive monitor of the VMS System and checks a number of 'areas of interest' on a regular basis, and reports when it notices that their has been a change since the last time a change was made to that 'area of interest'. 2.0 PROCESSING PHILOSOPHY __________ __________ The philosophy used is to interrogate some areas of VMS and generate a file with the results of that interrogation called SNAPxxx.OLD , where 'xxx' is some mnemonic which is indicative of what you have out there. The command file SNAPSHOT.COM, on my system, is run every night at midnight but its run interval is arbitrary. Each time SNAPSHOT is run is generates a 'current' SNAPxxx.OLD for each area of interest interrogated. The system utility DIFFERENCES is then run comparing the 'current' file against the 'previous' file. If there were no differences recorded, the 'current' SNAPxxx.OLD file is deleted. If, however, there were differences, a message is sent to SNAP$RECIPIENT, normally 'SYSTEM', via the MAIL utility with the SNAPxxx.DIF as the text of the message, where SNAPxxx.DIF is the output of the DIFFERENCES comparison along with a note at the bottom which tells you the creation date of both files. The 'previous' SNAPxxx.OLD file is then deleted and the 'current' file with the changes becomes the one to check against. The command file which does the checking and notifying is called SNAPCHECK.COM as is designed to compare two 'P1'.OLD files and as such can be used to check and 'new' areas of interest that need to be added to suit your system. 3.0 AREAS OF INTEREST _____ __ ________ A number of Areas within the VMS system are monitored to insure that a change has not be made by someone that should be dealt with. The processing philosophy is modular to allow additional areas to added based on individual needs. SYSTEM SNAPSHOT Page 2 3.1 INSTALLED IMAGES(PROGRAMS) VMS has a large number of installed images which in many cased require privileges to run. In addition 'privileged' users may 'install' programs on the system which even after the 'job related' privileges are removed, a program which they installed could give them whatever 'clout' they desire. As an attempt to identify when an installed image is added or modified, a full listing of all images which are installed on the system as well as what privileges they have are dumped to a file (SNAPINS.OLD). 3.2 SYMBOLS Since Symbols can be used to 're-direct' an operation to another, ie. if a symbol DIRECTORY was set up to preform the function PURGE. When the user asked for a directory listing he would receive something else. All the currently defined Symbols are dumped to a file (SNAPSYM.OLD). 3.3 LOGICAL NAMES Logical assignments are another area which can 're-direct' an operation so as a precaution all the currently defined logical names are dumped to a file (SNAPLOG.OLD). 3.4 DEVICE PROTECTION Each physical device on the system carries with it a access protection scheme which is used to control who has access to what. In order to monitor any changes in that area a list of all devices and their protection are dumped to a file (SNAPDEV.OLD). 3.5 SYSGEN PARAMETERS An obvious area is that of what Sysgen parameters are currently in effect. A full list of System parameter settings are dumped to a file (SNAPGEN.OLD) as well as the /CONFIGURATION and /ADAPTER output. SYSTEM SNAPSHOT Page 3 3.6 SYSUAF ENTRIES Since it would be possible to just be 'up front' and have the SYSUAF.DAT file modified, a dump of all the current SYSUAF entries is made to SNAPUAF.OLD. 3.7 SYSTEM/USER FILE ACCESS Within any system their are files which require controlled access. Setting the VMS file protection on them is fine unless it get changed after the fact. There exists a file called SNAPFIL.LST into which you the user can add any files you wish checked with your system. At present the degree of checking extends to making sure that the file exists and that the protection as well as the files 'revision' date, has not changes since the last 'authorized' change. The command file will read SNAPFIL.LST and create a file with the current file protection and rev-date called SNAPFIL.OLD. The only exception to this rule is the file SYS$SYSTEM:SYSUAF.DAT which, if checked, will not have the 'revision date' written to the SNAPFIL.OLD file. The reason for this is that any 'use' of the MAIL Utility will result in the SYSUAF file being updated which would result in SNAP$RECIPIENT getting a mail every time that SNAPSHOT is run. 3.8 LOG-FAIL ANALYSIS An obvious area to check for attempted entry to your system is the number of log fails which has occurred within a given 'check-interval'. On my system, I have it set up to run SNAPSHOT every night at midnight. The first time this module is run it will create an Index-sequential data file by the name SNAPLFAIL.DAT. This file will hold the date and time of the 'last' check made, as well as an entry for each User which has had log-fails. The procedure will access the current Accounting.dat file for any log-fails this 'check-interval' and write that information to a temporary holding file. The holding file is then accessed and the number of log-fails for a user is compared to the 'average' number of log-fails which is on file for that user. If the actual number of log-fails exceeds the average the User name and log-fail information is sent to the SNAP$RECIPIENT. In an effort to 'clean up' after itself, the procedure will also read all users which are in the SNAPLFAIL.DAT file and access the SYS$SYSTEM:SYSUAF.DAT file to see if they exist on the system. If not, that specific User record in SNAPLFAIL.DAT is removed. A word of caution should be added in that if, on your system, you 'close' your system accounting file and then start up a new version be sure that SNAPSHOT has a chance to run prior to switching over to the new version. SYSTEM SNAPSHOT Page 4 3.9 DECnet RELATED CHECKS DECnet is also an access within the System which should be monitored. At the present time this module is under development and is not ready for the cold cruel world. I would expect that it will make it's appearance in the not too distant future. 4.0 INSTALLATION INSTRUCTION ____________ ___________ o Copy the files into a directory or sub-directory that they will be run from. This location will also be the area that the SNAPxxx.OLD will live. o Define the logical name SYS$SNAP to point to the area that the Snapshot files live. This can be system wide or go into SNAPSHOT.COM as a local definition. o Define the logical name SNAP$RECIPIENT if you wish the MAIL output from SNAPSHOT to be directed to any account other than 'SYSTEM'. The default SNAP$RECIPIENT definition is 'SYSTEM'. o Add any additional file you wish to be monitored by adding the files in SNAPFIL.LST . o The SNAPSHOT system can be run manually or submitted via BATCH to run at some interval that you wish. 5.0 FEEDBACK ________ I would be interested to hear what 'additional' areas of interest or modification have been made to the SNAPSHOT package once it gets out in the world on it's own. To that end, please feel free to give me a call and share whatever you have found,... I shall do the same.