|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
One of the most neglected area of Unix is handling system events. Daily checks for system messages is crucial for the security and health conditions of a computer system.
System logs contain much "noise" - messages which have no importance - and on the contrary important events, which should not be lost in the load of messages. With current tools it's difficult to select which messages we are interested in.
A message is sent to different destinations based on the assigned facility/priority pair. There are 12+8 (12 real and 8 local) predefined facilities (mail, news, auth etc.), and 8 different priorities (ranging from alert to debug).
BSD syslog protocol is defined in RFC 3164 (rfc3164) - The BSD Syslog Protocol A good summary of RFC can be found in Introduction to Syslog Protocol - MonitorWare
Syslog uses target UDP port 514. RFC recommends that source port also be set to 514.
syslog uses the user datagram protocol (UDP) [1] as its underlying transport layer mechanism. The UDP port that has been assigned to syslog is 514.
It is RECOMMENDED that the source port also be 514 to indicate that the message is from the syslog process of the sender, but there have been cases seen where valid syslog messages have come from a sender with a source port other than 514. If the sender uses a source port other than 514 then it is RECOMMENDED and has been considered to be good form that subsequent messages are from a single
consistent port.
It its pure form it is an outdated, insecure (if used with central logging host, as it actually should be used in any modern enterprise environment) and rather primitive logging mechanism that lucks the flexibility of dynamically extending message classification scheme. A better scheme was proposed in 2004 syslog-1 but tremendous amount of inercia prevent any changes.
The fixed classification scheme with just a dozen of entries is a major problem with the protocol. Messages severity classification also can be improved/simplified (IBM has a better classification on mainframes) but even in present form it is an OK solution.
There are two slightly better, more modern implementation of traditional syslog daemon called syslog-ng and kiwi syslog. Syslog-ng is a better implementation if you wish to integrate Tivoli log preprocessing. It is also portable between different platforms. I do not know why Sun did not replaced the traditional syslog with syslog-ng in Solaris 10 (after all they discarded pretty usable own firewall in favor of IP Filter). It probably should consider this move.
Standard Solaris syslog system consists of the following components:
syslogd
logger
syslog() an application program interface (API) referenced by several standard system utilities and available to anyone writing software in the C programming language, C++, Java and many scripting languages (Perl is one example).
logadm -- System Log Rotation Utility (Solaris 9 and later)
The key file that is influencing syslog behavior is /etc/syslog.conf
file. It contains two colums called the selection and action.
As typical for Sun the file has a dinosaur (pre-70th style) syntax, as it does not permit using spaces as a separator, tabs should be used as a separator between two columns of syslog.conf. Now let's discuss those two columns is some details:
The selector field is a semicolon-separated list of priority specifications in the following format: facility.level; facility.level.
After making any changes to syslog.conf file, you need to ask the daemon to reread the configuration file with kill -HUP command, for example pkill -HUP syslogd. This is an operation that is often forgotten. It might make sense to implement "system configuration" attribute that can automatically send executes a command after closing of the file with such attribute if it was opened for writing (Unix has "command execution string" for scripts forever, for example #!/usr/bin/perl, so it can be used for configuration files). In the absence of such facility that would be a real paradise for absent minded people like me you probably will be better off creating a special script, like visyslog that contains just two command: vi and pkill to ensure that you do not forget this operation; I often do and then face consequences)
The default Solaris syslog configuration (
/etc/syslog.conf) is far from being optimal (any selector in /etc/syslog.conf means "this level and higher", for example mail.crit includes mail.emerg):*.err;kern.notice;auth.notice /dev/sysmsg
*.err;kern.debug;daemon.notice;mail.crit /var/adm/messages
*.alert;kern.err;daemon.err operator
*.alert root
*.emerg *
# if a non-loghost machine chooses to have authentication messages
# sent to the loghost machine, un-comment out the following line:
#auth.notice ifdef(`LOGHOST', /var/log/authlog, @loghost)
mail.debug ifdef(`LOGHOST', /var/log/syslog, @loghost)
#
# non-loghost machines will use the following lines to cause "user"
# log messages to be logged locally.
#ifdef(`LOGHOST', ,
user.err /dev/sysmsg
user.err /var/adm/messages
user.alert root, operator
user.emerg *
)
For one thing, AUTH messages dont get logged to any logfiles. This is important if you want to know when people are trying to break into your system so such messages should be emailed at least to operator (may be operator and root) and written to /var/adm/authlog
*.emerg *
*.kernel.notice;*.alert root,operator
*.err;kern.notice;auth.notice /dev/sysmsg
*.notice /var/adm/messages
auth.notice /var/adm/authlog, /var/log/messages
Each line of the file contains two parts:
A selector that specifies which kinds of messages to log (e.g., all error messages or all debugging messages from the kernel).
An action field that says what should be done with the message (e.g., put it in a file or send the message to a user's terminal).
|
Message selectors have two parts: a facility and a priority. kern.debug, for example, selects all debug messages (the priority) generated by the kernel (the facility). It also selects all priorities that are greater than debug. An asterisk in place of either the facility or the priority indicates "all." (That is, *.debug means all debug messages, while kern.* means all messages generated by the kernel.) You can also use commas to specify multiple facilities. Two or more selectors can be grouped together by using a semicolon. (See the earlier examples.)
The action field specifies one of five actions (some versions of syslog support additional actions, such as logging to a proprietary error management system):
With the following explanation, understanding the typical syslog.conf configuration file shown earlier becomes easy:
This line causes all error messages, all kernel debug messages, and all notice
messages generated by the authorization system to be printed on the system console.
If your system console is a printing terminal, this process will generate a
permanent hardcopy that you can file and use for later reference. (Note that
kern.debug means all messages of priority
debug and above.)
This line causes all notice messages from either the system daemons or the authorization system to be appended to the file /var/log/messages. Note that this is the second line that mentions auth.notice messages. As a result, auth.notice messages will be sent to both the console and the messages file.
This line causes all messages from the line printer system to be appended to the /var/log/lpd-errs file.
This line causes all messages from the authorization system to be sent to the users root and nosmis. Note, however, that if the users are not logged in, the messages will be lost.
This line causes all authorization messages to be sent to the syslog daemon on the computer prep.ai.mit.edu. If you have a cluster of many different machines, you may wish to have them all perform their loggings on a central (and presumably secure) computer.
This line causes all emergency messages to be displayed on every user's terminal.
This line causes all alert messages to be sent to a program called dectalker, which might broadcast the message over a public address system.
This line causes the time to be printed on the system console every 20 minutes. This is useful if you have other information being printed on the console, and you want a running clock on the printout.
|
|||||||
- From release notes for Red Hat Enterprise Linux 5.2
- rsyslog
rsyslogis an enhanced multi-threadedsyslogddaemon that supports the following (among others):
- MySQL
- syslog/tcp
- RFC 3195
- permitted sender lists
- filtering on any message part
- more granular output format control
rsyslogis compatible with the stocksysklogd, and can be used as a replacement in most cases. Its advanced features make it suitable for enterprise-class, encryptedsyslogrelay chains; at the same time, its user-friendly interface is designed to make setup easy for novice users.For more information about
rsyslog, refer to http://www.rsyslog.com/.
newsyslog is a faithful Perl rewrite of the MIT newsyslog utility, with a number of features taken from the FreeBSD and NetBSD variants of newsyslog. It archives log files based on size, date or interval, and can optionally compress archives with gzip or bzip2. Complete documentation is available via "perldoc newsyslog.pl".
About: Rsyslog is an enhanced multi-threaded syslogd. Among other features, it offers support for reliable syslog over TCP and RFC 3195, writing to MySQL databases, fully configurable output formats (including great timestamps), the ability to filter on any part of the syslog message, and on-the-wire message compression. It is designed as a drop-in replacement for stock syslogd and thus is able to work with the same configuration file syntax. Of course, some enhanced features require changing the configuration file, but in general, this should be fairly easy.
Changes: Support for IPv6 has been added and some minor cleanups plus a fix for the Red Hat init script were applied. Currently, IPv6 is implemented for UDP only, TCP will follow shortly. IPv6 support should be considered experimental. It is not recommended that this release be used in production.
This chapter presents an overview of the syslog protocol and shows you how to deploy an end-to-end syslog system. You'll learn about the syslog architecture as well as the issues in deploying syslog servers in Linux and Windows OSs with a focus on their relevance in a Cisco environment.
Solaris systems use the /var directory to store logs and other local files so that the operating system can support other directories being mounted as read only, sometimes from file servers elsewhere on the network. The /var directory is thus often on a partition that is local to the system.
All of the log files described below can be found in subdirectories under /var. There may be other application-specific log files that you will also need to inspect. However, it is beyond the scope of this implementation to describe all of the log files that you might want to inspect for your specific Solaris installation.
Because log files often provide the only indication of an intrusion, intruders often attempt to erase any evidence of their activities by removing or modifying the log files. For this reason, it is very important that your log files be adequately protected to make it as difficult as possible for intruders to change or remove then. See the practice "Managing logging and other data collection mechanisms" for more information on this topic.
My central loghost machine uses a modified version of logcheck.sh that I wrote named (imaginatively) newlogcheck.sh. The modified version calls another script I wrote that sorts the output of the "logtail" by individual hosts into separate portions of the final report. The perl script attempts to avoid duplication of log messages by printing each log message only once, reporting how many times the event was reported.
This approach dramatically reduces the size of your logcheck reports, and sorting it by host makes it easy to read.
Check out a sample newlogcheck report
You need to configure your logcheck settings yourself, read the README that comes with logcheck from psionic.com, then the one included with my scripts. Copy my newlogcheck.sh and sort_logs.pl into your logcheck dir, and run newlogcheck.sh instead of logcheck.sh for reports.
If you're ready to go ahead, get the tarred/gzipped file here.
This paper is not an in depth paper about syslog. It simply gives you an overview and a broader picture about the Syslog Protocol and its architecture. If you are interested in in-depth details about Syslog, I would strongly suggest you to go through RFC: 3164.
What is Syslog?
Syslog is a protocol that allows a machine to send event notification messages across IP networks to event message collectors - also known as Syslog Servers or Syslog Daemons. In other words, a machine or a device can be configured in such a way that it generates a Syslog Message and forwards it to a specific Syslog Daemon (Server).
Syslog messages are based on the User Datagram Protocol (UDP) type of Internet Protocol (IP) communications. Syslog messages are received on UDP port 514. Syslog message text is generally no more than 1024 bytes in length. Since the UDP type of communication is connectionless, the sending or receiving host has no knowledge receipt for retransmission. If a UDP packet gets lost due to congestion on the network or due to resource unavailability, it will simply get lost - no one would know about it!!
What is Syslog Daemon?
A Syslog Daemon or Server is an entity that would listen to the Syslog messages that are sent to it. You cannot configure a Syslog Daemon to ask a specific device to send it Syslog Messages. If a specific device has no ability to generate Syslog Messages, then a Syslog Daemon cannot do anything about it. To make this thing clear, you can consider a Syslog Server or Syslog Daemon as a TV which can only display you the program that is currently running on a specific channel. You cannot ask another station to send a new program on that channel.
Some Background
Syslog Protocol was created for use by Unix Operating Systems. Using Syslog, a
remote Unix host could, in effect, keep track of the general well being of any other Unix host. Any application can generate Syslog Compliant messages to send the information over the network. Since each process, application and operating system was written somewhat independently, there is little uniformity to the content of syslog messages. For this reason, no assumption is made upon the formatting or contents of the messages. The protocol is simply designed to transport these event messages. One of the fundamental design considerations of the syslog protocol was its simplicity. No stringent coordination is required between the transmitters and the receivers. Indeed, the transmission of syslog messages may be started on a device without a receiver being configured, or even actually physically present. Conversely, many devices will most likely be able to receive messages without explicit configuration or definitions. This simplicity has greatly aided the acceptance and deployment of syslog [1]Format of a Syslog Packet
The full format of a Syslog message seen on the wire has three ditinct parts.
1. PRI
2. HEADER
3.MSG.
The total length of the packet cannot exceed 1,024 bytes, and there is no minimum length
1. PRI
The Priority part is a number that is enclosed in angle brackets. This represents both the Facility and Severity of the message. This number is an eight bit number. The first 3 least significant bits represent the Severity of the message (with 3 bits you can represent 8 different Severities) and the other 5 bits represent the Facility of the message. You can use the Facility and the Severity values to apply certain filters on the events in the Syslog Daemon. Note that Syslog Daemon cannot generate thse Priority and Facility values. They are generated by the applications on which the event is generated. Following are the codes for Severity and Facility. Please note that the codes written below are the recommended codes that the applicatoins should generate in the specified situations. You cannot, however, be 100 % sure if it really is the correct code sent by the application. For example: An application can generate a numerical code for severity as 0 (Emergency) when it should have generated 4 (Warning) instead. Syslog Daemon can not do anything about it!! It will simply receive the message as it is.
a) Severity Codes
The Severity code is the severity of the message that has been generated. Following are the codes for Severity:
Numerical Code Severity 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 condition 6 Informational: informational messages 7 Debug: debug-level messages b) Facility Codes
The facility is the application or operating system component that generates a log message.Following are the codes for facility:
Numerical Code Facility 0 kernel messages 1 user-level messages 2 mail system 3 system daemons 4 security/authorization messages 5 messages generated internally by syslogd 6 line printer subsystem 7 network news subsystem 8 UUCP subsystem 9 clock daemon 10 security/authorization messages 11 FTP daemon 12 NTP subsystem 13 log audit 14 log alert 15 clock daemon 16 local use 0 17 local use 1 18 local use 2 19 local use 3 20 local use 4 21 local use 5 22 local use 6 23 local use 7 1.1 Calculating Priority Value
The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a "local use 4" message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165. In the PRI part of a Syslog message, these values would be placed between the angle brackets as <0> and <165> respectively.
2. Header
The HEADER part contains the following things:
a) Timestamp -- The Time stamp is the date and time at which the message was generated. Be warned, that this timestamp is picked up from the system time and if the system time is not correct, you might get a packet with totally incorrect time stamp
b) Hostname or IP address of the device.
3. MSG
The MSG part will fill the remainder of the Syslog packet. This will usually contain some additional information of the process that generated the message, and then the text of the message. The MSG part has two fields:
a) TAG field
b) CONTENT field
The value in the TAG field will be the name of the program or process that generated the message. The CONTENT contains the details of the message.
Some Important Points
- As mentioned above, since Syslog protocol is UDP based, it is unreliable. It does not guarantee you the delivery of the messages. They may either be dropped through network congestion, or they may be maliciously intercepted and discarded.
- As mentioned above, since each process, application and operating system was written somewhat independently, there is little uniformity to the content of syslog messages. For this reason, no assumption is made upon the formatting or contents of the messages. The protocol is simply designed to transport these event messages.
- The receiver of a Syslog packet will not be able to ascertain that the message was indeed sent from the reported sender.
- One possible problem associated with the above mentioned point is of Authentication. A misconfigured machine may send syslog messages to a Syslog Daemon representing itself as another machine. The administrative staff may become confused because the status of the supposed sender of the messages may not be accurately reflected in the received messages.
- Another problem associated with point 2 is that an attacker may start sending fake messages indicating a problem on some machine. This may get the attention of the system administrators who will spend their time investigating the alleged problem. During this time, the attacker may be able to compromise a different machine, or a different process on the same machine.
- The Syslog protocol do not ensure ordered delivery of packets.
- An attacker may record a set of messages that indicate normal activity of a machine. At a later time, that attacker may remove that machine from the network and replay the syslog messages to the Daemon.
Related Software
The MonitorWare line of products [2] can be used as Syslog Daemons for Windows Operating System to collect Syslog Messages from various devices (including Routers, Fire walls etc). They can also act as relaying servers and can forward the data from one Syslog Daemon to another.
References
Last week we discussed syslog, a system for handling status messages and logging and we looked briefly at the format of a syslog message. There's a lot more to the standard, and we encourage you to read the relevant IETF standard, RFC 3164, "The BSD syslog Protocol".The syslog protocol is very useful, but be warned it has its deficiencies: It isn't secure; syslog messages are relatively easy to fake (sending syslog messages greater than the standard maximum of 1,024 bytes has been used in an exploit to hack syslog) and there's no sender validation. Anyway, we will forgo delving any deeper into the bowels of syslog and instead look at syslog products.
RFC 3164 (rfc3164) - The BSD Syslog Protocol
rfc3195 Reliable Delivery for syslog
Supporting documents and discussions:
This chapter presents an overview of the syslog protocol and shows you how to deploy an end-to-end syslog system. You'll learn about the syslog architecture as well as the issues in deploying syslog servers in Linux and Windows OSs with a focus on their relevance in a Cisco environment.
One of the most neglected area of Unix is handling system events. Daily checks for system messages is crucial for the security and health conditions of a computer system.
System logs contain much "noise" - messages which have no importance - and on the contrary important events, which should not be lost in the load of messages. With current tools it's difficult to select which messages we are interested in.
A message is sent to different destinations based on the assigned facility/priority pair. There are 12+8 (12 real and 8 local) predefined facilities (mail, news, auth etc.), and 8 different priorities (ranging from alert to debug).
One problem is that there are facilities which are too general (daemon), and these facilities are used by many programs, even if they do not relate each other. It is difficult to find the interesting bits from the enourmous amount of messages.
A second problem is that there are very few programs which allow setting their "facility code" to log under. It's at best a compile time parameter.
So using facilities as a means of filtering is not the best way. For it to be a good solution would require runtime option for all applications, which specifies the log facility to log under, and the ability to create new facilities in syslogd. Neither of these are available, and the first is neither feasible.
One of the design principles of syslog-ng was to make message filtering much more fine-grained. syslog-ng is able to filter messages based on the contents of messages in addition to the priority/facility pair. This way only the messages we are really interested in get to a specific destination. Another design principle was to make logforwarding between firewalled segments easier: long hostname format, which makes it easy to find the originating and chain of forwarding hosts even if a log message traverses several computers. And last principle was a clean and powerful configuration file format.
This article tries to give you an overview on syslog-ng's internals, for more detailed information see http://www.balabit.hu/products/syslog-ng and select the documentation link.
This paper is intended to assist a data center manager in setting up a centralized syslog server. There are a variety of commercial packages that deal with security and troubleshootp0111/syslog.html">Daemon News Logging Syslog to a Database
I'm working on set of scripts and tools to automate log management, but they are not yet finished. You can always contact me for more information at kodz@slonce.com.
I would like to thank Kamil Andrusz and Maciej Kozak for support.
[1] - stunnel - SSL tunnel - http://www.stunnel.org/
[2] - syslog-ng - Syslog next generation - http://www.balabit.hu/en/products/syslog-ng/
[3] - msyslog - Modular syslog - http://www.corest.com/solutions/products.html
[4] - sqlsyslogd - SQL syslog extension. - http://www.frasunek.com/
[5] - syslogd+mysql - Patched FreeBSD syslogd - http://keves.org/dev/files/syslogd+mysql.tgz
System messages in a UNIX system are handled by syslog. The responsibilities of syslog are to filter and disperse program generated messages based on a priority code contained in each message. Filtering with priority codes is not sufficient to generate enough usable information for the system administrator. Utilities which do regular expression parsing of syslog messages typically do not run continuously and thus are limited by a lack of state in detecting potentially important patterns in syslog messages.
Classic way to resolve this problem is peephope optimizers that look into a fixed window (last N messages). They improves the monitoring of systems by extending the existing syslog infrastructure with programmable (usually Perl-based) modules. These modules use a library with a simple API to perform near real time analysis based on the messages they register to receive. System administrators peephole optimizers to improve the services provided by their systems without the need for constant manual evaluation of message logs.
The "system logger'', or syslog, gives programs a standard interface to report interesting events to the administrator. These messages are read by a background daemon and routed accordingly. The data which a program passes to syslog is called a message. A message consists of two parts: priority and textual data [9]. The priority of a message also contains two parts: an encoded facility and level. The facility of a message is a general category into which the message fits. The level of a message is a way for the program to rate the severity of the message, typically ranging from emerg to debug. The textual data of a syslog message is a string provided by the program that describes the event being logged.
I used the logger utility(this was provided by Michael Kriss) that allowed me to test out these entries by issuing the following:
logger -p local0.debug "this is a test"
logger -p cron.info " this is a test"The syslog daemon, syslogd, acts as the router for system messages. When it receives a message from a program, it in turn must decide what to do with the it. Most commonly this action involves writing the message to disk, but other potential actions include printing it to the system console, notifying online users, or forwarding the message to another system. syslogd makes these decisions based on a configuration file written by the system administrator. The rules in this configuration file are based entirely on the priority of the message.
The standard syslog daemon [Note 1] lacks many important features. These features impact the the reliability of message delivery and the integrity of messages after delivery.
There is no standard structure for writing syslog messages. A cleverly written program could bypass the syslog library calls and write directly to the listening syslogd socket. When syslogd reads this message, it will prepend default priority information and route the message according to these defaults. While the lack of message structure is not critical for system operation, it does not encourage good security.
Some versions of syslog have the ability to route messages based upon regular expression filtering. This allows greater discrimination and handling of messages than is possible with priority filtering. Sophisticated classification and processing of messages is still difficult with regular expression filtering. Extending syslog in this manner violates the UNIX design philosophy of simple tools doing one thing well. Extra processing must be performed with each message, which decreases message handling capacity.
Syslog permits file redirection via pipe symbol.
Standard facility for logging in Unix env. is syslogd diamon. Depending on the configuration of /etc/syslog.conf, it accept messages form subsystems and write it in an appropriate system log, writes it to the system console, forwards it to a list of users, or forwards it to syslogd on another host over the network.
Each logged message includes a message header and a message body. The message header consists of a facility indicator, a severity level indicator, a timestamp, a tag string, and optionally the process ID.
The message body is generated from the message and arguments to the call in the same manner as if these were arguments to printf function and include severity level and facility that indicates the application or system component generating the message.
Possible values of severity level include:
- LOG_EMERG A panic condition. This is normally broadcast to all users.
- LOG_ALERT A condition that should be corrected immediately, such as a corrupted system database.
- LOG_CRIT Critical conditions, such as hard device errors.
- LOG_ERR errors
- LOG_WARNING Warning messages.
- LOG_NOTICE Conditions that are not error conditions, but that may require special handling.
- LOG_INFO Informational messages.
- LOG_DEBUG Messages that contain information normally of use only when debugging a program.
Possible facility values include:
- LOG_KERN Messages generated by the kernel. These cannot be generated by any user processes.
- LOG_USER Messages generated by random user processes. This is the default facility identifier if none is specified.
- LOG_MAIL The mail system.
- LOG_DAEMON System daemons, such as in.ftpd(1M) .
- LOG_AUTH The authorization system: login(1) , su(1M) , getty(1M) .
- LOG_LPR The line printer spooling system: lpr(1B) , lpc(1B) .
- LOG_NEWS Reserved for the USENET network news system.
- LOG_CRON The cron/at facility; crontab(1) , at(1) , cron(1M) .
- LOG_LOCAL0 -- LOG_LOCAL7 Reserved for local use.
Syslog, the system logger, is a daemon that accepts log messages from programs and writes them to the appropriate log file. Some programs such as Apache and MySQL write their log files directly, while other programs such as sendmail and the ftp and telnet daemons write them indirectly through syslog.
There are two keys to understanding syslog. First, the syslog daemon does not generate the log messages, it merely sorts them into files. The log messages are generated by all of the other servers and daemons, and not every program even uses syslog. Second, the messages that are processed through syslog are all tagged with a facility and priority, where the facility describes the subsystem that generated the message. Syslog uses the facility and priority to decide what to do with the message. These are their possible values.
Facility: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, syslog, user, uucp, local0, ..., local7.
Priority (high to low): emerg, alert, crit, err, warning, notice, info, debug.
Note that these are the only legal values, you can't make up new ones like http for the Apache web server. And now we can see which programs are likely to use syslog. Old programs that have a facility defined for them will probably use syslog. Newer programs that don't have an obvious facility will bypass syslog and write their log files directly.
Syslog.conf Syslog uses the file /etc/syslog.conf to decide where to write the messages it receives. In its simplest form, each line contains a facility and priority separated by dot and then a file name. This applies to the given priority and anything higher. You can also use multiple facility.priority pairs separated by semicolon, an asterisk to mean any facility or priority and the special priority none. Messages are written to every file on a matching line. So, depending on your rules, a message may go to multiple files or none at all. For example:
# Logs mail facility at priority info or higher. mail.info /var/log/maillog # Logs both auth and authpriv facilities. auth.info;authpriv.info /var/log/secure # Logs news facility at any priority. news.* /var/log/news # Logs any facility at priority crit or higher. *.crit /var/log/critical # Logs all facilities except mail and news. *.info;mail.none;news.none /var/log/messages # Displays all messages on virtual terminal 12. *.* /dev/tty12After editing the syslog.conf file, you must stop and restart the syslog daemon for the changes to take effect. Early versions of syslog required tabs between facility.priority and the file name, but now most versions allow spaces or tabs.
Logger You can manually send messages to the syslog daemon with the logger(1) program. This is useful for testing your config file and for shell scripts. The logger program reads the message either from the command line or from standard input. For example:
logger -p news.warning "This is a news.warning message."Config Tips Normally, the default syslog.conf file is fine for the home user and does not need to be changed. But suppose you're having trouble with some server that uses syslog. In that case, you may wish to increase its log level. And remember that it's the server that generates the log messages, so refer to the server's documentation for how to make it generate more or fewer log entries.
Security Syslog is a network daemon and reads its input on UDP port 514. If you want to prevent other machines from writing messages into your log files, then you should block that port in your firewall rules. Also, some messages contain sensitive security information, especially the auth and authpriv facilities. So, be careful what permissions you put on those files.
See Also The man pages for syslogd(8), syslog.conf(5) and logger(1). There is an excellent chapter in the Unix System Administration Handbook.
I started putting the data into a database for more flexible querying, using SQLSyslogd, written by Przemyslaw Frasunek, available at: http://www.frasunek.com/sources/security/sqlsyslogd/.
I like having SQL at my disposal when I need very specific information from my logs.
You can pipe to sqlsyslogd with a line like this:
destination sqlsyslogd { program("/usr/local/sbin/sqlsyslogd -u sqlsyslogd -t logs sqlsyslogd -p"); }; log { source(src); destination(sqlsyslogd); };"src" in this case is all the incoming messages, there's no filtering of messages. You still need to setup your database according to the instructions for sqlsyslogd. Read the docs that come with it.
See also Syslog configuration debugging
Summary - configuring syslog.conf
To all of the people who responded to my questions, many thanks..
(There were just too many responses to thank everyone individually).
Overall, the suggestions were similar.
Don't use spaces, use tabs when configuring syslog.conf.
After making changes, kill -HUP pid for syslog.conf.
The message below is from Kai O'Yang who was one of may who forwarded
their syslog.conf files to share.
I am now receiving auth.notice messages from a remote system to my
loghost(on both the console and authlog file.
The only real problem I have that I haven't been able to resolve with
this is that the name of the remote host is not showing up. Instead,
I am receiving "???" in its place, and garbage on the device name:
Oct 23 14:44:32 ??? su:'su root' succeeded for mconroy on /dev/pts/3^m
I am sure it is configured correctly in dns. So I am at a lost.
Any thought???
Thanks again for everyone's help.
Mark Conroy
First add a loghost alias in /etc/hosts or nis table for the syslog
host. Here's my syslog.conf for all client machines.
#ident "@(#)syslog.conf 1.3 93/12/09 SMI" /* SunOS 5.0
*/ #
# Copyright (c) 1991-1993, by Sun Microsystems, Inc. #
# syslog configuration file.
#
# This file is processed by m4 so be careful to quote (`') names #
that match m4 reserved words. Also, within ifdef's, arguments #
containing commas must be quoted.
#
# Note: Have to exclude user from most lines so that user.alert #
and user.emerg are not included, because old sendmails # will
generate them for debugging information. If you
# have no 4.2BSD based systems doing network logging, you #
can remove all the special cases for "user" logging.
#
*.err;kern.notice;auth.notice;user.none /dev/console
*.err;kern.debug;daemon.notice;mail.crit;user.none @loghost
*.alert;kern.err;daemon.err;user.none operator,@loghost
*.alert;user.none root,@loghost
*.emerg;user.none @loghost auth.info
@loghost
mail.info @loghost daemon.info
@loghost
For the loghost:
#ident "@(#)syslog.conf 1.3 93/12/09 SMI" /* SunOS 5.0
*/ #
# Copyright (c) 1991-1993, by Sun Microsystems, Inc. #
# syslog configuration file.
#
# This file is processed by m4 so be careful to quote (`') names #
that match m4 reserved words. Also, within ifdef's, arguments #
containing commas must be quoted.
#
# Note: Have to exclude user from most lines so that user.alert #
and user.emerg are not included, because old sendmails # will
generate them for debugging information. If you
# have no 4.2BSD based systems doing network logging, you #
can remove all the special cases for "user" logging.
#
*.err;kern.notice;auth.notice;user.none /dev/console
*.err;kern.debug;daemon.notice;mail.crit;user.none
/var/adm/messages
*.alert;kern.err;daemon.err;user.none operator
*.alert;user.none root
*.emerg;user.none * auth.info
/var/log/authlog mail.info
/var/log/mlog
#
# Adding log to daemon information
#
daemon.info /var/log/syslog
Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: December 12, 2008