lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 29 May 2020 16:52:34 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     jbaron@...mai.com
Cc:     netdev@...r.kernel.org, jhs@...atatu.com, xiyou.wangcong@...il.com,
        jiri@...nulli.us
Subject: Re: [net-next 0/2] net: sched: cls-flower: add support for
 port-based fragment filtering

From: Jason Baron <jbaron@...mai.com>
Date: Wed, 27 May 2020 16:25:28 -0400

> Port based allow rules must currently allow all fragments since the
> port number is not included in the 1rst fragment. We want to restrict
> allowing all fragments by inclucding the port number in the 1rst
> fragments.
> 
> For example, we can now allow fragments for only port 80 via:
> 
> # tc filter add dev $DEVICE parent ffff: priority 1 protocol ipv4 flower
>   ip_proto tcp dst_port 80 action pass
> # tc filter add dev $DEVICE parent ffff: priority 2 protocol ipv4 flower
>   ip_flags frag/nofirstfrag action pass
> 
> The first patch includes ports for 1rst fragments.
> The second patch adds test cases, demonstrating the new behavior.

But this is only going to drop the first frag right?

Unless there is logic to toss the rest of the frags this seems
extremely hackish as best.

I don't want to apply this as-is, it's a short sighted design
as far as I am concerned.

Powered by blists - more mailing lists