Exploring Audit Logs
There are many different types of audit logs on different systems. Operating systems include regular logs that record activity on the computer, applications frequently record information in application logs based on the needs of the application, and network devices (such as firewalls) regularly record different types of data to document network activity.
This section describes many of these logs and how you can use them to identify and track activity on your network. Together, these logs can help an organization to create a comprehensive audit trail to document a significant amount of activity on individual systems and networks.
Operating System Logs
Operating systems include logs that track activity on a system, and the operating system includes the means to review these logs. For example, Figure 10-3 shows the Windows 7 Event Viewer.
Figure 10-3 Microsoft event viewer
Microsoft operating systems include at least the system, application, and security logs, but newer operating systems since Windows Vista and Windows Server 2008 include additional logs. Any of these logs can record both success and failure events. In other words, if a user tries to read a file and is able to, it is a success event. However, if a lack of permissions prevents the user from reading the file, it is a failure event.
Security logs can record activity from any auditable activity. For example, an administrator can configure object access logging for objects such as folders, files, or printers, and then when a user accesses one of these objects, the security log records the event. Other auditable security events include deleting or modifying files or folders, modifying permissions, and more.
TIP It’s not useful to audit all objects, but instead administrators often choose to audit access to sensitive or proprietary data. For example, an organization may choose to record all access to classified research and development data, but not record access to publicly available data.
System logs record events from the operating system, such as when the system boots or is shut down or when a driver or service is stopped or started. Application logs record events from specific applications. These events can be from end-user applications, such as a web browser, or server-based applications, such as from a database server application or a server running the Domain Name System (DNS) service. The setup log records events related to the setup of certain applications.
Microsoft has included additional features with logs in their Event Viewer. For example, in Figure 10-3, you can see forwarded events and subscriptions. You can create subscriptions with other systems so that log entries on the other systems are forwarded to a centralized system used for monitoring these events.
For example, if you manage 10 servers hosting Microsoft SQL Server databases, you can forward relevant events to an 11th server to monitor all of these servers. The original servers will still hold the original logs, while the monitoring server hosts the logs in a remote location. Even if an attacker modifies the logs on one of the servers after an attack, the entries will still be recorded on the remote server. The Forwarded Events log holds log entries from event log subscriptions.
*Nix Logs
UNIX derivatives (such as Linux) are often referred to as *nix, and these systems have their own types of logs. The log file locations sometimes vary from one version to another, but there are some similarities.
System and accounting log files are usually in one of the following directories: /var/log,/var/adm, and/usr/adm.
Some of the common log files and their contents include the following:
• syslog Many security processes and other utilities write to syslog. It’s often a good place to view overall system activity.
• sulog This log records all attempts to use the su command. The su command (sometimes called the super user command) grants the user elevated privileges and can be misused.
• auth This log records authentication events on a secure shell (SSH) server. You can use it to determine whether a system intrusion has occurred. For example, a brute force attempt to log in to the system will show multiple failed SSH login attempts, usually from multiple usernames.
• maillog Inbound and outbound mail activity is recorded here.
Proxy Server Logs
Most proxy servers can log all activity through the proxy server. This allows an organization to determine what sites users visit, how often they spend on the site, and all attempts to go to unauthorized sites.
Chapter 4 presented proxy servers. Recall that an organization can use a proxy server to retrieve all web pages from the Internet on behalf of internal clients. The proxy server uses Network Address Translation (NAT) to translate private addresses from internal clients to public addresses for websites on the Internet. Web pages are cached so that repeat requests for the same pages don’t need to be repeated, conserving Internet bandwidth usage, and a proxy server can block access to sites based on a list of sites deemed unacceptable or acceptable.
As mentioned earlier in this chapter, simply the existence of proxy server logs acts as a deterrent. When a user visits an unauthorized site, some organizations display a warning similar to that shown in Figure 10-4.
Figure 10-4 Proxy server warning
EXAM TIP Some logs such as proxy server logs can serve as a deterrent to unacceptable or undesirable behavior. Although this isn’t a good deterrent to stop criminals, it can help to deter many users from engaging in unsafe computing practices.
When users see their activity is being logged, they may be less inclined to try deliberately to circumvent the policy. Of course, it’s possible that a user has a legitimate need to access specific websites, so most organizations include a process that users can use to request exceptions for these types of needs.
Firewall Logs
Most firewalls include the ability to log all activity that is either passed through a firewall, blocked at a firewall, or both. These logs can be very useful when trying to reconstruct the events from an attack on an internal system. For example, after discovering an attack on an internal system, you can use the firewall logs at the edge of your network to determine whether the attack came from an external attacker on the Internet or from an internal source.
Firewall logs are commonly used by intrusion detection systems (IDSs) to detect attacks such as port scans or TCP flood attacks. The IDS regularly monitors the firewall logs and when an attack occurs, it can log and report the event, and active IDS systems can also take action to block the event. For example, it’s possible for the IDS to modify the configuration of the firewall to block the attack as it is in progress.
Additionally, firewall logs sometimes provide details on botnet activity. If you suspect that one or more of your internal systems has become a zombie within a botnet, you can check the host-based firewall logs of the system and the network-based firewall logs for suspicious activity. For example, if 20 or so of your systems are regularly connecting with a system with an IP address from another country and you don’t recognize that address, it could be an indication of botnet-related activity.
The Review of Logs
One of the most important steps of auditing is the review of audit logs. In some situations, administrators get overwhelmed with day-to-day activities and skip this step, but at the very least logs should be archived so that they can be reviewed later if necessary.
Reviewers should look for any types of anomalies in the logs. For example, a long string of failed attempts to log on to the administrator account could be followed with a successful event. In this situation, someone may have guessed the password for the administrator account.
Admittedly, reviewing logs for anomalies isn’t easy to do. If you’re reviewing thousands of log entries, and one or two entries occur that aren’t normally there, it’s difficult to pick up. However, many automated systems are available that can look for and issue alerts for specific events.
At the very least, logs should be archived on a regular basis. For example, Figure 10-5 shows how you can right-click over any log in Microsoft’s Event Viewer to save the contents of a log. Logs saved in this manner can easily be opened in Event Viewer by selecting Open Saved Log and browsing to the location.
When you archive logs like this, you can review them later. In other words, even if you don’t notice an incident until much later, you can still re-create the events from the archived logs.
Logs Stored on Remote Systems
Chapter 8 mentioned that any logs stored on a local system (rather than a remote system) can be modified by an attacker and should be viewed with suspicion after an attack. However, if you are able to store the logs on remote systems, it is much less likely that an attacker will be able to modify the logs. In other words, by storing logs on remote systems, you can help retain their integrity.
Audit Log Management
In addition to storing logs on remote systems to maintain their integrity, you can take several other steps to improve the security related to logs. A primary step is to protect the logs with permissions.
Access to logs should be restricted to users (such as administrators) who have a need to view or maintain the logs. If anyone has the ability to clear the logs, a user may be able to erase a log that has recorded the user activity.
TIP Most systems include the ability to detect when a log has been cleared. For example, in Windows systems, the first log entry in a new log records details on when the previous log was cleared. If an organization normally does this every Friday, but the first entry shows the log was cleared on a different day, it indicates suspicious activity that deserves further investigation.
Many organizations mandate the retention of logs for a specific period such as three years or longer. This allows an investigator to go back in time to reconstruct events even if several months or even several years have passed. If logs must be retained, they need to be archived periodically. In smaller organizations, an administrator must do this manually, but in larger organizations, the process can be automated.