Neutralność sieci dzięki Open SSH
Autorem artykułu jest Dariusz Puchalak, OSEC.
Na bezpłatnym evencie OSEC Forum 2017 (objętym patronatem medialnym przez bloga StrefaKodera.pl) prowadzone będą warsztaty z używania OpenSSH tak, aby każdy ich uczestnik był w stanie zapewnić sobie neutralność sieci bez względu na ustawione po drodze firewalle. Zapoznaj się już teraz ze wstępem do warsztatów!
Christoph Scholz, CC BY-SA 2.0.
Jak to się wszystko zaczęło?
Jest rok 1995, ówczesna sieć bardziej przypomina ARPANET niż dzisiejszy Internet. Nie ma jeszcze Google’a, Facebook’a, Youtube’a, Twittera. Najpopularniejszy portal to Yahoo. Przeglądarki WWW dopiero raczkują, zamiast przeglądarki WWW częściej wykorzystywany jest gopher. Bezpieczeństwo sieci z której korzystają przede wszystkim uczelnie, realizowane jest poprzez zaufanie do innych użytkowników. Przy braku szyfrowania danych, administratorzy zakładają, że inni użytkownicy sieci nie będą wykradać przesyłanych informacji. Co ciekawe obowiązują również restrykcje CoCom – gdzie wiedza dotycząca kryptografii jest traktowana na równi z wiedza dotyczącą budowy broni jądrowej i nie może być eksportowana z USA.
Kiedy na uniwersytecie technicznym w Helsinkach ma miejsce seria włamań wykorzystująca podsłuchane w sieci hasła. Programista Tatu Ylönen decyduje się stworzyć narzędzie zastępujące niezabezpieczone protokołu. Tak powstaje pierwsza wersja Secure Shell (SSH).
Pierwsze kroki ku bezpieczeństwu…
SSH ma za cel zastąpić używane wtedy powszechnie usługi zdalnego logowania, kopiowania oraz uruchamiania programów na zdalnych systemach. Ma to robić w sposób prosty i bezpieczny. Podczas pierwszego połączenia użytkownik musi sprawdzić klucz serwera, do którego się łączy. Następne połączenia korzystają już z tej wiedzy i zabezpieczają przed atakami sieciowymi. Polecenia używane do zdalnego logowania (telnet, rlogin) i uruchamiania programów na innych systemach (rsh) zostały zastąpione przez SSH. Kopiowanie plików (rcp) zastąpiono przez scp. W 1996 roku debiutuje publicznie protokół SSL (obecnie zastąpiony przez TLS).
Ale są pomiędzy nimi (SSL vs SSL/TLS) znaczące różnice w budowie i wymaganiach. SSL/TLS wymaga infrastruktury (PKI z CA), natomiast SSH jest stworzone w duchu Uniksa. Nie wymaga tworzenia wcześniejszej infrastruktury, centrum certyfikacji i całej dodatkowej infrastruktury z tym związanej. SSH jako narzędzie zdobywa szturmem serca administratorów, bo pozwala w sposób łatwy i bezpieczny na zdalną pracę. Użytkownicy cenią go za wygodę i ułatwienia, np. bardzo proste i bezpieczne uruchamianie zdalnych aplikacji graficznych.
Do dzisiaj w sieci jest wiele szkodliwych porad, jak uruchomić zdalną aplikację graficzną w postaci „xhost +” – co pozwala każdemu z dowolnego miejsca na świecie na podglądanie naszych aplikacji, podsłuchiwanie klawiatury itd. W ssh przełącznik -X rozwiązuje ten problem w sposób łatwy, prosty, przyjemny i na dodatek bezpieczny.
Nie wszystko złote co się świeci
Niestety – w protokole SSH podobnie jak z SSL/TLS wychodzą powoli braki doświadczenia związane z projektowaniem tego typu protokołów. W SSL wersja 1.0 nie ujrzała nigdy światła dziennego, wersja 2.0 została szybko zastąpiona wersją 3.0, a później TLS’em.
W SSH-1.x największa wada to brak elastyczności protokołu. Na przykład sprawdzanie integralności przesyłanych danych realizowała jednokierunkowa funkcja skrótu CRC32. CRC32 jest dobre do zastosowań telekomunikacyjnych, ale nie w bezpieczeństwie – jest po prostu za krótka. Ponieważ protokół nie pozwalał wymienić CRC32 na coś bezpieczniejszego, do kodu została dodana funkcjonalność wykrywania ataku na CRC32. Niestety, jak to w życiu bywa, jeśli coś od początku nie zostało zrobione porządnie, to później dowolna ilość drutu i taśmy klejącej tego nie naprawi. W 2001 roku pojawił się atak na kod wykrywania ataku na skrót CRC32.
Inne rozwiązania?
Oprócz SSH pojawiają się inne propozycje dające możliwość bezpiecznego logowania np. telnet-ssl, klucze jednorazowe do logowania, itd. Nie zdobywają jednak wystarczającej popularności, są zbyt trudne w użyciu, lub nie dają odpowiedniego poziomu bezpieczeństwa. Świat używa właściwie już tylko i wyłącznie SSH i SSL/TLS.
Nauczony tymi doświadczeniami Tatu Ylönen projektuje (jeszcze przed w/w atakiem) nowy protokół SSH – zwany w skrócie SSH 2.0. Właściwie jest to zupełnie inny protokół niż poprzedni. Posiada wydzielone warstwy (w tym osobną warstwę transportową), jest elastyczny – pozwala dodać dowolne algorytmy szyfrowania, sprawdzania integralności. Ale jest jeden duży minus – autor SSH założył firmę, która sprzedaje SSH w wersji 2.0 jako komercyjne rozwiązanie. Powoduje to, że większa część internetu korzysta z ostatniej darmowej wersji bazującej na protokole SSH 1.5.
W 1999 roku ludzie z projektu OpenBSD biorą ostatnią wolną wersję kodu ssh autorstwa Tatu i zaczynają ją udoskonalać. W taki sposób powstaje OpenSSH – najpopularniejsza obecnie implementacja protokołu SSH. Przez pierwsze lata ich wysiłek wkładany jest w rozwój implementacji oraz dodanie wsparcia dla protokołu SSH-2.0. Korzystając z elastyczności nowego protokołu, rozbudowywane i dodawane są nowe funkcjonalności. Proste tunelowanie, czyli możliwość „zapakowania” ruchu nieszyfrowanego w szyfrowany, rozbudowuje się. Oprócz możliwości budowania tunelu, który zaczyna się na maszynie inicjującej połączenie SSH (local), jest możliwość zbudowania tunelu działającego w drugą stronę (remote). Local używany jest do szyfrowanego łączenia do innych sieci, Remote natomiast pozwala na dostanie się do sieci, z której zainicjowano połączenie SSH. Do SSH dodano możliwość uruchomienia własnego proxy (DynamicForward). Łącząc się z ustawioną opcją DynamicForward, możemy wychodzić do internetu z systemu do którego połączyliśmy się po SSH.
Nie tylko omijamy wszelkie blokady, które mogły być po drodze, ale możemy także udostępnić takie połączenie innym komputerom w naszej sieci lokalnej. Dodano możliwość „przeskakiwania” przez kilka komputerów (ProxyCommand), co pozwala zalogować się do dowolnego systemu tak, jakbyśmy się łączyli do systemu stojącego obok nas. Ponieważ SSH został zaprojektowany tak, aby różne funkcjonalności można było łączyć, coraz więcej osób korzystało z ProxyCommand i SSHFS’a, aby podmontować sobie zasoby plikowe ze zdalnego systemu, do którego nie ma jak się połączyć bezpośrednio.
SSHFS
SSHFS jest dosyć pomysłowym rozwinięciem idei Secure SHell. Na początku to były skrypty w perlu i bash wykonywane na zdalnym systemie, które w połączeniu z częścią SSHFS uruchamianą lokalnie pozwalały zamontować (mechanizm Filesystem in User SpacE – FUSE) zdalne pliki. Szybko jedna wykorzystano podsystem sftp, który po wielu rozbudowach obecnie pozwala na bardzo przyjemne operowanie na zdalnych plikach dowolnej aplikacji.
Korzystając z mechanizmu uwierzytelniania parą kluczy, można mechanizmem Uniksowym pipe ( | ) połączyć wykonanie backupu na systemie A i zapisać jego wynik na systemie B, gdzie stacja, z której łączymy się klientem SSH, nie zapisuje po drodze przesyłanych danych. Ten sam mechanizm jest na tyle elastyczny, że możemy łączyć wynik działania jednego programu i wejście danych do innego bez względu na miejsce wykonywania. Np. możemy podsłuchiwać ruch sieciowy na zdalnym systemie i analizować go w czasie rzeczywistym na naszej stacji roboczej w celu rozwiązania problemu sieciowego.
Ten sam mechanizm powala na automatyzację wykonywania zdalnych poleceń, oraz ograniczenia dany klucz może zrobić. Np. połączenie do systemu z określonym kluczem zawsze uruchomi określony program (i nic innego), ale tylko pod warunkiem połączenia się z określonej sieci/systemu.
W ramach dodawania nowych funkcjonalności pojawiła się możliwość wykorzystania już istniejącego połączenia SSH do przesyłania dodatkowych połączeń. Dzięki temu z punktu widzenia sieciowego mamy jedno połączenie TCP, a wewnątrz niego multiplekser SSH przesyła osobne strumienie danych. Pozwala to na znaczące skrócenie czasu nawiązywania nowego połączenia do tego samego systemu przy krótkich połączeniach lub dużych opóźnieniach w sieci (np. sieci komórkowe).
Kolejne zmiany…
Rok 2003 przyniósł użytkownikom indywidualnym i firmom nowy komunikator (Skype), który szybko zdobył ogromny rynek. Jego największą zaletą było omijanie zabezpieczeń sieci (firewalle, naty), co powodowało, że zyskał duże uznanie wsród użytkowników. Z technicznego punktu widzenia od strony sieciowej nie przyniósł nic nowego – te same możliwości (a często nawet więcej) mamy w OpenSSH. I na dodatek w OpenSSH możemy to wszystko kontrolować.
Możemy np. zezwalać wybranym użytkownikom na uwierzytelnienie z użyciem hasła, ale pod warunkiem, że są w sieci wewnętrznej. Możemy tak skonfigurować klienta ssh, aby po podaniu nazwy host łączył się z nim od razu bez względu na to, czy znajdujemy się w sieci wewnętrznej czy gdzieś w hotelu na drugim końcu świata. Możemy tworzyć własne tunele, udostępniać internet wybranym klientom w sposób w pełni kontrolowany.
Obecnie ta implementacja jest używana w prawie wszystkich dystrybucjach Linuksowych, systemach z rodziny BSD, dużej części urządzeń sieciowych oraz pojawił się port do systemów MS Windows zrobiony przez sam Microsoft. Dzięki OpenSSH możemy łączyć się w sposób bezpieczny oraz zapewnić sobie neutralność sieci (nawet jeśli w danej lokalizacji są urządzenia w tym przeszkadzające).
Autorem artykułu jest Dariusz Puchalak, OSEC.
OSEC Forum 2017 zostało objęte patronatem medialnym przez bloga StrefaKodera.pl.
