Whether you’re dealing with a car or a computer, poor maintenance habits lead to the same consequence: disaster. You’re on the freeway, carefully driving at the posted speed limit, and your engine suddenly dies. You go to the mechanic, who roots out the cause: your timing belt broke. You would have replaced your timing belt, had you kept to the maintenance schedule and taken your car in for service at 60,000 miles. Airline maintenance crews who stick to a steadfast and detailed maintenance schedule rarely have this happen to them, mainly because they know precisely on what date the plane was maintained, at what time, and what maintenance was performed.

This is how many seasoned network administrators treat security. They proactively manage their systems. They log when they perform maintenance on the machine and notice when anomalies occur. They review their logs regularly. But logs often go unnoticed and unread, which is unfortunate, as they can be a great source of insight into securing your systems. Even when security has been compromised, many administrators don’t think to check the logs to see what happened.

Why is this? It’s simple. Logs can be complicated to the untrained eye, and some administrators just don’t understand what the logs are telling them.

In this chapter, we will show you where to look for log files on the Mac (and Windows machines as well, because they can tell you a lot about security with respect to a Mac) and show you what they mean. We hope that once you realize what kind of information is stored in logs, you’ll start using them a lot more effectively.

What Exactly Gets Logged?

It may seem weird to think that much of what you do on your computer gets logged. Imagine if every move you made was written down, and you could review every step you made over the course of the day. Although we may never know whether the National Security Agency (or AT&T) is actually recording our every move, logging every move on a computer is commonplace.

What gets logged can be determined by the application or by the operating system. This differs for each program, and what gets logged can be configured manually. The act of escalating your privileges is typically logged, as are failed attempts to do so. Many items are logged for the purposes of troubleshooting, but when it comes to security, any item that elevates privileges, references a password entry, or indicates the occurrence of an application failure should be logged.

A log entry can be as simple as one line indicating the deletion of a file, or as detailed as each file created during an installation or process. The following shows a portion of the output of the install.log file during the installation of the Mac OS X Server Admin tools. The install log shows each file created during the process as well as the corresponding date, time, and system on which each was created (or touched).

Oct 23 14:03:03 Gene-Sullivans-MacBook installd[137]: PackageKit: Registered bundle
 file://localhost/Applications/Server/Xgrid%20Admin.app/
Oct 23 14:03:03 Gene-Sullivans-MacBook installd[137]: PackageKit: Registered bundle
 file://localhost/System/Library/CoreServices/Server%20Assistant.app/
Oct 23 14:03:03 Gene-Sullivans-MacBook installd[137]: PackageKit: Registered bundle
 file://localhost/Applications/Server/Server%20Monitor.app/
Oct 23 14:03:03 Gene-Sullivans-MacBook installd[137]: PackageKit: Registered bundle
 file://localhost/Applications/Server/Server%20Admin.app/
Oct 23 14:03:03 Gene-Sullivans-MacBook installd[137]: PackageKit: Registered bundle
 file://localhost/Applications/Server/Workgroup%20Manager.app/
Oct 23 14:03:03 Gene-Sullivans-MacBook installd[137]: PackageKit: Registered bundle
 file://localhost/Applications/Server/Server%20Admin.app/Contents/Resources/
ServerAdminLauncher.app/
Oct 23 14:03:03 Gene-Sullivans-MacBook installd[137]: PackageKit: Registered bundle
 file://localhost/Applications/Server/iCal%20Server%20Utility.app/
Oct 23 14:03:03 Gene-Sullivans-MacBook installd[137]: PackageKit: Registered bundle
 file://localhost/Applications/Server/System%20Image%20Utility.app/
Oct 23 14:03:03 Gene-Sullivans-MacBook installd[137]: PackageKit: Registered bundle
 file://localhost/Applications/Server/Server%20Preferences.app/Contents/Resources/
ServerPrefsLauncher.app/
Oct 23 14:03:03 Gene-Sullivans-MacBook installd[137]: PackageKit: Registered bundle
 file://localhost/Applications/Server/Server%20Preferences.app/
Oct 23 14:03:03 Gene-Sullivans-MacBook installd[137]: PackageKit: Registered bundle
 file://localhost/Applications/Server/Podcast%20Composer.app/
Oct 23 14:03:03 Gene-Sullivans-MacBook installd[137]: PackageKit: Registered bundle
 file://localhost/Applications/Server/System%20Image%20Utility.app/Contents/
Library/Automator/Create%20Image.action/Contents/MacOS/AutoPartition.app/
Oct 23 14:03:03 Gene-Sullivans-MacBook installd[137]: PackageKit: Registered bundle
 file://localhost/Applications/QuickTime%20Broadcaster.app/
Oct 23 14:03:04 Gene-Sullivans-MacBook installd[137]: Installed "Server
 Administration Software" ()
Oct 23 14:03:04 Gene-Sullivans-MacBook installd[137]: PackageKit:
 ----- End install -----
Oct 23 14:03:05 Gene-Sullivans-MacBook Installer[127]: Running install actions
Oct 23 14:03:05 Gene-Sullivans-MacBook Installer[127]: Removing temporary directory "/var/folders/cm/cmSii-8XGFiRvFh+UL8r3U+++TI/-Tmp-//Install.127IGw3rb"
Oct 23 14:03:05 Gene-Sullivans-MacBook Installer[127]: Finalize disk "Snow Leopard"
Oct 23 14:03:05 Gene-Sullivans-MacBook Installer[127]: Notifying system of updated
 components

Multiple processes can be logged simultaneously, because they use such little processing power. Logging software writes entries to log files while you’re performing many of the common tasks you do every day and when routine tasks are running on your system in the background. This may be some of those pesky items that cause the computer to run slowly at various times of the day, such as right around 3:15 AM (this is when the normal daily periodic Unix scripts run).

When looking at logs, try to keep in mind that reading every single line of every log file can become tedious. Rather than doing this, look for strange entries in the files. For example, if the previous log also had included a line that indicated the installation of something called keystrokelogger, that would be something to be concerned about.

These strange entries are also called anomalies, or one-offs. They are entries that can appear odd or unexplainable or can be indications of something going wrong, or a process or an account doing something that it should not be doing.

Of course, looking for strange entries and anomalies assumes that you already know what the patterns are in your logs and that you can then tell when a strange entry or an anomaly turns up. Which really means that you should be looking at your log files regularly so that reading them becomes second nature. Also, when you do these regular reviews you should be practicing your searching so that when the time comes for you to search for that anomalous needle in your log entry haystack you will have little problem constructing a good search and then narrowing it down.

Using Console

In general, log files are text files that can be read with any text editor. (One exception to this rule are the BSM logs, which are addressed later in this chapter.) But trying to find and read all the system logs in a text editor can be a daunting endeavor. With OS X, Apple has simplified and streamlined this by giving you a handy tool in the /Applications/Utilities folder called Console. In this section we’ll cover how to use Console to view and mark logs.

Viewing Logs

