Re: fighting amplification attack --was: Re: pf: block drop not working

No this is not possible. UDP is trivially spoofed (which is probably why you see the problem in the first place; the source IPs you see on the packets are the *victims* not the attacker). Doing this for UDP opens an easy DoS of your legitimate clients. -- Sent from a phone, apologies for poor

Re: fighting amplification attack --was: Re: pf: block drop not working

Hello Axel, Check out fastnetmon if you have SFLOW (Preferably ) or Netflow support on your switches /or routers facing external providers you can put pps per second thresholds on . but bear in mind if the amount of bandwdith being sent to your router exceeds capacity you need to send a BGP co

Re: fighting amplification attack --was: Re: pf: block drop not working

> Am 05.05.2021 um 16:20 schrieb Stuart Henderson >: > > This is usually best dealt with in your DNS server software e.g. by using > the rrl-* configuration in NSD, see nsd.conf(5), or "rate-limit" config > section in BIND. Yes, I have this in place now, but I try

Re: fighting amplification attack --was: Re: pf: block drop not working

On 2021-05-05, Axel Rau wrote: >> >> check the table name … > > But even with the correct table name I had to flush states to get it working. That is expected. A state lookup is done before parsing the ruleset. You can try clearing states with pfctl -k but there are some issues, it doesn't alway

fighting amplification attack --was: Re: pf: block drop not working

> Am 05.05.2021 um 13:30 schrieb Tom Smyth : > > black_whole vs black_hole > > check the table name … But even with the correct table name I had to flush states to get it working. Does anyone has a script handy to update the table to black hole dns clients which repeat same query with high f