SSH-Protokollierung und Sitzungsverwaltung mit AWS SSM

Veröffentlicht: 2022-03-11

Das Einrichten benutzerdefinierter Tools oder Skripts zum Führen eines SSH-Protokolls unter Linux kann mühsam und fehleranfällig sein.

Ingenieure können rootsh , screen oder ein anderes Dienstprogramm verwenden, um Benutzeraktivitäten zu protokollieren, aber wenn die Benutzerberechtigungen nicht richtig eingestellt sind, kann ein erfahrener Benutzer Überwachungsprotokolle löschen, um ihre Spuren zu verwischen. Eine andere Möglichkeit wäre, die Protokollierung auf Kernel-Ebene einzurichten, aber das dafür erforderliche Fachwissen ist nicht so verbreitet.

Glücklicherweise gibt es eine Möglichkeit, Benutzeraktivitäten zu protokollieren, ohne auch nur einen einzigen Linux-Befehl schreiben zu müssen! Wir benötigen diese Dienste:

  • EC2
  • IAM (Identitäts- und Zugriffsverwaltung)
  • KMS (Schlüsselverwaltungsdienst)
  • CloudWatch Logs (und/oder S3)
  • AWS Systems Manager (früher bekannt als SSM)

Mal sehen, wie man jeden von ihnen einrichtet.

EC2 und IAM

Das Starten einer EC2-Instance ist normalerweise ziemlich einfach, aber es gibt eine wichtige Aufgabe, die während des Starts erledigt werden muss: Wir müssen unserer Instance eine IAM-Rolle zuweisen, da wir sonst nicht in der Lage sein werden, die erwarteten Ergebnisse zu erzielen, die am Ende beschrieben werden Artikel.

Die IAM-Rolle, die wir unserer EC2-Instance zuordnen, muss über die integrierte AmazonSSMManagedInstanceCore -Richtlinie verfügen, plus diese Richtlinie (als Inline angehängt oder vom Kunden verwaltet):

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

Abgesehen von der IAM-Rolle verwenden wir im Allgemeinen diese EC2-Instance-Konfiguration:

  • Das Betriebssystem ist Amazon Linux 2, da es standardmäßig mit installiertem AWS Systems Manager Agent (SSM Agent) geliefert wird. (Das gilt auch für Ubuntu-Distributionen, die ebenfalls eine Option sind.)
  • Der Instanztyp ist t3.micro (aber jeder Typ ist geeignet).
  • Die standardmäßige Sicherheitsgruppe , die AWS der VPC zuweist, funktioniert, da wir für diese Übung keinen offenen SSH-Port benötigen.

Wir können mit der Einrichtung von KMS beginnen, ohne auf das Hochfahren der EC2-Instanz zu warten.

KMS

Wir benötigen einen KMS-Schlüssel, wenn alle an CloudWatch übermittelten Sitzungsprotokolle verschlüsselt gespeichert werden sollen. Gehen wir zum KMS-Dienst und erstellen einen Schlüssel.

Ein Screenshot von AWS mit den Breadcrumbs „KMS“, „Vom Kunden verwaltete Schlüssel“ und „Schlüssel erstellen“, derzeit bei Schritt 1: „Schlüssel konfigurieren“. Der „Schlüsseltyp“ kann auf „Symmetrisch“ (ausgewählt) oder „Asymmetrisch“ eingestellt werden. Unter „Erweiterte Optionen“ kann die Einstellung „Herkunft des Schlüsselmaterials“ „KMS“ (ausgewählt), „Extern“ oder „Benutzerdefinierter Schlüsselspeicher (CloudHSM)“ sein.
Schritt 1: Auswahl eines symmetrischen Schlüsseltyps.

Ein Screenshot von AWS mit den gleichen Breadcrumbs, jetzt bei Schritt 2: „Labels hinzufügen“. Ein Alias-Feld wird auf „cwlg“ gesetzt, ein optionales Beschreibungsfeld wird leer gelassen und einem optionalen Tags-Feld werden keine Tags hinzugefügt.
Schritt 2: Benennen unseres Schlüssels.

