From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 26-FEB-1994 15:33:12.31 To: EVERHART CC: Subj: Thoughts On Eliminating Security OPCOM's Within VCS ENS Subsystem... Date: Sun, 20 Feb 1994 0:11:15 -0500 (EST) From: "Clayton, Paul D." To: dwd@genrad.com Cc: INFO-VAX@SRI.COM, CLAYTON@radium.xrt.upenn.edu Message-Id: <940220001115.41e00102@radium.xrt.upenn.edu> Subject: Thoughts On Eliminating Security OPCOM's Within VCS ENS Subsystem... Derek @ "dwd@genrad.com" has a problem with the VCS 1.4 ENS window scrolling poorly when audit server messages are generated in large quick groups. Too many messages to scroll to fast results in poor, if any window contents. We had this same problem on our VCS platforms due to the significant amount of security OPCOMs that were generated as a result of the security oversight groups on the program. Their policy at the time was give me everything and let me weed it out. It has since gone through several more iterations and we are now at a 'respectable' level of auditing. I started looking into this for many reasons. The VCS system was being swamped by security OPCOM messages. The DS90TL's were hanging ports on us from time to time. CSC's position on VCS console line speed is that everything works fine at 2400 baud. I did NOT want to run 2400 baud. We have 6610's clocking 9600 baud console lines and even this is to slow. Nothing like a screaming CPU to start heading south and you find out about it minutes later due to slow OPCOM delivery. So, what I found was that the base VCS 1.4 system has the event LOGIN_001 defined with the text match string being 'USERNAME:'. This event no doubt was to record that 'someone' logged into the node being monitored on the console line. And since the console line has 'special options' (such as control-P), knowing who uses the line and when DOES come in handy when its 'time to find the guilty party'. ;^) The HASSLE is that most all security OPCOM messages ALSO have the string 'USERNAME:' somewhere in them so that you as security officier know who is doing what. Based on this there are several options. 1. The OPA0 port can be DISABLED for receiving security OPCOM messages. We have eventually ended up here. The 'best' means I have found to do this is with the OPC$xxx logicals that OPCOM uses on startup. There are examples in SYS$MANAGER:SYLOGICALS.COM. We also ended up using these logicals to stop security messages in the OPERATOR.LOG file as well. The comments in this file are well written and easy to follow. 2. Delete the LOGIN_001 VCS event definition from the configuration file. We did not like this due to the help it provides when seeing what went wrong with a node based on the nodes events. Having to examine the full console text just to see when someone logged in and what username can be very combersome when there is a lot of activity on the consoles. This option was not considered in our case. 3. Remembering that the security OPCOM's are the one which also has the 'USERNAME:' string in them, I examined the option of PATCHing the appropriate .EXE image files in VMS to have the string show up as 'something else'. I got some pointers from the support group for a VMS 6.0 field test we were doing at the same time and ended up scrapping this option as well due to how many times the 'USERNAME:' string was defined in the various images. Have at this option if you like real challenges. 4. The REAL 'USERNAME:' string I wanted VCS to key off of was part of the login sequence and as such under the control of SYS$SYSTEM:LOGINOUT.EXE. A DUMP/BLOCK/OUT=file of LOGINOUT.EXE showed that the 'USERNAME:' string was defined in ONLY ONE place in this image! Now I needed to make this string unique so that the VCS event could be changed to match it and not end up reporting other cases as well. I settled on changing 'USERNAME:' to 'USERNAME;'. The difference being ';' instead of ':'. A little bit of time re-reading the PATCH utility manual for VMS and poking around the image finding the 'right offset' and presto, 'USERNAME:' was NOW 'USERNAME;'. I have attached the command file I created to do this change on a VMS 5.5-2 system at the end of this message. Note that this change MUST be done to the LOGINOUT.EXE image on the systems BEING MONITORED by the VCS platform. NOT the VCS platform itself, although there is nothing wrong with implementing the change on the VCS system. I have been wondering about 'looping' the VCS platform OPCOM messages 'back into the VCS software' so that I can monitor the VCS node as well. Have not gotten this one worked out as yet. After executing the patch file, you can either do an INSTALL/REPLACE command or reboot the node so that the new/patched LOGINOUT.EXE image is what is used by the system. There must be a corresponding change to the VCS event definition for LOGIN_001 so that the 'USERNAME;' string is now being searched for. This can be done with the command: VCS_EDIT> modify event/text="USERNAME;" login_001 VCS_EDIT> exit $ vcs reconfigure !make new defintion current in system With the change done this way, we have been able to drastically reduce the ENS window scoll 'shakes/shivers' regardless of the OPCOMs being received from the monitored nodes. This includes the times when an operator logs into OPA0 and does a REPLY/ENABLE and all of a sudden you are once again swamped with security OPCOM messages. Your VCS log files will grow like crazy, and the VCS performance may end up in the pits, but the ENS event logs will not be impacted anymore. There are several other items to note here. 1. If you re-install VMS, or install a CSC patch kit that replaces LOGINOUT.EXE, this patch kit will need to be re-installed and the node rebooted or a INSTALL/REPLACE done again. 2. WARNING to all VCS sites that use Phase II disk shadowing (HBVS) OR run VMS 6.0 on nodes MONITORED by a VCS platform. For the pre- 6.0 sites, there is a CSC patch kit for HBVS (CSCPAT_0269nnn). This patch kit has as part of it a NEW EXCEPTION.EXE image for placement in SYS$LOADABLE_IMAGES directory. This image for VMS 5.5-2 contains the BUGCHECK message strings from VMS 6.0. And the PROBLEM is that SOMEONE involved with VMS 6.0 development decided that having bugcheck messages in ALL UPPERCASE did not 'look nice and pleasing to the eye'. So having nothing better to do with their time, they MODIFIED the bugcheck strings to be MIXED CASE! Now this might not appear to be all that much of a big deal. It wouldn't if you did not RELY on a VCS platform to tell you what was going on. For those of us who DO RELY on VCS systems, we GOT HOSED! BIG TIME! The VCS software does an EXACT (including case) MATCH between the console text being received and the /TEXT="..." strings defined for the VCS events you are interested in. We installed the latest 269 patch kit and stopped getting bugcheck messages. After missing a rather severe one that others noticed and I didn't even whisper about, we ended up searching around as to why the VCS platforms were no longer triggering on bugchecks and what had caused this change in behaviour. That's when the 269 patch kit EXCEPTION.EXE problem came to light. If there is interest, I can post a procedure to make the needed VCS event changes so that you once again get notified when a node bugchecks and other things. Bugchecks were not the only messages changed. That's all for now. Have fun... pdc ---------- The following I placed into the file: loginout_c2_vcs_patch.com $! $!There is a 'nuisance problem' which deals with the following componets. $! $! - SYS$SYSTEM:LOGINOUT.EXE $! - C2 audit server, and its reporting of events $! - VCS software monitoring events on OPA0 ports $! $!The 'problem' is that the VCS software has an event of 'LOGIN' which is $!defined to look for the string 'Username:' and in the event it finds a match, $!to signal an event. The VCS software is triggering this event INCORRECTLY when $!any action is taken which causes the C2 audit server to report an event. $!Within the text of the events, the string 'Username:' appears. Such as in the $!following example: $! $!%%%%%%%%%%% OPCOM 16-FEB-1993 23:34:01.13 %%%%%%%%%%% $!Message from user AUDIT$SERVER on nnnnn $!Security alarm (SECURITY) and security audit (SECURITY) on nnnn, system id:mm $!Auditable event: Remote interactive login failure $!Event time: 16-FEB-1993 23:34:01.10 $!PID: 2920043B $!Username: $!Terminal name: _RTA3: $!Remote nodename: nnnn Remote node id: mmmm $!Remote username: SYSTEM $!Status: %LOGIN-F-NOSUCHUSER, no such user $! $! $!I placed a message to the VMS 6.0 field test group to see what it would $!take to change the audit server to change the text of 'Username:' to something $!else. The answer came back that there are a number of places in the file, $!SYS$LIBRARY:VMS$FORMAT_AUDIT_SYSTEM.EXE which would need to be changed. $!Probably close to 2 dozen places need to change. $! $!I have also looked at the image, SYS$SYSTEM:LOGINOUT.EXE for the 'Username:' $!text and found it in only one spot. $! $!I have since run a test by changing the 'Username:' text in LOGINOUT.EXE to be $!'Username;' (semicolon instead of colon). Then did a INSTALL REPLACE command $!on this new version of LOGINOUT. The prompt now comes up with 'Username;'. $! $!This would then need only one change to the VCS platform for the VCS event $!text match to be changed from 'Username:' to 'Username;'. $! $!So with only two changes, we get the change we are looking for. $! $!I have chosen the later method to implement this change. $! $!As a result, the following changes have been implemented. $! $!The image, SYS$COMMON:LOGINOUT.EXE, has been patched using the PATCH utility $!in ABSOLUTE mode with the following command stream. $! $! This patch kit file for VMS 5.5-2 ONLY $! Paul D. Clayton / USA - 2/27/93 $! $save_dir = f$directory() $set default sys$common:[sysexe] $patch/absolute sys$common:[sysexe]loginout.exe replace/byte 9295 3a exit 3b exit update exit $! $set protection=wo:re sys$common:[sysexe]loginout.exe;* !enable access $exit The VCS event definition to be modified is: Event: LOGIN_001 Abbreviation = Login Information = Attempt login at console terminal Text = Username: Start = 2 Count = 5 Priority = 10