the Support Group inc Sponsor Message

More on Multi-CPU Security

By Shawn M. Gordon

Inside VESOFT covers tips and techniques you can use with VESOFT’s products, especially MPEX. As always, I am totally open to getting input from you users of MPEX, Security/3000 or VEAudit/3000 — it helps me learn, too. Send me your tricks, and we’ll get a “3000 for 2000” cap out to you as our thanks.

Last month we talked about using setting up multi-HP 3000 CPU security in a two-system environment using Security 3000. This month I’m going to extend my topic to covering any number of machines in a spoke and ring fashion.

The two-machine configuration described last month is actually a minimal version of a “ring” topology, where changes are passed from the first machine to the second, the second machine to the third, and so on until the last machine in the chain transmits data to the first machine.

For example, let’s rename last month’s system “KYLE” to system “KENNY” and add the new system “CARTMAN” to the chain. Using a ring analogy, the network now looks like this:

As you can see, you can put as many of these “nodes” between STAN and KENNY as you want. In actual practice, however, you are not likely to add more than a dozen nodes in this manner — especially since you will run out of names from South Park. After that point, it may be easier to define a star or wheel type network, in which one machine is considered the “hub” and all other machines are “spokes.” Changes made on any spoke are only sent to the hub, and the hub is then responsible for forwarding the changes to the other spokes. This is actually the method I prefer, since it plans ahead.

The reason this works is because you can specify more than one $NET-SEND in your SECURCON.DATA.VESOFT file to indicate that user profile change information should be transmitted to several computers. For example:

$SYS-NAME “HUB”
$NET-SEND STAN
$NET-SEND CARTMAN
$NET-SEND KENNY

Similarly, you can specify more than one $FROM-SYS in your hub’s NETRECV.DATA.VESOFT file, indicating that information should be received from several computers.

$FROM-SYS NODEA STAN
$FROM-SYS NODEE CARTMAN
$FROM-SYS NODEZ KENNY

If you have many machines, you might want to set up a pair of files in the group NETRECV.VESOFT that contains a list of machine names and DSLINE node names. You can then refer to these lists of machines in $NET-SEND and $FROM-SYS keywords. For example, you might build a file called SPOKENS.NETRECV.VESOFT (for SPOKE NameS) that contains the line: STAN CARTMAN KENNY
and then say in your SECURCON file

$NET-SEND ^SPOKENS.NETRECV.VESOFT

Then you build SPOKEDS.NETRECV.VESOFT (SPOKE DSlines) which contains:
NODEA NODEE NODEZ
and in your NETRECV.DATA.VESOFT file
$FROM-SYS ^SPOKEDS CHANGES

The file CHANGES.NETRECV (on the hub) would be used for ALL the nodes listed in SPOKEDS. Each “spoke” machine (STAN, CARTMAN and KENNY) should have $NET-SEND HUB in their SECURCON file and $FROM-SYS HUB in their NETRECV file. Therefore, a change on system STAN will be sent to the hub system, which in turn will be received from the hub by CARTMAN and KENNY.

Note that if your system names are the same as their DSLINE node names, then the same file can be used for both the SECURCON $NET-SEND and NETRECV $FROM-SYS keywords. Given how convoluted this can get, I strongly recommend keeping it as simple as possible and reusing the names.

When a user is changed, it usually wouldn’t make sense to transmit the entire user profile, including the terminal restrictions, time-of-day restrictions, day-of-week restrictions, and menu file. This is because these things are typically quite different on different systems. You’d almost certainly want to have different menu files on different systems; the terminals are configured as different LDEVs, and the normal working days and times might be different too.

So only the user name and password information (including password history, last change date, etc.) actually get sent from one system to another. Now, what if you want to impose terminal, time-of-day or day-of-week restrictions on users who might perhaps get automatically added as a result of an addition on another system? The $FORBID keyword lets you impose restrictions on entire usersets, not just individual user profiles, so in your SECURCON file you could say:

$FORBID “NOT BETWEEN(CLOCK,9AM,5PM)” “Bad time” @.AP

This will impose a time-of-day restriction on all the users in the AP account. These restrictions will be enforced even though the users won’t have specific time-of-day restrictions in their user profiles.

Pushing is another method of maintaining security profiles on multiple systems. Normally, a SECURITY user profile on system STAN gets moved to system KYLE by a NETRECV task running under the BACKG job on KYLE which keeps a remote session logged on to STAN.

What if you don’t want to keep this session permanently logged on? Security 3000 lets you indicate that data is to be “pushed” across the network, i.e., have the data transfer be done by the computer on which the changes were initially done rather than “pulled.” Let’s see how it’s done.