Ein Screenshot von AWS mit den gleichen Breadcrumbs, jetzt bei Schritt 3: „Definiere wichtige administrative Berechtigungen“. Das erste Feld „Schlüsselverwalter“ hat ein leeres Suchfeld mit 10 Ergebniszeilen (Seite 1 von 3) mit den Spalten „Name“, „Pfad“ und „Typ“. Nur in der ersten Zeile (mit den jeweiligen Spaltenwerten „admin“, „/“ und „Benutzer“) ist das entsprechende Kontrollkästchen aktiviert. Das andere Feld, „Schlüssel löschen“, hat eine einzige Option, „Schlüsseladministratoren erlauben, diesen Schlüssel zu löschen“, deren Kontrollkästchen ebenfalls aktiviert ist.
Schritt 3 (optional): Administrator zuweisen.

Wir empfehlen, einen Administrator zuzuweisen, damit der Schlüssel von anderen Benutzern als dem Root-Benutzer des AWS-Kontos verwaltet werden kann, aber wenn andere keinen Zugriff benötigen, können wir Schritt 3 überspringen.

Hier haben wir den IAM-Benutzer „admin“ als Schlüsseladministrator gewählt, aber wir können jeden Benutzer oder jede Rolle frei wählen. Wir können uns auch dafür entscheiden, die Berechtigung zum Löschen von Schlüsseln für den Administrator zu deaktivieren.

Ein Screenshot von AWS mit den gleichen Breadcrumbs, jetzt bei Schritt 4: „Define Key Usage Permissions“. Das erste Feld „Dieses Konto“ hat die gleichen Suchergebnisse wie in Schritt 3, aber keines davon ist aktiviert. Dem anderen Feld „Andere AWS-Konten“ wurde nichts hinzugefügt.
Schritt 4: Überspringen der Benutzerzuweisungsseite.

Wir werden diesem Schlüssel keine Benutzer zuweisen, da wir möchten, dass dieser Schlüssel nur vom CloudWatch Logs-Dienst für Verschlüsselungs- und Entschlüsselungsvorgänge von SSH-Protokollen verwendet wird.

Ein Screenshot von AWS mit den gleichen Breadcrumbs, jetzt bei Schritt 5: „Review“. Das erste Feld „Schlüsselkonfiguration“ listet den „Schlüsseltyp“ als „Symmetrisch“, die „Schlüsselspezifikation“ als „SYMMETRIC_DEFAULT“, die „Schlüsselverwendung“ als „Verschlüsseln und Entschlüsseln“ und den „Ursprung“ als „AWS_KMS ." Das nächste Feld „Alias ​​und Beschreibung“ listet einen Alias ​​„cwlg“ ohne Beschreibung auf. Das nächste Feld „Tags“ zeigt keine Daten. Das letzte Feld „Schlüsselrichtlinie“ enthält ein Textfeld, das mit einer Richtlinie im JSON-Format vorausgefüllt ist.
Schritt 5: Überprüfen Sie unsere Konfiguration und tauschen Sie die Standardschlüsselrichtlinie aus.

Auf der Überprüfungsseite müssen wir die KMS-generierte Schlüsselrichtlinie ändern, da sie keine Berechtigungen für CloudWatch Logs zur Verwendung des Schlüssels enthält. Wir ersetzen sie durch diese Richtlinie:

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

Stellen Sie sicher, dass Sie alle Platzhalter ersetzen:

  • ACCOUNT_ID wird zu unserer AWS-Konto-ID.
  • USERNAME wird zum Administrator-Benutzernamen, der in Schritt 3 ausgewählt wurde. Wenn wir diesen Schritt abgelehnt haben, entfernen wir hier den zweiten Anweisungsblock (den mit "Sid": "Allow access for Key Administrators" ).
  • REGION wird zum regionalen Identifikationscode, für den wir Dienste bereitstellen (z. B. us-west-1 ).

