| |||||||||||||
Some stupid ideasSome stupid ideasPosted Aug 13, 2008 18:53 UTC (Wed) by rvfh (subscriber, #31018)Parent article: Details of the DNS flaw revealed
An improvement would be to not accept the first answer, and wait a bit to make sure only one matching answer is received. If more than one, try again! Also, if the bad guy is sending loads of wrong answers, this seems easy-ish to guess that we are under attack. Although I don't know what to do with that information...
(Log in to post comments)
Some stupid ideas Posted Aug 13, 2008 19:13 UTC (Wed) by drag (subscriber, #31333) [Link] > Although I don't know what to do with that information... Block him with firewall rules, would be my guess, or build it into the DNS server to deny them. Similar to setting up rules to block people that attempt to brute force a ssh password or whatnot. Of course that would lead to interested DOS possiblities. Like having some goofy webpage or emailing somebody with a html email that have images that link to thousands of non-existent servers with fake dns names.
Some stupid ideas Posted Aug 13, 2008 20:46 UTC (Wed) by darwish07 (subscriber, #49520) [Link] The packets does not have to be with the same IP source address and UDP port. This is UDP, The attacker source IP address can be changed when every new packet is sent without affecting the end result.
Some stupid ideas Posted Aug 14, 2008 6:02 UTC (Thu) by rvfh (subscriber, #31018) [Link] Yeah, the last thing we want is to turn a defensive measure into a DoS vulnerability :-)
DNS hacking: Blacklisting source IP address Posted Aug 15, 2008 20:42 UTC (Fri) by giraffedata (subscriber, #1954) [Link] This is UDP, The attacker source IP address can be changed when every new packet is sent without affecting the end result. The source IP address is not UDP; it's basic IP. The attacker can't simply choose the source IP address because whoever routes his IP packet into the Internet will not accept it if its source IP address is someone else's (and the attacker isn't trusted as a router for that someone). You have to pull off a pretty high level hack of the Internet before you can spoof a source IP address.
DNS hacking: Blacklisting source IP address Posted Aug 16, 2008 8:21 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link] actually, there are large chunks of the Internet that do not check the source IP when routing the packets. and once you get a hop or so from the source (real or forged) this is nessasary becouse the routers could be dealing with packets from just about anywhere. in theory every company/personal router and every ISP border router (both to the customers and to other ISPs) has such filters. in practice relativly few of them do. this is even true of the major international peering points. every year or so you hear of a country that got knocked off the Internet due to mistakes that someone makes with BGP routing configuration. these useually get detected and fixed within a short time and so don't make the news, but every once in a while the outage lasts long enough to get attention. I've been at the recieving end of enough forged attacks to know that it's definantly possible. although I'll admit that with botnets getting as large as they are, forged packets are not used as much as they used to be.
DNS hacking: Blacklisting source IP address Posted Aug 23, 2008 12:06 UTC (Sat) by darwish07 (subscriber, #49520) [Link]
Yes, I agree. but what I meant is that UDP puts less restrictions on the sender IP address.
IP forging can happen more easily with UDP since no handshake or any kind of replies are needed. Only the forged packet is enough.
Some stupid ideas Posted Aug 13, 2008 23:46 UTC (Wed) by njs (guest, #40338) [Link] You don't even have to wait -- you know something funny is going on from the very first bogus packet you receive (since the attacker has to send thousands of bogus packets before one of them will chance to be valid). That still doesn't tell you what to do, though. Besides page the sysadmin, I mean, which isn't going to be very effective on a consumer router. I guess one of the pieces of information you can extract from the bogus packet is what cache entry the attacker is trying to poison, and then treat that entry more carefully -- e.g., you could put a flag on that entry, and when you receive an apparently valid value, if the flag is set then you clear the flag but *don't* cache the value you received; this would mean that an attacker had to spoof you on two transactions in a row without sending any bogus packets in between in order to successfully poison your cache. You can tune how many bogus packets are required to set the flag and how many valid responses are required to clear the flag to trade-off between safety and joe-job potential, but really if someone is flooding you with thousands of UDP packets then running even dozens of extra queries is not going to be your performance bottleneck.
Some stupid ideas Posted Aug 14, 2008 10:08 UTC (Thu) by NAR (subscriber, #1313) [Link] I think this is a good idea. RFC 1035 states that "TTL is a 32 bit signed integer that specifies the time interval that the resource record may be cached", so this actually would not break the DNS specification.
Some stupid ideas Posted Aug 14, 2008 10:51 UTC (Thu) by rvfh (subscriber, #31018) [Link] In this case, one could ask for each value (or only the ones under attack) twice: - ask value, return to requester with short TTL (a few seconds) - wait a bit - ask value again, if matches use given TTL (or limit it to a few hours) Anyway, it seems the solution is in the repetition, to decrease the probability of success of the attack.
|
|||||||||||||