Posted: Sat Jan 17, 2026 22:11 Post subject: iptables policy left as default
Why is the default iptables policy left to default ACCEPT? Isn't this a security risk?
I see at least two issues:
- problems during development - due to a bug it might incorrectly apply the rules and leave a security hole. Yes it might get detected in time, but until then? (MINOR)
- applying configuration - when the iptables configuration is reset all existing rules are cleaned first, then the new rules are applied; in the meantime the default policy applies. The setup might not be functional but it might be enough for a network scan from the wan. (MAJOR)
Joined: 08 May 2018 Posts: 16758 Location: Texas, USA
Posted: Sat Jan 17, 2026 22:37 Post subject:
I'm sure you could read the entire document, but that's been the default in Linux firewall policy, especially for NAT and masquerade since (before) the Linux 2.4 kernel:
I'm not so sure about "split-fraction-of-a-second", if you try to list the rules during configuration change (after you push save & apply) it takes seconds when you see the tables are empty (having only the default policy in place). _________________ Router: Netgear R7800
Joined: 16 Nov 2015 Posts: 7090 Location: UK, London, just across the river..
Posted: Sun Jan 18, 2026 8:23 Post subject:
kernel-panic69 wrote:
It would be great to see the output of what you're referring to. This is also where we could state that using save & apply while changing anything firewall-related is probably user-induced risk.
yep i second that..i always use save and reboot...instead...and sometimes it sucks as i have to wait 4-5 min to have all my rules set...
Of course save & apply not always rebuilds firewall rules, only in cases when there are changes regarding/related firewall so, yes there are situations when save & apply is needed...and its does not reset the firewall...in those cases everything is block....
will be nice to see the output...anyway... _________________ Atheros
TP-Link WR1043NDv2 -DD-WRT 62606 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 -DD-WRT 63600 GTW/SmDNS/DoT,AD-Blk,Forced DNS,AP&Net Isolation,x2VLAN,Vanilla
Netgear R7800 --DD-WRT 62606 Gateway/DNSCryptv2,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla,VPN cli
Netgear R9000 --DD-WRT 62606 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Dynalink DL-WRX36-DDWRT 62606
Broadcom
Netgear R7000 --DD-WRT 63600 GTW/DNScrypt-proxy2/AD-Block,IPset Firewall,Forced DNS,x4VLAN,VPN cli
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
You should never see this while applying rules, but you do. And the fix is trivial, just change the default policy to DROP to the main filtering tables.
Applying a new configuration involves a risk of the setup not working (ex. clients not being able to access the internet), but should never imply a security risk. IMO, it's unacceptable for a single packet to escape from the WAN into the LAN.
BTW, changing the default policy to DROP is a known best practice. _________________ Router: Netgear R7800
Last edited by arpadf78 on Sun Jan 18, 2026 10:38; edited 1 time in total
Just to make this evident, I just tried pinging a host inside the LAN (192.168.6.0/24) from the WAN (192.168.3.0/24). Of course I added a route to 192.168.6.0 via WAN interface (192.168.3.2)
I started this in the WAN:
Code:
ping -c 20 192.168.6.5
then, hit Save & Apply in the router. Got this:
Code:
PING 192.168.6.5 (192.168.6.5): 56 data bytes
64 bytes from 192.168.6.5: seq=9 ttl=63 time=28.430 ms
--- 192.168.6.5 ping statistics ---
20 packets transmitted, 1 packets received, 95% packet loss
round-trip min/avg/max = 28.430/28.430/28.430 ms
