Solaris Security: Basic Auditing04 Jul '05 - 15:40 by benr
Auditing is the process of double checking something, general by means of comparison: what is and what should be. The idea is similar to a tax audit: for some reason the IRS thinks something not right and thus they double check all your books comparing what you reported and what you should have reported. The practice is a useful one for two common reasons: security analysis and general audit purposes. An example of a common security analysis would be if you logged into a system and suddenly got that "somethings not right" feeling and wanted to analysis in great detail any changes made to the system generally looking for evidence of tampering or breakin. A general audit would be the same sort of analysis yet without the paranoia, looking to see what new things have been installed, if any configurations have been changed, etc, all of which can be part of a healthy change management policy.
Solaris provides two resources for auditing: BART (Basic Audit Reporting Tool) and BSM (Basic Security Module). Here we'll discuss BART. We'll discuss BSM some other day, untill then you can plenty of information via Google.
BART is a simple tool, yet extremely useful and powerful in the right circumstances. BART simply does file level auditing, meaning that it trolls your systems directory tree recording information about each file as it goes. The result is a flat text file which we call a BART manifest (not to be confused with SMF manifests). This manifest becomes a baseline. At a later point in time (after a suspected compromise perhaps) you run BART again, creating yet another manifest, which you then compare against the baseline manifest you made earlier. By comparing these two manifests we can see exactly what has changed on our system and use that information to begin further analysis.
At this point some of you are saying "Hey, thats TripWire?" And guess what, your right. Its basically a simple implementation of TripWire. The diffrence being that: a) TripWire is $$$, BART is already avalible within Solaris, b) BART is much less robust but still does the job, no bells and whistles, no fancy reports, no web interface, just create a report and compare a report, c) Despite the lack of functionality in BART, its less likely to capture the attention of an attacker like TripWire would. Despite this, if you actually can afford TripWire, by all means, buy it. Not only is TripWire a really kool company that provides a great product but the small price you pay for it you do get a lot of flexability. TripWire has been good to us, lets be good to them when possible.
Using BART is really really simple. You simply use bart create to create a manifest, and then bart compare to compare the two. Output sent to STDOUT, so make sure you redirect it. Here's a simple example of running BART:
root@monolyth tmp$ bart create -n > bart-`hostname`-`date '+%m-%d-%y'` root@monolyth tmp$ touch /etc/passwd root@monolyth tmp$ bart create -n > bart-`hostname`-`date '+%m-%d-%y'`b root@monolyth tmp$ bart compare bart-monolyth-07-04-05 bart-monolyth-07-04-05b /etc/passwd: mtime control:42bbca1e test:42c98f7b
The command bart create above is also using the -n argument, which tells bart to not create signatures for each file. The generation of hashes for each file would be extremely CPU intensive and take a long long time, so this argument just lets us skip that. Following the creation of our baseline manifest we'll touch a the password file and then create yet another manifest, and then compare these two manifests to see what changed. We clearly see that the modification time (mtime) on /etc/passwd has been changed.
So, BART is the answer to the age old question: "What changed?"
There are two problems with what we did above however. Firstly, it'd be nice to have more control over comparisons. Secondly, the manifests we created trolled the whole system, which includes /tmp, /var/tmp, home directories, etc, and we probly don't care about capturing that much data, especially with reguards to files we expect to change often (such as .bash_history files, etc).
As I mentioned before, BART fills the same role as TripWire but isn't as powerful, it just lacks all the polish and glitz. However, using BARTs -p option we can get easily parsable output from bart compare. We can use this output to easily craft our own reporting tools using SED or PERL and fill any needs we might want.
To assert some control over BART we can leverage BART rules. A rules file is just what it sounds like, a listing of rules by which BART should conform. A simple example of a rules file would be:
# Global Attributes CHECK all IGNORE dirmtime # Check /etc and /usr /etc /usr CHECK # Check /var but ignore filesizes and mod time (logs) /var IGNORE size mtime
In this rules file, the first block is special and contains the global attributes, meaning the default arguments passed to CHECK and IGNORE. Each following block contains a list of subdirectories to be checked. Using the IGNORE and/or CHECK keywords after each block can modify the information gather reguarding those subdirectories.
BART will, by default, grab the following attributes reguarding each file: acl, contents, dest, devnode, dirmtime, gid, lnmtime, mode, mtime, size, type, uid. Additionally a catchall attribute, "all", exists. We can use these attributes to determine what to check and what to ignore in our rules. For instance, we genearlly don't care about directory modification times since if a file is added or deleted we're going to catch it anyway. Another example is log files, we want to know if they are created or deleted, however we expect them to change so attributes like size and mtime can be ignored. In the example rules file we check /usr and /etc using the global attributes specified in the first block, then we check /var but ignore size and mtime. Rules can be leveraged by BART by specifying the -r argument to bart followed by the name of the rules file.
So, BART can be a pretty handy little tool. Its simple enough to implement that it would be wise for just about anyone to generate a manifest on a regular basis (daily or weekly) via cron, just in case something should ever happen.
For more information on BART read the mange pages: bart(1m), bart_manifest(4), and bart_rules(4).
There’s also AIDE, [[http://www.cs.tut.fi/~rammer/aide.html]]
anastacia (URL) - 12 June '06 - 20:39Follow your dreams, you can reach your goals. Hey man…sorry I missed the party.