This category includes frameworks or meta services on which larger, more complex applications are built. The types of frameworks typically found in this category are: ■ Naming services, for example, Network Information Services (NIS), NIS+, and
Lightweight Directory Access Protocol (LDAP)
■ Authentication services, for example, Kerberos and LDAP
■ Utility services, such as port mapper used by the Remote Procedure Call (RPC) facility
It is not always clear when an application depends on these types of services. When special adjustments are needed to configure an application, such as when adding it to a Kerberos realm, the dependency is known. However, application dependencies do not always require any added tasks, and the actual dependency might not be documented by the vendor.
One such example is the RPC port mapper. The secure.driver in the Solaris Security Toolkit software disables the RPC port mapper. This action might cause unexpected behavior in other services relying on this service. Based on past experiences, services abort, hang, or fail depending on how well the application’s code is written to handle exception cases. To determine if an application is using the RPC port mapper, use the rpcinfo command. For example:
20384: open("named.local", O_RDONLY) = 5 20384: open("db.192.168.1", O_RDONLY) = 5 20384: open("db.internal.net", O_RDONLY) = 5
CODEEXAMPLE2-5 Determining Which Applications Use RPC # rpcinfo -p
100000 3 tcp 111 rpcbind 100000 4 udp 111 rpcbind 100000 2 udp 111 rpcbind CODE
EXAMPLE 2-4 Determining if a Configuration File Is In Use (Continued) # truss -f -topen,open64 /usr/sbin/in.named 2>&1 | \ grep -v "/usr/lib/.*.so.*"
The service column is populated with information from the /etc/rpc file or a configured naming service, such as LDAP.
If this file does not have an entry for a service, as is often the case for third-party products, the service field might be empty. This makes it more difficult to identify applications registered by other applications.
For example, consider the rusers command. This command relies on the RPC port mapping service. If the RPC port mapper is not running, the rusers command appears to hang. The program eventually times out with the following error message:
This problem occurs because the program cannot communicate with the service. After starting the RPC port mapping service from /etc/init.d/rpc, however, the program immediately yields its result.
As another example, consider the case where the RPC port mapping service is running, and the rusers service is not configured to run. In this case, a completely different response is generated, and it is relatively straightforward to validate.
100024 1 udp 32777 status 100024 1 tcp 32772 status 100133 1 udp 32777 100133 1 tcp 32772 100021 1 udp 4045 nlockmgr 100021 2 udp 4045 nlockmgr 100021 3 udp 4045 nlockmgr 100021 4 udp 4045 nlockmgr 100021 1 tcp 4045 nlockmgr # rusers -a localhost
localhost: RPC: Rpcbind failure
CODEEXAMPLE2-6 Validating rusers Service # rusers -a localhost
localhost: RPC: Program not registered # grep rusers /etc/rpc
CODE
EXAMPLE 2-5 Determining Which Applications Use RPC (Continued) # rpcinfo -p
Chapter 2 Securing Systems: Applying a Methodology 27 Given that the rpcinfo command does not have a registry for the rusers service, it is safe to assume that the service is not configured to run. This assumption is validated by looking at the service entry in the /etc/inet/inetd.conf.
The comment mark (#) at the beginning of the service line indicates that the rusers service is disabled. To enable the service, uncomment the line and send a SIGHUP signal to the /usr/sbin/inetd process as follows.
Note – The pkill command is only available in Solaris OS versions 7 through 10. For other versions, use the ps and kill commands respectively to find and signal the process.
Another way to determine if an application uses the RPC facility is to use the ldd command described earlier.
The entry for librpcsvc.so.1 indicates, along with the file name, that this service relies on the RPC port mapping service.
rusersd 100002 rusers # rpcinfo -p | grep rusers <No output generated>
# grep rusers /etc/inet/inetd.conf
# rusersd/2-3 tli rpc/datagram_v,circuit_v wait root /usr/lib/netsvc/rusers/rpc.rusersd rpc.rusersd
# pkill -HUP inetd
CODEEXAMPLE2-7 Alternative Method for Determining Applications That Use RPC # ldd /usr/lib/netsvc/rusers/rpc.rusersd libnsl.so.1 => /usr/lib/libnsl.so.1 librpcsvc.so.1 => /usr/lib/librpcsvc.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1 CODE
In addition to the RPC port mapper, applications might rely on other common OS services such as FTP, SNMP, or Network File System (NFS). You can use similar techniques to debug these services and to determine if they are actually needed to support a business function. One method involves using the netstat command as follows.
This command returns a list of services that are or were recently in use, for example:
In this example, many services are in use, but it is unclear which ports are owned by which services or applications. This information can be collected by inspecting the processes using the pfiles(1) command (available on Solaris OS versions 8, 9, and 10). The pfiles command reports information for all open files in each process.
A more effective and efficient way to determine these dependencies is by using the list open files (lsof) command.
Download the lsof source code from:
ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/
Download the lsof binaries from:
http://www.sunfreeware.com
# netstat -a | egrep "ESTABLISHED|TIME_WAIT"
TABLE2-1 Listing Services Recently in Use
localhost.32827 localhost.32828 49152 0 49152 0 ESTABLISHED localhost.35044 localhost.32784 49152 0 49152 0 ESTABLISHED localhost.32784 localhost.35044 49152 0 49152 0 ESTABLISHED localhost.35047 localhost.35046 49152 0 49152 0 ESTABLISHED localhost.35046 localhost.35047 49152 0 49152 0 ESTABLISHED filefly.ssh 192.168.0.3.2969 17615 1 50320 0 ESTABLISHED
CODEEXAMPLE2-8 Determining Which Ports Are Owned by Services or Applications # for pid in `ps -aeo pid | grep -v PID`; do
> pfiles ${pid} | egrep "^${pid}:|sockname:" > done
Chapter 2 Securing Systems: Applying a Methodology 29 The lsof command determines which processes are using which files and ports. For example, to determine which processes are using port 35047 from the previous example, use the following command.
The output of lsof indicates that port 35047 is in use for communication between the dtexec and ttsession processes.
Using the lsof program, you might be able to more rapidly determine intersystem or interapplication dependencies that require file system or network usage. Nearly everything that is addressed in this section can be captured using various options of the lsof program.
Note – The methods described for determining dependencies might not find rarely used items. In addition to using these methods, review Sun documentation and vendor documentation.