Controlling Security on a Network

From the perspective of security, networked systems are more vulnerable than standalone systems. Networking increases system accessibility, but also add greater risk of security violations.

While you cannot control security over the network, you can control the security of each node on the network to limit penetration risk without reducing the usefulness of the system or user productivity.

All network administration programs should be owned by a protected, network-specific account, such as uucp, nso, or daemon, rather than root.

Controlling an Administrative Domain

An administrative domain is a group of systems connected by network services that allow users to access one another without password verification. An administrative domain assumes system users have already been verified by their host machine. Follow these steps to identify and control an administrative domain.

List the nodes to which you export file systems in /etc/exports.
/etc/exports contains entries that consist of the path name of a file system followed by a list of computers or groups of computers allowed access to the file system. Any entry consisting of only a path name without being followed by a computer name is a file system available to every computer on the network.
The /etc/exports entries might contain names of groups of computers. You can find out what individual machines are included in a group by checking /etc/netgroup.
List the nodes that have equivalent password data bases in /etc/hosts.equiv.
Verify that each node in the administrative domain does not extend privileges to any unincluded nodes.
You must repeat steps 2 and 3 for each node in the domain.
Control root and local security on every node in your administrative domain. A user with superuser privileges on any machine in the domain can acquire those privileges on every machine in the domain.
Maintain consistency of user name, uid, and gid among password files in your administrative domain.
Maintain consistency among any group files on all nodes in your administrative domain.
For example, if you are working on system hq and you wish to check consistency with system mfg, and mfg’s root file system is remotely mounted to hq as /nfs/mfg/, enter
diff /etc/group /nfs/mfg/etc/group
If you see any output, your two /etc/group files are inconsistent.

Verifying Permission Settings on Network Control Files

Modes, owners, and groups on all system files are set carefully. All deviations from these values should be noted and corrected.

Pay particular attention to network control files, which reside in /etc, and are notable targets because they provide access to the network itself. Network control files should never be writable by the public. Among them are:

exports: List of file systems being exported to NFS clients
hosts: Network hosts and their addresses
hosts.equiv: Remote hosts allowed access equivalent to the local host
inetd.conf: Internet configuration file
netgroup: List of network-wide groups
networks: Network names and their addresses
protocols: Protocol name database
services: Services name database

Understanding Network Services

HP-UX provides various networking services, each providing a means of authentication, either through password verification or authorization set up in a file on the remote system.

Table 8-2 Access Verification for Network Services

Network service	Access verification
ftp	Password verification. See ftp(1).
mount	Entry in `/etc/exports`. See mount(1M).
rcp	Entry in `.rhosts` or `hosts.equiv` file. See rcp(1).
remsh	Entry in `.rhosts` or `hosts.equiv` file. See remsh(1).
rlogin	Password verification or entry in `.rhosts` or `hosts.equiv` file. See rlogin(1).
telnet	Password verification. If the TAC User ID option is enabled by telnetd, telnet uses the entry in the `.rhosts` or `hosts.equiv` file. See telnet(1) and telnetd(1M).

For information on using the services, refer to the manpage specific to the services. We have identified here some of the major security concerns related to these network services.

Using inetd.sec to Restrict Outside Access

Access control to individual network services can be set in /var/adm/inetd.sec, an optional security file for the Internet daemon. You can explicitly allow or deny use of most networking services by listing them on a per-machine or per-subnet basis.

The syntax of entries in /var/adm/inetd.sec is:

service-name allow|deny {host-address|host-name}...

The service-name is the official name (not an alias) of a valid service in the file /etc/services. The service-name for RPC-based services (NFS) is the official name (not an alias) of a valid service in the file /etc/rpc. The wildcard character * and the range character - are permitted in addresses.

Refer to inetd.sec(4) for complete details on the syntax and use of this file.

Denying Access with /etc/ftpd/ftpusers

ftpd, the file transfer protocol server, is run by the Internet daemon (see inetd(1M)) when a service request is received at the port indicated in /etc/services.

