Logowanie SSH i zarządzanie sesją za pomocą AWS SSM

Opublikowany: 2022-03-11

Konfigurowanie niestandardowych narzędzi lub skryptów do przechowywania dziennika SSH w systemie Linux może być żmudne i podatne na błędy.

Inżynierowie mogą używać rootsh , screen lub innego narzędzia do rejestrowania aktywności użytkowników, ale jeśli uprawnienia użytkownika nie są ustawione prawidłowo, doświadczony użytkownik może usunąć dzienniki audytu, aby zatrzeć ślady. Inną opcją byłoby skonfigurowanie logowania na poziomie jądra, ale wiedza potrzebna do tego nie jest tak powszechna.

Na szczęście istnieje sposób na rejestrowanie aktywności użytkowników bez pisania nawet jednego polecenia Linuksa! Będziemy potrzebować tych usług:

  • EC2
  • IAM (zarządzanie tożsamością i dostępem)
  • KMS (usługa zarządzania kluczami)
  • Dzienniki CloudWatch (i/lub S3)
  • Menedżer systemów AWS (wcześniej znany jako SSM)

Zobaczmy, jak skonfigurować każdy z nich.

EC2 i IAM

Uruchamianie instancji EC2 jest zwykle dość łatwe, ale jest jedno kluczowe zadanie, które należy wykonać podczas uruchamiania: musimy przypisać rolę IAM do naszej instancji, w przeciwnym razie nie będziemy w stanie osiągnąć oczekiwanych wyników wyszczególnionych na końcu tego artykuł.

Rola uprawnień, którą powiążemy z naszą instancją EC2, musi mieć wbudowaną zasadę AmazonSSMManagedInstanceCore oraz tę zasadę (dołączoną jako wbudowane lub zarządzane przez klienta):

 { "Version": "2012-10-17", "Statement": [ { "Action": [ "logs:CreateLogStream", "logs:DescribeLogStreams", "logs:DescribeLogGroups", "logs:PutLogEvents" ], "Effect": "Allow", "Resource": "*" } ] }

Oprócz roli IAM zazwyczaj używamy tej konfiguracji instancji EC2:

  • System operacyjny to Amazon Linux 2, ponieważ domyślnie jest dostarczany z zainstalowanym AWS Systems Manager Agent (SSM Agent). (Podobnie jak dystrybucje Ubuntu, które również są opcją).
  • Typ instancji to t3.micro (ale każdy typ będzie odpowiedni).
  • Domyślna grupa zabezpieczeń , którą AWS przypisuje do VPC, będzie działać, ponieważ do tego ćwiczenia nie potrzebujemy otwartego portu SSH.

Możemy zacząć konfigurować KMS bez czekania na uruchomienie instancji EC2.

KMS

Potrzebujemy klucza KMS, jeśli chcemy, aby wszystkie logi sesji dostarczane do CloudWatch były przechowywane w postaci zaszyfrowanej. Przejdźmy do usługi KMS i utwórzmy klucz.

Zrzut ekranu AWS z elementami nawigacyjnymi „KMS”, „Klucze zarządzane przez klienta” i „Utwórz klucz”, obecnie w kroku 1: „Konfiguruj klucz”. „Typ klucza” można ustawić na „Symetryczny” (wybrany) lub „Asymetryczny”. W sekcji „Opcje zaawansowane” ustawienie „Pochodzenie materiału klucza” może mieć wartość „KMS” (wybrany), „Zewnętrzny” lub „Niestandardowy magazyn kluczy (CloudHSM)”.
Krok 1: Wybór typu klucza symetrycznego.

Zrzut ekranu AWS z tymi samymi okruchami chleba, teraz w kroku 2: „Dodaj etykiety”. Pole Alias ​​jest ustawione na „cwlg”, opcjonalne pole Opis jest puste, a opcjonalne pole Tagi nie zawiera żadnych tagów.
Krok 2: Nazywanie naszego klucza.

Zrzut ekranu AWS z tymi samymi okruszkami, teraz w kroku 3: „Zdefiniuj kluczowe uprawnienia administracyjne”. Pierwsze pole „Kluczowi administratorzy” zawiera puste pole wyszukiwania z 10 wierszami wyników (strona 1 z 3) z kolumnami Nazwa, Ścieżka i Typ. Tylko pierwszy wiersz (z odpowiednimi wartościami kolumny „admin”, „/” i „Użytkownik”) ma zaznaczone odpowiednie pole wyboru. Drugie pole „Usunięcie klucza” ma jedną opcję „Zezwalaj administratorom kluczy na usunięcie tego klucza”, która również ma zaznaczone pole wyboru.
Krok 3 (opcjonalnie): Przypisanie administratora.