You can use Console to review logs quickly without having to open and read each file independently. When you open Console, you are immediately viewing Console Messages. Clicking the Show Log List button gives you a listing of all the logs that Console is aware of, divided into three sections (see Figure 5-1). The Files section is a list of plain text log files, laid out according to where they’re located in the file system. Any other log files you open for viewing with Console will appear in this section.

The top two sections don’t show the contents of text files, but rather information drawn from the Apple System Logger database. ASL is a new logging facility that Apple introduced with Leopard, which consists of syslogd and aslmanager. The de facto standard for logging messages on Unix system is syslogd. It is historically used by the kernel to write messages to the system log, and is also used by daemons and programs such as Apache and Postfix. Since Snow Leopard, messages logged by the syslogd server are stored in a binary database located in /private/var/log/asl/. The files in that directory are managed by aslmanager. For compatibility with the many other systems that use syslogd, many of the messages are elso echoed to /private/var/log/system.log.

Console was designed to give you an easy one-stop shop for reviewing system logs. Although this is helpful, Console doesn’t show you every log on your computer. Each application logs information a little bit differently, and it would be impossible to cover every aspect of every log file ever created. Happily, many of the apps made for Mac OS X follow a fairly standard method that Apple established with its own logs. We’ll point out the ones to check for most security purposes. You can then apply this knowledge to other network-aware applications in order to check their logs for issues. Before we delve into what these logs can tell you, we’ll discuss how you can interact with the logs.

Though the log files use .log as their file type designator, they are mostly text files. As such this means they can be opened, read and searched by text editors such as vi or vim (built into the Mac), TextEdit, or advanced text editors such as BBedit. Console has good search functionality, but if you prefer to work in another editor and use something like regular expressions for more powerful pattern recognition and search capabilities you can do that.

Marking Logs

It is sometimes helpful to mark a spot in a log, while you are reviewing them, much like using a sticky note or highlighter to mark a passage in a book. To do so, select the log in the Logs window of Console and click the Insert Marker button. It’s important to note that these markers are not inserted into the log itself, but into your view of the log in Console. Clicking the Reload button, choosing another log, or quitting Console will cause those markers to disappear.

Another way to insert a marker into system.log and the ASL database is to use the logger utility, which provides an interface to syslogd. All entries you write will be prefaced with the date and time, and will include whatever message you send to it.

logger Marker

This command will insert the following line in system.log:

Nov  8 22:12:32 Snow-Leopard gene[1421]: Marker

Console also makes it easy to copy data out of the logs. When you click a log in Console, you can highlight text and copy it to TextEdit, Word, or any other program that supports pasting. To copy, you can either use Cmd-C key or select Edit ä Copy. Notice that you cannot cut text; Console does not let you modify logs.

For performance and simplicity, when you view the logs in the Database Searches section of Console, it will show you only the most recent 4,000 lines of data in the log. If there is more data in a log than Console can show, the Earlier and Later buttons on Console’s status bar will become active. When viewing any of the other logs, Console will only show the most recent 16MB of messages. When a log is larger than this, the Earlier and Later buttons will allow you to view the rest of the log.

Searching Logs

If you’re looking for a specific item in a log, the Filter box in Console’s Toolbar will filter the log you’re currently viewing, showing you only the lines containing the text you’re seeking. If you’re looking for successful and failed ssh attempts, you could enter sshd in the Filter box. As you type, the messages will be filtered until you’re only viewing messages containing sshd. This can be very useful for simple searches, but it can be difficult to put the results in context.

You can also search within a log by going to Edit ä Find (or pressing Cmd-F) and entering a search term. The first matching instance will be highlighted, and you can see what you’re looking for while still seeing what else was being logged around that time. It’s also possible to find terms within a filtered log.

Console also allows you to create saved Database Searches that will appear at the top of the Log List alongside All Messages and Console Messages. Go to File ä New Database Search (or press Cmd-Option-N), and you will be presented with the Database Search editor (see Figure 5-2).

Give your search a name and select your search criteria. You can search by the contents of the message (as with filtering, explained previously), by Sender (the name of the process sending the message), by Facility (a legacy designation of the part of the system sending the message), or by Level (the severity of the message). It’s possible to create very granular searches that will be a big help in keeping an eye on your system.

Finding Logs

The /private/var/log directory is where OS X stores most of its important log files. If you write an application or script that builds its own log file, then you can write these logs to /private/var/log and they will automatically appear in Console under /private/var/log. Many developers put their logs here because the /private/var directory is used in most Unix distributions (flavors) to house logs that are not user-specific. This includes logs for open source software that has been installed by Apple such as the firewall (ipfw), the Windows sharing component (samba), the web server (apache), and many other items.

The Finder is intentionally designed to not make these folders easily accessible. To get to the /private/var folder, you need to use the Terminal application and access it through the command line, or you can use the Cmd-Shift-G keystroke and type /private/var (or just /var, which is a symbolic link) in the “Go to the Folder” field. This is a fairly standard way of accessing many of the logs we will be discussing in this chapter.

Generally you can configure third-party applications to log to wherever you want. For example, Rumpus, the popular FTP server, stores its logs by default in the /usr/local/Rumpus/Logs directory. However, you can customize this using the Log Folder field (as shown in Figure 5-3). Additionally, with third-party applications, you can usually customize the frequency with which logs are trimmed and the amount of data that is written to the logs.

Because logs are compressed and stored for a short period of time before being deleted, if you are doing deep forensics on a system you may need to go into the backups to do a more extensive search. It’s not uncommon to go back months or even years in the backups to search older log files to find what you are looking for or to find a pattern.

What Happened to the Secure.log??

The secure.log file had its last hurrah in Snow Leopard, 10.6. With 10.7 and up through 10.11 the security events that were captured in secure.log are captured in the system log. Some of the security events can be captured by other logs. Some enterprise environments may install third party software that facilitates and enhances authentication to Active Directory. In this case that software may have its own logs – and you may find the login event information not on the Mac but in the Active Directory logs. However, those events go through the kernel too, so if you have the Basic Security Module enabled for certain security events (including but not limited to logins and logouts) you can refer to the BSM audit logs. For more on BSM and auditing see that section later in this chapter.

appfirewall.logThe built-in firewall (covered in greater detail in Chapter 11) is a feature-rich application layer firewall that is capable of logging massive amounts of data. appfwloggerd is a program built specifically for the purpose of logging firewall events to the appfirewall.log file. This file located at /private/var/log/appfirewall.log. appfwloggerd logs only those events that the Application Firewall determines are not acceptable.

Jul 16 15:10:18 dimac.local socketfilterfw[182] <Info>: CrashPlanService: Deny TCP CONNECT (in:25 out:0)
Jul 16 15:10:18 dimac.local socketfilterfw[182] <Info>: AppleFileServer: Allow TCP CONNECT (in:12 out:0)

The format of the previous log entries indicates information about the network traffic, or packet, that was processed by the firewall. Log entries include the date and time stamp the source of the packet (the IP address that the packet came from), and the destination of the packet (the IP address to which the packet is traveling).

