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 ------------------------------------------------------------------------------ _______________________________________________ Vuurmuur-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/vuurmuur-users
