Page MenuHomePhabricator

Disable conntrack helper?
Open, NormalPublic

Description

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:

  • test this for a while and see if anything major breaks
  • disable nf_conntrack_helper

Details

Impact
Normal

Event Timeline

Patrick created this task.Mar 28 2016, 3:12 PM

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.

tcp-timestamps-disable
Reverse Depends:

anon-shared-packages-dependencies

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:

https://github.com/Whonix/anon-meta-packages/blob/9bf7e5764d80bc449de285552acb2c33b839aa15/debian/control#L23

In T486#8529, @HulaHoop wrote:

I formatted debian/control to follow packaging rules but the formatting looks ugly in the README.

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.

Patrick changed the task status from Open to Review.Mar 31 2016, 5:56 PM

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.


Patrick changed the task status from Review to Open.Apr 21 2016, 8:10 PM

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?

HulaHoop added a comment.EditedApr 22 2016, 5:51 PM

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 .

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.

Patrick updated the task description. (Show Details)Jun 3 2016, 11:11 PM

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}"
In T486#11057, @Patrick wrote:

I don't know what to think of this which warns of conntrack... https://lists.torproject.org/pipermail/tor-talk/2016-December/042717.html

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.

Patrick changed the task status from Review to Open.Mar 7 2018, 12:51 AM
Patrick edited projects, added Whonix 15; removed Whonix 14.