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

2021-05-07 Thread Stuart Henderson
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 formatting.
On 7 May 2021 09:54:58 Axel Rau  wrote:





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 to let the fw drop them:
This seems not working:
udp_inbound_dns_options = 'keep state (max-src-conn-rate 120/60, overload 
 flush global )'

…
pass in quick on $red_if proto udp from any to { $ns4, $ns5 } \
port { domain } tag RED_DMZ $udp_inbound_dns_options label "dns inbound"
Is this not possible with udp?

Axel

---
PGP-Key: CDE74120  ☀  computing @ chaos claudius




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

2021-05-07 Thread Tom Smyth
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 community to
do  remote Triggered Black Holeto your providers...  RTBH ... (BGP
Communities) etc..

Best of Luck

On Fri, 7 May 2021 at 10:10, Axel Rau  wrote:
>
>
>
> > 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 to let the fw drop them:
> This seems not working:
> udp_inbound_dns_options = 'keep state (max-src-conn-rate 120/60, overload 
>  flush global )'
> …
> pass in quick on $red_if proto udp from any to { $ns4, $ns5 } \
> port { domain } tag RED_DMZ $udp_inbound_dns_options label "dns 
> inbound"
>
> Is this not possible with udp?
>
> Axel
> ---
> PGP-Key: CDE74120computing @ chaos claudius
>


-- 
Kindest regards,
Tom Smyth.



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

2021-05-07 Thread Axel Rau


> 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 to let the fw drop them:
This seems not working:
udp_inbound_dns_options = 'keep state (max-src-conn-rate 120/60, overload 
 flush global )'
…
pass in quick on $red_if proto udp from any to { $ns4, $ns5 } \
port { domain } tag RED_DMZ $udp_inbound_dns_options label "dns inbound"

Is this not possible with udp?

Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP


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

2021-05-05 Thread Stuart Henderson
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 always work.

> Does anyone has a script handy to update the table to black hole dns clients 
> which repeat same query with high frequency?

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.




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

2021-05-05 Thread Axel Rau


> 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 frequency?

Thanks, Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP