linux-kernel - Re: [PATCH] tcp: Add listening address to SYN flood message

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: <Y20Bxc1gQ8nrFsvA@lunn.ch>
Date:   Thu, 10 Nov 2022 14:51:01 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Jamie Bainbridge <jamie.bainbridge@...il.com>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        David Ahern <dsahern@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tcp: Add listening address to SYN flood message

On Thu, Nov 10, 2022 at 09:21:06PM +1100, Jamie Bainbridge wrote:
> The SYN flood message prints the listening port number, but on a system
> with many processes bound to the same port on different IPs, it's
> impossible to tell which socket is the problem.
> 
> Add the listen IP address to the SYN flood message. It might have been
> nicer to print the address first, but decades of monitoring tools are
> watching for the string "SYN flooding on port" so don't break that.
> 
> Tested with each protcol's "any" address and a host address:
> 
>  Possible SYN flooding on port 9001. IP 0.0.0.0.
>  Possible SYN flooding on port 9001. IP 127.0.0.1.
>  Possible SYN flooding on port 9001. IP ::.
>  Possible SYN flooding on port 9001. IP fc00::1.
> 
> Signed-off-by: Jamie Bainbridge <jamie.bainbridge@...il.com>
> ---
>  net/ipv4/tcp_input.c | 16 +++++++++++++---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 0640453fce54b6daae0861d948f3db075830daf6..fb86056732266fedc8ad574bbf799dbdd7a425a3 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -6831,9 +6831,19 @@ static bool tcp_syn_flood_action(const struct sock *sk, const char *proto)
>  		__NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPREQQFULLDROP);
>  
>  	if (!queue->synflood_warned && syncookies != 2 &&
> -	    xchg(&queue->synflood_warned, 1) == 0)
> -		net_info_ratelimited("%s: Possible SYN flooding on port %d. %s.  Check SNMP counters.\n",
> -				     proto, sk->sk_num, msg);
> +	    xchg(&queue->synflood_warned, 1) == 0) {
> +#if IS_ENABLED(CONFIG_IPV6)
> +		if (sk->sk_family == AF_INET6) {

Can the IS_ENABLED() go inside the if? You get better build testing
that way.

     Andrew