View
287
Download
3
Category
Preview:
DESCRIPTION
Adam Obszyński – works at Infoblox as Regional Sales Engineer responsible for CEE. Previously, he worked at Cisco and in few integrators and at ISP in the country. Adam has many years’ experience in designing and in implementation of network solutions. He has been in the industry for 17 years. He is the holder of CISSP and CCIE #8557 certificates. Adam is also the speaker at many conferences in the country and abroad (such as Cisco Live U.S. & EU, Cisco Forum, Cisco Expo, PLNOG). Topic of Presentation: DNSSEC – Cryptography in the service of the secure DNS Language: Polish Abstract: Keyword DNSSEC on Google returns over 2.5 million results. Probably everyone heard term DNSSEC. I will try to systematize information about DNSSEC protocol. I’ll talk about DNSSEC impact on DNS services – from SP and customer perspective. Why is it not used in Poland? Why world uses it? The session should include a mix of theory and practices used today on the Internet. Do You maintain DNS? You are invited then. You will learn how to protect Your data in the DNS system. You can also increase security of your customers :-) Do You use DNS? You are invited too. Learn what you should ask your ISP for. Same for providers, banks and gov. Institutions. No marketing. Just the facts.
Citation preview
DNSSECKryptografia w służbie bezpiecznego DNS
Adam Obszyński
DNSSEC – Co to jest?
3
Co to jest DNSSEC i co on właściwie robi?
Rozszerzenia bezpieczeństwa DNS „DNS Security Extensions”, oryginalnie opisane w RFC 2535 wspierane przez BIND od 1997 roku!
Aktualizacja definicji w roku 2005 w formie RFC 4033-4035 opisujących specyfikacje DNSSEC.
DNSSEC oferuje: – Uwierzytelnia pochodzenie/źródło danych DNS:
• Weryfikuje czy dane zostały wysłane z poprawnego źródła i czy nie zostały podmienione w trakcie transmisji
• Jeżeli weryfikacja będzie błędna wysyłany jest komunikat “SERVFAIL”
– Weryfikuje integralność danych:• Gwarantuje że dane nie zostały podmienione w trakcie transmisji• Nawet “potencjalnie ryzykowne” źródła danych mogą być sprawdzone!
– Uwierzytelnia zaprzeczenie istnienia• Jeżeli serwer, strefa/domena, rekord(y) nie istnieją DNSSEC pozwala to potwierdzić
4
Czego w DNS nie zapewnią nawet najlepsze praktyki ?
Mimo że zalecenia pomagają zmniejszyć ryzyko nie mogą zlikwidować słabości protokołu DNS:– Brak weryfikacji integralności danych– Brak możliwości weryfikacji źródła danych– Brak możliwości weryfikacji odpowiedzi negatywnych
Odporności na następujące ataki:– DNS spoofing– Cache Poisoning
5
Czego DNSSEC nam nie zapewni?
DNSSEC nie szyfruje danych DNS– Rekordy DNS przesyłane są jawnym tekstem
DNSSEC nie chroni przed DoS i innymi atakami bezpośrednimi
6
Jak DNSSEC działa – widok z lotu ptaka
DNSSEC bazuje na kryptografii klucza publicznego– Dwa zestawy kluczy (Key Signing Keys, Zone Signing Keys)
Używa kluczy prywatnych do podpisania RR w strefie DNS. Może to zweryfikować każdy posiadający klucz publiczny.– DNSSEC używa algorytmów RSA/SHA
Dystrybucja kluczy i podpisów bazuje na nowych typach rekordów (Resource Records)– DNSKEY, RRSIG, DS, NSEC, NSEC3, NSEC3PARAM
Na potrzeby DNSSEC dodano nowe flagi (DNS Header Flags)– Checking Disabled (CD)– Authenticated Data (AD)– DNSSEC wymaga użycia EDNS0 (RFC2671)– Używany jest też bit EDNS0 ‘DO’ oznaczający DNSSEC OK
Dystrybucja kluczy bazuje na łańcuchu zaufania (chain of trust). Używana jest hierarchia DNS i ‘Trust Anchors’
DNSSEC – Detale
DNSSEC – Klucze do królestwa
Zone Signing Key (ZSK)– Oznaczenie 256– Używany do podpisywania danych strefy– Każda strefa ma swój własny ZSK
Key Signing Key (KSK)– Oznaczenie 257– Używany do podpisania DNSKEY w strefie– Każda strefa ma swój własny KSK– KSK jest również używany/nazywany Secure Entry Point (RFC3757)
Strefy są podwójnie podpisywane– Dane DNS za pomocą ZSK– ZSK jest podpisywany za pomocą KSK– Klucze nie wygasają automatycznie ale mają oznaczenie daty
aktywności/usunięcia.
Podpisywanie strefy (Zone Signing)
Przygotowanie strefy– RR z poza danej strefy są usuwane– Wszystkie nazwy zapisywane małymi litermami
Sortowanie danych w strefie– Rekordy sortujemy od prawej etykiety– Sortowanie słownikowe– Liczby przed literami– Nieistniejące etykiety przed liczbami– Przykład:
bloxbank.pl poprzedza 0.bloxbank.pl poprzedza www.bloxbank.pl
Przeliczenie i dodanie do strefy rekordów DNSSEC
Sortowanie rekordów
bloxbank.pl. 86400 IN SOA ns1.bloxbank.pl. hostmaster.bloxbank.pl. (20140609021h15m30d1h )
bloxbank.pl. 86400 IN NS ns1.bloxbank.pl.bloxbank.pl. 86400 IN MX 10 mail.bloxbank.pl.bloxbank.pl. 3600 IN A 192.168.0.1mail.bloxbank.pl.86400 IN A 192.168.0.2ns1.bloxbank.pl. 86400 IN A 192.168.0.3sub.bloxbank.pl. 86400 IN NS ns1.sub.bloxbank.pl.www.bloxbank.pl. 86400 IN CNAME bloxbank.pl.
Podpisywanie strefy – dodane klucze
bloxbank.pl. 86400 IN SOA ns1.bloxbank.pl. hostmaster.bloxbank.pl. (20140609031h15m30d1h )
bloxbank.pl. 86400 IN DNSKEY 257 3 5 AwEAAfYh8eqw+…bloxbank.pl. 86400 IN DNSKEY 256 3 5 eeSiesh2eWio+…bloxbank.pl. 86400 IN NS ns1.bloxbank.pl.bloxbank.pl. 86400 IN MX 10 mail.bloxbank.pl.bloxbank.pl. 3600 IN A 192.168.0.1mail.bloxbank.pl.86400 IN A 192.168.0.2ns1.bloxbank.pl. 86400 IN A 192.168.0.3sub.bloxbank.pl. 86400 IN NS ns1.sub.bloxbank.pl.www.bloxbank.pl. 86400 IN CNAME bloxbank.pl.
;31897;18165
Podpisywanie strefy – NSEC
bloxbank.pl. 86400 IN SOA ns1.bloxbank.pl. hostmaster.bloxbank.pl. (20140609041h15m30d1h )
bloxbank.pl. 86400 IN DNSKEY 256 3 5 AwEAAfYh8eqw+…bloxbank.pl. 86400 IN DNSKEY 257 3 5 eeSiesh2eWio+… bloxbank.pl. 86400 IN NS ns1.bloxbank.pl.bloxbank.pl. 86400 IN MX 10 mail.bloxbank.pl.bloxbank.pl. 3600 IN A 192.168.0.1bloxbank.pl. 3600 IN NSEC mail.bloxbank.pl. SOA NS MX A RRSIG NSEC DNSKEYmail.bloxbank.pl. 86400 IN A 192.168.0.2mail.bloxbank.pl. 3600 IN NSEC ns1.bloxbank.pl. A RRSIG NSECns1.bloxbank.pl. 86400 IN A 192.168.0.3ns1.bloxbank.pl. 3600 IN NSEC sub.bloxbank.pl. A RRSIG NSECsub.bloxbank.pl. 86400 IN NS ns1.sub.bloxbank.pl.sub.bloxbank.pl. 3600 IN NSEC www.bloxbank.pl. NS RRSIG NSECwww.bloxbank.pl. 86400 IN CNAME bloxbank.pl.www.bloxbank.pl. 3600 IN NSEC bloxbank.pl. CNAME RRSIG NSEC
;31897;18165
Podpisywanie strefy – generowanie RRSIG
bloxbank.pl. 86400 IN SOA ns1.bloxbank.pl. hostmaster.bloxbank.pl. (20140609051h15m30d1h )
bloxbank.pl. 86400 IN DNSKEY 256 3 5 AwEAAfYh8eqw+…bloxbank.pl. 86400 IN DNSKEY 257 3 5 eeSiesh2eWio+… bloxbank.pl. 86400 IN NS ns1.bloxbank.pl.bloxbank.pl. 86400 IN MX 10 mail.bloxbank.pl.bloxbank.pl. 3600 IN A 192.168.0.1bloxbank.pl. 3600 IN NSEC mail.bloxbank.pl. SOA NS MX A RRSIG NSEC DNSKEYbloxbank.pl. 86400 IN RRSIG DNSKEY 5 3 180 20140428110136 20140424104538 31897 bloxbank.pl. XXXXXXX…mail.bloxbank.pl. 86400 IN A 192.168.0.2mail.bloxbank.pl. 3600 IN NSEC ns1.bloxbank.pl. A RRSIG NSECns1.bloxbank.pl. 86400 IN A 192.168.0.3ns1.bloxbank.pl. 3600 IN NSEC sub.bloxbank.pl. A RRSIG NSECsub.bloxbank.pl. 86400 IN NS ns1.sub.bloxbank.pl.sub.bloxbank.pl. 3600 IN NSEC www.bloxbank.pl. NS RRSIG NSECwww.bloxbank.pl. 86400 IN CNAME bloxbank.pl.www.bloxbank.pl. 3600 IN NSEC bloxbank.pl. CNAME RRSIG NSEC
;31897;18165
Podpisywanie strefy – generowanie RRSIG cd.
bloxbank.pl. 86400 IN SOA ns1.bloxbank.pl. hostmaster.bloxbank.pl. (20140609061h15m30d1h )
bloxbank.pl. 86400 IN DNSKEY 256 3 5 AwEAAfYh8eqw+…bloxbank.pl. 86400 IN DNSKEY 257 3 5 eeSiesh2eWio+… bloxbank.pl. 86400 IN NS ns1.bloxbank.pl.bloxbank.pl. 86400 IN MX 10 mail.bloxbank.pl.bloxbank.pl. 3600 IN A 192.168.0.1bloxbank.pl. 3600 IN NSEC mail.bloxbank.pl. SOA NS MX A RRSIG NSEC DNSKEYbloxbank.pl. 86400 IN RRSIG DNSKEY 5 3 180 20140428110136 20140424104538 31897 bloxbank.pl. XXX…bloxbank.pl. 86400 IN RRSIG DNSKEY 5 3 180 20140428110136 20140424104538 18165 bloxbank.pl. XXX…bloxbank.pl. 86400 IN RRSIG NS 5 3 180 20140428110136 20140424104538 18165 bloxbank.pl. XXX…bloxbank.pl. 86400 IN RRSIG MX 5 3 180 20140428110136 20140424104538 18165 bloxbank.pl. XXX…bloxbank.pl. 86400 IN RRSIG A 5 3 180 20140428110136 20140424104538 18165 bloxbank.pl. XXX…bloxbank.pl. 86400 IN RRSIG NSEC 5 3 180 20140428110136 20140424104538 18165 bloxbank.pl. XXX…mail.bloxbank.pl. 86400 IN A 192.168.0.2mail.bloxbank.pl. 3600 IN NSEC ns1.bloxbank.pl. A RRSIG NSECmail.bloxbank.pl. 86400 IN RRSIG A 5 3 180 20140428110136 20140424104538 18165 bloxbank.pl. XXX…mail.bloxbank.pl. 86400 IN RRSIG NSEC 5 3 180 20140428110136 20140424104538 18165 bloxbank.pl. XXX…ns1.bloxbank.pl. 86400 IN A 192.168.0.3ns1.bloxbank.pl. 3600 IN NSEC sub.bloxbank.pl. A RRSIG NSECns1.bloxbank.pl. 86400 IN RRSIG A 5 3 180 20140428110136 20140424104538 18165 bloxbank.pl. XXX…ns1.bloxbank.pl. 86400 IN RRSIG NSEC 5 3 180 20140428110136 20140424104538 18165 bloxbank.pl. XXX…sub.bloxbank.pl. 86400 IN NS ns1.sub.bloxbank.pl.sub.bloxbank.pl. 3600 IN NSEC www.bloxbank.pl. NS RRSIG NSECsub.bloxbank.pl. 86400 IN RRSIG NS 5 3 180 20140428110136 20140424104538 18165 bloxbank.pl. XXX…sub.bloxbank.pl. 86400 IN RRSIG NSEC 5 3 180 20140428110136 20140424104538 18165 bloxbank.pl. XXX…www.bloxbank.pl. 86400 IN CNAME bloxbank.pl.www.bloxbank.pl. 3600 IN NSEC bloxbank.pl. CNAME RRSIG NSECwww.bloxbank.pl. 86400 IN RRSIG CNAME 5 3 180 20140428110136 20140424104538 18165 bloxbank.pl. XXX…www.bloxbank.pl. 86400 IN RRSIG NSEC 5 3 180 20140428110136 20140424104538 18165 bloxbank.pl. XXX…
;31897;18165
DNS Resource Record Types – DNSKEY
DNSKEY
RR Type Name:
DNS Key Record
RR Type Number:
48
Description:DNSKEY record contains the public key that a DNS resolver uses to verify DNSSEC signatures in RRSIG records.
Example:infoblox.pl. IN DNSKEY 256 3 5 AwEAAfYh8eqw+…
RR Text Code:
DNS Resource Record Types – DNSKEY
infoblox.pl. IN DNSKEY 256 3 5 AwEAAfYh8eqw+…
infoblox.pl.
256 (ZSK) or 257 (KSK)
3
5
AwEAAfYh8eqw+…
Domain Name
Key Type
Protocol
Encryption Algorithm
Base64-encoded Public Key
DNS Resource Record Types – DNSKEY Algorithms
infoblox.pl. IN DNSKEY 256 3 5 AwEAAfYh8eqw+…
Number Description Support
1 RSA/MD5 (deprecated)
3 DSA/SHA-1 (optional)
5 RSA/SHA-1 (required)
6 DSA-NSEC3-SHA1 (optional)
7 RSASHA1-NSEC3-SHA1 (recommended)
8 RSA/SHA-256 (recommended)
10 RSA/SHA-512 (recommended)
12 GOST R 34.10-2001 (optional)
13 ECDSA Curve P-256 with SHA-256 (recommended)
14 ECDSA Curve P-384 with SHA-384 (recommended)
DNSSEC – Chain of Trust – Łańcuch zaufania
DNSSEC używa relacji zaufania bazującej na łańcuchu.
Musisz poprosić o klucz publiczny ale klucz publiczny jest używany do poświadczenia tożsamości.
„Kotwica” jest potrzebna na poziomie ROOT DNS
Każdy link/relacja w łańcuchu jest podpisana poprzednim linkiem.
Bez użycia „Kotwicy” konieczne byłoby ręczneweryfikowanie każdej domeny
DNSSEC Chain of Trust – Rozwiązywanie nazw
Trust Anchor(published by IANA)
KSK: Key Signing Key DS: Delegation SignerZSK: Zone Signing Key
Public
Private
Root KSK
Root KSK
Public
Private
Root ZSK
Root ZSK
root zone
.comDS record
Public
Private
.com KSK
.com KSK
Public
Private
.com ZSK
.com ZSK
Public
Private
.bloxbank.com KSK
.bloxbank.com KSK
Public
Private
.bloxbank.com ZSK
.bloxbank.com ZSK
signs
.bloxbank.comzone
.com zone
.bloxbank.comDS record
signs
signs
signs
signs
signs
www
refers refers
signed‘www’
https://www.iana.org/dnssec/files
DNSSEC – Rozwiązywanie nazw
Jeżeli resolver jest DNSSEC-aware to potrafi:– Sprawdzić czy serwery danej domeny wspierają DNSSEC– Sprawdzić czy otrzymana odpowiedź jest zaufana– Sprawdzić czy odpowiedź zawiera błąd
Procedura rozwiązywania jest inna dla tzw. stub resolvers i inna dla serwerów Cache DNS (recursive name servers).
Stub Resolvers– Wysyłają zapytanie do serwera Cache DNS (resolver)– Używają flagi AD do rozpoznania czy DNS serwer sprawdził odpowiedź
Proces wymiany kluczy
DNSSEC wymaga utrzymania porządku i opieki
Klucze muszą być regularnie wymieniane
Trzeba uważać aby nie przerwać „Chain of Trust”– Intepretowane dane mogą być traktowane jako niepewne– Lub nawet gorzej jako fałszywe => brak walidacji
Wymiana kluczy musi zachować „Chain of Trust”– RRset mogą posiadać wiele sygnatur– Jak długo jedna z nich jest potwierdzona, tak długo strefa jest bezpieczne– Dodatkowe sygnatury nie szkodzą DNSSEC
Proces wymiany kluczy - metody
Istnieją dwie metody wymiany kluczy:
1. Podwójne sygnatury– Strefa jest równocześnie podpisana za pomocą starych i nowych kluczy– Oba zestawy sygnatur są używane do czasu aż DNS Cache będą miały
czas aby je wygasić. Potem stare sygnatury usuwamy.– Metoda jest bardzo bezpieczna– Podwaja się rozmiar strefy
2. Wcześniejsza publikacja (Pre-publishing)– Publikujemy nowy rekord DNSKEY (zanim podpiszemy nim rekordy)– Z chwilą gdy nowy DNSKEY jest już widoczny w Internecie (DNS Cache)
usuwamy stare sygnatury i propagujemy nowy– Bardziej eleganckie podejście– Ale skomplikowane i podatne na błędy!– Wymaga BARDZO ostrożnego użycia :-)
Proces wymiany kluczy - metody
Zone Signing Key– Brak interakcji ze światem zewnętrznym– Publikacja NOWYCH kluczy na miesiąc przed podpisywaniem– Usunięcie STARYCH kluczy miesiąc po podpisaniu NOWYMI kluczami
Key Signing Key– Wymagana interakcja z nadrzędnym DNS (np. Domain Registrar) aby
opublikować NOWE klucze (DS).– Klucze KSK mogą być używane podwójnie dodając tylko jeden dodatkowy
RRSIG– Usunięcie STARYCH z chwilą gdy wszystkie rekordy w DNS Cache nie są
już dostępne.– Należy używać dłuższego z czasów:
• Czas wygaśnięcia strefy nadrzędnej + TTL strefy nadrzędnej, lub• Czas wygaśnięcia twojej strefy + TTL twojej strefy
Proces wymiany kluczy – SYTUACJE AWARYJNE
Gdy klucze KSK / ZSK zostały zagrożone/naruszone itp.
Wybór: przerwanie „Chain of Trust” albo wymiana kluczy
Wszystkie klucze muszą być jak najszybciej wymienione
Kroki jakie należy wykonać:– Zabezpieczamy system przed następnymi atakami i dopiero wtedy…– Tworzymy nowe KSK i ZSK dla każdej strefy– Zaczynamy normalny proces wymiany ZSK i KSK– Należy być agresywnym i brutalnym ;-) w usuwaniu naruszonych kluczy.
DNSSEC Lookaside Validation (RFC5074)
Nie wszystkie TLD są podpisane, nadrzędne rekordy DS nie mogą być sprawdzane.
DNSSEC Lookaside Validation Registrar (DLV)– Umowny zbiór dodatkowych „trust anchor” dla stref– Cache (Validating DNS) może zostać skonfigurowany aby sprawdzać
zasoby DLV jeżeli tradycyjna walidacja od ROOT nie powiodła się.– Dane z DLV są akceptowane jako zaufane ogniwo przy sprawdzaniu „Chain
of Trust”
DLV dotyka problemów zaufania– DLV utrzymywane przez ISC jest kontrolowane przez ISC itp.– Czasami zasady bezpieczeństwa uniemożliwiają ufania DLV– Automatycznie ufamy ISC i tym którzy im już zaufali..– https://dlv.isc.org/
DNSSEC – Podsumowanie teorii
DNSSEC = DNS Security Extensions– Wstecznie kompatybilne z tradycyjnym DNS
Wprowadza dodatkowe rekordy (RR) do DNS– DNSKEY, DS, RRSIG, NSEC/NSEC3, and NSEC3PARAM
Używa poprzednio nieużywane flagi w nagłówkach DNS Używa również flag udostępnionych przez rozszerzenie EDNS0 Używa kryptografii klucza publicznego
– Cyfrowe podpisy rekordów (RR)– Gwarantuje że wiadomość była stworzona przez właściciela klucza– Gwarantuje że wiadomość nie została zmieniona podczas transmisji
Dwa klucze kryptograficzne– Zone Signing Key (ZSK) – podpisuje rekordy w strefie– Key Signing Key (KSK) – podpisuje ZSK
DNSSEC – Podsumowanie teorii cd.
Strefy DNS podpisujemy:– Sortując rekordy– Tworząc cyfrowe podpisy z wykorzystaniem ZSK– Sygnatury są dodawane do strefy DNS
Resolver weryfikuje sygnatury przez:– Pobieranie rekordów i kluczy w górę hierarchii DNS aż do ROOT.– Jest to tzw. Łańcuch Zaufania - “Chain of Trust”– Błąd/przerwa w łańcuchu powoduje błąd walidacji
Rekordy NSEC/NSEC3 udostępniają potwierdzenie nieistnienia DNS Lookaside Validation pozwala wykorzystywać DNSSEC nawet
gdy TLD jest bez DNSSEC.
DNSSEC – Przypadki
29
DNSSEC – Punkty obserwacyjne :-)
Aby poznać lepiej DNSSEC trzeba dokonać trzech obeserwacji
Użytkownik Operator / ISPDostawca treściNp. mojBank.pl
#1 #2 #3
DNSSEC – Z perspektywy klienta/użytkownika
31
Czy mój DNS Server wspiera DNSSEC
Upraszczając - możliwe są 2 przypadki– #1 Najbardziej popularny– Mój serwer nie wie co to DNSSEC
• Działamy zgodnie z klasycznym DNS bez DNSSEC• Ew. używamy plugin do przeglądarki który sprawdzi DNSSEC za pomocą innego
serwera albo sam dokona pełnego odpytywania („Without resolver”).• FF, Safari, Chrome: https://www.dnssec-validator.cz/
Działa jak “stary” DNS bez DNSSEC.
Czy mój DNS Server wspiera DNSSEC
33
Czy mój DNS Server wspiera DNSSEC
Upraszczając możliwe są 2 przypadki– #2 Prawie jak YETI– Mój DNS Serwer (Cache/Recursive) wspiera DNSSEC– DNSSEC Validating Resolver– Chroni (SERVFAIL) nieświadomy resolver/klienta.
Przypadek zapytania o rekord z błędną weryfikacją DNSSEC
34
Czy mój DNS Server wspiera DNSSEC
Upraszczając możliwe są 2 przypadki– #2 Prawie jak YETI– Mój DNS Serwer (Cache/Recursive) wspiera DNSSEC– DNSSEC Validating Resolver– Chroni (SERVFAIL) nieświadomy resolver/klienta.
35
Czy mój DNS Server wspiera DNSSEC
Upraszczając - możliwe są 2 przypadki– #2 Prawie jak YETI– Mój DNS Serwer (Cache/Recursive) wspiera DNSSEC– DNSSEC Validating Resolver– Chroni (SERVFAIL) nieświadomy resolver/klienta.
Przypadek zapytania o rekord z poprawną weryfikacją DNSSEC
36
DNSSEC – Już prawie wkradł się do przeglądarek…
Google Chrome od wersji 14 (wrzesień 2011) miało wsparcie dla DNSSEC
Stan weryfikacji DNSSEC można było sprawdzić tylko dla https klikając na „kłódkę”.
https://www.imperialviolet.org/2011/06/16/dnssecchrome.html
Usunięto wsparcie:
37
DNSSEC – Ale teraz mamy tylko pluginy
https://www.dnssec-validator.cz/
Currently, Internet Explorer (IE), Mozilla Firefox (MF), Google Chrome/Chromium (GC),Opera (OP), Apple Safari (AS) are supported.
DNSSEC – Z perspektywy operatora
39
DNSSEC – Jak to wygląda na świecie
Matthäus Wander przeprowadził test sprawdzania DNSSEC w różnych krajach http://www.vs.uni-due.de/wander/20130319_DNSSEC_Validation/#19
DNSSEC –na świecie – badanie by Geoff Huston z APNIC
http://stats.labs.apnic.net/dnssec
Używają reklam google.com do dystrybucji zapytań
41
DNSSEC – Jak sprawdzić operatora?
http://dnssec.vs.uni-due.de/
=>
43
DNSSEC – Jak sprawdzić operatora?
Są też aplikacje – przykład DNSSEC Check z http://www.dnssec-tools.org/
DNSSEC u operatora – Jak do tego podejść.
- Czas na wdrożenie, można etapami- Więcej ruchu, więcej zasobów, większe pakiety- Ew. wymiana FW/LB/IDS/IPS (EDNS0).- DNS to też TCP:53 - Najpopularniejsze:
- BIND 9.7+ i Unbound 1.4+- Podpowiedzi jak włączyć DNSSEC Validation:
- http://www.surf.nl/en/knowledge-and-innovation/knowledge-base/2012/white-paper-deploying-dnssec.html
- Zawsze warto pobrać nowy IANA ROOT Trust Anchor- Przynajmniej zweryfikować i porównać- Od jakiegoś czasu dystrybucja BIND’a zawiera ROOT Trust Anchor
- Uprzedzić użytkowników i przeszkolić helpdesk/infolinię/NOC- Potrzeba trochę czasu i konieczny jest dobry czas na serwerach (NTP!)- Sprawdzić:
- http://dnssectest.sidn.nl/test.php & dnssec-failed.org & rhybar.cz- Ew. uruchomić sprawdzanie na własnym WWW/E-BOK itp.:
https://github.com/SIDN/client_dnssec_check
DNSSEC u operatora – Dlaczego warto?
- Z jednej strony mamy koszty- Wdrożenie, utrzymanie, ryzyko większej ilości zgłoszeń itp.- Do tego więcej zasobów i ruchu
- Z drugiej strony mamy takie usługi jak Google DNS czy OpenDNS.- Powstały one i są używane z jakiegoś powodu.
- Warto dostarczyć lepszą, bezpieczniejszą usługę- Warto się wyróżnić- Warto dbać o swoich użytkowników
- WARTO SIĘ TYM CHWALIĆ- I KONKUROWAĆ BEZPIECZEŃSTWEM
- Executive Summary:- Trudno na tym zarobić
… ale łatwo się wyróżnić i poprawić PR http://itssaulconnected.com/archives/2009/10/10-ways-to-recognize-an-innovator/
DNSSEC – Z perspektywy dostawcy treści(e-commerce, finanse, banki, e-gov itp.).
47
DNSSEC – Na początek trochę danych ze świata
Czechy - DNSSEC w .CZ od 2008 rokuhttps://stats.nic.cz
38%
48
DNSSEC – Statystyka
Dystrybucja DNSSEC w TLD/ccTLDhttp://secspider.cs.ucla.edu/islands.html
.NL podpisana od 2010 (?)
.SE podpisana od 2005– jako pierwsza na świecie ccTLD
.CZ podpisana od 2008
49
DNSSEC – NIST
IPv6 na DNS/MAIL/MAIL oraz DNSSEChttp://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com
Monitorują USA GOV, USA EDU i 1070 domen z rynku komercyjnego
50
DNSSEC – A w PL?
DNSSEC w .pl od czerwca 2012
DNSSEC w .gov.pl od 27.08.2014 (wcześniej był poza NASK)
Z ostatniego raportu NASK:[…]pierwsze półrocze rejestr zakończył liczbą 2 491 276 nazw aktywnych w DNS
[…]
Z końcem pierwszego półrocza 2014 roku w rejestrze domeny .pl istniało 15851 nazw zabezpieczonych protokołem DNSSEC. [...]
0,63%
http://www.dns.pl/NASK_Q2_2014_RAPORT.pdf
51
DNSSEC – Dostawcy treści…
- Koszty utrzymania, szkolenia itd.- Ryzyko błędu / niedostępności- Brak zrozumienia u klientów
- Co z bezpieczeństwem klientów?- Czy bez DNSSEC firma zrobiła wszystko co mogła?
- Chciałbym konto w banku z DNSSEC- Chciałbym aby nasz GOV.PL używał DNSSEC
- A gdyby mój serwis e-mail miał DNSSEC- To już bym był szczęśliwy :-)
52
DNSSEC – Dostawcy treści…
https://www.cert.org/blogs/certcc/post.cfm?EntryID=206
53
DNSSEC – Jak?
- Najlepiej zacząć od pilota (np. jedna mniej popularna strefa)- Ew. DNSSEC w trybie offline
- Sprawdzić oprogramowanie DNS na serwerach- Sprawdzić FW, LB, IDS/IPS czy radzi sobie z EDNS0 i TCP:53 dla DNS
- Potwierdzić czy Registrar wspiera DNSSEC- Jaka jest metoda dostarczania DS.- Jak wygląda aktualizacja DS i sytuacje awaryjne
- Nic nie zastąpi doświadczenia zdobytego „w realu”. Jak w IPv6 ;-)
- Przy większej skali warto zastosować urządzenia HSM.- Są już pierwsze przymiarki do audytowania DNSSEC:
http://www.nlnetlabs.nl/downloads/publications/dns-audit-framework-1.0.pdf
54
DNSSEC – Sprawdzamy czy wszystko jest OK
- http://dnsviz.net/
- http://dnssec-debugger.verisignlabs.com/
55
DNSSEC – Ciekawostki
- DANE (DNS-based Authentication of Named Entities)- Np. SMTP, Jabber/XMPP, SIP, SSLVPN, SDN Tools- Certyfikaty w DNS - Dodatkowa weryfikacja
- SSHFP RR: SSH Key FingerprintsPrzykład: http://www.phcomp.co.uk/Tutorials/Unix-And-Linux/ssh-check-server-fingerprint.html
RSA key fingerprint is ca:fe:aa:bb:56:f8:0c:04:12:5b:ef:4d:46:ad:09:23.Matching host key fingerprint found in DNS.Are you sure you want to continue connecting (yes/no)?
Przykład z Postfix:
https://ripe68.ripe.net/presentations/253-DANEs_don%27t_lie-20140512.pdf
TLSA Checker: https://check.sidnlabs.nl/dane/
Więcej info o DANE by Scott Hogg:https://community.infoblox.com/blogs/2014/04/14/dns-based-authentication-named-entities-dane
DNSSEC – Jak poprawić popularność?
- Promocje/zniżki opłat za domeny jeżeli włączamy DNSSEC- Standaryzacja odgórna np. gov.pl
- Czesi mają od paru lat projekt IPv6 i DNSSEC dla Edu i Gov- W USA instytucje Gov miały czas do końca 2011 aby wdrożyć IPv6 i
DNSSEC na styku z Internetem (czyli klientem)
- Powinno nam zależeć aby podnosić bezpieczeństwo- Jak również na unikaniu manipulacji i polityki- Przykład Turcji – gdyby twitter i facebook używał DNSSEC
https://ripe68.ripe.net/presentations/158-bortzmeyer-google-dns-turkey.pdf
Potrzebny byłby jeszczeDNSSEC Validating server/resolver
Miał być konkurs – ale go nie będzie.Bo nikt nie nadesłał pytań …
Pytania?
Recommended