netdev - Re: syslog spam: TCP segment has incorrect auth options set

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 4 Jan 2024 13:49:05 +0000
From: Dmitry Safonov <dima@...sta.com>
To: Christian Kujau <lists@...dbynature.de>
Cc: netdev@...r.kernel.org, Dmitry Safonov <0x7f454c46@...il.com>,
 Francesco Ruggeri <fruggeri@...sta.com>,
 Salam Noureddine <noureddine@...sta.com>, David Ahern <dsahern@...nel.org>,
 linux-kernel@...r.kernel.org
Subject: Re: syslog spam: TCP segment has incorrect auth options set

Hi Christian,

Thanks for the report,

On 1/4/24 10:55, Christian Kujau wrote:
> Ever since commit 2717b5adea9e ("net/tcp: Add tcp_hash_fail() ratelimited 
> logs") the following is printed, in waves of small floods, to syslog:
> 
>  kernel: TCP: TCP segment has incorrect auth options set for XX.20.239.12.54681->XX.XX.90.103.80 [S]
> 
> This host is connected to the open internet and serves as a small HTTP and 
> SSH login server, not much traffic is happening here. So I'd assume these 
> messages to be the result of random internet scans and/or fingerprinting 
> attempts or the like. While not really a concern, these messages are 
> flooding the dmesg buffer over time :-(
> 
> Is there a way to adjust the severity of these messages?
> 
> * In include/net/tcp.h this gets logged with tcp_hash_fail(), which is
> * defined in include/net/tcp_ao.h and calls net_info_ratelimited(), which
> * is in turn defined in include/linux/net.h and calls pr_info().
> 
> Can e.g. net_dbg_ratelimited be used instead?

Yeah, I guess it's possible to down the severity of these logs, but may
be unexpected by admins: TCP-MD5 messages existed for long time and
there may be userspace that expects them (i.e. in arista there are tests
that look for these specific messages - those would be easy to fix, but
there may be others outside this company).

While thinking on the origin of your issue, it seems that the logs
produced by either TCP-MD5 or TCP-AO are desired by a user when they
add/use the authentication. Could you try this and see if that solves
the issue for you?

https://lore.kernel.org/all/20240104-tcp_hash_fail-logs-v1-1-ff3e1f6f9e72@arista.com/

Thanks,
             Dmitry