Înregistrare SSH și gestionare a sesiunilor folosind AWS SSM

Publicat: 2022-03-11

Configurarea instrumentelor sau scripturilor personalizate pentru a păstra un jurnal SSH pe Linux poate fi plictisitoare și predispusă la erori.

Inginerii pot folosi rootsh , screen sau alt utilitar pentru a înregistra activitatea utilizatorului, dar dacă permisiunile utilizatorului nu sunt setate corect, un utilizator calificat poate șterge jurnalele de audit pentru a-și acoperi urmele. O altă opțiune ar fi configurarea logării la nivel de kernel, dar expertiza necesară pentru asta nu este atât de comună.

Din fericire, există o modalitate de a înregistra activitatea utilizatorului fără a scrie măcar o singură comandă Linux! Vom avea nevoie de aceste servicii:

  • EC2
  • IAM (Gestionarea identității și accesului)
  • KMS (serviciu de gestionare a cheilor)
  • Jurnalele CloudWatch (și/sau S3)
  • AWS Systems Manager (cunoscut anterior ca SSM)

Să vedem cum să setăm fiecare dintre ele.

EC2 și IAM

Lansarea unei instanțe EC2 este în mod normal destul de ușoară, dar există o sarcină cheie care trebuie făcută în timpul lansării: trebuie să atașăm un rol IAM instanței noastre, altfel nu vom putea obține rezultatele așteptate detaliate la sfârșitul acestui articol. articol.

Rolul IAM pe care îl asociem cu instanța noastră EC2 trebuie să aibă încorporată politica AmazonSSMManagedInstanceCore , plus această politică (atașată ca inline sau gestionată de client):

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

Pe lângă rolul IAM, în general folosim această configurație de instanță EC2:

  • Sistemul de operare este Amazon Linux 2, deoarece implicit vine cu AWS Systems Manager Agent (SSM Agent) instalat. (La fel și distribuțiile Ubuntu, care sunt, de asemenea, o opțiune.)
  • Tipul de instanță este t3.micro (dar orice tip va face).
  • Grupul de securitate implicit pe care AWS îl alocă VPC-ului va funcționa, deoarece nu avem nevoie de un port SSH deschis pentru acest exercițiu.

Putem începe să setăm KMS fără a aștepta pornirea instanței EC2.

KMS

Avem nevoie de o cheie KMS dacă dorim ca toate jurnalele de sesiune livrate către CloudWatch să fie stocate criptate. Să mergem la serviciul KMS și să creăm o cheie.

O captură de ecran a AWS cu breadcrumb „KMS”, „Chei gestionate de client” și „Creare cheie”, în prezent la Pasul 1: „Configurare cheie”. „Tipul cheii” poate fi setat la „Simetric” (selectat) sau „Asimetric”. Sub „Opțiuni avansate”, setarea „Originea materialului cheie” poate fi „KMS” (selectat), „Extern” sau „Magazin de chei personalizat (CloudHSM).”
Pasul 1: Alegerea unui tip de cheie simetrică.

O captură de ecran a AWS cu aceleași pesmet, acum la Pasul 2: „Adăugați etichete”. Un câmp Alias ​​este setat la „cwlg”, un câmp opțional Descriere este lăsat necompletat, iar un câmp opțional Etichete nu are etichete adăugate.
Pasul 2: Numirea cheii noastre.

O captură de ecran a AWS cu aceleași pesmeturi, acum la Pasul 3: „Definiți permisiunile administrative cheie”. Primul câmp, „Administratori cheie”, are o casetă de căutare goală cu 10 rânduri de rezultate (pagina 1 din 3) cu coloanele Nume, Cale și Tip. Doar primul rând (cu valorile respective ale coloanei „admin”, „/” și „Utilizator”) are caseta de selectare corespunzătoare bifată. Celălalt câmp, „Ștergerea cheii”, are o singură opțiune, „Permiteți administratorilor cheilor să șteargă această cheie”, care are și caseta de selectare bifată.
Pasul 3 (opțional): Atribuirea unui administrator.

