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

Re: prefix len confusion

[Randy Bush]

> 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

my apologies.  i meant the >256 octets to signal that these data had
been manipulated with intent to anonymize.  i did not intent to give
heartburn to a fellow ipcalc user.

randy

Re: prefix len confusion

[Randy Bush]

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

thanks a million.  this showed pretty conclusively that the
`/etc/nftables.conf` was indeed correct and filtering as one
would hope/expect.  and i learned a new hack!

so we are now looking for more subtle attack surface, e.g. loose
source routing, bouncing off a legitimately open service on the
same LAN, etc.

we also see this (distributed source) attack on proxmox clusters' web
interfaces

    2026-06-07T02:01:39.274405+00:00 pv0 pvedaemon[2276]: authentication failure; rhost=::ffff:85.11.167.7 user=root@pam msg=Authentication failure
    2026-06-07T02:01:42.970943+00:00 pv0 pvedaemon[2277]: authentication failure; rhost=::ffff:85.11.167.7 user=root@pam msg=Authentication failure

can we safely just add ffff::0 to the v6 bogon list?

randy

Re: prefix len confusion

[Kerin Millar]

On Wed, 10 Jun 2026, at 5:33 PM, Randy Bush wrote:
>> 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".
>
> thanks a million.  this showed pretty conclusively that the
> `/etc/nftables.conf` was indeed correct and filtering as one
> would hope/expect.  and i learned a new hack!
>
> so we are now looking for more subtle attack surface, e.g. loose
> source routing, bouncing off a legitimately open service on the
> same LAN, etc.
>
> we also see this (distributed source) attack on proxmox clusters' web
> interfaces
>
>     2026-06-07T02:01:39.274405+00:00 pv0 pvedaemon[2276]: 
> authentication failure; rhost=::ffff:85.11.167.7 user=root@pam 
> msg=Authentication failure
>     2026-06-07T02:01:42.970943+00:00 pv0 pvedaemon[2277]: 
> authentication failure; rhost=::ffff:85.11.167.7 user=root@pam 
> msg=Authentication failure
>
> can we safely just add ffff::0 to the v6 bogon list?

It's an IPv4 address being logged in the form of an IPv4-mapped IPv6 address. If you wish to block it, consider it as an ordinary IPv4 address (85.11.167.7). Your BOGONS6 variable does not need to be adjusted.

For that reason, you should also be able to observe the packet(s) if you add a suitable tracing rule to the existing PREROUTING chain. That is, unless it is bridged traffic or does not traverse the firewall (as discussed previously).

--
Kerin Millar

Re: prefix len confusion

[Randy Bush]

>> we also see this (distributed source) attack on proxmox clusters' web
>> interfaces
>>
>>     2026-06-07T02:01:39.274405+00:00 pv0 pvedaemon[2276]: 
>> authentication failure; rhost=::ffff:85.11.167.7 user=root@pam 
>> msg=Authentication failure
>>     2026-06-07T02:01:42.970943+00:00 pv0 pvedaemon[2277]: 
>> authentication failure; rhost=::ffff:85.11.167.7 user=root@pam 
>> msg=Authentication failure
>>
>> can we safely just add ffff::0 to the v6 bogon list?
> 
> It's an IPv4 address being logged in the form of an IPv4-mapped IPv6
> address. If you wish to block it, consider it as an ordinary IPv4
> address (85.11.167.7).

if nft treats it as an ipv4 addy, then the ipv4 filters should have
blocked, n'est-ce pas?

    tcp dport 8006 ip daddr $PROX4 drop

> For that reason, you should also be able to observe the packet(s) if
> you add a suitable tracing rule to the existing PREROUTING chain.

after pouting another cup

> That is, unless it is bridged traffic or does not traverse the
> firewall (as discussed previously).

no bridging.  we are hunting other holes in the attack surface.
using your prerouting hack to demonstrate the filtering is working
is a big help in focusing our efforts.

randy

Re: prefix len confusion

[Kerin Millar]

On Wed, 10 Jun 2026, at 6:19 PM, Randy Bush wrote:
>>> we also see this (distributed source) attack on proxmox clusters' web
>>> interfaces
>>>
>>>     2026-06-07T02:01:39.274405+00:00 pv0 pvedaemon[2276]: 
>>> authentication failure; rhost=::ffff:85.11.167.7 user=root@pam 
>>> msg=Authentication failure
>>>     2026-06-07T02:01:42.970943+00:00 pv0 pvedaemon[2277]: 
>>> authentication failure; rhost=::ffff:85.11.167.7 user=root@pam 
>>> msg=Authentication failure
>>>
>>> can we safely just add ffff::0 to the v6 bogon list?
>> 
>> It's an IPv4 address being logged in the form of an IPv4-mapped IPv6
>> address. If you wish to block it, consider it as an ordinary IPv4
>> address (85.11.167.7).
>
> if nft treats it as an ipv4 addy, then the ipv4 filters should have
> blocked, n'est-ce pas?
>
>     tcp dport 8006 ip daddr $PROX4 drop

Assuming the packets arrive at $IFACE, that pv0 resides within $PROX4 and so on and so forth.

-- 
Kerin Millar

Re: prefix len confusion

[Sunny73Cr]

Try this:

table ip filter {
    chain forward {
        type filter hook forward priority filter;
        iifname "lo" accept # please filter this too, you'll bounce your bushies (brows)
        iifname $IFACE goto wan-in
        ip protocol icmp accept
        # so is LAN
        ip saddr $INTv4 accept
        drop
    }
    chain wan-in {
        ip saddr $BOGONS4 drop
        ip daddr $VULN4 drop
        ip protocol icmp accept
        ip saddr $JUMP4 accept
        ip saddr $EXTv4 accept
        tcp dport 8006 ip daddr $PROX4 drop   # block proxmox web login
...

Basically, you want to drop anything you don't like before you accept anything that you do (unless it will be dropped by a later hook). Someone mentioned no input hook registration; that should be OK as docs say that later hooks still get evaluated... test to be sure.

Refer to VERDICT STATEMENT in https://www.netfilter.org/projects/nftables/manpage.html; it says '
accept - Terminate ruleset evaluation and accept the packet. The packet can still be dropped later by another hook...'.

So currently, if iifname was lo (due to some other kernel vuln), or protocol was ICMP, or saddr was jump4 or extv4: it will get forwarded to the machine within 42.642.11.80/30

Hope all is well,
sunny

CONFIDENTIALITY NOTICE:
This email and its attachments are intended solely for the use of the intended addressee; and may contain confidential and/or privileged information. You are hereby notified that any unauthorized use of this email or its attachments is strictly prohibited. If you have received this email in error, please destroy instances of it, and any information that was derived directly from it. To be clear, the message and its headers (SMTP, IMAP, POP message, etc.) is 'this email', but network headers (Ethernet, Internet Protocol, Transmission Control Protocol, User Datagram Protocol, etc.) are not.

SIGNATURE NOTICE:
If we have not met, the below public key is not useful.

sunny_0x00000000_public.asc

-----BEGIN PGP PUBLIC KEY BLOCK-----
KEY REDACTED, WE HAVE NOT MET.
-----END PGP PUBLIC KEY BLOCK-----

Re: prefix len confusion

[Randy Bush]

>     chain wan-in {
>         ip saddr $BOGONS4 drop
>         ip daddr $VULN4 drop
>         ip protocol icmp accept
>         ip saddr $JUMP4 accept
>         ip saddr $EXTv4 accept

i believe that this would drop connections from within the trust bundary
($JUMP4 & EXTv4) to the protected hosts ($VULN4) that the trust boundary
was created to specifically allow.

randy