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 85B463BB48 for ; Wed, 10 Jun 2026 01:01:34 +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=1781053296; cv=none; b=FX3qdcCiLHYsc/IsPhK3KBiVHEKDyLU2a04F2HvuFp/LsV0jYU3+qyLU3jkQGAwdeYN3xrprZmx43P3IE1RCtb3EzEEPsQ4w+0tKbxnNXJbLtzrXOU/F5vbCLz61uETwiguxx7x3bgZT71jXyYMt84DCqFgXlQZvRqSq9/V9JD4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781053296; c=relaxed/simple; bh=aqIeKNNXmH/D0R0K9eh7TmGF9YBLzL4xI8atB84yYHk=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=T6GqrxLB1b5t58hrOBw8F7CohvMnzuOuCM1GMDRLcedCLRwSO2Z3LxE11N0/xN65dFwDGCW1xxq4DNNKG4xrfpJ+pNSLKwdMcf2SjySWJ152DQrDoX9ylkIGf+S5CGM73IXpxfSDWhX9OzQ1qPJrCr0GpesU1g2gRkibFboz8Ao= 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=DTK3xvW7; 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="DTK3xvW7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=psg.com; s=rgnet-mail; t=1781053293; bh=aqIeKNNXmH/D0R0K9eh7TmGF9YBLzL4xI8atB84yYHk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DTK3xvW7FXazbL6Igez1MT/t7MhYjE+rOg01W3Uwi99K4kXdeoh05IC64HO+CiKos OPzeJDTLDN94nT5SVutc0RVzPb/vsBrLE5xpn29CF+UhVmfnwFNoZEWmapm/TjRsfw R4DyEBWfstwa09gy5IoYBbnmeb/iLvtlxprWHHpCZ41T7t1g0lgVLYC34PEgut+YnN q/HtIFx794xqwer7jF35SfjqF6vVAzgWYxi9DRuNxQqdPtFNvnbQlDMFlTZ3y5/8ez XAIHLGbVYpEZVxdQyMcePAqybcO/2vne3ae0cy/aDT8Fk87Fy6SZNHmFuKr/jKf94u oqZa+uSjlR3Og== Received: from ryuu.rg.net (localhost [127.0.0.1]) by r.rg.net (Postfix) with ESMTP id 97C938027A; Wed, 10 Jun 2026 01:01:33 +0000 (UTC) Date: Tue, 09 Jun 2026 18:01:33 -0700 Message-ID: From: Randy Bush To: "Kerin Millar" Cc: netfilter@vger.kernel.org Subject: Re: prefix len confusion In-Reply-To: <7b1ed82b-3bdd-4cae-bb08-7f8479778a7a@app.fastmail.com> References: <7b1ed82b-3bdd-4cae-bb08-7f8479778a7a@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 >> tl;dr: >> o ipv4 ssh dict attacker getting through >> o i am not an nftables guru; but a few of this have stared at this >> for many days >> o do i not understand cidr prefix notation? >> >> essentially, i am seeing the traditional ssh dict attcak to >> 42.642.11.82, when i think i am filtering 42.642.11.80/30, which should >> cover 42.642.11.82 > > Getting through to where? If you mean to an instance of sshd(8) that's > running on the nftables box itself, such is to be expected because you > have no chain bearing an "input" hook. The input path is currently > wide open. > > It could also be that you're expecting your "forward" chain to cover > your proxmox guests. But if they are bridged, you may need to perform > your filtering at layer 2 instead (or also). That would entail > creating a table in the bridge family. > > table bridge filter { > chain wan-in { > type filter hook forward priority filter; > ... > } > } 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 and nothing to do with proxmox. that is a separate security boundary with its own code. > Incidentally, the iifname "lo" rule serves no purpose in your > "forward" chain and can safely be removed. thanks. i am mot sure why/where we invented that. probably some example. randy