Log Dejargonizer

iptables / netfilter · Event IN= OUT=

iptables: a packet was logged by a firewall rule

The Linux kernel firewall matched a packet against a rule with logging enabled and wrote the packet header to the kernel log. The format is dense and unpunctuated, but every field is a key-value pair and it reads easily once you know the order.

Also written as iptables deniedIN= OUT= SRC= DST=kernel iptables drop lognetfilter drop log

What it means for you

On a personal computer

Your Linux machine's firewall blocked a connection and wrote down the details. On anything reachable from the internet this happens continuously and is the firewall working correctly.

For an analyst

The LOG target only writes the entry; it does not drop anything, so a matching DROP or REJECT rule must follow it. The IN and OUT fields together give you direction: IN populated with OUT empty means inbound to this host, and both populated means forwarded. Outbound and forwarded drops deserve far more attention than inbound ones.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Aug 28 09:41:17 gw-01 kernel: [1234567.890123] IPT-DROP-IN: IN=eth0 OUT= MAC=00:00:5e:00:53:01:00:00:5e:00:53:02:08:00 SRC=198.51.100.77 DST=192.0.2.15 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=41928 DF PROTO=TCP SPT=49820 DPT=3389 WINDOW=29200 RES=0x00 SYN URGP=0

The fields that decide it

Everything else in the log line is context.

IN
The interface the packet arrived on. Empty for locally generated packets.
OUT
The interface it was leaving by. Empty for packets destined to this host.
  • Both IN and OUT populatedA forwarded packet — this host is routing.
  • IN populated, OUT emptyInbound to this machine. The most common case.
  • IN empty, OUT populatedGenerated locally and leaving. Outbound drops are the interesting ones.
SRC
Source IP address.
DST
Destination IP address.
PROTO
The protocol — TCP, UDP, ICMP, or a number.
SPT
Source port.
DPT
Destination port. What was being reached for.
  • 22SSH. Continuously scanned on any public address.
  • 3389Remote Desktop, unusual on a Linux host and worth noting.
  • 445SMB. Should never be reachable from the internet.
  • A high random portOften the return leg of an outbound connection that the state table lost.
The log prefix
Free text set by the rule with --log-prefix. Set one per rule; without it you cannot tell which rule matched.
SYN / ACK / RST
TCP flags, written as bare words in the line. SYN alone is a connection attempt; ACK without state is an out-of-state packet.

Ordinary reasons this happens

Most of the time it is one of these.

  • Internet background scanning against any public address, which is nearly all of it.
  • Broadcast and multicast discovery traffic on the local network.
  • Return traffic arriving after the connection tracking entry expired.
  • A service moved or decommissioned while clients still try to reach it.
  • Health checks and monitoring probes aimed at ports that are closed.
  • Docker and container networking, which adds forwarding rules that log unexpectedly.

When it is not ordinary

Port scanning from one source.

What gives it awayOne SRC against a sequence of DPT values in a short window.

ATT&CK T1046

A sweep for one exposed service.

What gives it awayOne DPT across many DST addresses.

ATT&CK T1018

A compromised local host trying to reach out.

What gives it awayDrops where IN is empty and OUT is populated. Outbound drops from your own machine are the ones worth chasing.

ATT&CK T1071

Lateral movement probing.

What gives it awayForwarded drops on administrative ports crossing between network segments.

ATT&CK T1021

What to do next

  1. Read IN and OUT together to establish direction before anything else.
  2. For outbound drops, identify the local process responsible — this is the highest-value case.
  3. Aggregate before judging: distinct DPT per SRC, and distinct DST per DPT.
  4. Read the log prefix to identify which rule matched. If there is no prefix, add one.
  5. For inbound drops from the internet, confirm the traffic is being dropped and move on.
  6. Remember the LOG target does not drop — check that a DROP or REJECT rule actually follows it.

Queries to run

grep Top sources. On systemd hosts use `journalctl -k` instead of reading the file. 
grep 'IN=' /var/log/kern.log | grep -oP 'SRC=\K[\d.]+' | sort | uniq -c | sort -rn | head -20
grep Most-probed destination ports, which tells you what scanners are currently looking for. 
grep 'IN=' /var/log/kern.log | grep -oP 'DPT=\K\d+' | sort -n | uniq -c | sort -rn | head -20
grep Sources exceeding fifty packets in an hour. 
journalctl -k --since '1 hour ago' | grep 'IN=' | grep -oP 'SRC=\K[\d.]+' | sort | uniq -c | awk '$1 > 50'
grep Outbound drops by destination — an empty IN field means the packet originated here, which is the case that matters most. 
grep -P 'IN=\s' /var/log/kern.log | grep -oP 'DST=\K[\d.]+' | sort | uniq -c | sort -rn
elastic 
event.dataset:"iptables" and iptables.output_device:* | stats count by destination.ip, destination.port

Common questions

How do I read an iptables log line?

Every field is a key-value pair in a fixed order. IN and OUT are the interfaces, SRC and DST the addresses, PROTO the protocol, and SPT and DPT the source and destination ports. The bare words near the end — SYN, ACK, RST — are TCP flags. Read IN and OUT first, because together they tell you the direction, which determines what the rest means.

Where are iptables logs written?

To the kernel log, which means /var/log/kern.log on Debian and Ubuntu, /var/log/messages on many Red Hat derivatives, and `journalctl -k` on any systemd host. The exact destination depends on your syslog configuration, and it is common to route them to a dedicated file with an rsyslog rule to keep them out of the general kernel log.

Why is my iptables LOG rule not blocking anything?

Because LOG is a non-terminating target — it writes the entry and lets the packet continue through the chain. You need a DROP or REJECT rule after it. A LOG rule with nothing following it produces log entries for traffic that is then happily accepted, which is a common and confusing misconfiguration.

How do I tell which iptables rule produced a log entry?

Use --log-prefix on each LOG rule to tag its output, for example `-j LOG --log-prefix "IPT-DROP-IN: "`. Without a prefix, every rule's output looks identical and there is no way to work out which one matched.

Read next

Vendor documentation

Last reviewed 28 August 2026