Damit ist KMS startklar.

CloudWatch-Protokollgruppe

Als nächstes benötigen wir eine CloudWatch Log-Gruppe (und/oder einen S3-Bucket – siehe unten), an die der SSM-Agent SSH-Sitzungsprotokolle senden kann. Lassen Sie es uns erstellen.

Ein Screenshot von AWS mit den Breadcrumbs „CloudWatch“, „CloudWatch Logs“, „Loggroups“ und „Create log group“. Es gibt keine mehrstufige Seitenleiste. Das erste Feld, „Details der Protokollgruppe“, hat drei Unterfelder: „Name der Protokollgruppe“ (auf „ssm-session-demo“ eingestellt), „Aufbewahrungseinstellung“ (in einem Dropdown-Menü auf „Läuft nie ab“) und „KMS-Schlüssel ARN – optional“ (auf einen abgeschnittenen Wert festgelegt, der mit „arn:aws:kms“ beginnt). Das zweite Feld „Tags“ enthält keine Tags.
Erstellen einer „CloudWatch Logs“-Protokollgruppe.

Beachten Sie das KMS-Schlüssel-ARN-Feld: AWS stellt uns den hier benötigten Wert bereit, nachdem der Schlüssel in Schritt 5 des KMS-Abschnitts erstellt wurde.

(Wenn wir unserem KMS-Schlüssel nicht früher die richtige Richtlinie zugeordnet haben, sodass der CloudWatch Logs-Dienst den Schlüssel verwenden kann, erhalten wir an dieser Stelle einen Fehler in Bezug auf den KMS-Schlüssel.)

Speichern von SSH-Protokollen in einem S3-Bucket

Um Aktivitätsprotokolle mit S3 anstelle von – oder zusätzlich zu – CloudWatch Logs zu speichern, müssen wir diese Berechtigungen unserem EC2-Instance-Profil als separate Richtlinie hinzufügen (oder sie manuell mit anderen Berechtigungen kombinieren, die wir möglicherweise verknüpfen müssen):

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

Achten Sie im obigen Snippet darauf, den Platzhalter BUCKET_NAME zu ersetzen.

Jetzt, da wir einen Ort zum Speichern der Protokolle eingerichtet haben – CloudWatch Logs, einen S3-Bucket oder beides –, sind wir bereit, SSH-Sitzungen anzuzapfen.

AWS Systems Manager-Sitzungsmanager

Dies ist der letzte wichtige Schritt, in dem wir den sicheren Zugriff auf unseren Linux-Computer für die Überwachung und Protokollierung von SSH-Sitzungen konfigurieren. Wir beginnen mit dem Session Manager-Dashboard.

Ein Screenshot des AWS Session Manager-Dashboards mit den Abschnitten „So funktioniert es“, „Warum Session Manager verwenden?“, „Erste Schritte“, „Weitere Ressourcen“ und in der oberen rechten Ecke „Start a session“. Der letzte Abschnitt hat eine orangefarbene Schaltfläche "Sitzung starten" und eine weiße Schaltfläche "Einstellungen konfigurieren".
Schritt 1: Erste Schritte mit dem Dashboard.

Klicken Sie auf dem Dashboard auf die weiße Schaltfläche „Einstellungen konfigurieren“ im oberen rechten Feld „Sitzung starten“, um die Sitzungsprotokollierung zu aktivieren.

Auf der Seite „Einstellungen“ finden wir mehrere Abschnitte, die wir untersuchen könnten, aber unser Fokus wird auf dem Streamen von SSH-Sitzungsprotokollen zu CloudWatch oder S3 liegen, damit wir schnell sehen können, was auf unserer Linux-Maschine passiert.

