Ssh on Morfitronik

Wsparcie dla WiFi w initramfs/initrd by odszyfrować LUKS przez SSH bezprzewodowo

Mikhail Morfikov — Sat, 13 Nov 2021 13:26:00 +0100

W poprzednim artykule, który traktował o odszyfrowaniu kontenera LUKS przez SSH z poziomu initramfs/initrd na Raspberry Pi, została poruszona kwestia adresacji IP, która w opisanym tam rozwiązaniu miała pewne ograniczenia. Chodziło o to, że połączenie SSH do RPI mogło być realizowane jedynie przez przewodowy interfejs sieciowy eth0 . Trzeba było zatem się zastanowić nad rozwiązaniem, które umożliwiłoby korzystanie również z bezprzewodowego interfejsu WiFi, tj. wlan0 . Celem niniejszego wpisu jest pokazanie w jaki sposób można dorobić wsparcie dla połączeń WiFi w naszej malinie, tak by szło odszyfrować kontener LUKS przez SSH, w sytuacji gdy z jakiegoś powodu nie chcemy lub też nie możemy korzystać z przewodowego interfejsu sieciowego tego minikomputera z zainstalowanym system RasPiOS/Raspbian.

Odszyfrowanie LUKS przez SSH z poziomu initramfs/initrd na Raspberry Pi

Mikhail Morfikov — Fri, 12 Nov 2021 23:13:00 +0100

Od paru dni bawię się swoim Raspberry Pi w kontekście zaszyfrowania jego systemu RasPiOS/Raspbian. O ile samo zaszyfrowanie tego minikomputera przy pomocy mechanizmu LUKS nie było jakoś specjalnie trudne, to trzeba było pomyśleć nad rozwiązaniami mającymi ułatwić otworzenie takiego zaszyfrowanego kontenera przy starcie systemu. Póki co udało się wypracować w miarę zadowalające rozwiązanie wykorzystujące dedykowane urządzenia USB w roli klucza, bez którego system się nie uruchomi. Są jednak i inne rozwiązania, które mogą nam pomóc odszyfrować system RPI bez potrzeby fatygowania się do pomieszczenia i wtykania w jej port USB jakiegoś pendrive. Mowa o zaprzęgnięciu usługi SSH, która by została uruchomiona w fazie initramfs/initrd, chwilę przed wpisaniem hasła do kontenera LUKS. Takie rozwiązanie wymaga jednak zainstalowania innego serwera SSH, tj. Dropbear, pogodzenia go z serwerem OpenSSH oraz też trzeba odpowiednio przygotować sam obraz initramfs/initrd. Po pomyślnym skonfigurowaniu systemu, będziemy się logować do Raspberry Pi przez SSH i wpisywać hasło do kontenera LUKS, a jeśli to hasło będzie prawidłowe, to system zostanie odszyfrowany i uruchomiony.

Jak skonfigurować połączenie VPN przez SSH

Mikhail Morfikov — Sun, 11 Dec 2016 15:59:06 +0000

Szukając informacji na temat ukrycia ruchu generowanego przez OpenVPN, natrafiłem także na sposób, który wykorzystuje do tego celu połączenie SSH. W efekcie jesteśmy w stanie upodobnić ruch VPN do tego, który zwykle służy do zarządzania zdalnymi systemami linux. Jako, że temat maskowania połączenia VPN jest kluczowy w walce z cenzurą internetu, to im więcej sposobów, by taki zabieg przeprowadzić, tym lepiej. Dlatego też postanowiłem odświeżyć nieco podlinkowany wyżej artykuł i sprawdzić czy jest on jeszcze aktualny. Wprawdzie nie dysponuję Ubuntu, a jedynie dystrybucją Debian ale raczej nie powinno być problemów z odwzorowaniem konfiguracji na tym systemie, choć artykuł jest dość leciwy już i pewnie trzeba będzie kilka rzeczy zaktualizować.