appfirewall.log can help you get a handle on the comings and goings of network traffic on your computer, but can be quite verbose. When scanning through the logs, your goal should not be to read every line, but to look for any information that seems out of the ordinary, such as a large number of rejected traffic packets. You also want to look out for repeated attempts on ports that are out of the ordinary or do not have corresponding services attached to your system.

In the example above I discovered that my backup service was being blocked at the firewall. This is a good reminder to check your logs.

Reviewing User-Specific Logs

Many user-specific operating-system components and third-party applications, such as 1Password, Carbon Copy Cloner, ClamXav, and Yasu, log data into files inside each user’s home directory. These logs are stored in the ~/Library/Logs folder. Because they are kept inside each user’s folder, the logs are accessible only to that user (or anyone who has access to the account). This is good for the privacy of each user, but it can make troubleshooting difficult. Keep in mind that logs stored in a user’s home directory are owned by that account, and could easily be modified by a proficient user. Any information gleaned from these logs should be taken with a grain of salt.

One log of note in the ~/Library/Logs folder is DiskUtility.log. This log file stores all the activities run by the Disk Utility application, including fixing permissions, fixing the disk, and formatting and partitioning. The Disk Utility logs do not get rotated, or cleared out on a routine basis, which makes them particularly useful if you are investigating suspicious behavior on the system. Let’s say you suspect that a hard drive was reformatted. By reviewing DiskUtility.log for each user on a system, you will find who reformatted a hard drive as well as any settings that were customized during the reformat process. The following is a sample Disk Utility log:

**********
2015-06-12 23:05:51 -0400: Preparing to erase : “8GB_xinuos”
2015-06-12 23:05:51 -0400:      Partition Scheme: GUID Partition Table
2015-06-12 23:05:51 -0400:      1 volume will be created
2015-06-12 23:05:51 -0400:              Name            : “8GB_xinuos”
2015-06-12 23:05:51 -0400:              Size            : 8.02 GB
2015-06-12 23:05:51 -0400:              File system     : Mac OS Extended (Journaled)

2015-06-12 23:05:51 -0400: Unmounting disk
2015-06-12 23:05:53 -0400: Creating the partition map
2015-06-12 23:05:56 -0400: Waiting for the disks to reappear
2015-06-12 23:05:56 -0400: Formatting disk3s2 as Mac OS Extended (Journaled) with name 8GB_xinuos
2015-06-12 23:06:06 -0400: Initialized /dev/rdisk3s2 as a 7 GB case-insensitive HFS Plus volume with a 8192k journal

2015-06-12 23:06:06 -0400: Mounting disk
2015-06-12 23:06:20 -0400: Erase complete.
2015-06-12 23:06:20 -0400:

Another log of note is the ClamXav-scan.log, which records all the results from an antivirus scan, and then summarizes the findings.

/Users/dano/Sites/surfcam_files/.DS_Store: OK
/Users/dano/Sites/surfcam_files/index.html: OK
/Users/dano/Sites/surfcam_files/jwplayer.js: OK
/Users/dano/Sites/surfcam_files/player.swf: OK
/Users/dano/Sites/surfcam_files/SurfCams.html: OK
/Users/dano/Sites/surfcam_files/swfobject.js: OK
/Users/dano/Sites/surfcam_files.zip: OK
----------- SCAN SUMMARY -----------
Known viruses: 3731269
Engine version: 0.98.5
Scanned directories: 73406
Scanned files: 544600
Infected files: 4
Total errors: 11
Data scanned: 144820.95 MB
Data read: 481779.80 MB (ratio 0.30:1)
Time: 18750.559 sec (312 m 30 s)
Mar 28 12:19:34 dimac04-2 newsyslog[10265]: logfile turned over due to size>5120K

Whether you believe in the efficacy of antivirus scans of OS X or not, it may be a requirement in an enterprise environment.

Launchd, the process that controls scheduled activities, also has the ability to log data. When you suspect a root kit (discussed further in Chapter 8) has infected your system as one user but isn’t active for all users, take a look at the launchd logs for your user account to see whether any events are occurring that you should be concerned about. Things to be concerned about include non-Apple services being initiated. The log level for launchd is set with the launchctl command. launchctl log mask notice will configure launchd to log events with every severity between Emergency and Notice.

User logs can be helpful in determining what was done while logged into your account. When used in conjunction with the other logs mentioned, you can get a fairly specific idea of what was performed on the system recently.

Some other user-specific logs to be aware of for forensics or information are: 1Password, appstore.log, the directory with Diagnostic Reports, FaceTime, the FlashPlayerInstallManager.log (especially this, since Flash must be kept up to date), GoogleSoftwareUpdateAgent.log, LittleSnitch (if you run it), gpg logs (if you use that personal privacy application), the VMware Fusion logs, and more.

Reviewing Command-Line Logs

DiskUtility.log lets you know if somebody burned a disk with Disk utility, but it won’t show whether someone ran a reformat or repair operation from the command line. For command-line information, it is often best to look into the command-line history for each user. This information is stored in the history file. The history file is different for each shell in which a user is operating. For example, the history file for the default shell, bash, is .bash_history. It is located in the root of each user’s home folder. The history files do not get automatically rotated by OS X subsystems and, by default will only keep 150 commands. As new commands are entered, old commands will expire. You can view history by using the history command (no arguments are needed), and you can clear the history by using history -c. Although the history file can be difficult to correlate events to when unaltered, it is one of the most important items to review as most will not alter this file.

When you use the su command, you are substituting your identity for that of root, the system’s built-in administrative user, or another user if you indicate another user during that process. Any commands that are run as the user you have switched to using the command line would be captured in the root user’s history, not your own. This means you need to log in to each account in order to review the account’s history. Reviewing the history file can be fairly difficult if you are looking to correlate history events with other logs. Unfortunately, there are no date and time stamps available in the history file to indicate when commands were run. However, provided a user has not rotated their logs, you know which commands were run, and in which order, and sometimes you can correlate this with system events from log files. Some of these commands may be recorded in the BSM log file, so that can help to correlate events on a timeline. However, BSM has to be configured appropriately to capture these events. To complicate matters even further, different users like to use different shells (a shell is just a different way to interface with the command line). Most users use bash (which is the default on Mac OS X), but others might use tcsh or ksh. Each shell has a different history file, and some, by default, don’t log history at all. If you switch to the bourne shell, your history will be stored in .sh_history. This gives you a lot of places to look for information if you have multiple shells running in Terminal. Luckily, bash is the most commonly used shell.

The last command will show a listing of the last users who logged into the computer and how long the login sessions were open. The format of the output of a last command is the username followed by the Terminal type, then the date logged in, and finally the start and stop time of the Terminal session. ttys001 indicates the first Terminal window opened. If a second is opened, it is ttys002, the third is ttys003, and so on. This goes back to mainframe days when each terminal station had a unique identifier. This can give you a good log of recent login activity for a specific machine.

gene      ttys001                   Tue Nov  3 23:09 - 23:15  (00:05)
gene      ttys001                   Tue Nov  3 23:04 - 23:04  (00:00)
gene      ttys000                   Tue Nov  3 22:35   still logged in
gene      console                   Tue Nov  3 22:23   still logged in

Reviewing Library Logs

If you’ve ever helped a friend move, and that friend was a fairly efficient mover, he probably assigned someone to stay in the moving truck to arrange everything so that the maximum amount of stuff could fit. This lets everyone else maximize efficiency by moving stuff from the house to the truck without worrying about how it’s packed. This idea can be translated into the ways in which software applications are programmed to work in an operating system. It often makes sense to use a shared library of items that many different applications can access. This allows more features to be written with less programming, which means greater efficiency, much like the guy in the truck allows the people moving furniture from the house to do so more efficiently.

Because the /Library folder keeps many shared application libraries (think of these as mini-applications), the types of logs stored here tend to be those generated by components that are shared across multiple applications. This includes CrashReporter, which writes application crash information into logs, and also server and directory service logs. Many application programmers also choose /Library/Logs as their log destination. This, for instance, would explain the random Timbuktu log you might notice in there.

Many applications and shared libraries communicate using data that might not make much sense to the untrained eye. In the crash logs, you will typically see hexadecimal memory segments listed, followed by the library that wrote the alert and then the path to the library. For example:

0x96e15000 - 0x96e2ffff libPng.dylib
/System/Library/Frameworks/ApplicationServices.framework/
Versions/A/Frameworks/ImageIO.framework/Versions/
A/Resources/libPng.dylib

These hexadecimal sequences in the logs can help decipher why a crash occurred if foul play is suspected. Nine times out of ten, rather than confirm irregular activity, you will instead find that there is actually a technical problem that caused the crash.

Breaking Down Maintenance Logs

Chances are you see your doctor at regular intervals. The dentist you’ll see every six months, and the family physician you’ll see every year. Just as your body needs to be maintained in regular intervals, so must your computer. Maintenance scripts run at scheduled times, and if one is missed, much like a doctor’s appointment, it is usually scheduled for the next available time. Maintenance scripts need to be run because they log what devices were plugged into a system, they back up the user database, and they do much more. Machines can be left off at night, laptops can get closed, and power outages can disable a system, helping to explain the disparity in time stamps you may see when viewing your maintenance scripts and why you may occasionally skip the execution of a maintenance script.

One thing that maintenance scripts do is rotate and archive certain log files, which can get really big. Try to imagine how large a log file would get if it logged every step, turn, and move you made. When archiving, the log files are usually archived into compressed files using the bzip format, a compression technique commonly used to reduce the size of single files. Once archived, the file will be renamed and cleared and become ready to begin writing new data. Some people refer to archiving a log as “rotating it.”

Those logs that are not rotated by the periodic scripts are maintained by newsyslog, which is run every 30 minutes by launchd. The configuration files for newsyslog are located in /private/etc/ and /private/etc/newsyslog.d. Newsyslog.conf covers the rotation of files written by syslogd, and the files in newsyslog.d cover the rotation of files written by other processes.

The important option to configure in newsyslog.conf is count, which determines how many archive files to keep. By default, seven old versions of system.log will be kept, but only five old versions of secure.log will stick around. If you’re interested in greater retention of files, change count to 10 (or even 15). Take care, though, as keeping more logs will take up more space than you might imagine.

In addition to archiving logs, maintenance scripts also perform other functions. These include removing temporary files, performing backups, reviewing drive capacity, checking how long you’ve been logged into your computer, and checking network statistics.

Mac OS X uses three main maintenance scripts that log data into separate files. These are known as periodic scripts. They include daily, weekly, and monthly. You can manually run these periodic scripts by using the periodic command . For example, to run the daily periodic script, use the following command:

sudo periodic daily

You can configure the periodic scripts to log more data than they do with the default settings. You can configure the manner with which periodic runs the daily scripts using the periodic.conf file located at /private/etc/defaults. You should make some minor adjustments to the periodic.conf file to increase the logging of events. These include the following:

• Change the NO in the lines for weekly_show_badconfig="NO" and monthly_show_badconfig="NO" to YES to have a periodic report of when there is bad configuration data found by the monthly.out file.
• Change the NO in the line containing the daily_clean_logs_verbose="NO" option to YES to have periodic show the files as they are being deleted.

daily.out

The daily.out file is an output file created by the daily maintenance scripts that run on your system. Like many of the maintenance logs, daily.out begins with a time stamp to provide you with the context of when it ran. Next, the daily.out log shows which old logs the daily script removed. For example:

Sun Nov  8 19:41:40 PST 2009

Removing old log files:

Removing old temporary files:

Cleaning out old system announcements:

Removing stale files from /var/rwho:

Removing scratch fax files

Disk status:
Filesystem     Size   Used  Avail Capacity  Mounted on
/dev/disk0s3   118Gi  50Gi   68Gi    43%    /

Network interface status:
Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll
lo0   16384 <Link#1>                            82     0       82     0     0
lo0   16384 localhost   ::1                     82     -       82     -     -
lo0   16384 localhost   fe80:1::1               82     -       82     -     -
lo0   16384 127           localhost             82     -       82     -     -
gif0* 1280  <Link#2>                             0     0        0     0     0
stf0* 1280  <Link#3>                             0     0        0     0     0
en1   1500  <Link#4>    00:1e:c2:ab:d7:9f     4536     0     4271     0     0
en1   1500  localhost   fe80:4::21e:c2ff:     4536     -     4271     -     -
en1   1500  192.168.11    192.168.11.5        4536     -     4271     -     -
en0   1500  <Link#5>    00:1e:c2:19:fd:b0        0     0        0     0     0
fw0   2030  <Link#6>    00:1f:5b:ff:fe:2d:89:c0        0     0        0     0     0

Local system status:
19:41  up 44 mins, 4 users, load averages: 0.02 0.05 0.01

-- End of daily output --

The big thing to look out for here is that the Ipkts field is greater than the others. The Name field refers to the name of the interface that the MAC address and the other statistics will be relevant for. The Network field is similar to the Name field but states the network that the interface can run on. The MTU field is the maximum transmission unit, which means the largest “packet” size that can be transferred in one physical frame on a network. Ipkts refers to the incoming packets, and Opkts refers to outgoing packets. The Ipkts field should always be higher than the Opkts field. If anything here looks like it is out of the ordinary, such as the Opkts field being higher than the Ipkts field, it often means you need to reinstall the drivers for your network interface. Another item to look out for is high numbers of collisions (the Col column). If your collisions are more than 10 percent of the Ipkts field, then you might have issues with your network.

The final action of the daily maintenance script is to rotate the system.log file. The system.log file is often the largest log file on the system. This is discussed in further detail later in this chapter. The daily script is scheduled to run at 3:15 AM every day.

Yasu

Yasu is a nice little free application that will run maintenance scripts if they are missed because the computer was turned off during their regular schedules (see Figure 5-4). Not only is it important to run the periodic maintenance scripts in order to view their output logs for errors, but it is equally important to run them in order to manage the size of the various log files that get archived with this script. To do this, simply open Yasu, make sure only the daily, monthly, and weekly cron script boxes are checked, and then click OK.

