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-
|
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 (localO) |
|
17 |
Local use 1 (local 1) |
|
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.
|
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.
Continue reading here: Figure 121 Delivery of Syslog Messages Across the Network
Was this article helpful?