Chapter 17. Logging

   

Logging and monitoring are so closely tied together that they often overlap in the minds of network administrators. There is an important distinction that has to be made between these two aspects of network security: Monitoring provides a picture of the present situation. Logging provides historical data. The historical data may only be a few minutes old, but it is still not necessarily a representation of the current network state.

Logging tracks changes in the state of a network device and requests made to the network device. Logs are incredibly useful for tracking down information about attacks. Attackers know this, and a skilled attacker will edit log files to hide the fact he or she has accessed the system. Editing log files is preferred to actually deleting them. Deleted log files are usually an immediate warning to administrators that a problem exists on the server. The longer an attacker can successfully hide the existence of a break-in the more information about the network that can be gathered.

The log structure for most applications is the same. It is based on either the Unix-centric syslog structure or on the Windows Event Logging structure. Most networking devices opt for the Unix syslog structure, because syslog has been designed to allow for remote logging. Because attackers are aware of how the two logging structures work, it is fairly easy to modify log files.

Using syslog as an example, if an attacker were to gain access to a server, there would be a record of that access. The record of the access would be written to a file called messages, generally located in the /var/adm/ or the /var/log/ directory. The messages will look like this:

 May 27 12:09:53 test sshd[1825]: Accepted password for \  root from 192.168.0.2 port 1903  May 27 12:09:53 test sshd(pam_unix)[1825]: session opened \  for user root by (uid=0) 

It is a trivial matter for an attacker to change or erase those lines to mask the fact that someone logged into the server at that time. Any changes to the server, which would normally be logged, can also be deleted as necessary, while still allowing the expected logs to be collected. The Unix logging structure will be discussed in detail in the Syslog section.

Windows NT and 2000-based systems have a similar logging system, called Windows Event Logging. The same type of information is collected, though in a slightly different format. Notifications are parsed into one of three groups: System, Application, and Security. While different types of messages are included in each Event Viewer, the format is the same (Figure 17.1):

Figure 17.1. A system notification in Windows 2000. It contains the date, time, type of event, the user, and the name of the computer on which the event occurred

graphics/17fig01.gif

NOTE

By default Windows NT and 2000 do not log user authentications to the server. This should be changed on all servers to ensure that logins can be properly tracked.


Windows assigns an Event ID to each logged system activity. The Event ID serves as a means to quickly gauge what type of event occurred; it also makes it easier to sort events according to their potential to indicate a security breach. Microsoft has maintained the same Event ID classification between Windows NT, 2000, and XP ”though new events are added with each progressive version of the operating system. To find out the most up-to-date information about an Event ID, and its meaning, consult the Microsoft website. Table 17.1 lists the logon events under Windows NT, 2000, and XP.

Table 17.1. Windows Logon Events

Event ID

Description

528

Successful Logon

529

Logon Failure: Reason: Unknown user name or bad password

530

Logon Failure: Reason: Account logon time restriction violation

531

Logon Failure: Reason: Account currently disabled

532

Logon Failure: Reason: The specified user account has expired

533

Logon Failure: Reason: User not allowed to logon at this computer

534

Logon Failure: Reason: The user has not been granted the requested logon type at this machine

535

Logon Failure: Reason: The specified account's password has expired

536

Logon Failure: Reason: The NetLogon component is not active

537

Logon Failure: Reason: An unexpected error occurred during logon

538

User Logoff

539

Logon Failure: Reason: Account locked out

540

Successful Network Logon

These events are common to Windows NT, 2000, and XP

A standardized logging infrastructure, like those on Unix and Windows servers, makes it easier to maintain a secure network. All applications can write logging data in the same format, to the same log files, and it becomes easier to centrally monitor the logs for all applications on the server. A similar logging infrastructure also makes it easier to centralize the logging infrastructure and to develop third-party applications to assist with the process of watching log files.

Log files are also useful for gathering information about pending attacks. Prior to a break-in attempt an attacker will usually initiate a port scan against the network, looking for vulnerabilities. Because port scans are so commonplace most administrators ignore them. However, repeated port scans from the same address, or netblock, could be an indication that a network is being targeted .

Centralizing application logging to a few directories, or a single server on the network, is necessary because, even within small networks, so much information is generated within the log files that it can be difficult to isolate patterns. It can be difficult to take appropriate proactive steps to stop an attack. As with monitoring, there are many tools on the market that help sift through log files and pull out the important information, but they are not always perfect. Many administrators opt to write their own programs that parse through log files and generate alerts, although these are more customized to individual network needs. They are, again, far from perfect.

There are aspects of logging that are of equal concern to security administrators: protecting the log files and retrieving the necessary information from the log files. If the information collected by various devices on the network cannot be aggregated and examined for patterns or trends, then logging is useless. In addition, if an administrator cannot be sure that logs have not been tampered with, there is no point in keeping log files.

   


The Practice of Network Security. Deployment Strategies for Production Environments
The Practice of Network Security: Deployment Strategies for Production Environments
ISBN: 0130462233
EAN: 2147483647
Year: 2002
Pages: 131
Authors: Allan Liska

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