prefix len confusion

prefix len confusion

[Randy Bush]

[ old dog but new to this list.  apologies for fleas ]

amd64 hardware, not vm
debian 13, very current
nftables v1.1.3 (Commodore Bullmoose #4)

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

the attack sources, at least as logged, are not within the allowed $JUMP
or other allow lists

the equivalent of this is happening in more than one pop

here is an anonymized copy of `/etc/nftables.conf`.  i hope the ip addy
mangling did not screw things up.  sorry for the length.

randy

#!/usr/sbin/nft -f

flush ruleset

define IFACE = enp4s0f1

define JUMP4 = {
    42.666.0.0/23,
    42.642.11.0/24,
    42.642.12.0/24
}

define JUMP6 = {
    2001:841:1::0/48,
    2001:841:3806::0/48,
    2001:841:8006::0/48
    }

define EXTv4 = {
    250.12.129.20/30, 
    238.224.157.204/30
}

define EXTv6 = {
    2001:841:3800:5000::20/126,
    2001:841:3800:5000::/126
}

define INTv4 = {
    42.642.11.0/24,
    250.12.129.20/30,
    238.224.157.204/30
}

define INTv6 = {
    2001:841:7830::0/48,
    2001:841:3800:5000::20/126, # NTT
    2001:841:3800:5000::/126    # NTT
}

define BOGONS4 = {
    42.642.11.0/24,
    10.0.0.0/8,
    127.0.0.0/8,
    172.16.0.0/12,
    192.168.0.0/16,
    169.254.0.0/16
}

define BOGONS6 = {
    ::/128,
    ::1/128,
    ::ffff:0:0/96,
    ::/96,
    100::/64,
    2001:10::/28,
    2001:db8::/32,
    3fff::/20,
    fc00::/7,
    fe80::/10,
    fec0::/10,
    ff00::/8
    }

define SNMP = {
    250.32.129.0/24,
    250.42.129.0/26,
    42.642.11.9,
    42.642.11.17
}

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   # <<<====
}

define PROX4 = {
    42.642.11.30/31,
    42.642.11.32/32
    }
    
define PROX6 = {
    2001:841:7830::30/127,
    2001:841:7830::32/128
    }

table ip filter {
    chain forward {
        type filter hook forward priority filter;
        iifname "lo" accept
        ip protocol icmp accept
        iifname $IFACE goto wan-in
        # so is LAN
        ip saddr $INTv4 accept
        drop
    }
    chain wan-in {
        ip saddr $BOGONS4 drop
        ip protocol icmp accept
        ip saddr $JUMP4 accept
        ip saddr $EXTv4 accept
        tcp dport 8006 ip daddr $PROX4 drop   # block proxmox web login
        ip daddr $VULN4 drop
        udp dport snmp ip saddr $SNMP accept
        tcp dport snmp ip saddr $SNMP accept
        udp dport { 111, 425, 137, 138, 139, 161, 445, 514, 515, 11211 } drop
        tcp dport { 111, 135, 137, 138, 139, 161, 445, 514, 515, 11211 } drop
        accept
    }
}

table ip6 filter {
    chain forward {
        type filter hook forward priority filter;
        iifname "lo" accept
        ip6 nexthdr icmpv6 accept
        iifname $IFACE goto wan-in
        # so is LAN
        ip6 saddr $INTv6 accept
        drop
    }
    chain wan-in {
        ip6 saddr $BOGONS6 drop
        ip6 nexthdr icmpv6 accept
        ip6 saddr $JUMP6 accept
        ip6 saddr $EXTv6 accept
        tcp dport 8006 ip6 daddr $PROX6 drop
        udp dport { 111, 425, 137, 138, 139, 161, 445, 514, 515, 631, 11211 } drop
        tcp dport { 111, 135, 137, 138, 139, 161, 445, 514, 515, 631, 11211 } drop
        accept
    }
}

Re: prefix len confusion

[Kerin Millar]

On Wed, 10 Jun 2026, at 1:10 AM, Randy Bush wrote:
> [ old dog but new to this list.  apologies for fleas ]
>
> amd64 hardware, not vm
> debian 13, very current
> nftables v1.1.3 (Commodore Bullmoose #4)
>
> 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;
        ...
    }
}

Incidentally, the iifname "lo" rule serves no purpose in your "forward" chain and can safely be removed.

--
Kerin Millar

Re: prefix len confusion

[Randy Bush]

>> 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

Re: prefix len confusion

[Kerin Millar]

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

Re: prefix len confusion

[Randy Bush]

>> 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

Re: prefix len confusion

[Kerin Millar]

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

Probably best to trace only packets with the SYN flag set. Otherwise, the trace output could be overwhelming.

ip daddr 42.642.11.82 tcp dport 22 tcp flags syn/syn,ack meta nftrace set 1

-- 
Kerin Millar

Re: prefix len confusion

[Reindl Harald]

Am 10.06.26 um 03:01 schrieb Randy Bush:
>>> 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
>>
> 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   # <<<====
>      }
you guys realize that "642" can't be part of an ipv4 address
and "should cover" is best answered with ipcalc
in that case it says the input is nonsense

[harry@srv-rhsoft:/downloads]$ ipcalc 42.642.11.80/30
ipcalc: bad IPv4 address: 42.642.11.80

if it's meant as obscurity that's not really helpful after a breach

Re: prefix len confusion

[Kerin Millar]

On Wed, 10 Jun 2026, at 7:20 AM, Reindl Harald wrote:
> Am 10.06.26 um 03:01 schrieb Randy Bush:
>>>> 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
>>>
>> 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   # <<<====
>>      }
> you guys realize that "642" can't be part of an ipv4 address
> and "should cover" is best answered with ipcalc
> in that case it says the input is nonsense

This is not the flex that you think it is.

Firstly, it is (obviously) a comment intended to draw attention to the entry, not a diagnostic message. Secondly, had the ruleset not been (obviously) obfuscated, nft would hardly wait until encountering that particular entry before electing to complain about an invalid address.

--
Kerin Millar