~nickbp/kapiti#30: 
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...

Status
REPORTED
Submitter
~nickbp
Assigned to
No-one
Submitted
4 months ago
Updated
4 months ago
Labels
Next

~nickbp 4 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):

[lan_default]
applies_to = [
  "192.168.1.1/16"
]
block = [
  "/etc/badhosts",
  "/etc/verybadhosts"
]
override = [
  "/etc/hosts"
]

[iot]
applies_to = [
  "192.168.5.1/24"
]
allow = [
  "/etc/iotallow"
]

[all]
block = [
  "/etc/verybadhosts"
]

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. 192.168.5.3 would be processed by the iot block
  • Only one block is processed per host, even if there are multiple matches. For example 192.168.1.2 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
Register here or Log in to comment, or comment via email.