Vă recomandăm să atribuiți un administrator, astfel încât cheia să poată fi gestionată de alți utilizatori decât utilizatorul root al contului AWS, dar dacă alții nu vor avea nevoie de acces, putem sări peste Pasul 3.

Aici am ales utilizatorul IAM „admin” ca administrator cheie, dar suntem liberi să alegem orice utilizator sau rol. De asemenea, putem opta pentru a dezactiva permisiunea de ștergere a cheilor pentru administrator.

O captură de ecran a AWS cu aceleași pesmeturi, acum la Pasul 4: „Definiți permisiunile de utilizare a cheilor”. Primul câmp, „Acest cont”, are aceleași rezultate de căutare ca la Pasul 3, dar niciunul nu este bifat. Celălalt câmp, „Alte conturi AWS”, nu are nimic adăugat.
Pasul 4: Omiterea paginii de atribuire a utilizatorului.

Nu vom aloca niciun utilizator acestei chei, deoarece dorim ca această cheie să fie utilizată numai de serviciul CloudWatch Logs pentru operațiunile de criptare și decriptare a jurnalelor SSH.

O captură de ecran a AWS cu aceleași pesmeturi, acum la Pasul 5: „Examinare”. Primul câmp, „Configurația cheii”, listează „Tipul cheii” ca „Simetric”, „Spec. cheii” ca „SYMMETRIC_DEFAULT”, „Utilizarea cheii” ca „Criptare și decriptare” și „Originea” ca „AWS_KMS ." Următorul câmp, „Alias ​​și descriere”, listează un Alias, „cwlg”, fără Descriere. Următorul câmp, „Etichete”, nu afișează date. Ultimul câmp, „Politica cheie”, include o casetă de text precompletată cu o politică în format JSON.
Pasul 5: revizuiți configurația noastră și schimbați politica implicită a cheilor.

Pe pagina de revizuire, va trebui să modificăm politica de cheie generată de KMS, deoarece aceasta nu include permisiunile pentru ca CloudWatch Logs să utilizeze cheia. Îl vom înlocui cu această politică:

 { "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:*" } } } ] }

Asigurați-vă că înlocuiți toți substituenții:

  • ACCOUNT_ID devine ID-ul contului nostru AWS.
  • USERNAME devine numele de utilizator de administrator selectat la Pasul 3. Dacă am renunțat la acel pas, aici eliminăm al doilea bloc de instrucțiuni (cel cu "Sid": "Allow access for Key Administrators" ).
  • REGION devine codul de identificare regional pentru care implementăm serviciile (de exemplu, us-west-1 ).

Cu asta, KMS este gata de plecare.

Grupul de jurnal CloudWatch

În continuare avem nevoie de un grup de jurnal CloudWatch (și/sau de un bucket S3 - vezi mai jos) unde Agentul SSM poate trimite jurnalele de sesiune SSH. Să-l creăm.

O captură de ecran a AWS cu breadcrumb „CloudWatch”, „CloudWatch Logs”, „Log groups” și „Create log group”. Nu există bară laterală cu mai mulți pași. Primul câmp, „Detaliile grupului de jurnal”, are trei sub-câmpuri: „Numele grupului de jurnal” (setat la „ssm-session-demo”), „Setare de păstrare” (setat la „Nu expiră niciodată” dintr-un meniu vertical) și „ARN cheie KMS - opțional” (setat la o valoare trunchiată care începe cu „arn:aws:kms”). Al doilea câmp, „Etichete”, nu are etichete.
Crearea unui grup de jurnal „CloudWatch Logs”.

Rețineți câmpul ARN al cheii KMS: AWS ne oferă aici valoarea necesară după ce cheia este creată la Pasul 5 al secțiunii KMS.

