Restructure toml filter config, support 'allow' filtering, and support different filtering by client netmask

Support cases like blackholing specific devices on a local network, where they are only allowed to query for specific domains. For example the user may want to block all DNS requests for a television that's trying to spray requests for several surveillance servers.

Need to figure out the config syntax for this compared to what's already there for denylists/overrides...

Assigned to
1 year, 6 months ago
9 months ago

~nickbp 1 year, 6 months ago

So we currently have override and block sections in the toml config, each containing a list of strings for files and URLs. These filters are applied to all incoming requests.

We could define a separate allow section, which would also be a list of strings for files and URLs. If it was applied to all requests, this allow section logically conflicts with the override and block sections. Instead, we could have it only apply to a list of IP masks. For example, a (bad and confusing) name could be allow_hosts, where the contents of allow would only apply to these hosts, and all others would instead be subject to override and block.

Another angle: It might help if we added a "block" grouping to the filters, where each block can be applied to a subset of clients (or all clients if the subset isn't specified). This could look something the following (haven't checked if this is valid toml):

applies_to = [
block = [
override = [

applies_to = [
allow = [

block = [

I think something like this would work. As implied by the example:

  • allow cannot be combined with block/override
  • The "most exact" match should win, e.g. would be processed by the iot block
  • Only one block is processed per host, even if there are multiple matches. For example should be processed under lan but not all, hence why /etc/verybadhosts is listed in both blocks. This avoids things getting confusing as blocks are added - imagine if someone had 20 blocks and needed to then trace the logic to check which ones matched a given host (and then try and guess the processing order of blocks vs allows/overrides)
  • It is invalid to have two blocks with equivalent applies_to settings

~nickbp 9 months ago

In the scenario where there are only applies_to blocks and no unfiltered "all" block, the server should only respond to traffic from the applies_to blocks. This may be useful for running a public service that only allows access from certain IPs.