From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from r.rg.net (r.rg.net [198.180.152.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EE93D228CB8 for ; Wed, 10 Jun 2026 01:32:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.180.152.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781055158; cv=none; b=Zvl/4gw4SOSce0u6UCTmuNGVgYwcsY/RXHzWQlAd55Cq7BAJfml2Fi+R2XqZKIdwTOacAtw9aDI0+1cwUuoTLxqjB4pIx1qr4buGwPEVfc02jCsdvrExdUCDXxUXG50SE636FCNYLJ9uoSI1qIu+1t8qhi+SgkZSupGqRdw7v5k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781055158; c=relaxed/simple; bh=olFN4dN32Ff8i9iqq03CPhNllxdFCe3nNxQFIChvwOM=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=cxjV/tPaXkBxXOSLWXQf3kUwklFbVwT3UFizcFRL/XLqL2aHLoMWSw18Wsf6CD+cM2+qJVhbl+qTpu7SyRTK2BMrFGT33DyZmep68Hui1Dm1Rrf6PLHo8wPlHS5LNwFd6f9SoSRIQMAy3zB66j8g7QTgS1/KfK8odLn0bOwxA7A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=psg.com; spf=pass smtp.mailfrom=psg.com; dkim=pass (2048-bit key) header.d=psg.com header.i=@psg.com header.b=oaY4XVpz; arc=none smtp.client-ip=198.180.152.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=psg.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=psg.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=psg.com header.i=@psg.com header.b="oaY4XVpz" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=psg.com; s=rgnet-mail; t=1781055156; bh=olFN4dN32Ff8i9iqq03CPhNllxdFCe3nNxQFIChvwOM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oaY4XVpzS4bwyZjgXQshu1ErO7AdibevWNAxYAlw2ta7UOaUlkGHaH+TagY+uemm1 Y5e47TqZgXuMNIG/NdV690ME7ignhJxjILyQ7c/7fFvgSKtG9REB4PNkxtP/A2heQI hXDfekAS7d0lXnVRLD6JiWcvW/46UkEiSlqk/1bDdAapaO2zMU4iBUZbBGzDmXJQ85 Z2XUWsotcR4cjQ0by564fTpQufz0rqkiXKX76YpzZLFeiJ57+gValUFW2Ync9L1bH3 HKCfhv81b/sS6zRAv7Dlq8IisAigk4EKO0jYDcYk8ybpwkp7UP7JtGs98j29I6GTTv jvACUZMYSnoLg== Received: from ryuu.rg.net (localhost [127.0.0.1]) by r.rg.net (Postfix) with ESMTP id ED2D080292; Wed, 10 Jun 2026 01:32:35 +0000 (UTC) Date: Tue, 09 Jun 2026 18:32:36 -0700 Message-ID: From: Randy Bush To: "Kerin Millar" Cc: netfilter@vger.kernel.org Subject: Re: prefix len confusion In-Reply-To: <6fcf67b9-4fee-4b1c-85f1-597afff788ba@app.fastmail.com> References: <7b1ed82b-3bdd-4cae-bb08-7f8479778a7a@app.fastmail.com> <6fcf67b9-4fee-4b1c-85f1-597afff788ba@app.fastmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 Precedence: bulk X-Mailing-List: netfilter@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII >> sorry for being insufficiently explicit >> >> the ssh attacker is getting through to 42.642.11.82, which is a piece of >> hardware, not a vm. it is the ssh port of a hardware switch whose >> security profile i prefer not to expose to attackers. >> >> define VULN4 = { >> 42.642.11.34/31, >> 42.642.11.36/31, >> 42.642.11.40/29, >> 42.642.11.48/29, >> 42.642.11.80/30 # <<<==== >> } >> >> ip daddr $VULN4 drop > > In that case, the question becomes one of whether your nftables host > is responsible for forwarding packets to "42.642.11.82" (as you put > it) at all. And, just as importantly, from which source address. the nftables is on the border router. and traceroute showed the path in. the sources of the attacks are a ddos, /82 logs the ssh attack as from a jillion source addresses. > Try incorporating the following table into your existing ruleset. > > table ip raw { > chain PREROUTING { > type filter hook prerouting priority raw; > ip daddr 42.642.11.82 tcp dport 22 meta nftrace set 1 > } > } > > > Next, run "nft monitor trace". sure, if only because i will learn a new hack :) > If you do see output, study it, for it will conclusively show how the > packets traverse your ruleset and why they are being accepted. that would be lovely!! thank you. will report back. randy