That is why any GOOD sysadmin will set up the system so that there is a single DNS server for the plant, and that server and that server alone is allowed to send and receive DNS packets to the greater Internet - all other machines are to use the local DNS server.
Not only does this GREATLY reduce the amount of DNS traffic a shop produces (by caching all requests locally) it helps prevent this sort of foolishness by requiring all packets to be well formed DNS packets - else the server drops them.
Then, you can block any client that makes more than a few requests a second.
Yes, it is easier to set up a firewall to be very porous to outbound traffic, but it is more secure to deny all direct access, and force clients to run through proxies for the various services.
The packets in question are (or at least could be) well formed.
Imagine that I own ISpy.com, and a user does a lookup on "user.jsmith.passwd.12345.ispy.com". Your server, in the middle, will forward that request to the NS for ispy.com more or less unchanged. And it doesn't have to be this obvious - it would certainly be easy enough to come up with some form of steganography appropriate to use in DNS.
Not that proxies are a bad idea, but in this case proxies will not prevent the attack. Mostly, they'll
Yeah, check out the slides. I rather obsessively follow the spec (limit to Base32 my upstream queries, Base64 my downstream TXT records, though I could just as easily use Base32'd CNAME's or MX's).
The whole point is that DNS is equivalent to every web server proxying, and that this proxy service does have security implications.
But please, cache stuff locally:-) It makes my radio hack work much much better.
Gosh, I even went so far as to state, very clearly, that a key part of defeating this sort of thing was, and I quote my previous post, "block any client that makes more than a few requests a second."
Now, lets see. DNS packets are limited to 512 bytes per spec (and having just finished implementing an DNS client the spec is quite clear in my mind). Let us take the commonly used value of "less than ten" for the term "a few".
So, you have less than 5120 bytes/second of throughput. That's assuming that you don
This attack works through proxies, because the proxy will simply relay a well-formed DNS request straight to the attackers DNS server, and return the well-formed DNS response back to the client.
Read the slides. It's quite impressive, even if it has also been known for a large number of years. No, Dan is not the first to realise the potential of this.
The opulence of the front office door varies inversely with the fundamental
solvency of the firm.
That's why you use proxies! (Score:5, Informative)
Not only does this GREATLY reduce the amount of DNS traffic a shop produces (by caching all requests locally) it helps prevent this sort of foolishness by requiring all packets to be well formed DNS packets - else the server drops them.
Then, you can block any client that makes more than a few requests a second.
Yes, it is easier to set up a firewall to be very porous to outbound traffic, but it is more secure to deny all direct access, and force clients to run through proxies for the various services.
Doesn't work that way (Score:3, Insightful)
Imagine that I own ISpy.com, and a user does a lookup on "user.jsmith.passwd.12345.ispy.com". Your server, in the middle, will forward that request to the NS for ispy.com more or less unchanged. And it doesn't have to be this obvious - it would certainly be easy enough to come up with some form of steganography appropriate to use in DNS.
Not that proxies are a bad idea, but in this case proxies will not prevent the attack. Mostly, they'll
Re:That's why you use proxies! (Score:3, Informative)
The whole point is that DNS is equivalent to every web server proxying, and that this proxy service does have security implications.
But please, cache stuff locally
--Dan
Re:That's why you use proxies! (Score:2)
Now, lets see. DNS packets are limited to 512 bytes per spec (and having just finished implementing an DNS client the spec is quite clear in my mind). Let us take the commonly used value of "less than ten" for the term "a few".
So, you have less than 5120 bytes/second of throughput. That's assuming that you don
Re:That's why you use proxies! (Score:1)
Read the slides. It's quite impressive, even if it has also been known for a large number of years. No, Dan is not the first to realise the potential of this.