Altering the default (built in) firewall rule set


I am a big fan of the firewall package as it makes my life simple. However I would like to alter some of the built in rules, namely:

-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT

I would like it to turn into:

-A FORWARD -m conntrack --ctstate ESTABLISHED -m comment --comment "!fw3" -j ACCEPT

In short I want to block the packets netfilter considers to be "related" to existing connections.

I am aware of what this does exactly and of possible problems I can run into because of it and it still is important for me to do it.

I couldn't find the default rules in any config files, I eventually managed to find them hardcoded in defaults.c file in firewall package source code. I would rather not compile my own version if possible, what are my solutions? It is important to me that packets deemed to be "related" are not being let through no matter how small the time window would be.

So far I tried putting those two rules in my /etc/firewall.user:

iptables -D FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT

This however does NOT work on boot for some reason. If I execute /etc/firewall.user or /etc/init.d/firewall restart manually it works, but only till reboot. I put this in firewall.user for debugging purposes:

iptables -S > /tmp/iptables_check
iptables -D FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT

and I can confirm that the rule is present during the execution of firewall.user:

root@OpenWRT:~# grep RELATED,ESTABLISHED /tmp/iptables_check | grep FORWARD
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT

How can I fix my firewall.user so the rule does get deleted or what else can I do so the RELATED packets get dropped? Should I just compile my own version?

uci set firewall.@include[0].reload="1"
uci commit firewall
service firewall restart
1 Like

Thanks, this made it better, but not ideal. First of all, would you mind telling me where I can read about what this does exactly, as in technical details? I searched for a bit before asking this question and couldn't find anything like this.

The rules from firewall.user do get added on boot now. However here is why it is not ideal:

  • for whatever reason the firewall.user script gets executed three times on boot only (when restarting firewall manually it only gets executed once as it should); this can make it awkward to work with more complex rules (or ones that are supposed to modify existing chains); this is a lesser issue I could probably live with
  • there is a small window when the firewall loaded all its default rules and the rules from /etc/config/firewall but has not yet processed firewall.user file; when restarting the firewall manually that window is extremely short (but still there), when flooding packets (sending a packet every 0.1 ms or less) I manage to squeeze one through every hundred firewall restarts or so; HOWEVER, during the boot time that window is much longer (50-100ms) and that is a problem for me:

I am trying to use this OpenWRT device as a very restrictive firewall. All the users behind it should be able to only exchange IP traffic with only one external device. That means packets from and to only one IP should be let through and nothing else, ever, even for a very very short time. As of now a malicious user can flood packets with low TTL to the address they are allowed to connect to and there is a small chance he will receive a reply from one of the hops during that short window when the the rule allowing RELATED packets hasn't got deleted yet.

I figured I could either build the firewall from source on my own and get rid of the RELATED part, or alternatively I could write my own init.d script that sleeps for few seconds and adds the (allow) FORWARD (to desired device) rule only after it made sure the RELATED rule got deleted from the chain. So this is not a hopeless situation. But I am still wondering if it is possible to do with the default configuration.

EDIT: found it
reload boolean no 0 Specifies whether the include should be called on reload - this is only needed if the include injects rules into internal chains
I do not really understand it though. This option should only apply on reloads, from what I understand firewall.user rules should apply on boot too even without it (and the file gets executed, just the rules don't seem to get deleted/added). I also don't understand why does it gets executed three times on boot.
I can also confirm that this is incorrect:

:!: If the rule exists in iptables, it will not be re-added. A standard iptables -I or -A will add a duplicate rule.
As I will have the same -A ppended rule added three times after boot (again, gets cleaned up on manual reload)

1 Like

Should've searched harder. Thank you. EDIT: I would've marked it as a solution but it technically isn't, as of now I believe it is not possible (without compiling from source) not to have the firewall setting the ESTABLISHED,RELATED -j ACCEPT rule as it is hardcoded in unconditionally. You cleared things out for me though so thank you again!

Incidentally, this is quite possibly why I was having unexpected behavior when I was trying to open up certain ports.

Once again, @vgaetera to the rescue. Moral of the story:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.