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
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
Comments on this entry are closed.
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=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.
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?
I had to reset the server too, please modify the article or alert people.
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.
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
Hi,
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?
Hi,
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
Thanks
Anes
hi
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 ?
Could you mention which kernel modules are required for logging?
For some reason on Ubuntu 14.04 I don’t have a /var/log/messages file
not sure where these log statements are going.
Ok, I see it should be in /var/log/kern.log — but I don’t see any dropped packets being logged (on VPS).
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=0.0.0.0 DST=255.255.255.255 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.