Weekly.out

The weekly periodic script runs at 3:15 AM on Saturdays. It updates the “whatis” database (used for the whatis command, which searches through man pages for words you provide), and little else.

Sun Nov  8 19:42:20 PST 2009

Rebuilding whatis database:

-- End of weekly output --

Monthly.out

The monthly.out log file is created by your monthly maintenance scripts and can be used to display what the monthly script did. As with the daily.out and weekly.out files, the monthly.out file will start with a date and time stamp. Monthly.out can keep track of how long a user is logged into a system, a feature unique to this file. Login accounting is useful if you suspect that a user’s password has been compromised and someone is illegally logging into a machine.

Sun Nov  8 19:58:15 PST 2009

Rotating fax log files:

Doing login accounting:
        total       17.11
        gene        16.99
        root         0.11

-- End of monthly output --

The monthly.out script ends with a statement about the log files that it rotated. Logs that are rotated monthly generally do not get to be more than 150KB in size. The install log, for example, should be empty if you haven’t installed any software in the past month. If you do see data in this file and you haven’t installed software, then review what software it is and check it.

The monthly script is scheduled to run on the first of the month at 5:30 AM local time.

What to Worry About

Los Angeles can be a strange place to live. If we ducked for cover every time we heard sirens, we wouldn’t get a wink of sleep or any writing done, and you wouldn’t be reading this book. To some extent, much of what could be considered worrisome simply becomes normal in a big city because of all of the “white noise” to which we’re exposed.

The same goes for log files. There is a lot of information in your log files, and not everything is important. This can be overwhelming for anyone, even the most senior systems administrators. We’ll now cover some of the items to be on the lookout for when reviewing your logs and some of the ways to reduce the amount of “white noise” in the logs.

One way to do this is by using keywords. The words failed, error, and incorrect are usually important to look out for. Read the content surrounding these for more information, or use an automated analysis tool. Sorting through a log file can also be automated by using a log analyzer to help keep track of events on user systems. An excellent open source option is Swatch, which has been used by Unix systems administrators for a long time. It has been ported to Mac OS X, and can monitor just about any type of log you’ll find. Other open source options are logsentry (formerly known as logcheck), a component of a security suite called Sentry Tools, and logwatch, both of which are available through MacPorts. There are also commercial options such as Sawmill, an analysis tool that can analyze hundreds of different log file formats, Graylog, an open source log aggregation tool, and Splunk, a monitoring and reporting tool that consolidates logs (as well as data from many other sources) into a searchable database.

Activity Monitor

In order to more easily identify some of what you see in your logs it is helpful to have an idea of what is going on in your machine. By this we mean you ought to have an idea of what processes are running behind the scenes. A good way to look at this is with the Activity Monitor. You can find the Activity Monitor in /Applications/Utilities.

Virtual Machine and Bootcamp Logs

It’s hard to imagine that discussing the methods that Windows uses to log events would ever factor into a book about the Mac. Who knew ten years ago that two competing technologies would ever converge? But converging they are. And if your computer is running VMWare Fusion, Parallels, or Bootcamp with Windows, then security is going to be one of your top concerns. As we’ve discussed throughout this chapter, logs can give you a wealth of information about how secure your system is. Windows has its own tools that can help you to secure a Windows environment on the Mac.

Event Viewer

The Event Viewer is similar to the Console application on a Mac. It provides an administrator with one place to go to find information about service-oriented errors on the system itself. Microsoft changed the structure and event codes after Windows XP. While Windows 7 and Server 2008 have much more detail in their event logging, the concepts are the same.

The Event Viewer is split into three parts (see Figure 5-5) in Windows 7. Windows XP and the different versions of Windows Server may look different, but for the sake of discussion in this book, we will concentrate on Windows 7. On the left is a list of Event categories, similar to the Log List in Console.

• Application contains events that are logged by programs. This includes database, Microsoft Exchange, SharePoint, and other applications that write data into logs that are not part of the core operating system.
• Security contains information about security events that have occurred when logging onto the computer. If you have enabled audit trails on file access, then this can be a verbose log. Otherwise, it is usually a very small log. Look out for anything with the word failure in the log because this can signify a failure with a security process.
• System shows you the events that get logged by the operating system. This includes drivers and other system components that could produce an error.

There is a plethora of Microsoft event IDs in the Event Viewer. Microsoft has made it fairly simple to sift through these event IDs to find the errors by using color-coding. Blue means no action is necessary, yellow indicates that an item should at least be looked at, and red indicates a failure. By researching the contents of each of these entries, you will get a good handle on what Windows is having any problems with, including many events directly related to the security of your system. Windows Event logs are rather easier to read than OS X’ raw logs, but the readability of both is vastly improved by using an audit log aggregator.

Although it may seem daunting at first, you should know what every warning and error message means. The Microsoft Web site is a good place to research information about these events. Another good reference to Windows event logs is Ultimate Windows Security.¹

Task Manager

The Event Viewer is helpful for researching events that have already occurred on your system. But it doesn’t go into detail about all the processes currently running on your system. The Task Manager in Windows is similar to the Activity Monitor on a Mac, and will provide you with the ability to look at what processes are currently running (see Figure 5-6).

To see the Task Manager, press the Ctrl-Alt-Del keys on your keyboard, and choose Start Task Manager. Here you will see a few tabs. The first is Applications, which contains applications currently running under your account. The second is Processes, which contains the applications you have launched and any background processes that might be running, as well as the user who started the process and the CPU and memory being taken up by that application. You can use the Performance tab to check memory and processor utilization and get a chart that shows this.

To stop a process that is running, you can right-click it and click End Process. To find out more about a process, consider using Google or the Microsoft Knowledge Base at www.microsoft.com/support to research what each process is doing on the system.

Performance Alerts

You can use the Performance Monitor Management Console Snap-In (see Figure 5-7) to customize the amount of information that is being logged and to provide you with extremely detailed information about nearly every aspect of how your system is running. This tool is far more advanced than those available on the Mac platform for tracking down bottlenecks in speed, levels of inbound traffic, and other items that could introduce security issues. A comprehensive discussion about this tool is beyond the scope of this book, but should definitely be consulted when trying to troubleshoot why the Windows environment on your computer is running poorly.

While it is possible (maybe even common) for many Windows admins to know just one operating system, many Mac admins need to know at least one OS in addition to OS X. While this is usually Windows, it does not hurt and can be quite helpful to learn to work with linux and perhaps even a BSD variant (most likely FreeBSD). In an enterprise security environment it’s common to use one of these unix-like operating systems in security appliances or dedicated systems. (For example, your penetration testing system will probably be Kali Linux.) With the added functionality of virtual machines in VMware Fusion or Parallels, these highly useful systems can be installed for free.

Review Regularly, Review Often

Reviewing logs is an integral aspect of security, and you should review them routinely. If you are the only person responsible for looking at logs, set up a recurring event in your calendar program to remind you to do this. This might be daily, weekly, or monthly, according to how concerned your organization is about the health and security of your system coupled with how complex your environment is.