(Dacă nu am asociat politica corectă cu cheia KMS mai devreme, permițând serviciului CloudWatch Logs să utilizeze cheia, vom primi o eroare legată de cheia KMS în acest moment.)

Stocarea jurnalelor SSH într-o găleată S3

Pentru stocarea jurnalelor de activitate cu S3 în loc de – sau în plus față de – jurnalele CloudWatch, trebuie să adăugăm aceste permisiuni la profilul nostru de instanță EC2 ca o politică separată (sau să le combinăm manual cu alte permisiuni de care avem nevoie asociate):

 { "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": "*" } ] }

În fragmentul de mai sus, asigurați-vă că înlocuiți substituentul BUCKET_NAME .

Acum că ne-am configurat undeva pentru a stoca jurnalele – jurnalele CloudWatch, o găleată S3 sau ambele – suntem gata să accesăm sesiunile SSH.

Manager de sesiune AWS Systems Manager

Acesta este ultimul pas cheie, în care configurăm accesul securizat la mașina noastră Linux pentru monitorizarea și înregistrarea sesiunilor SSH. Vom începe cu tabloul de bord Session Manager.

O captură de ecran a tabloului de bord AWS Session Manager cu secțiuni, „Cum funcționează”, „De ce să utilizați Managerul de sesiune?” „Noțiuni introductive”, „Mai multe resurse” și în colțul din dreapta sus, „Începeți o sesiune”. Ultima secțiune are un buton portocaliu „Start Session” și un buton alb „Configurare preferințe”.
Pasul 1: Începeți cu tabloul de bord.

Pe tabloul de bord, faceți clic pe butonul alb „Configurați preferințe” din caseta din dreapta sus „Începeți o sesiune” pentru a activa înregistrarea sesiunii.

Pe pagina Preferințe, vom găsi mai multe secțiuni pe care le-am putea explora, dar accentul nostru se va concentra pe transmiterea jurnalelor de sesiuni SSH către CloudWatch sau S3 pentru a ne permite să vedem rapid ce se întâmplă în mașina noastră Linux.

O captură de ecran a unei secțiuni AWS intitulată „Logging CloudWatch”. Prima sa setare, numită și „Logging CloudWatch”, are o casetă de selectare etichetată Activare care este bifată. Următoarea setare, „Alegeți opțiunea de înregistrare preferată”, are selectat „Jurnalele de sesiune în flux (recomandat)” în loc de „Încărcați jurnalele de sesiune”. Următoarea setare, „Aplicați criptarea”, are o casetă de selectare etichetată „Permiteți numai grupurile de jurnal CloudWatch criptate” care este bifată. Setarea finală, „Grup de jurnal CloudWatch”, are selectat „Alegeți un nume de grup de jurnal din listă” în loc de „Introduceți un grup de jurnal în caseta de text”. Sub ea este o listă, „Grupuri de jurnal CloudWatch”, cu „ssm-session-demo” selectat. Are coloanele corespunzătoare „Criptare” (setate la „Criptat”), „Evenimentele expirate după” (setate la „Nu expiră niciodată”), „Filtre metrice” (setate la 0), „Octeți stocați” (setate la 0) și un marcaj temporal „Timp de creare”.
Pasul 2a: Activarea înregistrării CloudWatch.

Imediat după secțiunea „Logging CloudWatch”, există o secțiune „Logging S3” unde putem selecta găleata.

O captură de ecran a unei secțiuni AWS intitulată „S3 logging”. Prima sa setare, „Trimite jurnalele de sesiune la S3”, are o casetă de selectare etichetată „Activare” care este bifată. Următoarea sa setare, „Aplicați criptarea”, are o casetă de selectare etichetată „Permiteți numai găleți S3 criptate” care este bifată. Următoarea sa setare, „Alegeți un compartiment S3”, are selectat „Alegeți un nume de compartiment din listă” în loc de „Introduceți un nume de compartiment în caseta de text”. Sub aceasta, „ssm-session-demo” este selectat dintr-o listă derulantă. Ultimul câmp, „Prefixul cheii S3 - opțional”, este necompletat.
Pasul 2b: Activarea înregistrării S3.

