Logging iptables Activity The iptables commands and options described to this point in this chapter operate without creating any special log entries. Sometimes, though, you want to have access attempts leave a trace in your system logs. For instance, you might want to record attempts to access sensitive ports that you've blocked, or failures related to stateful packet inspection. Such events may indicate an attempt to break into your system, so you may want to be made aware of them in order to be on the alert for other activities directed against your computer. WARNING  | Although logging firewall activities can be a useful source of information, it can also slow down your firewall's operation and provide a potential means of attack. If an attacker knows that you're logging particular types of information, the attacker can send your system packets with the goal of causing your system to write a lot of data to its log files. This degrades your firewall's performance, and in an extreme case it might cause the log file partition to run out of space, causing you further problems. For this reason, you should use these logging options with caution. If possible, place your system log files on a separate partition so that if it's overrun by an out-of-control logging process, it won't cause problems for other programs or processes. |
The iptables program includes a special target, LOG , for logging information. Unlike some targets, a match to the LOG target doesn't cause the system to stop searching for matches; after matching and logging the match, the kernel continues searching the chain to which the LOG target belongs. You can use this target in several different ways: -
You can log events that may not match other explicit targets. For instance, you might include a rule to log any stateful packet inspection violation, whether your system is configured to reject such violations. TIP  | Logging events that you don't necessarily want to reject can be a useful debugging tool, because you can verify that packets are reaching your system, and automatically log some information about these packets. Other tools, such as packet sniffers, can fill a similar role, but you might find this feature useful in some situations nonetheless. |
-
If your system has a default DENY or REJECT policy, you can include a firewall rule for any type of activity you want to log as if you were explicitly blocking that access, but call the LOG target instead of DENY or REJECT . When the packet is logged, it will be blocked by the default policy, unless some other rule lets it through. -
If your system has a default ACCEPT policy, you can log packets you want to block by duplicating the DENY or REJECT rule for those packets and changing the first copy to call the LOG target. If you change the second copy to call the LOG target, the result will be ineffectual, because the ACCEPT target will exit from the chain, leaving the LOG target unused. As an example, consider the following firewall rules on a default- ACCEPT policy firewall, which restrict access from the 172.24.0.0/16 network and log the access: # iptables -A INPUT -s 172.24.0.0/16 -j LOG # iptables -A OUTPUT -d 172.24.0.0/16 -j LOG # iptables -A INPUT -s 172.24.0.0/16 -j DROP # iptables -A OUTPUT -d 172.24.0.0/16 -j DROP The first two commands are exact duplicates of the last two, except for the change in the target ” LOG as opposed to DROP . The position of the second and third targets could easily be swapped; this detail is unimportant. You could also add other rules in-between the LOG and DROP rules, but this would make it more difficult to see that the two rules are related. The result of a logging operation resembles the following from a /var/log/messages file: Nov 18 22:13:21 teela kernel: IN=eth0 OUT= MAC=00:05:02:a7:76:da:00:50:bf:19:7e:99:08:00 SRC=192.168.1.3 DST=192.168.1.2 LEN=40 TOS=0x10 PREC=0x00 TTL=64 ID=16023 DF PROTO=TCP SPT=4780 DPT=22 WINDOW=32120 RES=0x00 ACK URGP=0 Information included in this output includes the following: -
Date and time ” The entry begins with a timestamp showing when the packet arrived. -
System name ” This computer is called teela . -
Input network interface ” The IN=eth0 entry indicates that the packet in question was an incoming packet on the eth0 interface. -
Output network interface ” The packet in question was not an outgoing packet, so the OUT= field is empty. -
MAC addresses ” The MAC= entry includes two media access control (MAC) addresses. The first six fields of this entry are the local system's MAC address, and the next six fields are the remote system's MAC address. (The remote system's MAC address is not reliable for packets that have passed through a router, such as packets from the Internet at large.) -
Source and destination IP addresses ” The SRC= and DST= entries provide the source and destination IP addresses, respectively. -
Source and destination ports ” The SPT= and DPT= entries specify the source and destination ports, respectively. -
Packet information ” Additional fields provide further information about the packet, such as its length ( LEN= ), its time-to-live (TTL) value ( TTL= ), and so on. The LOG target supports several additional options that you can use to control material that goes into log entries. The most useful option is probably --log-prefix prefix . This option lets you specify a string of up to 29 characters to help you identify log entries, and hence the rule that caused the log entry to be made. |
