diff --git a/infra.rst b/infra.rst index ced30e8..ad51c0a 100644 --- a/infra.rst +++ b/infra.rst @@ -1,22 +1,5 @@ Chapter 8. Infrastructure Security ============================================== -.. Brad notes - I really enjoyed the CCR paper with anonymous authors on collateral - damage of China’s censorship (IIRC, causing DNS lookup failures in - other countries). - That paper is not exactly current now, but it is a nice example of - how a state actor can deploy things that break infrastructure - outside its own state boundaries. - My gut feeling is that material on why stock DNS is vulnerable to - attack, what DNSSEC is, how it’s supposed to make things better, - and why it’s hard to deploy would definitely be useful. - And probably the same for BGP and the RPKI. Goldberg has a paper on - why it’s so hard to secure routing; I think it was in Queue. - I wonder if a synthesis of any sort is possible on this - topic. Certainly certificate chains and delegated signature authority - are at the core of both DNSSEC and the RPKI. - Perhaps there is a unifying theme of securing infrastructure with distributed domains of control. - In a way CAs fit this model, too. In the preceding chapters we have focused on the security of @@ -713,9 +696,48 @@ effects in and beyond China. `__. Computer Communications Review, July 2012. - - -8.2.1 DNS Security Extensions (DNSSEC) +8.2.1 DNS Amplification Attacks +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +There is a class of denial-of-service (DoS) attack that leverages the +properties of DNS to attack other systems, rather than being an attack +on DNS itself. Recall that DNS is UDP-based. A name server sends a +response back to the IP address from which a query was sent, and since +there is no TCP connection to establish, it is relatively easy to use +a fake source address in a query. In this case, the name server can be +tricked into sending traffic to some unsuspecting host. And it is not +hard to see how this can be turned into a *distributed* +denial-of-service attack: many hosts (e.g., a set of hosts in a +botnet) can make coordinated requests to a set of name servers, with +all the requests using the same spoofed source address. Not only does +this lead to a lot of traffic heading to the target address, but the +name servers can be make to perform a traffic *amplification* +function, because the response to a DNS query can be much larger than +the query that triggered it. In particular, the DNS query type "ANY" +causes all records for a domain to be returned, which can be a lot of +data returned for a simple query. The handling of such queries has +recently been clarified in an RFC in a manner that should reduce the +impact of ANY queries, but that is not a complete solution to DNS +amplification attacks. + +Three main steps can be taken to reduce these attacks. The first +is to avoid the deployment of "open" resolvers, i.e., resolvers +which will accept queries from anywhere. For example, the resolver +for an enterprise should be configured such that only clients +within that enterprise can send queries to it; it should not accept +queries from the broader Internet. + +The second step is source address validation. Source address +filtering is a tool that can be applied at the boundaries of +autonomous systems to reject traffic with spoofed source +addresses. It may not be 100% effective but it will reduce the +effectiveness of large scale attacks. + +Finally, there are ways to deal with DoS attacks such as the use +of content distribution networks and black-holing of DoS +traffic. We discuss these further in Chapter 9. + +8.2.2 DNS Security Extensions (DNSSEC) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Since DNS queries in the original design are unauthenticated, @@ -810,7 +832,26 @@ This is not to say that protecting DNS is unimportant, however. Interference with DNS is still a vector for censorship and surveillance of Internet usage. For this reason there are other methods of protecting DNS that have started to gain traction more -recently. +recently, as discussed in the next section. + +A final note on DNSSEC is that, by making responses larger, it has the +potential to worsen amplification attacks. The response to a request +to a DNS server that implements DNSSEC contains both a signature and +the key used to verify the signature. That's a significant increase in +the number of bytes returned for a single query. The mitigation +techniques outlined above—source address filtering and DoS +prevention—can still be applied. Additionally, there is an advantage +to using crytographic algorithms that use relatively short keys. For +this reason the EDCSA algorithm may be preferred to RSA, since EDCSA +keys are considerably shorter than RSA keys for comparable levels of +security. + +This small detail illustrates how much of security consists of making +tradeoffs. While adding DNSSEC is a positive in terms of securing the +DNS itself, it has contributed to the risk of DoS attacks leveraging +DNS amplification. Adding security almost always imposes some costs—it +is important to be aware of them and to ensure that the payoff for an +additional mechanism justifies its costs. .. _reading_dnstime: @@ -821,7 +862,9 @@ recently. APNIC Blog, May 2024. -8.2.2 Encrypted DNS (DoH, DoT, ODNS) + + +8.2.3 Encrypted DNS (DoH, DoT, ODNS) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~