Ein Screenshot eines AWS-Abschnitts mit dem Titel „CloudWatch-Protokollierung“. Die erste Einstellung, auch „CloudWatch-Protokollierung“ genannt, hat ein Kontrollkästchen mit der Bezeichnung Aktivieren, das aktiviert ist. Bei der nächsten Einstellung „Wählen Sie Ihre bevorzugte Protokollierungsoption“ ist „Sitzungsprotokolle streamen (empfohlen)“ anstelle von „Sitzungsprotokolle hochladen“ ausgewählt. Bei der nächsten Einstellung „Verschlüsselung erzwingen“ ist ein Kontrollkästchen mit der Bezeichnung „Nur verschlüsselte CloudWatch-Protokollgruppen zulassen“ aktiviert. Bei der letzten Einstellung „CloudWatch-Protokollgruppe“ ist „Einen Protokollgruppennamen aus der Liste auswählen“ anstelle von „Geben Sie eine Protokollgruppe in das Textfeld ein“ ausgewählt. Darunter befindet sich eine Liste „CloudWatch-Protokollgruppen“, in der „ssm-session-demo“ ausgewählt ist. Es hat entsprechende Spalten „Verschlüsselung“ (auf „Verschlüsselt“ gesetzt), „Ereignisse ablaufen nach“ (auf „Läuft nie ab“), „Metrische Filter“ (auf 0 gesetzt), „Gespeicherte Bytes“ (auf 0 gesetzt) ​​und einen „Erstellungszeit“-Zeitstempel.
Schritt 2a: Aktivieren der CloudWatch-Protokollierung.

Direkt nach dem Abschnitt „CloudWatch-Protokollierung“ gibt es einen Abschnitt „S3-Protokollierung“, in dem wir den Bucket auswählen können.

Ein Screenshot eines AWS-Abschnitts mit dem Titel „S3-Protokollierung“. Die erste Einstellung „Sitzungsprotokolle an S3 senden“ hat ein Kontrollkästchen mit der Bezeichnung „Aktivieren“, das aktiviert ist. Die nächste Einstellung, „Verschlüsselung erzwingen“, hat ein Kontrollkästchen mit der Bezeichnung „Nur verschlüsselte S3-Buckets zulassen“, das aktiviert ist. Bei der nächsten Einstellung „S3-Bucket auswählen“ ist „Bucket-Namen aus der Liste auswählen“ anstelle von „Bucket-Namen in das Textfeld eingeben“ ausgewählt. Darunter wird „ssm-session-demo“ aus einer Dropdown-Liste ausgewählt. Das letzte Feld „S3-Schlüsselpräfix – optional“ ist leer.
Schritt 2b: S3-Protokollierung aktivieren.

Sobald die SSH-Protokollierung konfiguriert ist, können wir uns per SSH in unseren Linux-Computer einloggen und einige Befehle ausführen, um zu sehen, ob die Aktivität erfasst wird oder nicht.

Beginnen wir also eine Sitzung. Auf derselben Seite finden wir eine Registerkarte „Sitzungen“, auf der wir eine Sitzung starten können. Durch Klicken auf die Schaltfläche „Sitzung starten“ erhalten wir eine Liste der EC2-Maschinen, auf denen wir eine Sitzung starten können:

Ein Screenshot von AWS mit Breadcrumbs AWS Systems Manager, Session Manager und Sitzung starten. Ein Suchfeld „Zielinstanzen“ enthält keine Abfrage und nur ein Ergebnis, wobei „Instanzname“ auf „SSM-Demo“ festgelegt ist.
Schritt 3: Auswahl unserer EC2-Instance zum Starten einer SSH-Sitzung.

Wenn wir unsere EC2-Linux-Instance nicht in der Liste sehen, sollten wir überprüfen, ob sie ausgeführt wird und die ihr zugeordneten IAM-Berechtigungen hat, die wir zuvor beschrieben haben.

Umgang mit einem SSM-Agent-Fehler „Unterstützt keine Streaming-Protokolle“.

Falls wir eine Fehlermeldung erhalten, dass die auf unserem EC2-Rechner installierte SSM-Agent-Version das Streamen von CloudWatch-Protokollen nicht unterstützt, machen Sie sich keine Sorgen. Es gibt einen schmerzlosen Weg, dies zu beheben.

Ein Screenshot einer AWS-Fehlermeldung mit weißem Text auf rotem Hintergrund. Ein eingekreistes X befindet sich neben der Meldung „Die auf dieser Instanz installierte SSM-Agent-Version unterstützt keine Streaming-Protokolle zu CloudWatch. Aktualisieren Sie entweder den SSM-Agent auf die neueste Version oder deaktivieren Sie die Streaming-Protokolloption in Ihren Einstellungen.“
Ein potenzieller Fehler „veraltete SSM-Agent-Version“.

Um den SSM-Agenten zu aktualisieren, müssen wir im linken Bereich des AWS Systems Manager -Service zu Run Command navigieren.

Ein Screenshot des AWS Systems Manager Run Command-Dashboards mit den Abschnitten „So funktioniert es“, „Funktionen und Vorteile“, „Anwendungsfälle und Blogposts“, „Dokumentation“ und in der oberen rechten Ecke „Verwalten Sie Ihre Instanzen“. Dieser Abschnitt enthält nur eine orangefarbene Schaltfläche "Befehl ausführen".
Schritt 1: Beginnen Sie mit dem „Run Command“-Dashboard.

Sobald wir dort sind, können wir auf die orangefarbene Schaltfläche „Befehl ausführen“ klicken, die zu einer neuen Seite führt, auf der wir einige Parameter eingeben können.

Ein Screenshot von AWS mit Breadcrumbs AWS Systems Manager, Befehl ausführen und Befehl ausführen. Ein Suchfeld mit der Bezeichnung „Befehlsdokument“ listet 10 Zeilen (Seite 4 von mehr als 5) auf, wobei eine mit dem Namen „AWS-UpdateSSMAgent“ ausgewählt ist. Es hat „Amazon“ in der Spalte „Eigentümer“ und „Windows, Linux“ in der Spalte „Plattformtypen“. In einem Feld unten, "Dokumentversion", ist "1 (Standard)" aus einer Dropdown-Liste ausgewählt.
Schritt 2: Auswählen eines Befehlsdokuments.

Wir beginnen mit der Auswahl von AWS-UpdateSSMAgent aus der Liste.

Ein Screenshot eines AWS-Abschnitts mit dem Titel „Ziele“. Das erste Feld, auch „Ziele“ genannt, enthält die Optionen „Instanz-Tags angeben“, „Instanzen manuell auswählen“ (ausgewählt) und „Ressourcengruppe auswählen“. Unten befindet sich ein Suchfeld „Instanzen“ ohne Abfrage, wobei das einzige Ergebnis „SSM-Demo“ aktiviert ist. Die entsprechende Instanz-ID in der Zeile wird mit einem X in ein Feld direkt über "Instanzen" kopiert.
Schritt 3: Auswählen der EC2-Instance, die einen SSM-Agenten hat, der aktualisiert werden muss.

Sobald dies ausgewählt ist, scrollen wir nach unten, bis wir den Abschnitt „Ziele“ sehen. Dort müssen wir die EC2-Instanz auswählen, auf der wir den SSM-Agent aktualisieren möchten, und dann am Ende auf die Schaltfläche „Ausführen“ klicken. Dadurch werden wir zu einer Seite weitergeleitet, auf der wir den Fortschritt des Updates überwachen können.

