SWITCH DNS/DNSSEC Audit

SWITCH is regularly assessing parts of the registry infrastructure in technical audits. The goal of these audits is to find operational or software vulnerabilities before attackers do. For 2013 we wanted to audit the DNS/DNSSEC related aspects of the registry and DNS name server service operation. The introduction of DNSSEC for the ch. and li. zones in early 2010 brought a lot of changes to our DNS management software, the registry application and to the registrar interface. Naturally, most changes occurred in the DNS management software, which is responsible for properly signing the zones and rolling the keys.

In 2009, when we started the DNSSEC project internally, mature support for DNSSEC was close to inexistent, so we ended up writing our own scripts and tools around ISC BIND. In the mean time BIND added support for inline-signing and OpenDNSSEC matured a lot, just to name a few examples. If you are on the verge of signing your zone, I suggest you look at already existing solutions first. I don’t think that today there is still a need to develop your own script and tools. However, ours have been in production since then. So we felt, it was high time to get an independent view on our implementation.

Continue reading “SWITCH DNS/DNSSEC Audit”

Was kommt nach DNS Response Rate Limiting?

Werden autoritative DNS-Server über reflektierende DNS-Angriffe missbraucht, zum Beispiel um in einem Distributed Denial of Service (DDoS) Angriff ein Zielsystem zu überlasten, so ist eine der vorgeschlagenen Massnahmen DNS Response Rate Limiting (DNS RRL) zu aktivieren.

SWITCH hat auf diesem Blog bereits in früheren Posts über DNS Angriffe und Massnahmen berichtet. In diesem Artikel möchten wir unsere neusten Beobachtungen im Betrieb von DNS RRL teilen und zeigen, dass es Anzeichen gibt, dass die Angreifer die Schwächen von DNS RRL ausnutzen um weiterhin ihre Angriffe durchführen zu können.

Stärken und Schwächen von DNS RRL
Für viele autoritative DNS Serverbetreiber war DNS RRL eine ersehnte Lösung um die Serverlast und vor allem die ausgehende Serverbandbreite aufgrund von reflektierenden DNS-Angriffen einzuschränken. DNS RRL lässt für einen IP-Adressbereich nur eine bestimmte Anzahl identische DNS Antworten zu. Wird der konfigurierte Schwellwert überschritten, verwirft DNS RRL zum einen die DNS-Antwort. Für einen anderen Teil der Antworten wird das “Truncated”-Bit (TC) in der Antwort gesetzt, damit wird der DNS Resolver aufgefordert, die Anfrage noch einmal über TCP zu stellen. Da bei reflektierenden DNS-Angriffen die Quelladresse gefälscht wird, kommt nie eine Verbindung über TCP zu Stande. Im Gegensatz zu Firewall-Regeln hat der DNS RRL Ansatz den Vorteil, dass bei einem leicht geänderten Angriffs-Pattern (z.B. Query-Name ändert) die implementierten Firewall-Regeln nicht angepasst werden müssen. Kurz, DNS RRL ist sehr effektiv gegenüber Angriffen, bei denen DNS-Anfragen gesendet werden, welche in identischen Antworten resultierten.
Continue reading “Was kommt nach DNS Response Rate Limiting?”

DNSSEC Signierungs-Algorithmus wechseln

Eine DNS-Zone zu signieren ist mit heutiger Software nicht mehr schwierig oder kompliziert. Die Schwierigkeiten im Betrieb von signierten Zonen sind selten angewendete Prozeduren, wofür teilweise noch die Software-Unterstützung fehlt, sei dies in der Signierungssoftware oder in Monitoring- und Debugging-Tools. Eine solche selten angewendete Prozedur ist der Wechsel des DNSSEC Signierungs-Algorithmus.

Als SWITCH die DNSSEC-Signierung für die ccTLDs CH und LI im Jahr 2009 entwickelte und testete, entschied sie sich für den DNS Security-Algorithmus RSASHA1-NSEC3-SHA1 (RFC 5155). Aktuell ist der DNS Security-Algorithmus RSA/SHA-256 (RFC5702) einer der verbreitetsten Signierungs-Algorithmen unter TLDs (NANOG 56, E. Lewis), welcher auch von der Root-Zone verwendet wird. SWITCH hat in den letzten Wochen einen sogenannten Key Algorithm Rollover durchgeführt und auf den DNS Security-Algorithmus RSA/SHA-256 gewechselt.

Continue reading “DNSSEC Signierungs-Algorithmus wechseln”

Analysing DNS traffic using PacketQ

Our authoritative only name-servers are every once in a while hit by strange DNS queries. To spot anomalies we use DSC (DNS Statistic Collector), which allows exploring many details of DNS requests and responses to and from our name-servers. Usually one can already get a good sense of what has happened with DSC. However often, deep packet inspection is needed to get the full picture.

DSC Statistic showing query-type MX and ANY traffic anomalies
DSC Statistic showing query-type MX and ANY traffic anomalies

DNS traffic heading towards our authoritative only name-servers is stored for a few days in PCAP. Should we have any need to analyse some of the data we can then easily do so. Analysing very large PCAP files may sound cumbersome but thanks to PacketQ this is actually very easy and fast. PacketQ was originally developed by IIS.SE and is open source. It is a command line tool to run sql queries directly on PCAP files. It exports some IP and UDP header fields and most importantly all DNS protocol fields.

Continue reading “Analysing DNS traffic using PacketQ”

CH-Zone Opfer eines DNS-Amplifikations-Angriffes

Erst ein paar Wochen ist es her, dass wir über DDoS-Angriffe durch Reflektierende DNS-Amplifikation gepostet haben. Heute Morgen um 4 Uhr wurde nun erstmals auch die CH-Zone für einen solchen DNS-Amplifikations-Angriff missbraucht.

NetFlow Daten: Ein- und Ausgehender Datenverkehr der SWITCH CH-Nameserver
NetFlow Daten: Ein- und Ausgehender Datenverkehr der SWITCH CH-Nameserver

Die DNS-Anfragen lauten auf ‘CH’. mit dem Query-Type ‘ANY’. Zusätzlich wird die EDNS-Erweiterung aktiviert, was es ermöglicht in einer UDP-Antwort mehr als 512 Bytes zu erhalten. Ohne EDNS würde der autoritative DNS-Server mit dem gesetzten Flag „TC“ (Truncated) antworten, womit der Client aufgefordert wird, die DNS-Anfrage nochmals über TCP zu schicken. Bei gespooften DNS-Anfragen will man das natürlich verhindern, deshalb ist hier EDNS aktiviert. Wir sehen die DNS-Anfragen von mehreren Quell-Adressen, jedoch ist eine IP-Adresse besonders benutzt. Diese IP-Adresse, welches das Opfer des DDoS-Angriffes ist, empfängt alle Antworten.

Warum wird gerade die CH-Zone missbraucht?

Continue reading “CH-Zone Opfer eines DNS-Amplifikations-Angriffes”