DD-WRT: SSH port forwarding i panel aministracyjny

Mikhail Morfikov — Mon, 12 Sep 2016 17:29:22 +0000

Firmware DD-WRT oferuje kilka sposobów na uzyskanie dostępu do naszego domowego routera. Poza graficznym panelem webowym, gdzie wszystko możemy sobie wyklikać, mamy jeszcze tekstowy telnet i SSH. DD-WRT jest nam w stanie także zaoferować SSH port forwarding. Ten mechanizm z kolei bardzo przydaje się w momencie, gdy chcemy uzyskać dostęp do routera przez panel administracyjny ale nie uśmiecha nam się wystawianie go na widok publiczny po niezabezpieczonym protokole HTTP. Z kolei serwer www posiadający zaimplementowany protokół SSL/TLS jest dość zasobożerny i jego zastosowanie średnio nadaje się w przypadku małych routerów. Za pomocą przekierowania portów SSH możemy uzyskać dostęp do lokalnej instancji panelu webowego omijając obydwa te powyższe problemy. Panel admina pozostaje schowany w sieci lokalnej, a my logujemy się do niego wykorzystując połączenie SSH.

DD-WRT: Dostęp do routera (telnet, ssh, panel web)

Mikhail Morfikov — Sun, 11 Sep 2016 12:42:30 +0000

Do routera posiadającego na pokładzie firmware DD-WRT możemy uzyskać dostęp na kilka sposobów. Ten najbardziej popularny, to oczywiście panel administracyjny dostępny z poziomu www, na który możemy się dostać wpisując w pasku adresu przeglądarki http://192.168.1.1/ . Niemniej jednak, to nie jest jedyna droga do zarządzania routerem. Standardowo również mamy aktywną usługę telnet. Dodatkowo możemy aktywować SSL/TLS w panelu admina oraz dorobić usługę SSH. W tym artykule omówimy sobie wszystkie te formy dostępu do routera.

packet_write_wait: Connection to IP port 22: Broken pipe

Mikhail Morfikov — Wed, 03 Aug 2016 13:41:52 +0000

Operowanie na VPS nie jest jakoś specjalnie trudne, zwłaszcza w przypadku, gdy mamy dostęp root i możemy logować się na serwer z wykorzystaniem protokołu SSH. Dalej to już zwykła linux'owa mechanika, która może być nieco inna, w zależności od tego, jaki dokładnie system operacyjny na tym VPS stoi. Czasami jednak, w pewnym momencie podczas połączenia możemy zostać rozłączeni z niewiadomych nam przyczyn. Niemniej jednak, zawsze, gdy ten problem występuje, w terminalu można zobaczyć komunikat: packet_write_wait: Connection to 1.2.3.4 port 22: Broken pipe . Przydałoby się zatem coś na ten stan rzeczy poradzić.

Zdalny backup przy pomocy rsync, ssh i sudo

Mikhail Morfikov — Thu, 28 Jul 2016 23:15:55 +0000

Mój VPS, jako że jest dość tani, nie zawiera całej masy wynalazków. Jedną z tych bardziej użytecznych rzeczy jest backup danych na dysku VPS'a. OVH liczy sobie trochę grosza za usługę snapshot'ów. Dlatego też byłem zmuszony poszukać innego rozwiązania, które sprawiłoby, że kopia wszystkich ważnych plików byłaby zawsze poza granicami tego VPS. Najlepiej, gdyby te pliki były umieszczany na moim własnym komputerze, czy jakiejś stacji roboczej, która ma robić za taki backup'owy serwer. Problem w tym, że ciężko jest zsynchronizować sobie poprawnie katalogi na odległość, choć jest to możliwe przy pomocy ssh , rsync oraz sudo . Z tym, że mamy tutaj szereg problemów związanych z uprawnieniami do plików. No i oczywiście trzeba także uwzględnić inny port SSH. Trochę było z tym zamieszania ale ostatecznie udało się to zadanie rozwiązać.

