On 08/19/2015 02:01 PM, Victor Julien wrote: > On 08/19/2015 06:53 PM, Dick Hollenbeck wrote: >> On 08/19/2015 07:50 AM, Victor Julien wrote: >>> On 08/18/2015 02:12 PM, Dick Hollenbeck wrote: >>>> This is still a problem as of 18-August-2015: >>>> >>>> http://vuurmuur-users.narkive.com/1W0jUSnb/existing-ssh-session-being-killed-during-rule-application >>>> >>>> I loaded nf_conntrack_ipv4 ahead of time, even logged out and back in, >>>> then did the >>>> vuurmuur startup and it killed my ssh connection. >>>> >>>> This makes the vuurmuur package unusable. If there is no remedy soon >>>> we'll have to remove >>>> this package from our embedded distro. >>>> >>>> >>>> # vuurmuur -V >>>> Vuurmuur 0.8rc1 (using libvuurmuur 0.8rc1) >>>> >>>> Again, its such a disagreeable behaviour that it makes the package >>>> unusable. >>>> >>> >>> I wonder what a good solution would be. For example, when you log in >>> over SSH you can get a env var: >>> >>> SSH_CONNECTION=192.168.1.3 34790 192.168.1.1 22 >>> >>> If you're willing to trust this env var, you could have the init script >>> do a work around. E.g. add a rule for that tulpe, or maybe add the >>> conntrack entry manually using the conntrack tool. >>> >>> However, this won't work in all cases. For example sudo strips this env >>> var away. >>> >>> I guess another way would be to have the interface define a 'management' >>> ip (or port) that operates outside of the conntrack rules (in the raw >>> table perhaps). >>> >>> Suggestions and/or patches are welcome. >> >> Victor, >> >> It is useful to experiment outside vuurmuur using iptables-restore and a >> given set of >> rules that can be tested. Here is the most simple rules file that keeps SSH >> alive during >> the operation: >> >> # iptables-restore < rules.txt >> >> >> -----<rules.txt>---------------------------- >> >> # Generated by iptables-save v1.4.17 on Wed Aug 19 10:32:04 2015 >> *filter >> :INPUT DROP [14:2577] >> :FORWARD DROP [0:0] >> :OUTPUT ACCEPT [0:0] >> -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT >> #-A INPUT -p tcp --dport ssh -j ACCEPT >> COMMIT >> >> >> -----</rules.txt>--------------------------- >> >> >> >> Observations: >> >> 1) if OUTPUT policy is DROP rather than ACCEPT, then another rule is needed >> for that chain. >> >> 2) Your chains have policy DROP, (but you knew that). >> >> 3) the FLUSH commands will kill any TCP connections instantaneously, and are >> probably the >> cause of the problem. I think this even trumps the ESTABLISHED rules that >> come later. >> Search this page for "FLUSH is dangerous": >> http://www.cyberciti.biz/faq/ubuntu-start-stop-iptables-service/ > > The flush thing is irrelevant. Even though 'vuurmuur -b' may show it, > it's not used using regular operations. There 'iptables-restore' is > used, which performs an atomic swap of the rulesets. This will not kill > existing connections already tracked by conntrack through a previous > ruleset. However ... > > ... in the 0.8 branch I made a change to the way conntracking is > handled. Normal connections, that are set up and accepted by 'ACCEPT' > rules (as opposed to NFQUEUE rules) are all tagged with the connmark > 0x1. NFQUEUE based connections use marks > 2. (2 itself is used for the > obsolete QUEUE target) > > This leaves the startup case unhandled. In the startup case, when there > is no previous ruleset, any connection in conntrack will have connmark > 0. This means that no ESTABLISHED/RELATED rule is going to allow for > this connection to continue. > > I guess adding a ESTABLISHED ACCEPT rule for connmark 0 would work here. > I will think a bit longer about possible side effects. > > Still this would only address those cases where conntrack was already > active and tracking the ssh connection (with mark 0). If this is not the > case, the connection will appear to be invalid to vuurmuur, as it's NEW > state is midsteam. In other words, no syn packets or full 3whs at state NEW. > > For this I guess the only way would be to have a special rule, something > like: ctstate NEW, no syn packet, tcp (src|dst) port 22 => set connmark > 1 and ACCEPT (the rest of the connection will then be handled normally > because of the connmark). > > Ideally such a hack/workaround would have a time limit, and/or limits to > ip addresses it applies to, as it bypasses some meaningful checks (state > NEW requiring SYN packets) > > > To confirm this idea, one useful test could be to ssh to your box, load > conntrack, use the conntrack tool to set the connmark on your ssh > connection to 1, then start vuurmuur. If I'm not mistaken, your > connection will stay 'up'. > > Regards, > Victor
after rebooting: # modprobe nf_conntrack_ipv4 # conntrack -U -m 1 # /etc/init.d/vuurmuur.sh start worked. ------------------------------------------------------------------------------ _______________________________________________ Vuurmuur-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/vuurmuur-users
