Blocklist Filter

[markmandel]

Thinking about Server side DDOS mitigation, or just general abuse mitigation - being able to block specific addresses from sending traffic through to any gameserver should be useful.

Something like:

version: v1alpha1
static:
  filters:
    - name: quilkin.extensions.filters.block.v1alpha1.Block
      config:
        addresses:
          - "194.56.36.79"
          - "3FFE:0000:0000:0001:0200:F8FF:FE75:50DF"
  endpoints:
    - name: server-1
      address: 127.0.0.1:7001

Question: Not sure if we need to block IP and port, or just IP?

[XAMPPRocky]

Since blocklists are such an essential part of proxies, I think it would be worth thinking of the blocklist not as a filter, but as a feature as part of a filter chain, so you'd set the list on that level, and then with #63 filters would be able to add and remove from the blocklist as part of their response.

Question: Not sure if we need to block IP and port, or just IP?

We'll need to be able to block both, as you can use the port for UDP reflection amplification attacks.

[markmandel]

Since blocklists are such an essential part of proxies, I think it would be worth thinking of the blocklist not as a filter, but as a feature as part of a filter chain, so you'd set the list on that level, and then with #63 filters would be able to add and remove from the blocklist as part of their response.

With #63 - I would suggest, let's take a user journey (this one seems like a good example), and flesh it out to see what we think we would like it to look like. I have some thoughts that think we can keep this quite simple, at least for first pass, but I won't dilute this ticket with those ideas for now.

I don't think we need to have a new special construct for blocklist management, it can work as a Filter, it just depends where it should be in the Filterchain ordering, but also keeps the cognitive overhead for users down -- but doing a user journey discussion on #63 will likely also find where the edge cases are.

[markmandel]

I was thinking about this the other day, and wanted to get people's feedback:

1. I think Quilkin should have it's own Allow/Deny features based on addresses. Yes, the end user may also block at a higher level than Quilkin, but if you are doing address based access control, it seems useful to be able to do redundant levels in case one fails.
2. I'm not 100% convinced it's Quilkin's job to be managing anything outside of itself. But long term, it can push data out to other systems that may do so through rules and actions (when we work out what that looks like).
3. I think it makes sense to combine block and allowlist functionality into a single Filter.

I've called this Firewall since I figure that's basically what it is.

version: v1alpha1
static:
  filters:
    - name: quilkin.extensions.filters.debug.v1alpha1.Firewall
      config:
        - direction: Read # ("Read": respond to on_read or "Write" for on_write filter events)
          action: Allow # (action on address/port match. "Allow" would allow traffic through, "Deny" would drop the packets)
          source: "192.168.51.0/24" # (ip4 or ipv6 Cidr)
          ports: # (which ports to match on)
             - 10 # (could be a single port, or a range with a `-` in the middle)
             - 1000-7000
  endpoints:
    - address: 127.0.0.1:7001

WDYT?

Some thoughts / questions I'm still thinking about, and would love feedback if you like the general idea:

1. Should it be filters > rules > (array of rules), in case we want more top level config options? (I'm thinking if you want a "match first" approach on the filter vs "match all" option?)
2. Not quite sure what standard defaults should be for source or ports - so for now we could leave them as required for configuration.

Thoughts?

[iffyio]

This makes sense merging both allow and deny into a Firewall filter!

Not quite sure what standard defaults should be for source or ports - so for now we could leave them as required for configuration.

Leaving them as required sounds reasonable. Also since the user specifies a list of rules, mistakenly having multiple rules in the list with default values might be a footgun otherwise.

Should it be filters > rules > (array of rules), in case we want more top level config options? (I'm thinking if you want a "match first" approach on the filter vs "match all" option?)

We can split the read/write rules into their own sections (like we do for e.g compress) since those rules won't relate to each other (e.g they can't conflict), so that we avoid specifying a direction per rule and its easier to view/process rules by direction.
Then I think this would also enable top level config options issue in the future too?

config:
  on_read:
  - action: Allow
    source: 0.0.0.0
    ports: [1,2,3]
  on_write:
  - action: Allow
    source: 0.0.0.1
    ports: [1,2,3]

[markmandel]

We can split the read/write rules into their own sections (like we do for e.g compress) since those rules won't relate to each other (e.g they can't conflict), so that we avoid specifying a direction per rule and its easier to view/process rules by direction.

Yeees! Thanks for that. We should definitely stick to the already established nomenclature of on_read and on_write! That works nicely. So the full config would look like:

version: v1alpha1
static:
  filters:
    - name: quilkin.extensions.filters.debug.v1alpha1.Firewall
      config:
        on_read:
          - action: ALLOW # (action on address/port match. "Allow" would allow traffic through, "Deny" would drop the packets)
            source: "192.168.51.0/24" # (ip4 or ipv6 Cidr)
            ports: # (which ports to match on)
               - 10 # (could be a single port, or a range with a `-` in the middle)
               - 1000-7000
        on_write: 
          - action: DENY
            source: "192.168.51.0/24" # (ip4 or ipv6 Cidr)
            ports: # (which ports to match on)
               - 7000
  endpoints:
    - address: 127.0.0.1:7001

(Those values aren't that realistic 😄 but this is a 👍🏻 for me!)

[markmandel]

Gonna start working on this. Let me know if anyone has any objections to the design above (can always tweak it as needed anyway).