Auditing Mac OS X


Auditing involves checking your Mac from time to time to make sure that nothing has happened to make it less secure. There are several ways to do this, including checking that the actual files on your computer have not been tampered with, monitoring your log files, and using a standard set of tools to determine whether your computer is as safe as other systems.

Monitoring Log Files

It may seem a bit academic, but watching log files is an excellent way to monitor the health of your computer. Inside Mac OS X are dozens of log files, all of which are important in one way or another. With respect to security, however, the following two log files, located in /var/log, stand out from the rest.

secure.log

secure.log relays information about users' attempts at accessing rights in the /etc/ authorization file, such as whether the screen saver has been invoked and a password is needed to unlock the screen, whether Fast User Switching is being used, whether there has been an attempt to use su or sudo from the command line, and whether there has been any attempt at unlocking a System Preferences pane.

Like the wtmp file, whether the user has logged in via the Login Window or remotely (usually via SSH), secure.log will show all logins and logouts. secure.log is extremely useful when watching attempts to access rights that may not be granted to the user. You can search for the word failed in the log; conversely, an administrator whose account may have been compromised can search for the word succeeded, which will indicate the acceptance of authentication to a given right. If attackers gain access to your system, the first thing they do is doctor or delete the log files in an attempt to hide their presence. So if you are an administrator, you may want to look for any absence of normal day-to-day authorization, as well.

wtmp

wtmp keeps a listing of restarts, shutdowns, logins, and logouts, both from the login window and via remote access (SSH). wtmp is a powerful log file that can show you who logged in to your computer, when it was shut down or restarted, whether anyone else has a hidden account on your machine, and whether he or she is using that account to access your computer. You cannot view the wtmp file directly; you must use the last command to view the contents of the file.

Using a Centralized Log Server

Reading log files to monitor the security health of your computer may seem like a good idea, and most of the time it is. But what if you have been attacked and your computer has been compromised? Remember, the first thing an attacker will do is doctor the log files to disguise their presence.

Therefore, you may want to create a centralized log server whose only job is to accept log files from another server (such as a Mac OS X Server running file services). If that file server is compromised, the attacker has no way to doctor the log files. You have a better chance to discover what happened and trace it back if your log files are safe from editing or deletion. When doing this, you must open up additional ports. It's not always possible to secure the log server against spoofing.

Apple Certification Compliance

Apple has augmented its commitment to security by becoming Common Criteriacertified for both Mac OS X and Mac OS X Server for version 10.3.6 and later. Achieving Common Criteria certification, a standard method of evaluating the security capabilities of information technology products, provides for a safer, more user-centered computing experience. Along those lines, Apple is working to comply with various security standards that many software companies, organizations, governments, and even nations are using. Among the certifications Apple adheres to are the following:

  • Controlled Access Protection Profile/Evaluation Assurance Level (CAPP/EAL3): This is set forth by the National Security Agency to ensure security requirements and baselines for IT infrastructure with the U.S. government. EAL3 is the common denominator among assurance levels with respect to operating systems.

  • National Institute of Standards and Technology, Federal Information Processing Standards (FIPS 140-2): Used to set security standards for cryptographic modules.

  • Common Criteria: This internationally approved set of security standards provides a clear and reliable evaluation of products' security capabilities. By furnishing an independent assessment of a product's ability to meet security standards, Common Criteria gives customers more confidence in the product's security and leads to more informed decisions. Security-conscious customers, such as the U.S. government, are requiring Common Criteria certification as a determining factor in their purchasing decisions. Because the requirements for certification are clearly established, vendors can target very specific security needs with a broad range of offerings.

    A protection profile defines a standard set of security requirements for a specific type of product. Common Criteria rates these as Evaluation Assurance Levels (EALs) numbering 1 to 7.

Common Criteria Tools

The Common Criteria tools available from Apple let administrators audit their systems. Running Common Criteria tools does not make an operating system inherently more secure, but it offers stellar event reporting via auditing, and a manageable way to benchmark one system against another. Keep in mind that a higher EAL level does not necessarily mean the system is more secure. The profile from Common Criteria must be matched against the EAL and measured against others in its category. In this manner, a more realistic view of the level of security can be established.

Common Criteria tools allow administrators to review results based on how secure the operating system environment is compared with the CCAP standard. Once the tools are installed, you configure the line AUDIT=ABC in the /etc/hostconfig file, where ABC can be one of four options:

  • AUDIT=YES

    Enable auditing and ignore failure.

  • AUDIT=FAILSTOP

    Enable auditing and allow processes to quit or halt if failures occur.

  • AUDIT=FAILHALT

    Enable auditing and allow the operating system to halt if a failure occurs.

  • AUDIT=NO

    No audits are run.

Once an audit option has been chosen, it will add records of certain events to a log file whose name is based on the date and time the file was created and stopped. For example, a log named 20051017060025.20051017113047 indicates that the log was started on October 17, 2005, at 6:00 A.M. and 25 seconds and stopped on October 17, 2005, at 11:30 A.M. and 47 seconds. If an audit is still in progress, the ending date and time will not be shown. Instead, the text not_terminated will appear in the log file name.

By using commands, you can force the rotation of log files (audit n) and reload the criteria settings (audit s), which will also automatically rotate the log file for you. The audit command has several other flags, all of which should be explored more thoroughly by reviewing the man page for audit.Once you have logged your audits, you can begin to make some sense of them. The auditreduce command lets you select only those topics relevant to you from the records. For example, you may want to see only those entries that exist when you log in as an administrator, rather than logging in as a regular user. In that case, you would use:

auditreduce e shortnameofuser/var/audit/20051017060025.20051017113047


to view only audited items pertaining to that user from that particular log file. The praudit tool allows you to print audit records.

Several files (audit_class, audit_control, audit_event, and audit_user) let you manage the breadth and scope of your auditing. Another part of auditing is the ability to configure the auditing subsystem to handle audit events. The file audit_class shows a list of those audit events and can configure the auditing subsystem based on your criteria. For example, a line in the audit_class file could be 0x00000000:fr:file read, indicating that the event file read is a recordable event.

The file audit_control can be edited to change where the log files are stored, specify which event classes are audited for all users and which are to be audited when a user cannot be identified, and set a limit on the amount of free space that must exist before warnings are issued and logging is potentially halted.

You use the audit_event file to view events indicated by number, name, description, and class.

Edit the audit_user file to specify which audit event classes are recorded for a given user. This is very useful when attempting to audit one user out of ten on a given machine. For example, you would add +lo to log events performed by a specific user or users.

Finally, audit_warnwhich is not really a file but a scriptwill send messages to the audit_messages file, such as whether the system is running, a given directory is out of space, or errors have occurred in the shutdown of the auditd process.

Auditing Software Using Checksums

A very sneaky technique to breach security is to replace known programs on a system with new versions of those programs that seem to operate like the normal versions, but allow easy access to an attacker.

Most likely replaced by a Trojan horse program, any common program can be replaced by an evil version, including UNIX daemons (such as ftpd, sshd, httpd, and so on) or, less likely but still possible, desktop applications.

Using mathematical calculation done in a predictable way, it is possible for auditing software to create a specific "number" for any file on the file system. If anything about that file is changed, even one byte of it, the number that is generated will be changed. This number is called a checksum. It is nearly impossible for two very different (or even very similar) files to generate the same checksum value.

Since programs on a computer are merely executable files in the file system, you can utilize auditing software to generate checksum values for some, or all, of the programs on a computer. Often, software developers will include the associated checksum with their software, either in the associated Read Me file, or on a webpage that contains the download link.

You can use the checksum mechanism to pre-audit the "correct" versions of the software, and then proactively check those checksums during regular security audits of the system. If the checksum has changed, either a new, legitimate version of software has been installed (which you can verify), or an unauthorized attacker has modified the program, perhaps with the intention of breaching the security of the system. There are existing utilities that permit this method of detection.

One type of checksum generator utilizes the Method Digest 5 (MD5) technique. To generate MD5 checksums, Mac OS X includes a program called md5.

Detecting UNIX Hacks

Virus scanners are great for detecting known viruses, particularly those popular with email. The downside, though, is that they often don't know about UNIX hacks. The UNIX hacks mentioned at the beginning of this lesson usually involve modifying a script, or completely replacing a system binary with one that has malicious intent. Virus scanners may not always know about or be able to detect these types of infections. This is where intrusion detection comes in.

Some tools used for intrusion detection compare binary checksums of the known good system and important files with current files. Tripwire is a well-known example. Tripwire detection involves scanning the entire file system of a computer and saving that snapshot. Later (usually once every day), you rescan the entire file system and compare this scan with the snapshot you saved earlier. If there are new files, or files that have changed, you should be suspect as to why they changed. The changed files could be totally normal. Maybe someone installed a new version of some software on the computer, or an administrator updated a configuration file. But if you didn't modify your computer and files are showing up as changed in a tripwire report, you should use some extra caution until you can rule out the possibility that they may now be malicious files.

There are a number of popular intrusion detection packages available:

  • Commercial and open-source products named Tripwire (www.tripwire.com, http://sourceforge.net/projects/tripwire)

  • FSLogger (www.kernelthread.com/software/fslogger)

  • fsdiff, part of the radmind project (http://eq.rsug.itd.umich.edu/software/radmind)

  • logGen (www.lsa.umich.edu/lsait/admin/mac/software/index.asp)

These products range in levels of sophistication from complex to simple. For example, Tripwire lets you decide if you want to omit certain directories, flag what signifies a change of a given file or directory (timestamps, file hash, file size, etc.), and specify options useful in special directories (like log file directories) to tell you only if a file has appeared or disappeared but to ignore changes to existing files. On the other end of the spectrum, logGen can ignore directories, but lacks other customization. logGen does offer a much more compressed set of output, however, in that it compresses the output down to show only the top level of a directory as changed rather than all of the files inside it. This is particularly useful if you're using logGen to create packages:

1.

Take a snapshot of the system with logGen.

2.

Install the software you want to package.

3.

Run logGen again to see what files or directories were created, modified, or deleted.

These are the files or directories you need to include in your package.

Tripwire

You must have the Apple Developer Tools (Xcode) installed to build Tripwire from scratch. Although there is a precompiled version available from www.macguru.net/~frodo/Tripwire-osx.html, compiling it from source is fairly simple, as shown in the following steps. The site www.macguru.net/~frodo/Tripwire-osx.html does have some good documentation, and is worth the read.

1.

Download Tripwire from www.frenchfries.net/paul/tripwire.

This is an updated port of the open-source Tripwire software that has been fixed up a bit to be easier to compile and use on Mac OS X.

2.

Type the following:

tar zxf tripwire-portable-0.9.tar.gz cd tripwire-portable-0.9 ./configure make (this will take a while...) sudo make install


3.

When prompted for the keyfile pass-phrases, enter something that you'll remember but that's secure.

4.

Examine the twpol.txt and twcfg.txt files.

Their locations should be indicated in the last few lines of output from the installation, and may vary for your site. These files control how much Tripwire will scan. You may need to modify them to accommodate your specific configuration, but just leave the files alone for now. If you do make changes, use the twadmin command to create new signed versions of these files that Tripwire will actually use.

5.

Type sudo /usr/local/sbin/tripwire init and enter your passphrase when prompted.

This will initialize your tripwire database. This process takes a snapshot of what your system should look like, and will take a while to run.

6.

Type sudo touch /etc/testfile.

7.

Type sudo /usr/local/sbin/tripwire check (you won't have to enter your passphrase this time).

You'll see output that contains something similar to the following:

------------------------------------------------------ Rule Name: OS Boot and Configuration Files (/private/etc) Severity Level: 100 ------------------------------------------------------ Added: "/private/etc/testfile" Modified: "/private/etc" ------------------------------------------------------ Rule Name: Variable System Files (/private/var/db) Severity Level: 60 ------------------------------------------------------ Modified: "/private/var/db/shadow/hash/A90B4CDD-8696-11D9-9221-000D93BFA322.state" ------------------------------------------------------ Rule Name: Variable System Files (/private/var/tmp) Severity Level: 60 ------------------------------------------------------ Modified: "/private/var/tmp"


As you can see, even though you made only one tiny change, there are many other files being changed automatically in the background. This is why customizing the configuration of Tripwire is important.

logGen

Once you install logGen on your computer, you'll want to test it by creating new files, modifying those files, and comparing the initial state with the older state looking for differences.

1.

Create some new files on your system by entering the following:

sudo mkdir /etc/tripdemo sudo chmod 777 /etc/tripdemo cp /etc/hosts /etc/tripdemo/hosts cp /etc/motd /etc/tripdemo/motd


2.

Download logGen from www.lsa.umich.edu/lsait/admin/macenv.asp.

3.

Double-click the package to install logGen.

4.

Type sudo /usr/local/sbin/logGen /var/db/logGen-baseline.

This process takes a snapshot of what your system should look like, and will take a while to run:

logGen -- version 1.5 Copyright 2005 - The Regents of the University of Michigan All Rights Reserved Checking File: 237202 --------------- / --------------- 0 changed files 0 deleted files


5.

Create some new files on your system by entering the following:

touch /etc/tripdemo/file1 mkdir /etc/tripdemo/testdir touch /etc/tripdemo/testdir/file2 touch /etc/tripdemo/testdir/file3


6.

Modify a file on your system by entering the following:

echo "changing..." >> /etc/tripdemo/hosts


7.

Delete a file on your system by entering the following:

rm /etc/tripdemo/motd


8.

Compare what's currently on the file system with the baseline, and output the difference by entering the following:

sudo /usr/local/sbin/logGen /var/db/logGen-current /var/db/logGen-baseline


This command also outputs a new file (logGen-current) as a snapshot of how it currently looks. You can either move that into place (replacing the baseline file) if you want it to be the new baseline, or just ignore it.

logGen -- version 1.5 Copyright 2005 - The Regents of the University of Michigan All Rights Reserved Checking File: 237202 of 237202 (100%) 4 new files: --------------- /private/etc/tripdemo/file1 /private/etc/tripdemo/testdir/ --------------- 1 changed files: --------------- /private/etc/tripdemo/hosts --------------- 1 deleted files: --------------- /private/etc/tripdemo/motd ---------------


Notice that logGen reported all of the changed, deleted, and new files, and that even though both file2 and file3 were new, it didn't list them individually because the entire directory that contains them is new.

9.

If your files were legitimately updated, you may want to move the current logGen snapshot to the location of your baseline with this command:

sudo cp /var/db/logGen-current /var/db/logGen-baseline


Detecting Mac OS X Intrusions

Older installation packages created in Mac OS X v10.3 and earlier and those created by third-party software vendors may ask for prebinding, a process to speed up application launch times and generally improve the user experience. It accomplishes this, however, through some changes to each application's executable file. The side effect of this is that a simple prebinding action (the step you see when you install software and at the end where it optimizes your system performance) can literally cause all of the executables to be shown as changed. Because of this, you may need to take a new baseline snapshot of your system every time you install new software.

You should also take some time to configure your intrusion detection application to your specific system. Both Tripwire and logGen offer ways to customize the directories that are searched or ignored.

As with any intrusion detection system, you'll want to keep a copy of your baseline snapshot file on a CD-R outside of your computer. The whole point of intrusion detection software is to detect if your computer has been compromised and your files have been changed. If that's happened, the attacker could quickly modify your baseline snapshot to hide the changes they made. However, if you keep your snapshot on read-only media or completely off your computer, you always have a picture of what your computer looked like while it was clean.

Intrusion detection is really effective only if you regularly run reports to detect any differences. Mac OS X offers a number of different options for regularly running software, but the easiest method is to simply create a shell script containing the commands you want to run every night and drop it in /etc/periodic/daily.




Apple Training Series. Mac OS X System Administration Reference, Volume 1
Apple Training Series: Mac OS X System Administration Reference, Volume 1
ISBN: 032136984X
EAN: 2147483647
Year: 2005
Pages: 258
Authors: Schoun Regan

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net