Rights identifiers are labels used to identify a specific agent or a group of agents. An agent is the initiator of a call; it can be a specific user or an application program. For example, you could create the following rights identifiers:

The way X.25 Security obtains rights identifiers for outgoing calls depends upon the type of system you are using:

Access levels are defined by X.25 Security and specify the access to particular objects for a specific agent or group of agents. An object can be:

You grant access to an object by creating an Access Control List (ACL) in which you specify the rights identifiers of an agent and the access to the associated object that you want that agent to have. Table 1.1, “Access Levels” shows the type of access you can specify and its meaning.

Table 1.2, “Agents and Objects” summarizes the relationships between call types, agents, and objects on which security is applied for each type of system.

An Access Control List (ACL) consists of one or more Access Control Entries (ACEs) that grant or deny an agent access to a particular system object.

Each ACE contains an Identifier field that defines one or more agents (using their rights identifiers), and an associated Access field that defines the level of access to be given to the specified agents.

An ACL has the following format:

acl {[ Identifier = { rights-identifiers1 }, Access = access-level1 ],
     [ Identifier = { rights-identifiers2 }, Access = access-level2 ],
     ... }

This format shows that each ACE consists of a set of rights identifiers followed by an access level (refer to Section 1.3.2, “Objects and Their Access Levels” for details of specifying access levels).

A set of rights identifiers can contain one or more identifiers. For example, the following ACL has two ACEs each having a single rights identifier:

{[Identifier={CALL_AUSTPAC},Access=All],[Identifier={*},Access=None]}

In this example, agents with the rights identifier of CALL_AUSTPAC have the access level All. Agents with any other rights identifier (indicated by the wildcard *) have the access level None.

As a further example, consider the following ACL:

    {[Identifier={CALL_AUSTPAC, PAYROLL, OUT_REV},Access=All],
     [Identifier={*},Access=None]} 

In this example, agents with the rights identifiers CALL_AUSTPAC, PAYROLL, and OUT_REV have the access level All. Any agent not possessing all the rights identifiers in the first ACE has the access level None.

Any pair of the following delimiters can be used when defining an ACL:

      ( )       { }       [ ] 

For example, any of the following ACL formats are valid:

acl ([ Identifier = { rights-identifiers1 }, Access = access-level1 ],
     [ Identifier = { rights-identifiers2 }, Access = access-level2 ], 
     ... )
acl {( Identifier = ( rights-identifiers1 ), Access = access-level1 ),
     ( Identifier = ( rights-identifiers2 ), Access = access-level2 ), 
     ... }
acl {[ Identifier = [ rights-identifiers1 ], Access = access-level1 ],
     ( Identifier = { rights-identifiers2 }, Access = access-level2 ), 
     ... }

Throughout the rest of this manual, the convention used for the delimiters is that shown in the ACL format at the start of this section.

In addition to the standard X.25 security entities, access to an X.25 for OpenVMS system is controlled by two rights identifiers:

These rights identifiers must be defined in the System Rights Database using the OpenVMS AUTHORIZE utility before the X.25 for OpenVMS software is loaded. If the identifiers are not defined before the software is loaded, but are defined subsequently, they have no effect and users require only NETMBX privilege to send calls via X.25 for OpenVMS.

Details of how X.25 Security handles system service requests using these rights identifiers are given in Appendix C, X.25 Security-Specific Identifiers.

This section describes how X.25 Security verifies an incoming call to an X.25 Direct Connect system, that is, a call from a remote DTE to the local DTE.

In the example shown in Figure 3.1, “Example Incoming Call (X.25 Direct Connect Systems)”, remote DTE REM1 (DTE address 123412345678) is attempting to make a call to an enquiry database on the local DTE LOC1. Security on the local DTE is set up as shown in Figure 3.2, “Local DTE Security (incoming calls)”.

The security set up shown in Figure 3.2, “Local DTE Security (incoming calls)” means that:

When an incoming call arrives for the local DTE, X.25 Security selects the REMOTE DTE entity having the RAP that most closely matches the calling DTE address. Then, X.25 Security assigns the rights identifiers from the selected REMOTE DTE entity to the incoming call. The DTE address matching process is described more fully in Section 3.5, “Remote DTE Entity Selection”.

