2007.02_Bezpieczne SSH_[Bezpieczenstwo].pdf

bezpieczeństwo

Bezpieczne SSH

Marcin Ulikowski

SSH jest popularnym standardem protokołów oferującym bezpieczne, szyfrowane połączenia.

Znajduje wiele zastosowań, od terminalowego łączenia ze zdalnym komputerem przez transfer plików

do tunelowania połączeń.

nych protokołów takich jak Telnet, FTP czy

RSH które wszelkie dane, także hasła, prze-

syłały w sposób jawny. Posiada bardzo istot-

ną cechę – umiejętność potwierdzenia tożsamości kompu-

tera z którym nawiązujemy połączenie. Jeśli weryikacja

przebiegnie pomyślnie, nie ma możliwości aby ktokolwiek

mógł odczytać lub zmodyikować zawartość transmisji.

Jednak pomimo szyfrowanego połączenia możliwe jest

podsłuchiwanie sesji, chociaż proces ten ma inny charakter

niż w przypadku starszych protokołów. Atak ten nosi na-

zwę Man in the middle (ang. człowiek po środku), czyli atak

z pośrednikiem.

cję. Osoba po drugiej stronie połączenia myśli, że komuni-

kuje się z inną osobą, podczas gdy w rzeczywistości komu-

nikuje się z napastnikiem.

Wyobraźmy sobie sytuację w której komputer A znaj-

dujący się w sieci lokalnej chce nawiązać połączenie zdal-

ne z komputerem B. Po drodze stoi komputer C, czyli bram-

ka NAT pod kontrolą atakującego. Oznacza to, że wszystkie

dane wysyłane w stronę Internetu są przekazywane za po-

średnictwem komputera C. Komputer ten może imitować

serwer usługi z którą chcemy się połączyć. Jeśli atak się po-

wiedzie, komputer A będzie bezpośrednio połączony z ma-

szyną napastnika myśląc, że jest połączony z właściwym

serwerem. Napastnik realizując jednocześnie połączenie z

komputerem A i serwerem docelowym B będzie miał do-

stęp do wszystkich przesyłanych informacji, łącznie z ha-

słem dostępu. Po zdobyciu hasła może zerwać połączenie

lub wciąż pełnić rolę przekaźnika, jeśli chce aby komputer

A pozostał nieświadomy faktu, że stał się oiarą.

Schemat ataku

Atak z pośrednikiem polega na czytaniu i modyikowa-

niu treści połączenia pomiędzy dwoma stronami bez ich

wiedzy. Atakujący pełni rolę pośrednika w komunikacji

między dwoma komputerami, podobnie jak to robią ser-

wery proxy. Jednak istotna różnica polega na tym, że nikt

nie wie o istnieniu pośrednika. W sposób niewidoczny ak-

tywnie monitoruje, przechwytuje i kontroluje komunika-

SSH i klucze publiczne

Protokół SSH standardowo udostępnia możliwość obrony

przed atakiem tego rodzaju. Klient, który realizuje szyfro-

luty 2007

Z ostał zaprojektowany jako następca wysłużo-

bezpieczeństwo

Bezpieczne SSH

z osobą zarządzającą serwerem w celu wyja-

śnienia przyczyny zmiany klucza oraz uzy-

skanie nowego, właściwego.

Rysunek 1. Schemat połączenia, w którym komputer C kontrolowany jest przez napastnika

Gdy jest za późno

Co zrobić, gdy zaakceptowaliśmy niezna-

ny klucz i zaczynamy podejrzewać, że stali-

śmy się oiarą ataku Man in the middle ? Mo-

żemy to sprawdzić w bardzo prosty sposób

na własną rękę. Potrzebny będzie tzw. in-

gerprint (ang. odcisk palca) klucza oraz in-

formacja jakim algorytmem został utworzo-

ny. W naszym przykładzie (Rysunek 4) jest

to algorytm RSA. Odcisk palca to 128-bito-

wa liczba zapisana w postaci szesnastko-

wej, gdzie oktety oddzielone są dwukropka-

mi. Musimy zalogować się na serwer w ce-

wane połączenie za każdym razem sprawdza

tożsamość serwera. Weryikacja opiera się na

sprawdzeniu zgodności klucza publicznego

danego serwera. Klucz serwera zapisywa-

ny jest na stale w bazie klienta i może się tam

znaleźć na trzy sposoby:

ny. W tym momencie klient SSH informuje

o tym fakcie oraz sugeruje wystąpienie po-

tencjalnego ataku. Częstym błędem popeł-

nianym przez użytkowników jest nie czyta-

nie komunikatów tego typu lub ich bagateli-

zowanie, co najczęściej wynika z nieświado-

mości istniejącego zagrożenia. Powodzenie

ataku zależy więc od użytkownika. Dlatego

podczas nawiązywania połączenia z serwe-

rem, nigdy nie wolno akceptować zmienione-

go klucza publicznego chyba, że mamy pew-

ność co do jego pochodzenia. Bardzo dob-

rym zwyczajem jest także stosowanie osob-

nych haseł dla posiadanych kont, dzięki

czemu ewentualne włamanie nie pociągnie

za sobą kolejnych.

Baza kluczy publicznych

• akceptacja klucza przesyłanego przez

serwer podczas pierwszego połączenia

(najczęściej stosowane rozwiązanie),

• administrator lub inna kompetentna oso-

ba udostępnia klucz publiczny serwera,

na przykład na stronie internetowej (za-

lecane, ale rzadko spotykane rozwiąza-

nie),

• znajoma osoba (darzymy ją zaufaniem),

która posiada dostęp do serwera, udo-

stępnia nam wcześniej otrzymany klucz

publiczny.

Baza znanych serwerów jest również źró-

dłem ciekawych informacji dla włamywacza.

W przypadku OpenSSH plik known_hosts

zawiera adresy IP (najczęściej także pełne

nazwy) serwerów oraz ich klucze publiczne.

Dane te nie są zabezpieczane, ponieważ

klucze publiczne mogą być rozpowszech-

niane bez obaw o naruszenie bezpieczeń-

stwa serwera. Jednak duża ilość takich da-

nych zebrana w jednym miejscu stanowi już

źródło pewnych informacji. Tworzy się lista

serwerów SSH na których użytkownik po-

siada konto (jak pokazuje praktyka, najczę-

ściej z takim samym hasłem). Bazy kluczy

publicznych to doskonały materiał dla wła-

mywacza. Analiza nieuprawnionych logo-

wań na konta użytkowników pokazuje, że

włamywacze uzyskując dostęp do plików

known_hosts zyskują dalszy dostęp do in-

nych kont. Główną przyczyną są takie same

hasła stosowane na wszystkich serwerach

oraz niezaszyfrowane klucze RSA (umoż-

liwiają zalogowanie się na serwer bez po-

dania hasła).

Rozwiązanie problemu jest dosyć pro-

ste i zostało wbudowane w OpenSSH 4.0

oraz nowsze wersje (opcja HashKnownHosts

w pliku koniguracyjnym). Polega na prze-

chowywaniu adresu w postaci skrótu ( hash ),

zamiast w postaci jawnej. W przypadku gdy

klient łączy się z serwerem, skrót umożliwia

łatwe sprawdzenie, czy adres znajduje się

w pliku. Natomiast nie jest możliwe działa-

nie odwrotne, czyli odzyskanie adresu ser-

wera ze skrótu. Dzięki temu włamywacz nie

dowie się z jakich serwerów korzysta użyt-

kownik.

Dlaczego klucz publiczny

serwera ulega zmianie?

Zmiana klucza publicznego nie zawsze ozna-

cza próbę włamania na nasze konto. Dlate-

go jeśli otrzymujemy komunikaty takie jak

na Rysunku 4 i Rysunku 5, nie wpadajmy

w panikę. Najczęściej przyczyną ich wystąpie-

nia jest:

Pierwsze rozwiązanie jest najczęściej stoso-

wane. Łącząc się po raz pierwszy z danym

serwerem, otrzymujemy informację, iż nie

posiadamy jeszcze takiego klucza publicz-

nego w swojej bazie. W przypadku klien-

ta OpenSSH będzie to komunikat podob-

ny do tego na Rysunku 2. Popularna imple-

mentacja SSH dla Windows, klient PuTTY ,

wyświetli komunikat zbliżony do przedsta-

wionego na Rysunku 3. Od nas zależy, czy

na pytanie o przyjęcie nowego klucza odpo-

wiemy twierdząco. Jeśli zdecydujemy się

zapisać klucz, połączenie zostanie zabezpie-

czone. Teraz użytkownik jest najsłabszym

