iptables RETURN vs. DROP target

[Ralph Grothe]

Hello,

I am currently figuring out how to setup a host's firewall while it is productive (I know, bad planning) without enforcing the DROP target as default policy prematurely, until I have assured all legitimate packets are caught by my filters.

So I wonder if effectively there was a difference between

e.g.

# iptables -I OUTPUT -o \! lo -m state INVALID -j LOG --log-prefix "OUTPUT INVALID: " --log-ip-options --log-tcp-options
# iptables -I OUTPUT -o \! lo -m state INVALID -j DROP

verses

# iptables -P OUTPUT DROP
# iptables -I OUTPUT -o \! lo -m state INVALID -j LOG --log-prefix "OUTPUT INVALID: " --log-ip-options --log-tcp-options
# iptables -I OUTPUT -o \! lo -m state INVALID -j RETURN


I am asking this because the 2nd variant would ease testing rules during the debugging phase as long as the line including the default policy for OUTPUT of drop wasn't effective (i.e. not issued).
Thereby I could skip all remaining rules (especially those following with further LOG targets) because RETURN would end the OUTPUT chain and fall back to the OUTPUT's default policy (which in this phase was ACCEPT).
This I think should avoid multiple logging of packets caught by different rules with LOG target, which normally would fall through to the next rule of the chain.

[Ivan Ferreira]

>>> This I think should avoid multiple logging of packets caught by different rules with LOG target, which normally would fall through to the next rule of the chain.

If this is what you want to achieve, then you could use a "-m limit" rule to avoid excessive logging.

The -j RETURN cannot be compared with -j DROP, if you latter want to change your rules, then you can have unexpected results.

[Ralph Grothe]

Hi Ivan,

if I understand the iptables manpage correctly
the -m limit match seems to mainly cater for imposed limit rates, which isn't what I want.
But maybe the --limit-burst option could do that if I wrote

# iptables -I OUTPUT -o \! lo -m state --state INVALID -m limit --limit-burst 1 -j LOG --log-prefix "OUTPUT INVALID: " --log-ip-options --log-tcp-options

Would this limit burst number then only log a caught packet (with the same ID=) once even if it was later in the chain caught by yet another LOG targeted rule?

But on the other hand, finally when I established my rule set I would simply replace each RETURN target, immediately following a LOG targeted rule with the exactly same match criteria, by a strict DROP.
This should make any such limit burst redundant I would assume as the packet would never make it to another rule which could possibly cause multiple logging.

Yet another issue,
in the OUTPUT chain I have ACCEPTed all packets with states ESTABLISHED,RELATED.
And I only ACCEPT state NEW packets for OUTPUT for a very limited number of services such as ntp, domain or smtp request.
Nevertheless, I see lots of packets that make it through the OUTPUT chain until they hit the last rule, which is a final LOG target for everything that made it this far.
This of course is only meant for debugging purposes and will be deleted in the final stage.
I now wonder if all those packets that hit the last LOG target are really illegitimate which I can safely DROP without bother?

[Steven E. Protter]

Shalom,

This limit rates work in frames(or packets), and do not easily translate into Kb/s because they don't take into account packet size.

Seems you are reinventing the wheel here.

You might want to look at this:
http://fs-security.com
Firestarter. You can use the Motif gui as a code generator for iptables and then tweak it accordingly.

You ask>>>
I now wonder if all those packets that hit the last LOG target are really illegitimate which I can safely DROP without bother?
My answer<<<<
Yes, you can. You may be making this more complex than it needs to be.

SEP

[Ralph Grothe]

Ivan,

the limit match put me on the wrong track.
This is good for limiting throughput by packet rates.
Also the burst bucket seems to measure per time unit.
I can only imagine this match could be useful to cap the logging activity of syslogd.
But I think to have read somewhere that the kernel's netfilter module isn't hampered at all by this.

SEP,

I know that there exist a host of GUI front ends to "ease" firewall administration.
I am not particular fond of them.
Quite to the contrary, it is the plain CLI interface of iptables that is its biggest asset.
The possibility to append (-A), insert (-I), delete (-D), replace (-R) and flush (-F) chains even makes the ubiquitous iptables shell scripts pretty redundant.
Thanks to iptables-save and iptables-restore I can in a snap load or offload any formerly dumped rule set, and dump every stage instantly (pretty much like snapshots).
This I think out-powers many other firewall products.

Btw, my assumptions must have been right.
I simply added the DROP target finally as the default policy, and the app (Heartbeat clustered) still is fully functional.
Finally, I only replaced the few RETURNs by DROPs to shortcut.
It turned out that the RETURNs really can be used in this manner during debugging a rule set.

Cheers
Ralph