Zalecamy przypisanie administratora, aby kluczem mogli zarządzać użytkownicy inni niż użytkownik root konta AWS, ale jeśli inni nie będą potrzebować dostępu, możemy pominąć krok 3.

Tutaj wybraliśmy użytkownika IAM „admin” jako administratora klucza, ale możemy wybrać dowolnego użytkownika lub rolę. Możemy również zdecydować się na wyłączenie uprawnień administratora do usuwania kluczy.

Zrzut ekranu AWS z tymi samymi okruszkami, teraz w kroku 4: „Zdefiniuj uprawnienia użycia klucza”. Pierwsze pole „To konto” zawiera te same wyniki wyszukiwania, co w kroku 3, ale żaden z nich nie jest zaznaczony. W drugim polu „Inne konta AWS” nic nie zostało dodane.
Krok 4: Pomijanie strony przypisywania użytkownika.

Nie będziemy przypisywać żadnych użytkowników do tego klucza, ponieważ chcemy, aby ten klucz był używany tylko przez usługę CloudWatch Logs do operacji szyfrowania i odszyfrowywania dzienników SSH.

Zrzut ekranu AWS z tymi samymi okruchami chleba, teraz w kroku 5: „Przejrzyj”. Pierwsze pole „Konfiguracja klucza” zawiera „Typ klucza” jako „Symetryczny”, „Specyfikacja klucza” jako „SYMMETRIC_DEFAULT”, „Użycie klucza” jako „Szyfrowanie i odszyfrowywanie” oraz „Pochodzenie” jako „AWS_KMS ”. Następne pole „Alias ​​i opis” zawiera jeden alias „cwlg” bez opisu. Następne pole „Tagi” nie zawiera żadnych danych. Ostatnie pole, „Zasady dotyczące kluczy”, zawiera pole tekstowe wypełnione zasadą w formacie JSON.
Krok 5: Przejrzyj naszą konfigurację i zamień domyślne zasady dotyczące kluczy.

Na stronie Przejrzyj będziemy musieli zmienić zasady dotyczące kluczy wygenerowanych przez KMS, ponieważ nie obejmują one uprawnień CloudWatch Logs do korzystania z klucza. Zastąpimy je następującymi zasadami:

 { "Version": "2012-10-17", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow access for Key Administrators", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:user/USERNAME" }, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion" ], "Resource": "*" }, { "Sid": "Allow access to CloudWatch Log", "Effect": "Allow", "Principal": { "Service": "logs.REGION.amazonaws.com" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*", "Condition": { "ArnLike": { "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:REGION:ACCOUNT_ID:*" } } } ] }

Pamiętaj, aby zastąpić wszystkie symbole zastępcze:

  • ACCOUNT_ID staje się naszym identyfikatorem konta AWS.
  • USERNAME staje się nazwą użytkownika administratora wybraną w kroku 3. Jeśli zrezygnowaliśmy z tego kroku, tutaj usuwamy drugi blok instrukcji (ten z "Sid": "Allow access for Key Administrators" ).
  • REGION staje się regionalnym kodem identyfikacyjnym, dla którego wdrażamy usługi (np. us-west-1 ).

Dzięki temu KMS jest gotowy do pracy.

CloudWatch Log Group

Następnie potrzebujemy grupy CloudWatch Log (i/lub zasobnika S3 — patrz poniżej), gdzie Agent SSM może wysyłać logi sesji SSH. Stwórzmy to.

Zrzut ekranu AWS z okruszkami „CloudWatch”, „Dzienniki CloudWatch”, „Grupy dzienników” i „Utwórz grupę dzienników”. Nie ma wieloetapowego paska bocznego. Pierwsze pole „Szczegóły grupy dzienników” ma trzy podpola: „Nazwa grupy dzienników” (ustawione na „ssm-session-demo”), „Ustawienia przechowywania” (ustawione na „Nigdy nie wygasają” z menu) oraz „KMS klucz ARN — opcjonalny” (ustawiony na obciętą wartość zaczynającą się od „arn:aws:kms”). Drugie pole „Tagi” nie zawiera tagów.
Tworzenie grupy logów „CloudWatch Logs”.

