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]
Message-ID: <fe1752a6-9866-45e6-b011-92a242304fce@arista.com>
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