ogniwem protokołu. Gdy dochodzi do ata-

ku, czyli między nami i serwerem stoi osoba

trzecia, otrzymujemy od serwera (w rzeczy-

wistości od napastnika) inny klucz publicz-

• zmiana wersji protokołu negocjowanego

przez serwer ze starszej SSHv1 (nie zale-

canej do stosowania) na nowszą SSHv2,

• aktualizacja demona SSH lub całkowi-

ta aktualizacja systemu w wyniku któ-

rej nie został zachowany (przeoczenie ze

strony administratora) wcześniej używa-

ny klucz publiczny,

• zmiana adresu IP lub nazwy serwera.

Najlepszym rozwiązaniem jest wstrzymanie

się z akceptacją zmienionego klucza i kontakt

Rysunek 2. Informacja o nieznanym kluczu publicznym (OpenSSH)

www.lpmagazine.org

bezpieczeństwo

Bezpieczne SSH

ku należy natychmiast zmienić hasło dostę-

pu do konta oraz skontaktować się z admi-

nistratorem systemu w celu wyjaśnienia sy-

tuacji.

Warto zapamiętać, że najpewniejszym

źródłem informacji jest administrator. Na-

pastnik ma pełną kontrolę nad treścią na-

szego połączenia. Możliwe jest więc, że in-

formacje zwracane przez program ssh-keygen

zostaną podczas transmisji podmienione na

fałszywe, aby uśpić naszą czujność. Dlatego

zawsze w takich sytuacjach warto skontak-

tować się z osobą zarządzającą daną usługą

na serwerze.

Rysunek 3. Informacja o nieznanym kluczu publicznym (PuTTY)

Podsumowanie

Przeprowadzenie ataku Man in the middle nie

jest trudne. Istnieją gotowe narzędzia, dzięki

którym nawet średnio-zaawansowany użyt-

kownik przy odrobinie szczęścia może pod-

słuchać nasze połączenie. Należy jednak pa-

miętać, że będzie to możliwe tylko wtedy, gdy

mu na to pozwolimy.

lu sprawdzenia odcisku palca. Wykorzysta-

my polecenie ssh-keygen oraz plik z kluczem

publicznym serwera. W naszym przypad-

ku będzie to plik ssh_host_rsa_key.pub , po-

nieważ odcisk palca został wygenerowany

przy użyciu algorytmu RSA (SSHv2). Do-

stęp do tego pliku powinien mieć każdy

użytkownik serwera.

gen są identyczne, więc nie mamy powodu

do obaw. Klucz został zmieniony w wyniku

działań administratora serwera. Jeśli odciski

palca są różne, to znaczy, że prawdopodobnie

staliśmy się oiarą ataku. W takim przypad-

$ ssh-keygen -l -f /etc/ssh/

ssh_host_rsa_key

1024 1e:d6:0d:f2:c6:eb:cf:ff:

e4:cd:e3:e1:b3:fd:46:ec

W naszym przykładzie odcisk palca z Ry-

sunku 2 i zwrócony przez polecenie ssh-key-

Rysunek 4. Linuksowy klient SSH informuje o zmianie klucza publicznego

Rodzaje kluczy

Wykorzystywane są dwie wersje protokołu:

SSHv1 oraz SSHv2. Starsza wersja SSHv1

wykorzystuje algorytm RSA, natomiast now-

sza SSHv2 polega na algorytmach RSA

i DSA. Możemy więc korzystać z trzech ro-

dzajów kluczy. W pliku koniguracyjnym /etc/

ssh/sshd_conig określane są on kolejno ja-

ko rsa1 , rsa , dsa . Podczas instalacji serwe-

ra SSH generowane są trzy różne klucze

oparte na wymienionych algorytmach. Klu-

cze prywatne są później przechowywane

w plikach: ssh_host_key (rsa1), ssh_host_

rsa_key (rsa) oraz ssh_host_dsa_key (dsa).

Dostęp do nich powinien mieć tylko admini-

strator. Pliki o takich samych nazwach, ale

z rozszerzeniem .pub zawierają tylko klu-

cze publiczne i dostęp do nich powinien być

swobodny. Do generowania kluczy prywat-

nych oraz publicznych (nie tylko) służy pole-

cenie ssh-keygen .

Rysunek 5. Program PuTTY ostrzega o potencjalnym ataku

luty 2007

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: