Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dnsdist: DynBlockGroupRules : eBPF block doesn't clear when ban expires #10324

Closed
thibmac opened this issue Apr 21, 2021 · 4 comments · Fixed by #10327
Closed

dnsdist: DynBlockGroupRules : eBPF block doesn't clear when ban expires #10324

thibmac opened this issue Apr 21, 2021 · 4 comments · Fixed by #10327

Comments

@thibmac
Copy link

thibmac commented Apr 21, 2021

  • Program: dnsdist
  • Issue type: Bug report
  • Operating system: Debian buster
  • Software version: dnsdist-1.6.0-rc1
  • Deb package

Short description

Follow up to #9782

Since 1.6 ,when dnsdist creates a DynBlock, I understand it also creates an eBPF block in the same time.
When the user space dynblock expires, the bpf block seems to remain and keeps blocking incoming queries.

Steps to reproduce

Conf to reproduce :

bpf = newBPFFilter(1048576, 1048576, 32)
setDefaultBPFFilter(bpf)

local dbr = dynBlockRulesGroup()
  dbr:setQueryRate(10, 1, "Exceeded query rate", 60)

function maintenance()
  dbr:apply()
end

Expected behaviour

When a dynblock is created for an IP, for the next 60 seconds, I expect to see :

  • showDynblocks() showing 1 block
  • bpf:getStats() showing 1 block too.
  • On the dnsdist web UI, I should see 1 IP in the "Dyn blocked netmask" field and that same IP in the "Kernel-based dyn blocked netmask" field

After 60 seconds, these blocks should be removed if the source IP doesn't generate more than 10 qps

Actual behaviour

I actually see :

  • showDynblocks() showing 1 block
  • bpf:getStats() showing 1 block too.
  • On the dnsdist web UI, the blocked IP is only displayed in the "Dyn blocked netmask" field

After 60 seconds:

  • showDynblocks() shows no more dynblock - that makes sense
  • bpf:getStats() keeps showing that 1 block too.

Queries are blocked because of that remaining eBPF dynblock too.
This eBPF block is usually cleared ~4/5 minutes after though, Is there a minimal value hardcoded somewhere here ?

@thibmac
Copy link
Author

thibmac commented Apr 21, 2021

I also have few questions about the new feature :

If I decide to return a truncate action instead of dropping the query with :

[...]
dbr:setQueryRate(10, 1, "Exceeded query rate", 60, DNSAction.Truncate)
[...]

What should I expect ? Is dnsdist also able to truncate the query in kernel space or is it dropping by default ?

Thanks!

Cheers

@rgacogne
Copy link
Member

This eBPF block is usually cleared ~4/5 minutes after though, Is there a minimal value hardcoded somewhere here ?

Dynamic blocks objects in userspace contains a "valid up to" field, and will skip any action after that time, which makes very accurate. The kernel space version, eBPF blocks, lacks that field and so will keep being applied until the object is garbage collected, which happens every 5 minutes by default. That value can be tuned via setDynBlocksPurgeInterval(), but I guess we should move the default to 60s now that we are using eBPF blocks by default. I'll do that soon.

What should I expect ? Is dnsdist also able to truncate the query in kernel space or is it dropping by default ?

Our current eBPF code only knows how to drop, so dynamic blocks with a different action should not be converted to eBPF. But looking at that code there seems to be a bug there, I'll investigate.

@thibmac
Copy link
Author

thibmac commented Apr 23, 2021

Our current eBPF code only knows how to drop

Small curiosity here, is it doable to implement those same truncate/delay action from classic dynblocks into the bpf dynblocks ?

@rgacogne
Copy link
Member

Delay cannot be implemented in eBPF, as far as I can tell. Truncate would be doable if someone is motivated enough, some eBPF groundwork has already been done by the NLnetLabs for XDP, see for example: https://labs.ripe.net/author/luuk_hendriks/journeying-into-xdp-part-0/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants