What's new

Need feedback on proposed rule for state INVALID check in iptables

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

coldwizard

Regular Contributor
Hi

Some configurations containing multiple LAN networks (either multiple routers or a inside VPN server) are having problems with connections between the local networks and devices on the private network of the gateway router.
A fix to this problem is to completely delete the INVALID checking rule from the FORWARD chain by using a /jffs/script.
This fixes that problem, but also stops the sanity checks for possible hacking attempts, for example packet with a bad TCP flag combination.

I am trying to make a rule that gives the security check for packets from the Internet (eth0) while allowing the connection between devices on the local networks.
Although I have two routers configured to give me a LAN with multiple networks, I cannot get it to fail.
I was hoping that someone that has the problem, could run the following script manually which would put the rule back in until a reboot, but to only check packets from the Interface eth0.

Code:
#!/bin/sh
#
InsLoc1=`iptables -nvL FORWARD --lin | grep -i "INVALID" | tail -n 1 | awk '{ print $1 }'`
if [ "x$InsLoc1" == "x" ]
then
   echo "Rule INVALID not found"
   # Add rule to Drop unexpected traffic from Internet interface only
   iptables -I FORWARD 1 -i eth0 -m state --state INVALID -j DROP
   InsLoc1=1
else
   echo "rule INVALID replaced at $InsLoc1"
   # Replace rule with one changed to drop unexpected traffic from Internet interface only
   iptables -D FORWARD $InsLoc1
   iptables -I FORWARD $InsLoc1 -i eth0 -m state --state INVALID -j DROP
fi
#

Please reply with
(1) Confirm that you had to remove the rule because of the problem above.
(2) If this rule works (or not) for your connectivity tests.
(3) Any new problems caused by this rule.
(4) Ideas on anything in your configuration that may explain why I cannot duplicate the problem.
 
Thanks again for your help.

Since this seems to effect VPN connections, you may also have a tunxx interface. Thinking out loud, maybe a '! -i br0' would be better? iptables is always trial and error for me, so ignore if totally off-base...
 
...
Thinking out loud, maybe a '! -i br0' would be better?
...

My justification for not using the negative check:

My logic was to have the check only on the interface that hackers from the Internet could use. If a VPN server is configured, it's port is still on the Internet interface. To get through to the VPN interface, which will be encrypted, the hacker would need to break the encryption to get his/her packets even accepted. On the WAN interface, you also can open ports to internal machines. These may not be encrypted and become a point where the hacker can inject his poisoned packets deeper into our network.
The proposed solution also handles people who have split one or more ports off the LAN interface (We don't know anyone who would do that ;) do we? ). It also scales nicely for multiple WAN interfaces, needing only one rule per active WAN interface.
 
I remember a few years ago, while trying to track down a VPN-related issue that was tied to the dropping of INVALID packets I saw that quite a few iptables experts all over the web were questioning whether dropping packets with an INVALID state was really improving security, or just causing more issue than it was worth. In the end I chose not to remove it at the time, but this might be something worth investigating some more.

The starting point would be to determine what consists of an INVALID packet. It might not be what some people think it is. If all it does is check the packet's state in conntrack, then it's not adding much to security. INVALID might not mean "malformed" as some people think it does, but simply that it's unexpected or inconsistent with what conntrack is tracking.
 
...

The starting point would be to determine what consists of an INVALID packet. It might not be what some people think it is. If all it does is check the packet's state in conntrack, then it's not adding much to security. INVALID might not mean "malformed" as some people think it does, but simply that it's unexpected or inconsistent with what conntrack is tracking.

There was also a discussion about that time about splitting off the malformed packet check from the conntrack's connection status. I think we will see a new "state" in future versions of the conntrack module that just checks for the malformed packets. Until then we are stuck with using INVALID in the places we need the checks to stop hackers.
 
Makes sense....thanks for sharing your thought process....

Well I got my configuration to fail / work on demand.
My problem was with the order of my tests. If I tested with ping or a UDP application first, then the TCP application worked too. You have to test with TCP first which shows the failure. Everything I tried works with the new rule in place.

Anyway to maintain existing security from Internet attacks I suggest:

Replace the current rule to drop all INVALID traffic with one or two rules to drop unexpected traffic from Internet interface(s) only (one or two rules depending on dual WAN or USB WAN
iptables -I FORWARD 1 -i $IPV4Device -m state --state INVALID -j DROP

Also it seems reasonable to do the same for IPV6 and replace the rule to drop unexpected traffic from IPV6 interface(s) only.
ip6tables -I FORWARD 1 -i $IPV6Device -m state --state INVALID -j DROP

If you decide to do this as an option
(like "Enable fix for second router or VPN on LAN")
or just replace it for everyone is something worth considering.
 
I realized in responding to another thread, I never closed out on this one.

I've implemented the change to the INVALID rule to input of the active WAN port only as an option in my latest fork release Update-11 (and 11E1). It covers both IPv4 and IPv6, and can be enabled on the firewall page as 'Enable local subnet forwarding**'
 
Thank you.
 
No, thank you for your efforts. I even pointed someone to your script in the first post as a workaround when running Merlin's releases.
 
Yeap, I used this script thanks to john9527 for pointing this out to me. I use this (from post1) for my firewall-start script to fix an issue where I have two networks connected between my two houses that are about 600ft apart.

Dixit
 
The script works well, replacing the old with the new in the same place in the FORWARD chain.
Tried on my OpenVPN network TAP mode and now works my smaba servers well and can communicate with each other.
Can not se something gets droped with the new script from eth0.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top