≡ Menu

How to Log Linux IPTables Firewall Dropped Packets to a Log File

This article is part of our ongoing Linux IPTables series of articles. When things are not working as expected with your IPTables rules, you might want to log the IPTables dropped packets for troubleshooting purpose. This article explains how to log both incoming and outgoing dropped firewal packets.

If you are new to IPTables, first get yourself comfortable with the IPTables fundamental concepts.

Log All Dropped Input Packets

First we need to understand how to log all the dropped input packets of iptables to syslog.

If you already have whole bunch of iptables firewall rules, add these at the bottom, which will log all the dropped input packets (incoming) to the /var/log/messages

iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

In the above example, it does the following:

  • iptables -N LOGGING: Create a new chain called LOGGING
  • iptables -A INPUT -j LOGGING: All the remaining incoming packets will jump to the LOGGING chain
  • line#3: Log the incoming packets to syslog (/var/log/messages). This line is explained below in detail.
  • iptables -A LOGGING -j DROP: Finally, drop all the packets that came to the LOGGING chain. i.e now it really drops the incoming packets.

In the line#3 above, it has the following options for logging the dropped packets:

  • -m limit: This uses the limit matching module. Using this you can limit the logging using –limit option.
  • –limit 2/min: This indicates the maximum average matching rate for logging. In this example, for the similar packets it will limit logging to 2 per minute. You can also specify 2/second, 2/minute, 2/hour, 2/day. This is helpful when you don’t want to clutter your log messages with repeated messages of the same dropped packets.
  • -j LOG: This indicates that the target for this packet is LOG. i.e write to the log file.
  • –log-prefix “IPTables-Dropped: ” You can specify any log prefix, which will be appended to the log messages that will be written to the /var/log/messages file
  • –log-level 4 This is the standard syslog levels. 4 is warning. You can use number from the range 0 through 7. 0 is emergency and 7 is debug.

Log All Dropped Outgoing Packets

This is same as above, but the 2nd line below has OUTPUT instead of INPUT.

iptables -N LOGGING
iptables -A OUTPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

Log All Dropped Packets (both Incoming and Outgoing)

This is same as before, but we’ll be taking the line number 2 from the previous two examples, and adding it here. i.e We’ll have a separate line for INPUT and OUTPUT which will jump to LOGGING chain.

To log both the incoming and outgoing dropped packets, add the following lines at the bottom of your existing iptables firewall rules.

iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A OUTPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

Also, as we explained earlier, by default, the iptables will use /var/log/messages to log all the message. If you want to change this to your own custom log file add the following line to /etc/syslog.conf

kern.warning   /var/log/custom.log

How to read the IPTables Log

The following is a sample of the lines that was logged in the /var/log/messages when an incoming and outgoing packets was dropped.

Aug  4 13:22:40 centos kernel: IPTables-Dropped: IN= OUT=em1 SRC= DST= LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=59228 SEQ=2
Aug  4 13:23:00 centos kernel: IPTables-Dropped: IN=em1 OUT= MAC=a2:be:d2:ab:11:af:e2:f2:00:00 SRC= DST= LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=9434 DF PROTO=TCP SPT=58428 DPT=443 WINDOW=8192 RES=0x00 SYN URGP=0

In the above output:

  • IPTables-Dropped: This is the prefix that we used in our logging by specifying –log-prefix option
  • IN=em1 This indicates the interface that was used for this incoming packets. This will be empty for outgoing packets
  • OUT=em1 This indicates the interface that was used for outgoing packets. This will be empty for incoming packets.
  • SRC= The source ip-address from where the packet originated
  • DST= The destination ip-address where the packets was sent to
  • LEN= Length of the packet
  • PROTO= Indicates the protocol (as you see above, the 1st line is for outgoing ICMP protocol, the 2nd line is for incoming TCP protocol)
  • SPT= Indicates the source port
  • DPT= Indicates the destination port. In the 2nd line above, the destination port is 443. This indicates that the incoming HTTPS packets was dropped

Additional IPTables Tutorials

Add your comment

If you enjoyed this article, you might also like..

  1. 50 Linux Sysadmin Tutorials
  2. 50 Most Frequently Used Linux Commands (With Examples)
  3. Top 25 Best Linux Performance Monitoring and Debugging Tools
  4. Mommy, I found it! – 15 Practical Linux Find Command Examples
  5. Linux 101 Hacks 2nd Edition eBook Linux 101 Hacks Book

Bash 101 Hacks Book Sed and Awk 101 Hacks Book Nagios Core 3 Book Vim 101 Hacks Book