ftpd rejects remote logins to local user accounts named in /etc/ftpd/ftpusers. Each restricted account name must appear by itself on a line in the file. The line cannot contain any spaces or tabs. User accounts with restricted login shells in /etc/passwd should be listed in /etc/ftpd/ftpusers, because ftpd accesses local accounts without using their login shells. uucp accounts should also be listed in /etc/ftpd/ftpusers. If /etc/ftpd/ftpusers does not exist, ftpd skips the security check.




	NOTE: In HP-UX versions prior to 11.`x`, this file is named `/etc/ftpusers`.

Files Mounted in an NFS Environment

A Network File System (NFS) is used to

Save file space
Maintain consistent file usage
Provide a lean cooperative user environment.

NFS streamlines file-sharing between server and client systems by controlling access via the /etc/exports file. Entries in /etc/exports provide permission to mount a file system existing on the server onto any client machine or a specified list of machines. Once a file system is put into /etc/exports, the information is potentially available to anyone who can do an NFS mount. Thus, the NFS client user can access a server file system without having logged into the server system. See “Managing File Systems” for more information. See also exports(4) for further information on controlling access to exported file systems.

Server Vulnerability

Server security is maintained by setting restrictive permissions on the file /etc/exports. Root privileges are not maintained across NFS. Thus, having root privileges on a client system does not provide you with special access to the server.

The server performs the same permission checking remotely for the client as it does locally for its own users. The server side controls access to server files by the client by comparing the user ID and group ID of the client, which it receives via the network, with the user ID and group ID of the server file. Checking occurs within the kernel.

A user with privileges on an NFS client can exploit that privilege to obtain unlimited access to an NFS server. Never export any file system to a node on which privilege is granted more leniently than from your own node’s policy!

Client Vulnerability

In earlier releases of NFS for workstations, the /dev inode had to reside on the client’s disk. NFS now allows for the /dev inode containing the major and minor numbers of a client-mounted device to exist on the server side. This opens the possibility for someone to create a Trojan Horse that overrides permissions set on the client’s mounted device, by accessing the device via the file and inode number found on the server side.

Although lacking permission to make a device file on the client side, a system violator wanting to sabotage the client can create an undermining device file, such as /dev/kmem, using root permissions on the server side. The new /dev file is created with the same major and minor number as that of the target device on client side, but with the following permissions: crw-rw-rw-.

The violator can then go to the client, log in as an ordinary user, and, using NFS, open up the newly created server-side device file and use it for devious means — to wipe out kernel memory on the server, read contents of everyone’s processes, or other mischief.

How to Safeguard NFS-Mounted Files

If possible, make sure that the same person administers both client and server systems.
Maintain uniformity of user ID and group ID for server and client systems.
Stay vigilant of /dev files in file systems exported from server.
Restrict write access to the /etc/passwd and /tcb/files/auth/*/* client files.
For strictest control, audit every host that is accessible through the network.

Link-Level Access

Link-level access is a very powerful facility that permits a programmer to access the link driver on the host directly. In the wrong hands, this capability can enable an ordinary user to fabricate any network packet, including network control packets.

To protect link-level access, make sure that the files /dev/ether*, /dev/ieee*, and /dev/lan* are owned and writable only by root. See “Security Considerations for Device Files”.




	CAUTION: On HP-UX 11.0 and later systems, `/dev/lan` has a symbolic link to `/dev/dlpi`; changing permissions on `/dev/lan` causes the permissions on `/dev/dlpi` to be changed as well. However, any DCE/RPC applications that do not run as UID 0 may require write access to `/dev/dlpi`. Therefore, the permissions of 644 on `/dev/dlpi` breaks these applications. Due to needing write access, for DCE/RPC applications that do not run as UID 0, the permissions for `/dev/dlpi` should be 666. For more information on `/dev/dlpi`, see the manual Installing and Administering LAN/9000 Software.