Re: prefix len confusion

On Wed, 10 Jun 2026, at 2:01 AM, Randy Bush wrote:
>>> 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.

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. 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". If you see no output whatsoever, even at a time when packets are definitely being sent to 42.642.11.82:22 then the packets are not passing through the nftables box to begin with. If you do see output, study it, for it will conclusively show how the packets traverse your ruleset and why they are being accepted.

--
Kerin Millar