Klucze szyfrujące RSA w OpenWRT (ssh)

Mikhail Morfikov — Sun, 24 Apr 2016 01:14:41 +0000

Klucze RSA w protokole SSH mogą być wykorzystane jako sposób identyfikacji danej osoby przy logowaniu się do zdalnego serwera. Te klucze zawsze występują w parach. Jeden prywatny, drugi publiczny. Pierwszy z nich jest znany tylko nam i powinien być trzymany w sekrecie i pilnie strzeżony. Klucz publiczny z kolei zaś jest przesyłany na każdy serwer SSH, z którym chcemy się połączyć. Gdy serwer jest w posiadaniu naszego klucza publicznego i widzi przy tym, że próbujemy nawiązać połączenie, używa on tego klucza, by wysłać do nas zapytanie (challange). Jest ono zakodowane i musi na nie zostać udzielona prawidłowa odpowiedź. Tej z kolei może udzielić ktoś, kto jest w posiadaniu klucza prywatnego. Nie ma innej opcji, by rozkodować wiadomość. Dlatego też nikt inny nie może udzielić na nią prawidłowej odpowiedzi. To rozwiązanie eliminuje wrażliwość na różne formy podsłuchu. Ten kto nasłuchuje nie będzie w stanie przechwycić pakietów zawierających hasło, bo ono nie jest nigdy transmitowane prze sieć. No i oczywiście jeśli chodzi o samo hasło, to odpadają nam ataki bruteforce pod kątem jego złamania. W tym wpisie postaramy się zaimplementować na routerze z OpenWrt system logowania oparty o klucze RSA.

Dostęp do routera OpenWRT (telnet, ssh, sshfs)

Mikhail Morfikov — Sun, 24 Apr 2016 00:00:51 +0000

Standardowa instalacja OpenWRT nie zawiera w sobie żadnego trybu graficznego czy też panelu www. Wszelkie operacje trzeba przeprowadzać przy pomocy terminala. Mimo to, OpenWRT daje nam kilka możliwości na uzyskanie dostępu do routera. Ten firmware ma zaimplementowaną obsługę protokołu telnet, który swoją drogą nie należy do bezpiecznych. Oprócz niego, mamy możliwość logowania się za pomocą protokołu SSH. Tutaj sprawa bezpieczeństwa ma się o wiele lepiej. Poza tym, można bardzo łatwo zaimplementować klucze SSH eliminując tym samym dostęp oparty o wprowadzanie hasła przy logowaniu. Czy takie zabezpieczenia nam są potrzebne w domowych warunkach? Tę kwestię niech sobie każdy użytkownik rozważy sam. Dodatkowo, jeśli już wspomnieliśmy o protokole SSH, to warto poruszyć kwestię protokołu SSHFS, czyli możliwości zamontowania systemu plików routera lokalnie na komputerze. Daje nam to możliwość przeglądania takiego systemu plików jak zwykłego katalogu. No i mamy też uproszczoną edycję plików, która może odbywać się w trybie graficznym przy pomocy narzędzi, z których zwykle korzystamy na swoim PC. W tym wpisie rzucimy okiem na te poszczególne metody i przy pomocy każdej z nich spróbujemy uzyskać dostęp do routera.

Szyfrowanie dźwięku przesyłanego przez sieć

Mikhail Morfikov — Sun, 01 Nov 2015 00:31:48 +0000

PulseAudio to serwer dźwięku, który jest w stanie otrzymywać zapytania ze zdalnych lokalizacji. Wobec czego, możemy realizować przesyłanie dźwięku przez sieć i usłyszeć go tam, gdzie go sobie życzymy. Problem w tym, że taki dźwięk jest przesyłany przez sieć w formie niezaszyfrowanej. Dlatego też jesteśmy narażeni na podsłuchanie wszystkiego co mówimy do mikrofonu lub też tego co pojawia się w naszych głośnikach. Możemy jednak zabezpieczyć komunikację między klientem i serwerem dźwięku wykorzystując do tego połączenie SSH. W ten sposób cały sygnał dźwiękowy, jaki jest generowany przez danego hosta w sieci, zostanie wrzucony w szyfrowany kanał TLS i nikt nie będzie w stanie go zinterpretować. Ten wpis ma na celu przedstawienie sposobu na zaszyfrowanie dźwięku, bez którego większość z nas nie wyobraża sobie pacy przy komputerze.