In the following discussion, “system STAN” is the system on which the SECURITY user profiles were changed; “system KYLE” is the system you wish to forward those changes to.

1) Instead of having a $FROM-SYS nodename sysname line in your NETRECV.DATA.VESOFT file on system KYLE, you should have a $FROM-SYS-PUSHED nodename sysname line. This tells the NETRECV task on KYLE that the data from STAN will be pushed by STAN, and doesn’t need to be pulled by KYLE.

2) There are two different ways that you can have system STAN push data to system KYLE: immediately or intermittently.

a) If you add to your NETRECV.DATA.VESOFT file on system STAN a line that says $PUSH-IMMEDIATE KYLE, the NETRECV task on STAN will do a :REMOTE HELLO to KYLE, transmit the change, and do a :REMOTE BYE every time a change is made on STAN.

b) If you add a line that says $PUSH-INTERMITTENT KYLE, the changes will only be pushed when you do a %SEC NETPUSH command (either online or using the NETPUSH task under the BACKG job). BACKG allows you to schedule the NETPUSH task to run once a day at a given time (1 AM, by default) so that it transmits all the changes to all the systems specified in the $PUSH-INTERMITTENT commands. If you find that you want to send the data to the other machines immediately, you can just do a %SEC NETPUSH online.

You will however need to keep the NETRECV task running on system KYLE; the main difference is it never logs onto system STAN. In addition, you must either run the NETRECV task on system STAN (for $PUSH-IMMEDIATE) or the NETPUSH task (for $PUSH-INTERMITTENT) to transmit the data to system KYLE. (A third alternative is to manually issue a %SEC NETPUSH command, which is what the NETPUSH task does once a day.) The NETRECV task on system KYLE then updates the SECURITY user profile.

Large network model

The large network model is much more complex. Imagine a network of systems scattered across the country. Using X.25, each one can connect with every other one, but they shouldn’t be continually connected. Instead, what we will do is have each system dial in to a “master” or “hub” system every time a profile is changed. Then, once a night, the “hub” will send all of the changes made to it during the day to each of the “slave” or “spoke” systems.

Using this plan, the “hub” will always have the current SECURITY configuration of all of the “spokes,” and each “spoke” will be updated with changes from all the other “spokes” at the end of the day. A user who changes his password on a “spoke” will be able to use his new password on the “hub” virtually immediately, and on other “spokes” starting tomorrow.

This is going to be a little confusing, so do your best to follow along:

A) On system HUB, add the following:

Filename: SECURCON.DATA.VESOFT
$SYS-NAME “HUB”
$NET-SEND ^SPOKELST.NETRECV.VESOFT
Filename: SPOKELST.NETRECV.VESOFT
SPOKE01
SPOKE02
...
Filename: NETRECV.DATA.VESOFT
$PUSH-INTERMITTENT SPOKE01
$PUSH-INTERMITTENT SPOKE02
...
$FROM-SYS-PUSHED ^SPOKELST SPOKECON
Filename: SPOKECON.NETRECV.VESOFT
$RECEIVE @ !HPJOBNAME,!HPUSER.!HPACCOUNT @,@.@

B) On each SPOKE system (SPOKE01, SPOKE02, ...), add the following:

Filename: SECURCON.DATA.VESOFT
$SYS-NAME “SPOKE01”
$NET-SEND HUB
Filename: NETRECV.DATA.VESOFT
$PUSH-IMMEDIATE HUB
$FROM-SYS-PUSHED HUB HUB
Filename: HUB.NETRECV.VESOFT
$RECEIVE @ !HPJOBNAME,!HPUSER.!HPACCOUNT @,@.@

C) On all systems (HUB and SPOKEs),

%SEC BACKG STARTJOB (If it’s not already running )
%SEC BACKG START,NETRECV

D) On system HUB only:

%SEC BACKG START,NETPUSH

The NETRECV task on the HUB merely waits for a SPOKE to send a change, which it then posts to the SECURITY user profiles on the HUB.

The NETRECV task on each SPOKE does two things. It sends changes to the HUB throughout the day (by logging onto the HUB, sending the change, and then logging off). At night, when NETPUSH on the HUB sends the changes to the spokes, NETRECV on each spoke posts the changes to the SECURITY user profiles.

Now, if you haven’t slipped into a coma reading all that, you are certainly now a master at network security.

Shawn Gordon, whose S.M. Gordon & Associates firm supplies HP 3000 utilities, has worked with 3000s since 1983.