Network objects are system programs and user-written
applications that permit communication among nodes in a DECnet network.
You need to identify the set of network objects allowed access to
your system, and set up the appropriate access controls for each object.
The following mechanisms are available:
DECnet object accounts
These are individual accounts for specific network
objects (for example, MAIL) automatically configured on your system.
These provide more accountability of remote access to an object than
the default DECnet account provides. (For example, an object can have
a captive account with a login command procedure that grants or denies
access to the object based on the remote node name or user name.)
Default DECnet account
This type of account allows all network objects
general access to the system. It is appropriate for systems with low
security requirements (for example, a local area network of systems
located within a site with no outside connections or dialup lines).
The default DECnet user name lets users perform
certain network operations, such as the exchange of electronic mail
between users on different nodes, without having to supply a user
name and password. The default DECnet user name is also used for file
operations when access control information is not supplied. For example,
it lets remote users access local files on which the file protection
has been set to allow world access. If you do not want remote users
accessing your node,
do not create a default DECnet user name. See “Removing Default DECnet Access to the System” for
information about removing default DECnet accounts.
Summary of Network Objects |
|
You should understand the function of the network
objects supplied with the OpenVMS operating system before you determine
the access control to apply to them. This section provides a description
of the most common network objects.
FAL
The file access listener (FAL) is the remote file
access facility. FAL is an image that receives and processes remote
file access requests for files at the local node.
Use of general FAL access
is strongly discouraged. Open access allows general network
access to any files marked world-accessible. It also allows remote
users to create files in any directory with world write access.
Sites with high security requirements, or sites
where it is difficult to recognize all the intended users, should
not create a FAL account. To control which users gain access, these
sites may establish one or more proxy accounts for specific purposes
(see “Proxy Access Control”).
MAIL
MAIL is an image that provides personal mail services
for OpenVMS systems. In most cases, allow the MAIL object general
access to the system.
MIRROR
MIRROR is an image used for particular forms of
loopback testing. For example, MIRROR is run during the DECnet phase
of the UETP test package.
MOM
MOM is the Maintenance Operations Module. The
MOM image downline loads unattended systems, transferring a copy of
an operating system file image from an OpenVMS node to a target node.
The MOM object is established during a system installation.
NML
NML is the network management listener. Remote
users with access to NML can use NCP TELL commands to gather and report
network information from your DECnet databases.
PHONE
PHONE is an image that allows online conversations
with users on remote OpenVMS systems. Note that if you allow default
DECnet access to PHONE, anyone in the network can get a list of users
currently logged in to the local system and attempt a login using
the list of user names.
TASK
Through the default DECnet account, the TASK object
allows arbitrary command procedures (including those that might be
used in intrusions) to be executed on your system.
Note that if you do not allow default DECnet access
on your system or if you disable default DECnet access to the TASK
object, you can allow remote user-written command procedures (tasks)
to run on your system through the use of access control strings or
proxy access.
VPM
VPM is the Virtual Performance Monitor Server.
Access to VPM is required to use the cluster monitoring features of
the Monitor utility (MONITOR).
Configuring Network Objects Manually |
|
The command procedure NETCONFIG.COM configures
the network objects on your system automatically, and the command
procedure NETCONFIG_UPDATE.COM updates the network objects automatically.
If you choose not to use the command procedures,
you can perform the following steps to allow network access to specific
objects:
Create a top-level directory
for each network object, and specify a unique owner UIC and group
UIC. For example, the following command sequence creates a top-level
directory for the MAIL object on the system disk:
$SET DEFAULT SYS$SPECIFIC:[000000]
$CREATE/DIRECTORY [MAIL$SERVER]/OWNER_UIC=[376,374]
|
“Network Object Defaults” lists the directory names, user names,
and UICs used by the NETCONFIG.COM and NETCONFIG_UPDATE.COM command
procedures to create accounts for specific network accounts. For consistency,
you should specify the same information when manually creating network
object accounts.
Note that the MOM object is created by the operating
system during installation.
Using AUTHORIZE, create
an account for the object, and use a generated password. (Note that
the user name and password that you specify must match the password
defined for the object in the network database [described in step
3].)
For example, the following command sequence sets up
an account for the MAIL object:
$RUN SYS$SYSTEM:AUTHORIZE
UAF>ADD MAIL$SERVER/OWNER=MAIL$SERVER DEFAULT -
_UAF>/PASSWORD=MDU1294B/UIC=[376,374]/ACCOUNT=DECNET -
_UAF>/DEVICE=SYS$SPECIFIC: /DIRECTORY=[MAIL$SERVER] -
_UAF>/PRIVILEGE=(TMPMBX,NETMBX) /DEFPRIVILEGE=(TMPMBX,NETMBX) -
_UAF>/FLAGS=(RESTRICTED,NODISUSER,NOCAPTIVE) /LGICMD=NL: -
_UAF>/NOBATCH /NOINTERACTIVE
|
The AUTHORIZE command SHOW MAIL$SERVER displays
the network account set up for the MAIL object, as shown in “UAF Record for MAIL$SERVER Account”.
Use the NCP DEFINE command
to associate the user name and password of the account with the specified
object in the network database, as follows:
$RUN SYS$SYSTEM:NCP
NCP>DEFINE OBJECT MAIL USER MAIL$SERVER PASSWORD MDU1294B
NCP>EXIT
|
Repeat steps 1 through
3 for each network object.
When finished, remove
default DECnet access from the executor database, and remove the default
DECnet account from the SYSUAF (see “Removing Default DECnet Access to the System” ).
Finally, reboot the system
to copy changes made to the permanent executor and object databases
to the running system.
“Network Object Defaults” lists the network object defaults.
Table 13-2 Network Object Defaults
Object Name | Directory and User (Account) Name | UIC |
---|
FAL | FAL$SERVER | [376,373] |
MAIL | MAIL$SERVER | [376,374] |
MIRROR | MIRRO$SERVER[1] | [376,367] |
$MOM | VMS$COMMON:[MOM$SYSTEM][2] | [376,375] |
NML | NML$SERVER | [376,371] |
PHONE | PHONE$SERVER | [376,372] |
VPM | VPM$SERVER | [376,370] |
Example 13-2 UAF Record for MAIL$SERVER Account
|
Username: MAIL$SERVER Owner: MAIL$SERVER
Account: MAIL$SERVER DEFAULT UIC: [376,374] ([DECNET,MAIL$SERVER])
CLI: DCL Tables:
Default: SYS$SPECIFIC:[MAIL$SERVER]
LGICMD:
Login Flags: Restricted
Primary days: Mon Tue Wed Thu Fri Sat Sun
Secondary days:
Primary 000000000011111111112222 Secondary 000000000011111111112222
Day Hours 012345678901234567890123 Day Hours 012345678901234567890123
Network: ##### Full access ###### ##### Full access ######
Batch: ----- No access ------ ----- No access ------
Local: ----- No access ------ ----- No access ------
Dialup: ----- No access ------ ----- No access ------
Remote: ----- No access ------ ----- No access ------
Expiration: (none) Pwdminimum: 6 Login Fails: 0
Pwdlifetime: (none) Pwdchange: (none)
Last Login: (none) (interactive), (none) (non-interactive)
Maxjobs: 0 Fillm: 16 Bytlm: 12480
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 12 JTquota: 1024
Prclm: 0 DIOlm: 6 WSdef: 180
Prio: 4 ASTlm: 16 WSquo: 200
Queprio: 0 TQElm: 10 WSextent: 0
CPU: (none) Enqlm: 20 Pgflquo: 25600
Authorized Privileges:
TMPMBX NETMBX
Default Privileges:
TMPMBX NETMBX
|
|
Removing Default DECnet Access to the System |
|
The default DECnet account is appropriate for
systems with low security requirements (see “Using DECnet Application (Object) Accounts”). If your site has moderate or high security requirements, you
should remove default DECnet access to the system once you have set
up accounts for individual network objects.
|
| |
|
| CAUTION: Before deleting your default DECNET account, as
described in this section, use the NCP command SHOW KNOWN OBJECTS
and the Authorize utility (AUTHORIZE) to verify that all network objects
and layered products that use network objects have network accounts
set up in the system user authorization file (SYSUAF.DAT). Otherwise,
network objects and layered products that use network objects may
not work as expected. |
|
| |
|
To do this, remove access to the DECNET account
in the network configuration database, and delete the DECNET account
from the SYSUAF.
Removing Default DECnet Access
Execute the following NCP commands to remove the
default DECnet access from the network executor database:
NCP>DEFINE EXECUTOR NONPRIVILEGED USER DEFAULT_DECNET
NCP>PURGE EXECUTOR NONPRIVILEGED PASSWORD
|
The DEFAULT_DECNET user specified in the first
command is a nonexistent user account that is specified for auditing
purposes only. (A network login failure message is written to the
security audit log file each time access to your system is attempted
through the [nonexistent] DEFAULT_DECNET account.)
Deleting the DECNET Account
Using AUTHORIZE, remove the DECNET account from
SYSUAF, as follows:
$SET DEFAULT SYS$SYSTEM
$RUN AUTHORIZE
UAF>REMOVE DECNET
UAF>EXIT
|
Delete any files in the [DECNET] directory structure.
Modifying the Volatile Configuration Database
To have the change take effect immediately, modify
the volatile database with the following NCP commands:
NCP>SET EXECUTOR NONPRIVILEGED USER DEFAULT_DECNET
NCP>CLEAR EXECUTOR NONPRIVILEGED PASSWORD
|
Setting Privilege Requirements for Remote Object Connections |
|
You can select specific privileges to control
the use of DECnet objects that are specified during network configuration.
In such instances, it becomes a privileged operation either to connect
to a privileged DECnet object or use an outgoing DECnet object.
For example, the following command establishes
the requirement that users initiating a DECnet connection to the remote
object MAIL must possess the OPER and SYSNAM privileges:
NCP>DEFINE OBJECT MAIL OUTGOING CONNECT PRIVILEGES OPER,SYSNAM
|
This mechanism is a useful way of limiting access
to certain DECnet applications to privileged users or programs. However,
to be effective, the privilege requirement must be imposed consistently
on all nodes in the network.