Project

General

Profile

Actions

tickets #152464

open

overly zealous egress filtering

Added by pjessen 5 months ago. Updated 4 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
Network
Target version:
-
Start date:
2023-12-12
Due date:
% Done:

0%

Estimated time:

Description

Whilst investigating #152071, I tried resolving some names via Google's public DNS, 8.8.8.8 and 4.4.4.4. No luck. Of course the same with cloudflare and quad9. IPv6 didn't work either.
Topic for discussion - aren't we being a little too zealous with the egress filtering?

Actions #1

Updated by crameleon 5 months ago

  • Category set to Network
  • Private changed from Yes to No

Hi,

we implement a whitelist based approach - traffic which is required for the operation of a service can be allowed on a case by case basis. All other traffic is denied.
What is the requirement behind connecting to arbitrary nameservers on the internet? Using our internal nameservers should be sufficient. Additionally our internal nameservers provide better functionality by offering DNS64.
Unless there is a legitimate requirement I prefer not to make exceptions to the rule.

Actions #2

Updated by pjessen 5 months ago

crameleon wrote in #note-1:

we implement a whitelist based approach - traffic which is required for the operation of a service can be allowed on a case by case basis. All other traffic is denied.

Yes, as I wrote, an "overly zealous egress filtering".

What is the requirement behind connecting to arbitrary nameservers on the internet? Using our internal nameservers should be sufficient.

That it really secondary, but in this particular case, our own internal nameservers did not provide the expected results - using others to verify is a normal part of diagnosing an issue.

Unless there is a legitimate requirement I prefer not to make exceptions to the rule.

Georg, how about presenting the "legitimate requirement" for this rule, this overly zealous egress filtering? We didn't have it before, why do we have it now?

Actions #3

Updated by crameleon 5 months ago

That it really secondary, but in this particular case, our own internal nameservers did not provide the expected results - using others to verify is a normal part of diagnosing an issue.

You verified that it's an issue with our internal nameservers using your client, which I acknowledged. I apologize there is an issue with our internal nameservers, but it is a problem that needs to be solved and not worked around.

Georg, how about presenting the "legitimate requirement" for this rule, this overly zealous egress filtering? We didn't have it before, why do we have it now?

I do not agree with your definition of "overly zealous". Whitelisting ...

  1. is a common network security practice to facilitate granting the least access possible. I applied the principle from our mother infrastructure which follows a thorough security design.
  2. makes auditing easier - a network operator can tell legitimate from malicious traffic apart by being able to map all traffic to documented traffic rules.
  3. helps us keeping the public IP space, which is associated with our name, clean. We are responsible for not generating any abusive outbound traffic.

So far, I am not aware of any hard complaints, all legitimate requirements were fulfilled to the requesters satisfaction.

I understand you are used to arbitrary network access on arbitrary hosts from the past setup, and I understand the change requires some adjustment with troubleshooting certain situations. I see this adjustment as a positive, as it makes administrators think about the commands they execute on a system more. Does one really need to install arbitrary debugging tools and connect to various internet servers from a production machine? Generally debugging tools can be called from an administrative workstation - in this particular case, as you have successfully done, using your own internet connected client. In other cases, where internal services need to be validated, from an administrative bastion. If it is really needed to execute such debugging activity from a production machine, the needful can be temporarily permitted.

I would also like to point out that everyone was given the opportunity to attend the meetings in which the network design was introduced and discussed.

Actions #4

Updated by crameleon 4 months ago

  • Status changed from New to Feedback
  • Assignee set to pjessen
Actions

Also available in: Atom PDF