In the example shown in Figure 3.1, “Example Incoming Call (X.25 Direct Connect Systems)” and Figure 3.2, “Local DTE Security (incoming calls)”, the best match for remote DTE REM1 (DTE address 123412345678) is the RAP 1234123*. This means that rights identifier use_enquiry_db is assigned to the incoming call.

Once X.25 Security has assigned rights identifiers to the calling DTE, it:

ACL matching is described in Section 3.6, “The ACL Matching Procedure”.

In the above example, the use_enquiry_db rights identifier matches with the first ACE in the ACL of the SECURITY FILTER entity security_enquiry_database. The access level associated with the rights identifier use_enquiry_db is All. This means that the call is permitted (refer to Table 1.1, “Access Levels”).

This section describes how X.25 Security verifies an incoming call to an X.25 Client system, that is, a call from a remote DTE that is forwarded by a Connector system to an X.25 Client system.

In the example shown in Figure 3.3, “Example Incoming Call (X.25 Client Systems)”, remote DTE REM1 (DTE address 123412345678) is attempting to make a call to an enquiry database on X.25 Client system CLT1 via Connecter system GTWY1. Security on the X.25 Client system (the local DTE) is identical to that shown in Figure 3.2, “Local DTE Security (incoming calls)”.

When an incoming call arrives for the X.25 Client system via the Connector system, X.25 Security selects the REMOTE DTE entity having the RAP that most closely matches the calling DTE address. Then, X.25 Security assigns the rights identifiers from the selected REMOTE DTE entity to the incoming call. The DTE address matching process is described more fully in Section 3.5, “Remote DTE Entity Selection”.

In the above example, the best match for remote DTE REM1 (DTE address 123412345678) is the RAP 1234123*. This means that rights identifier use_enquiry_db is assigned to the incoming call.

Once X.25 Security has assigned rights identifiers to the calling DTE, it:

ACL matching is described in Section 3.6, “The ACL Matching Procedure”.

In the above example, the use_enquiry_db rights identifier matches with the first ACE in the ACL of the SECURITY FILTER entity security_enquiry_database. The access level associated with the rights identifier use_enquiry_db is All. This means that the call is permitted (refer to Table 1.1, “Access Levels”).

This section explains how X.25 Security verifies an outgoing call from an X.25 Direct Connect system, that is, from a local DTE connected directly to a PSDN.

In Figure 3.4, “Example Outgoing Call (X.25 Direct Connect System)” a user of the local DTE LOC1 is attempting to call remote DTE REM1 (DTE address 123412345678). Security is set up as shown in Figure 3.5, “Local DTE Security (outgoing calls)”.

On the local DTE, X.25 Security looks in the file SYS$SYSTEM:RIGHTSLIST.DAT for the rights identifiers associated with the user’s process. For this example, the rights identifier associated with the user’s process is SYS.

X.25 Security then:

If the verifications are successful, the call is passed to the PSDN.

To summarize the preceding example, remote DTE REM1 (DTE address 123412345678) matches the REMOTE DTE entity having a RAP of 1234123*. The rights identifier SYS matches with the first ACE in the ACL. The access level associated with the rights identifier SYS is Access = ALL, which means that the call is permitted.

For outgoing calls from an X.25 Client system, X.25 Security performs two verifications; one at the X.25 Client system and one at the Connector system.

In the example shown in Figure 3.6, “Example Outgoing Call from an X.25 Client System”, X.25 Client system CLT1 is attempting to make a call to remote DTE REM1 (DTE address 123412345678) through Connector system GTWY1.

Security on the X.25 Client system is set up as shown in Figure 3.7, “X.25 Client System Security”.

X.25 Security looks in SYS$SYSTEM:RIGHTSLIST.DAT for the rights identifiers associated with the process. X.25 Security then:

If the verifications are successful, the call is passed to the Connector system.

To summarize the preceding example, DTE CLASS entity branch_link is used for the outgoing call. Associated with this DTE class is SECURITY DTE CLASS entity client_branch_link which has three SECURITY DTE CLASS REMOTE DTE entities. Remote DTE 123412345678 best matches the REMOTE DTE entity with a RAP of 1234123*. The SYS rights identifier of the process that initiated the call matches with the first ACE in the ACL of RAP 1234123*. The Access field of this ACE is Access = All, which means that the call is permitted by the X.25 Client system and is forwarded to the Connector system.

