| Previous | Table of Contents | Next |
Configuring and maintaining audit logs on UNIX systems is no trivial matter. A number of different parameters need to be properly set. Expertise in UNIX audit administration is not a widely available skill. Furthermore, the management concepts and tasks across different UNIX systems differ widely. For example, the AIX audit subsystem provides a panic capability. Paranoid administrators can panic the system if there is not enough space to write audit records. There are people who would prefer to see the system go down rather than have an incomplete audit trail. The Audit Management subsystem of Stalker provides a GUI that attempts to hide the complexities of audit administration for several versions of UNIX. Because the concepts and tasks are not identical on all platforms, you will fill in different screens depending on the OS running on the Agent.
In the audit configuration screen, some of the items you can control include the following:
Most UNIX systems support two modes for storing audit records. In bin mode, the audit subsystem writes records into the first bin (file) until it is full. The audit subsystem then switches and writes into the second bin, until it, too, becomes full, and the first bin is used again. In stream mode, output from the audit trail is passed in real time to system-defined processes. For example, Stalker intercepts the audit events in real time in stream mode and writes, formats the output into a common format, and then writes the data into files.
Processing records in bin mode can result in the loss of records. Stream mode records are lost only if the file system space fills up. Stalker configures UNIX systems to run in stream mode. The Stalker agent code then attaches to the stream and captures audit records as they are generated. When the records are reformatted into a common form, they are written into ASCII files that the detection engine analyzes. You can choose whether to keep the original audit records generated by the system as part of Audit Management.
On Solaris systems, you can choose to monitor more than 240 different types of audit events. Other operating systems monitor 100 event types or more. Therefore, deciding which events to monitor is your responsibility as an administrator. By default, Stalker configures Agents to monitor only a subset of events. For performance reasons, not all file opens are monitored. AIX provides per-file auditing, so it is possible to watch opens for only certain files, such as /etc/security/passwd. Unfortunately, there will be many legitimate accesses to this file as part of the normal operating system behavior, particularly if there are many logins and logouts during the day at your site. On the other hand, if you don’t watch people writing to /etc/security/passwd, you can miss attacks.
Auditing subsystems generate substantially large files. Haystack Labs would suggest that customers plan for 10—50 MB of data per user per day. Your mileage might vary.
The Tracer/Browser (TB) is a query tool for filtering through these large amounts of audit data. To look for specific entries in the audit logs, you select a client from the GUI, click on the TB icon, and fill in the next few screens. Note that the TB is designed to search through audit logs for events that match your search parameters. It does not look for sequences or complex patterns of events.
The TB enables you to filter on many different fields:
You can form very complex queries in the GUI. For each field, you may define inclusion and exclusion qualifiers, such as asking for all AUIDs not equal to zero or all file names that match a particular regular expression. Predefined lists of values for a search field are also allowed. That is, the GUI will let you create a list of critical file names to monitor, assign a name to this list, and reuse the list in different queries over time. You then can search through the audit logs looking for audit events showing attempted accesses for only those files.
The output from the query can be displayed, printed, mailed, or saved to a file. When saved to a file, the format can be either a text report or an audit event file that can be further reduced with a query. Queries may be formulated in advance and then stored as templates. Scheduled TB queries are then run via cron jobs to reduce the audit data into regularly delivered reports.
When would you use the TB? When you want to keep records of important security events, such as when users are added or removed, a convenient report can be created in the TB. Thus, you can use TB reports for documenting your security activities. Stalker is shipped with a number of default TB queries and reports. One example is a report with both successful and failed logins. Notice that this report is not an intrusion detection signature. It’s just a useful report showing you who connected and who had trouble connecting. An attack signature happens to use the same data to look for someone trying to break into the system. You might also want to know anytime someone runs the su command or executes a SUID program. All of these types of queries are supported by the TB.
You also can use the TB to look for trouble. A second built-in report that Stalker provides is the mail-policy-violation-report. A simple query looks for typical UNIX mail files and finds audit events that show that someone other than the file’s owner tried to access the file. If you think of the audit logs as a relational database table and envision the TB as a query interface into this database, you see that there are a number of important uses.
Stalker looks for attacks against UNIX systems. If you install application software for which Stalker does not include predefined reports or queries, you can design your own queries or reports to track activities against these files. If the application introduces its own subjects, objects, and access control events, Stalker will not report on those activities unless they are added to the audit trail by the application vendor.
Today, Stalker provides only batch or interactive queries. The capability to filter for specific queries in real time would be an added advantage. This feature would introduce some interesting tradeoffs for you as well. Each real-time filter would add load on the network and on a centralized monitor. Configuring a feature like this in a distributed environment would require a few tries to perfect, particularly if you have a very large site. The capability to organize analysis engines into a hierarchy also would be beneficial for any real-time distributed monitoring tool.
| Previous | Table of Contents | Next |