netdev - ESTABLISHED tcp conntrack timeout

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CANpxKHGdbN6UYTw=r=r9=usZ3taX05ARpnAQ_StF4Zikcpp5WA@mail.gmail.com>
Date:   Wed, 10 Apr 2019 17:47:35 +0700
From:   Naruto Nguyen <narutonguyen2018@...il.com>
To:     netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
        netfilter@...r.kernel.org
Subject: ESTABLISHED tcp conntrack timeout

Hello everyone,

When duplicating tcp conntrack from main name space to another network
namespace, I see that sometimes timeout value for an established tcp
connection in another network namespace has been changed from 432000
to 300 like below, even it is in ASSURED

03:05:53.773
tcp      6 300 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:05:56.018
tcp      6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:05:58.267
tcp      6 300 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:06:00.511
tcp      6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:06:02.767
tcp      6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:06:05.024
tcp      6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:06:07.318
tcp      6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:06:09.578
tcp      6 431999 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:06:11.833
tcp      6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:06:14.082
tcp      6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:06:16.315
tcp      6 299 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:06:25.314
tcp      6 431999 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:06:27.571
tcp      6 431999 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:06:29.815
tcp      6 431999 ESTABLISHED src=10.172.1.6 dst=11.35.4.5 sport=70752
dport=7050 src=11.35.4.5 dst=10.172.1.6 sport=7050 dport=70752
[ASSURED] mark=0 use=1
03:06:32.065

In nf_conntrack_proto_tcp.c, I see that 2 constants have 5 mins set

[TCP_CONNTRACK_RETRANS] = 5 MINS,
[TCP_CONNTRACK_UNACK] = 5 MINS,

and the code

if (ct->proto.tcp.retrans >= tn->tcp_max_retrans &&
       timeouts[new_state] > timeouts[TCP_CONNTRACK_RETRANS])
       timeout = timeouts[TCP_CONNTRACK_RETRANS];
else if ((ct->proto.tcp.seen[0].flags | ct->proto.tcp.seen[1].flags) &
       IP_CT_TCP_FLAG_DATA_UNACKNOWLEDGED &&
       timeouts[new_state] > timeouts[TCP_CONNTRACK_UNACK])
       timeout = timeouts[TCP_CONNTRACK_UNACK];
else
       timeout = timeouts[new_state];

but I am not sure this code cause the above issue. For the second
TCP_CONNTRACK_UNACK, it only happens for [UNREPLIED] instead of
[ASSURED]. Could you please let me know how the time out value can be
changed for an established tcp connection and how to prevent this
change?

Thanks,
Brs,
Naruto