-rw------- root root system_u:object_r:var_log_t /var/log/messages
# chcon system_u:object_r:var_log_t /var/log/cooling
# chmod 0600 /var/log/cooling # Optional!
# ls -Z /var/log/messages /var/log/cooling
-rw------- root root system_u:object_r:var_log_t /var/log/cooling
-rw------- root root system_u:object_r:var_log_t /var/log/messages
8.7.1.3. Keeping an eye on logs
The -f option to tail provides a convenient way to watch messages that are being appended to a file and is perfect for use with logfiles:
# tail -f /var/log/messages
Jun 1 08:47:14 darkday kerneclass="underline" hub 1-0:1.0: over-current change on port 1
Jun 1 08:47:14 darkday kerneclass="underline" hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
Jun 1 08:47:14 darkday kerneclass="underline" hub 1-0:1.0: over-current change on port 2
Jun 1 08:47:14 darkday kerneclass="underline" usb 1-2: USB disconnect, address 4
Jun 1 08:47:14 darkday kerneclass="underline" usb 1-2: new low speed USB device using uhci_hcd and address 5
Jun 1 08:47:14 darkday kerneclass="underline" usb 1-2: configuration #1 chosen from 1 choice
Jun 1 08:47:14 darkday kerneclass="underline" input: Logitech USB-PS/2 Optical Mouse as /class/input/input4
Jun 1 08:47:14 darkday kerneclass="underline" input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1f.2-2
Jun 1 09:54:49 darkday cooling: Water temperature exceeds 70C
Jun 1 09:54:49 darkday cooling: Water temperature exceeds 85C
...(Additional lines are displayed as they are added to the logfile)...
/var/log/messages is normally readable only by root. Although making it readable by other users may reveal a small amount of information about your system (reducing security), it can also reduce the amount of time spent in superuser mode (which, in turn, increases security). To make the messages file accessible to everyone:
# chmod a+r /var/log/messages
This tail command will display the last 10 lines in the file, and then additional lines within a second of the time that they are appended to the file. It can be left running in a terminal window in the corner of the screen while you perform system administration tasks.
8.7.1.4. Configuring remote logging
The syslog service was designed to facilitate remote logging. This is very useful in two circumstances:
In the event of a successful system intrusion, an attacker will often edit or delete logfiles to erase any record of his presence. If messages are logged to a remote server, it becomes more difficult to erase the trail because the attacker then needs to successfully attack the machine recording the log in addition to the system originally compromised.
In a network, it is convenient to gather logs in one place for centralized analysis. This lets you stay on top of the state of many systems from one location.
To configure a syslog network server, edit that host's /etc/sysconfig/syslog file, which initially looks like this:
# Options to syslogd
# -m 0 disables 'MARK' messages.
# -r enables logging from remote machines
# -x disables DNS lookups on messages recieved with -r
# See syslogd(8) for more details
SYSLOGD_OPTIONS="-m 0"
# Options to klogd
# -2 prints all kernel oops messages twice: once for klogd to decode, and
# once for processing with 'ksymoops'
# -x disables all klogd processing of oops messages entirely
# See klogd(8) for more details
KLOGD_OPTIONS="-x"
#
SYSLOG_UMASK=077
# set this to a umask value to use for all logfiles, as in umask(1).
# By default, all permissions are removed for "group" and "other".
Change the SYSLOGD_OPTIONS line to include -r (remote logging):
SYSLOGD_OPTIONS="-m 0 -r"
Then restart syslogd :
# service syslog restart
Shutting down kernel logger: [ OK ]
Shutting down system logger: [ OK ]
Starting system logger: [ OK ]
Starting kernel logger: [ OK ]
Ensure that your firewall configuration permits connections on UDP port 514.
Next, edit the file /etc/syslog.conf on the machines that will be forwarding log messages to the syslog server, and add this line:
*.* @ syslogserver
This will forward all messages to the remote host syslogserver (which may be an IP address or hostname). Restart syslogd to activate the changes.
It's important to leave local logging turned on in case the syslog server is unavailable, so don't remove the lines that write to the local logfiles.
The result will be a combined log containing entries from both the syslog server and the host that is forwarding its log messages:
Jun 1 02:52:33 darkday named[13255]: starting BIND 9.3.2 -u named
Jun 1 02:52:33 darkday named[13255]: found 1 CPU, using 1 worker thread
Jun 1 02:52:33 darkday named[13255]: loading configuration from '/etc/named.conf'
Jun 1 02:52:33 darkday named[13255]: listening on IPv4 interface lo, 127.0.0.1#53
Jun 1 02:52:33 darkday named[13255]: listening on IPv4 interface eth0, 172.16.97.100#53
Jun 1 02:52:33 darkday named[13255]: command channel listening on 127.0.0.1#953
Jun 1 02:52:33 darkday named[13255]: zone 0.in-addr.arpa/IN: loaded serial 42
Jun 1 02:52:33 darkday named[13255]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
Jun 1 02:52:33 darkday named[13255]: zone 255.in-addr.arpa/IN: loaded serial 42
Jun 1 02:52:33 darkday named[13255]: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 1997022700
Jun 1 02:52:33 darkday named[13255]: zone localdomain/IN: loaded serial 42
Jun 1 02:52:33 darkday named[13255]: zone localhost/IN: loaded serial 42
Jun 1 02:52:33 darkday named[13255]: running
Jun 1 02:57:22 bluesky chris: VNC service configured, restarting xinetd
Jun 1 02:57:29 bluesky xinetd[15394]: Exiting...
Jun 1 02:57:29 bluesky xinetd[15452]: xinetd Version 2.3.13 started with libwrap loadavg options compiled in.