This article is more than 1 year old

FreeBSD 6.2 nears release

Robert Watson on the new security event auditing system

How does the audit framework work?

Robert Watson: Configuring audit is quite straight forward. We do not ship the GENERIC kernel with AUDIT support enabled, as it will be considered an experimental feature for FreeBSD 6.2, so you will need to recompile the kernel with "options AUDIT". All of the necessary tools are compiled into user space by default, however. To turn on basic audit, add the following line to /etc/rc.conf and reboot:

     auditd_enable="YES"

This will enable the audit daemon. The default configuration audits login and logout events, but it can be configured to audit in much greater detail. Configuration files for audit are found in /etc/security. To audit all program execution performed by authenticated users, you can modify the flags line and policy lines in audit_control(5)to read:

   dir:/var/audit
   flags:lo,+ex
   minfree:20
   naflags:lo
   policy:cnt,argv

After restarting the audit service, successful calls to execve(2) will be included in the audit log, producing a detailed trace of user activity. The praudit(8) tool is used to convert BSM trails to text for analysis, and the auditreduce(8) command can be used to select specific records for processing. For example, the following command line will print the tail end of the current open audit trail:

   % praudit /var/audit/20060919152519.not_terminated | tail -14
   header,194,10,execve(2),0,Fri Sep 22 11:25:28 2006, + 186 msec
   exec arg,/usr/sbin/praudit,/var/audit/20060919152519.not_terminated
   path,/usr/sbin/praudit
   attribute,755,root,wheel,90,74867,293408
   subject,robert,robert,robert,robert,robert,27579,24249,60949,131.111.204.168
   return,success,0
   trailer,194
   header,128,10,execve(2),0,Fri Sep 22 11:25:28 2006, + 189 msec
   exec arg,tail,-14
   path,/usr/bin/tail
   attribute,555,root,wheel,90,27225,114880
   subject,robert,robert,robert,robert,robert,27580,24249,60949,131.111.204.168
   return,success,0
   trailer,128

One interesting thing about audit is that we log the authenticated user, not just the UNIX real/effective uids. This means that activities performed after su'ing will be traceable both to the original user who logged in, not just the user switched to, which can be quite useful for introducing accountability for shared role accounts. Using auditreduce(8), you can select down to particular users, particular files, times of day, type of operation, and so on.

You can find more information on audit in the FreeBSD Handbook chapter on audit, as well as detailed information on configuration file formats and tools in the man pages.

Audit is required for Common Criteria evaluation. Do you think this feature could help FreeBSD gain more market share in enterprise and government agencies?

Robert Watson: Common Criteria evaluation is critical to the adoption of operating systems by a number of major software consumers, including US DoD and other parts of the US government. Even without evaluation, audit is an important software requirement for many other security-sensitive organisations, such as banks.

Inclusion of this feature in FreeBSD will open a lot of doors. On the other hand, adding audit support is not the same as completing evaluation - evaluation is a very expensive prospect, and typically happens in the context of a vendor with a specific product, not an open source community project.

Our goal has been to facilitate evaluation of FreeBSD by its consumers and resellers, not perform the evaluation itself. FreeBSD should now meet almost all of the technical requirements for a basic CAPP evaluation, if someone should come along wanting to do one. As FreeBSD has been evaluated numerous times under the common criteria as part of various products, such as routers, firewalls, and so on, there's a lot of evidence that such an evaluation could be completed successfully without much additional development work.

What type of advantages could a forensic technician get from it?

Robert Watson: Post-mortem analysis is a tricky business - you want to figure out how the system was broken into and what was done, but this is complicated by the fact that software is extremely flexible and there isn't much log information. It could be that the first thing you know of an attack is a defaced web page, but maybe the actual break-in occurred weeks before. A detailed audit trail of events can often directly answer the question of how and when the break-in occurred, and allow the technician to backtrack through the log identifying what files were modified by the attacker, what software was run, and what other activities, such as attacking other systems, were performed.

As audit is flexible to configure and we ship trail reduction tools, administrators can decide on their own trade-offs between disk space use, performance impact, and log completeness. For example, administrators might choose to audit only system logins, which has very low space and performance overhead - or, they might choose to audit all commands executed and system logins, costing somewhat more in space and overhead, keeping execution information for four weeks, then reducing the logs down to only login information and keeping that for 12 months.

More about

TIP US OFF

Send us news


Other stories you might like