Logging and Log-Analysis Tools

Logging and Log-Analysis Tools Most firewalls can log events related to traffic that has been permitted or denied.. Most firewalls use one of two types of logging methods: • Syslog Impl

Logging and Log-Analysis Tools

Most firewalls can log events related to traffic that has been permitted or denied

Unfortunately, the sheer volume of data from even a moderately sized environment can quickly become unmanageable Most firewalls use one of two types of logging methods:

• Syslog Implemented by most firewalls and uses a relatively simple UDP-based (although the Cisco Secure PIX Firewall also supports TCP) client/server logging method

• Open Platform for Security Log Export Application Programming Interface

(OPSEC LEA API) Implemented by Check Point for Firewall-1, OPSEC LEA is

an API-based logging format, similar in function to syslog

Syslog requires a server and a client component The client typically runs on the firewall itself; the server is installed on a Windows, Linux, or UNIX host Syslog server

functionality on Linux and UNIX is built in to the operating system For Windows hosts, however, you must install a third-party syslog server A popular Windows-based syslog server is the Kiwi Syslog Daemon available at http://www.kiwisyslog.com/ Kiwi Syslog allows not only for the logging of events from the firewall but also provides advanced functionality such as implementing hashing on the logs for chain of custody and legal reasons, event filtering, and event notification via e-mail and pager for specified events Syslog uses a combination of facilities and severities to identify the source and type of message that is being generated Although there are 24 total facilities, most firewalls are configured to use facilities local0 to local7 Message severity consists of the following severity levels:

• Emergency (0) System is unusable

• Alert (1) Action must be taken immediately

• Critical (2) Critical conditions

• Error (3) Error conditions

• Warning (4) Warning conditions

• Notice (5) Normal but significant conditions

• Informational (6) Informational messages

• Debug (7) Debug-level messages

In most cases, you should log debug-level severity messages only for the purposes of troubleshooting A good default setting is to log all messages between Emergency and Informational level and then reduce the information logged accordingly after you have

established what information you can obtain from more restrictive logging levels (that is, Notice or Warning)

In the case of the Cisco Secure PIX Firewall, configuring the firewall to log to a syslog server is a relatively trivial task Example A-8 shows a sample of the commands to be executed

Example A-8 Configuring a Cisco Secure PIX Firewall to Use Syslog

firewall(config)# logging on

firewall(config)# logging host inside 192.168.1.101

firewall(config)# logging trap informational

firewall(config)# logging timestamp

A valuable component of logging events is the ability to perform log analysis Whereas most syslog servers enable you to log events, few enable you to perform event correlation

or event analysis In addition, it quickly becomes an insurmountable task for a human being to review the logs in a timely fashion to identify security events or negative trends Therefore, it is typically necessary to implement a complex scripting environment to parse and correlate the logs that are collected or to use third-party log-analysis tools such

as Cisco Security Monitoring, Analysis, and Response System (CS-MARS), Net IQ Security Manager, LogLogic, Network Intelligence, and SenSage These tools all provide for the archival, parsing, and reporting of huge amounts of data, shifting the burden from the security staff and firewall admins to an automated and intelligent system of review and notification