Interpreting the System Logs
| syslogd is the service daemon that logs system events. syslogd's main system log file is /var/log/messages. Many programs use syslogd's standard logging services. Other programs, such as the Apache web server, maintain their own separate log files. syslog ConfigurationNot all log messages are equally importantor even interesting. This is where /etc/syslog.conf comes in. The configuration file /etc/syslog.conf enables you to tailor the log output to meet your own needs. Messages are categorized by the subsystem that produces them. In the man pages, these categories are called facilities (see Table 8.1).
Within any given facility category, log messages are divided into priority types. The priorities, in increasing order of importance, are listed in Table 8.2.
An entry in syslog.conf specifies a logging facility, its priority, and where to write the messages. Not obvious is that the priority is inclusive. It's taken to mean all messages at that priority and higher. If you specify messages at the error priority, for example, all messages at priority error and higher are includedcrit, alert, and emerg. Logs can be written to devices, such as the console, as well as to files and remote machines.
These two entries write all kernel messages to both the console and /var/log/_messages. Messages can be duplicated to multiple destinations: kern.* /dev/console kern.* /var/log/messages This entry writes panic messages to all default locations, including /var/log/messages, the console, and all user terminal sessions: *.emerg * The next two entries write authentication information related to root privilege and connections to /var/log/secure, and user authorization information to /var/log/auth. With the priority defined at the info level, debug messages won't be written: authpriv.info /var/log/secure auth.info /var/log/auth The next two entries write general daemon information to /var/log/daemon, and mail traffic information to /var/log/maillog: daemon.notice /var/log/daemon mail.info /var/log/maillog Daemon messages at the debug and info priorities and mail messages at the debug priority are not logged (author's preference). named, crond, and systematic mail checking produce uninteresting informational messages on a regular basis. The final entry logs all message categories of priority info or higher to /var/log/messages, with the exception of auth, authpriv, daemon, and mail. In this case, the latter four message facilities are set to none because their messages are directed to their own dedicated log files: *.info;auth,authpriv,daemon,mail.none /var/log/messages
syslogd can be configured to write the system logs to a remote machine. A site that uses a networked server configuration similar to the example in Chapter 6, "Packet Forwarding," with services offered from internal machines in the DMZ, might want to keep a remote copy of the system logs. Maintaining a remote copy offers two advantages: First, log files are consolidated on a single machine, making it easier for a system administrator to monitor the logs. Second, the information is protected if one of the server machines is ever compromised. Chapter 9, "Intrusion Detection and Response," discusses the importance that system logs play during recovery if a system is ever compromised. One of the first things an attacker does after successfully gaining root access to a compromised machine is to either erase the system logs or install trojan programs that won't log his activities. The system log files are either gone or untrustworthy at exactly the time you need them most. Maintaining a remote copy of the logs helps protect this information, at least until the hacker replaces the daemons writing the log file information. To log system information remotely, both the local logging configuration and the remote logging configuration require slight modifications. On the remote machine collecting the system logs, add the -r option to the syslogd invocation. The -r option tells syslogd to listen on the UDP syslog UDP port 514 for incoming log information from remote systems. On the local machine producing the system logs, edit syslogd's configuration file, /etc/ syslog.conf, and add lines specifying what log facilities and priorities you want written to a remote host. For example, the following copies all log information to hostname: *.* @hostname syslogd output is sent over UDP. Both the source and the destination ports are 514. The client firewall rule would be as follows: iptables -A OUTPUT -o <out-interface> -p udp \ -s <this host> --sport 514 \ -d <log host> --dport 514 -j ACCEPT Firewall Log Messages: What Do They Mean?To generate firewall logs, the kernel must be compiled with firewall logging enabled. By default, individually matched packets are logged as kern.warn (priority 4) messages. The log priority can be changed with the --log-level option to -j LOG. Most of the IP packet header fields are reported when a packet matches a rule with the LOG target. Firewall log messages are written to /var/log/messages by default. You could duplicate the firewall log messages to a different file by creating a new log file and adding a line to /etc/syslog.conf: kern.warn /var/log/fwlog As a TCP example, this rule denying access to the portmap/sunrpc TCP port 111 would produce the following message in /var/log/messages: iptables -A INPUT -i $EXTERNAL_INTERFACE -p tcp \ --dport 111 -j LOG --log-prefix "DROP portmap: " iptables -A INPUT -i $EXTERNAL_INTERFACE -p tcp \ --dport 111 -j DROP (1) (2) (3) (4) (5) (6) (7) Jun 19 15:24:16 firewall kernel: DROP portmap: IN=eth0 OUT= (8) MAC=00:a0:cc:40:9b:a8:00:a0:cc:d4:a7:81:08:00 (9) (10) (11) SRC=192.168.1.4 DST=192.168.1.2 LEN=60 (12) (13) (14) (15) (16) TOS=0x00 PREC=0x00 TTL=64 ID=57743 DF (17) (18) (19) (20) PROTO=TCP SPT=33926 DPT=111 WINDOW=5840 (21) (22) (23) RES=0x00 SYN URGP=0 The log message fields are numbered for the purposes of discussion:
When interpreting the log message, the most interesting fields are these: Jun 19 15:24:16 DROP portmap: IN=eth0 SRC=192.168.1.4 DST=192.168.1.2 PROTO=TCP SPT=33926 DPT=111 SYN This says that the dropped packet is a TCP packet coming in on the eth0 interface from an unprivileged port at 192.168.1.4. It was a TCP connection request targeted to this machine's (192.168.1.2) port 111, the sunrpc/portmap port. (This can be a common message because portmap historically is one of the most commonly targeted services.) As a UDP example, this rule denying access to the portmap/sunrpc UDP port 111 would produce the following message in /var/log/messages: iptables -A INPUT -i $EXTERNAL_INTERFACE -p udp \ --dport 111 -j LOG --log-prefix "DROP portmap: " iptables -A INPUT -i $EXTERNAL_INTERFACE -p udp \ --dport 111 -j DROP (1) (2) (3) (4) (5) (6) (7) Jun 19 15:24:16 firewall kernel: DROP portmap: IN=eth0 OUT= (8) MAC=00:a0:cc:40:9b:a8:00:a0:cc:d4:a7:81:08:00 (9) (10) (11) SRC=192.168.1.4 DST=192.168.1.2 LEN=28 (12) (13) (14) (15) TOS=0x00 PREC=0x00 TTL=40 ID=50655 (16) (17) (18) (19) PROTO=UDP SPT=33926 DPT=111 LEN=8 The log message fields are numbered for the purposes of discussion:
When interpreting the log message, the most interesting fields are these: Jun 19 15:24:16 DROP portmap: IN=eth0 SRC=192.168.1.4 DST=192.168.1.2 PROTO=UDP SPT=33926 DPT=111 This says that the dropped packet is a UDP packet coming in on the eth0 interface from an unprivileged port at 192.168.1.4. It was a UDP exchange targeted to this machine's (192.168.1.2) port 111, the sunrpc/portmap port. (This can be a common message because portmap historically is one of the most commonly targeted services.) |
EAN: 2147483647
Pages: 163