Table 1-1. Syslog facilities
Facility number Facility Description
0
kern
Kernel messages
1
user
User-level messages
2
mail
Mail system
3
daemon System daemons
4
auth
Security/authorization messages
5
syslog
Messages generated internally by syslogd
6
lpr
Line printer subsystem
7
news
Network news subsystem
8
uucp
UUCP subsystem
9
Clock daemon
10
authpriv Security/authorization messages
11
ftp
FTP daemon
12
-
NTP subsystem
13
-
Log audit
14
-
Log alert
15
cron
Scheduling daemon
16
local0
Local use 0 (local0)
17
local1
Local use 1 (local1)
18
local2
Local use 2 (local2)
19
local3
Local use 3 (local3)
20
local4
Local use 4 (local4)
21
local5
Local use 5 (local5)
22
local6
Local use 6 (local6)
23
local7
Local use 7 (local7)
Along with the facility is the severity. The severity has
potential values of Emergency,
Alert, Critical, Error, Warning, Notice,
Informational, and Debug. These severities
are
listed in descending order, with the most severe listed first. You may determine
that Emergency logs should be sent somewhere different from other severity levels. In
Example 1-8
, all of the severities are being sent to the log associated with each facility.
The “*” after the facility name indicates all facilities.
If you wanted to, for instance,
send errors from the auth facility
to a specific log file, you would use
auth.error
and
indicate the file you want to use.
Once you
know where the logs are kept, you need to be able to read them. Fortu‐
nately, syslog log entries are easy enough to parse. If you look at
Example 1-11
, you
will see a collection
of log entries from the
auth.log
on a Kali system. Starting on the
