How to prevent iptables from counting bytes and packets on empty chains

iptableskernel-modules

Background

I occasionally have firewall rules that I need to use for maintenance windows, but don't want active (and therefore consuming CPU cycles or slowing the network interface) the rest of the time. I add the rules when I need them, and then want to wipe the slate clean and stop iptables from counting packets and bytes flowing through the filter chains.

Problem: Filter Table Keeps Counting Anyway

The first time I check iptables in verbose mode, packet and byte counts are
always zero. For example:

$ sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

However, once the filter table has been initialized, flushing the table or resetting the counters doesn't stop the table from continuing to count packets and bytes. For example:

$ sudo iptables -F; sleep 5; sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 395 packets, 577K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 199 packets, 11135 bytes)
 pkts bytes target     prot opt in     out     source               destination

Current Solution

While I suspect that the actual CPU usage isn't all that high for an empty table, it seems wasteful to have the kernel inspect packets or count bytes that I don't care about. In order to prevent the filter table from consuming CPU cycles when there are no active rules, I've been doing the following:

$ sudo iptables -F; sudo iptables -X; sudo modprobe -r iptable_filter

This removes the rules and the filter table, allowing the iptables filter module to be removed from the running kernel. Once I do that, then counters remain zeroed until I once again initialize the table.

The Actual Question

My two-part question is:

Whether the counters for empty chains even have a measurable impact on performance. Intuitively, it seems like they would on a busy network interface, but I have no idea how to measure whether the impact exists.
Assuming there is an impact, whether there's a more elegant way to stop iptables from counting bytes/packets on empty chains than unloading the related kernel modules.

Best Answer

You can't unless you patch the kernel. And you have better things to do.

The counters are incremented __nf_ct_refresh_acct if the parameter do_acct is nonzero. This function is called through two wrappers: nf_ct_refresh_acct, which increments the counters, and nf_ct_refresh, which doesn't. The choice of wrapper is made according to the protocol type: protocols that can track do, the ones that can't don't.

The amount of computation is tiny. It's just two synchronized additions. Modern processors have very deep instruction pipelines, which makes conditional instructions expensive: the processor tries to predict which branch will be taken to start executing the next few instructions before it's determined the result of the test, and if the prediction is wrong, a lot of work needs to be discarded. The additions do require synchronization between the CPUs, because all CPUs have to be updating the same counter; on typical multicore architecture, this means that the core has to lock the cache line containing the counters. If the feature was optional, the CPU would have to read the configuration value, which doesn't require exclusive access so is a little less expensive. Still it would be an extremely tiny gain, to be balanced by the slightly less tiny loss for the majority of users who want the counters. It's just not worth having an option to disable this feature.

Related Solutions

Why are packages being rejected even through there’s a rule that accepts them all before hand

The ACCEPT target is a terminating target that allows packet to get through NetFilter. The REJECT is a terminating targetd that effectively disallows packet to get through and causes the ICMP response to be sent to the packet originator. The third rule in your sample most likely looks like this if you list the tables with 'iptables -v -L' command:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  639  304K ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            
  101  7798 ACCEPT     all  --  lo     any     anywhere             anywhere

In the column in there is an interface the rule is matching on. For the third rule it is the lo interface, so this rule allows any traffic on loopback interface and this is correct, as otherwise you will not be able to access any local to the host services over TCP or UDP at localhost address.

A chain in iptables

Iptables chains are just lists of rules, processed in order. They can be one of the fixed built-in ones (INPUT, OUTPUT, FORWARD in the default filter table, some others in e.g. the nat table), or user-defined ones, which can then be called from others.

As the -A (append), -I (insert) and -D (delete) commands imply, the rules in the chains are freely editable, they're not fixed.

In the following command is INPUT the name of a chain?

Yes.

Is it a name that I can give arbitrarily?

That one isn't, it's the built-in chain that contains rules for packets entering the system (destined for processes running on the host). The other two in the default filter table are OUTPUT (packets coming from the system, obviously), and FORWARD (routed packets).

The man page iptables(8) has the descriptions of the tables and their built-in chains (under TABLES).

Of course you could place any rules for input packets in an arbitrary user-defined chain, then you'd just need to add a rule to INPUT referring to that chain. (e.g. iptables -A INPUT -j mychain would jump to mychain and process any rules there.)

Does this chain have exactly two rules?

We don't know that. Those two commands append two rules to the chain. But there might be others that were already there before those commands were run.

If you had iptables -F INPUT as the first command before those two, then the result would be that only those two rules remained.

See also: How iptables tables and chains are traversed which contain links to all you never needed to know about this, e.g. https://stuffphilwrites.com/2014/09/iptables-processing-flowchart/. (You may want to ignore the raw and mangle tables to start with, they're that often needed.)