Firewalls andLogging
The information provided through the use of logging is arguably the most important tool
that a firewall administrator has available. Through the use of logging, administrators
gain tremendous insight as to the general health and status of their firewalls. I frequently
equate the information gained from logging to being similar to how parents know what is
going on with their children. Parents spend so much time with their kids that they just
know when things are not right, and that allows them to intervene where necessary.
Logging provides that kind of insight into the firewall. In fact, logging is really the only
method most firewalls can use to inform an administrator what is going on. By
collectingand, most important, by reviewingthe firewall logs, an administrator will
rapidly learn the normal and abnormal behavior for the firewall, making it much easier to
determine when and how to intervene where necessary to correct the situation.
Generally speaking, there are two methods of logging:
• Syslog logging
• Proprietary logging
The Syslog Protocol
The syslog protocol is the de facto standard method of providing event notification
messages across the network. Syslog is defined by RFC 3164 and uses UDP as the
default transport mechanism (by default and typically over UDP port 514). By using
UDP, syslog gains the advantage of being a low-overhead connectionless delivery
method (thus requiring less resources on the systems doing the logging), but that also
results in syslog being an inherently unreliable delivery method. Although not common,
this can result in messages being lost. To address this deficiency, many devices support
using syslog over TCP to provide for reliable data delivery. This process is defined in
RFC 3195.
Syslog messages use what is known as a logging facility and severity level to determine
where the message should be delivered and the importance of the message. The syslog
protocol defines 24 logging facilities, as shown in Table 12-1
.
Table 12-1. Syslog Facilities
Logging Facility Code Logging Facility Description
0 Kernel messages
1 User-level messages
2 Mail systems
3 System daemons
4 Security authorization messages
5 Messages generated internally by syslog daemon
6 Line printer systems
7 Network news subsystem
8 UNIX-to-UNIX Copy (UUCP) subsystem
9 Clock daemon
10 Security/authorization messages
11 FTP daemon
12 Network Time Protocol (NTP) subsystem
13 Log audit
14 Log alert
15 Clock daemon
16 Local use 0 (local0)
17 Local use 1 (local1)
18 Local use 2 (local2)
19 Local use 3 (local3)
20 Local use 4 (local4)
21 Local use 5 (local5)
22 Local use 6 (local6)
23 Local use 7 (local7)
The easiest way to think of the facility level is to think of each facility as a different pipe,
allowing the syslog server to separate and distinguish messages that belong to different
systems. The syslog server can then use this information to perform certain actions on
messages from one facility while performing completely different actions on messages
from other facilities, such as logging messages from each facility into unique files.
Although there are 24 facilities, most firewalls use one of the 8 local-use facilities to
define where the message originated from and is destined to. For example, the Cisco
Secure PIX Firewall defaults to Local4 as the logging facility.
The severity level is used to identify messages of different degrees of importance by
grouping them into one of eight categories. Table 12-2
lists the different message severity
levels.
Table 12-2. Syslog Message Severity Levels
Numeric Code Level System Condition
0 Emergency System is unusable.
1 Alert Action must be taken immediately.
2 Critical Critical conditions.
3 Error Error conditions.
4 Warning Warning conditions.
5 Notice Normal but significant conditions.
6 Informational Informational messages.
7 Debug Debug-level messages.
The message severity is listed from highest to lowest importance, with Emergency
messages being the highest importance and Debug messages being the lowest
importance. As a general rule, it is a good idea when first implementing syslog to log
only Information-level messages and above, and then restrict the logging even more as
you fine-tune the messages that are important to you. For example, as a general rule,
Cisco recommends that after the firewall is operational the logging severity level be set to
either Warning or Error. The reason for this is that the lower the importance, the more
potential messages that will be generated, which can put unnecessary stress and have a
negative impact on the firewall performance. The flip side, of course, is that if you are
not logging at a severity level that a given event is triggered under (for example, if you
have set your logging to Warning but a Notice event occurs), that event will not be
logged. You must determine for your environment the appropriate logging severity level.
As shown in Figure 12-1
, using syslog requires the implementation of a syslog client on
the firewall and a syslog server somewhere on the network.
Figure 12-1. Delivery of Syslog Messages Across the Network
The syslog client is then configured to deliver syslog messages to the syslog server. For
example, you can configure a Cisco Secure PIX Firewall to use syslog by running the
following basic commands.
For Cisco Secure PIX Firewalls running versions of the PIX OS other than 7.0, the
commands are as follows:
logging on
logging trap information
logging host inside ip-address
For Cisco Secure PIX Firewalls running version 7.0 or later, you need to run the
following commands from the configuration mode:
logging enable
logging trap information
logging host inside ip-address
In addition, I recommend that you log time stamps by running the following command
for all versions of PIX OS 6.3 and greater (this only applies to log messages sent to the
syslog server):
firewall(config)# logging timestamp
If you require the firewall to log using a different facility (for example, from the default
Cisco PIX logging facility of 20 or local4), you can run the following command to
change the logging facility, in this case changing it to Local1 (logging facility code 17, as
displayed in Table 12-1
):
firewall(config)# logging facility 17
Configuring the syslog server to receive the syslog message depends largely on the
syslog server software that you decide to run. Virtually all versions of UNIX and Linux
ship with a built-in syslog server. In addition, a number of freeware as well as
commercial syslog server products are available on the market, including the following:
• Kiwi Syslog Daemon This is a popular and relatively inexpensive syslog server for
Windows-based systems that can be obtained at http://www.kiwisyslog.com
and is
shown in Figure 2-2
.
• UNIX syslogd Most UNIX and Linux distributions include the syslogd daemon.
Refer to your software manufacturer for additional information.
• CiscoWorks VPN/Security Management Solution (VMS) CiscoWorks VMS is a
software bundle that includes numerous tools and utilities, including a syslog
server for managing and monitoring all aspects of Cisco security devices.
Figure 12-2. Kiwi Syslog Daemon
[View full size image]
All of these products do a good job at monitoring small- to medium-size environments. If
you have an enterprise or large network with a lot of firewalls that generate a large
number of syslog messages, however, consider implementing more specialized security
incident management (SIM) and log management applications, such as the following:
• NetIQ Security Manager Security Manager is a comprehensive SIM solution that
provides real-time security log consolidation, analysis, and reporting of not only
syslog but virtually every other logging technology currently in use. Its
comprehensiveness allows for the collection of data not only from your firewalls
but from your host servers and applications, enabling you to correlate events
across the enterprise regardless of what device originally generated the event. This
information can then be used for performing forensic analysis and advanced
correlation and reporting on the data, helping to identify and eliminate threats and
security incidents while ensuring compliance with federal and industry rules and
regulations (such as Sarbanes-Oxley and the Health Insurance Portability and
Accountability Act). The number of events and the amount of data that Security
Manager can handle far exceed the capabilities of any of the previously mentioned
syslog server products.
• Cisco Security Monitoring, Analysis and Response System (CS-MARS) CS-
MARS appliances provide similar functionality as NetIQ Security Manager,
enabling you to perform advanced monitoring, analysis, and threat mitigation and
response on not only Cisco-based devices but on a wide range of host systems and
applications. This information can be consolidated and reported on, ensuring
compliance with federal and industry rules and regulations.
Syslog Security Deficiencies
When you implement syslog, you need to be aware of a couple of significant security
deficiencies with regard to how syslog data is delivered across the network. First, by
default, syslog uses UDP as the transport mechanism, which makes it easy to spoof
syslog messages. This could allow attackers to generate bogus log entries in an attempt to
masquerade what they are really doing. The use of UDP also means that there is no way
to ensure the successful delivery of syslog message.
To address this issue, some firewalls implement syslog over TCP, which does not
necessarily prevent spoofing but does make it a quite a bit more difficult to pull off.
Using syslog over TCP also provides for guaranteed delivery of all syslog messages,
albeit generally at a performance impact on the firewall. The following is a sample of
enabling syslog over TCP on all versions of the Cisco Secure PIX Firewall:
firewall(config)# logging host inside 192.168.1.110 tcp/1470
In this case, syslog has been configured to use TCP port 1470 (which is the default TCP
port that Cisco uses) to communicate with the syslog server located at IP address
192.168.1.110. Keep in mind that your syslog server will also need to be configured to
accept syslog messages over TCP. Refer to your syslog server documentation for
instructions on how to do this.
Caution
When you configure the PIX Firewall to use TCP as the syslog delivery mechanism and
the PIX Firewall cannot for some reason communicate with the syslog server (for
example, the syslog server is down), by default the firewall will stop delivering all data
(not just all syslog data, but all data effectively causing the firewall to fail closed). With
PIX OS versions 7.0 and above, you can prevent the firewall from stopping delivering
data by running the command logging permit-hostdown from the global configuration
mode. Unless you require TCP, I recommend not implementing it.
Another security deficiency of syslog is the lack of any method of performing
authentication of the message sender, the lack of any method of providing message
integrity, and the inability to ensure the privacy of the data through the use of encryption.
N
o native methods within syslog address any of this. Instead, if you require the secure
transmission of syslog data, encapsulate the data using a protocol such as IPsec. For more
information about encapsulating syslog traffic in IPsec, see Chapter 10
of Hardening
N
etwork Infrastructure (Osborne/McGraw-Hill).
Proprietary Logging Methods
Proprietary logging is a bit of a misnomer because many firewalls that do not implement
syslog use a standard logging methodology developed by Check Point known as Open
Platform for Security - Logging Export API (OPSEC LEA). Fundamentally, OPSEC
LEA is similar to syslog in that you will need a logging server to retrieve the log
information using OPSEC LEA procedure call.
Other firewalls, such as Microsoft ISA Server 2004, use largely proprietary (or rather
non-syslog-based) logging methods to log events to a database, typically a Microsoft
Data Engine (MSDE) or Structure Query Language (SQL) database. One of the
advantages of this kind of logging system is the ability to then be able to build and issue
custom queries against the data in the database, providing tremendous functionality and
flexibility for building reports. By default, the Microsoft ISA Server 2004 logging data is
accessed via the ISA Server Management Console, as shown in Figure 12-3
.
Figure 12-3. Microsoft ISA Server Log Data
[View full size image]
Why Logging Is Important
It is easy to say that you should log events from your firewalls because doing so provides
insight as to the status of your firewall, but there are a number of specific and tangible
benefits to logging:
• Improves network administration, troubleshooting, and debugging
• Establishes a baseline
• Helps to determine the health of the system
• Provides intrusion detection and incident containment
• Facilitates performing forensic analysis
Improved Network Administration, Troubleshooting, and Debugging
If there is one certainty in firewall administration, it is that sooner or later you will need
to determine why traffic that should be permitted by the firewall is not being permitted.
There are literally dozens of reasons why the firewall may not be allowing the traffic, and
the easiest method of determining which reason is the cause is to put the firewall into a
debugging mode and then observe the logged data to identify the error or reason why the
firewall is not allowing the traffic to pass. Be aware that debug logging can negatively
affect firewall performance.
In addition, logging events from the firewall also reduces the time required to identify,
troubleshoot, and isolate problems with the firewall. This frees the firewall administrator
up to perform other administration tasks. In fact, one of the first troubleshooting steps
when working with firewalls is to check the firewall logs to determine whether they can
provide any insight on the current issue.
Establishing a Baseline
The only effective method of determining what is normal and secure behavior for a
firewall is to monitor the firewall events and identify patterns of activity. Doing so will
p
rovide a baseline that makes it much easier to identify when situations are occurring that
are outside of the scope of normal operations and functionality. For example, it is quite
routine and normal for a firewall to block all sorts of traffic. By monitoring the firewall
logs, you can develop a baseline of the kinds of traffic that are typically denied. Doing so
makes it much easier to notice exceptions to the baseline, which in turn makes it easier to
identify situations and circumstances that warrant additional investigation.
Determining the Health of the System
In conjunction with establishing a baseline, your firewall logs can also be used to
determine what the health of the system is. By comparing the current logs to the known
baseline, it is much easier to identify conditions that may result in negative performance.
Doing so enables you to solve the issues that may be leading to the negative impact in a
much more proactive fashion.
Intrusion Detection and Incident Containment
One of the most important reasons for monitoring your firewall logs is that the logs can
alert you to potential security compromises and security incidents. I am reminded of a
news story I read about a company that discovered their proprietary information had been
compromised when they found their internal documentation when performing a search of
the Internet. When a legal investigation was launched, it was discovered that the firewall
logs contained information relating to the security breach. Because no one was routinely
monitoring the logs, however, this information went undetected. Had someone been
monitoring the logs, the incident might have been preventable.
Performing Forensic Analysis
The odds are that sooner or later you will have to deal with a security incident in your
organization. The simple fact of the matter is that it is impossible to prevent every
security incident, all the time. When the security incident occurs, one of the most
important questions that will be asked is this: what happened? By collecting and
archiving your firewall logs, you greatly increase your ability to determine what occurred
so that you can begin the process of recovering from the incident. In addition, this
information can be critical evidence in the event that legal action is necessary. To ensure
the legal admissibility of your firewall logs, it is critical that your logging system provide
a means of demonstrating that the logs have been unaltered and the data contained in the
logs is accurate and adheres to the rules of chain of custody (for more information about
the chain of custody, see http://www.cert.org/security-improvement/practices/p048.html
).
Many enterprise logging products provide this functionality as a standard function of
their product. If your product does not do this, you can implement third-party solutions
such as FSUM (http://www.slavasoft.com/fsum/
) to provide file integrity checking and to
ensure that the logs have not been altered (especially if the logs are written to a write
once, read many [WORM] drive or similar media). Always review all data evidence
policies with your organization's legal department to ensure that the process you are
following will be admissible in court.
.
following basic commands.
For Cisco Secure PIX Firewalls running versions of the PIX OS other than 7.0, the
commands are as follows:
logging on
logging trap. federal and industry rules and
regulations (such as Sarbanes-Oxley and the Health Insurance Portability and
Accountability Act). The number of events and