Comments on this entry are closed.

  • Abhishek August 15, 2012, 12:18 pm

    after I executed “iptables -A LOGGING -j DROP” rule all connections were dropped off my server so I changed it to “iptables -A LOGGING -j ACCEPT” to log all incoming packets.

  • shakaran August 15, 2012, 2:46 pm

    For me, this block and down fully a development server because iptables logging drop every package on localhost:
    kernel: IPTables-Dropped: IN= OUT=lo SRC= DST= LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=3502 DF PROTO=UDP SPT=39673 DPT=39673 LEN=24

    I have to make a rescue in boot mode and clean iptables rules for get start the server again.

  • Jalal Hajigholamali August 19, 2012, 10:53 pm


    Thanks a lot….

  • Steve October 25, 2012, 12:03 pm

    Very helpful,

  • brian December 10, 2012, 3:57 pm

    the first 3 comments were from people who didn’t read and understand the entire article.

    good info.

  • james brown January 5, 2013, 2:07 am

    So, what if I wanted to–for some service, lets say httpd–allow connections from some IP block and deny from elsewhere and wanted to log both accepted and denied connections, would I need two chains for logging, one which would then be targeted to ACCEPT and another to DROP, ie:

    iptables -A LOGGINGA -j ACCEPT
    iptables -A LOGGINGD -j DROP

  • Gaurav Kansal January 14, 2013, 2:34 am

    IPtables logs are coming in both file i.e., ./var/log/messages and /var/log/custom.log

    What should i do so that logs only comes in custom log file and not in /var/log/messages file.

  • Simon Tyler January 22, 2013, 2:40 pm

    I read the entire article and thought I understood it, it seemed really quite simple. I followed the instructions exactly, but as per the first comments, the result was that the server would not accept connections, and I had to go to the console and restart iptables so that the new rules were removed.

    Can someone please explain what we’re doing wrong?

  • leif February 21, 2013, 1:24 pm

    Also smart to stop the logging in /va/log/messages.
    kern.warning /var/log/custom.log
    kern.warning ~
    *.* /var/log/messages

  • Simon Turner March 4, 2013, 5:39 am

    I think the confusion is because of the statement “If you already have whole bunch of iptables firewall rules, add these at the bottom, which will log all the dropped input packets”. The (unstated) implication is that you already have a whole bunch of rules that ACCEPT connections, and so the suggested rules will log and drop *whatever is left*. That’s why it says “All the remaining incoming packets will jump to the LOGGING chain”. Of course if you only have existing rules that DROP connections (or no rules at all) then the net effect is to DROP everything (!).

  • dj March 14, 2013, 9:25 am

    @ Simon Turner

    Or when you have default policy DROP in INPUT chain (like i do)
    I did the same stupidity without thinkind and now my server is down for 30 minutes (i have a cron job to reset iptables to the working one once an hour)

    i think will be better to specify this in article.
    It only works when the default policy is accept.
    You have some accept rule and this logging rule acts also as DROP everything else is not covered in rules.

  • greanie April 19, 2013, 5:08 am

    Can you log other things besides just dropped packets?

  • pacus December 31, 2013, 6:41 am

    I had to reset the server too, please modify the article or alert people.

  • Mohammad February 26, 2014, 4:31 pm

    Hi, I have a question. Could we log packets which are dropped because of forwarding queue is filled (e.g in congestion time)? How do I perform this work?
    Regards Mohammad.

  • Tyler Gillispie March 21, 2014, 4:50 pm

    My default policy for the INPUT chain is DROP. I ran the four commands to log all dropped packets from the INPUT chain. Dropped packets are now being logged.

    Thank you!

    One hint that may help others. Make sure the firewall rules are working rather than just accepting everything. List the rules and make sure pkts are actually hitting any rules in place.

    iptables -L –line-number -v

  • Jan June 2, 2014, 5:05 am

    I need to measure iptables’ latency.

    My question is: what tools are there to use in order to measure iptables latency (delay when it processes different volumes of traffic) in Linux Debian?

    Is this done before? If yes, can you please help me find the results of the measurement or similar project results?

  • Anes P A June 21, 2014, 8:26 am

    I need a fast reply from you , this for my lab exam on Tuesday(Coming) . I tried the 4th
    command as above
    iptables -A LOGGING -m limit –limit 2/min -j LOG –log-prefix “IPTables-Dropped: ” –log-level 4

    but show message as “iptables v1.4.12: no command specified . Try iptables -h or iptables –help for more information” on my ubuntu.

    Please advise whats wrong with me


  • Anuprasad September 10, 2014, 8:40 am

    my UDP drop rule says 780 packets dropped on iptables -vnL output with only single drop rule. But all input log rule shows only 8 packets why ?

  • Jason Eten February 6, 2015, 6:39 am

    Could you mention which kernel modules are required for logging?

  • chovy February 26, 2016, 2:26 am

    For some reason on Ubuntu 14.04 I don’t have a /var/log/messages file

    not sure where these log statements are going.

  • chovy February 26, 2016, 3:09 am

    Ok, I see it should be in /var/log/kern.log — but I don’t see any dropped packets being logged (on VPS).

  • Balo March 24, 2017, 7:56 pm

    Hi, I set logging for All Dropped Input Packets according to your example and I have noticed this in log: IPTables-Dropped: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:04:2e:58:47:ch:08:00 SRC= DST= LEN=334 TOS=0x00 PREC=0x00 TTL=128 ID=24675 PROTO=UDP SPT=68 DPT=67 LEN=314

    Any idea what is causing this (what is being blocked)? Thanks.