Firewalls and Logging
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]