Security on the Connector system is set up as shown in Figure 3.8, “Connector System Security”.

At the Connector system, X.25 Security performs another verification. Each Connector system has one or more SECURITY NODES entities, which contain DECdns node names and the rights identifiers associated with them. The DECdns node names are the names of the X.25 Client systems to be granted the associated rights identifiers.

When an outgoing call reaches a Connector system, X.25 Security:

To summarize the preceding example, the agent on X.25 Client system CLT1 is given the rights identifiers call_branch at the Connector system. Remote DTE 12312345678 best matches the REMOTE DTE entity with a RAP of 1234123*. The call_branch rights identifier matches with the first ACE in the ACL. The Access field of this ACE is Access = All, which means that the call is permitted by the Connector system and is sent to the remote DTE.

A null ACL is an ACL without entries and is represented using the following format:

    { } 

A null ACL does not allow any agents to have access to the objects it protects and is equivalent to the following match-all ACL:

    {[Identifier = {*}, Access = None]}

This ACL has a wildcard rights identifier that matches any set of agent rights identifiers and an access level that does not permit calls to be accepted.

Whenever an entity is created, it is assigned a null ACL. This ensures that system objects have maximum protection as soon as the associated entities are created. The null ACL remains in effect until an alternative, more specific, ACL is defined (set) for the entity.

If no rights identifiers have been defined for a remote DTE, that DTE is said to have a null rights identifier.

Null rights identifiers match wildcard ACEs. For example, if the following ACE has been defined:

    {[Identifier = {*}, Access = level]} 

then the wildcard ( * ) matches all occurrences of zero or more characters and therefore encompasses the null rights identifier. In this case, the access level given to the null rights identifier is specified by level, where level is All, Remote_Charge, or None.

The order of ACEs in an ACL is important. The ACL matching algorithm searches each ACE in turn for the first rights identifier match it can find. When a match is found, the search is terminated. If a match occurs in an ACE specified later in the ACL, it is ignored.

ACLs can be created to provide several levels of protection to system objects. However, care must be taken to position ACEs in an ACL so that the greatest protection occurs nearest the end of the ACL. For example, you may want to apply greater protection to calls that you pay for than to calls that the remote DTE pays for. In this case, you would define ACEs in the ACL of the REMOTE DTE entity in the order shown in Figure 3.10, “The Ordering of ACL Entries”.

The ACEs in Figure 3.10, “The Ordering of ACL Entries” ensure that:

If you have the same security requirements for all the filters on your system, you need only create one SECURITY FILTER entity. In this security filter, specify an ACL to control access. Once you have defined the security filter, you will need to modify the Security Filter characteristic of each FILTER entity so that it points to the defined security filter.

If you have different security requirements for different filters, you should create more than one security filter. For example, suppose you have defined two filters, called x29 and app, that listen for calls to applications x.29 and app and you want to allow all agents to use application app but restrict access to application x.29. In this case, you should set up the following SECURITY FILTER entities:

By using several security filters, you can clearly define the security requirements for each filter.

The following example details the NCL commands required to set up incoming call security for the example just described:

ncl> create x25 access security filter APP_SECURITY
ncl> set x25 access security filter APP_SECURITY ACL -
_ncl> {[Identifier={*}, Access=All]}
ncl> create x25 access security filter X29_SECURITY
ncl> set x25 access security filter X29_SECURITY ACL -
_ncl> {[Identifier={USE_X29}, Access=All], [Identifier={*}, Access=None]}
ncl> set x25 Access filter APP security filter APP_SECURITY
ncl> set x25 Access filter x29 security filter x29_SECURITY
ncl>

Each SECURITY DTE CLASS entity is a parent for the SECURITY DTE CLASS REMOTE DTE entities associated with it. You can create one or more SECURITY DTE CLASS entities on your system.

The number of REMOTE DTE entities you need to set up depends on your security requirements. For example, if you want all the DTEs in a particular network to have the same rights identifiers and be controlled by the same ACL, you can set up a single REMOTE DTE entity having the Data Network Identification Code (DNIC) of the network. Note that DNICs apply only to public networks.

If you want to specify different security levels for different DTEs or groups of DTEs you need to set up REMOTE DTE entities for several DTE address prefixes. For example, you could create REMOTE DTE entities with the following prefixes:

123412345678   
123412345677
1234123*       
1234113*
1234*          

In general, the finer the security control required, the greater the number of REMOTE DTE entities that must be defined.

SECURITY DTE CLASS entities should be set up using the X.25 for OpenVMS configuration program. See Section 4.1, “Introduction” for information about using the X.25 configuration program.

Alternatively, NCL commands can be issued interactively. For example, suppose you want to set up outgoing security to a DTE class called galaxy so that only users with the rights identifier AUSTPAC are permitted to make calls. This can be achieved using the following NCL commands:

ncl> create x25 access security dte class sec-1                
ncl> create x25 access security dte class sec-1 -
_ncl> remote dte FRED remote address prefix 1234               
ncl> set x25 access security dte class sec-1 remote -
_ncl> dte fred acl {[Identifier = {AUSTPAC}, Access = All]}    
ncl> set x25 access dte class galaxy security dte class sec-1  

Security information is part of an X25 PROTOCOL DTE PVC entity. You need to work out who you want to be able to use a PVC and then set up an ACL to control access.

Note that for PVCs, the REMOTE_CHARGE access level provides the same access as ALL.

Bilateral Closed User Groups (BCUGs) differ from CUGs in that they consist of only two DTEs, one of which is a member of a GROUP entity on the local system. Therefore, the remote DTE is uniquely identified by the use of the BCUG; no remote DTE address is necessary. However, for local security purposes, the address of the remote DTE address must be known. To set up BCUG group security, you must define in the GROUP entity the exact DTE address of the remote DTE in the specified BCUG. In this sense, even though they do not directly contain rights identifiers or ACLs, BCUG GROUP entities indirectly control security on the local system.

BCUG group security should be set up using the X.25 configuration program. See Section 4.1, “Introduction” for information about using the X.25 configuration program.

Alternatively, you can enter NCL commands interactively. For example, to define group security for BCUG bistar that contains this system and another system having the DTE address 123456, enter the following commands:

ncl> create x25 protocol group bistar                         
ncl> set x25 protocol group bistar type bcug                  
ncl> set x25 protocol group bistar remote dte address 123456  

An event log contains messages that record changes in the status of the system. For example, every time security blocks an incoming call, an event message is logged. Event logging is the primary tool for monitoring and problem solving your system. The VSI DECnet-Plus for OpenVMS Network Management Guide describes how to set up event logging on your system. X.25 Security-specific events are described in Appendix B, X.25 Security Events.

The X25 Access module maintains several security counters which record the number of times security blocked access to or from your system. The X25 Access counters are described in Table 5.1, “X.25 Access Module Security Counters”.

In addition to the counters maintained by X25 Access, some of the X.25 Security entities maintain counters. These counters are described in Table 5.2, “Entity-Specific Security Counters”.

You can find out about security problems on your system in three ways:

If you notice a security problem, look at the event that was generated.

If the problem was caused by an incoming call:

If the problem was caused by an outgoing call:

The SECURITY DTE CLASS and the SECURITY FILTER entities have the status attributes shown in Table 5.3, “Status Attributes”.

Use these status attributes to verify your security set-up. For example, the following command displays the DTE CLASS entities guarded by the SECURITY DTE CLASS entity x121:

ncl> show x25 access security dte class x121 all status

If you have set up match-all ACLs, for example, to block calls from particular countries, you will have set up ACLs similar to the following example:

{[Identifier = {*}, Access = None]}

If you have ACLs like this associated with short remote address prefixes (for example, DNIC only) and you find a large number of incoming call blocked events, you will need to locate the specific DTEs attempting to break into your system. Look at the event log to find out which remote DTE is attempting to break into your system. Monitor the specific remote DTE by setting up a REMOTE DTE entity with the full DTE address of the suspect DTE as the RAP. Specify no access on the ACL you associate with the RAP. For example:

ncl> create x25 access security -
_ncl> dte class bill remote dte catch-hacker -
_ncl> remote address prefix 123412345678
ncl> set x25 access security dte -
_ncl> class bill remote dte catch-hacker acl -
_ncl> {[Identifier = {*}, Access = None]}

If you do not have the event logs available, you can find out a specific remote DTE by a process of elimination. For example, if you have a large number of incoming access blocked events on a REMOTE DTE entity with the RAP 1234, determine the address of the remote DTE attempting to break-in as follows: