ADMINISTROWANIE SIECIAMI LINUX - Materiały pomocnicze do wykładów- cd

Instalacja i konfiguracja serwera OpenSSH

SSH (Secure Shell) – protokół przeznaczony do autoryzacji i szyfrowania transmisji. Używa technologii kryptograficznych kluczy asymetrycznych zgodnie z algorytmami RSA i DSA

Istnieją dwa modele transmisji zaufanej dla SSH:

• oparty na lokalnej bazie kluczy asymetrycznych (nie wymaga infrastruktury PKI),

• oparty na zewnętrznym CA (Certificate Authority).

Wersje SSH

SSH 1 – (tylko RSA), podatna na ataki hakerskie

SSH 2 - opracowana w latach 90-tych, RSA + DSA (RFC 4251),

wersja zalecana

Wybrane aspekty protokołu SSH:

• uwierzytelnianie łączących się systemów poprzez zastosowanie klucza publicznego i prywatnego,

• silne szyfrowanie (AES, Blowfish, 3DES) pełnej transmisji unikalnym kluczem sesyjnym (praca w trybie synchronicznym),

• autentykacja użytkownika jego nazwą i hasłem szyfrowanym kluczem sesyjnym (nieodporne na ataki man-in the-middle)

• możliwość autoryzacji dwoma parami kluczy asymetrycznych (zabezpieczenie przed man-in the-middle)

Niektóre zastosowania SSH:

- zdalne zarządzanie systemem,

- uruchamianie aplikacji przez bezpieczny tunel SSH,

- bezpieczny transfer plików (SFTP).

Instalacja Open SSH i uruchomienie usługi:: apt-get install openssh-server

Opcjonalnie można pobrać i zainstalować dedykowany graficzny edytor dla plików konfiguracyjnych serwera i klienta (sshd_config, ssh_config ):

lub: apt-get install libconfig-model-openssh-perl

Instalacja pakietu OpenSSH powoduje powstanie pliku konfiguracyjnego /etc/ssh/sshd_config, wygenerowanie kluczy asymetrycznych (2048-bit) dla algorytmów RSA i DSA w plikach:

/etc/ssh/ssh_host_dsa_key /etc/ssh/ssh_host_rsa_key

/etc/ssh/ssh_host_dsa_key.pub /etc/ssh/ssh_host_rsa_key.pub

uraz uruchomienie dla demona sshd nasłuchującego na ogólnie znanym porcie
TCP 22

Polecenia zatrzymywania i wznawiania usługi OpenSSH

service ssh stop

service ssh start

service ssh restart

Każda zmiana w pliku konfiguracyjnym demona wymaga „przeładowania” usługi!

Polecenie klienta SSH systemu Linux:

shh user@host

lub

ssh –p x user@host

gdzie x to numer portu nasłuchującego demona sshd, host – nazwa komputera lub jego IP (można zrealizować odpowiedni wpis w pliku /etc/hosts)

Widok okna klienta SSH dla Windows (putty.exe)

Przebieg autoryzacji stron przy pomocy 1 pary kluczy:

1. klient SSH łączy się na port TCP serwera SSH,

2. serwer wysyła klientowi SSH host_key (klucz publiczny) oraz fingerprint,

3. przy pierwszym połączeniu (za zgodą użytkownika) klient zapisuje klucz publiczny serwera w swoim systemie lub porównuje przy każdym następnym połączeniu z własną bazą kluczy

4. klient losuje np. 128 bitową liczbę, zapamiętuje ją, zaszyfrowuje kluczem publicznym serwera i wysyła do serwera,

5. serwer, przy pomocy klucza prywatnego jest w stanie odszyfrować przesłaną 128 bitową liczbę

6. serwer ponownie szyfruje kluczem prywatnym odszyfrowany wynik i przesyła do klienta

7. klient odszyfrowuje informację i porównuje z tym co zapamiętał wcześniej,

8. jeżeli wynik porównania jest pozytywny, to od tego momentu klient i serwer traktują dekodowaną liczbę jako klucz sesyjny,

9. klient wysyła zaszyfrowane hasło do serwera – następuje autentykacja hasła,

10. jeżeli autentykacja jest prawidłowa serwer wysyła zgodę do klienta na połączenie, klient przesyła zaszyfrowane polecenia de serwera.

Położenie kluczy publicznych serwera na stacji klienta:

- klient SSH Linux: np. /root/.ssh/known_hosts lub inny katalog domowy użytkownika np. /home/rpekala/.ssh/known_hosts, który inicjuje sesję SSH,

- putty.exe –klient SSH dla Windows: jako wartość rejestru systemu:

HKEY_CURRENT_USER Software

SimonTatham Putty SshHostKeys

Zadanie I:

a) zainstalować usługę OpenSSH,

b) sprawdzić port usługi System Administrations Network Tools

c) zmienić port usługi, sprawdzić efekty zmian

d) sprawdzić odcisk palca dla kluczy publicznych RSA i DSA

ssh-keygen -l

e) zrealizować połączenie z klienta SSH Linux oraz putty.exe

f) sprawdzić położenie kluczy publicznych serwera dla obydwu klientów

g) wygenerować nowe klucze serwera dla RSA i DSA: np. ssh-keygen –t dsa

klucze zapisać w plikach

h) sprawdzić odcisk palca nowych kluczy

i) skonfigurować demona sshd dla nowej pary kluczy RSA

j) zrealizować połączenie od klienta putty.exe dla nowych kluczy

k) usunąć wpisy w rejestrach Windows dla putty: putty –cleanup

l) nawiązać ponownie połączenie z serwerem OpenSSH.

Autentykacja przy pomocy 2 par kluczy – pełniejsze zabezpieczenie przed atakiem typu man-in the–middle.

W tym przypadku klient powinien swój klucz publiczny, najlepiej fizycznie, zamieścić na serwerze w odpowiednim pliku i katalogu:

np. /.ssh/kluczfirmy dla użytkownika root

/home/rpekala/.ssh/kluczfirmy dla innego użytkownika, który będzie realizował sesję SSH.

Jeżeli takich użytkowników będzie wielu, to dla każdego z nich należy zamieścić klucz publiczny klienta.

Para kluczy asymetrycznych klienta może być wygenerowana przez oprogramowanie serwerowe lub klienckie.

Przebieg połączenia

1. klient SSH łączy się na port TCP serwera SSH,

2. serwer wysyła klientowi SSH host_key (klucz publiczny) oraz fingerprint

3. przy pierwszym połączeniu (za zgodą użytkownika) klient zapisuje klucz publiczny serwera w swoim systemie lub porównuje przy każdym następnym połączeniu z własną bazą kluczy

4. klient losuje np. 128 bitową liczbę, zapamiętuje ją, zaszyfrowuje kluczem publicznym serwera i wysyła

5. serwer, przy pomocy klucza prywatnego jest w stanie odszyfrować przesłaną 128 bitową liczbę

6. serwer ponownie szyfruje kluczem prywatnym odszyfrowany wynik i przesyła do klienta

7. klient odszyfrowuje informację i porównuje z tym co zapamiętał wcześniej, dokonuje (lub nie) uwierzytelnienia klienta,

8. jeżeli wynik uwierzytelniania jest pozytywny klient wysyła do serwera swój klucz publiczny,

9. serwer porównuje ten klucz z bazą kluczy w pliku ~/.ssh/authorized_keys,

10. jeżeli klucz zostaje znaleziony serwer losuje liczbę np. 128-bitową, zapamiętuje ją, szyfruje kluczem publicznym klienta i wysyła do klienta,

11. klient odbiera i deszyfruje te dane swoim kluczem prywatnym,

12. odszyfrowane dane ponownie szyfruje swoim kluczem prywatnym (inaczej: podpisuje tym kluczem) a następnie to wszystko jeszcze raz szyfruje kluczem publicznym serwera SSH i wysyła,

13. serwer odbiera dane, deszyfruje swoim kluczem prywatnym, a następnie, pozostałe dane deszyfruje kluczem publicznym klienta, w ten sposób odczytuje wartość liczby i porównuje wynik z liczbą zapamiętaną,

14. Serwer wysyła zgodę do klienta na połączenie, klient przesyła zaszyfrowane polecenia do serwera.

Hasło „nie opuszcza” stacji klienckiej !

Zadanie II

1. Wygenerować klucz publiczny i prywatny RSA przy pomocy puttygen.

2. Zapisać wygenerowany klucz prywatny w pliku

3. Umieścić wygenerowany klucz publiczny w pliku kluczfirmy.pub dla wybranego użytkownika serwera – Uwaga ! ze względu na nazwę i/lub rozszerzenie zmodyfikować i uaktywnić odpowiedni wpis w pliku konfiguracyjnym serwera ssh.

