Jak źle jest mieć wiele urządzeń z tymi samymi kluczami serwera SSH?

21

Pracuję na wbudowanym urządzeniu z systemem FreeBSD i SSH.

Jak wiesz, sshd lubi losowo generować zestaw kluczy serwera podczas pierwszego uruchamiania. Problem polega na tym, że wyślemy produkt z systemem plików sd-card tylko do odczytu (bez możliwości negocjacji).

Moje dwie opcje, jak je widzę, to:

  • Wyślij te same klucze serwera sshd na wszystkie urządzenia
  • Zamontuj system plików pamięci i generuj klucze serwera przy każdym rozruchu (powoli ...)

Czy wysyłanie tych samych kluczy serwera na wszystkich urządzeniach jest poważnym problemem w zakresie bezpieczeństwa? Te elementy nie będą bezpośrednio w Internecie. Czasami będzie wiele urządzeń należących do tej samej osoby i w tej samej sieci.

Przez większość czasu urządzenie nie będzie podłączone do Internetu.

Logowanie za pomocą SSH nie jest częścią normalnej pracy. Jest to głównie dla wygody programistów i techników. Klienci nie będą logować się do urządzenia za pomocą SSH.

Jakie są konsekwencje używania tych samych kluczy serwera na wielu urządzeniach?

PS czy ktoś mógłby stworzyć tag internetu rzeczy?

EDYCJA : Mówię o instalacji tego samego klucza prywatnego hosta na wszystkich serwerach (urządzeniach). Jeśli chodzi o klucze publiczne / prywatne użytkownika, obecnie nie ma planów używania logowania na podstawie klucza - byłoby to logowanie za pomocą hasła. Ponownie to samo hasło na wszystkich serwerach (urządzeniach).

Wiem, że to chyba zły pomysł. Chciałbym jednak wiedzieć, dlaczego to zły pomysł, aby zrozumieć kompromisy.

NXT
źródło
Jeśli masz na myśli klucze hosta, użytkownicy z więcej niż jednym urządzeniem mogą otrzymywać ostrzeżenia w zależności od konfiguracji klienta ssh. większe obawy dotyczyłyby faktycznych kluczy uwierzytelniających ssh. Mam nadzieję, że nie instalujesz żadnych kluczy prywatnych i mam nadzieję, że twoje klucze publiczne są ograniczone do określonych sieci źródłowych i mam nadzieję, że twoje klucze prywatne będące własnością twoich techników mają na nich mocne hasło i mam nadzieję, że te klucze nigdy nie zostaną przez pomyłkę sprawdzone. IoT mają naprawdę złą nazwę z powodu tych rzeczy. Nie mówię, że tak, po prostu mówiąc, że to duży problem.
Aaron,
Mówię o instalacji tego samego klucza prywatnego hosta na wszystkich serwerach, jeśli o to ci chodzi.
NXT,
2
Używanie tej samej nazwy użytkownika / hasła na wszystkich urządzeniach to bardzo zły pomysł. Są one znacznie łatwiejsze do użycia z użyciem siły brutalnej niż klucz prywatny używany do uwierzytelniania klucza publicznego. Nawet jeśli te urządzenia nie mają być bezpośrednio podłączone do Internetu, ktoś i tak to zrobi. A jeśli „nie podłączony bezpośrednio” oznacza NAT, są one wystarczająco połączone ...
Tero Kilkanen,
7
Udostępnianie klucza SSH oznacza, że ​​osoba, która może uzyskać dostęp do klucza prywatnego na jednym urządzeniu, może podszyć się pod wszystkie te urządzenia.
user253751,
3
Chociaż jest to interesujące pytanie, nie widzę w tym nic związanego z administracją systemem, a zatem jest nie na temat błędu serwera. Pytasz o zaprojektowanie interfejsu debugowania / diagnostyki dla urządzenia wbudowanego, które wysyłasz, a nie interfejsu, który byłby odpowiedni dla sysadmins. To pytanie można przenieść do systemu bezpieczeństwa informacji .
200_success

Odpowiedzi:

27

Zamiast przechowywać dane specyficzne dla hosta, takie jak klucze hosta ssh na karcie SD lub innym nośniku tylko do odczytu, można je przechowywać w pamięci NVRAM, czyli do czego służy w systemie wbudowanym. Będziesz musiał wykonać niestandardowe skrypty, aby przechowywać i odzyskiwać klucze w czasie uruchamiania, ale skrypty będą dokładnie takie same dla każdego urządzenia.

Michael Hampton
źródło
12

