On Mon, 24 Jun 2024, Chris Rapier wrote: > On 6/19/24 4:11 PM, Joseph S. Testa II wrote: > > On Wed, 2024-06-19 at 09:19 -0400, chris wrote: > > > real world example (current snapshot of portable on linux v. dheater) > > > > Thanks for this. However, much more extensive testing would be needed > > to show it is a complete solution. In my original research article, I > > used CPU idle time as the main metric. Also, I showed that very low- > > latency network links could bypass the existing countermeasures. > > > > I suppose in the next few days, I'll try reproducing my original steps > > with the new version and see what happens. > > You may want to try this on IPv6 where you are frequently changing the > attackers MAC address. If the IP is constructed with EUI-64 then it could > start to flood the table used to store the penalized IPs. I'd really like to > see what that looks like, especially in terms of CPU/memory utilization. it will look like a successful DoS, unless/until we change the default PerSourcePenalties overflow6 mode and or the default IPv6 PerSourceNetBlockSize. IMO the latter is the more likely path. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