Szyfrowanie ruchu do Xserver'a przy pomocy SSH

Mikhail Morfikov — Sat, 31 Oct 2015 16:47:10 +0000

W przypadku zaufanych sieci lokalnych, czy też kontenerów LXC, nie musimy zbytnio się troszczyć o bezpieczeństwo przesyłanych danych. Nikt nam przecież nie założy tutaj podsłuchu. Dlatego też we wpisie poświęconym konfiguracji Wine nie szyfrowaliśmy praktycznie żadnego ruchu sieciowego. Gdyby jednak zaszła potrzeba przesłania pakietów do zdalnego Xserver'a przez internet, to takie rozwiązanie naraziłoby nas na przechwycenie wszystkich danych. By zabezpieczyć się przed tego typu scenariuszem możemy zaszyfrować ruch do Xserver'a forward'ując wszystkie zapytania przy pomocy szyfrowanego tunelu TLS. Możemy to zrobić przy pomocy SSH i w tym wpisie postaramy się skonfigurować ten mechanizm.

Uwierzytelniające klucze SSH

Mikhail Morfikov — Tue, 02 Jun 2015 15:35:53 +0000

Klucze SSH mogą być wykorzystane jako sposób identyfikacji danej osoby przy logowaniu się do zdalnego serwera SSH. Te klucze zawsze występują w parach -- jeden prywatny, drugi publiczny. Pierwszy z nich jest znany tylko nam i powinien być trzymany w sekrecie i pilnie strzeżony. Klucz publiczny z kolei zaś jest przesyłany na każdy serwer SSH, z którym chcemy się połączyć. Gdy serwer jest w posiadaniu naszego klucza publicznego i widzi przy tym, że próbujemy nawiązać połączenie, używa on tego klucza by wysłać do nas zapytanie (challange) -- jest ono zakodowane i musi na nie zostać udzielona odpowiednia odpowiedź, a tej może dokonać ktoś, kto jest w posiadaniu klucza prywatnego. Nie ma innej opcji by rozkodować wiadomość, dlatego też nikt inny nie może udzielić na nią prawidłowej odpowiedzi. To rozwiązanie eliminuje wrażliwość na różne formy podsłuchu -- ten kto nasłuchuje nie będzie w stanie przechwycić pakietów zawierających hasło, bo ono nie jest nigdy transmitowane prze sieć. No i oczywiście jeśli chodzi o samo hasło -- odpadają nam ataki typu Brute Force pod kątem jego złamania.

GitHub z obsługą kluczy SSH

Mikhail Morfikov — Sun, 17 May 2015 21:06:05 +0000

W końcu przyszedł czas na eksperymenty z serwisem GitHub. Jakby nie patrzeć, do tej pory jedyne co potrafiłem zrobić w przypadku samego gita, to wydać jedno polecenie, którym było git clone . Wszelkie inne rzeczy, choć nie było ich wcale tak dużo, robiłem via panel www, co trochę było upierdliwe. Postanowiłem nauczyć się obsługi gita i nieco uprościć sobie życie. Jeśli chodzi o samą naukę, to tutaj jest dostępny dość obszerny pdf (prawie 500 stron). Nie będę tutaj przerabiał wyżej podlinkowanej książki, bo w sumie jeszcze jej nie przeczytałem, tylko zajmę się ciekawym tematem jakim jest implementacja kluczy SSH, tak by operować na gicie bez zbędnych haseł.