Ein Screenshot von AWS mit Breadcrumbs „AWS Systems Manager“, „Run Command“ und „Command ID“ (gefolgt von einer GUID). Der erste Abschnitt, „Befehlsstatus“, zeigt Erfolgsindikatoren, ebenso wie die einzige Zeile des nächsten Abschnitts, „Ziele und Ausgaben“, die die einzelne Instanz von früher auflistet. Es gibt auch zwei nicht erweiterte Abschnitte unten, "Befehlsbeschreibung" und "Befehlsparameter".
Schritt 4: Überwachung unseres Aktualisierungsfortschritts.

Das Agenten-Update sollte nicht länger als fünf Minuten dauern. Sobald dies erledigt ist, sollten wir in der Lage sein, eine Sitzung im Sitzungsmanager zu erstellen.

An diesem Punkt sollte eine SSH-Sitzung gestartet werden.

Ein Screenshot von AWS mit einer Sitzungs-ID und einer Instanz-ID über einem Terminal. Die Eingabeaufforderung lautet „sh-4.2$“ und die Befehle „whoami“ und „pwd“ wurden eingegeben, mit den Ausgaben „ssm-user“ bzw. „/usr/bin“.
Eine SSH-Sitzung mit dem SSM-Agent über AWS Systems Manager Session Manager.

Nachdem Sie einige Befehle ausgeführt haben, navigieren wir zur CloudWatch Logs-Protokollgruppe (oder unserem S3-Bucket, nicht gezeigt) und bestätigen, dass die Aktivität aufgezeichnet wird.

Ein Screenshot von AWS mit den Breadcrumbs „CloudWatch“, „CloudWatch Logs“, „Log groups“, „ssm-session-demo“ und der Sitzungs-ID des vorherigen Schritts. Der einzige Abschnitt ist ein Suchfeld „Ereignisse protokollieren“ mit Zeilen, die jeweils einen Zeitstempel und eine Nachricht im JSON-Format enthalten. Einer von ihnen wird erweitert, um sein JSON hübsch gedruckt und mit einer weißen Schaltfläche auf der rechten Seite mit der Aufschrift „Kopieren“ zu zeigen.
SSH-Protokollereignisse, die in CloudWatch Logs aufgezeichnet werden.

Wir haben jetzt ein Setup mit aktivierter Verschlüsselung im Ruhezustand, das jeden auf unserer Linux-Maschine ausgelösten Befehl aufzeichnet.

Tatsächlich kann jeder Befehl mehr sein, als wir wollen: Alle während der Sitzung bereitgestellten oder generierten Geheimnisse werden in CloudWatch oder S3 aufgezeichnet und können von jedem eingesehen werden, der über die erforderlichen Berechtigungen verfügt. Um das zu verhindern, können wir stty -echo; read passwd; stty echo; stty -echo; read passwd; stty echo; für jedes Geheimnis, das wir während der Sitzung bereitstellen müssen.

Eine großartige SSM/SSH-AWS-Protokollierungslösung mit kleinen Einschränkungen

Session Manager ist ein nützliches Tool, um Fernzugriff auf unsere virtuellen Maschinen in AWS zu erhalten, ohne Port 22 öffnen zu müssen. Tatsächlich können wir auf diese Weise keine SSH-Protokolle generieren, wenn wir als Session Manager Portweiterleitung oder eine direkte SSH-Verbindung verwenden Dokumentationsnotizen.

Nichtsdestotrotz ist die Kombination von Session Manager mit Sitzungsprotokollierung eine robuste Lösung zur Steuerung und Überwachung von Aktivitäten innerhalb von VMs. Darüber hinaus wird uns die Nutzung des Session Manager-Dienstes nicht in Rechnung gestellt. Wir zahlen nur für unsere EC2-Instanz und CloudWatch Logs oder einen S3-Bucket zum Speichern von Protokollen.

Für Leser, die Video-Tutorials bevorzugen, habe ich ein sehr ähnliches Verfahren etwas ausführlicher auf YouTube behandelt.

Weiterführende Literatur im Toptal Engineering Blog:

  • Fallstudie: Warum ich AWS Cloud Infrastructure für meine Produkte verwende