On 2018.08.14 22:39 Roman Mamedov wrote: > On Tue, 14 Aug 2018 15:19:27 -0700 > "Doug Smythies" <dsmythies@xxxxxxxxx> wrote: ...[snip]... > Here is the difference. Your script: > > $IPTABLES -A INPUT -i $EXTIF -p tcp -m conntrack --ctstate INVALID -j DROP > $IPTABLES -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP > $IPTABLES -A INPUT -i $EXTIF -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT > $IPTABLES -A INPUT -i $EXTIF -p tcp -m conntrack --ctstate NEW --dport 22 -j ACCEPT > > It seems that if the kernel now empties the conntrack table due to no > conntrack rules in iptables, with such a ruleset there will be no record for > your SSH connection, so it can't continue, unless initiated again (NEW) > specifically as a new connection (--syn). You can check if that's indeed the > case by comparing contents of "/proc/net/nf_conntrack" before and after reset. I do not have a file "/proc/net/nf_conntrack". If you are referring to examining the conntrack table without using the conntrack tool, I used to love the old way of using "/proc/net/ip_conntrack", but that disappeared about 3 years ago. During this investigation I have made extensive use of the conntrack tool, and things seems confused (or I am confused). I just assumed that since these recent changes, the conntrack tool is broken. However, I never see the table as empty. Example 1 rule set in place: doug@s17:~$ sudo conntrack -L | grep 192.168.111.101 [sudo] password for doug: conntrack v1.4.4 (conntrack-tools): 5 flow entries have been shown. tcp 6 431954 ESTABLISHED src=192.168.111.120 dst=192.168.111.101 sport=22 dport=57260 src=192.168.111.101 dst=192.168.111.120 sport=57260 dport=22 [ASSURED] mark=0 use=1 tcp 6 431698 ESTABLISHED src=192.168.111.101 dst=192.168.111.120 sport=61110 dport=22 src=192.168.111.120 dst=192.168.111.101 sport=22 dport=61110 [ASSURED] mark=0 use=1 tcp 6 430591 ESTABLISHED src=192.168.111.101 dst=192.168.111.120 sport=57599 dport=22 src=192.168.111.120 dst=192.168.111.101 sport=22 dport=57599 [ASSURED] mark=0 use=1 tcp 6 431839 ESTABLISHED src=192.168.111.101 dst=192.168.111.120 sport=65240 dport=22 src=192.168.111.120 dst=192.168.111.101 sport=22 dport=65240 [ASSURED] mark=0 use=1 tcp 6 299 ESTABLISHED src=192.168.111.101 dst=192.168.111.120 sport=65278 dport=22 src=192.168.111.120 dst=192.168.111.101 sport=22 dport=65278 [ASSURED] mark=0 use=1 I see one entry at 299 seconds, but think it should be more like 5 days. And I see one entry that I think is backwards. While 5 sessions are shown, only 3 are actually working at the moment. Two got dropped recently. Example 2: no rule set: doug@s17:~$ sudo conntrack -L | grep 192.168.111.101 conntrack v1.4.4 (conntrack-tools): 5 flow entries have been shown. tcp 6 431821 ESTABLISHED src=192.168.111.120 dst=192.168.111.101 sport=22 dport=57260 src=192.168.111.101 dst=192.168.111.120 sport=57260 dport=22 [ASSURED] mark=0 use=1 tcp 6 431361 ESTABLISHED src=192.168.111.101 dst=192.168.111.120 sport=61110 dport=22 src=192.168.111.120 dst=192.168.111.101 sport=22 dport=61110 [ASSURED] mark=0 use=1 tcp 6 431978 ESTABLISHED src=192.168.111.101 dst=192.168.111.120 sport=57599 dport=22 src=192.168.111.120 dst=192.168.111.101 sport=22 dport=57599 [ASSURED] mark=0 use=1 tcp 6 431501 ESTABLISHED src=192.168.111.101 dst=192.168.111.120 sport=65240 dport=22 src=192.168.111.120 dst=192.168.111.101 sport=22 dport=65240 [ASSURED] mark=0 use=1 tcp 6 431817 ESTABLISHED src=192.168.111.101 dst=192.168.111.120 sport=65278 dport=22 src=192.168.111.120 dst=192.168.111.101 sport=22 dport=65278 [ASSURED] mark=0 use=1 > And here's why it still works for me. In my case the rules are just: > > -A INPUT -m state --state INVALID -j DROP > -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT > -A INPUT -p tcp -m set --match-set myipv4 src -m tcp --dport 22 -j ACCEPT > > (the ipset part should be irrelevant) > > I accept everything to port 22, without involving -m conntrack. Personally I > prefer the firewall to be as stateless as possible (and switched to fully > stateless on several machines, at least on the IPv6 side). I thought "-m state" (which is what I always used until now) was just an alias for "-m conntrack". Regardless, "-m state" doesn't work for me now (iptables version 1.6.1-2ubuntu2). > Is there a significant reason for filtering it as strictly as in your example, > e.g. what kind of threats the more strict rules are preventing that mine don't? It is simply the simplest version of a rule set that I could come up with to demonstrate the issue, and is in no way representative of my real iptables rule set. ... Doug
