/flags/iptables/iptables-j-log-log-prefix
iptables -j LOG --log-prefix: log dropped packets before dropping them
- tool
- iptables / nftables
- command
- iptables
- flag
- -j LOG --log-prefix PREFIX
- default
- no prefix; --log-level defaults to warning
iptables -A INPUT -j LOG --log-prefix "INPUT-DROP: " writes a kernel log line for every packet that reaches the rule, starting with the given prefix so you can find it with journalctl -k | grep INPUT-DROP. LOG is a non-terminating target: after logging, the packet continues to the next rule. To see what a firewall drops, put a LOG rule with the same match directly before the DROP rule (or before the chain's DROP policy), so each logged line is a packet that was then discarded.
Log, then drop
sudo iptables -A INPUT -m limit --limit 5/min --limit-burst 10 -j LOG --log-prefix "INPUT-DROP: " --log-level info
sudo iptables -A INPUT -j DROP
sudo journalctl -k -f | grep INPUT-DROPThe log line contains the interface (IN=, OUT=), MAC header, source and destination (SRC=, DST=), protocol, ports (SPT=, DPT=) and TCP flags; that is usually enough to see which rule is missing. Without -m limit, a port scan or a flood can write thousands of lines per second.
LOG options
The iptables-extensions manual lists these options for the LOG target:
| Option | Effect |
|---|---|
| --log-prefix PREFIX | Text placed before each message, up to 29 letters; end it with a space or colon |
| --log-level LEVEL | Syslog level: emerg, alert, crit, error, warning, notice, info or debug (or a number) |
| --log-tcp-sequence | Log TCP sequence numbers (a security risk if users can read the log) |
| --log-tcp-options | Log TCP header options |
| --log-ip-options | Log IP/IPv6 header options |
| --log-uid | Log the user ID of the local process that generated the packet |
| --log-macdecode | Decode MAC addresses and protocol |
Placement and prefixes
- One prefix per decision point. Use distinct prefixes such as
FW-IN-DROP:,FW-FWD-DROP:andFW-SSH-NEW:so a single grep tells you which rule logged the packet. - Order. The LOG rule must sit before the rule that drops; with
-Aafter a DROP it never sees a packet. See iptables -I vs -A and check positions with --line-numbers. - Skip normal traffic. Accept
ESTABLISHED,RELATEDtraffic first (conntrack --ctstate), so the log shows only new, unexpected packets.
Pitfalls
- Prefix length. The prefix is limited to 29 characters; iptables rejects longer values.
- Containers and namespaces. LOG in a non-initial network namespace may be suppressed by the kernel unless
net.netfilter.nf_log_all_netnsis enabled. - Root required. Adding rules needs root; without it you get Permission denied (you must be root).
- NFLOG. For high volumes or packet capture,
-j NFLOGsends packets to user space (ulogd, tcpdump on the nflog interface) instead of the kernel log.
FAQ
Why does my LOG rule not drop the packet?
LOG is a non-terminating target: it writes the log line and rule traversal continues with the next rule. To log and drop, use two rules with the same match, first -j LOG, then -j DROP.
Where do the log lines appear?
In the kernel log, readable with dmesg or journalctl -k, and in syslog files such as /var/log/kern.log or /var/log/messages depending on the distribution's logging setup.
How do I avoid flooding the log?
Add a rate limit to the LOG rule, for example -m limit --limit 5/min --limit-burst 10, so only a few packets per minute are logged while all of them are still dropped by the next rule.