Odată ce înregistrarea SSH este configurată, putem SSH în mașina noastră Linux și executa câteva comenzi pentru a vedea dacă activitatea este capturată sau nu.

Deci, să începem o sesiune. Pe aceeași pagină, vom găsi o filă „Sesiuni” de unde putem începe o sesiune. Făcând clic pe butonul „Start session” ne va oferi o listă de mașini EC2 pe care putem iniția o sesiune:

O captură de ecran a AWS cu breadcrumbs AWS Systems Manager, Session Manager și Start a session. O casetă de căutare „Instanțe țintă” nu are nicio interogare completată și un singur rezultat, cu „Nume instanță” setat la „Demo SSM”.
Pasul 3: Selectarea instanței noastre EC2 pentru a începe o sesiune SSH.

Dacă nu vedem instanța noastră EC2 Linux în listă, ar trebui să verificăm dacă se află într-o stare de rulare și are permisiunile IAM asociate cu ea pe care le-am descris mai devreme.

Gestionarea unui agent SSM Eroare „Nu acceptă jurnalele de streaming”.

În cazul în care primim o eroare care spune că versiunea SSM Agent instalată pe mașina noastră EC2 nu acceptă fluxul de jurnalele CloudWatch, nu vă faceți griji. Există o modalitate nedureroasă de a remedia asta.

O captură de ecran a unui mesaj de eroare AWS cu text alb pe fundal roșu. Un X încercuit este lângă mesajul „Versiunea SSM Agent instalată pe această instanță nu acceptă jurnalele de streaming către CloudWatch. Fie actualizați agentul SSM la cea mai recentă versiune, fie dezactivați opțiunea jurnalelor de streaming din preferințele dvs.”.
O potențială eroare „versiunea de agent SSM învechită”.

Pentru a actualiza agentul SSM, trebuie să navigăm la Run Command în panoul din stânga al serviciului AWS Systems Manager .

O captură de ecran a tabloului de bord AWS Systems Manager Run Command cu secțiuni, „Cum funcționează”, „Caracteristici și beneficii”, „Cazuri de utilizare și articole de blog”, „Documentație” și în colțul din dreapta sus, „Gestionați-vă instanțele”. Secțiunea respectivă conține doar un buton portocaliu „Run a Command”.
Pasul 1: Începând cu tabloul de bord „Run Command”.

Odată ajuns acolo, putem face clic pe butonul portocaliu „Run a Command”, ceea ce duce la o nouă pagină în care putem completa câțiva parametri.

O captură de ecran a AWS cu breadcrumbs AWS Systems Manager, Run Command și Run a command. O casetă de căutare etichetată „Document de comandă” listează 10 rânduri (pagina 4 din mai mult de 5), cu unul numit „AWS-UpdateSSMAgent” selectat. Are „Amazon” în coloana „Owner” și „Windows, Linux” în coloana „Platform types”. Un câmp din partea de jos, „Versiune document”, are „1 (implicit)” selectat dintr-o listă derulantă.
Pasul 2: Selectarea unui document de comandă.

Vom începe prin a selecta AWS-UpdateSSMAgent din listă.

O captură de ecran a unei secțiuni AWS intitulată „Ținte”. Primul câmp, numit și „Ținte”, are opțiunile „Specificați etichete de instanță”, „Alegeți manual instanțele” (selectat) și „Alegeți un grup de resurse”. În partea de jos este o casetă de căutare „Instanțe” fără interogare, cu singurul rezultat, „SSM Demo”, bifat. ID-ul de instanță corespunzător din rând este copiat într-o casetă chiar deasupra „Instanțe” cu un X.
Pasul 3: Selectarea instanței EC2 care are un agent SSM care are nevoie de o actualizare.

