Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort

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 Configuration

Not 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:

• Field 1 is the date, Jun 19.

• Field 2 is the time the log was written, 15:24:16.

• Field 3 is the computer's hostname, firewall.

• Field 4 is the log facility generating the message, kernel.

• Field 5 is the log-prefix string defined in the LOG rule.

• Field 6 is the incoming network interface that the input rule is attached to, eth0.

• Field 7 is the outgoing interface, which has no value in a rule on the INPUT chain.

• Field 8 is the MAC address of the interface that the packet is arriving on, followed by eight pairs of garbage hexadecimal digits.

• Field 9 is the packet's source address, 192.168.1.4.

• Field 10 is the packet's destination address, 192.168.1.2.

• Field 11 is the IP packet's total length in bytes, LEN=60, including both the packet header and its data.

• Field 12 is the type of service (TOS) field's 3 service bits, plus a reserved trailing bit, TOS=0x00.

• Field 13 is the TOS field's top 3 precedence bits, PREC=0x00.

• Field 14 is the packet's time to live (TTL) field, TTL=64. Time to live is the maximum number of hops (that is, routers visited) remaining before the packet expires.

• Field 15 is the packet's datagram ID, ID=57743. The datagram ID is either the packet ID or the segment to which this TCP fragment belongs.

• Field 16 is the fragment flags field, indicating that the Don't Fragment (DF) bit is set.

• Field 17 is the message protocol type contained in the packet, PROTO=TCP. Field values include 6 (TCP), 17 (UDP), 1 (ICMP/<code>), and PROTO=<number> for other protocol types.

• Field 18 is the packet's source port, 33926.

• Field 19 is the packet's destination port, 111.

• Field 20 is the sender's window size, WINDOW=5840, which indicates the amount of data that it is willing to accept and buffer from this host at this time.

• Field 21 reports the reserved field in the TCP header. All 4 bits must be 0.

• Field 22 is the TCP state field. In this case, the SYN flag is set.

• Field 23 is the urgent pointer, which indicates the amount of data considered to be urgent. The field is 0 because the URG flag isn't set.

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:

• Field 1 is the date, Jun 19.

• Field 2 is the time the log was written, 15:24:16.

• Field 3 is the computer's hostname, firewall.

• Field 4 is the log facility generating the message, kernel.

• Field 5 is the log-prefix string defined in the LOG rule.

• Field 6 is the incoming network interface to which the input rule is attached, eth0.

• Field 7 is the outgoing interface, which has no value in a rule on the INPUT chain.

• Field 8 is the MAC address of the interface that the packet is arriving on, followed by eight pairs of garbage hexadecimal digits.

• Field 9 is the packet's source address, 192.168.1.4.

• Field 10 is the packet's destination address, 192.168.1.2.

• Field 11 is the IP packet's total length in bytes, LEN=28, including both the packet header and its data.

• Field 12 is the TOS field's 3 service bits, plus a reserved trailing bit, TOS=0x00.

• Field 13 is the TOS field's top 3 precedence bits, PREC=0x00.

• Field 14 is the packet's TTL field, TTL=40. Time to live is the maximum number of hops (that is, routers visited) remaining before the packet expires.

• Field 15 is the packet's datagram ID, ID=50655.

• Field 16 is the message protocol type contained in the packet, PROTO=UDP. Field values include 6 (TCP), 17 (UDP), 1 (ICMP/<code>), and PROTO=<number> for other protocol types.

• Field 17 is the packet's source port, 33926.

• Field 18 is the packet's destination port, 111.

• Field 19 is length of the UDP packet, including both the header and data, LEN=8.

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.)