As an ops lead,
I want to detect unexpected DNS resolution for unexpected traffic
And block on these requests via a firewall,
So that I prevent unexpected DNS resolution.
WHY are we building?
To prevent unexpected egress traffic talking back to the world.
WHAT are we building?
Add DNS resolver firewall allow and block lists to only let expected outbound requests resolve.
VALUE created by our solution
More security in our product.
Acceptance Criteria
[ ] Determine an allow list of expected DNS to get resolved.
[ ] Block DNS resolution that are unexpected.
QA Steps
[ ] Test with a call from within the VPC to an non-allowed DNS and expect it to get blocked.
Additional information
There are potential red flags and solution we can attack this issue.
Red flags
We have API callbacks that are configured by users and will need DNS resolution. For these, we'd have to build a list and potentially make wildcards out of governmental domain names. But that might not be sufficient from the moment that a user adds a non-governemental domain to be supported.
We'd need to have a more dynamic way to update the allow list that triggers when a user update an API callback. This could allow GCNotify to be more precise too in which DNS we have in the allow list (vs having a general wild card pattern).
The issue with that solution is that we will have to define a static list of domains that are allowed. Our API callbacks that can contain various domain names might pose a problem with this, as we'd require some more dynamic configuration.
Dynamic configuration of allowed domains triggered on API callback changes
We could configure the allowed list of domains upon trigger of API callback changes from GCNotify users. We can copy what the SRE team did with the Route 53 firewall and add extra hooks in our application code to configure the allowed list dynamically.
This would require a custom solution and more resources to implement.
Description
As an ops lead, I want to detect unexpected DNS resolution for unexpected traffic And block on these requests via a firewall, So that I prevent unexpected DNS resolution.
WHY are we building?
To prevent unexpected egress traffic talking back to the world.
WHAT are we building?
Add DNS resolver firewall allow and block lists to only let expected outbound requests resolve.
VALUE created by our solution
More security in our product.
Acceptance Criteria
QA Steps
Additional information
There are potential red flags and solution we can attack this issue.
Red flags
We have API callbacks that are configured by users and will need DNS resolution. For these, we'd have to build a list and potentially make wildcards out of governmental domain names. But that might not be sufficient from the moment that a user adds a non-governemental domain to be supported.
We'd need to have a more dynamic way to update the allow list that triggers when a user update an API callback. This could allow GCNotify to be more precise too in which DNS we have in the allow list (vs having a general wild card pattern).
Reuse SRE team Terraform module
The SRE team has a handy Terraform module we can use to define Route 53 firewall that we configure with a list of allowed/blocked domains. An example in scan-files is showed here.
The issue with that solution is that we will have to define a static list of domains that are allowed. Our API callbacks that can contain various domain names might pose a problem with this, as we'd require some more dynamic configuration.
Dynamic configuration of allowed domains triggered on API callback changes
We could configure the allowed list of domains upon trigger of API callback changes from GCNotify users. We can copy what the SRE team did with the Route 53 firewall and add extra hooks in our application code to configure the allowed list dynamically.
This would require a custom solution and more resources to implement.
Source issue
This was reported by the SRE team via this issue.