Accountability

Establishing some form of accountability is also important. Have you ever gone to a bathroom in a gas station and seen a sign-in sheet for the attendants to mark when they’ve cleaned the bathroom? If a customer complains about a dirty bathroom, the manager can use the sign-in sheet to find out who forgot to clean it. Similarly, unless you establish some form of accountability, you will likely run into a situation where your logs haven’t been checked in months, especially if you are dealing with multiple people in charge of log checking.

Using a spreadsheet or a sign-in sheet to indicate when log files have been reviewed is an excellent way to establish accountability for log checking. You can also track when logs are backed up to optical media (or some other form of storage) if you choose to do so.

Another alternative is to use the sudoers file. This is a special file that provides allows designated users and account access to elevate to other accounts, i.e. “substitute user”. What it effectively does is force a user to log in with their own account and then use the sudo or “substitute user do” command to change accounts. Usually this means they are switching to a more privileged account, such as root. And this then means that anybody who uses the root account must log in as themselves first, which provides accountability. It is fundamentally different from four or five people having root and then you having to do forensics on some bad event only to find out you cannot tell which of those four or five (minus yourself) may be responsible for that event. You can check the manual page for sudoers (man sudoers), or check Wikipedia² first. Note that you should edit the sudoers file with caution as you do not want to lock yourself out of your privileged accounts. Editing the sudoers file requires a special syntax so you should practice on a lab machine or a lab test virtual machine before you edit the sudoers files on production computers. This is particularly useful if you have to track down an APT event or an outside intruder who has captured a login from one of your privileged users and done something untoward in one or some of your machines. The sudoers files is located at /etc/sudoers.

The following are the items to include in your regularly scheduled log reviews:

• When were the periodic maintenance scripts (daily, weekly, and monthly) last run? You can easily find this using ls –l /var/log/*.out to see when their log files were last updated. Was there anything out of the ordinary in those logs?
• Were there bad password attempts? Look for repeated bad password attempts in the log for any service that accepts a network connection, such as the smb.log (if there are Windows computers on your network) or ftp.log (if you are sharing files through FTP).
• Look for any bad password attempts, and check for privilege escalations.
• Do you know who your privileged users are? Do you know when they log into your system? Set up the sudoers file and give explicit access only to those privileged users who need it.
• Review the history command to check for strange commands and the last command to look for weird user logins.
• If you’re running Parallels or Bootcamp, check your Windows Event Viewer.
• The access.log file in the /private/var/log /cups/access_log folder shows all the CUPS activity on your print server.
• The logs located in the /private/var/log/samba directory deal with access attempts from Windows computers.

Incident Response

Smart homeowners have a disaster plan in place for what to do if their home is affected by a natural disaster or burglary. They post the phone number to the local police or fire department next to their phone. In California, earthquake country, they keep gallons of water and canned foods stored in their pantries. Whether they know it or not, they are developing an incident response plan.

If, in your searching through regular log files, you find something that concerns you, then you will want to also have an incident response plan for how you are going to handle these incidents. Incident response plans don’t have to be very complicated, but the more people who are involved in the operations of your information systems, the more involved the incident response plan will be; therefore, the more complex the infrastructure, the more thought out the incident response plan should be.

The incident response plans can vary from location to location. For example, if you are troubleshooting your security logs at home, a typical incident response to a suspicious item in a log might be to spend an hour trying to discover what occurred. After that initial hour, if you haven’t managed to discover the culprit, you will immediately reformat your hard drive and restore your data from backup. (You do have backups, right?) But at the office, you might decide that if a security event occurs and you cannot figure out what the problem is, you will open a ticket with AppleCare immediately, down the system, make a check-summed clone of it, install a new hard drive, install OS X on the new hard drive, and migrate data. Home incident response plans are typically easy to compile and really just offer you a task list of what to do in the case of a security incident. Office incident response plans are typically more comprehensive, and need to go through committees or IT groups for approval, especially because they could contain some mission-critical systems with guaranteed uptimes that need to be maintained.

We cannot stress enough the importance of implementing an incident response system. Intellectual property theft is on the rise. Companies have lost billions of dollars in revenue over the years because of stolen intellectual property. When it occurs, it is usually not a sudden occurrence; it happens over time. More often than not, the logs were giving clues to breaches in the security framework long before the actual theft occurred. Some companies have been put out of business because of security breaches. An incident response plan coupled with a tested, reliable backup plan spares everyone the heartache and devastation of stolen intellectual property and financial information.

Incident response plans can become fairly complex if you consider some of the possibilities such as a disaffected insider doing damage or data theft, or an intruder who has gained privileged access and you have to determine the extent of the damage and their access. Your incident response plan should have policies as well as technical measures.

BSM – Auditing with the Basic Security Module

During the early production period of OS X 10.3 (Panther) Apple quietly contracted with McAfee Research Labs to develop a system of internal monitoring and logging of a large number of diverse actions that occurred outside the normal logging environment. The purpose of this was to achieve Common Criteria certification for the operating system, as well as to enhance the security posture of the OS. This security subsystem allows auditing of many processes, and it is auditing that enhances the security and is one of the major factions in Common Criteria certification.

Since OS X is derived from FreeBSD, which is more similar to Solaris than many operating systems, the choice was made to create this security subsystem for both FreeBSD and OS X, and to model it after BSM that is built into Solaris. In late 2004 OS X 10.3.6 was released with BSM as an option that could be installed into the system, and would be operational with some additional configurations.

(The audit subsystem was part of Common Criteria Tools.³ From 10.6 to the present 10.11.x the audit subsystem is built into the operating system so you do not have to install it. In fact you should not attempt to install it as doing so will break your system. There is an Administrator’s Guide (see the link in the footnote below) that includes a guide to using the audit system and interpreting its output.)

Over the ensuing years this BSM was developed so that it quickly became a native part of the OS (not optional) and no special configuration was required for it to work. Also, this version of OS X was granted Common Criteria certification,⁴ which validated it for some high security uses such as the US Government. In the ensuing years BSM was developed further for both FreeBSD and OS X, and is now commonly known as OpenBSM to distinguish it from BSM in Solaris.

Currently Apple has documentation about the OpenBSM system in its Open Source Projects description tree here⁵ and here,⁶ and in the Developers guide.⁷

The OpenBSM subsystem also creates log files, but this log environment is completely separate and different from the Apple System Logs (ASL) and the other log files that are described above. While the OpenBSM system could have an entire chapter devoted just to it, let’s take a look at its basic functions, configurations, and uses of auditing.

If you boot a Mac while holding down the Command-V keys you will set the machine to boot into verbose mode. This will send to the display a line for every process that starts, and many configurations. This will amount to hundreds of lines, and is sometimes a useful tool in troubleshooting. If you watch the first few lines you will see the BSM system start up. That is, the Basis Security Modules is one of the very first processes to start in the operating system. This is important in tracking everything that the system does, or that any process or user does as well.

[illustration of the top of the boot screen]

The OpenBSM process is one that is owned and managed by the kernel. This means that – unlike nearly all the other log files – it can only be accessed by the superuser or root. Consequently this also means that both configuring the system and reading its output requires that an administrator account in the OS must elevate to root in order to get at the OpenBSM system.

One of the first places to look for information about OpenBSM is in the man pages. Here you will find information about auditd, the audit daemon, as well as the commands and configuration files that are available to you, the system administrator and/or auditor.

Fortunately for us, there are actually few commands to learn. However, the configurations files are somewhat more complex, and the output files are actually very complex and can require considerable time, study and practice to learn to work with and understand.

The Audit Daemon and Audit Commands

The audit daemon is controlled by the kernel, so you will not touch auditd directly. However, you have access to several commands that tell the audit daemon what to do: The audit command allows you to restart and resynchronize the audit daemon to a new configuration of audit settings, or to simply close the currently open audit file (also known as an audit trail file, or simply audit trail) and to open a new audit trail. There are a few other flags available to you in the audit command, but these two are most commonly used.

The two other important commands in the audit system are auditreduce and praudit. (The command auditpipe also exists, but it is used much less than the first three.)

The auditreduce command allows the auditor to filter out data that is not important to the audit search when looking through the existing audit trails. For example, you may configure the audit system to capture when a user logs in or out, when a user opens and closes files either successfully or unsuccessfully, and when either a user or the operating system starts and closes processes. But you may want to do a search through these audit trails that only returns the action of when a specific user logs in. Or you may want to restrict that even further, to when a specific user logged in on a certain day and between certain times. The auditreduce command allows you to do this.

The praudit command is when you want to convert those audit trails, whether they are reduced or whole, from the native binary format into text files.

This is another facet of the security that the OpenBSM system provides. That is, the audit trail files that are generated by the kernel are stored in binary encoded form that is similar to encryption, and they can only be read after being decoded by the kernel upon your command to “print” the audit trail files. This prevents any user who does not have access to root from reading the files. In addition the directories (or folders) that these audit trail files are stored in are owned by root and no other user on the system has access to write to or read from these directories.

Of course if a user already has access to the machine and knows enough about OS X to know of the existence of the audit files then they may be knowledgeable enough to figure a workaround and access the files anyway. For this reason, in an environment where the integrity of these security files is important we recommend that you or your system administrator move the files to a remote server that is inaccessible to most general users. (This is one advantage to using a log aggregator.)

The praudit command has only a few modifiers. You can change the style in which the audit trail records are displayed so that all records are on a single line, or that the components of each new record (called tokens) are themselves each printed to a new line. The latter setting is the default and this is probably the configuration you will most commonly choose to print to.

You can also choose to print a short, long, or raw version of the audit trail.

One of the more useful options in the praudit command allows you to choose whether to view the user ID (UID) as a number or as a user name.

Finally, another useful option in praudit is to print the decoded audit trail files into XML format. This can be useful if you need to view the audits in a browser or if you are converting them to a format that is ultimately going into a log aggregator such as Splunk or Graylog.

Configuring the Audit System

The audit system is installed in a default configuration that is probably sufficient for home use, but in an enterprise environment you probably want to collect more information about the dynamic security of the host machines. These primary configuration settings are in the audit configuration file, named audit_config, which is located at /etc/security/audit_config.

There are five configuration files located in /etc/security and as root you can modify all of them, but in practice you will probably only change audit_control. These five config files are: audit_class, audit_control, audit_event, audit_user, and audit_warn.

The illustrations below show three different configurations of the audit_control file. The first configuration is the default configuration for all versions of OS X since (about) 10.6.

Default Audit Settings

[illustration of audit_control.orig]

The default settings and flags in /etc/audit_control

Let’s look at some of the settings in this configuration. The first line is preceded by the # symbol, so it is commented out of the actual configuration. However, it is a good reference to the OpenBSM project.⁸ The most relevant settings are lines 4-10.

Line 4: The default configuration of “dir:” directs the system to store the audit trail files in /var/audit. It’s best to leave this configuration in place unless you really need to place the files somewhere else. And if you do need to change the default audit trail store location remember that this directory has special access controls that you may need to apply to the new location.

Line 5: The audit “flags” tell the kernel which actions it should monitor. In the default configuration it tracks only logins and logouts with the “lo” flag, and the “aa” flag, which records authentication and authorization events. These two flags are basic requirements for any enterprise, but there are other flags that add more richness to a host security profile.

Line 6: The “minfree” setting determines the minimum free space on the storage volume that is required before the audit daemon will stop the entire system from operating. In this case if the boot drive gets down to 5% of its total storage volume then the audit system will cause the OS to stop functioning. This can be a dramatic event for the user, but it is not drastic for the administrator. If the drive fills up to this point then somebody – probably the administrator – needs to clear some of the files. But you might ask how does that happen if the OS is no longer functioning? Actually, the OS will continue to function, it just will not get to a login screen. The seasoned administrator will have to log into the system in single-user mode and then clear files to create adequate storage availability so the OS can return to normal function on reboot.

In these days of very large hard drives this may seem like a trivial consideration. But in fact the audit daemon itself can generate extremely large volumes of audit trail files if it is configured to capture too much information. Consider this a cautionary note as you modify the “flags” and “naflags” in the audit_control file. It is possible to generate gigabytes of audit data in minutes or even seconds. At this rate it is possible to fill up multiple terabytes of data within hours.

Line 7: Certain actions can be considered as non-attributable to a specific user or process, and these actions are captured by “naflags”. Consider a scenario where an intruder attempts to log into a Mac. Before completing an authenticated login the intruder’s actions are not attributable to any user or process on the machine, and his (or her) attempts will be captured by these flags. And just as in the settings for “flags”, lo and aa stand for login/logout and authentication and authorization. Less data will be captured, but there are processes that can run without attribution and these will be monitored by this na-flag setting.

Line 8: You can set certain policies for the audit daemon. The default case of “policy:cnt,argv” tells the system to, with ‘cnt’, continue auditing even if there is a failure in the audit subsystem, and with ‘argv’ to audit commands issued in the Terminal. If ‘argv’ is not entered as a policy, then a user could bypass the audit subsystem by working from the command line.

Line 9: The setting “filesz” tells the audit daemon how big a file should be allowed to become before it is closed and a new audit file is started. This is equivalent to how the Apple System Logs are rolled over when they reach a certain size.

Line 10: The audit trails will continue to collect indefinitely in /var/audit without a configuration setting telling the system when to discard files. Setting “expire-after:10M” tells the system that the audit directory should be maintained at no more than 10 megabytes, with a policy of first-in-first-out. This should be sufficient for you to capture the audit trails in a log aggregator or an audit log server before they are automatically deleted by the system. However, in these days of very large boot drives you are probably safe in changing this setting to something somewhat larger. I often set this to 100M if I have to manage the audit trails manually, as this gives me some extra time to get to the files.

Now that we have examined the default settings, let’s look at some examples of settings that provide more functionality.

Naming of the Audit Trail Files

Like all the other log files the audit trail files are named automatically. In a localized environment such as a home user or even a small office it may not be important to distinguish the audit trail files, but in an enterprise environment where the audit trails are being collected and indexed for later analysis.

The audit trail files have a naming convention that is very different from any of the conventional log files. By default the audit files are named with the date and time that the file was created, then a dot for separation, followed by the date and time that the file was closed. A shorthand notation for this format would look like: yyyymmddhhmmss.yyyymmddhhmmss. For example, an audit trail file that was created on September 30, 2015 at 8 AM (Pacific Daylight Time) and then closed exactly 24 hours and 1 minute later would be named: 2015093015000.2015100115001. Note that there is no indication of the hostname of the machine that produced this file, and unlike the conventional log files there is not always a solid indication of the host source inside the audit trail files. To rectify this problem the programmers have built in a setting that allows the system administrator to tell the kernel how to name the files.

Setting the Hostname in Audit Trails

[illustration of audit_control mod 1, hostname added]

In the illustration above I inserted a new Line 5, with the entry “hostname:rincon”. This tells the kernel to append a dot followed by the name to the end of each new audit trail file. This is particularly helpful when using a log aggregator where all the audit trail files can appear to be identical. Also note that this feature is not identified in the man pages (yet), so you will need to remember it when doing your configurations or when making and following up on images for distribution.

Audit Trail Configurations for High Security Environments

[illustration of audit_control mod 2, Ch.8 config added]

In some cases you may need a more complex audit_control configuration to provide more detailed auditing. The reason for this might be because the systems operate under stringent regulations or because you need to have better insight into what a particular user or process is doing. (An excellent example of using audit trails to follow the behavior of processes can be found in a 2012 research paper by Todd Heberlein, MSCS.⁹ In this study he tracks how Google’s Software Update mechanism works in a Mac.)

In this revised audit_control configuration file I have further modified the flags so that the audit daemon also watches for the following:

• ad – administrative events, either succeeded or failed,
• -fr – failed attempts to read a file
• -fw – failed attempts to write to a file
• -fc - failed attempts to create a file
• -fd - failed attempts to delete a file
• -fm - failed attempts to modify the metadata of a file such as a creation date
• -cl - failed attempts to close a file

In line 3 you’ll see that I have also added a comment about the addition of the hostname and these new audit flags. These audit flags are the minimum requirement for a US government security regulation found in the National Industrial Security Program Operations Manual for Protection Level 1 (PL1).

If the config file for this computer was required to meet PL2, then I would remove all the dashes in front of the flags so that the audit subsystem would collect both failed and successful instances for each of the operations.

More On Audit Trails

These nine audit config flags above are actually settings for classes of events rather than for individual events. These nine are just about half of all the available classes, and each one of the nine contains numerous individual event types. For example the ad or administrative event class alone watches for and will record the details of more than 80 individual event types. And though ad is one of the larger event classes it is not unusual to have this many events in a classes.

The other classes that are available are as follows (from the FreeBSD manual¹⁰):

With these 20 classes there are over 160 actual events.

Viewing Audit Trails

The audit trails are stored by the kernel in /var/audit and they are owned by the kernel. Because these files are owned by the kernel, in order to access them in any way you will have to elevate to root. I commonly use the sudo su command to temporarily operate as the super user.

After elevating to the super user you can cd into /var/audit and ls to view all the files. Use ls –al to view the metadata of the files.

Since our configuration file says these files should rotate every 2MB we should see no files bigger than that. Also, the config file is set to expire old files to keep the aggregate file volume no larger than 10MB. These are the default configurations and you may find that you prefer to keep an expiration size somewhat large. This is especially useful if you set the flags and non-attributable flags to be more than the default. I commonly use the PL1 configuration so I set my expire setting to be 100MB. (And in these days of terabyte hard drives you can probably afford to keep your audit files stored locally for a longer time period.)

Since these files are stored in binary code they will not be viewable in their native form in any text viewer. This is different from most other files that have been discussed earlier in this chapter. To view these files you will have to work within the audit system and use the commands auditreduce and praudit. The use of these commands is addressed above in the section The Audit Daemon and Audit Commands.

Output and Interpretation of Audit Trails

For an example of how to deconstruct and interpret an audit trail file I scrubbed through a few files using auditreduce to look for an example of a login or logout. To do this I used the following command to 1) search for and extract an lo record, then piped that record to praudit, then told praudit to print that result to a text file.

auditreduce –c lo 20151022043941.20151022044928.dimac | praudit > 20151022043941.20151022044928.dimac.txt

This resulted in the following record. Note that the record consists of four lines. Each of these lines is referred to as a token, and each token has comma-separated values which are known as fields. In this example of a login, there are four tokens – header, subject, return, trailer.

header,72,11,loginwindow login,0,Wed Oct 21 21:46:27 2015, + 366 msec
subject_ex,dano,root,wheel,dano,staff,276,100007,50331650,0.0.0.0
return,success,0
trailer,72

Every record will have a header and a trailer, so you can expect to see those formatted in the structure above. All other records will have different tokens for different events, and those tokens can and do have different structures depending on the kind of audit event information they contain.

For more information about the various events and their respective token structures see the Apple Common Criteria Configuration Guide, Security Event Auditing in the FreeBSD Manual, and the Sun Basic Security Module Guide.

Summary

In this chapter we looked at the various logs and logging facilities built into Mac OS X. These logs provide insight into what is happening on the inside of your computer. They can be used to guide you in troubleshooting efforts and to act as an early warning sign, even when you don’t have a symptom you are looking to troubleshoot.

The logs in Mac OS X can also be used to obtain critical security information. Using the steps we laid out, you can centralize logs, or run scripts to aggregate information routinely. Those aggregated logs can enable you to see what is going on throughout an enterprise with very little work from savvy systems administrators.

Now that we have looked at logs, we’ll move on to one of the aspects of Mac OS X that can place information in those logs, applications. In Chapter 6 we will jump into securing applications, with a focus on leveraging Apple’s sandbox facility and rich application signing framework.

___________________________

¹Randy Franklin Smith’s Ultimate Windows Security: https://www.ultimatewindowssecurity.com/securitylog/quickref/Default.aspx

²Wikipedia on sudoers: https://en.wikipedia.org/wiki/Sudo

³Apple’s Common Criteria Tools for 10.3.6 (to the end of 10.3.x), 10.4 and 10.5, https://support.apple.com/downloads/Common_Criteria_Tools

⁴Common Criteria certification, https://en.wikipedia.org/wiki/Common_Criteria

⁵Open Source Projects, http://www.apple.com/opensource/

⁶the OpenBSM project files, http://www.opensource.apple.com/source/OpenBSM/OpenBSM-21/

⁷Apple Developer, https://developer.apple.com

⁸Security Event Auditing in the FreeBSD manual, http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit.html

⁹“The APT You Have: Google Chrome”, Todd Heberlein, 2012, http://www.netsq.com/Documents_html/GoogleAPT/

¹⁰FreeBSD Manual, 16.3.1, Event Selection Expressions, http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit-config.html