Monitoring Processes

I l @ ve RuBoard

Processes are started by either "forking" them, that is, creating a new process that is a child process of the process that forked it, or by "execing" them, which replaces the first process with the second process and in so doing destroys the first process. In both cases, the new process inherits a number of characteristics from the parent process. Some of these characteristics are the owner of the process, including privileges, priority, and the user 's environment.

Process monitoring comes in two varieties: first, monitoring processes while they are running, and second, monitoring processes after they have completed. The first is generally done with the processes status command, ps , the second with process logging.

Running Processes

To be able to monitor what is currently running on a system, you must be able to look into the system and examine the system's tables. These tables include the process table, which is a list of the processes in the system.

In order to look into the system, you must have appropriate privileges to examine the system's memory where these tables are stored. These privileges are either granted by setting the permissions on the memory device file, /dev/mem , or by having the information-gathering program run with enough privileges to access the system memory.

There is a long list of programs that can be used to gather information about the system's current status. These are generally classified as performance tools. The simplest way to see what is running on the system is to use the process status, ps , command.

The options for the ps command vary based on whether the system is a BSD or SYSV derivative. In either case, this command can report all the processes currently running in the system. It can display the owner of the process, the amount of CPU time consumed, the associated terminal, if any, its parent process, the name , and all the parameters to the process.

Completed Processes

To be able to gather historic information about what has been running on a system, the system has to record and store this information. There are a number of levels within the system where this reporting occurs and for a number of reasons.

The most common is system logging. Historically, however, system logging has been the most proprietary area of a UNIX system. Each vendor implemented its own low-level logging for each hardware platform and interface.

Today, most systems utilize the system logging facility syslog. The syslog facility creates a single logging environment that is system-independent. It allows messages to be sorted by their source and importance, and the messages can be routed to a variety of destinations.

Session accounting is a UNIX utility that records resource utilization by user for billing purposes. It measures user connect time, CPU usage, printer usage, and disk usage. The commands used by BSD and SYS-III derivatives differ significantly even though they report the same basic information.

Auditing, a relatively new feature for most UNIX implementations , is a method of monitoring specific activities as they relate to specific system calls or specific users. Auditing is a requirement for a C2 security grade operating system as defined by the U.S. Department of Defense's Orange Book.

Auditing allows you to monitor user access to objects. Specifically what is auditable will vary between implementations, but it will include system calls, administrative commands, and network connections. The audit will report which user invoked the call and whether the call was successful or not.

These audit logs can be used to identify security breaks and attempted security breaks. These are well-known to hackers and are often targeted to remove evidence of the hacker's activities.

Security logs, that is, information that is logged specifically to report on the security health of a system, are currently found as a collection of specific tools that address specific security issues or third-party products. There are a number of products that do security logging, but there is no standard set of integrated tools that is widely utilized throughout the industry. Many of the tools are written with the ability to utilize the system logging facility, syslog. If the syslog system has been secured, it is a good method to control and manage the security log messages. These messages must be regularly reviewed.

Command Histories

The shell history is a file that contains a command stack of all the commands entered by the user. It is generally configured to a specific size so that it holds a finite number of commands; after that point, they fall off the stack. Depending on the size and activity, the history file may be more or less than the last session. The hacker uses the history file to monitor a user's activities while he is not online.

Shell histories can also be used by system administrators to see what a hacker has been doing on the system. Once you have determined that a specific account is being used by a hacker, reviewing that account's shell history file may reveal what the hacker has been doing.

All this information may be of limited value if you do not know what each user should be doing on the system. That is why user profiles are so important to security.

I l @ ve RuBoard