4 ms·

I'm really struck by how hostile to enterprise security these proposals are. Yes, I know that the security folks will adapt (they'll have to), but it still feel

by g-clef 9y ago

I'm really struck by how hostile to enterprise security these proposals are. Yes, I know that the security folks will adapt (they'll have to), but it still feels like there's a lot of baby+bathwater throwing going on. DNS over HTTP is a prime example: blocking outbound DNS for all but a few resolvers, and monitoring the hell out of the traffic on those resolvers is a big win for enterprise networks. What the RFC calls hostile "spoofing" of DNS responses enterprise defenders call "sinkholing" of malicious domains. Rather than trying to add a layer of validation to DNS to provide the end user with assurance that the DNS request they got really is the name they asked for (and, in theory, allow the enterprise to add their own key to sign sinkhole answers) instead DOH just throws the whole thing out...basically telling enterprise defenders "fuck your security controls, we hate Comcast too much to allow anyone to rewrite DNS answers." "Fuck your security controls, we hate Comcast" is, I think, a bad philosophy for internet-wide protocols. (That's basically what the TLS 1.3 argument boils down to also...and that's a shame.)

slrz 9y ago
As implemented, all these "enterprise security" things are mostly indistinguishable from malicious attacks. Of course they break when you start tightening security. Forging DNS responses is a horrible idea (and already breaks with DNSSEC). I have a hard time to comprehend how this can be considered a reasonable security measure.
- g-clef 9y ago
  > I have a hard time to comprehend how this can be considered a reasonable security measure. OK, let's walk it through. Task: block access to "attacker.com" and all it's subdomains. Reason: Maybe it's a malware command and control, maybe it's being used for DNS tunneling, whatever. Blocking a domain that's being used for malicious behavior is a reasonable thing for an enterprise to want to accomplish. Option 1: Block by IP at the firewall. Problems: Attackers can simply point the domain to another IP, so you're constantly playing whack-a-mole and constantly behind the attacker. Also, if it's a DNS tunnel the DNS answer is what's interesting, not the traffic to the actual IP. Result: Fail, doesn't solve the problem. Option 2: Block by DNS Name at the firewall. Problems: Requires the firewall to understand the protocols involved, which they have shown themselves to be inconsistent at, at the best of times. Also, doing regex on every DNS query packet(in order to find all subdomains) doesn't scale. Result: Fail, doesn't scale. Option 3: Block with local agent. Problems: Tablets, phones, appliances, printers can't run a local agent. Result: Fail. Not complete coverage Option 4: Block outbound DNS except for approved resolvers, give those resolvers an RPZ feed of malicious domains. Problem: Clients have to be configured to use those resolvers, but otherwise none. Result: Pass. It's standards compliant, and DNSSec isn't an issue since the resolver never asks for the attackers DNS answer, so they never get the chance to offer DNSSec. That's why option 4 (or some variant of it) is popular in enterprises. It accomplishes the task in a standards-compliant way, and covers the entire enterprise in a way that scales well. DOH blows this up. So, the question becomes: in a world with DOH, how is an enterprise supposed to completely and scalably block access to "attacker.com" and all its subdomains? So far, the answer has been "you don't." I think that is a really shitty answer to someone who's trying to accomplish something reasonable.
  - Dylan16807 9y ago
    If the attacker can get new IPs, they can get new domains. Why is pure domain-blocking a goal in the first place? The one-size-fits-all answer with DOH is the same as without it: Tell your devices to use/trust the MitM.

by g-clef 9y ago

slrz 9y ago

As implemented, all these "enterprise security" things are mostly indistinguishable from malicious attacks. Of course they break when you start tightening security. Forging DNS responses is a horrible idea (and already breaks with DNSSEC). I have a hard time to comprehend how this can be considered a reasonable security measure.

g-clef 9y ago
> I have a hard time to comprehend how this can be considered a reasonable security measure. OK, let's walk it through. Task: block access to "attacker.com" and all it's subdomains. Reason: Maybe it's a malware command and control, maybe it's being used for DNS tunneling, whatever. Blocking a domain that's being used for malicious behavior is a reasonable thing for an enterprise to want to accomplish. Option 1: Block by IP at the firewall. Problems: Attackers can simply point the domain to another IP, so you're constantly playing whack-a-mole and constantly behind the attacker. Also, if it's a DNS tunnel the DNS answer is what's interesting, not the traffic to the actual IP. Result: Fail, doesn't solve the problem. Option 2: Block by DNS Name at the firewall. Problems: Requires the firewall to understand the protocols involved, which they have shown themselves to be inconsistent at, at the best of times. Also, doing regex on every DNS query packet(in order to find all subdomains) doesn't scale. Result: Fail, doesn't scale. Option 3: Block with local agent. Problems: Tablets, phones, appliances, printers can't run a local agent. Result: Fail. Not complete coverage Option 4: Block outbound DNS except for approved resolvers, give those resolvers an RPZ feed of malicious domains. Problem: Clients have to be configured to use those resolvers, but otherwise none. Result: Pass. It's standards compliant, and DNSSec isn't an issue since the resolver never asks for the attackers DNS answer, so they never get the chance to offer DNSSec. That's why option 4 (or some variant of it) is popular in enterprises. It accomplishes the task in a standards-compliant way, and covers the entire enterprise in a way that scales well. DOH blows this up. So, the question becomes: in a world with DOH, how is an enterprise supposed to completely and scalably block access to "attacker.com" and all its subdomains? So far, the answer has been "you don't." I think that is a really shitty answer to someone who's trying to accomplish something reasonable.
- Dylan16807 9y ago
  If the attacker can get new IPs, they can get new domains. Why is pure domain-blocking a goal in the first place? The one-size-fits-all answer with DOH is the same as without it: Tell your devices to use/trust the MitM.