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=192.168.1.23 DST=192.168.1.20 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=192.168.2.115 DST=192.168.1.23 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
- Linux Firewall Tutorial: IPTables Tables, Chains, Rules Fundamentals
- Linux IPTables: How to Add Firewall Rules (With Allow SSH Example)
- Linux IPTables: Incoming and Outgoing Rule Examples (SSH and HTTP)
- IPTables Flush: Delete / Remove All Rules On RedHat and CentOS Linux
- 25 Most Frequently Used Linux IPTables Rules Examples
Linux provides several powerful administrative tools and utilities which will help you to manage your systems effectively. If you don’t know what these tools are and how to use them, you could be spending lot of time trying to perform even the basic administrative tasks. The focus of this course is to help you understand system administration tools, which will help you to become an effective Linux system administrator.Get the Linux Sysadmin Course Now!
If you enjoyed this article, you might also like..
|
|
|
|






My name is Ramesh Natarajan. I will be posting instruction guides, how-to, troubleshooting tips and tricks on Linux, database, hardware, security and web. My focus is to write articles that will either teach you or help you resolve a problem. Read more about
{ 12 comments… read them below or add one }
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.
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=127.0.0.1 DST=127.0.0.1 LEN=44 TOS=0×00 PREC=0×00 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.
Hi,
Thanks a lot….
Very helpful,
thanks
the first 3 comments were from people who didn’t read and understand the entire article.
good info.
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
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.
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?
Also smart to stop the logging in /va/log/messages.
kern.warning /var/log/custom.log
kern.warning ~
*.* /var/log/messages
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 (!).
@ 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.
Can you log other things besides just dropped packets?