Help/guidance with automatic CT helper assignment

Help/guidance with automatic CT helper assignment

[Mauro Santos]

Hello,

I'm running linux 4.10.8 and I am aware that automatic connection
tracker loading has been disabled by default for security reasons.

I'm currently seeing:

nf_conntrack: default automatic helper assignment has been turned off
for security reasons and CT-based  firewall rule not found. Use the
iptables CT target to attach helpers instead.

in my kernel logs, which is to be expected to some degree I suppose.

What I would like some help/guidance with is finding out what is causing
this, that is, finding out which program would cause an automatic helper
to be loaded if automatic loading was enabled.

I have currently setup two helpers, one for ftp and one for pptp (which
pulls the gre helper if I'm not mistaken). These two helpers have been
added with:
iptables -t raw -A OUTPUT -p tcp --dport 21 -j CT --helper ftp
iptables -t raw -A OUTPUT -p tcp --dport 1723 -j CT --helper pptp

I have tried monitoring incoming and outgoing connections with source
and destination ports that the other helpers should work with (I've
taken the list from here http://www.shorewall.net/Helpers.html) but the
timestamps of the messages (ports log and nf_conntrack message) are too
far for me to believe I'm catching what is causing this.

Short of logging everything in bulk, is there anything else I can try to
catch the culprit? I'd like to avoid logging in bulk because I have not
found a way to trigger this on demand and sometimes I see the
nf_conntrack message several hours after boot, which would make for huge
logs with normal machine usage (youtube, video calls, etc).

-- 
Mauro Santos

Re: Help/guidance with automatic CT helper assignment

[Noel Kuntze]

[-- Attachment #1.1: Type: text/plain, Size: 2061 bytes --]

Hello Mauro,

On 10.04.2017 23:22, Mauro Santos wrote:
> Hello,
> 
> I'm running linux 4.10.8 and I am aware that automatic connection
> tracker loading has been disabled by default for security reasons.
> 
s/loading/assignment/

> 
> What I would like some help/guidance with is finding out what is causing
> this, that is, finding out which program would cause an automatic helper
> to be loaded if automatic loading was enabled.
> 
Receiving of packets of protocols (or ports) for which helpers exist, but aren't assigned.

> I have currently setup two helpers, one for ftp and one for pptp (which
> pulls the gre helper if I'm not mistaken). These two helpers have been
> added with:
> iptables -t raw -A OUTPUT -p tcp --dport 21 -j CT --helper ftp
> iptables -t raw -A OUTPUT -p tcp --dport 1723 -j CT --helper pptp
 

> I have tried monitoring incoming and outgoing connections with source
> and destination ports that the other helpers should work with (I've
> taken the list from here http://www.shorewall.net/Helpers.html) but the
> timestamps of the messages (ports log and nf_conntrack message) are too
> far for me to believe I'm catching what is causing this.

The helpers and what packets are not handled are obviously not the same!
The two groups also do not intersect! Receiving a GRE packet can cause this message, too!

> 
> Short of logging everything in bulk, is there anything else I can try to
> catch the culprit? I'd like to avoid logging in bulk because I have not
> found a way to trigger this on demand and sometimes I see the
> nf_conntrack message several hours after boot, which would make for huge
> logs with normal machine usage (youtube, video calls, etc).

The list of conntrack helpers is limited. You don't need to log everything.
See this[1] blog article.

[1] https://home.regit.org/netfilter-en/secure-use-of-helpers/


-- 

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 866 bytes --]

Re: Help/guidance with automatic CT helper assignment

[Mauro Santos]

On 11-04-2017 11:31, Noel Kuntze wrote:
>> What I would like some help/guidance with is finding out what is causing
>> this, that is, finding out which program would cause an automatic helper
>> to be loaded if automatic loading was enabled.
>>
> Receiving of packets of protocols (or ports) for which helpers exist, but aren't assigned.

Yes you are correct, I have gotten ahead of myself. My plan is to narrow
down which packets of protocols (or ports) would trigger an automatic
assignment so that in the end I could try figure out which program is
sending those packets (that is, if this is not caused by a random port
scan).

>> I have currently setup two helpers, one for ftp and one for pptp (which
>> pulls the gre helper if I'm not mistaken). These two helpers have been
>> added with:
>> iptables -t raw -A OUTPUT -p tcp --dport 21 -j CT --helper ftp
>> iptables -t raw -A OUTPUT -p tcp --dport 1723 -j CT --helper pptp
>  
> 
>> I have tried monitoring incoming and outgoing connections with source
>> and destination ports that the other helpers should work with (I've
>> taken the list from here http://www.shorewall.net/Helpers.html) but the
>> timestamps of the messages (ports log and nf_conntrack message) are too
>> far for me to believe I'm catching what is causing this.
> 
> The helpers and what packets are not handled are obviously not the same!
> The two groups also do not intersect! Receiving a GRE packet can cause this message, too!

Then if I understand correctly I should log not only tcp/udp but also
gre (which should not be much traffic I hope). Your comment also made me
realize that I might have made a reasoning error, I have assigned the
pptp and ftp helpers for outgoing packets but I have not done the same
for incoming packets so I suppose that incoming pptp or ftp could also
trigger the message. Am I correct in this reasoning?

>> Short of logging everything in bulk, is there anything else I can try to
>> catch the culprit? I'd like to avoid logging in bulk because I have not
>> found a way to trigger this on demand and sometimes I see the
>> nf_conntrack message several hours after boot, which would make for huge
>> logs with normal machine usage (youtube, video calls, etc).
> 
> The list of conntrack helpers is limited. You don't need to log everything.
> See this[1] blog article.
> 
> [1] https://home.regit.org/netfilter-en/secure-use-of-helpers/

That is the exact page I have found when the warning/message about the
behavior change first started to show up in my kernel logs.

From the information on that page I suppose I should use the raw table
to do the monitoring and as a starting point I should monitor on the
default ports of the protocols for which there are helpers (and for the
ones I have not assigned). Is this reasoning correct or am I (still)
missing something obvious?

-- 
Mauro Santos

Re: Help/guidance with automatic CT helper assignment

[Mauro Santos]

Your comment about gre really nudged me in the right direction. After
refining my logging rules I have found that incoming tcp packets with
destination port 21 or 1723 would trigger the nf_conntrack message.

This now makes sense since I have assigned helpers for the outgoing
packets but not incoming packets.

My mistake was assuming that connection tracking helpers applied only
outgoing packets. I was also puzzled as to why udp packets with
destination port 5060 (and other default ports for protocols for which
there is a conntrack helper) would not trigger the message but I assume
that is because nf_conntrack_sip is not loaded.

-- 
Mauro Santos