Wykorzystanie rekordów DNS do weryfikacji kluczy

Wykorzystanie rekordów DNS
do weryfikacji kluczy publicznych SSH
Radosław Kujawa – [email protected]
OSEC
15 czerwca 2015
Spis treści I
1 Zagrożenia bezpieczeństwa związane z weryfikacją kluczy
publicznych hostów
2 Jak wykorzystać rekordy SSHFP do zautomatyzowanej
weryfikacji kluczy
3 Konfiguracja klienta SSH
4 Automatyzacja procesu aktualizacji stref
5 Zabezpieczanie DNS przed spoofingiem
Część 1
Zagrożenia bezpieczeństwa związane z
weryfikacją kluczy publicznych hostów
SSH - weryfikacja kluczy a bezpieczeństwo
I
Każdy z nas używa SSH...
I
Protokół SSH jest „bezpieczny”.
I
Ale często zapominamy o zagrożeniach.
Akceptacja klucza publicznego zdalnego hosta
$ ssh example.com
The authenticity of host ’example.com (1.2.3.4)’ can’t be established.
RSA key fingerprint is 12:75:dd:41:22:3f:6f:88:f7:bc:4e:ad:2e:b5:da:2d.
Are you sure you want to continue connecting (yes/no)?
I
Manualna weryfikacja odcisku klucza najczęściej się nie
odbywa.
•
•
•
A co to jest? Myślałem, że trzeba tu wpisać „yes”.
Nie mam czasu / zarobiony jestem.
A kto będzie atakował ten mało ważny serwer?
Problem z weryfikacją kluczy publicznych
I
Protokół SSH jest faktycznie bezpieczny, ale...
I
Całe bezpieczeństwo opiera się na weryfikacji klucza
publicznego zdalnego hosta!
I
Skutecznie wykonany atak Man-in-the-Middle podczas
pierwszego połączenia całkowicie burzy to bezpieczeństwo.
I
SSH nie wymusza stosowania infrastruktury klucza
publicznego (PKI).
Gdy klucz zostanie zaakceptowany
I
Jest zapisywany w $HOME/.ssh/known hosts.
I
Używany do weryfikacji każdego kolejnego połączenia do tego
samego hosta.
I
Przy połączeniu do nowego hosta problem powraca...
Część 2
Jak wykorzystać rekordy SSHFP do
zautomatyzowanej weryfikacji kluczy
Mechanizm SSHFP
I
RFC4255, RFC6594, RFC7479.
I
Klient inicjuje połączenie z serwerem SSH.
I
Serwer SSH legitymuje się swoim kluczem publicznym.
I
Klient pobiera wartość rekordów SSHFP dla danego FQDN.
Klient weryfikuje odcisk klucza dla danego algorytmu, skoro
odcik się zgadza...
I
•
•
I
Może automatycznie zaakceptować klucz.
Może zapytać użytkownika czy klucz zaakceptować, podając
informację o zgodności z rekordem SSHFP.
Dalej połączenie SSH przebiega jak zazwyczaj.
Generowanie rekordów SSHFP
I
Nie trzeba niczego instalować dodatkowo
I
Znane narzędzie ssh-keygen posiada tą funkcjonalność.
I
ssh-keygen -r ‘hostname‘.
Struktura rekordu SSHFP
www
www
www
www
www
I
IN
IN
IN
IN
IN
A 192.168.0.100
SSHFP 1 1 0b34980da528297a8c9f3be3e8b6c05d58d14602
SSHFP 1 2 1f45321c7f1b730840a7fef14e30725a9d5ef5c5c7a9174(...)
SSHFP 2 1 c9a822aba840658002a4911f0a430f00f6e76d4e
SSHFP 2 2 15d544b67d0074bcd74219be55b96cdb36378f513159582(...)
Algorytm którym wygenerowano klucz:
•
•
•
•
I
-
RSA.
DSA.
ECDSA.
Ed25519.
Funkcja skrótu którą wygenerowano odcisk:
•
•
I
1
2
3
4
1 - SHA1.
2 - SHA256.
Weryfikacja: dig -t SSHFP www.example.com.
Część 3
Konfiguracja klienta SSH
Konfiguracja klienta – OpenSSH
I
I
Nie trzeba niczego instalować dodatkowo
Parametry konfiguracyjne klienta:
•
•
•
I
.
/etc/ssh/ssh config.
$HOME/.ssh/config.
Parametr -o polecenia ssh.
Opcje:
•
VerifyHostKeyDNS na wartość yes lub ask.
Część 4
Automatyzacja procesu aktualizacji stref
Automatyzacja aktualizacji stref
.
I
Brak standardu
I
Red Hat IPA/FreeIPA.
I
Dynamic DNS – nsupdate.
I
Generowanie kluczy w Kickstarcie i własny skrypt do
aktualizacji DNS.
I
Puppet/Chef/Ansible...
Część 5
Zabezpieczanie DNS przed spoofingiem
DNS a spoofing
I
Brak podpisu elektronicznego DNS w standardzie
•
I
I
Podatność DNS na ataki MITM.
DNSSEC rozwiązuje ten problem.
•
I
.
Tylko trzeba go wdrożyć...
W obrębie własnej infrastruktury alternatywą może być IPsec.
Nawet jeśli „spoofowalność” DNS jest problemem...
•
Samo wdrożenie SSHFP jest lepsze w porównaniu z brakiem
jakiejkolwiek weryfikacji kluczy publicznych hostów.
Alternatywy dla SSHFP?
I
OpenSSH CA (min. wersja 5.3, faktycznie potrzebna 5.6).
I
sss ssh knownhostsproxy.
I
ssh keyscan.
I
Manualna weryfikacja
.
Koniec. . .
Dziękuje!
Czy są pytania?