This chapter describes how to manage incoming access restrictions:
• Incoming access restrictions are used to restrict the hosts (or groups of hosts) allowed access to TCP-based services that the TCPware master server initiates. You can use incoming access restrictions to help secure your host by restricting which hosts have access to its services.
• Outgoing access restrictions apply to outgoing TCP connections made from the TCPware host. You can use them to limit the TCP-based services that TCPware host users can use on other systems. You can base these restrictions on user rights identifiers, or destination IP addresses or ports.
You can also use outgoing access restrictions to log or alarm outgoing connections. Log means that a record is written to the TCPWARE:NETCP.LOG file, which identifies the user and the destination of the connection. Alarm means that this same message is sent to OPCOM. Even if you do not restrict the connections users can make, you might want to log or alarm all attempts.
If the process attempting to open a connection has SYSPRV or BYPASS privilege or is running under a system UIC, outgoing access restrictions are not applied. However, logging and alarming entries are still honored.
Permit or deny incoming access using access lists controlled by commands in the Network Control Utility (NETCU), as follows:
$ NETCU [command]
The commands are:
• ADD ACCESS_LIST
• ADD SERVICE
• MODIFY SERVICE
• REMOVE ACCESS_LIST
• SHOW ACCESS_LISTS
See the NETCU Command Reference for details on each command.
You first set up an access list using the ADD ACCESS_LIST command to specify the hosts or groups of hosts you want to have explicit use of the service. Access lists should be defined in SERVERS.COM. You then define (or modify) a service using the ADD SERVICE (or MODIFY SERVICE) command and use the /ACCESS_LIST qualifier to indicate the access list number. If a host's internet address is not in the permitted list, it cannot use the service. Any connections the host makes to that service are immediately closed. The special /ACCESS_LIST=0 entry means that all users are allowed access to that service.
An implicit DENY is added to the end of each access list, meaning that you need an explicit permit to allow access. Also, an empty access list denies all users access to the service.
Consider the ADD ACCESS_LIST command syntax:
$ NETCU ADD ACCESS_LIST list condition ia mask
The list is the access list number, condition is either DENY or PERMIT, ia is the internet address, and mask is the subnet mask. The mask is the most significant field used to determine the order of entries in the file, followed by DENY before PERMIT conditions, followed by the address.
Often in entries without masks, all DENY entries are listed before all PERMIT entries. If you do use masks, this order can change based on your intent. Consider the following sequence of commands where you want to deny access to a Class C network yet permit access for a particular host on that network:
$ NETCU ADD ACCESS_LIST 1 DENY 192.168.142.0
255.255.255.0 -
_$ /MESSAGE="Sorry, access denied."
$ NETCU ADD ACCESS_LIST 1 PERMIT 192.168.142.25
$ SHOW ACCESS_LISTS
List Condition Internet Address Address Mask Access Denied Message
---- --------- ---------------- ------------ ---------------------
1 PERMIT 192.168.142.25 255.255.255.255 "Sorry, access
denied."
DENY 192.168.142.0 255.255.255.0
The longer mask (255.255.255.255) is more specific about the entry and has priority in the file. That is why the PERMIT entry appears before the DENY entry, so that host 192.168.142.25 has access while other hosts on its Class C network do not.
Note that the Access Denied Message you can add using the /MESSAGE qualifier applies to DENY entries for a particular list. The message appears next to the first list entry in a SHOW ACCESS_LISTS display, even if it is a PERMIT entry as in the previous example.
The following example restricts SMTP server access to hosts only on the local network.
$ NETCU ADD ACCESS_LIST 21 PERMIT local-networklocal-network-mask
$ NETCU MODIFY SERVICE 21 TCP/ACCESS_LIST=21
The following example uses an empty access list to make a service temporarily unavailable:
$ NETCU REMOVE ACCESS_LIST 1
$ NETCU MODIFY SERVICE SMTP TCP/ACCESS_LIST=1
To make the service available again later, use:
$ NETCU MODIFY SERVICE SMTP TCP/ACCESS_LIST=0
The 0 access list is special and means all users are allowed access.
To use outgoing access restrictions, you create a file that contains the list of restrictions. Once you create this file, load it using the SET OUTGOING_ACCESS_RESTRICTIONS command in the Network Control Utility (NETCU). Once loaded, TCPware checks the outgoing access restrictions list whenever an active, outgoing connection attempt is made. If the outgoing access restrictions list permits the access, the connection attempt is allowed. If not, the connection attempt fails with a privilege violation status.
When building an outgoing access restrictions list, be sure to add permit entries for all permitted activity, since an implicit "deny everything else" is always at the end of the list. Therefore, you need an explicit permit entry to allow access.
The format of outgoing access restrictions list entries is as follows:
action ID [destination [mask] [operator port]]
Table 21-1 describes the fields in each entry.
|
Table 21-1 Fields in an Outgoing Access Restrictions File Entry |
||
|
Field... |
With valid values... |
Description |
|
action |
deny log |
Keyword or keyword list (separated by commas; no spaces in
between). Do not use PERMIT together with DENY. Denies access. Logs the access attempt in the NETCP.LOG file. |
|
ID |
username or UIC rights-ID * |
Local user's username or UIC, such as SMITH, [10,100], or [SMITH]. Local user's rights identifier, such as ACCOUNTING. Wildcard used by itself (to mean "anyone") or as in [*,100] or [10,*]. |
|
destination |
Example: |
Destination IP address to check, in dotted-decimal format. If omitted, indicates all destination addresses. |
|
mask |
Example: (This example sets only the first three bytes in the destin-ation address as significant. This restricts access to a class C network.) |
Destination address mask to check, in standard bit mask format. Each bit set indicates that the corresponding bit in the destination field is significant. If omitted, TCPware determines the mask based on whether the host portion is 0; if 0, TCPware uses the network or subnet mask; if not 0, TCPware uses the mask 255.255.255.255 (meaning all bits are significant). |
|
operator |
lt |
Use with the port field: |
|
port |
port-number |
Destination port specification of either the port number (such as 2049 for the NFS port) or the port name (such as SMTP). If a name, must be defined it in the TCPWARE:SERVICES. file. |
The order of the entries in the file is important. TCPware looks at each condition in sequence and stops testing after the first match that involves a permit or deny, ignoring any subsequent condition for an address. To use outgoing access restrictions:
1 Create outgoing access restrictions list entries in a file.
2 Apply the file entries to your system using commands in NETCU.
To create an outgoing access restriction file, edit a file and add entries in the format described. For example, you can set the following outgoing access criteria:
! Log all connections
log * 0.0.0.0 0.0.0.0
! Deny access to SMTP applications over the network
deny * 0.0.0.0 0.0.0.0 eq 25
! Permit all connections to the INTERNET_USER rights identifier only
permit internet_user 0.0.0.0 0.0.0.0
Any number of spaces or tabs can separate each entity. Lines beginning with an exclamation point (!) are comment lines. Use the dash (-) continuation character at the end of a line continuing onto the next.
An implicit deny * (deny all) is the last entry in the file. This means that an explicit permit entry must exist to allow any outgoing access. However, permit access always exists for privileged users (with SYSPRV or BYPASS privilege or running from a system UIC).
In addition, facilities that use a TCPware internal interface are also considered privileged users; for example, any application that uses the PWIPDRIVER interface (such as the PATHWORKS v5 server and the DECnet/OSI product from HP).
Once you load the file using SET OUTGOING_ACCESS_RESTRICTIONS, the outgoing access restrictions indicated in the file go into effect. You can use a subsequent SHOW OUTGOING_ACCESS_RESTRICTIONS command to display the results:
$ NETCU SET OUTGOING_ACCESS_RESTRICTIONS
HOMERRESTRICT.DAT
$ NETCU SHOW OUTGOING_ACCESS_RESTRICTIONS
TCPware(R) for OpenVMS Outgoing Access Restrictions List
Actions Userid Destination Address Destination Mask Port
------- ------ ------------------- ---------------- ----
LOG * 0.0.0.0 0.0.0.0
DENY * 0.0.0.0 0.0.0.0 EQ 25
PERMIT INTERNET_USER 0.0.0.0 0.0.0.0
Use the outgoing access restrictions commands on the NETCU level. The commands are:
• SET OUTGOING_ACCESS_RESTRICTIONS
• SET NOOUTGOING_ACCESS_RESTRICTIONS
• SHOW OUTGOING_ACCESS_RESTRICTIONS
All commands require OPER privilege. The SET OUTGOING_ACCESS_RESTRICTIONS command only affects the running system. To load the outgoing access restrictions each time you start TCPware, you can:
1 Place outgoing access restrictions in the TCPWARE:TCPWARE_OUTGOING_RESTRICTIONS.DAT file (STARTNET loads this file if it exists).
2 Add a SET OUTGOING_ACCESS_RESTRICTIONS command to the TCPWARE:ROUTING.COM file.
See the NETCU Command Reference for details about these commands.
CAUTION! Avoid using the SET OUTGOING_ACCESS_RESTRICTIONS NLA0: command. You can deny all outgoing access.
Examples of how you might use outgoing access restrictions include:
• For service bureaus or sites that want to limit which users are allowed access to TCP-based services, you might consider creating an INTERNET_USER rights identifier, and granting it to those users that purchase or need TCP/IP access. Then, you would create a very simple outgoing access restriction list such as:
permit INTERNET_USER
This list would permit all users with the INTERNET_USER rights identifier to establish TCP connections. Anyone without that rights identifier would not be allowed to establish TCP connections.
Note that users can still send SMTP mail using SMTP-OpenVMS mailer. To disable use of this service, you would need to add ACLs to the TCPWARE:SMTP_MAILSHR.EXE file to allow only users with the INTERNET_USER rights identifier access.
• If you have problems with TELNET users accessing the SMTP port and creating fake mail messages, prevent this by using an outgoing access restriction list:
deny * 0 0 eq smtp
permit *
Note that users can still send and receive SMTP mail using SMTP-OpenVMS (which runs with privileges that allow it to bypass the outgoing access restrictions list).
• If you want to log all outgoing connections:
permit,log *
To alarm all connections, use:
permit,alarm *
You can also log or alarm selected outgoing connections. For example, to log all outgoing SMTP connections:
permit,log * 0 0 eq smtp
permit *
Note that the second entry (permit *) permits all other outgoing connections.