Information You Can Use
Syslog addresses the problem of information overload by breaking down log data into categories that can be easily managed and analyzed. The two most common categories are log source and criticality, which map to syslog message components "Facility," showing what daemon or service originated the message, and "Severity," weighing its importance.
For logs to have value, it is critical to configure syslog properly.
Each facility can be sent to a different location or reviewed by a different group to provide maximum flexibility and checks and balances. (See "Syslog Message Sources") Large enterprises can create multiple syslog servers, each devoted to a particular facility or set of facilities; for smaller organizations, a single syslog server that logs different facilities to separate directories will do nicely.
Kern and other critical services should be reviewed more often than some of the less important services running on a system. However, it is essential to keep messages from all facilities; they might give tips into a system problem or the root cause of a compromise. For example, during one incident, a system had a rootkit, but the company could not figure out how. Since it was a kernel-level rootkit, they focused their energy and effort on the kern and system facility messages. It was not until they examined the mail facility that they noticed an unusual packet size entering the company. Syslog provided the data, but a human had to do the manual correlation.
Some versions of syslog have built-in alerting capabilities; others can incorporate alerting through simple scripting.
As the volume of log data grows, however, tracking down an attack, even using syslog, becomes more difficult. This is where syslog meets up with SIM/SEM tools. These tools do the initial correlation and analysis to narrow down the events, so a human can do root-cause analysis much more quickly.
