This chapter describes how to configure MultiNet services. The chapter provides specific information about configuring the RLOGIN, RSHELL, NTY, TFTP, and SYSLOG services. The remaining chapters in this guide provide specifics about configuring other services.
MultiNet services require basic IP connectivity on your system for the services to function properly. Read Chapter 11 to learn how to establish IP connectivity.
For a list of the servers you can configure with SERVER-CONFIG, see Appendix A.
When configured, MultiNet services start when a request for service is accepted by the master server (MULTINET_SERVER) process, which listens for incoming connections. When a connection request is received, either a separate, detached process is created to handle the connection, or the MULTINET_SERVER process handles the service internally.
Configuration information for the master server is in the configuration file MULTINET:SERVICES.MASTER_SERVER which is read by the MULTINET_SERVER process when it starts to determine its configuration.
When MultiNet is first installed, the normal set of services is enabled. Before starting MultiNet, you may want to verify that the server configuration meets your needs. This may require:
• Disabling servers your site does not want accessed
• Enabling servers your site wants accessed
• Adding servers specific to your site
The server configuration supplied with MultiNet is adequate to get a system up and running. The server configuration can be easily changed as needed.
Generally, services are configured with one of the following configuration utilities:
• SERVER-CONFIG, invoked with the MULTINET CONFIGURE /SERVERS command
• MENU-CONFIG, invoked with the MULTINET CONFIGURE /MENU command
This chapter describes how to use these utilities and provides information about other MultiNet servers.
The MultiNet command line-based server configuration utility (SERVER-CONFIG) is an interactive utility that controls which network servers are available on the local node. In addition, you can use SERVER-CONFIG to set restrictions on a server to prevent access from unauthorized sites, to keep a log file of connections to a server, and to limit the system resources available to a server.
To invoke SERVER-CONFIG, enter this command:
$ MULTINET CONFIGURE /SERVERS
Exit this utility with the EXIT or QUIT command.
To display the list of servers available under MultiNet, run SERVER-CONFIG, and issue the SHOW command. You can use the SHOW /FULL command to display the characteristics of a particular server. To change the default configuration, enable a server with the ENABLE command and modify server configuration parameters with the SELECT and SET commands.
In the following example, SERVER-CONFIG enables the TFTP server (which is disabled by default) displays the TFTP server's configuration, and restarts the MULTINET_SERVER process so the changes take effect immediately.
$ MULTINET CONFIGURE /SERVERS
MultiNet Server Configuration Utility 5.0(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>ENABLE TFTP
SERVER-CONFIG>SHOW TFTP/full
Service "TFTP":
UDP socket (AF_INET,SOCK_DGRAM), Port 69
INIT() = Merge_Image
Program = "MULTINET:LOADABLE_TFTP.EXE"
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first?[YES]<Return>
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]
SERVICES.MASTER_SERVER]
%RUN-S-PROC_ID, identification of created process is 20600046
SERVER-CONFIG>EXIT
[Configuration not modified, so no update needed]
$
Table 12-1 lists the SERVER-CONFIG commands.
Before using a SET command, use the SELECT command to select a service.
Table 12-1 SERVER-CONFIG Commands
|
Command |
Description |
|
ADD |
Adds a service to the configuration |
|
ATTACH |
Detaches a terminal from calling process and attaches it to another process |
|
COPY |
Copies a service to create a new service |
|
DELETE |
Deletes a service from the current configuration |
|
DISABLE |
Disables a service in the current configuration |
|
ENABLE |
Enables a service in the current configuration |
|
EXIT |
Exits from the SERVER-CONFIG session |
|
GET |
Reads in a server configuration file |
|
NETCONTROL |
Contacts the NETCONTROL server |
|
PUSH |
Accesses the DCL command line while pausing SERVER-CONFIG |
|
QUIT |
Exits SERVER-CONFIG without saving changes |
|
RESTART |
Restarts the master server process |
|
SAVE |
Writes out the current server configuration file |
|
SELECT |
Selects a server for SET command |
|
SET ACCEPT-HOSTS |
Specifies hosts that can access the server |
|
SET ACCEPT-NETS |
Specifies networks that can access the server |
|
SET BACKLOG |
Specifies server connection queue limits |
|
SET CONNECTED |
Specifies a connection-request-received routine |
|
SET DISABLED-NODES |
Specifies VMScluster nodes on which the service is disabled |
|
SET ENABLED-NODES |
Specifies VMScluster nodes on which the service is enabled |
|
SET FLAGS |
Specifies a flag bit mask for service operation control |
|
SET INIT |
Specifies an initialize-service routine |
|
SET KEEPALIVE-TIMERS |
Specifies probes for cleaning up dormant connections |
|
SET LISTEN |
Specifies a listen-for-connections routine |
|
SET LOG-ACCEPTS |
Enables/disables successful connections logging |
|
SET LOG-FILE |
Specifies a log message destination |
|
SET LOG-REJECTS |
Enables/disables failed connections logging |
|
SET MAX-SERVERS |
Specifies the maximum number of processes |
|
SET PARAMETERS |
Specifies service-dependent parameters; affects the current configuration and becomes active the next time MULTINET_SERVER starts |
|
SET PQL-ASTLM [ PQL stands for process quota limits.] |
Specifies the OpenVMS AST (asynchronous system trap) limit (the number of pending ASTs available to a process) |
|
SET PQL-BIOLMa |
Specifies the OpenVMS buffered I/O limit (the number of outstanding buffered I/O requests available to a process) |
|
SET PQL-BYTLMa |
Specifies the OpenVMS buffered I/O byte count limit (the number of bytes allowed in any single buffered I/O request) |
|
SET PQL-CPULMa |
Specifies the OpenVMS CPU time limit of the created process |
|
SET PQL-DIOLMa |
Specifies the OpenVMS direct I/O limit (the number of outstanding direct I/O requests available to a process) |
|
SET PQL-ENQLMa |
Specifies the OpenVMS enqueue limit of the created process |
|
SET PQL-FILLMa |
Specifies the OpenVMS open file limit (the number of open files available to a process) |
|
SET PQL-JTQUOTAa |
Specifies the OpenVMS job-wide logical name table byte quota (the quota allocated to the job-wide logical name table on its creation) |
|
SET PQL-PGFLQUOTAa |
Specifies the OpenVMS paging file quota of the created process |
|
SET PQL-PRCLMa |
Specifies the OpenVMS sub-process limit (the number of sub-processes available to a process) |
|
SET PQL-TQELM |
Specifies the OpenVMS timer queue entry limit (the number of timer queue entries available to a process) |
|
SET PRIORITY |
Specifies the OpenVMS priority for created processes |
|
SET PROGRAM |
Specifies an OpenVMS file name for run or merged images |
|
SET RECEIVE-BUFFER-SIZE |
Specifies the size of receive socket buffer |
|
SET REJECT-BY-DEFAULT |
Specifies what happens if no match is found on SET ACCEPT-HOSTS and SET REJECT-HOSTS, and on SET ACCEPT-NETS and SET REJECT-NETS |
|
SET REJECT-HOSTS |
Specifies hosts not allowed service access |
|
SET REJECT-MESSAGE |
Specifies a rejected connection message |
|
SET REJECT-NETS |
Specifies networks not allowed service access |
|
SET SEND-BUFFER-SIZE |
Specifies the size of the send socket buffer |
|
SET SERVICE |
Specifies a perform-service routine |
|
SET SERVICE-NAME |
Changes a service name. The underscore character can be used in the service name. |
|
SET SOCKET-FAMILY |
Specifies service family address |
|
SET SOCKET-OPTIONS |
Specifies setsockopt( ) options |
|
SET SOCKET-PORT |
Specifies the port for connection listening |
|
SET SOCKET-TYPE |
Specifies the socket type |
|
SET USERNAME |
Specifies the name of the user under which the service is started; applies only to UCX services. A UCX service has the UCX_SERVER flag set |
|
SET WORKING-SET-EXTENT |
Specifies the OpenVMS working set extent of the created process |
|
SET WORKING-SET-QUOTA |
Specifies the OpenVMS working set quota of the created process |
|
SHOW |
Shows the current server configuration |
|
SHUTDOWN |
Stops the master server process |
|
SPAWN |
Executes a DCL command, or mimics PUSH |
|
STATUS |
Shows the SERVER-CONFIG status |
|
USE |
Reads in a server configuration file |
|
VERSION |
Shows the SERVER-CONFIG version |
|
WRITE |
Writes out the current server configuration file |
When you run SERVER-CONFIG commands, a number of prompts are displayed. These prompts are explained in Appendix A. There are a number of per-service prompts when you modify server parameters. Some of these parameters control the operation of the server, including process priority, working set limit, restrictions, and auditing. Other parameters define operations of the server, such as the protocol and port number.
For each SERVER-CONFIG command, there is a corresponding command or parameter field you can modify using MENU-CONFIG. For basic information about MENU-CONFIG, see Chapter 9.
To access the service configuration parameters through MENU-CONFIG:
1 Start MENU-CONFIG with the MULTINET CONFIGURE /MENU command.
2 Choose Configure MultiNet Server from the main MultiNet Configuration menu.
3 To modify a service, choose View/Modify an Existing Service. When you do this, the Service Selection Menu appears.
4 Choose the service you want to configure. A Server menu appears for the service you chose.
5 To view the full list of service configuration commands, switch to Extended mode by pressing PF1. Each command allows you to view or modify specific types of service parameters.
6 Select the desired set of service parameters and modify the parameter values as needed. Context-sensitive help describes each parameter as you select it.
7 When done, return to the Server menu by pressing Ctrl/Z.
8 If desired, configure other service parameters.
9 To return to the Services Configuration menu, press Ctrl/Z.
10 To put your changes into effect, choose Restart the MULTINET_SERVER Process. The master server restarts using the new service configuration.
11 Save or abandon your changes by choosing Save Changes and Return to Previous Menu or Abandon Changes and Return to Previous Menu, respectively.
The MULTINET_SERVER process can listen for user-written services (including IPX/SPX) and, when a connection request arrives, create an OpenVMS detached process running the user-written program. This process is created with full privileges. SYS$INPUT, SYS$OUTPUT, and SYS$ERROR are set to the network. See the MultiNet for OpenVMS Programmer's Reference for descriptions of library routines for writing your own services that interface to MultiNet.
The following example shows how to add a user-written service called NNTP to the MultiNet configuration. The program NNTP_SERVER.EXE is invoked when an NNTP connection arrives.
SERVER-CONFIG>ADD NNTP
[Adding new configuration entry for service "NNTP"]
Protocol: [TCP] TCP
TCP Port number: 119
Program to run: USER$DISK:[NNTP]NNTP_SERVER.EXE
[Added service NNTP to configuration]
[Selected service is now NNTP]
SERVER-CONFIG>
Note! If your service uses the getservbyname( ) or getservbyport( ) socket library functions, you must also add your service to the HOSTS.LOCAL file and recompile your host tables.
You can tailor the MULTINET_SERVER to meet your specific needs by enabling or disabling services using the ENABLE, DISABLE, or DELETE commands.
For example, to enable BOOTP service with the SERVER-CONFIG ENABLE BOOTP command and restart the server to make the change immediately available, issue these commands:
$ MULTINET CONFIGURE /SERVER
MultiNet Server Configuration Utility 5.0(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>ENABLE BOOTP
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first ? [YES] RETURN
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]
SERVICES.MASTER_SERVER]
%RUN-S-PROC_ID, identification of created process is 20600046
SERVER-CONFIG>EXIT
[Configuration not modified, so no update needed]
$
The following example shows how to disable the SMTP service:
SERVER-CONFIG>DISABLE SMTP
You can enable or disable services on a per-node basis in a VMScluster. Using the SET ENABLED-NODES or SET DISABLED-NODES commands, you can specify a list of VMScluster nodes on which the service does or does not run. You must also enable the service using the ENABLE command. For example, to enable the SMTP service to run only on the VMScluster node VMSA:
SERVER-CONFIG>SELECT SMTP
[The Selected SERVER entry is now SMTP]
SERVER-CONFIG>SET ENABLED-NODES
You can now add new VAXcluster nodes for SMTP.
An empty line terminates.
Add VAXcluster node: VMSA
Add VAXcluster node: RETURN
SERVER-CONFIG>
MultiNet allows a system manager to restrict access to services on a per-service, per-network, or per-host basis.
Note! Restriction lists are supported only for services that listen for connections through MULTINET_SERVER. For example, the NFS Server, which reads datagrams directly, ignores any restrictions configured through SERVER-CONFIG.
Five service parameters (ACCEPT-HOSTS, ACCEPT-NETS, REJECT-HOSTS, REJECT-NETS, and REJECT-BY-DEFAULT) control whether the MULTINET_SERVER process allows or rejects a connection request based on the requesting host address, network, or subnetwork.
• If the connection comes from a host listed in the ACCEPT-HOSTS or REJECT-HOSTS lists, the connection is accepted or rejected, respectively.
• If the host is not found in one of these lists, the ACCEPT-NETS and REJECT-NETS lists are examined.
• If a match is found, the connection is accepted or rejected.
• If the host does not match any of these four lists, the action taken is governed by the REJECT-BY-DEFAULT parameter, which is normally set to FALSE, indicating that all connections are accepted.
You can also use the ACCEPT-NETS and REJECT-NETS parameters to specify a subnetwork number. You specify a subnetwork by supplying the subnetwork number followed by a space and the subnetwork mask for that subnetwork. For example:
REJECT-NETS 128.1.1.0 255.255.255.0
rejects only the hosts on the 128.1.1.n network. All other hosts on 128.1.n.n have access.
Note! If you answer YES after the Internet address at the prompt, only connections from a port number below 1024 are accepted.
The action taken to reject a connection depends on the protocol involved; for example, a UDP datagram is rejected by ignoring it, but a TCP connection is rejected by immediately closing the connection.
The REJECT-MESSAGE parameter specifies a text string sent to the client before the connection is closed. The following example shows how to restrict access to the TELNET server to hosts that are on a local network at address 128.1.0.0, with the one exception of the host at the address 192.0.0.2.
$ MULTINET CONFIGURE/SERVERS
MultiNet Server Configuration Utility 5.0(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>SELECT TELNET
[The Selected SERVER entry is now TELNET]
SERVER-CONFIG>SET ACCEPT-NETS
You can now add new addresses for TELNET. An empty line terminates.
Add Address: 128.1.0.0
Add Address: RETURN
SERVER-CONFIG>SET ACCEPT-HOSTS
You can now add new addresses for TELNET. An empty line terminates.
Add Address: 192.0.0.2
Add Address: RETURN
SERVER-CONFIG>SET REJECT-BY-DEFAULT TRUE
SERVER-CONFIG>SET REJECT-MESSAGE Illegal source of TELNET connection
SERVER-CONFIG>SHOW/FULL
Service "TELNET":
TCP socket (AF_INET,SOCK_STREAM), Port 23
Socket Options = SO_KEEPALIVE
INIT() = TCP_Init
LISTEN() = TCP_Listen
CONNECTED() = TCP_Connected
SERVICE() = Internal_Telnet
Accept Hosts = IP-192.0.0.2
Accept Nets = IP-128.1.0.0
Reject by default all other hosts and nets
Reject Message = "Illegal source of TELNET connection"
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first ? [YES] YES
[Writing configuration to
MULTINET_COMMON_ROOT:[MULTINET]SERVICES.MASTER_SERVER]
%RUN-S-PROC_ID, identification of created process is 20600054
SERVER-CONFIG>
MultiNet allows the security-conscious system manager to audit access to a service, file, or the OpenVMS process. Three service parameters govern the auditing that occurs when a connection is accepted or rejected:
|
LOG-ACCEPTS |
Enables or disables logging for accepted connection requests. |
|
LOG-FILE |
Specifies the OpenVMS file name to which log messages are written. The auditing data collected by the MultiNet Server is collected in this file and flushed (written to disk) approximately every five to ten minutes. To maintain different versions of this file, you can copy an empty file over the old one on a daily basis (or at a frequency that meets your needs). |
|
LOG-REJECTS |
Enables or disables logging for rejected connection requests. A request can be rejected if the REJECT-HOSTS, REJECT-NETS, or REJECT-BY-DEFAULT security restrictions are enabled and succeed, or if the ACCEPT-HOSTS and ACCEPT-NETS restrictions are enabled and fail. For more information, refer to the Restricting Access to Servers section. |
Note! The only services that support auditing are those that listen for connections through the MULTINET_SERVER. For example, the optional NFS server, which reads datagrams directly, ignores the auditing parameters.
You should not turn on logging for a UDP service. Because there is no "formal" connection for UDP, every packet sent to the UDP service would be logged.
The following example shows how to enable a log file on the TELNET service.
$ MULTINET CONFIGURE /SERVERS
MultiNet Server Configuration Utility 5.0(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>SELECT TELNET
[The Selected SERVER entry is now TELNET]
SERVER-CONFIG>SET LOG-ACCEPTS TRUE
SERVER-CONFIG>SET LOG-REJECTS TRUE
SERVER-CONFIG>SET LOG-FILE MULTINET:SERVER.LOG
SERVER-CONFIG>SHOW/FULL
Service "TELNET":
TCP socket (AF_INET,SOCK_STREAM), Port 23
Socket Options = SO_KEEPALIVE
INIT() = TCP_Init
LISTEN() = TCP_Listen
CONNECTED() = TCP_Connected
SERVICE() = Internal_Telnet
Log File for Accepts & Rejects = MULTINET:SERVER.LOG
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first ? [YES] YES
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]
SERVICES.MASTER_SERVER]
%RUN-S-PROC_ID, identification of created process is 20600054
SERVER-CONFIG>
The next example shows the auditing records written to the log file.
15-JUN-2003 17:27:00 RPCPORTMAP (accepted) from [127.0.0.1,108] (localhost)
15-JUN-2003 17:50:25 FINGER (accepted) from [192.41.228.65,1071] (ABC.COM)
15-JUN-2003 21:10:40 RLOGIN (accepted) from [192.41.228.65,1022] (ABC.COM)
16-JUN-2003 11:49:46 FINGER (accepted) from [192.41.228.65,1214] (ABC.COM)
16-JUN-2003 11:51:05 RLOGIN (accepted) from [192.41.228.68,1022] (Bubba)
16-JUN-2003 20:09:48 FTP (accepted) from [192.41.228.68,1039] (Bubba)
MultiNet allows a system manager to further customize the auditing facilities.
You can provide a user-written shareable image that is merged into the MULTINET_SERVER when the server is restarted. The user-written shareable image is called whenever a connection arrives with information about the connection and can perform the desired auditing.
If the MultiNet Programmer’s Kit is installed, the directory MULTINET_ROOT:[MULTINET.EXAMPLES] contains the file USER_AUDITOR.C. This is a C-language template of a routine called when a connection arrives.
Compile, link, and place it in the MULTINET: directory according to the instructions at the beginning of the file.
MultiNet provides the IP address and an optional IP port number of a suspected intruder to OpenVMS accounting and intrusion detection. The IP address is recorded in hexadecimal format to make room for the optional IP port address. By default, the IP port address is included. To disable this feature, set the LGI_BRK_TERM system parameter to zero.
This example shows accounting and intrusion reports generated with LGI_BRK_TERM set to one (the default).
$ ACCOUNTING/NODE=TELNET
Remote node name: TELNET Privilege <31-00>: 00148000
Remote ID: A12C800C:0F94 Privilege <63-32>: FFFFFFC0
^^^^^^^^ ^^^^
IP address IP port
$ SHOW INTRUSION
Intrusion Type Count Expiration Source
NETWORK SUSPECT 2 17:35:09.28 TELNET::A12C800C:0F94
^^^^^^^^^^^^^^^^^^
IP address IP port
In these examples, A12C800C is the IP address 191.87.34.22 and 0F94 is IP port 3988, both expressed in hexadecimal. You can use the following DCL code to convert hexadecimal IP addresses and port numbers (of the form hex-address:hex-port-number) into dotted decimal format:
$ IP_ADDRESS = F$ELEMENT(0,":",P1)
$ PORT_NUMBER = F$ELEMENT(1,":",P1)
$ WRITE SYS$OUTPUT F$FAO("IP address/port: !UL.!UL.!UL.!UL/!UL", -
F$INTEGER("%X''F$EXTRACT(0,2,IP_ADDRESS)'"), -
F$INTEGER("%X''F$EXTRACT(2,2,IP_ADDRESS)'"), -
F$INTEGER("%X''F$EXTRACT(4,2,IP_ADDRESS)'"), -
F$INTEGER("%X''F$EXTRACT(6,2,IP_ADDRESS)'"), -
F$INTEGER("%X''PORT_NUMBER'"))
$ EXIT
Intrusion detection uses the physical (Ethernet) address, SPX port number, and possibly the target user name. The target user name appears only when the break-in attempt targets a valid account and LGI_BRK_TERM is set to one (the default), as in the following example intrusion report.
$ SHOW INTRUSION
Intrusion Type Count Expiration Source
TERM_USER SUSPECT 1 16:23:38.67 [A12C8000:AA.00.04.00.08.60#ECB]:
^^^^^^^^ ^^^^^^^^^^^^^^^^^ ^^^ ^^^
Network Ethernet address SPX User
number port Name
In this example,
• A12C8000 is the network number, expressed in hexadecimal.
• AA.00.04.00.08.60 is the Ethernet address, expressed in dotted-hexadecimal format.
• ECB is the SPX port.
• No user name is specified; the user name normally follows the ending colon.
The OpenVMS SHOW INTRUSION Utility truncates the Source display field to 33 characters. The TERM_USER record is actually associated with a particular user name; you can delete it (with DELETE/INTRUSION) only by specifying the full source specification, including the invisible, truncated data.
The following example of an FTP_SERVER.COM file shows the use of the FTP server qualifiers. The first section ensures that global and local symbols appear as expected. Information is then taken from the logical names that store data about the person who has accessed this FTP server:
$ Set := "Set"
$ Set Symbol/Scope=(NoGlobal,NoLocal)
$ If F$TrnLNM("MULTINET_FTP_ADDRESS") .Eqs. "" Then -
MultiNet FTP/Server/Get_Remote_Info
$ FTP_Address = F$TrnLNM("MULTINET_FTP_ADDRESS")
$ FTP_Hostname = F$TrnLNM("MULTINET_FTP_HOSTNAME")
$ FTP_Password = F$TrnLNM("MULTINET_ANONYMOUS_PASSWORD")
$ Ident = FTP_Hostname
$ If FTP_Hostname .Eqs. "" Then Ident = FTP_Address
In the next section, if FTP_Hostname is null, the IP address could not be found in the host table or by DNS lookup. The Ident symbol is set to flag this event:
>PRE>
$ Message = ""
$ If FTP_Hostname .Eqs. "" Then -
Message = Message + ",""Unknown hostname: ''Ident'; DNS Problem!"""
$ If F$Edit(FTP_Password,"UPCASE") .Eqs. "GUEST" Then -
Message = Message + ",""''Ident'; say who really you are."""
$ Message = Message + ",""@WELCOME.TXT"""
$ If Message .Nes. "" Then -
Message = "/Message=("+F$Extract(1,256,Message)+")"
In the following section, the banner message is altered to fit the circumstances under which the user logs in.
$ If F$Extract(0,6,FTP_Address) .Eqs. "192.0." Then Goto Intruder
$!
$ DirOptions = "/Directory=Users:[Anonymous]"
$ AccOptions = "/Access=NoWrite"
$ MultiNet FTP/Server 'AccOptions' 'DirOptions' 'Message'
$!
$ Logout/Brief
The following section tests the IP address for a known intruder. If the intruder is discovered, control is passed to the Intruder label. Next, the FTP server is called to handle the anonymous login, and when done, logs out.
1 An offensive stance is taken when an intruder is discovered by running a FINGER of the intruder's system.
2 INFLAME.TXT is invoked to display a personalized message.
3 The FINGER output is displayed on the intruder's terminal.
4 Mail is sent to the system manager to indicate that an intrusion event occurred.
5 The procedure exits.
$ Intruder:
$ Set NoOn
$ create finger.temp
$ define/user sys$output finger.temp
$ MultiNet Finger @'FTP_Address
$!
$ MultiNet FTP/Server/Reject/Message=("@Inflame.txt",-
"Thanks for listening ''FTP_Password'@''Ident';
now smile:","","@finger.temp")
$ Mail/Subject="intruder FTP access from
''FTP_Password'@''Ident'" finger.temp system
$ del finger.temp;*
$ logout/Brief
If OpenVMS Accounting is enabled on your system, the following process header fields are set for network server processes created by the MultiNet master server:
• CTL$T_NODENAME is the name of the service being run; for example, FTP, TELNET, or SMTP.
• CTL$T_REMOTEID is the IP address of the remote client system in dotted-decimal format.
This change can make attempted break-ins to your system easier to track. It also provides a simple mechanism for tracking remote access to your system.
For example, to determine which users are using TELNET to gain access to your system, you can issue the command:
$ ACCOUNTING /NODE=TELNET
Note! The TELNET service complies with RFC-779 and provides location information.
Note! IP address and port information is displayed in hexadecimal in accounting reports.
The MULTINET NETCONTROL command features ACCOUNTING and DEBUG parameters for the NETCONTROL (master server) service.
The format of this command is:
$ MULTINET NETCONTROL NETCONTROL ACCOUNTING n
By default (as described above), additional information is provided in the accounting record by the MultiNet server. You can disable this feature by setting n to 0. When set to 1, the remote name and service name are added to the ACCOUNTING record.
OpenVMS adds accounting records to a central database each time a special system event occurs. These events include processes exiting, images (programs) ending, failed logins, and so on. OpenVMS stores a record of the event with information from the process.
One item that OpenVMS includes in the accounting record is the remote node ID, which it gets from the internals of the process. For most processes, the remote node ID is empty.
When you use SET HOST to create a log for another node, DECnet fills in the remote node ID field when it creates the process. This information then appears in any accounting record generated for that process.
If you suspect an intruder has attempted a security breach of your system, you can examine the accounting records to see who has logged in and identify where a login attempt originated.
The master server fills in both the remote node ID and the node name field. The remote node ID field is set to the ASCII representation of the dotted-decimal IP address of the node that requested the service. The NODE NAME field is set to the service name, such as FTP, TELNET, and so on.
The following example shows a LOGIN failure accounting record:
LOGIN FAILURE
-------------
Username: MILLER UIC: [SYSTEM]
Account: <net> Finish time: 23-JUN-2003 21:27:34.47
Process ID: 21200124 Start time: 23-JUN-2003 21:27:33.81
Owner ID: Elapsed time: 0 00:00:00.66
Terminal name: Processor time: 0 00:00:00.26
Remote node addr: Priority: 4
Remote node name: FTP Privilege <31-00>: FFFFFFFF
Remote ID: 161.44.128.94Privilege <63-32>: FFFFFFFF
Remote full name:
Queue entry: Final status code: 00D380FC
Queue name:
Job name:
Final status text:%LOGIN-F-INVPWD, invalid password
Page faults: 166 Direct IO: 7
Page fault reads: 5 Buffered IO: 12
Peak working set: 246 Volumes mounted: 0
Peak page file: 3280 Images executed: 1
Services written to be started by the auxiliary server (INETD) in HP TCP/IP Services for OpenVMS can be configured for use with MultiNet by setting the service parameter SET FLAGS UCX_SERVER.
Driver enhancements support TeamLinks, POSIX sockets, DCE for OpenVMS, and TCP/IP Services V2.0 keepalive compatibility.
The logical name UCX$INET_HOSTADDR contains the text value of the primary interface. MultiNet defines UCX$INET_HOSTADDR automatically, much the same as other TCP/IP Services logical names. It is defined in START_MULTINET.COM.
Performing a close (dassgn) operation on any TCP/IP Services (BG) device used in a select list cancels the select operation.
The following logicals are defined for improved UCX compatibility:
TCPIP$BIND_DOMAIN
TCPIP$BIND_SERVER000
TCPIP$BIND_SERVER001 (if more than one BIND server is defined)
TCPIP$BIND_SERVER002 (if more than one BIND server is defined)
TCPIP$DEVICE = BG:
TCPIP$INET_DEVICE = BG:
TCPIP$INET_HOST
TCPIP$INET_HOSTADDR
TCPIP$IPC_SHR = MULTINET:UCX$IPC_SHR
You can specify DCL command procedures (.COM files) as the programs associated with MultiNet services. When a service is initiated, MultiNet calls LOGINOUT to invoke the user's LOGIN.COM file and the specified DCL command procedure. When called, the DCL and CLI are mapped for use by the process. This feature gives the system manager a "hook" into a service with an easy-to-create command procedure. Note, however, that the command procedure cannot use SYS$INPUT. Therefore, do not use the READ SYS$INPUT or INQUIRE commands in the command procedure or a user's LOGIN.COM file.
Make sure that all command procedures associated with services include a command that assigns SYS$INPUT to SYS$OUTPUT as follows:
$ DEFINE /USER SYS$INPUT SYS$OUTUT
This command must appear immediately before any command that runs an image, but is only in effect while the image is running. To ensure the assignment lasts for the duration of the entire command procedure, use the above command without the /USER qualifier:
Keepalives are useful when other systems that connect to services provided by your system are subject to frequent crashing, resets, or power-offs (as with personal computers). TCP/IP connections must normally pass through a three-way handshake sequence to be closed and removed from the connection table. If a connection is open but idle, and the remote system is shut down, reset, or crashes, the connection is not closed down until your system attempts to communicate with the remote system. If an application or service does not attempt to communicate, a keepalive probe can clean up these dormant connections.
The format for the SET KEEPALIVE-TIMERS function is:
SERVER-CONFIG>SELECT service SERVER-CONFIG>SET KEEPALIVE-TIMERS idle-time probe-interval probe-count
|
idle-time |
is the amount of time, in seconds, that a connection should be idle before the first keepalive probe is sent. |
|
probe-interval |
is the number of seconds between keepalive probes (75 seconds minimum). |
|
probe-count |
is the number of probes sent, with no reply from the other side of the connection, before the connection is destroyed. |
Setting any of these parameters to 0 retains its default setting.
If you set the SO_KEEPALIVE socket option for a service, but you do not explicitly set KEEPALIVE-TIMERS, the default values are:
• idle-time is 2 hours.
• probe-interval is 75 seconds.
• probe-count is 8.
If you do not set the SO_KEEPALIVE socket option for a service, no keepalive probes are sent for connections to that service.
The MultiNet TFTP service uses standard Internet TFTP to perform file transfers. Like FTP, TFTP can also be used to transfer files between a host running OpenVMS and a remote host. Unlike FTP, TFTP cannot perform operations other than transferring files between a local system and a remote one; that is, TFTP cannot list directories, delete files, and so on.
TFTP does not perform any authentication when transferring files, so a user name and password on the remote host are not required. In general, only files with world-read (W:R) access in certain directories on the remote host are available for reading, and only certain directories are available for writing.
Use SERVER-CONFIG to enable TFTP as follows:
$ MULTINET CONFIGURE /SERVER
MultiNet Server Configuration Utility 5.0(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>ENABLE TFTP
SERVER-CONFIG>EXIT
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]| SERVICES.MASTER_SERVER]
$
Note! The permissions of the accessed directories are not checked before the access is attempted. Because the TFTP protocol does not specify any user login or validation, the TFTP server permits only WORLD-readable files to be accessed.
The TFTP server normally requires full file system pathnames, as it operates without a default directory. If you are using TFTP to download network servers which may not be able to provide full pathnames, you can set a TFTP default directory using the NET-CONFIG SET TFTP-DIRECTORY command.
Note! The TFTP mail option, as defined in RFC-783, is obsolete and not supported under the MultiNet TFTP server.
The MULTINET:TFTP.FILENAME-TRANSLATIONS file can be used to translate between TFTP client file names and OpenVMS file names, and restrict TFTP access to certain files or directories. The following is an example of a MULTINET:TFTP.FILENAME-TRANSLATIONS file:
#
# TFTP filename fixups for broken TFTP
# loaders & file access restrictions
#
RESTRICT-ACCESS
#
# This is a translation for a single file
#
/Foo/bar.dat SYS$MANAGER:BAR.DAT
#
# These two translations map an entire OpenVMS directory
#
/usr/lib/X11/ncd/configs/* NCD_CONFIGS:[000000]
/ncd_fonts/dw75dpi/* NCD_FONTS:[DW75DPI]
#
# This translation is a file access restriction
#
SYS$SYSROOT:[SYSFONT.DECW.* SYS$SYSROOT:[SYSFONT.DECW.
Use either "#" or "!" to start a comment.
If the keyword RESTRICT-ACCESS is on a line by itself in the file, only files that match one of the translation specifications are accessible. This restricts TFTP access to specific directory hierarchies. If this string is not specified in the FTP.FILENAME-TRANSLATIONS file, all WORLD-readable files are accessible to TFTP clients.
The first translation causes a client reference to /Foo/bar.dat to access the OpenVMS file SYS$MANAGER:BAR.DAT (note that comparisons are not case-sensitive). This is an example of a translation for a single file.
The next two translations are examples of mapping an entire OpenVMS directory. If the client reference matches everything up to the asterisk (*), the rest of the client reference is appended to the translation string. For example, /usr/lib/X11/ncd/configs/foo.dat becomes NCD_CONFIGS:[000000]FOO.DAT.
The last translation is an example of a file access restriction. The result of the translation is the same as the client-specified file. The TFTP server disallows subdirectory specifications that include ".-" to ensure you cannot bypass access restrictions by going back up the VMS directory hierarchy.
If the file MULTINET:TFTP.FILENAME-TRANSLATIONS is edited, NETCONTROL must be used to RELOAD it:
$ MULTINET NETCONTROL TFTP RELOAD
This section describes configuration of the "R" services, RLOGIN and RSHELL.
• RLOGIN provides a means of logging in to another system.
• RSHELL executes commands remotely on another system.
These services are enabled when MultiNet is installed.
The authentication scheme used by RLOGIN and RSHELL is based on trusted users and trusted hosts specified in files on the destination system. The MULTINET:HOSTS.EQUIV file (/etc/hosts.equiv on UNIX systems) grants access on a system-wide basis. The file SYS$LOGIN:.RHOSTS (~/.rhosts on UNIX systems) can be used by individual users on a system to grant remote users access to their accounts.
Note! Do not use IP addresses in the HOSTS.EQUIV or .RHOSTS file.
Access control requirements differ between RLOGIN and other "R" services. RLOGIN requires both NETWORK and LOCAL access, while RSHELL, REXEC, RMT, and RCP only require NETWORK access.
If you remove a user's NETWORK access, the user can still log in until their RLOGIN cache entry expires or is flushed. However, if you remove that user's LOCAL access, the user is denied access immediately, even if they have a current cache entry.
The format of an entry in the HOSTS.EQUIV or .RHOSTS file is:
hostname [username]
If an entry containing only the host name is in the file MULTINET:HOSTS.EQUIV (or /etc/hosts.equiv) on the target system, all users on hostname with the same user name as on the target system can access the target without specifying a user name or password.
Both MULTINET:HOSTS.EQUIV and SYS$LOGIN:.RHOSTS accept "wildcards" in host names. For example, to specify all hosts at FLOWERS.COM, include the following line:
*.FLOWERS.COM
If an entry in SYS$LOGIN:.RHOSTS or a user's ~/.rhosts file contains the following format, the specified username on the hostname system can access the user's account on the target system without specifying a password (or a user name if the user names are identical on the two systems):
hostname username
The next example shows a HOSTS.EQUIV file on the host SALES.FLOWERS.COM that gives users on SALES.FLOWERS.COM RLOGIN and RSHELL access to their own accounts on the system (this is allowed by the first two entries).
In this example, FLOWERS.COM and BUBBA.FLOWERS.COM are identified (in the last two entries) as trusted hosts, allowing any user on either of these systems to have RLOGIN and RSHELL access to the account of the same name on SALES.FLOWERS.COM without specifying a user name or password.
localhost
sales.flowers.com
flowers.com
bubba.flowers.com
This example shows a .RHOSTS file that belongs to a user on SALES.FLOWERS.COM:
flowers.com system
unix.flowers.com root
The first entry grants access to the user's account on the host SALES.FLOWERS.COM to user SYSTEM on host FLOWERS.COM. The second entry grants access to the user's account to user "root" on host UNIX.FLOWERS.COM. Hence, either of these two remote users can use RLOGIN or RSHELL to access the user's account on SALES.FLOWERS.COM without specifying a password.
Note! When specifying a user in any of the authentication files (particularly on the UNIX operating system), make sure to specify the user name in the correct case. "ROOT" and "root" are treated as different user names under case-sensitive systems such as the UNIX Operating System.
The host initiating the RLOGIN or RSHELL request must be listed in the destination host's hostname database or must be resolvable within the Domain Name System (DNS), if domain name service is enabled. If the destination host cannot determine the initiating host's name from the IP address in the connection request, it rejects the request.
The RLOGIN server parameters INCLUDE-AUTHENTICATION-INDICATION, INCLUDE-PORT-NUMBER and INCLUDE-SEND-LOCATION cause an authentication indication, a port number, or a send location (or all three) to be placed in the TT_ACCPORTNAM field of the NTY device control block. These parameters are disabled by default. To enable them, use SERVER-CONFIG (MULTINET CONFIGURE /SERVER).
The RSHELL /NOSTDERR option disables creation of the connection from the remote RSHELL server back to the client for "standard error" output. This allows you to use the RSHELL command through firewalls that do not allow TCP connections that originate from outside the local network. When you use this option, the remote RSHELL server sends messages to the "standard output" connection, so error messages are still displayed.
The MultiNet RLOGIN and RSHELL servers cache the contents of the .RHOSTS and HOSTS.EQUIV files and authentication information from the SYSUAF file in memory for ten minutes to improve performance. This means that changes made to these files may not be noticed by the network immediately. Use the following command to flush the cache before the timeout period:
$ MULTINET NETCONTROL RLOGIN FLUSH
You can use SERVER-CONFIG to change the timeout on these caches by setting the RHOSTS-TIMEOUT or UAF-TIMEOUT parameters for RSHELL, RLOGIN, or REXEC. The default value for these parameters is 600 seconds. Setting a value of 0 (zero) disables the cache. Because the "R" services share a common authentication cache, you need only set these parameters for one service. If you set different values for different servers, only one of the values is used, so set these parameters on only one server. The following example shows how to set the timeout parameter.
$ MULTINET CONFIGURE/SERVER
MultiNet Server Configuration Utility 5.0(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>SELECT RLOGIN
[The Selected SERVER entry is now RLOGIN]
SERVER-CONFIG>SET PARAMETERS
Delete parameter "rhosts-timeout 0" ? [NO] YES
[Parameter "rhosts-timeout 0" deleted from RLOGIN]
You can now add new parameters for RLOGIN. An empty line terminates.
Add Parameter: RHOSTS-TIMEOUT 3600
Add Parameter: UAF-TIMEOUT 60
Add Parameter:
[Service specific parameters for RLOGIN changed]
SERVER-CONFIG>
The UAF access type specification for RSHELL access is NETWORK. MultiNet checks all access times.
The MULTINET NETCONTROL RLOGIN SHOW command shows the time the information read in from specific .RHOSTS files will expire. This is the time remaining until the .RHOSTS file is read in again.
Note! A non-existent .RHOSTS file is treated the same as an empty .RHOSTS file.
If a client closes a connection before the remote process finishes, the RSHELL and REXEC servers may delete the process. This behavior affects PC-based X servers that use REXEC to launch X applications.
This default action can be changed by using SERVER-CONFIG to SET PARAMETER as in the following example:
$ multinet configure /server
. . . startup messages . . .
SERVER-CONFIG>select rshell
[The Selected SERVER entry is now RSHELL]
SERVER-CONFIG>set parameter
You can now add new parameters for RSHELL. An empty line terminates.
Add Parameter: ? parameter, one of the following:
DEBUG DISALLOW-RHOSTS DISALLOW-X-DISPLAY
PREVENT-PROCESS-DELETION RHOSTS-TIMEOUT UAF-TIMEOUT
or confirm with carriage return
Add Parameter: PREVENT-PROCESS-DELETION
Add Parameter:
[Service specific parameters for RSHELL changed]
SERVER-CONFIG>
By default, MultiNet "R" services create WSA devices and set displays to simplify setup for X client users, allowing users to run X clients without explicitly issuing the SET DISPLAY command. To disable this feature, set DISALLOW-X-DISPLAY with the SET PARAMETER command (in SERVER-CONFIG) or with Set Service Specific Options (in MENU-CONFIG).
Problems arise when remote users log into systems using a login command procedure (SYS$LOGIN:SYLOGIN.COM or SYS$MANAGER:SYLOGIN.COM) that requires screen output. To inhibit this behavior, make sure the following lines are included at the top of all login command procedures:
$ VERIFY = 'F$VERIFY(0) ! Turn off verify without echoing
$ IF F$MODE() .EQS. "OTHER" THEN EXIT ! If a DETACHED process (RSHELL)
. . .
$ IF VERIFY THEN SET VERIFY ! If a batch job, may want to turn
! verify back on.
In general, "R" services should not be permitted access to captive or restricted OpenVMS accounts. However, if your users depend on such access, define the following logical to allow access to these types of accounts:
$ DEFINE/SYSTEM/EXEC MULTINET_RSHELL_ALLOW_CAPTIVE "TRUE"
The TELNET Client and Server require the installation of the KRB$RTL32.EXE shareable image provided by the HP Kerberos for OpenVMS product. This can be added via the install utility:
$ install add sys$library:krb$rt132 /open/header/share
Enable the Kerberos V5 functionality with the following commands:
$ MULTINET CONFIGURE /SERVER
... startup messages...
SERVER-CONFIG>SELECT TELNET
(The Selected SERVER entry is now TELNET)
SERVER-CONFIG>SET PROGRAM MULTINET:LOADABLE_KTELNET_CONTROL
(Program to run for TELNET set to MULTINET:LOADABLE_KTELNET_CONTROL)
SERVER-CONFIG>SET INIT Merge_Image
(Init action of TELNET set to Merge_Image)
After the values are saved and the Master Server is restarted, Kerberos 5 functionality is available.
The authentication behavior on the TELNET Server is determined by the system logical MULTINET_AUTH_TELNET. It has 3 possible values: ALLOWED, REQUIRED, and DISABLED.
Note! Not all configuration options are available with the Kerberos V5 Server. While the Kerberos V5 Server is started and terminated by the Master Server, it runs as a separate process. It uses a limited subset of server control options. server control options currently supported are: INIT, Program, Priority, and Log-Accepts. To set the SOCKET-PORT option, use the system logical MULTINET_TELNET_PORT.
The default is DISABLED; a login prompt will result. When the value is REQUIRED, any user without a valid Kerberos V5 Ticket Granting Ticket (TGT) will be rejected. Finally, if the value is ALLOWED, the user can log-in to the server with or without a valid Kerberos V5 TGT (with a login prompt resulting if no TGT).
For example, to force authentication by any remote telnet client, set the logical as follows:
$ DEFINE/SYSTEM MULTINET_TELNET_AUTH REQUIRED
Note! Kerberos V5 requires Kerberos for HP OpenVMS (Version 2.0), which is available from the HP Web site. The Kerberos V5 applications can also run with any Kerberos V5-compliant Key Distribution Center (KDC) software. Kerberos V5 applies to VMS V7.0 or higher, and VMS Alpha V7.2-2 or higher.
The TELNET server parameters INCLUDE-AUTHENTICATION-INDICATION, INCLUDE-PORT-NUMBER and INCLUDE-SEND-LOCATION cause an authentication indication, a port number, or a send location (or all three) to be placed in the TT_ACCPORNAM field of the NTY device control block. These parameters are disabled by default. To enable them, use SERVER-CONFIG (MULTINET CONFIGURE /SERVER).
Note! These parameters will not function with the Kerberos 5 Telnet server, as it uses pty devices.
Enable these parameters with the following commands:$ MULTINET CONFIGURE /SERVER
. . . startup messages . . .
SERVER-CONFIG>SELECT TELNET
[The Selected SERVER entry is now TELNET]
SERVER-CONFIG>SET PARAMETERS
You can now add new parameters for TELNET. An empty line terminates.
Add Parameter: INCLUDE-AUTHENTICATION-INDICATION
Add Parameter: INCLUDE-PORT-NUMBER
Add Parameter: INCLUDE-SEND-LOCATION
Add Parameter: RETURN
[Service specific parameters for TELNET changed]
SERVER-CONFIG>
If these parameters are defined, the appropriate information is stored in the TT_ACCPORNAM field.
These parameters appear in the Remote Port Info field of the SHOW TERMINAL and SHOW USERS command output. The INCLUDE-SEND-LOCATION parameter enables support for RFC 779 in the Telnet server. In the following example, the port number is 1021, and the /AUTH qualifier indicates that WHORFIN used authentication to log in from LOT49.FLOWERS.COM.
$ SHOW TERMINAL
Terminal: _VTA84: Device_Type: VT100 Owner: WHORFIN Physical terminal: _NTY3: Remote Port Info: LOT49.FLOWERS.COM/1021/AUTH Input: 9600 LFfill: 0 Width: 80 Parity: None Output: 9600 CRfill: 0 Page: 24
Terminal Characteristics: Interactive Echo Type_ahead No Escape
No Hostsync TTsync Lowercase Tab
Wrap Scope Remote No Eightbit
No Broadcast No Readsync No Form Fulldup
No Modem No Local_echo Autobaud Hangup
No Brdcstmbx No DMA Altypeahd Set_speed
No Commsync Line Editing Insert editing No Fallback
No Dialup No Secure server Disconnect No Pasthru
No Syspassword No SIXEL Graphics No Soft Characters No Printer Port
Numeric Keypad ANSI_CRT No Regis No Block_mode
Advanced_video No Edit_mode DECEC_CRT2
No DEC_CRT3 No DEC_CRT4 VMS Style Input
$
Authentication information is not valid if someone uses the LOGOUT /NOHANG command and then logs in again.
All MultiNet Secure/IP configuration parameters are stored in the MULTINET:START_ACCESS.COM command procedure. You must run this procedure to make configuration changes take effect. When you first install MultiNet Secure/IP, the MULTINET:START_ACCESS.COM file does not exist; you cannot start MultiNet Secure/IP until you configure it with one of the utilities listed in the following table.
|
This command procedure or utility... |
Performs this function: |
|
SECUREIP_CONFIGURE.COM |
Prompts you for the parameters required for a basic configuration. For details, seeUsing SECUREIP_CONFIGURE.COM below. |
|
ACCESS-CONFIG |
Provides access to all MultiNet Secure/IP Client and Server parameters. Invoke ACCESS-CONFIG with the MULTINET CONFIGURE /ACCESS command. For details, seeUsing ACCESS-CONFIG below. |
|
MENU-CONFIG |
Provides access to all MultiNet Secure/IP Client and Server parameters through a menu-driven interface. Invoke MENU-CONFIG with the MULTINET CONFIGURE /MENU command. For details, seeUsing MENU-CONFIG below. |
Note! Do not manually edit the START_ACCESS.COM file with a text editor. Make all configuration changes using the ACCESS-CONFIG or MENU-CONFIG utilities, or the SECUREIP_CONFIGURE command procedure.
You can modify the MultiNet Secure/IP Client challenge and response prompts using logical names. For details, see Chapter 11.
The MultiNet startup command procedure, START_MULTINET.COM, checks for START_ACCESS.COM and executes it if it exists. For details about enabling and disabling MultiNet Secure/IP, see below.
Use the SERVER-CONFIG and MENU-CONFIG utilities to configure the MultiNet master server for the ACCESS service (MultiNet Secure/IP Server). For details about configuring MultiNet services, see the MultiNet for OpenVMS Administrator’s Guide.
The MULTINET:SECUREIP_CONFIGURE.COM command procedure prompts you for basic information required to configure MultiNet Secure/IP Clients and Servers. It creates a new MULTINET:START_ACCESS.COM command procedure, which you can run to make the configuration take effect. To configure MultiNet Secure/IP with SECUREIP_CONFIGURE.COM:
1 Use the configuration checklist in Table 12-2 to record information specific to your installation.
Table 12-2 MultiNet Secure/IP Configuration Checklist
|
Parameter |
Description |
Your Value |
|
MultiNet Secure/IP Server IP Address |
Every host to be protected by the MultiNet Secure/IP Client must know the IP address of the MultiNet Secure/IP Server that authenticates users. If the MultiNet Secure/IP Server runs on the same host as the MultiNet Secure/IP Client, use the default loopback address, 127.0.0.1. | |
|
MultiNet Secure/IP Port |
By default, MultiNet Secure/IP Clients and Servers communicate on port 702. If port 702 is already in use by another server, specify an alternative port number between 1 and 1024. All systems running MultiNet Secure/IP must use the same port. | |
|
Default Authentication Method (only required on MultiNet Secure/IP Servers) |
The authentication method this MultiNet uses for users who are not configured for a preferred authentication method. Accepted methods are "SecureNet," "SecurID Card," "S/KEY," and "plaintext." |
2 At the DCL prompt, enter:
@MULTINET:SECUREIP_CONFIGURE
The first two prompts ask if you are running the MultiNet Secure/IP Client and Server on your system.
3 Respond YES for each MultiNet Secure/IP component you need to configure.
4 The remaining prompts ask you for information from the configuration checklist. Enter the configuration checklist information at the appropriate prompts. After you respond to the final prompt, SECUREIP_CONFIGURE writes a new START_ACCESS.COM file and exits.
5 Run @MULTINET:START_ACCESS to make the new configuration take effect.
ACCESS-CONFIG, which you invoke with the command MULTINET CONFIGURE /ACCESS, is a command line-based configuration utility that provides access to all MultiNet Secure/IP Client and Server configuration parameters. Like SECUREIP_CONFIGURE.COM, ACCESS-CONFIG creates a new START_ACCESS.COM command procedure file that contains configuration parameters. To make the new configuration parameters take effect, you must run @MULTINET:START_ACCESS after running ACCESS-CONFIG. ACCESS-CONFIG works like other MultiNet configuration utilities such as NET-CONFIG and SERVER-CONFIG. For details about the ACCESS-CONFIG commands, see the MultiNet for OpenVMS Administrator’s Reference. For online command information, use the HELP command at the ACCESS-CONFIG prompt.
The START_ACCESS.COM startup command procedure file does not exist when you first install MultiNet Secure/IP. You must run ACCESS-CONFIG to create it. Even if you configure MultiNet Secure/IP, it is only enabled if you intentionally set the CALLOUTS-ENABLED parameter.
The following example illustrates how to enable the MultiNet Secure/IP Client:
$ MULTINET CONFIGURE /ACCESS
MultiNet Access Configuration Utility 1.0(6)
[Reading in configuration from MULTINET:START_ACCESS.COM]
ACCESS-CONFIG>SHOW
Secure/IP Server Parameters
---------------------------
Default Method: Digital Pathways SecureNet Key
Allow Local Passwords: TRUE
Local Network(s): <default>
Untrusted Host(s): <none>
Allow user control of S/KEY TRUE
Allow key display (/SHOW): TRUE
Secure/IP Client Parameters
---------------------------
Telnet Enabled: TRUE
FTP Enabled: TRUE
Server Address(es): 127.0.0.1
Server Port: 702
LOGINOUT Parameters
-------------------
Require mutual authentication: FALSE
Local Device(s): <none>
Allow plaintext passwords, on:
Remote DECnet terminals (RT): FALSE
Pseudo-terminal devices (FT): TRUE
Attempt Network (Kerberos) Login: TRUE
Kerberos ticket lifetime (minutes): 480
MultiNet Login command procedure: MULTINET:MULTINET-LOGIN.COM
ACCESS-CONFIG>SET TELNET-ENABLED FALSE
ACCESS-CONFIG>SHOW
Secure/IP Server Parameters
---------------------------
Default Method: Digital Pathways SecureNet Key
Allow Local Passwords: TRUE
Local Network(s): <default>
Untrusted Host(s): <none>
Allow user control of S/KEY TRUE
Allow key display (/SHOW): TRUE
Secure/IP Client Parameters
---------------------------
Telnet Enabled: FALSE
FTP Enabled: TRUE
Server Address(es): 127.0.0.1
Server Port: 702
LOGINOUT Parameters
-------------------
Require mutual authentication: FALSE
Local Device(s): <none>
Allow plaintext passwords, on:
Remote DECnet terminals (RT): FALSE
Pseudo-terminal devices (FT): TRUE
Attempt Network (Kerberos) Login: TRUE
Kerberos ticket lifetime (minutes): 480
MultiNet Login command procedure: MULTINET:MULTINET-LOGIN.COM
ACCESS-CONFIG>EXIT
Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]START_ACCESS.COM]
[LOGINOUT Client configuration modified; @MULTINET:START_ACCESS required]
$ @MULTINET:START_ACCESS.COM
A trusted local network (TLN) is defined by a list of the following:
• Devices connected directly to the MultiNet Secure/IP Client
• Trusted IP networks
• Specific hosts on local IP networks that are not trusted
Within your TLN, users can log into hosts running the MultiNet Secure/IP Client with plaintext passwords even if they are registered on a MultiNet Secure/IP Server for S/KEY, SecurID, or SNK authentication. However, users logging in from hosts not included in your TLN must always use secure authentication. Use ACCESS-CONFIG to define the trusted local network. Table 12-3 shows the ACCESS-CONFIG commands that define the trusted local network.
Table 12-3 Defining the Trusted Local Network
|
To perform this function... |
Use this ACCESS-CONFIG command: |
|
Add a hardwired device to the TLN |
SET LOCAL-DEVICE |
|
Add a network to the TLN |
SET LOCAL-NETWORK |
|
Exclude a host from the TLN |
SET UNTRUSTED-HOST |
CAUTION! If you define trusted local networks with the SET LOCAL-NETWORKS command, you must explicitly add the loopback network, 127.0.0.0/255.0.0.0. It is not implicitly included in your TLN.
Local networks can be identified by subnet. When there are no local networks, the interface Netmask is used instead of the Class A, B, or C default Netmask.
CAUTION! If you do not specify a local networks list and you are using subnets, you may not get the behavior you expect. The local network address is derived by ANDing the interface address with the interface Netmask. So, if the Netmask is for a subnet, only addresses on the derived subnet will be considered local addresses.
You must ensure that users have enough time to enter information before the system times out and rejects the login attempt. The timeout value for logging in is specified by the SYSGEN parameter LGI_PWD_TMO which defaults to 30 seconds.
• For the Digital Pathways token, Secure/IP doubles the value of LGI_PWD_TMO, up to a maximum of 256.
• For Security Dynamics, the timeout value is a minimum of 60 seconds or LGI_PWD_TMO, whichever is higher.
Each authentication method requires a different type of input from users when they log into a Secure/IP Client from outside the trusted local network. By itself, the MultiNet Secure/IP Client does not know the token or authentication method a user is using; it obtains this information from the MultiNet Secure/IP Server when the user enters a name, or when it prompts the user for the specific input. A user does not see the exchange between the MultiNet Secure/IP Client and Server at login.
You can specify authentication methods in one of two ways:
• A system-wide default authentication method for all users (see the Specifying the Default Authentication Method section)
• Authentication methods for individual users that override the system default
A user’s default authentication method is determined either by the default system authentication method or by the method associated with the user in the user profile database. To set or change the default system authentication method:
1 Start ACCESS-CONFIG with the command:
$ MULTINET CONFIGURE /ACCESS
2 Enter the following command sequence:
ACCESS-CONFIG>SET DEFAULT-METHOD method
ACCESS-CONFIG>EXIT
3 Ensure that user profiles exist for the specified authentication method (see Chapter 12).
4 Reload the MultiNet Secure/IP Server configuration with the following command:
$ MULTINET NETCONTROL ACCESS RELOAD
You can reconfigure a MultiNet Secure/IP Client to use a MultiNet Secure/IP Server other than the one for which it was configured during installation. You can also change the TCP port through which the MultiNet Secure/IP Client and Server communicate:
1 Start ACCESS-CONFIG with the command:
$ MULTINET CONFIGURE /ACCESS
2 To change the MultiNet Secure/IP Server used by the local MultiNet Secure/IP Client, enter:
ACCESS-CONFIG>SET SERVER-ADDRESS new_ip_address
3 To change the TCP port used by the local MultiNet Secure/IP Client and Server (if running), enter:
ACCESS-CONFIG>SET SERVER-PORT new_port
Note! If you change the local TCP port for MultiNet Secure/IP, you must also change the port on all other MultiNet Secure/IP systems with which this host communicates.
4 Exit ACCESS-CONFIG with the following command:
ACCESS-CONFIG>EXIT
5 Restart the MultiNet Master Server with the command:
$ @MULTINET:START_SERVER
6 Restart the MultiNet Secure/IP Client with the command:
$ @MULTINET:START_ACCESS
MultiNet Secure/IP includes a feature that enables users within a TLN to automatically obtain Kerberos ticket-granting tickets when they log into a MultiNet Secure/IP Client with their Kerberos passwords. By default, this feature is enabled on MultiNet Secure/IP Clients. You can disable this feature on a MultiNet Secure/IP Client with the ACCESS-CONFIG command SET NETWORK-LOGIN. For more information, see the SET command in the MultiNet for OpenVMS Administrator’s Reference.
This feature is automatically disabled if Kerberos is not configured on the MultiNet Secure/IP Client.
MENU-CONFIG provides access to all MultiNet configuration parameters using a character-based, menu-driven interface. For general information on MENU-CONFIG, see the MultiNet for OpenVMS Installation and Administrator’s Guide.
After you invoke MENU-CONFIG with the MULTINET CONFIGURE /MENU command, choose "Configure Secure/IP."
When the MultiNet Secure/IP Configuration menu appears, you can view or modify the MultiNet Secure/IP Client and Server parameters by choosing "Set Secure/IP Parameters" or "Show Secure/IP Parameters." Each parameter corresponds to an ACCESS-CONFIG parameter described in the section Using ACCESS-CONFIG. MENU-CONFIG provides context-sensitive help (at the bottom of your screen) as you move the cursor between parameters.
By default, MultiNet Secure/IP Client presents "Challenge:" and "Response:" prompts when users log in. You can modify these prompts by defining the logical names shown in Table 12-4 on the MultiNet Secure/IP Client.
Table 12-4 Secure/IP Client Logical Names
Specify all challenge formats as quoted text that includes the "%s" formatting directive to indicate the placement of the challenge. For example, to produce the following prompt:
Sys1 Challenge: 271-1836
Enter this command:
$ DEFINE MULTINET_ACCESS_CHALLENGE_FORMAT "Sys1 Challenge: %s"
This section describes how to manage MultiNet Secure/IP user profiles, the database records that MultiNet Secure/IP Servers maintain to authenticate users when they log into MultiNet Secure/IP Client systems.
Note! You must run all MultiNet Secure/IP management commands on the MultiNet Secure/IP Server.
For convenience, MultiNet Secure/IP includes the MULTINET PROFILE /SHOW command to allow you to view user profiles.
To view user profiles, enter:
$ MULTINET PROFILE [username] /SHOW
If you omit username, the command displays your user profile. For more information, see the MULTINET PROFILE /SHOW command in the MultiNet for OpenVMS Administrator’s Reference.
To determine how many user profiles are in the database, enter:
User profiles are created automatically when you run the MULTINET TOKEN SKEY /INIT or MULTINET TOKEN SKEY /LOAD commands, or when you log in using SecurID authentication. To override the default authentication method for a specific user, add profiles with the MULTINET PROFILE /MODIFY command, as follows:
$ MULTINET PROFILE /MODIFY=METHOD=method username
method is one of the following:
|
password |
snk |
skey |
cryptocard |
securid |
If a user profile does not already exist for username, the MULTINET PROFILE /MODIFY command adds a new profile with the parameters you specify on the command line.
If a user profile already exists for username, method replaces the user’s default authentication method.
Note! If you specified a default authentication method for a user, and later need to return to the system-wide default, use the MULTINET PROFILE /DELETE=METHOD command (see the Deleting User Profiles section).
For more information on the MULTINET PROFILE /MODIFY command, see the MultiNet for OpenVMS Administrator’s Reference.
The following example shows how to change a user’s default authentication from the system-wide default method (SNK) to SecurID Card.
$ MULTINET CONFIGURE /ACCESS
MultiNet Access Configuration Utility 1.0(n)
[Reading in configuration from MULTINET:START_ACCESS.COM]
ACCESS-CONFIG>SHOW
Authentication Server Parameters
--------------------------------
Default Method: Digital Pathways SecureNet Key
Allow Local Passwords: TRUE
Local Network(s): <default>
Untrusted Host(s): <none>
Allow user control of S/KEY TRUE
Allow key display (/SHOW): TRUE
Secure/IP Client Parameters
---------------------------
Telnet Enabled: FALSE
FTP Enabled: TRUE
Server Address(es): 127.0.0.1
Server Port: 702
LOGINOUT Parameters
-------------------
Require mutual authentication: FALSE
Local Device(s): <none>
Allow plaintext passwords, on:
Remote DECnet terminals (RT): FALSE
Pseudo-terminal devices (FT): TRUE
Attempt Network (Kerberos) Login: TRUE
Kerberos ticket lifetime (minutes): 480
MultiNet Login command procedure: MULTINET:MULTINET-LOGIN.COM
ACCESS-CONFIG>EXIT
[Configuration not modified, so no update needed]
$ MULTINET PROFILE /SHOW ALISON
Username Preferred Method
-------- ----------------
alison <default>
$ MULTINET PROFILE/MODIFY=METHOD=SECURID ALISON $ MULTINET PROFILE/SHOW ALISON
Username Preferred Method
-------- ----------------
ALISON Security Dynamics SecurID
You can determine how many user profiles are in the user profile database with the MULTINET PROFILE /SUMMARY command.
To delete user profiles from the user profile database, or to delete specific profile data from specific profiles, use the MULTINET PROFILE /DELETE command:
$ MULTINET PROFILE /DELETE[=subtype] username
If you specify a subtype, only the specified authentication data is deleted from the profile. For details on the types of authentication data that user profiles can contain, see Chapter 11.
If you omit the subtype, the entire user profile is deleted from the database, and the MULTINET PROFILE/SUMMARY command shows a decreased user profile count.
You can also delete CRYPTOCard, SNK, or S/KEY authentication data from user profiles with the MULTINET TOKEN CRYPTOCARD /CLEAR, MULTINET TOKEN SNK/CLEAR, or MULTINET TOKEN SKEY /CLEAR commands. For more information about these commands, see the MultiNet for OpenVMS Administrator’s Reference.
Note! You cannot delete SecurID authentication data with the MULTINET PROFILE /DELETE command because the data is stored on the UNIX-based ACE/Server. The MultiNet Secure/IP Server automatically creates entries in the profile database the first time users log in using their SecurID cards.
MultiNet Secure/IP provides a set of MULTINET TOKEN commands to allow system managers to generate programming codes for CRYPTOCard and SNK tokens and simultaneously add the corresponding DES keys to the user profiles. MultiNet Secure/IP provides similar commands for generating S/KEY response sequences that are also maintained in user profiles.
Before you generate program codes for a CRYPTOCard or SNK token, or generate an S/KEY response sequence, make sure the token’s user is registered in the user profile database.
Table 12-5 lists the MultiNet Secure/IP DCL commands for programming tokens.
Table 12-5 MultiNet Secure/IP Commands for Programming Tokens
|
To program this token... |
Use this programming command... |
|
CRYPTOCard |
MULTINET TOKEN CRYPTOCARD /LOAD |
|
S/KEY |
MULTINET TOKEN SKEY /LOAD |
|
SNK |
MULTINET_TOKEN_SNK_/LOAD |
Note! SecureID Cards require no programming.
Table 12-6 lists the MultiNet Secure/IP DCL commands for testing tokens.
Table 12-6 MultiNet Secure/IP Commands for Testing Tokens
|
To test this token... |
Use this test command... |
|
CRYPTOCard |
MULTINET TOKEN CRYPTOCARD /TEST |
|
S/KEY |
MULTINET TOKEN SKEY /TEST |
|
SNK |
MULTINET_TOKEN_SNK_/TEST |
With MultiNet Secure/IP you can use token- or S/KEY-based authentication to access OpenVMS systems running MultiNet Secure/IP.
Note! Although MultiNet Secure/IP provides authentication protection, it cannot prevent authenticated users from inadvertently compromising security. Make sure all MultiNet Secure/IP users know they must avoid doing anything that involves entering a password while logged in from outside the TLN (for example, across the Internet). The following are examples of actions that compromise security:
• Using explicit DECnet access controls such as:
$ COPY node_name"username password"::
• Changing your OpenVMS password with the SET PASSWORD command
• Modifying or resetting user passwords with the OpenVMS AUTHORIZE utility
• Accessing other non-MultiNet Secure/IP systems via TELNET or SET HOST
• Changing the Kerberos password with the MULTINET KERBEROS PASSWORD command
• Obtaining Kerberos tickets with the MULTINET KERBEROS INITIALIZE command
• Initializing S/KEY response sequences with the MULTINET TOKEN SKEY /INITIALIZE command without the /NOPASSWORD qualifier
This section describes how to use your CRYPTOCard to log into a MultiNet system protected by MultiNet Secure/IP. You can log in from any system with a TELNET, RLOGIN, FTP, or SET HOST client.
Note! The system administrator on the remote MultiNet system must configure MultiNet Secure/IP to authenticate you with the CRYPTOCard protocol.
1 Connect to the MultiNet host with your TELNET, RLOGIN, FTP, or SET HOST client.
2 When prompted, enter your account name. The MultiNet system responds with a challenge.
3 Turn on your CRYPTOCard and enter your PIN.
4 When the CRYPTOCard responds with the READY prompt, press ENT. The CRYPTOCard displays a challenge. The CRYPTOCard challenge may match the MultiNet system challenge because both are derived from the previous challenge.
5 If the CRYPTOCard challenge matches the MultiNet system challenge, press ENT on your CRYPTOCard. If the challenges differ, press CH/MAC, then enter the MultiNet system’s challenge on your CRYPTOCard and press ENT. Your CRYPTOCard displays a response.
6 Enter the response at the MultiNet system Response: prompt. If you enter the correct response, your login session continues.
If MultiNet responds with "User authorization failure," press RETURN and repeat Steps 2 through 5.
Once your system manager has set up your Security Dynamics token, log in as shown in the following example:
Username: HUEY
Enter PASSCODE: passcode
Welcome to AXP/VMS Version V6.1 on node HOLMES
Last interactive login on Monday, 26-JUN-2003 14:21:42.14
Last non-interactive login on Monday, 26-JUN-2003 00:00:00.31
If the MultiNet Secure/IP Client cannot contact the MultiNet Secure/IP Server, the following message appears:
Error opening connection to Secure/IP authentication server
Enter the passcode by specifying your PIN, followed by the number specified on the token. For example, if your PIN is 4320 and the token displays 23493, enter 432023493 at the Enter PASSCODE prompt. Once entered, a Security Dynamics passcode cannot be used again until the cardcode changes.
If your Security Dynamics token has a number pad, enter the PIN on the keypad. Ensure that no one can see what you are entering. The token uses the PIN to compute a number. Enter that number on the computer at the Enter PASSCODE prompt.
Occasionally, for time-clock synchronization, you may be prompted to enter the next token-generated value (specified in the prompt as a "cardcode"). Wait until the number on the token changes, then enter only that number (that is, do not preface the cardcode number with your PIN).
The Security Dynamics method may require users to maintain their own PINs. The procedure for doing so is explained in the Security Dynamics documentation. Use the following guidelines to create a PIN:
• Create a PIN that is four to eight digits long.
• Do not use an obvious number such as your address, birthday, or telephone number.
• Do not start the number with a zero.
The following example illustrates a login session in which the user obtains a new PIN:
Username: WHORFIN
Enter PASSCODE:*****
New PIN required; do you wish to continue now? (Y/N) [N]: YES
Enter your new PIN (4 to 8 digits) or press <RETURN> for a random PIN:*****
Re-enter your new PIN:*****
New PIN successfully set
Welcome to AXP/VMS Version V6.1 on node BIGBOOTE
Last interactive login on Tuesday, 27-JUN-2003 16:35:00.87
Last non-interactive login on Tuesday, 27-JUN-2003 11:34:38.09
Note! If you do not specify a new PIN, a random PIN is displayed.
Once your system manager has set up your Digital Pathways SecureNet Key token, you can log in. If your token was initialized by your system manager to display hexadecimal responses, the response appears on your token as numbers and letters similar to those shown in the following example. If the token was initialized to display decimal responses, the response contains only numbers.
If the MultiNet Secure/IP Client cannot contact the MultiNet Secure/IP Server, the following message appears:
Error opening connection to Secure/IP authentication server
The following example shows an SNK-004 token configured for hexadecimal responses:
Username: ALISON
Challenge: 271-1836
Response: 9B2B605D
Welcome to AXP/VMS Version V6.1 on node BIGBOOTE
Last interactive login on Monday, 26-JUN-2003 14:23:16.74
Last non-interactive login on Monday, 26-JUN-2003 00:00:00.31
In this example, Alison enters her username at the Username: prompt. The computer displays the Challenge value in U.S. telephone number style (nnn-nnnn).
Alison takes the following steps with her SNK-004 token to get the proper Response value:
1 She presses the ON button on the token. The token displays the EP (Enter PIN) prompt.
2 After entering her PIN, she presses ENT.
3 The token then displays "Ed" to prompt her to enter the challenge value. Alison enters the numbers from the Challenge value into the token keypad and presses ENT. (A dash is not provided on the token keypad; it is only shown in the Challenge to improve readability.)
4 The token then displays the response value for about 60 seconds, after which the display clears.
Pressing ENT while the Response value is displayed can have unpredictable results. To start a new challenge-response sequence, press ON.
Using S/KEY authentication involves the steps shown in the following table.
|
Initializing your S/KEY response list |
While logged into the MultiNet Secure/IP Server, use the MULTINET TOKEN SKEY commands to clear, initialize, list, and test a new list of S/KEY responses (see the Initializing an S/KEY Response List section). Make sure you obtain either an S/KEY calculator program or a printed copy of the new response list. |
|
Logging into the MultiNet Secure/IP Client |
Log into the MultiNet Secure/IP Client using your S/KEY calculator program or response list (see the Logging into an S/KEY System section). |
To initialize a new S/KEY response list:
1 Log into the MultiNet Secure/IP Server.
2 If you are logged into the MultiNet Secure/IP Server over a physically secure connection, create a new sequence of login values with the MULTINET TOKEN SKEY /INITIALIZE command, as shown in the following example:
$ MULTINET TOKEN SKEY /INITIALIZE
%SECUREIP-E-SKEYNOTFOU, S/KEY not found for principal "brown"
Enter VMS Password: *****
%SECUREIP-I-SKEYINIT, S/KEY initialization for principal "brown"
New Password: *****
Verification: *****
%SECUREIP-S-INITIALIZED, S/KEY for principal "brown" initialized;
current challenge is "99 go34263"
$
In this example, user "brown" has no privileges and is prompted first for his VMS password. The "New Password:" prompt requests a password that is only used with other MULTINET TOKEN SKEY commands. The password has no effect when logging in. After using this command, use the MULTINET TOKEN SKEY command to list the passwords needed to log into a system.
3 If you are not logged into the MultiNet Secure/IP Server over a physically secure connection, create a new sequence of login values with the MULTINET TOKEN SKEY /INITIALIZE
/NOPASSWORD command, as shown in the following example:
$ MULTINET TOKEN SKEY/INIT/NOPASSWORD
%SECUREIP-I-SKEYINIT, S/KEY initialization for principal "whorfin"
Challenge: s/key 99 bi301206
Response: ?
Enter results of ’s/key 99 bi301206’ using a new password
Challenge: s/key 99 bi301206
Response: MEW GARY ERIC LESK HART WOW
%SECUREIP-S-INITIALIZED, S/KEY for principal "whorfin" initialized; current challenge is "99 bi301206"
Note! You must have access to an S/KEY calculator to provide an S/KEY response. For details on the MULTINET TOKEN SKEY /INITIALIZE command, see the MultiNet for OpenVMS Administrator’s Reference.
4 List the sequence and seed values with the MULTINET TOKEN SKEY /SHOW command, as shown in the following example:
$ MULTINET TOKEN SKEY /SHOW
%SECUREIP-I-SKEYNEXT, current S/KEY challenge for principal "holmes" is "99 go48244"
5 List the new response list with the MULTINET SKEY/COUNT command. If you anticipate having to log in without an S/KEY calculator program, use the MULTINET SKEY /COUNT
/PRINT command to direct the output to a printer. The following example shows how to use MULTINET SKEY /COUNT:$ MULTINET TOKEN SKEY/SHOW
Last S/KEY challenge for principal "whorfin" was "42 bi40353"$ MULTINET SKEY/COUNT=20 41 bi40353
Password: *****
S/KEY sequence for seed "bi40353":
22: LEND JURY GYM KOCH BOYD PAN
23: COCK DOT LIMB LAIR DAY MICE
24: CURD BELT INTO CUBA GREG RED
25: BASH NULL LEFT WARD GOUT TON
26: FRAU GAIT NUT BLUR LEON FOLD
27: MOS JOVE HERO RACY HURT DUB
28: MALI DAR SWAG JULY BOO DAM
29: FACT GALA CARR ROTH EMMA TIC
30: MALI LEO KANE DIET GAS BREW
31: FEND FIGS JIVE SIT NET ISLE
32: JOLT GAIT FOUL MIMI RUSS FOUL
33: BALI ALUM BOY KEEN STAN DOWN
34: SAID FLUE SHIN KUDO NEE JUNO
35: WRY BON TUNE GUS O RINK
36: LARK BORE HEAL NUMB HELL ROAR
37: DAM MARY OUCH SHE IQ LOUD
38: TENT REST LIED MYRA BERN DOVE
39: GOUT LOP RICE OUTS WORD HANK
40: HEAL DARK YALE DESK ROSA OINT
41: SILK GEL WERE TALK NOSE TOO
6 To clear the response list, use the MULTINET TOKEN SKEY /CLEAR command, as shown in the following example:
$ MULTINET TOKEN SKEY /CLEAR
%SECUREIP-S-DELETED, S/KEY for principal "holmes" deleted
This erases the S/KEY sequence for "holmes."
For more information on the S/KEY commands, see the MultiNet for OpenVMS Administrator’s Reference.
This section explains how to log into a MultiNet Secure/IP Client being served by a MultiNet Secure/IP Server, on which you have initialized an S/KEY response list (see the Initializing an S/KEY Response List section). To log in, you must have one of the following:
• A list of S/KEY responses printed out from the MultiNet Secure/IP Server
• An S/KEY calculator program such as the MULTINET SKEY command or the DOS, Microsoft Windows, and Apple Macintosh utilities included with MultiNet Secure/IP (see Chapter 11).
To log into a MultiNet Secure/IP Client from outside the TLN:
1 Log into the MultiNet Secure/IP Client with TELNET, RLOGIN, or any other comparable program. You are prompted for your user name.
2 Enter your user name. If you are configured for S/KEY authentication or the default authentication method and the system default is S/KEY, a challenge appears consisting of a challenge number and the seed value generated when you initialized your response list.
If the MultiNet Secure/IP Client cannot contact the MultiNet Secure/IP Server, the following message appears:
Error opening connection to Secure/IP authentication server
3 To determine the appropriate response, do one of the following:
• Calculate the response by entering the challenge data and your S/KEY password into your
S/KEY calculator program. For details on using the MultiNet Secure/IP S/KEY calculator for OpenVMS, see the MULTINET SKEY command in the MultiNet for OpenVMS Administrator’s Reference.
• Look up the response that corresponds to the challenge number in your S/KEY response list. For example, if the challenge prompt is "s/key 94 bi55253", look up response number 94.
For convenience, S/KEY responses consist of a list of short English words.
4 Enter the appropriate response and press RETURN. MultiNet Secure/IP authenticates you and grants access to the MultiNet Secure/IP Client.
5 If you are using a printed copy of your S/KEY response list, cross off the response you just used; MultiNet Secure/IP will not prompt you with the same challenge in future login attempts.
SYSLOG receives messages from remote IP nodes that have been configured to forward SYSLOG messages to the MultiNet host. SYSLOG then directs the messages to a file, terminal, or OPCOM. In addition, messages can be forwarded elsewhere. [ Forwarding messages are specified with the Forwarding command in the SYSLOG configuration file.]
SYSLOG is provided with MultiNet, and you can enable it with SERVER-CONFIG. By default, when MultiNet is installed, SYSLOG is disabled.
Note! Messages generated by the MULTINET_SERVER process are not sent via SYSLOG, but are instead directed to OPCOM. OPCOM copies the messages to the SYS$MANAGER:OPERATOR.LOG file.
With SYSLOG enabled, you can determine the precise output of message classes and specify how priority messages are handled. Message classes and facility keywords are described in Table 12-7.
Table 12-7 SYSLOG Message Classes
|
Message Type |
Facility Keyword |
|
Authorization messages |
auth |
|
BOOTP messages |
bootpd |
|
Daemon (background processes) messages |
daemon |
|
Domain Name System messages |
named |
|
GATED (gateway messages) |
gated |
|
Kernel messages |
kern |
|
Mail utility messages |
|
|
Network Time Protocol (NTP) messages |
ntpd |
|
Security services messages |
security |
|
Messages generated by user programs |
user |
Enable SYSLOG with SERVER-CONFIG and modify the file MULTINET:SYSLOG.CONFIGURATION. Enable SYSLOG as follows:
$ MULTINET CONFIGURE /SERVER
MultiNet Server Configuration Utility 5.0(nnn) [Reading in configuration from MULTINET:SERVICES.MASTER_SERVER] SERVER-CONFIG>ENABLE SYSLOG SERVER-CONFIG>EXIT [Writing configuration to MULTINET_COMMON_ROOT:[MULTINET] SERVICES.MASTER_SERVER] $
Add entries to the configuration file in the following form: selector action
Separate the fields with tabs. The selector is a semicolon-separated list of priority specifications in this form: facility.level[;facility.level]
• facility is a keyword (see Table 12-7).
Both facility and level are generated by applications on the remote host. The action specifies how SYSLOG responds to these messages. If the applications on the remote host do not write messages to SYSLOG, they are not displayed.
Possible values for facility are auth, bootpd, daemon, gated, kern, mail, named, ntpd, security, user, and asterisk (*). (Specify an asterisk to include all messages written to SYSLOG of the specified priority.)
Each facility represents a different source of system message. The level is the priority level for each message. Possible values ranging from most severe to least severe are panic, emerg, alert, crit, err, error, warn, warning, notice, info, debug, and asterisk (*). (Specify an asterisk to include all messages for the specified level.)
Examples of facility.level statements are:
|
Example |
Description |
|
*.debug |
All debug messages |
|
ntp.info |
Network Time Protocol information messages |
|
gated.warn |
GATED warning messages |
The action is the destination of the message. Possible message destinations include:
|
Destination |
Specified As |
Example |
|
Broadcast (RWALL) |
Asterisk |
* |
|
Console |
Use OPCOM |
/OPCOM |
|
File |
Precede the fully specified file name with a slash |
/USERS:[HOLMES]OUTFILE. |
|
Forwarding |
Precede the IP address or host name with an at sign (@) |
@192.92.38.1 |
|
OPCOM |
Precede with a slash |
/OPCOM |
|
Terminal |
Precede the terminal name with a slash and end name with a colon |
/TXA3: |
Each message handled by SYSLOG includes a time stamp, the facility name at the beginning of the message, and a newline character at the end of the message.
Comments are entered in the SYSLOG.CONFIGURATION file as pound signs (#) at the beginning of the line.
Some example SYSLOG.CONFIGURATION file entries are shown below:
# SYSLOG.CONFIGURATION examples
#
# Each entry is tab-separated and has this form:
# selector action
#
*.debug /OPCOM
kern.panic;kern.warning /OPCOM
syslog.info /users:[treefrog]syslog_info_messages.
*.error @forwardhost
user.* /users:[treefrog]all_user_messages.