Zwróć uwagę na pole ARN klucza KMS: AWS udostępnia nam wartość potrzebną w tym miejscu po utworzeniu klucza w kroku 5 sekcji KMS.

(Jeśli wcześniej nie powiązaliśmy prawidłowej polityki z naszym kluczem KMS, umożliwiając usłudze CloudWatch Logs użycie klucza, w tym momencie otrzymamy błąd związany z kluczem KMS.)

Przechowywanie dzienników SSH w zasobniku S3

Aby przechowywać dzienniki aktywności za pomocą S3 zamiast — lub oprócz — CloudWatch Logs, musimy dodać te uprawnienia do naszego profilu instancji EC2 jako oddzielną politykę (lub ręcznie połączyć je z innymi uprawnieniami, które mogą być nam potrzebne):

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::BUCKET_NAME/*" }, { "Effect": "Allow", "Action": [ "s3:GetEncryptionConfiguration" ], "Resource": "*" }, { "Effect": "Allow", "Action": "kms:GenerateDataKey", "Resource": "*" } ] }

W powyższym fragmencie pamiętaj, aby zastąpić symbol zastępczy BUCKET_NAME .

Teraz, gdy mamy skonfigurowane miejsce do przechowywania dzienników — logi CloudWatch, zasobnik S3 lub oba te elementy — jesteśmy gotowi do korzystania z sesji SSH.

Menedżer sesji AWS Systems Manager

To jest ostatni kluczowy krok, w którym konfigurujemy bezpieczny dostęp do naszej maszyny z systemem Linux w celu monitorowania i rejestrowania sesji SSH. Zaczniemy od pulpitu Menedżera sesji.

Zrzut ekranu pulpitu menedżera sesji AWS z sekcjami „Jak to działa”, „Dlaczego używać Menedżera sesji?”, „Pierwsze kroki”, „Więcej zasobów” oraz w prawym górnym rogu „Rozpocznij sesję”. Ta ostatnia sekcja ma pomarańczowy przycisk „Rozpocznij sesję” i biały przycisk „Konfiguruj preferencje”.
Krok 1: Rozpoczęcie korzystania z pulpitu nawigacyjnego.

Na pulpicie kliknij biały przycisk „Konfiguruj preferencje” w prawym górnym polu „Rozpocznij sesję”, aby włączyć rejestrowanie sesji.

Na stronie Preferencje znajdziemy wiele sekcji, które moglibyśmy zbadać, ale skupimy się na przesyłaniu strumieniowym dzienników sesji SSH do CloudWatch lub S3, aby umożliwić nam szybkie sprawdzenie, co dzieje się na naszej maszynie z systemem Linux.

Zrzut ekranu sekcji AWS zatytułowanej „Logowanie CloudWatch”. Jego pierwsze ustawienie, zwane również „rejestrowaniem CloudWatch”, ma pole wyboru oznaczone jako Włącz, które jest zaznaczone. Następne ustawienie „Wybierz preferowaną opcję rejestrowania” ma wybraną opcję „Przesyłaj dzienniki sesji (zalecane)” zamiast „Prześlij dzienniki sesji”. Następne ustawienie, „Wymuszaj szyfrowanie”, ma pole wyboru „Zezwalaj tylko na zaszyfrowane grupy dzienników CloudWatch”, które jest zaznaczone. Ostateczne ustawienie, „Grupa dzienników CloudWatch”, ma wybraną opcję „Wybierz nazwę grupy dzienników z listy” zamiast „Wprowadź grupę dzienników w polu tekstowym”. Poniżej znajduje się lista „Grupy dzienników CloudWatch” z zaznaczoną opcją „ssm-session-demo”. Ma odpowiednie kolumny „Szyfrowanie” (ustawione na „Zaszyfrowane”), „Wygaśnięcia zdarzeń po” (ustawione na „Nigdy nie wygasają”), „Filtry metryczne” (ustawione na 0), „Przechowywane bajty” (ustawione na 0) i znacznik czasu „Czas utworzenia”.
Krok 2a: Włączenie logowania CloudWatch.

Tuż za sekcją „Logowanie CloudWatch” znajduje się sekcja „Logowanie S3”, w której możemy wybrać zasobnik.

Zrzut ekranu sekcji AWS zatytułowanej „Logowanie S3”. Pierwsze ustawienie, „Wyślij dzienniki sesji do S3”, ma zaznaczone pole wyboru „Włącz”. Kolejne ustawienie, „Wymuś szyfrowanie”, ma zaznaczone pole wyboru „Zezwalaj tylko na zaszyfrowane zasobniki S3”. Kolejne ustawienie, „Wybierz zasobnik S3”, ma wybraną opcję „Wybierz nazwę zasobnika z listy” zamiast „Wprowadź nazwę zasobnika w polu tekstowym”. Poniżej z rozwijanej listy wybierane jest „ssm-session-demo”. Ostatnie pole „Prefiks klucza S3 — opcjonalny” jest puste.
Krok 2b: Włączenie rejestrowania S3.

Po skonfigurowaniu rejestrowania SSH możemy SSH do naszego komputera z systemem Linux i wykonać kilka poleceń, aby sprawdzić, czy aktywność jest przechwytywana, czy nie.

Zacznijmy więc sesję. Na tej samej stronie znajdziemy zakładkę „Sesje”, w której możemy rozpocząć sesję. Kliknięcie przycisku „Rozpocznij sesję” da nam listę maszyn EC2, na których możemy zainicjować sesję:

Zrzut ekranu AWS z bułką tartą AWS Systems Manager, Session Manager i Start a session. W polu wyszukiwania „Wystąpienia docelowe” nie ma wypełnionego zapytania i jest tylko jeden wynik, a „Nazwa wystąpienia” ustawiono na „SSM Demo”.
Krok 3: Wybór naszej instancji EC2 do rozpoczęcia sesji SSH.

Jeśli nie widzimy na liście naszej instancji EC2 Linux, powinniśmy sprawdzić, czy jest ona uruchomiona i ma powiązane z nią uprawnienia IAM, które opisaliśmy wcześniej.

Obsługa błędu agenta SSM „Nie obsługuje dzienników przesyłania strumieniowego”

W przypadku, gdy otrzymamy błąd mówiący, że wersja agenta SSM zainstalowana na naszym komputerze EC2 nie obsługuje przesyłania strumieniowego logów CloudWatch, nie martw się. Jest bezbolesny sposób na naprawienie tego.

Zrzut ekranu komunikatu o błędzie AWS z białym tekstem na czerwonym tle. X obok komunikatu „Wersja agenta SSM zainstalowana w tej instancji nie obsługuje przesyłania strumieniowego dzienników do CloudWatch. Zaktualizuj agenta SSM do najnowszej wersji lub wyłącz opcję przesyłania strumieniowego dzienników w swoich preferencjach”.
Potencjalny błąd „nieaktualnej wersji agenta SSM”.

Aby zaktualizować agenta SSM, musimy przejść do opcji Uruchom polecenie w lewym panelu usługi AWS Systems Manager .

Zrzut ekranu pulpitu nawigacyjnego AWS Systems Manager Run Command z sekcjami „Jak to działa”, „Funkcje i korzyści”, „Przypadki użycia i wpisy na blogu”, „Dokumentacja” oraz w prawym górnym rogu „Zarządzaj instancjami”. Ta sekcja zawiera tylko pomarańczowy przycisk „Uruchom polecenie”.
Krok 1: Rozpoczęcie od pulpitu nawigacyjnego „Uruchom polecenie”.

Gdy już tam jesteśmy, możemy kliknąć pomarańczowy przycisk „Uruchom polecenie”, co prowadzi do nowej strony, na której możemy wypełnić niektóre parametry.

Zrzut ekranu AWS z bułką tartą AWS Systems Manager, Run Command i Run a command. Pole wyszukiwania o nazwie „Dokument polecenia” zawiera 10 wierszy (strona 4 lub więcej niż 5), z zaznaczonym jednym o nazwie „AWS-UpdateSSMAgent”. Ma „Amazon” w kolumnie „Właściciel” i „Windows, Linux” w kolumnie „Typy platform”. W polu na dole „Wersja dokumentu” z listy rozwijanej wybrano „1 (domyślna)”.
Krok 2: Wybór dokumentu poleceń.

Zaczniemy od wybrania z listy AWS-UpdateSSMAgent .

Zrzut ekranu sekcji AWS zatytułowanej „Cele”. Pierwsze pole, zwane również „Celami”, zawiera opcje „Określ tagi wystąpień”, „Ręcznie wybierz wystąpienia” (wybrane) i „Wybierz grupę zasobów”. Na dole znajduje się pole wyszukiwania „Instancje” bez zapytania, z zaznaczonym jedynym wynikiem „SSM Demo”. Odpowiedni identyfikator instancji w wierszu jest kopiowany do pola tuż nad „Instancjami” z X.
Krok 3: Wybór instancji EC2 z agentem SSM wymagającym aktualizacji.

Po wybraniu będziemy przewijać w dół, aż zobaczymy sekcję „Cele”. Tam musimy wybrać instancję EC2, na której chcemy zaktualizować Agenta SSM, a następnie nacisnąć przycisk „Uruchom” na końcu. To przeniesie nas na stronę, na której możemy monitorować postęp aktualizacji.

Zrzut ekranu AWS z bułką tartą „AWS Systems Manager”, „Run Command” i „Command ID” (z identyfikatorem GUID). Pierwsza sekcja, „Stan polecenia”, pokazuje wskaźniki powodzenia, podobnie jak jedyny wiersz następnej sekcji, „Cele i wyniki”, która zawiera listę pojedynczych wystąpień z wcześniejszej części. Na dole znajdują się również dwie nierozwinięte sekcje: „Opis poleceń” i „Parametry poleceń”.
Krok 4: Monitorowanie postępu naszej aktualizacji.

Aktualizacja agenta nie powinna zająć więcej niż pięć minut. Po wykonaniu tej czynności powinniśmy móc ponownie utworzyć sesję w Menedżerze sesji.

W tym momencie powinniśmy mieć rozpoczętą sesję SSH.

Zrzut ekranu AWS z identyfikatorem sesji i identyfikatorem instancji nad terminalem. Znak zachęty to „sh-4.2$”, a wprowadzono polecenia „whoami” i „pwd” z wyjściami odpowiednio „ssm-user” i „/usr/bin”.
Sesja SSH przy użyciu agenta SSM za pośrednictwem Menedżera sesji AWS Systems Manager.

Po wykonaniu kilku poleceń przejdźmy do grupy logów CloudWatch Logs (lub naszego wiadra S3, nie pokazanego) i potwierdźmy, że aktywność jest rejestrowana.

Zrzut ekranu AWS z okruszkami „CloudWatch”, „Logami CloudWatch”, „Grupami dzienników”, „ssm-session-demo” i identyfikatorem sesji z poprzedniego kroku. Jedyna sekcja to pole wyszukiwania „Dziennik zdarzeń” z wierszami, z których każdy ma sygnaturę czasową i wiadomość w formacie JSON. Jedna z nich została rozszerzona, aby odsłonić ładnie wydrukowany format JSON i biały przycisk po prawej z napisem „Kopiuj”.
Zdarzenia dziennika SSH rejestrowane w CloudWatch Logs.

Mamy teraz konfigurację z włączonym szyfrowaniem w spoczynku, która rejestruje każde polecenie uruchomione na naszym komputerze z systemem Linux.

W rzeczywistości każdej komendy może być więcej niż byśmy chcieli: wszelkie sekrety dostarczone lub wygenerowane podczas sesji zostaną zapisane w CloudWatch lub S3 i będą widoczne dla każdego, kto ma wymagane uprawnienia. Aby temu zapobiec, możemy użyć stty -echo; read passwd; stty echo; stty -echo; read passwd; stty echo; za każdy sekret, który musimy podać podczas sesji.

Świetne rozwiązanie do rejestrowania SSM/SSH AWS z drobnymi zastrzeżeniami

Menedżer sesji to przydatne narzędzie do uzyskania zdalnego dostępu do naszych maszyn wirtualnych w AWS bez konieczności otwierania portu 22. W rzeczywistości nie możemy w ten sposób generować logów SSH, jeśli jako Menedżer sesji korzystamy z przekierowania portów lub bezpośredniego połączenia SSH notatki dotyczące dokumentacji.

Niemniej jednak połączenie Menedżera sesji z rejestrowaniem sesji jest niezawodnym rozwiązaniem do kontrolowania i monitorowania aktywności na maszynach wirtualnych. Ponadto nie pobieramy opłat za korzystanie z usługi Menedżera sesji. Płacimy tylko za naszą instancję EC2 i CloudWatch Logs lub wiadro S3 do przechowywania logów.

Dla czytelników, którzy preferują samouczki wideo, nieco dokładniej omówiłem bardzo podobną procedurę na YouTube.

Dalsza lektura na blogu Toptal Engineering:

  • Studium przypadku: Dlaczego korzystam z infrastruktury chmury AWS dla moich produktów