If you installed the Transmission Control Protocol/Internet Protocol (TCP/IP) and Network File System (NFS) software, you can configure your system to communicate over a network. This guide does not describe the basic concepts of TCP/IP, but rather describes security-related concerns of TCP/IP. For information on installing and the initial configuration of TCP/IP, refer to the Transmission Control Protocol/Internet Protocol chapter in AIX 5L Version 5.2 System Management Guide: Communications and Networks.
For any number of reasons, the person who administers your system might have to meet a certain level of security. For instance, the security level might be a matter of corporate policy. Or a system might need access to government systems and thus be required to communicate at a certain security level. These security standards might be applied to the network, the operating system, application software, even programs written by the person who administers your system.
This chapter describes the security features provided with TCP/IP, both in standard mode and as a secure system, and discusses some security considerations that are appropriate in a network environment.
After you install TCP/IP and NFS software, use the Web-based System Manager or the System Management Interface Tool (SMIT) tcpip fast path, to configure your system.
This chapter discusses the following topics:
Many of the security features available for TCP/IP are based on those available through the operating system. The following sections outline TCP/IP security.
The security policy for networking is an extension of the security policy for the operating system, and it consists of the following major components:
Network auditing is provided by TCP/IP, using the audit subsystem to audit both kernel network routines and application programs. The purpose of auditing is to record those actions that affect the security of the system and the user responsible for those actions.
The following types of events are audited:
Creation and deletion of objects are audited by the operating system. Application audit records suspend and resume auditing to avoid redundant auditing by the kernel.
The operating system provides the trusted path to prevent unauthorized programs from reading data from a user terminal. This path is used when a secure communication path with the system is required, such as when you are changing passwords or logging in to the system. The operating system also provides the trusted shell (tsh), which executes only trusted programs that have been tested and verified as secure. TCP/IP supports both of these features, along with the secure attention key (SAK), which establishes the environment necessary for secure communication between you and the system. The local SAK is available whenever you are using TCP/IP. A remote SAK is available through the telnet command.
The local SAK has the same function in telnet that it has in other operating system application programs: it ends the telnet process and all other processes associated with the terminal in which telnet was running. Inside the telnet program, however, you can send a request for a trusted path to the remote system using the telnet send sak command (while in telnet command mode). You can also define a single key to initiate the SAK request using the telnet set sak command.
For more information about the Trusted Computing Base, see The Trusted Computing Base.
Some commands in TCP/IP provide a secure environment during operation. These commands are ftp, rexec, and telnet. The ftp function provides security during file transfer. The rexec command provides a secure environment for running commands on a foreign host. The telnet function provides security for login to a foreign host.
The ftp, rexec, and telnet commands provide security during their operation only. That is, they do not set up a secure environment for use with other commands. For securing your system for other operations, use the securetcpip command. This command gives you the ability to secure your system by disabling the nontrusted daemons and applications, and by giving you the option of securing your IP layer network protocol as well.
The ftp, rexec, securetcpip, and telnet commands provide the following forms of system and data security:
| ftp | The ftp command provides a secure
environment for transferring files. When a user invokes the ftp command to a foreign host, the user is prompted for a login ID. A
default login ID is shown: the user's current login ID on the local host.
The user is prompted for a password for the remote host.
The automatic login process searches the local user's $HOME/.netrc file for the user's ID and password to use at the foreign host. For security, the permissions on the $HOME/.netrc file must be set to 600 (read and write by owner only). Otherwise, automatic login fails. Note: Because use of the .netrc file requires storage of passwords in a nonencrypted file, the automatic login feature of the ftp command is not available when your system has been configured with the securetcpip command. This feature can be reenabled by removing the ftp command from the tcpip stanza in the /etc/security/config file. To use the file transfer function, the ftp command requires two TCP/IP connections, one for the File Transfer Protocol (FTP) and one for data transfer. The protocol connection is primary and is secure because it is established on reliable communicating ports. The secondary connection is needed for the actual transfer of data, and both the local and remote host verify that the other end of this connection is established with the same host as the primary connection. If the primary and secondary connections are not established with the same host, the ftp command first displays an error message stating that the data connection was not authenticated, and then it exits. This verification of the secondary connection prevents a third host from intercepting data intended for another host. |
| rexec | The rexec command provides a
secure environment for executing commands on a foreign host. The user is prompted
for both a login ID and a password.
An automatic login feature causes the rexec command to search the local user's $HOME/.netrc file for the user's ID and password on a foreign host. For security, the permissions on the $HOME/.netrc file must be set to 600 (read and write by owner only). Otherwise, automatic login fails. Note: Because use of the .netrc file requires storage of passwords in a nonencrypted file, the automatic login feature of rexec is not available when your system is operating in secure. This feature can be reenabled by removing the rexec entry from the tcpip stanza in the /etc/security/config file. |
| securetcpip | The securetcpip command enables TCP/IP security
features. Access to commands that are not trusted is removed from the system
when this command is issued. Each of the following commands is removed by
running the securetcpip command:
The securetcpip command is used to convert a system from the standard level of security to a higher security level. After your system has been converted, you need not issue the securetcpip command again unless you reinstall TCP/IP. |
| telnet or tn | The telnet (TELNET) command provides a secure environment for login to a foreign host. The user is prompted for both a login ID and a password. The user's terminal is treated just like a terminal connected directly to the host. That is, access to the terminal is controlled by permission bits. Other users (group and other) do not have read access to the terminal, but they can write messages to it if the owner gives them write permission. The telnet command also provides access to a trusted shell on the remote system through the SAK. This key sequence differs from the sequence that invokes the local trusted path and can be defined within the telnet command. |
Users on the hosts listed in the /etc/hosts.equiv file can run certain commands on your system without supplying a password. The following table provides information about how to list, add, and remove remote hosts using Web-based System Manager, SMIT, or command line.
| Task | SMIT fast path | Command or file | Web-based System Manager Management Environment |
|---|---|---|---|
| List Remote Hosts That Have Command Execution Access | smit lshostsequiv | view /etc/hosts.equiv file | Software --> Network --> TCPIP (IPv4 and IPv6) --> TCPIP Protocol Configuration --> TCP/IP --> Configure TCP/IP --> Advanced Methods --> Hosts File --> Contents of /etc/hosts file. |
| Add a Remote Host for Command Execution Access | smit mkhostsequiv | edit /etc/hosts.equiv fileNote 1 | Software --> Network --> TCPIP (IPv4 and IPv6) --> TCPIP Protocol Configuration --> TCP/IP --> Configure TCP/IP --> Advanced Methods --> Hosts File. In Add/Change host entry, complete the following fields: IP Address, Host name, Alias(es), and Comment. Click Add/Change Entry, and click OK. |
| Remove a Remote Host from Command Execution Access | smit rmhostsequiv | edit /etc/hosts.equiv fileNote 1 | Software --> Network --> TCPIP (IPv4 and IPv6) --> TCPIP Protocol Configuration --> TCP/IP --> Configure TCP/IP --> Advanced Methods --> Hosts File. Select a host in Contents of /etc/host file. Click Delete Entry --> OK. |
Users listed in the /etc/ftpusers file are protected from remote FTP access. For example, suppose that user A is logged into a remote system, and he knows the password of user B on your system. If user B is listed in the /etc/ftpusers file, user A cannot FTP files to or from user B's account, even though user A knows user B's password.
The following table provides information about how to list, add, and remove restricted users using Web-based System Manager, SMIT, or command line.
| Task | SMIT fast path | Command or file | Web-based System Manager Management Environment |
|---|---|---|---|
| List Restricted FTP Users | smit lsftpusers | view /etc/ftpusers file | Software --> Users --> All Users. |
| Add a Restricted User | smit mkftpusers | edit /etc/ftpusers fileNote 1 | Software --> Users --> All Users --> Selected --> Add this User to Group. Select a group, and click OK. |
| Remove a Restricted User | smit rmftpusers | edit /etc/ftpusers fileNote 1 | Software --> Users --> All Users --> Selected --> Delete. |
A trusted program, or trusted process, is a shell script, a daemon, or a program that meets a particular standard of security. These security standards are set and maintained by the U.S. Department of Defense, which also certifies some trusted programs.
Trusted programs are trusted at different levels. Security levels include A1, B1, B2, B3, C1, C2, and D, with level A1 providing the highest security level. Each security level must meet certain requirements. For example, the C2 level of security incorporates the following standards:
TCP/IP contains several trusted daemons and many nontrusted daemons.
Examples of trusted daemons are as follows:
Examples of nontrusted daemons are as follows:
For a system to be trusted, it must operate with a trusted computing base; that is, for a single host, the machine must be secure. For a network, all file servers, gateways, and other hosts must be secure.
The Network Trusted Computing Base (NTCB) consists of hardware and software for ensuring network security. This section defines the components of the NTCB as they relate to TCP/IP.
The hardware security features for the network are provided by the network adapters used with TCP/IP. These adapters control incoming data by receiving only data destined for the local system and broadcast data receivable by all systems.
The software component of the NTCB consists of only those programs that are considered as trusted. The programs and associated files that are part of a secure system are listed in the following tables on a directory-by-directory basis.
| Name | Owner | Group | Mode | Permissions |
|---|---|---|---|---|
| gated.conf | root | system | 0664 | rw-rw-r-- |
| gateways | root | system | 0664 | rw-rw-r-- |
| hosts | root | system | 0664 | rw-rw-r-- |
| hosts.equiv | root | system | 0664 | rw-rw-r-- |
| inetd.conf | root | system | 0644 | rw-r--r-- |
| named.conf | root | system | 0644 | rw-r--r-- |
| named.data | root | system | 0664 | rw-rw-r-- |
| networks | root | system | 0664 | rw-rw-r-- |
| protocols | root | system | 0644 | rw-r--r-- |
| rc.tcpip | root | system | 0774 | rwxrwxr-- |
| resolv.conf | root | system | 0644 | rw-rw-r-- |
| services | root | system | 0644 | rw-r--r-- |
| 3270.keys | root | system | 0664 | rw-rw-r-- |
| 3270keys.rt | root | system | 0664 | rw-rw-r-- |
| Name | Owner | Group | Mode | Permissions |
|---|---|---|---|---|
| host | root | system | 4555 | r-sr-xr-x |
| hostid | bin | bin | 0555 | r-xr-xr-x |
| hostname | bin | bin | 0555 | r-xr-xr-x |
| finger | root | system | 0755 | rwxr-xr-x |
| ftp | root | system | 4555 | r-sr-xr-x |
| netstat | root | bin | 4555 | r-sr-xr-x |
| rexec | root | bin | 4555 | r-sr-xr-x |
| ruptime | root | system | 4555 | r-sr-xr-x |
| rwho | root | system | 4555 | r-sr-xr-x |
| talk | bin | bin | 0555 | r-xr-xr-x |
| telnet | root | system | 4555 | r-sr-xr-x |
| Name | Owner | Group | Mode | Permissions |
|---|---|---|---|---|
| arp | root | system | 4555 | r-sr-xr-x |
| fingerd | root | system | 0554 | r-xr-xr-- |
| ftpd | root | system | 4554 | r-sr-xr-- |
| gated | root | system | 4554 | r-sr-xr-- |
| ifconfig | bin | bin | 0555 | r-xr-xr-x |
| inetd | root | system | 4554 | r-sr-xr-- |
| named | root | system | 4554 | r-sr-x-- |
| ping | root | system | 4555 | r-sr-xr-x |
| rexecd | root | system | 4554 | r-sr-xr-- |
| route | root | system | 4554 | r-sr-xr-- |
| routed | root | system | 0554 | r-xr-x--- |
| rwhod | root | system | 4554 | r-sr-xr-- |
| securetcpip | root | system | 0554 | r-xr-xr-- |
| setclock | root | system | 4555 | r-sr-xr-x |
| syslogd | root | system | 0554 | r-xr-xr-- |
| talkd | root | system | 4554 | r-sr-xr-- |
| telnetd | root | system | 4554 | r-sr-xr-- |
| Name | Owner | Group | Mode | Permissions |
|---|---|---|---|---|
| tn | root | system | 4555 | r-sr-xr-x |
| Name | Owner | Group | Mode | Permissions |
|---|---|---|---|---|
| rwho (directory) | root | system | 0755 | drwxr-xr-x |
The security feature for TCP/IP does not encrypt user data transmitted through the network. Therefore, it is suggested that users identify any risk in communication that could result in the disclosure of passwords and other sensitive information, and based on that risk, apply appropriate countermeasures.
Using the TCP/IP security feature in a Department of Defense (DOD) environment might require adherence to DOD 5200.5 and NCSD-11 for communications security.
Discretionary Access Control for Internet Ports (DACinet) features user based access control for TCP ports for communication between AIX 5.2 hosts. AIX 5.2 can use an additional TCP header to transport user and group information between systems. The DACinet feature allows the administrator on the destination system to control access based on the destination port, the originating user id and host.
In addition, the DACinet feature allows the administrator to restrict local ports for root only usage. UNIX systems like AIX treat ports below 1024 as privileged ports which can only be opened by root. AIX 5.2 allows you to specify additional ports above 1024 which can be opened only by root, therefore preventing users from running servers on well known ports.
Depending on the settings a non-DACinet system may or may not be able to connect to a DACinet system. Access is denied in the initial state of the DACinet feature. Once DACinet has been enabled, there is no way to disable DACinet.
The dacinet command accepts addresses which are specified as hostnames, dotted decimal host addresses, or network addresses followed by the length of the network prefix.
The following example specifies a single host which is known by the fully qualified host name host.domain.org:
host.domain.org
The following example specifies a single host which is known by the IP address 10.0.0.1:
10.0.0.1
The following example specifies the entire network which has the first 24 bits (the length of the network prefix) with a value of 10.0.0.0:
10.0.0.0/24
This network includes all IP addresses between 10.0.0.1 and 10.0.0.254.
DACinet uses the /etc/rc.dacinet startup file and the configuration files it used are /etc/security/priv, /etc/security/services, and /etc/security/acl.
Ports listed in /etc/security/services are considered exempt from the ACL checks. The file has the same format as /etc/services. The easiest way to initialize it is to copy the file from /etc to /etc/security and then delete all the ports for which ACLs should be applied. The ACLs are stored in two places. The currently active ACLs are stored in the kernel and can be read by running dacinet aclls. ACLs that will be reactivated at the next system boot by /etc/rc.tcpip are stored in /etc/security/acl. The following format is used:
service host/prefix-length [user|group]
Where the service can be specified either numerically or as listed in /etc/services, the host can be given either as a host name or a network address with a subnet mask specification and the user or group is specified with the u: or g: prefix. When no user or group is specified, then the ACL takes only the sending host into account. Prefixing the service with a - will disable access explicitly. ACLs are evaluated according to the first match. So you could specify access for a group of users, but explicitly deny it for a user in the group by placing the rule for this user in front of the group rule.
The /etc/services file includes two entries with port number values which are not supported in AIX 5.2. The system administrator must remove both lines from that file prior to executing the mkCCadmin command. Remove the following lines from the /etc/services file:
sco_printer 70000/tcp sco_spooler # For System V print IPC sco_s5_port 70001/tcp lpNet_s5_port # For future use
For example, when using DACinet to restrict access to port TCP/25 inbound to root only with the DACinet feature, then only root users from other AIX 5.2 hosts can access this port, therefore limiting the possibilities of regular users to spoof e-mail by just telneting to port TCP/25 on the victim. The following example shows how to configure the X protocol (X11) for root only access. Make sure that the X11 entry in /etc/security/services is removed, so that the ACLs will apply for this service.
Assuming a subnet of 10.1.1.0/24 for all the connected systems, the ACL entries to restrict access to the root user only for X (TCP/6000) in /etc/security/acl would be as follows:
6000 10.1.1.0/24 u:root
When limiting Telnet service to users in the group friends, no matter from which system they are coming from, use the following ACL entry after having removed the telnet entry from /etc/security/services:
telnet 0.0.0.0/0 g:friends
Disallow user fred access to the web server, but allow everyone else access:
-80 0.0.0.0/0 u:fred 80 0.0.0.0/0
Normally any user can open any port above 1024. For example, a user could place a server at port 8080, which is quite often used to run Web proxies or at 1080 where one typically finds a SOCKS server. To prevent regular users from running servers at specific ports, these ports can be designated as privileged. The dacinet setpriv command can be used to add privileged ports to the running system. Ports that are to be designated as privileged when the system starts have to be listed in /etc/security/priv.
Ports can be listed in this file either with their symbolic name as defined in /etc/services or by specifying the port number. The following entries would disallow non-root users to run SOCKS servers or Lotus Notes servers on their usual ports:
1080 lotusnote
For more information on the dacinet command, refer to the AIX 5L Version 5.2 Commands Reference.