Introduction
In any Linux system, event registration is essential to monitor behavior, diagnose problems and ensure the integrity of the environment. The most traditional and widely adopted mechanism is the syslog system, which centralizes kernel-generated messages, services and applications in a structured format.
What is syslog?
Syslog is a protocol and a set of tools designed to capture, classify and store system events. Each message includes a time mark, the name of the host that generated it, a facility that indicates the origin of the message and a level of severity that reflects its criticality.
History and evolution
The origin of syslog dates back to the 1980s, when it was implemented in the Berkeley Unix system as a simple daemon called syslod. Over time, more advanced alternatives such as rsyslog and syslog-ng emerged, adding features such as regular expression-based filtering, TLS support and database writing.
Main components
In a typical Linux installation we find several daemon that can play the role of syslog:
- syslod: the original daemon, still present in some minimalist distributions.
- rsyslog: a high performance syslog improvement, input and output modules, and real-time processing capacity.
- syslog-ng: another alternative focused on scalability and complex filtering, with native support for JSON and data structures.
All of these daemon read the configuration from files like / etc / rsyslog.conf or / etc / syslog-ng.conf and write messages at various destinations, such as local files, remote consoles or centralized log servers.
Rough levels and facilities
Each syslog message has two classifications that allow the information to be filtered and routed:
- Facility: indicates the subsystem that generated the message. The most common values are kern (kernel), user (user processes), mail, daemon, auth, syslog, lpr, news, uucp, cron, local0 to local7 (reserved for local use).
- Severity (gravity level): follows the standard RFC 5424 and ranges from 0 (emergency) to 7 (debug). The levels are: emergency, alert, critical, error, warning, notice, informational and debug.
Thanks to this combination, an administrator can create rules that, for example, send all auth messages with error level or higher to a separate security server.
Basic configuration
In most modern distributions the default daemon is rsyslog. Your main configuration file is in / etc / rsyslog.conf. The basic syntax of a rule is:
facility.nivel acción
Where facility and level can be an asterisk (*) to indicate any, and the action is usually the route of a file, a tube or a remote direction.
A simple example that saves all warning and higher level messages in / var / log / warnings.log would be:
*.warning /var/log/warnings.log
To capture only the authentication events with error level or higher would be used:
auth.err /var/log/auth_errors.log
Example of rules
A more complete configuration file can contain several sections that direct different types of information to different destinations:
- Kern.* / var / log / kernel
- mail.info / var / log / mail.info # mail service information
- auth, authpriv.* / var / log / secure # login and authentication attempts
- daemon.* / var / log / daemon.log # background services
- *. = debug; auth, authpriv.none; news.none; mail.none - / var / log / debug # debugging excluding certain facilities
- *.emerg: omusrmsg:* # sending emergencies to all connected users
These lines show how you can combine facilities and levels, use the point and coma to separate multiple selectors, and use the minus (-) sign before the route to deactivate the synchronization after each writing, which improves performance in high-load systems.
Sending to remote servers
One of the advantages of syslog is the ability to send the logs to a centralized server, which facilitates the correlation of events and long-term retention. In rsyslog the reshipment directive has the following form:
*.* @logservidor.example.com:514
The @ symbol indicates UDP transport; if TCP is preferred it is used @ @ instead. To add TLS encryption you can use the omtls module:
action(type='omtls' target='logservidor.example.com' port='6514' mode='peer' authmode='anon' caFile='/etc/ssl/certs/ca-certificates.crt')
This configuration sends all messages via TLS to the 6514 port of the log server, ensuring the confidentiality and integrity of the information during transit.
Login rotation
Log files tend to grow indefinitely, so it is necessary to rotate them periodically to avoid the exhaustion of disk space and to facilitate its management. The standard Linux tool is logotate, which is run by cron and applies policies defined in / etc / logotate.conf and in / etc / logotate.d / files.
A typical example of configuration for syslog files would be:
- / var / log / syslog {
weekly
rotate 4
compress
delaycompressor
missingok
notifempty
create 640 root adm
sharescripts
bentotate
/ usr / lib / rsyslog / rsyslog-rotate
endscript
}
This rule breaks the file every week, keeps four compressed copies, creates a new file with 640 permissions and runs a script to tell rsyslog to reopen its file descriptors.
Good practices
For the maximum benefit of the registration system it is recommended to follow some guidelines:
- Separate the critical logs (auth, kernel) from the least relevant ones in different files and send them to a dedicated security server.
- Use appropriate severity levels: avoid recording debug messages in production unless a specific problem is being solved.
- Apply filtered at source to reduce the volume of data transmitted and stored.
- Protect transmission channels with TLS or VPN when the logs leave the perimeter of confidence.
- Review rotation and retention rules regularly to comply with compliance policies (e.g. GDPR or ISO 27001).
- Monitor disk use and set alerts when the available space falls under a secure threshold.
Conclusion
The syslog command and its modern implementations such as rsyslog and syslog-ng remain the backbone of the event record in Linux environments. Its flexibility, based on facilities and levels of severity, allows to adapt the capture of messages to almost any operational or security requirements. Understanding its operation, know how to set up filtering and forwarding rules, and applying good rotation and protection practices are essential skills for any system manager who seeks to maintain a visible, safe and easy to debug infrastructure.
