3 ms·

It feels like the de-facto network policy design methodology, which I am yet to see implemented in open source, is one in which CI/CD test processes observe net

It feels like the de-facto network policy design methodology, which I am yet to see implemented in open source, is one in which CI/CD test processes observe network utilization in test environments and automatically implement restrictions for deployed instances. For example, and ingress-only static content webserver would not require any outbound internet access. The same approach could and should be used for other observable and manageable layers (filesystem access, syscalls, language interpreter-specific function call whitelisting, etc.). I am waiting for a security-focused CI/CD tool to own this space. Even a light touch implementation would surely improve greatly on the status quo.

iampims 9y ago
Your comment reminded me of this talk https://youtu.be/BuFTHOgsgAY https://youtu.be/BuFTHOgsgAY especially the conclusion that something that rely on access patterns can't be trusted because it's almost impossible to validate all code paths.
- contingencies 9y ago
  Perfection is not required.
fulafel 9y ago
Sounds like this kind of setup would autogenerate subtle firewall misconfigurations that result in mysterious failure modes. Like blocking ICMP which breaks TCP path MTU discovery. Or blocking outbound 53/tcp.
- contingencies 9y ago
  Blocking outbound 53/* is often great. Many services don't need DNS (which is usually UDP not TCP) and it is known to be a very frequent covert channel for infiltrators. AFAIK tcp/53 is most frequently used for zone transfers... not something you'd want to encourage on most production servers! Restricted ICMP (certain message types only) could be a default permit. If you have an internal service running over known virtual infrastructure to an external-facing proxy, MTU path discovery may be unnecessary anyway. It doesn't have to be nazi, just better than nothing.
  - fulafel 9y ago
    Those were just some examples - I was trying to point out that this method will generally give you subtly broken firewall rules. (re DNS: the DNS protocol uses both TCP and UDP interchangeably, it switches to TCP when the message size crosses a threshold. Many kinds of DNS messages can be over the limit. See eg https://github.com/moby/moby/issues/24344 https://github.com/moby/moby/issues/24344)
    - contingencies 9y ago
      You don't need to rigidly and purely enforce rules only from test results but rather also embedded wisdom, defaults and recommendations. ICMP is a well known gotcha and the only such protocol in its class. I've personally never seen a fallback to TCP requirement in the wild but you could easily say "if DNS then enable both protocols" as a general rule, and add <received wisdom>. These are easy to add as policies and will result in better rules than manually configured systems in many cases, if documented. Everyone's happy.

iampims 9y ago

Your comment reminded me of this talk https://youtu.be/BuFTHOgsgAY https://youtu.be/BuFTHOgsgAY especially the conclusion that something that rely on access patterns can't be trusted because it's almost impossible to validate all code paths.

contingencies 9y ago
Perfection is not required.

fulafel 9y ago

Sounds like this kind of setup would autogenerate subtle firewall misconfigurations that result in mysterious failure modes. Like blocking ICMP which breaks TCP path MTU discovery. Or blocking outbound 53/tcp.

contingencies 9y ago
Blocking outbound 53/* is often great. Many services don't need DNS (which is usually UDP not TCP) and it is known to be a very frequent covert channel for infiltrators. AFAIK tcp/53 is most frequently used for zone transfers... not something you'd want to encourage on most production servers! Restricted ICMP (certain message types only) could be a default permit. If you have an internal service running over known virtual infrastructure to an external-facing proxy, MTU path discovery may be unnecessary anyway. It doesn't have to be nazi, just better than nothing.
- fulafel 9y ago
  Those were just some examples - I was trying to point out that this method will generally give you subtly broken firewall rules. (re DNS: the DNS protocol uses both TCP and UDP interchangeably, it switches to TCP when the message size crosses a threshold. Many kinds of DNS messages can be over the limit. See eg https://github.com/moby/moby/issues/24344 https://github.com/moby/moby/issues/24344)
  - contingencies 9y ago
    You don't need to rigidly and purely enforce rules only from test results but rather also embedded wisdom, defaults and recommendations. ICMP is a well known gotcha and the only such protocol in its class. I've personally never seen a fallback to TCP requirement in the wild but you could easily say "if DNS then enable both protocols" as a general rule, and add <received wisdom>. These are easy to add as policies and will result in better rules than manually configured systems in many cases, if documented. Everyone's happy.