17.2 Syslog Servers

   

The syslog Protocol was originally designed for the BSD operating system that has since been incorporated into other operating systems. The syslog specification is outlined in RFC 3164. The syslog protocol has two uses: to collect logging information from applications on a server and to collect logging information from other devices on the network.

A syslog server is an excellent tool for collecting information from routers and switches. Because these devices do not have a lot of storage space, sending logging information to another device gives network administrators a chance to maintain a historical perspective on network events, and can help track changes in the network.

A syslog server also helps to increase network security. If devices are configured to send logging information to another server, it is more difficult for an attacker to modify those log files to cover a security breach. Of course, this is assuming that proper security precautions have been taken to secure the logging server.

Syslog has grown in popularity because it has a relatively simple format that is adaptable to any network device, and it is fairly liberal in the type of data it will accept. All syslog messages should be sent over UDP Port 514, and must be less than 1,024 bytes. Syslog also has extensive configuration options, allowing the creation of different files for different logging purposes. Syslog can even be configured so that some messages are sent to a remote logging server, while others are stored on the local server.

A syslog message is divided into three parts: PRI, HEADER, and MSG. PRI indicates the priority of the message, the HEADER contains the time and the hostname of the message, and the MSG is the actual message being transmitted by the remote host. Each of the fields must be separated from the other fields, so they can be easily parsed by a human reviewing the log file, or an application that is scanning the log file. None of the three parts are mandatory.

A typical syslog message will look like this:

 May 28 19:29:06 test sshd(pam_unix)[3257]: session opened \ for user  root by (uid=0) 

Or, a message from a remote device:

 May 28 19:49:32 192.168.0.101 14: 00:13:38: \  %SYS-5-CONFIG_I: Configured from console by allan on console 

In these examples a priority code is not used. If the priority code were used, it would be enclosed within "< >" at the beginning of the message, prior to the date. The priority code is the combination of two numbers , the facility that is generating the message, and the severity. Each facility is assigned a number, as shown in Table 17.2. That number is multiplied by eight and the numerical value of the severity, outlined in Table 17.3, is added to it.

Table 17.2. Numerical Value of Facility Messages

Numerical Value

Facility

Kernel

1

User

2

Mail

3

System

4

Security, Authorization, Audit

5

Syslog Daemon

6

Printer

7

News

8

UUCP

9

Clock

10

Security, Authorization, Audit

11

FTP

12

NTP

13

Log Audit

14

Log Alert

15

Cron

16 “23

Local Use 0 “7

There is some duplication because different operating systems assign different facility values to some functions.

Table 17.3. Numerical Value of Severity Messages

Numerical Value

Severity

Emergency

1

Alert

2

Critical

3

Error

4

Warning

5

Notice

6

Information

7

Debug

Based on the two charts , a message generated by the kernel with a severity of Emergency would have a priority of <0> . A message generated by the FTP daemon with a severity label of Critical would have a priority of <90> . The priority field should have no more than 5 characters in it (191 would be the maximum numerical value) including the "< >."

The HEADER field of a syslog packet will have the date and the time that the message is logged; in other words, it contains the date and time of the local system, not the system sending the message. The format of the HEADER field is very specific, in that it should be sent as:

 Mmm dd hh:mm:ss hostname 

Mmm represents the three-letter abbreviated form of the month, with the first letter capitalized (e.g., Jan, Mar, Sep, etc.). The date is separated by a single space and is represented by a two-digit number. In cases where the date is a single-digit number, an additional space should be added between the month and date columns . A zero should not be used as filler for single-digit numbers. The hour, minute, and second field are separated from the date by a space, and listed in 24- hour military time.

The hostname can be the canonical hostname of the remote device ”without the associated domain name , the IPv4 dotted decimal address, or the IPv6 address. A space should follow the hostname field as well.

The message field contains the bulk of the information in which an administrator will be interested. It has the name of the application that created the message as well as the message itself. The message contains two fields, the TAG field, a 32-character or less field that has the application name, and the CONTENT field. The content field contains the actual message. There is no limit to the size of the field (other than the constraints of the 1,024 byte packet), and the message can be in any format.

Although there is no limit on the type of information that can be sent in the CONTENT field, most vendors standardize the format of the messages, making it easier to monitor the log files. This information should be published on each vendor's website or in its manuals. It is important to understand how each vendor writes its syslog messages so it will be easier to pull the necessary information from a logging server.

17.2.1 Syslog Configuration

There are a lot of different options when using syslog to create a logging server, making it sometimes difficult to decide how a server should be configured. Many administrators start by logging everything, from all network devices. After spending a week doing nothing but reviewing information on the logging server, administrators usually change this policy.

The goal of any centralized logging system is to gather the information needed, without overloading administrators with information. The easiest way to do this is to use the syslog configuration file to sort the logged information into separate log files.

The syslog configuration file is usually syslog.conf, located in the /etc directory on most Unix servers. The format of the syslog configuration file is relatively simple:

 facility.severityhostname or file 

Because syslog configuration allows an administrator to send different messages to different locations, it is easier for an administrator to isolate messages that may be critical to system security. The better job administrators do of determining how messages will be logged, the easier it will be to isolate messages and the faster a potential attack will be caught.

As a general rule all devices that use the syslog server should receive all messages that are at a severity level of informational and above. (Of course emergency messages should be sent to all users logged onto the affected system as well.) Debugging messages are only used when there is a system problem and can be activated as needed on the local device. If a network administrator designates the server 10.10.100.130 as the syslog server, then the following entry is all that is needed in the syslog.conf file of the remote servers:

 # If there is an emergency, display it to console  *.emerg *  # Otherwise, everything, including emergency messages,  # but mail messages should go to the Syslog server.  *.info;mail.none  @10.10.100.130 

The syslog server will have a more complex configuration file. In order to make the monitoring process easier on the administrative staff, it is best to divide up the messages. Messages of differing importance can be sent to different files, or even to different servers. A sample syslog server configuration file might look like this:

 # Different Facilities are logged to different files  kern.*   /var/log/kernel  mail.*   /var/log/maillog  local7.*  /var/log/boot  # Emergency messages should be sent to a separate file so  # they can be dealt with immediately  *.emerg/var/log/emergency  # Authentication messages are obviously important, as are  # instances of users using the su command, these should  # be logged to secure files.  auth,authpriv.warn;user.*  /var/log/secure  auth,authpriv.=notice   /var/log/sulog  # Other messages are sent to the system log file  *.info;mail,news,lpr,authpriv,auth.none /var/log/messages 

NOTE

Syslog will not automatically create the log files. If a new entry is added to the syslog configuration file, the file has to be created before information will be logged to it. The file creation is usually accomplished using the touch filename command.


This type of setup is great for network devices that are true to the Unix-based syslog system, but different vendors have their own lists of facilities, and those facilities do not always follow the Unix standard. Tables 17.4 and 17.5 list the Juniper and Cisco, respectively, facility information for log messages.

Network administrators must understand the facility information that is being sent to the syslog server, so the proper files can be generated. Even if a catch-all file, such as /var/log/messages, is used, sorting through that file looking for critical messages is a waste of CPU and manpower. It makes much more sense to isolate important messages from different network devices into easily manageable files.

Table 17.4. Juniper Syslog Facilities

Facility Name

Description

Any

All facilities

Authorizations

Login attempts

Change-log

Configuration changes

Cron

Cron daemon

Daemon

Daemons not specified by other facilities

Interactive commands

Commands issued in a terminal or console

Kernel

Kernel messages

User

Any user process

Table 17.5. Cisco Syslog Facilities

Facility Name

Description

Auth or security

Login attempts

Bootp

Bootp daemon

Daemon

Daemons not specified by other facilities

Named

DNS messages

Gated

Gateway messages

Kern

Kernel messages

Mail

Mail daemon

NTP

Network Time Protocol messages

Local0 “local7

User-defined messages

So, if a network administrator wants to log all bootp messages from Cisco devices into a separate file, a line like this would need to be added:

 # Log all bootp messages to a separate file  bootp.info /var/log/bootp 

The configuration process for different devices is also different than the configuration process for Unix systems. Most routers and switches will allow network administrators to configure syslog entries through the command line interface. However, the manner in which this is accomplished varies from router to router. Juniper routers have a syslog command at the [edit system] hierarchy. Assuming the name of the Juniper router was GW1, and the syslog server was 10.10.100.130, the configuration would look something like this:

 syslog {    host 10.10.100.130 {     * info;     log-prefix  gw1  ;    } 

The asterisk represents all facilities; alternatively, a line could be created for each facility that is to be logged.

The Cisco method, using the IOS command line, is a little different. The syslog configuration information is referred to as "logging" in the global configuration section, as shown in Figure 17.2. As with other syslog configurations, the Cisco logging facility allows network administrators to set the IP address of the syslog server and create different logging rules for different facilities, as well as different types of access (e.g., terminal versus console access).

Figure 17.2. The Cisco logging facility. Cisco's version of syslog

graphics/17fig02.gif

Different hosts can also be specified for different types of logging. Cisco's IOS will also allow administrators to determine from which interface the syslog messages should be generated. This feature is particularly useful for syslog servers that use IPTables or some other firewall facility to limit traffic allowed to the server.

17.2.2 Windows and Syslog

The internal logging facility on Microsoft servers is not compatible with syslog. Generally, administrators either use the Microsoft Windows logging facility to create a centralized logging system, or they use a third-party, Windows-based syslog facility.

Truthfully, trying to manage two, or more, logging systems is a pain, and can create unnecessary confusion. Many administrators in a mixed-network environment are opting to meld them into a single syslog system, even when multiple syslog servers are used. It is still more efficient to manage multiple syslog servers than it is to manage different logging facilities.

A commonly used Microsoft Windows syslog system is Winsyslog, shown in Figure 17.3. Developed by Adiscon, Winsyslog takes standard Microsoft Windows event messages and converts them into syslog format. These messages can then be sent to a remote machine, just like other syslog messages, making log management relatively simple.

Figure 17.3. Winsyslog converts Microsoft Windows error messages into syslog messages

graphics/17fig03.gif

   


The Practice of Network Security. Deployment Strategies for Production Environments
The Practice of Network Security: Deployment Strategies for Production Environments
ISBN: 0130462233
EAN: 2147483647
Year: 2002
Pages: 131
Authors: Allan Liska

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net