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

[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

[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

[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

[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.

Re: pf: block drop not working

[John McGuigan]

I think you've used "black_hole" and "black_whole" as table names. They
should all be the same.

John

On Wed, May 5, 2021, 5:18 AM Axel Rau  wrote:

> Hi all,
>
> in pf.conf, I have at the beginning:
> - - -
> table  persist file "/etc/pf/black_hole.txt"
> block drop in quick on $red_if from  flags any
>
> fw1# pfctl -s rules  | head -3
> block drop in quick on em2 from  to any
>
> fw1# pfctl -t black_hole -T show
> . . .
>146.168.0.0/16
> . . .
>
> But responses still going out from my ns:
>
>  0800 532: x.y.z.71.53 > 146.168.163.94.443: [udp sum ok] 1- 0/13/14(490)
> (ttl 63, id 10399, len 518)
>  0800 72: 146.168.163.94.443 > x.y.z.21.53: [no udp cksum] 1+ RRSIG?
> pizzaseo.com.(30) (ttl 249, id 3922, len 58)
>  0800 532: x.y.z.21.53 > 146.168.163.94.443: [udp sum ok] 1- 0/13/14(490)
> (ttl 63, id 38336, len 518)
>  0800 72: 146.168.163.94.443 > x.y.z.171.53: [no udp cksum] 1+ RRSIG?
> pizzaseo.com.(30) (ttl 249, id 55913, len 58)
>  0800 532: x.y.z.171.53 > 146.168.163.94.443: [udp sum ok] 1- 0/13/14(490)
> (ttl 62, id 53578, len 518)
>
>
> What is wrong in my setup?
>
> Thanks, Axel
> ---
> PGP-Key: CDE74120  ☀  computing @ chaos claudius
>
>

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

[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

Re: pf: block drop not working

[Axel Rau]

> Am 05.05.2021 um 13:30 schrieb Tom Smyth  >:
> 
> black_whole vs black_hole
> 
> check the table name …

Thanks a lot!
Axel
---
PGP-Key: CDE74120  ☀  computing @ chaos claudius



signature.asc
Description: Message signed with OpenPGP

Re: pf: block drop not working

[Tom Smyth]

black_whole vs black_hole

check the table name ...

On Wed, 5 May 2021 at 12:11, Axel Rau  wrote:
>
> Hi all,
>
> in pf.conf, I have at the beginning:
> - - -
> table  persist file "/etc/pf/black_hole.txt"
> block drop in quick on $red_if from  flags any
>
> fw1# pfctl -s rules  | head -3
> block drop in quick on em2 from  to any
>
> fw1# pfctl -t black_hole -T show
> . . .
>146.168.0.0/16
> . . .
>
> But responses still going out from my ns:
>
>  0800 532: x.y.z.71.53 > 146.168.163.94.443: [udp sum ok] 1- 0/13/14(490) 
> (ttl 63, id 10399, len 518)
>  0800 72: 146.168.163.94.443 > x.y.z.21.53: [no udp cksum] 1+ RRSIG? 
> pizzaseo.com.(30) (ttl 249, id 3922, len 58)
>  0800 532: x.y.z.21.53 > 146.168.163.94.443: [udp sum ok] 1- 0/13/14(490) 
> (ttl 63, id 38336, len 518)
>  0800 72: 146.168.163.94.443 > x.y.z.171.53: [no udp cksum] 1+ RRSIG? 
> pizzaseo.com.(30) (ttl 249, id 55913, len 58)
>  0800 532: x.y.z.171.53 > 146.168.163.94.443: [udp sum ok] 1- 0/13/14(490) 
> (ttl 62, id 53578, len 518)
>
>
> What is wrong in my setup?
>
> Thanks, Axel
> ---
> PGP-Key: CDE74120computing @ chaos claudius
>


-- 
Kindest regards,
Tom Smyth.

pf: block drop not working

[Axel Rau]

Hi all,

in pf.conf, I have at the beginning:
- - -
table  persist file "/etc/pf/black_hole.txt"
block drop in quick on $red_if from  flags any

fw1# pfctl -s rules  | head -3
block drop in quick on em2 from  to any

fw1# pfctl -t black_hole -T show
. . .
   146.168.0.0/16
. . .

But responses still going out from my ns:

 0800 532: x.y.z.71.53 > 146.168.163.94.443: [udp sum ok] 1- 0/13/14(490) (ttl 
63, id 10399, len 518)
 0800 72: 146.168.163.94.443 > x.y.z.21.53: [no udp cksum] 1+ RRSIG? 
pizzaseo.com.(30) (ttl 249, id 3922, len 58)
 0800 532: x.y.z.21.53 > 146.168.163.94.443: [udp sum ok] 1- 0/13/14(490) (ttl 
63, id 38336, len 518)
 0800 72: 146.168.163.94.443 > x.y.z.171.53: [no udp cksum] 1+ RRSIG? 
pizzaseo.com.(30) (ttl 249, id 55913, len 58)
 0800 532: x.y.z.171.53 > 146.168.163.94.443: [udp sum ok] 1- 0/13/14(490) (ttl 
62, id 53578, len 518)


What is wrong in my setup?

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



signature.asc
Description: Message signed with OpenPGP