I was teaching this week at University. It was a pretty normal class until I heard the following from one of my students: What happened to google? A couple of seconds after, many people started to make the same complaint and one minute after nobody had access to google. I typed the google URL from my computer and got the following screen: First thing I though was that google suffered an attack. Looking further, I queried for the current google IP and found the following: When I looked for the owner of that IP address, ARIN says it is not precisely google. I performed a nslookup from another domain and got the correct ip address for google: At this time I found out we were victim of a DNS cache poisoning attack.Since the network admin was not at his office because class was in the night, there was nothing I could do but wait for the DNS cache to expire. How this attack works and How we can protect ourselves The DNS process works as follows to resolve ip address from a fully qualified domain name (FQDN):
The attack works as follows:
How do we protect ourselves from the attack?
Any other protection measure you want to share with us? Please use our contact form. Manuel Humberto Santander Peláez | http://manuel.santander.name | http://twitter.com/manuelsantander |
Manuel Humberto Santander Pelaacuteez 195 Posts ISC Handler Jun 27th 2011 |
Thread locked Subscribe |
Jun 27th 2011 1 decade ago |
For those of you using a Windows DNS server, the source port randomization is built-in to Windows 2008 R2's DNS server and other versions that have 'Security Update MS08-037' applied.
http://www.microsoft.com/technet/security/Bulletin/ms08-037.mspx |
Anonymous |
Quote |
Jun 27th 2011 1 decade ago |
Test My DNS
> https://www.dns-oarc.net/oarc/services/dnsentropy . |
Jack 160 Posts |
Quote |
Jun 27th 2011 1 decade ago |
"First thing I though was that google suffered an attack"
How often did this happen? "If you hear hoofbeats–don’t think of zebras" ... |
Jack 27 Posts |
Quote |
Jun 28th 2011 1 decade ago |
Allow me to focus on two points of how to protect :
1) "do not allow recursion from outside ..." I agree, don't. But if the logs of the cached poisoned server were analysed, probably one would find that the attack was launched by an internal device !!! Cache poisoning, eg Dan Kaminsky style, can only be successful (in a reasonable period of time) if there is sufficient bandwidth between attacker and victim. This being said : you cannot forbid your internal caching name server to service your internal clients ... 2) Use DNSSEC If you are not using DNSSEC, you're game for attackers. But what precisely *is* using DNSSEC ? a) do offer signatures that can be validated This is more or less implied by the statement that "root servers support it". It is also the essential contribution in "DNSSEC tips", posted as follow up on this diary. b) (MOSTLY OVERLOOKED) do validate signatures It is useless to offer signatures that can be validated, if the receiver of the signature ignores them. eu. also is ready for DNSSEC, with complete chain-of-trust since early september 2011. Marc Lampo EURid Security Officer |
Jack 7 Posts |
Quote |
Jun 29th 2011 1 decade ago |
Sorry, that should have been :
eu. is ready for DNSSEC since september 2010 (not 2011 !) Marc Lampo |
Jack 7 Posts |
Quote |
Jun 29th 2011 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!