17.3 Sifting Through Logged Data

Now that the logging information has been secured, centralized, and sorted into separate files, the next step is to determine how to isolate important information. A trap that some administrators fall into is relying too heavily on monitoring information to determine when there is a problem and using logging data only after an incident has occurred. Monitoring information is important, but it doesn't always tell when there is a problem. Logged data can help bring to light emerging patterns on the network, which indicate there may be a potential security breach.

As has already been mentioned, the problem is that so much logging data is generated by network devices that relying on a human to pick out patterns may be difficult. Fortunately, there are several programs ”both open source and commercial ”available that aide in the monitoring of log files.

17.3.1 LogSentry

One of the most common tools used to monitor log files is Psionic Technologies LogSentry. Like syslog itself, the strength of LogSentry lies in the fact that it is extremely customizable and can be configured to match the needs of most organizations.

LogSenty runs as a cron job on a Unix syslog server (LogSentry is not designed to work on Windows servers). Every hour , or more frequently if desired, it searches through the log files on the server looking for possible attacks. LogSentry will determine if there is a problem in one of two ways: by the severity of the log entry and by searching for certain patterns that are indicative of attacks.

If suspicious activity is identified then notification is sent to the address listed in the configuration file. The default contact is root; however, that can be changed. In fact most settings can be changed in the LogSentry configuration file. By default this file is called logcheck.sh and is located, after installation, in the /usr/local/etc directory.

In the configuration file the address to which alerts should be addressed can be changed. The files that should be searched can be changed, and the types of alerts that should cause alarm can be changed. This gives administrators a great deal of control over what alerts are generated, and can be a useful tool for fine-tuning the alert process so fewer false alarms are generated.

NOTE

As with monitoring, getting the syslog checking process down takes time. Initially the administrative staff will undoubtedly be flooded with alerts, but as the checking process is refined, the alerts should begin to more accurately reflect the state of the network.

In addition to the information within the check.sh file, there are four other files that aid in the log file checking process:

1. HACKING_FILE

2. VIOLATIONS_FILE

3. VIOLATIONS_IGNORE_FILE

4. IGNORE_FILE

The HACKING_FILE is a plain text file that contains known words or phrases often associated with attacks. The words and phrases in this file should generate very few false positives, and are usually a sign of an attack, or potential attack. LogSentry includes a default HACKING_FILE, logcheck.hacking, which comes with the following entries:

 "wiz"  "WIZ"  "debug"  "DEBUG"  ATTACK  nested  VRFY bbs  VRFY decode  VRFY uudecode  VRFY lp  VRFY demo  VRFY guest  VRFY root  VRFY uucp  VRFY oracle  VRFY sybase  VRFY games  vrfy bbs  vrfy decode  vrfy uudecode  vrfy lp  vrfy demo  vrfy guest  vrfy root  vrfy uucp  vrfy oracle  vrfy sybase  vrfy games  expn decode  expn uudecode  expn wheel  expn root  EXPN decode  EXPN uudecode  EXPN wheel  EXPN root  LOGIN root REFUSED  rlogind.*: Connection from .* on illegal port  rshd.*: Connection from .* on illegal port  sendmail.*: user .* attempted to run daemon  uucico.*: refused connect from .*  tftpd.*: refused connect from .*  login.*: .*LOGIN FAILURE.* FROM .*root  login.*: .*LOGIN FAILURE.* FROM .*guest  login.*: .*LOGIN FAILURE.* FROM .*bin  login.*: .*LOGIN FAILURE.* FROM .*uucp  login.*: .*LOGIN FAILURE.* FROM .*adm  login.*: .*LOGIN FAILURE.* FROM .*bbs  login.*: .*LOGIN FAILURE.* FROM .*games  login.*: .*LOGIN FAILURE.* FROM .*sync  login.*: .*LOGIN FAILURE.* FROM .*oracle  login.*: .*LOGIN FAILURE.* FROM .*sybase  kernel: Oversized packet received from  attackalert 

As new attacks are recorded within a network, or on any of the security sites, pattern matches can be added to this file.

The VIOLATIONS_FILE consists of words or phrases, similar to the HACKING_FILE, that indicate someone may be attempting to violate the network security policies. These words or phrases can be things like an attempted root login, restarting a network device, someone attempting to use the superuser ( su ) command, and more. A sample file is also included, as a way to help administrators develop their own file.

The VIOLATIONS_IGNORE_FILE is used for log messages that contain words that are in the VIOLATIONS_FILE, but can be ignored in some situations. These are usually more complete sentences, and they override the messages in the VIOLATIONS_FILE. An example of this might be a case where an administrator does not necessarily care about denied messages generated by BIND. The keyword denied is included in the VIOLATIONS_FILE, but an entry could be added in the VIOLATIONS_IGNORE_FILE similar to this:

 named*: client *: update denied 

NOTE

The asterisks indicate a wildcard in this entry. Use wildcards judiciously in the VIOLATIONS_IGNORE_FILE. If they are too liberally applied, they can result in a potential security problem slipping through.

The IGNORE_FILE consists of everyday log messages, which are expected and should not be treated as security violations. LogSentry includes a log list of log file messages: cron, FTP, Sendmail, and NTP, which can be ignored in the reporting process and would simply create more information for an administrative staff to sort through. Clearing these entries out makes it easier to determine which messages are possible security threats, and which are not.

Because LogSentry relies on mail to deliver messages, it can be used in conjunction with a ticketing system, such as Remedy. It also means that administrators should hardly ever need to access the syslog server directly. Alert messages will be sent to a remote mailbox or a ticketing system and processed from there.

17.3.2 IPSentry

IPSentry is a Windows-based monitoring application. While its primary purpose is to perform ICMP, SNMP, and other types of remote monitoring services, it also has a built-in syslog server that can be used to receive remote messages from other network devices.

There are two ways to view the monitored data created by IPSentry. The first, and most common, method is through a console located directly on the server, as shown in Figure 17.4. The console runs in the background on a Windows server and shows monitoring information, as well as syslog messages, as they appear. The problem with this method is that it is inherently insecure . Having to allow continual access directly to the monitoring server can open potential security holes, leaving the monitoring server vulnerable.

Figure 17.4. The IPSentry monitoring screen. It can be used to monitor on several different ports, as well as to monitor syslog entries.

The second method, which is a way to increase the level of security, is to opt to use the web interface to view logged data, so no direct access to the server is required. This is more secure, but because IPSentry does not allow for HTTPS access to the remote server, it could create additional security problems. To maximize security, HTTP connections should be made over the management network.

Syslog configuration within IPSentry is relatively simple. Select a device that is currently being monitored, and choose the Syslog tab from the options. A screen similar to Figure 17.5 will be presented; simply fill in the appropriate fields.

Figure 17.5. The IPSentry syslog screen

IPSentry allows an administrator to fill in the facility as well as the priority for each device being monitored. Unlike LogSentry, IPSentry relies strictly on the priority information to determine whether or not an alert should be generated. If a problem is generated through syslog, a notice will be sent to the monitoring screen, which forwards it to the web interface.

There are other tools available for both Unix and Windows systems that can be used to monitor syslog events. Keep in mind, when choosing a program, the goal of a syslog monitoring system is to communicate information to the appropriate administrators in as secure a method as possible.

The more secure the syslog server is, and the more secure the methods to communicate information are, the more reliable the information from the server will be. In the event of a security breach, secure logs are going to be important.

NOTE

Another commonly used application to monitor syslog files is SWATCH, short for the Simple Watcher. SWATCH, written by Todd Atkins and available for download from www.oit.ucsb.edu/~eta/swatch/ , works in a manner similar to LogSentry, except log anomalies are reported as soon as they happen.