syslog
| syslog | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Family: | TCP / IP | ||||||||||||||||||||||||
| Operation area: | Transmission of log messages in an IP - computer network |
||||||||||||||||||||||||
| Ports: | 514 / UDP | ||||||||||||||||||||||||
|
|||||||||||||||||||||||||
| Standards: | |||||||||||||||||||||||||
syslog is a standard for the transmission of log messages in an IP - computer network . The term “syslog” is often used to refer to both the actual syslog network protocol and the application or library that sends or receives syslog messages.
The syslog protocol has a very simple structure - the syslog client sends a short text message (less than 1024 bytes ) to the syslog receiver, which consists of a header of a few words and the actual message. The recipient is often referred to as "syslogd", "syslog daemon", or "syslog server". A syslog server can also work as a relay and transfer received messages to other servers.
The messages can be transmitted using various transmission protocols. The standard prescribes implementations of the syslog protocol as the transmission protocol to be supported TLS . In addition, according to the standard, a syslog implementation should support UDP .
Syslog is typically used for computer system management and security monitoring. It has some weaknesses, but it is available on a wide variety of devices. This enables the easy integration of various log sources into a central repository (overall directory).
Structure of a syslog message
A syslog message consists of three components: a selector - called priority -, a header and the actual content.
The priority selector is an integer whose binary representation can be split into two parts: the facility field and the severity field. This enables the syslog messages to be classified according to their origin and severity. The Severity field, which contains the last three bits of the priority, contains a numerical value between 0 and 7, with 0 being the most critical or urgent level:
0 Emergency
1 Alert
2 Critical
3 Error
4 Warning
5 Notice
6 Informational
7 Debug
The Facility field, comprising the first five bits of the Priority, contains a numeric value that identifies the service or component that generated the syslog message. The following values are predefined according to RFC 3164 :
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 local0
17 local1
18 local2
19 local3
20 local4
21 local5
22 local6
23 local7
In the syslog configuration file, the names are abbreviated as follows: kern (0), user (1), mail (2), daemon (3), auth (4), syslog (5), lpr (6), news (7 ), uucp (8), cron (9), authpriv (10), ftp (11).
The values 16 - 23 are provided for general syslog messages (local0 to local7). However, it is entirely permissible to use the predefined values 0 to 15 for your own purposes. With the help of the priority selector you can easily filter for certain messages, such as: "Record all mail server messages with the severity error ".
The header contains a time stamp and the name or IP address of the sender of the syslog message. The time stamp is inserted by the recipient, i.e. the syslog server. It contains the date and the local time at the time of receipt. Often, the date and time of sending is also included in the actual message.
history
Syslog was developed by Eric Allman as part of the Sendmail project. Originally (in the early 1980s) it was developed and used exclusively for Sendmail. However, it quickly turned out to be a useful tool that other applications could use. Today syslog is the standard logging mechanism under Unix and Linux . Syslog implementations also exist under other operating systems such as Microsoft Windows .
Syslog was not initially standardized. To increase the security of the protocol, the Internet Engineering Task Force formed a working group. In 2001 the status achieved was documented in RFC 3164. Since then we have been working on new extensions.
outlook
There are new areas of application and increasing interest in syslog. Recently syslog has been standardized or recommended for a number of auditing applications, e.g. B. the "health care environment" ( IHE ) in the USA. The standardization efforts are still ongoing within the IETF .
Weak points
The syslog protocol has several weaknesses:
- Uses severity and facility inconsistently
- Some implementations do not mention the original source (when forwarding a message across multiple log hosts)
These weak points were the trigger for the standardization efforts described above. In addition, there are many implementations in practice that remedy these weaknesses in whole or in part. Such implementations can be found for all common operating systems. However, the solutions from different manufacturers are only compatible with one another to a limited extent. A very common implementation is syslog-ng , the extensions of which to the syslog protocol can now be seen as the industry standard.
See also
RFCs
- RFC 3164 - The BSD Syslog Protocol (obsoleted by RFC 5424 )
- RFC 3195 - Reliable Delivery for syslog
- RFC 5424 - The Syslog Protocol
- RFC 5425 - Transport Layer Security (TLS) Transport Mapping for Syslog
- RFC 5426 - Transmission of Syslog Messages over UDP
Web links
Individual evidence
- ↑ syslog; History; Outlook; Facility levels; Degrees of severity; Format of a syslog packet. Retrieved on October 23, 2018 (German).