3 ms·

I think the bane is when you make it hard to get exceptions. If a developer can add a specific IP, or ideally a domain, to the "allow" group, automatically, tha

I think the bane is when you make it hard to get exceptions. If a developer can add a specific IP, or ideally a domain, to the "allow" group, automatically, that's far less impact than if you have to fill in pages of paper explaining why you need outbound access. In the latter case, developers will work around your restrictions, and you're simply left with a false sense of security.

EvanAnderson 5y ago
So many vendors (I work with a lot of COTS software-- not in-house-developed) have absolutely no idea what their communication dependencies are (client-to-server, server-to-server, etc). I've ended up being the first sysadmin to ask more times than I'd like to count. I, like the grandparent poster suggested, prefer to put applications where the developer demands carte blanche access to the Internet via TCP port 443 behind a MiTM proxy and whitelist domains. (I don't do as much to stop DNS-based exfiltration as I should be doing, though. It's probably a good time to revisit that using this vulnerability as a practical justification.)
mrweasel 5y ago
Arguably you shouldn't make too hard to get exceptions, but what we frequently see is that the developer actually don't appear to know that their code is make outbound connects, and they certain don't mention it as part of the requirements. We've frequently build setups where machines are completely isolated, because the requirements do not mention that this software will connect to servers on the internet. When we install the software it then fails to work, because it was never testet in a closed environment. I've seen Java applications fail to boot because they cannot can't pull a XSD from the internet... Why isn't that just bundled? Why do you need to get that a boot time? What is that other server is down? But you're right, valid firewall opening should not be hard get.

EvanAnderson 5y ago

So many vendors (I work with a lot of COTS software-- not in-house-developed) have absolutely no idea what their communication dependencies are (client-to-server, server-to-server, etc). I've ended up being the first sysadmin to ask more times than I'd like to count. I, like the grandparent poster suggested, prefer to put applications where the developer demands carte blanche access to the Internet via TCP port 443 behind a MiTM proxy and whitelist domains. (I don't do as much to stop DNS-based exfiltration as I should be doing, though. It's probably a good time to revisit that using this vulnerability as a practical justification.)

mrweasel 5y ago

Arguably you shouldn't make too hard to get exceptions, but what we frequently see is that the developer actually don't appear to know that their code is make outbound connects, and they certain don't mention it as part of the requirements. We've frequently build setups where machines are completely isolated, because the requirements do not mention that this software will connect to servers on the internet. When we install the software it then fails to work, because it was never testet in a closed environment. I've seen Java applications fail to boot because they cannot can't pull a XSD from the internet... Why isn't that just bundled? Why do you need to get that a boot time? What is that other server is down? But you're right, valid firewall opening should not be hard get.