Wpływ wysyłki tej samej pary kluczy ze wszystkimi urządzeniami jest bezpośrednio związany z bezpieczeństwem klientów łączących się z nimi, ponieważ oznacza to, że nie ma możliwości (od klienta SSH) jednoznacznej identyfikacji urządzenia, z którym może się łączyć. W razie wycieku pary kluczy można jej użyć do ataków MITM.

Z drugiej strony, ponowne wygenerowanie kluczy przy każdym uruchomieniu spowoduje także wyświetlenie ostrzeżenia dla klientów.

Dla odniesienia man ssh(1):

sshautomatycznie utrzymuje i sprawdza bazę danych zawierającą dane identyfikacyjne dla wszystkich hostów, z którymi kiedykolwiek była używana. Klucze hosta są przechowywane w ~/.ssh/known_hostskatalogu osobistym użytkownika. Ponadto plik /etc/ssh/ssh_known_hostsjest automatycznie sprawdzany pod kątem znanych hostów. Wszelkie nowe hosty są automatycznie dodawane do pliku użytkownika. Jeśli identyfikator hosta kiedykolwiek się zmieni, sshostrzega o tym i wyłącza uwierzytelnianie hasłem, aby zapobiec fałszowaniu serwerów lub atakom typu man-in-the-middle, które w przeciwnym razie mogłyby zostać wykorzystane do obejścia szyfrowania. StrictHostKeyCheckingOpcja może być używany do sterowania maszynami loginów do których klucz hosta nie jest znany lub nie zmieniło.

dawud
źródło
2
Nie rozumiem, dlaczego nie mogą wygenerować tylko raz (na każdym urządzeniu, przy pierwszym uruchomieniu), a następnie nigdy więcej nie wygenerować (chyba że zostaną usunięte)?
djsmiley2k - CoW
Idealnie wykonalne. Ale OP stwierdza, że ​​chce: „Zamontować system plików pamięci i generować klucze serwera przy każdym rozruchu”. Tak więc moja odpowiedź zakłada.
dawud
Ach, tak, przegapiłem to, kiedy czytałem to po raz pierwszy.
djsmiley2k - CoW
5

Wygląda na to, że w pierwszej opcji klucze SSH byłyby dostępne na karcie SD. Aby każdy użytkownik mógł wziąć kartę i odczytać ją. Zasadniczo twoje klucze prywatne stały się (głównie) publiczne.

Umożliwi to ataki typu man-the-the-middle, takie jak:

  1. Użytkownik konfiguruje serwer SSH z kluczami prywatnymi uzyskanymi z urządzenia i przekazuje ten adres IP technikowi.
  2. Twój technik wprowadza hasło roota przez połączenie SSH.
  3. Użytkownik zna teraz hasło roota, które jest ważne dla wszystkich twoich urządzeń.

Jednak nie powinieneś używać haseł roota, zamiast tego użyj kluczy ssh do uwierzytelnienia. Zatem wpływ kluczy serwera współdzielonego jest niewielki, jeśli logujesz się tylko z sieci LAN.

SSH zapewnia również tajemnicę przekazywania, więc osoba atakująca musi mieć możliwość skonfigurowania fałszywego serwera, aby móc korzystać z kluczy; pasywne wąchanie ruchu nie pozwoli na jego odszyfrowanie.

jpa
źródło
To zabawne, jak nasze uprzedzenia mogą nas oślepić (mnie). Karta SD znajduje się wewnątrz urządzenia za panelem i pod płytką drukowaną, więc nigdy nie przyszło mi do głowy, że ktoś ją wyciągnie. Jednak masz rację, jest absolutnie dostępny dla każdego, kto ma śrubokręt. Dziękujemy za przypomnienie, aby rozważyć fizyczne bezpieczeństwo systemu.
NXT,
WRT # 2, hasło roota nie powinno być wysyłane przez połączenie SSH. Powinien być wprowadzony do klienta terminala i wykorzystany do lokalnej połowy protokołu uwierzytelnienia, który potwierdza posiadanie tajnego klucza bez przesyłania tajnego klucza („dowód wiedzy”). Nawet dziesięciolecia systemów wiedziały, że wysyłają skrót hasła, a nie samo hasło. Uwzględnij wartość jednorazową w protokole wyzwania / odpowiedzi, a atakujący nie zna oryginalnego hasła ani tokena, którego można użyć zamiast niego.
Ben Voigt,
1
@BenVoigt Myślę, że większość systemów uniksowych przekazuje hasło do serwera. Plik cienia przechowuje tylko skrót, ale nie chcesz ufać skrótowi wygenerowanemu przez klienta - ponieważ w przeciwnym razie każdy mógłby zalogować się przy użyciu skradzionego skrótu, bez jego odwracania. Tak więc serwer musi znać rzeczywiste hasło, aby uruchomić na nim bcrypt lub podobne.
jpa
2

