IPv4 Evil Bit

IPv4 Evil Bit

[Marek Küthe]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

Hello,

I hope I am in the right place. I have two questions about nftables:

1) Is it possible to perform OR operations in nftables? For example
`ip6 saddr ::/128 OR ip saddr 127.0.0.1/8 accept;` As far as I
understand it, everything else is concatenated with AND.

2) I want to see how many IPv4 packets I can get with the Evil Bit
(RFC3514). Since there seems to be no native function for this in
nftables, I seem to have to use raw payload expression. So I have
set up the following:

@th,6,1 & 0x80 = 0x80 \
    log prefix "[nftables] Evil bit: " counter reject;

However, `Error: syntax error, unexpected '='` appears. What is the
reason for this? How can I formulate this expression correctly?

I would really appreciate your answers!

Greetings
Marek Küthe

-- 
Marek Küthe
m.k@mk16.de
er/ihm he/him

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: IPv4 Evil Bit

[Kerin Millar]

On Wed, 7 Jun 2023 13:17:43 +0200
Marek Küthe <m-k-mailling-list@mk16.de> wrote:

> Hello,
> 
> I hope I am in the right place. I have two questions about nftables:
> 
> 1) Is it possible to perform OR operations in nftables? For example
> `ip6 saddr ::/128 OR ip saddr 127.0.0.1/8 accept;` As far as I
> understand it, everything else is concatenated with AND.

No. Nor would a set suffice, as ipv4_addr and ipv6_addr elements cannot be mixed.

> 
> 2) I want to see how many IPv4 packets I can get with the Evil Bit
> (RFC3514). Since there seems to be no native function for this in
> nftables, I seem to have to use raw payload expression. So I have
> set up the following:
> 
> @th,6,1 & 0x80 = 0x80 \
>     log prefix "[nftables] Evil bit: " counter reject;
> 
> However, `Error: syntax error, unexpected '='` appears. What is the
> reason for this? How can I formulate this expression correctly?

Try @nh,48,8 & 0x80 == 0x80. The offset and length values are expressed in bits, not bytes.

-- 
Kerin Millar

Re: IPv4 Evil Bit

[Paul Robert Marino]

Answering the first question i think you may be looking for sets
https://wiki.nftables.org/wiki-nftables/index.php/Sets

As for the second one RFC3514 implementing that is a bad idea for a
number of reasons which is why as far as I know nothing implements it,
it's too easy for a bad actor to take advantage of. In fact it was
actually an april fools joke RFC. There are a lot of those and some
people confuse them as being legitimate but they are not. if you see
an RFC with a publish date of April 1st any year don't take it
seriously.
AGAIN I CAN NOT STRESS THIS POINT ENOUGH THAT RFC (RFC3514 ) WAS
WRITTEN AS AN APRIL FOOLS JOKE!!!!!.

On Wed, Jun 7, 2023 at 8:12 AM Marek Küthe <m-k-mailling-list@mk16.de> wrote:
>
> Hello,
>
> I hope I am in the right place. I have two questions about nftables:
>
> 1) Is it possible to perform OR operations in nftables? For example
> `ip6 saddr ::/128 OR ip saddr 127.0.0.1/8 accept;` As far as I
> understand it, everything else is concatenated with AND.
>
> 2) I want to see how many IPv4 packets I can get with the Evil Bit
> (RFC3514). Since there seems to be no native function for this in
> nftables, I seem to have to use raw payload expression. So I have
> set up the following:
>
> @th,6,1 & 0x80 = 0x80 \
>     log prefix "[nftables] Evil bit: " counter reject;
>
> However, `Error: syntax error, unexpected '='` appears. What is the
> reason for this? How can I formulate this expression correctly?
>
> I would really appreciate your answers!
>
> Greetings
> Marek Küthe
>
> --
> Marek Küthe
> m.k@mk16.de
> er/ihm he/him

Re: IPv4 Evil Bit

[Marek Küthe]

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]

On Wed, 7 Jun 2023 14:30:19 +0100
Kerin Millar <kfm@plushkava.net> wrote:

> On Wed, 7 Jun 2023 13:17:43 +0200
> Marek Küthe <m-k-mailling-list@mk16.de> wrote:
> 
> > Hello,
> > 
> > I hope I am in the right place. I have two questions about nftables:
> > 
> > 1) Is it possible to perform OR operations in nftables? For example
> > `ip6 saddr ::/128 OR ip saddr 127.0.0.1/8 accept;` As far as I
> > understand it, everything else is concatenated with AND.  
> 
> No. Nor would a set suffice, as ipv4_addr and ipv6_addr elements cannot be mixed.

Too bad nftables doesn't have something like that.

> 
> > 
> > 2) I want to see how many IPv4 packets I can get with the Evil Bit
> > (RFC3514). Since there seems to be no native function for this in
> > nftables, I seem to have to use raw payload expression. So I have
> > set up the following:
> > 
> > @th,6,1 & 0x80 = 0x80 \
> >     log prefix "[nftables] Evil bit: " counter reject;
> > 
> > However, `Error: syntax error, unexpected '='` appears. What is the
> > reason for this? How can I formulate this expression correctly?  
> 
> Try @nh,48,8 & 0x80 == 0x80. The offset and length values are expressed in bits, not bytes.

Thanks a lot! This works.

> 
> -- 
> Kerin Millar


-- 
Marek Küthe
m.k@mk16.de
er/ihm he/him

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: IPv4 Evil Bit

[Marek Küthe]

[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]

On Wed, 7 Jun 2023 10:38:23 -0400
Paul Robert Marino <prmarino1@gmail.com> wrote:

> Answering the first question i think you may be looking for sets
> https://wiki.nftables.org/wiki-nftables/index.php/Sets

Thanks for the answer. Is there a possibility to combine sets (i.e. to
perform a kind of merge)?
iifname @dnet_interfaces oifname {
@client_interfaces, @dnet_interfaces } goto dnet_forward;

> 
> As for the second one RFC3514 implementing that is a bad idea for a
> number of reasons which is why as far as I know nothing implements it,
> it's too easy for a bad actor to take advantage of. In fact it was
> actually an april fools joke RFC. There are a lot of those and some
> people confuse them as being legitimate but they are not. if you see
> an RFC with a publish date of April 1st any year don't take it
> seriously.
> AGAIN I CAN NOT STRESS THIS POINT ENOUGH THAT RFC (RFC3514 ) WAS
> WRITTEN AS AN APRIL FOOLS JOKE!!!!!.

I know this RFC is intended as an April Fool's joke. However, I would
like to see how many requests I get with the Evil Bit. And how many
requests I forward for the dn42 with the Evil Bit.

How could a malicious actor have the advantage if I log this bit? Or do
you mean that I shouldn't rely on malicious requests having that bit?

"Inspired" me to this idea was
https://blog.benjojo.co.uk/post/evil-bit-RFC3514-real-world-usage.

> 
> On Wed, Jun 7, 2023 at 8:12 AM Marek Küthe <m-k-mailling-list@mk16.de> wrote:
> >
> > Hello,
> >
> > I hope I am in the right place. I have two questions about nftables:
> >
> > 1) Is it possible to perform OR operations in nftables? For example
> > `ip6 saddr ::/128 OR ip saddr 127.0.0.1/8 accept;` As far as I
> > understand it, everything else is concatenated with AND.
> >
> > 2) I want to see how many IPv4 packets I can get with the Evil Bit
> > (RFC3514). Since there seems to be no native function for this in
> > nftables, I seem to have to use raw payload expression. So I have
> > set up the following:
> >
> > @th,6,1 & 0x80 = 0x80 \
> >     log prefix "[nftables] Evil bit: " counter reject;
> >
> > However, `Error: syntax error, unexpected '='` appears. What is the
> > reason for this? How can I formulate this expression correctly?
> >
> > I would really appreciate your answers!
> >
> > Greetings
> > Marek Küthe
> >
> > --
> > Marek Küthe
> > m.k@mk16.de
> > er/ihm he/him  


-- 
Marek Küthe
m.k@mk16.de
er/ihm he/him

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: IPv4 Evil Bit

[Florian Westphal]

Marek Küthe <m-k-mailling-list@mk16.de> wrote:
> > > 1) Is it possible to perform OR operations in nftables? For example
> > > `ip6 saddr ::/128 OR ip saddr 127.0.0.1/8 accept;` As far as I
> > > understand it, everything else is concatenated with AND.  
> > 
> > No. Nor would a set suffice, as ipv4_addr and ipv6_addr elements cannot be mixed.
> 
> Too bad nftables doesn't have something like that.

Anon chain would come closest:

 iifname "lo" jump {
   ip saddr 127.0.0.0/8 accept
   ip6 saddr ::1 accept
 }

Re: IPv4 Evil Bit

[Kerin Millar]

On Thu, 8 Jun 2023 09:58:39 +0200
Marek Küthe <m-k-mailling-list@mk16.de> wrote:

> On Wed, 7 Jun 2023 10:38:23 -0400
> Paul Robert Marino <prmarino1@gmail.com> wrote:
> 
> > Answering the first question i think you may be looking for sets
> > https://wiki.nftables.org/wiki-nftables/index.php/Sets
> 
> Thanks for the answer. Is there a possibility to combine sets (i.e. to
> perform a kind of merge)?
> iifname @dnet_interfaces oifname {
> @client_interfaces, @dnet_interfaces } goto dnet_forward;

Named sets cannot be aggregated. This can only be accomplished with symbolic variables those values define anonymous sets. See https://bugzilla.netfilter.org/show_bug.cgi?id=1539#c6 for an example.

-- 
Kerin Millar

Re: IPv4 Evil Bit

[Paul Robert Marino]

On Thu, Jun 8, 2023 at 3:57 AM Marek Küthe <m-k-mailling-list@mk16.de> wrote:
>
> On Wed, 7 Jun 2023 10:38:23 -0400
> Paul Robert Marino <prmarino1@gmail.com> wrote:
>
> > Answering the first question i think you may be looking for sets
> > https://wiki.nftables.org/wiki-nftables/index.php/Sets
>
> Thanks for the answer. Is there a possibility to combine sets (i.e. to
> perform a kind of merge)?
> iifname @dnet_interfaces oifname {
> @client_interfaces, @dnet_interfaces } goto dnet_forward;
>
> >
> > As for the second one RFC3514 implementing that is a bad idea for a
> > number of reasons which is why as far as I know nothing implements it,
> > it's too easy for a bad actor to take advantage of. In fact it was
> > actually an april fools joke RFC. There are a lot of those and some
> > people confuse them as being legitimate but they are not. if you see
> > an RFC with a publish date of April 1st any year don't take it
> > seriously.
> > AGAIN I CAN NOT STRESS THIS POINT ENOUGH THAT RFC (RFC3514 ) WAS
> > WRITTEN AS AN APRIL FOOLS JOKE!!!!!.
>
> I know this RFC is intended as an April Fool's joke. However, I would
> like to see how many requests I get with the Evil Bit. And how many
> requests I forward for the dn42 with the Evil Bit.
>
> How could a malicious actor have the advantage if I log this bit? Or do
> you mean that I shouldn't rely on malicious requests having that bit?
>
> "Inspired" me to this idea was
> https://blog.benjojo.co.uk/post/evil-bit-RFC3514-real-world-usage.

Yes I read this Blog too right after your first email, but I
interpreted it very differently.
He points out that yes you could actually implement it and he makes an
argument on how in theory you could implement it to prevent scanners
from scanning a port but it's a flawed argument.
A better argument he missed is if you know the upstream firewall
supports it a network sniffer or security endpoint software could flip
it to inform the firewall to block it, but this too is a flawed
argument.
I interpreted he was making a related joke but, if not then I would
interpret it as he actually didn't fully get the joke in the RFC, and
or is too naive on the subject of how port scanners actually work to
know why his theory is mostly pointless. What he actually pointed out
in the blog page is a large number of companies that have a huge
vulnerability, and he probably should have tried to submit some bug
bounties.

Here are a few reasons why implementing this bit for any reason other
than logging is a bad idea.
1) It will only work if the firewall the sender is going through
blocks on this bit on outbound and or established connections which is
a huge unlikely if. I can tell you from  pentesting experience this
wouldn't stop any of the tools I've used from picking up the port. An
nmap xmas scan is legitimately evil and won't care if you set the evil
bit to true https://nmap.org/book/scan-methods-null-fin-xmas-scan.html

2) Any firewall that blocks based on the evil bit is a denial of
service liability because all someone would need to do is infect an
upstream switch, router, transceiver, or firewall  with a worm or some
other malware that flips the bit on for all connections that pass
through it and your firewall will deny service and it will be very
difficult to figure out especially since standard tools like wireshark
ignore it.

3) Malware or an office prankster on windows could change a registry
entry to turn the bit on on all outbound connections, and it's not
much harder to do on Linux, BSD or MacOS either, so from a customer or
users perspective you would be blocking them and others wouldn't be.
Try explaining that to your largest customer or your CEO, etc. that
your firewall is denying them service because it complies with an
April fools joke and let me know how it goes lol.

The truth is I never thought to test for this but if i'm ever
conducting a pentest of a company again and I find their firewall
implements this April fools joke I will fail them on it, that said
logging if you see it is not a bad idea as it may indicate something
wrong with a client or piece of network equipment so i wouldn't fail
them for logging when they see it, but blocking on it is a potential
business continuity issue because the eas of which it can be exploited
and the difficulty to detect if it were exploited.