Odată ce este selectat, vom derula în jos până când vedem secțiunea „Ținte”. Acolo trebuie să selectăm instanța EC2 pe care dorim să actualizăm agentul SSM, apoi apăsăm butonul „Run” de la sfârșit. Acest lucru ne va trimite la o pagină unde putem monitoriza progresul actualizării.

O captură de ecran a AWS cu breadcrumb „AWS Systems Manager”, „Run Command” și „Command ID” (urmat de un GUID). Prima secțiune, „Starea comenzii”, arată indicatorii de succes, la fel ca și singurul rând al secțiunii următoare, „Ținte și rezultate”, care listează instanța unică de mai devreme. Există, de asemenea, două secțiuni neextinse în partea de jos, „Descrierea comenzii” și „Parametrii comenzii”.
Pasul 4: Monitorizarea progresului actualizării noastre.

Actualizarea agentului nu ar trebui să dureze mai mult de cinci minute. Odată ce s-a terminat, ar trebui să putem crea o sesiune înapoi în Managerul de sesiuni.

În acest moment, ar trebui să începem o sesiune SSH.

O captură de ecran a AWS cu un ID de sesiune și un ID de instanță deasupra unui terminal. Promptul este „sh-4.2$” și au fost introduse comenzile „whoami” și „pwd”, cu ieșirile „ssm-user” și respectiv „/usr/bin”.
O sesiune SSH folosind agentul SSM prin AWS Systems Manager Session Manager.

După ce executăm câteva comenzi, să navigăm la grupul de jurnal CloudWatch Logs (sau găleata noastră S3, care nu este afișată) și să confirmăm că activitatea este înregistrată.

O captură de ecran a AWS cu breadcrumbs „CloudWatch”, „CloudWatch Logs”, „Log groups”, „ssm-session-demo” și ID-ul sesiunii de la pasul anterior. Singura secțiune este o casetă de căutare, „Înregistrați evenimente”, cu rânduri care au fiecare un marcaj de timp și un mesaj în format JSON. Unul dintre ele este extins pentru a-și dezvălui JSON destul de imprimat și cu un buton alb în dreapta etichetat „Copiare”.
Evenimentele din jurnalul SSH sunt înregistrate în CloudWatch Logs.

Acum avem o configurare, cu criptarea în repaus activată, înregistrând fiecare comandă lansată în mașina noastră Linux.

De fapt, fiecare comandă poate fi mai mult decât ne dorim: orice secrete furnizate sau generate în timpul sesiunii vor fi înregistrate în CloudWatch sau S3 și pot fi văzute de oricine are permisiunile necesare. Pentru a preveni acest lucru, putem folosi stty -echo; read passwd; stty echo; stty -echo; read passwd; stty echo; pentru fiecare secret pe care trebuie să-l furnizăm în timpul sesiunii.

O soluție excelentă de înregistrare SSM/SSH AWS, cu avertismente minore

Session Manager este un instrument util pentru a obține acces de la distanță la mașinile noastre virtuale din AWS fără a fi nevoie să deschidem portul 22. De fapt, nu putem genera jurnalele SSH în acest fel dacă folosim redirecționarea portului sau o conexiune SSH directă, ca Manager de sesiune. note de documentare.

Cu toate acestea, combinarea Session Manager cu înregistrarea sesiunii este o soluție robustă pentru controlul și monitorizarea activității în cadrul VM-urilor. În plus, nu suntem taxați pentru utilizarea serviciului Session Manager. Plătim doar pentru instanța noastră EC2 și pentru jurnalele CloudWatch sau pentru o găleată S3 pentru stocarea jurnalelor.

Pentru cititorii care preferă tutoriale video, am tratat puțin mai detaliat o procedură similară pe YouTube.

Citiți suplimentare pe blogul Toptal Engineering:

  • Studiu de caz: De ce folosesc AWS Cloud Infrastructure pentru produsele mele