Inhoudsopgave:
In april werd een Nederlandse hacker gearresteerd voor wat de grootste gedistribueerde denial of service-aanval ooit wordt genoemd. De aanval werd gepleegd op Spamhaus, een antispamorganisatie, en volgens ENISA, het IT-beveiligingsagentschap van de Europese Unie, bereikte de belasting van de infrastructuur van Spamhaus 300 gigabit per seconde, drie keer het vorige record. Het veroorzaakte ook grote internetcongestie en verstoorde de internetinfrastructuur wereldwijd.
DNS-aanvallen zijn natuurlijk nauwelijks zeldzaam. Maar terwijl de hacker in de Spamhaus-zaak alleen zijn doel wilde beschadigen, wezen de grotere gevolgen van de aanval ook op wat velen een grote fout in de internetinfrastructuur noemen: het Domain Name System. Als gevolg hiervan hebben technici en zakenmensen door recente aanvallen op de kern-DNS-infrastructuur naar oplossingen gezocht. Dus, hoe zit het met jou? Het is belangrijk om te weten welke opties u heeft om de DNS-infrastructuur van uw eigen bedrijf te versterken en hoe de DNS-rootservers werken. Laten we daarom eens kijken naar enkele van de problemen en wat bedrijven kunnen doen om zichzelf te beschermen. (Meer informatie over DNS in DNS: één protocol om ze allemaal te regeren.)
Bestaande infrastructuur
Het Domain Name System (DNS) is van een tijd dat het internet is vergeten. Maar dat maakt het geen oud nieuws. Met de steeds veranderende dreiging van cyberaanvallen, heeft DNS in de loop der jaren veel aandacht gekregen. In de kinderschoenen bood DNS geen vormen van authenticatie aan om de identiteit van een afzender of ontvanger van DNS-query's te verifiëren.
In feite zijn de kernnaamservers of rootservers al vele jaren onderworpen aan uitgebreide en gevarieerde aanvallen. Tegenwoordig zijn ze geografisch divers en worden ze beheerd door verschillende soorten instellingen, waaronder overheidsinstanties, commerciële entiteiten en universiteiten, om hun integriteit te behouden.
Het is verontrustend dat sommige aanvallen in het verleden enigszins succesvol zijn geweest. Een verlammende aanval op de root-serverinfrastructuur vond bijvoorbeeld plaats in 2002 (lees hier een rapport over). Hoewel het geen merkbare impact had voor de meeste internetgebruikers, trok het wel de aandacht van de FBI en het Amerikaanse ministerie van Binnenlandse Veiligheid, omdat het zeer professioneel en zeer gericht was en negen van de 13 operationele rootservers trof. Als het langer dan een uur had geduurd, zeggen experts, zouden de resultaten catastrofaal kunnen zijn geweest, waardoor elementen van de DNS-infrastructuur van het internet vrijwel nutteloos waren geworden.
Een dergelijk integraal onderdeel van de internetinfrastructuur verslaan zou een succesvolle aanvaller veel macht geven. Als gevolg hiervan is sindsdien aanzienlijke tijd en investering besteed aan de kwestie van het beveiligen van de root-serverinfrastructuur. (Je kunt hier een kaart bekijken met rootservers en hun services.)
DNS beveiligen
Afgezien van de kerninfrastructuur, is het even belangrijk om te overwegen hoe robuust de DNS-infrastructuur van uw eigen bedrijf kan zijn tegen zowel aanvallen als falen. Het is bijvoorbeeld gebruikelijk (en vermeld in sommige RFC's) dat naamservers zich op geheel verschillende subnetten of netwerken moeten bevinden. Met andere woorden, als ISP A een volledige uitval heeft en uw primaire naamserver offline valt, zal ISP B uw belangrijke DNS-gegevens nog steeds aan iedereen verstrekken die hierom vraagt.
Domain Name System Security Extensions (DNSSEC) zijn een van de meest populaire manieren waarop bedrijven hun eigen nameserverinfrastructuur kunnen beveiligen. Dit zijn een add-on om ervoor te zorgen dat de machine die verbinding maakt met uw naamservers is wat het zegt. DNSSEC staat ook authenticatie toe om te identificeren waar de verzoeken vandaan komen, evenals om te verifiëren dat de gegevens zelf onderweg niet zijn gewijzigd. Vanwege het openbare karakter van het domeinnaamsysteem garandeert de gebruikte cryptografie echter niet de vertrouwelijkheid van de gegevens, noch heeft het enig idee over de beschikbaarheid ervan als delen van de infrastructuur een beschrijving niet hebben.
Een aantal configuratierecords wordt gebruikt om deze mechanismen te leveren, waaronder RRSIG-, DNSKEY-, DS- en NSEC-recordtypen. (Voor meer informatie, bekijk 12 DNS-records uitgelegd.)
RRISG wordt gebruikt wanneer DNSSEC beschikbaar is voor zowel de machine die de vraag indient als degene die deze verzendt. Dit record wordt samen met het gevraagde recordtype meegestuurd.
Een DNSKEY met ondertekende informatie kan er zo uitzien:
ripe.net een DNSKEY plaat 257 3 5 AwEAAXf2xwi4s5Q1WHpQVy / kZGyY4BMyg8eJYbROOv3YyH1U8fDwmv6k BVxWZntYtYUOU0rk + Y7vZCvSN1AcYy0 / ZjL7cNlkc3Ordl2DialFHPI6 UbSQkIp3l / 5fSWw5xnbnZ8KA7g3E6fkADNIEarMI4ARCWlouk8GpQHt1 1wNW1c65SWB8i958WZJ6LI0pOTNK BIx8u98b + + EVr7C08dPpr9V6Eu / 7 3uiPsUqCyRqMLotRFBwK8KgvF9KO1c9MXjtmJxDT067oJoNBIK + gvSO9 QcGaRxuGEEFWvCbaTvgbK4E0OoIXRjZriJj8LXXLBEJen6N0iUzj8nqy XSCm5sNxrRk =
De DS, of gedelegeerde ondertekenaar, wordt gebruikt om de vertrouwensketen te helpen authenticeren, zodat een ouder en een kinderzone met een extra mate van comfort kunnen communiceren.
NSEC of volgende beveiligde items gaan in wezen naar het volgende geldige item in een lijst met DNS-items. Het is een methode die kan worden gebruikt om een niet-bestaande DNS-vermelding te retourneren. Dit is belangrijk zodat alleen geconfigureerde DNS-vermeldingen als echt worden vertrouwd.
NSEC3, een verbeterd beveiligingsmechanisme om aanvallen in woordenboekstijl te helpen verminderen, werd in maart 2008 geratificeerd in RFC 5155.
DNSSEC-ontvangst
Hoewel veel voorstanders hebben geïnvesteerd in de inzet van DNSSEC, is dit niet zonder critici. Ondanks het vermogen om aanvallen zoals man-in-the-middle-aanvallen te helpen voorkomen, waarbij query's kunnen worden gekaapt en op een onjuiste manier worden ingevoerd naar degenen die DNS-query's genereren, zijn er vermeende compatibiliteitsproblemen met bepaalde delen van de bestaande internetinfrastructuur. Het belangrijkste probleem is dat DNS meestal het minder bandbreedte-hongerige User Datagram Protocol (UDP) gebruikt, terwijl DNSSEC het zwaardere Transmission Control Protocol (TCP) gebruikt om zijn gegevens heen en weer te sturen voor grotere betrouwbaarheid en verantwoording. Grote delen van de oude DNS-infrastructuur, die 24 uur per dag, zeven dagen per week doorspekt worden met miljoenen DNS-aanvragen, kunnen mogelijk niet in staat zijn om het verkeer te vergroten. Toch geloven velen dat DNSSEC een belangrijke stap is in de richting van het beveiligen van de internetinfrastructuur.
Hoewel niets in het leven is gegarandeerd, kan het nemen van enige tijd om uw eigen risico's te overwegen, in de toekomst veel dure hoofdpijn voorkomen. Door DNSSEC te implementeren, kunt u bijvoorbeeld uw vertrouwen in delen van uw belangrijkste DNS-infrastructuur vergroten.