Przeczytałem to z przerażeniem! Ja, który wykonałem wiele komputerów w tym samym klastrze z tym samym kluczem hosta ssh, nigdy nie odważyłbym się tego zrobić. W żadnym wypadku nie zezwalaj komputerom z różnymi zestawami administratorów na współdzielenie kluczy hosta ssh. W ten sposób kryje się szaleństwo i krzyczący horror, gdy dostajesz wiadomość za brak bezpieczeństwa.

Oto mówię prawdę, ten, kto naruszy jedno urządzenie, narazi je wszystkie. Po zdobyciu jednego, spodziewaj się, że źli ludzie będą skakać od jednego do drugiego do woli, a bezpieczeństwo wycofało się, jakby to był cienki papier.

Joshudson
źródło
1
Czy mógłbyś wyjaśnić, w jaki sposób osoba atakująca użyłaby skradzionego klucza prywatnego serwera do naruszenia bezpieczeństwa innych urządzeń?
jpa
@jpa: W przypadku kluczy hosta poprzez przechwytywanie i kradzież haseł itp. Również ta konfiguracja wydaje się sugerować robienie tego samego z kluczami użytkownika.
joshudson,
1

Ponieważ wspominasz, że dostęp SSH nie jest używany przez użytkownika końcowego / klienta, możesz chcieć domyślnie wyłączyć dostęp SSH i włączyć go tylko tymczasowo, gdy urządzenie przejdzie w tryb „debugowania”.

Następnie możesz wysłać wszystkie urządzenia z tym samym kluczem, zakładając, że chroniłeś tryb „debugowania”, aby nie mógł zostać uruchomiony zdalnie przez osobę próbującą włamać się do urządzenia.

Lub masz wygenerowany nowy klucz, gdy urządzenie przechodzi w tryb „debugowania” - więc nie musisz marnować czasu rozruchu na generowanie kluczy przy każdym włączeniu urządzenia.

Edders
źródło
Podoba mi się ten pomysł.
NXT,
1

Oto przykładowy scenariusz ataku oparty na ograniczeniach:

Jeśli masz urządzenia, powiedz na przykład Raspberry Pi. Jeśli podchodzę i wyciągam kartę SD z jednego, mogę wsunąć kartę SD do własnego komputera, znaleźć klucz sshd i skopiować go w dowolne miejsce. Może biorę własną malinową pi i kartę Ethernet USB. Teraz mogę wsadzić to pomiędzy urządzenie docelowe i gdziekolwiek idą i monitorować połączenia ssh. Kiedy widzę, że urządzenie docelowe próbuje nawiązać połączenie ssh, robię to:

(target) <---> (my evil sshd <--> decrypted traffic <--> ssh) <---> (real server)
                                       |
                                       V
                                    log file

Co to jest? Twoje hasło to „Lubię koty”? Chłopcze, to ciekawy e-mail wysłany do żony. Założę się, że byłoby jeszcze bardziej interesujące, gdyby przeczytała ten e-mail wysłany do żony sąsiadów z sąsiedztwa.

Możliwości są nieograniczone . Cel nigdy się nie dowie, ponieważ klucz sshd jest identyczny z kluczem znalezionym na prawdziwym serwerze. W zależności od fizycznego bezpieczeństwa urządzeń odbierających twoje urządzenie może to być niezwykle trywialne. Nie rób tego

Zamiast tego zrób to, co już zaproponowałeś, ale napraw to . Przed napisaniem obrazu uruchom coś takiego:

ssh-keygen -f some-new-server
cp some-new-server /path/to/the/mounted/image/sshd/key
cp some-new-server.pub /path/to/the/mounted/image/sshd/key.pub

A teraz każdy serwer ma nowy klucz. Ponieważ naprawdę, naprawdę nie chcesz rozpowszechniać kopii klucza. Chodzi mi szczerze, że jest to co najmniej tak złe, jak zrobienie zdjęcia kluczy do domu i przesłanie ich do Internetu za pomocą adresu domowego.

Wayne Werner
źródło
1
Jeśli ktoś ma fizyczny dostęp do twojego sprzętu, a ty nie szyfrujesz danych w spoczynku, wszystkie zakłady są wyłączone.
user9517 obsługuje GoFundMonica