cat /proc/sys/net/netfilter/nf_conntrack_helper
Reasoning:
https://mailman.boum.org/pipermail/tails-dev/2014-December/007537.html
Perhaps useful:
https://labs.riseup.net/code/issues/11391
TODO:
Very dangerous feature that allows a bunch of unsafe protocols to be parsed in the kernel when they have no business there:
https://home.regit.org/netfilter-en/secure-use-of-helpers/
Will you disable it by blacklisting the module before it loads:
modprobe nf_conntrack nf_conntrack_helper=0
or with sysctl after it loads?
echo 0 > /proc/sys/net/netfilter/nf_conntrack_helper
Not using echo, that would be a non-ideal implementation.
Probably using /etc/sysctl.d should be appropriate, well auditable,
configurable.
Found it. The sysctl.d paramter is:
net.netfilter.nf_conntrack_helper =0
I think its best if the tcp-timestamps-disable package is extended as a general hardening package for the network and its name changed to someything like "safe-networking" instead.
I am willing to change the name in every other package's depends section if there is a way enumerate them all.
Should we also disable conntrack helper in Qubes? @marmarek
I was wondering if the tcp-timestamps-disable package should be merged
into the security-misc package. Disabling conntrack helper might fit
into the security-misc package?
Should we also disable conntrack helper in Qubes?
I think so.
I was wondering if the tcp-timestamps-disable package should be merged
into the security-misc package. Disabling conntrack helper might fit
into the security-misc package?
Good idea.
I added the changes to security-misc. I formatted debian/control to follow packaging rules but the formatting looks ugly in the README.
I looked for a anon-shared-packages-dependencies metapackage to change dependencies but couldn't find it.
After these small tweaks tcp-timestamps-disable can be deleted - I can't do a pull for that.
So we should do this for #Whonix13 already? Might be doable.
Did you try enabling this setting in your Whonix VMs and host yet? Did
it cause any obvious issues?
HulaHoop (HulaHoop):
I looked for a anon-shared-packages-dependencies metapackage to change dependencies but couldn't find it.
Use grep from the Whonix source code folder.
grep --exclude-dir=.git -r tcp-timestamps-disable
It's here:
The README.md can be automatically generated from debian/control. (Also should be. Otherwise these have to be manually merged upon next run of the auto generator.)
How?
Get into Whonix folder packages/whonix-developer-meta-files
General overview. (No other documentation. Requires reading the source and it's supposed to be used by devs only.)
./debug-steps/packaging-helper-script
Readme creation.
./debug-steps/packaging-helper-script pkg_readme_creator
So we should do this for #Whonix13 already? Might be doable.
Yes its worth it.
Did you try enabling this setting in your Whonix VMs and host yet? Did
it cause any obvious issues?
Tried it with no negative effects so far.
The README.md can be automatically generated from debian/control.
I just wanted to check with you debian/control looks good.
Fixed dependencies.
Please post your links to the pull requests so everyone can keep track of them (and in case github mailer does not work).
https://github.com/Whonix/anon-meta-packages/pull/1
Fixed dependencies.
There is no point to have both anon-shared-packages-dependencies and anon-shared-packages-recommended depend on security-misc. Should just be one or the other. Otherwise if you keep enforcing the duplicate dependency we would have to do that for a lot other packages also and that does seem counter useful.
Don't copy from github web - it eats formatting such as leading spaces. If anything, copy from gitub raw, or for better security directly from local file.
Doesn't work. The file is in place.
https://github.com/Whonix/security-misc/blob/master/etc/sysctl.d/nf_conntrack_helper.conf
Yet, conntrack still is enabled!
cat /proc/sys/net/netfilter/nf_conntrack_helper
1
The config file notation net.netfilter.nf_conntrack_helper=0 vs net.netfilter.nf_conntrack_helper = 0 does not make a difference. (But as per other files in /etc/sysctl.d both formats should work.)
Any idea?
Looks like disabling the helper is more complicated because of module dependencies:
https://github.com/regit/secure-conntrack-helpers/blob/master/secure-conntrack-helpers.rst
Instructions: Disable Helper by default
Another module "nf_conntrack" has to be blacklisted in modprobe .
How to disable conntrack protocol parsing in the linux kernel?:
http://security.stackexchange.com/questions/121513/how-to-disable-conntrack-protocol-parsing-in-the-linux-kernel
Disabled for now as it needs more work.
https://github.com/Whonix/security-misc/commit/192d1e0cee505a59c5f62d01022562b12ca6646e
I am also wondering if we are chasing a ghost here. As long as we are not using --helper ftp or similar, the protocol parser code might not be used.
Also in /usr/bin/whonix_firewall we are using -m conntrack. So totally disabling conntrack may not be possible.
That explains it. If iptables rules rely on the module it will be enabled: https://serverfault.com/a/73087. Also there are tips on the web to make iptables rules more DoS resistant by disabling conntracking. Is it possible to replace these rules or are they necessary?
What I understand from Jacob's message is that by having this module enabled you expose all the code paths to malicious input.
I think blacklisting specific conntrack helpers modules should be
enough. After all we want to disable protocols parsing code, not the
conntrack itself. Also adding appropriate check to whonixcheck is a good
thing.
I don't know what to think of this which warns of conntrack... https://lists.torproject.org/pipermail/tor-talk/2016-December/042717.html
But anyhow. If less attack surface can be exposed in the kernel... Maybe we can not only get rid of conntrack helpers but also of conntrack generally.
The remaining use of conntrack in Whonix...
Whonix generally:
May not be wise to remove...
## https://lists.torproject.org/pipermail/tor-talk/2014-March/032507.html $iptables_cmd -A OUTPUT -m conntrack --ctstate INVALID -j REJECT --reject-with icmp-admin-prohibited $iptables_cmd -A OUTPUT -m state --state INVALID -j REJECT --reject-with icmp-admin-prohibited
May not be possible to remove...
$iptables_cmd -A INPUT -m state --state ESTABLISHED -j ACCEPT
Qubes-Whonix for updates proxy only:
Removing those works fine... Those both have pros and cons so hard to make a decision.
$iptables_cmd -t nat -A OUTPUT -p udp -m owner --uid-owner tinyproxy -m conntrack --ctstate NEW -j DNAT --to "127.0.0.1:${DNS_PORT_GATEWAY}"$iptables_cmd -t nat -A OUTPUT -p tcp -m owner --uid-owner tinyproxy -m conntrack --ctstate NEW -j DNAT --to "127.0.0.1:${TRANS_PORT_GATEWAY}"$iptables_cmd -t nat -A OUTPUT -p udp -m owner --uid-owner vm-updates -m conntrack --ctstate NEW -j DNAT --to "127.0.0.1:${DNS_PORT_GATEWAY}"$iptables_cmd -t nat -A OUTPUT -p tcp -m owner --uid-owner vm-updates -m conntrack --ctstate NEW -j DNAT --to "127.0.0.1:${TRANS_PORT_GATEWAY}"I think it's a wrong link.
But anyhow. If less attack surface can be exposed in the kernel... Maybe we can not only get rid of conntrack helpers but also of conntrack generally.
Doesn't NAT use conntrack too?
May not be possible to remove...
$iptables_cmd -A INPUT -m state --state ESTABLISHED -j ACCEPT
Yes, this would be hard to replace with anything else (if possible at all).
I think it's a wrong link.
True. It think Patrick meant this message which mentions conntrack.
https://lists.torproject.org/pipermail/tor-talk/2016-December/042710.html
Maybe the guy is talking about conntrack helper, which we've known to be problematic for some time now.