#20249: firewall.user is not read on reload from LuCI
---------------------------------------------+-----------------------------
Reporter: Jérôme Poulin <jeromepoulin@…> | Owner: developers
Type: defect | Status: new
Priority: highest | Milestone: Chaos Calmer
Component: packages | (trunk)
Resolution: | Version: Trunk
| Keywords:
---------------------------------------------+-----------------------------
Comment (by Jérôme Poulin <jeromepoulin@…>):
I must admit that I'm surprised. I've never been bitten by this before
because I was always using *_rule chains for my rules in firewall.user and
assumed it was executed on every restart/reload.
However, since I needed to block connections after they had gone through
the firewall, it stopped working on reload since I was inserting stuff on
top of zone_*_dest_ACCEPT and the reload was flushing this rule (the whole
chain in fact). I always try to use hook points but I had no choice this
time. Here is an example:
{{{iptables -I zone_public_dest_ACCEPT -d 192.168.0.0/16 -j
zone_public_src_REJECT}}}
Since an options to execute a script on reload exist and I didn't event
bother re-reading the firewall section of the manual before making this
ticket, it can be closed as invalid or at least lowered in priority.
As for the ''big'' security risk part, it is from the fact that I (and
maybe other users), assume this script is executed on every firewall
reload and if not testing thoroughly, the user might miss the fact that
some of its rules get wiped out in certain conditions but not on fresh
boot.
With this in mind, I would like to suggest a change to the header of
firewall.user from
{{{
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.
}}}
to
{{{
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start but
# not on reload by default.
}}}
adding the ''by default'' part would hint the user to go read how to
configure this behaviour.
--
Ticket URL: <https://dev.openwrt.org/ticket/20249#comment:3>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