4. Sprawdzić odcisk palca – oraz dokonać konwersji klucza Putty do formatu OpenSSH:

ssh-keygen –if kluczfirmy.pub >kluczfirmy

5. Umieścić właściwy klucz w katalogu/katalogach użytkowników przewidzianych do autoryzacji (np.: root/.ssh, /home/rpekala/.ssh)

6. Zrealizować połączenie z serwerem.

Niektóre dodatkowe elementy polityki bezpieczeństwa dla sesji SSH

- wykorzystanie plików serwera: /etc/hosts.allow i/lub /etc/hosts.deny

zmiany w plikach nie wymagają restartu demona sshd

-używanie jedynie SSH v2,

- okresowa zmiana kluczy kryptograficznych,

- zmiana domyślnego portu TCP 22 – sugeruje się porty z zakresu portów wyższych (>1000),

- brak możliwości logowania użytkownika root – zmienna PermitRootLogin
w sshd_config

- ograniczenie czasu logowania użytkownika zmienna LoginGraceTime

w sshd_config

Włączenie banera podczas logowania:

dodatkowy wpis w sshd_config: np.: banner /etc/baner.txt

gdzie baner.txt – plik z zawartością banera

Standardowo czytany jest /etc/issue.net przez wszystkie protokoły (np. telnet)

Tunelowanie (port forwarding) w protokole SSH - ochrona transmisji dla protokołów nieszyfrowanych (np., telnet, ftp)

Idea tunelowania (przykład):

1. niech na stacji B funkcjonuje usługa sieciowa (serwer) nasłuchująca na porcie 23 (Telnet) – może to być dowolna inna usługa (np. WWW, pop3, ftp…),

2. przyjmując adresy IP jak na rysunku można rozważać gniazda klienta i serwera odpowiednio: 10.1.1.1:1987 oraz 10.1.1.10:23

3. standardowo klient wysyła pakiety poprzez swoje gniazdo, pakiet trafia na gniazdo serwera,(klient łączy się z serwerem),

4. wykorzystując mechanizmy tunelowania należy dokonać konfiguracji, w wyniku której pakiet od klienta zamiast do aplikacji serwera zostanie przekierowany do aplikacji klienckiej SSH na komputerze A, na gniazdo: 127.0.0.1:portssh, gdzie portssh to dowolny port TCP, z równoczesnym wskazaniem docelowego gniazda aplikacji serwera 10.1.1.10:23 (telnet)

5. uruchomienie protokołu SSH z zadeklarowanym tunelem spowoduje na stacji A otwarcie gniazda 127.0.0.1:portssh, gdzie portssh to port TCP „wystawiony” przez serwer SSH

6. klient SSH jako wewnętrzny program pracujący na gnieździe TCP 127.0.0.1 przechwytuje pakiet dedykowany serwerowi

7. uruchomienie klienta telnet na stacji A do gniazda 127.0.0.1:5000 spowoduje, iż wszystkie pakiety klienta będą trafiały właśnie do tej końcówki tunelu i przechodziły na drugą stronę tunelu, czyli do gniazda 127.0.0.1: portsshd

8. -zgodnie z instrukcją z punktu D zadaniem serwera będzie przekierowanie pakietu do gniazda 10.1.1.10:23

Realizacja tunelu przy pomocy putty.exe

Po dokonaniu ustawień w polach Source i

Destination należy dodać wpis (Add)

Zadanie III

1. utworzyć banner na serwerze,

- /etc/banner.txt – plik z zawartością

- utworzyć wpis w sshd_config: banner /etc/banner.txt

- reload sshd

- sprawdzić baner

2. zabronić logowania na konto Root

3. utworzyć tunel na kliencie SSH Linux

ssh -2 –N –f –L 5000:127.0.0.1:23 10.1.1.8

zrealizować połączenie: telnet 127.0.0.1 5000

4. utworzyć tunel na kliencie Windows (putty.exe)

- utworzyć oddzielnie połączenie telnet oraz ssh, zwrócić uwagę na banery

powinny być różne,

- sprawdzić otwarte gniazda (netstat –n) na stacji klienckiej,

- zerwać połączenie telnet na port 23

- zadeklarować tunel (rysunek powyżej),

- za pomocą putty utworzyć połączenie ssh wraz z zadeklarowanym tunelem

- nawiązać połączenie telnet do tunelu SSH: telnet localhost (porównać banery dla tunelu ssh oraz telnetu – powinny być takie same)

- sprawdzić gniazda tunelu (netstat –n)