Richtlinien für gemeinsame Linux-AMIs - Amazon Elastic Compute Cloud

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Richtlinien für gemeinsame Linux-AMIs

Befolgen Sie folgende Richtlinien, um die Angriffsfläche zu verkleinern und die Zuverlässigkeit der erstellen AMIs zu erhöhen.

Wichtig

Die Liste der Sicherheitsrichtlinien kann sehr umfassend sein. Seien Sie beim Erstellen gemeinsamer AMIs vorsichtig und überlegen Sie sorgfältig, an welcher Stelle empfindliche Daten offengelegt werden könnten.

Wenn Sie AMIs für AWS Marketplace erstellen möchten, finden Sie unter Erstellen von AMIs für AWS Marketplace Anleitungen, Richtlinien und bewährte Methoden.

Zusätzliche Informationen zum sicheren Teilen von AMIs finden Sie in den folgenden Artikeln:

Aktualisieren der AMI-Tools vor der Verwendung

Für Instance Store-Backed AMIs empfehlen wir, die Amazon EC2 AMI-Erstellungstools während des Startups herunterzuladen und ein Upgrade durchzuführen, bevor Sie sie verwenden. Hierdurch wird sichergestellt das neue AMIs, die auf gemeinsamen AMIs basieren, die aktuellsten AMI-Tools aufweisen.

Für Amazon Linux 2 installieren Sie das aws-amitools-ec2-Paket und fügen die AMI-Tools Ihrem Pfad mit dem folgenden Befehl hinzu. Für das Amazon Linux AMI ist das aws-amitools-ec2-Paket standardmäßig installiert.

[ec2-user ~]$ sudo yum install -y aws-amitools-ec2 && export PATH=$PATH:/opt/aws/bin > /etc/profile.d/aws-amitools-ec2.sh && . /etc/profile.d/aws-amitools-ec2.sh

Aktualisieren Sie die AMI-Tools mit dem folgenden Befehl:

[ec2-user ~]$ sudo yum upgrade -y aws-amitools-ec2

Stellen Sie für andere Verteilungen sicher, dass die aktuellen AMI-Tools installiert sind.

Deaktivieren passwortbasierter Remoteanmeldungen für Root-Benutzer

Die Verwendung fester Root-Passwörter für öffentliche AMIs ist ein Sicherheitsrisiko, das schnell bekannt werden kann. Wenn die Benutzer bei der ersten Anmeldung zum Ändern des Passworts aufgefordert werden, bietet sich hierbei eine potenzielle Möglichkeit des Missbrauchs.

Um das Problem zu beheben, deaktivieren Sie die Passwort-basierte Remoteanmeldung für den Root-Benutzer.

Deaktivieren Passwort-basierter Remoteanmeldung für Root-Benutzer

  1. Öffnen Sie die Datei /etc/ssh/sshd_config in einem Textbearbeitungsprogramm und suchen Sie nach folgender Zeile:

    #PermitRootLogin yes
  2. Ändern Sie die Zeile folgendermaßen:

    PermitRootLogin without-password

    Der Speicherort dieser Konfigurationsdatei weicht von Ihrer Verteilung ggf. ab. Das ist auch der Fall, wenn Sie nicht OpenSSH verwenden. Ist dies der Fall, schlagen Sie in der entsprechenden Dokumentation nach.

Deaktivieren des lokalen Root-Zugriffs

Wenn Sie gemeinsame AMIs verwenden, hat sich das Deaktivieren direkter Root-Anmeldung als bewährte Methode etabliert. Melden Sie sich hierfür in der ausgeführten Instance an und geben Sie den folgenden Befehl aus:

[ec2-user ~]$ sudo passwd -l root
Anmerkung

Der Befehl beeinträchtigt nicht die Verwendung von sudo.

Entfernen von SSH-Host-Schlüsselpaaren

Wenn Sie ein von einem öffentlichen AMI abgeleitetes AMI teilen möchten, entfernen Sie die bestehenden SSH-Schlüsselpaare in /etc/ssh. Hierdurch erstellt die SSH-Funktion neue eindeutige SSH-Schlüsselpaare, wenn eine Instance mit dem AMI gestartet wird. Dies verbessert die Sicherheit und verringert die Wahrscheinlichkeit von „Man-In-the-Middle (MITM)“-Angriffen.

Entfernen Sie die folgenden Schlüsseldateien aus Ihrem System.

  • ssh_host_dsa_key

  • ssh_host_dsa_key.pub

  • ssh_host_key

  • ssh_host_key.pub

  • ssh_host_rsa_key

  • ssh_host_rsa_key.pub

  • ssh_host_ecdsa_key

  • ssh_host_ecdsa_key.pub

  • ssh_host_ed25519_key

  • ssh_host_ed25519_key.pub

Sie können all diese Dateien mit folgendem Befehl sicher entfernen.

[ec2-user ~]$ sudo shred -u /etc/ssh/*_key /etc/ssh/*_key.pub
Warnung

Dienstprogramme zum sicheren Entfernen wie shred entfernen möglicherweise nicht alle Kopien einer Datei vom Speichermedium. Journaling-Dateisysteme (u. a. Amazon Linux default ext4), Snapshots, Sicherungen, RAID und temporäres Caching erstellen möglicherweise versteckte Kopien von Dateien. Weitere Informationen finden Sie in der shred -Dokumentation.

Wichtig

Wenn Sie die bestehenden SSH-Host-Schlüsselpaare nicht aus dem öffentlichen AMI entfernen, benachrichtigt unser routinemäßiger Prüfprozess Sie und alle Kunden, die Instances des AMI ausführen, über potenzielle Sicherheitsrisiken. Nach einer kurzen Übergangsfrist wird das AMI als privat markiert.

Installieren von Anmeldeinformationen für öffentliche Schlüssel

Wenn Sie das AMI so konfigurieren, dass keine Passwortanmeldung möglich ist, müssen Sie eine anderen Anmeldemethode für die Benutzer bereitstellen.

Amazon EC2 ermöglicht den Benutzern die Angabe eines öffentlich-privaten Schlüsselpaar-Namens beim Starten einer Instance. Wenn dem RunInstances-API-Aufruf (oder mittels Befehlszeilen-API-Tools) ein gültiger Schlüsselpaarname bereitgestellt wird, wird der öffentliche Schlüssel (der Teil des Schlüsselpaars, den Amazon EC2 nach einem CreateKeyPair- oder ImportKeyPair-Aufruf auf dem Server speichert) der Instance mittels HTTP-Abfrage gegen die Instance-Metadaten verfügbar gemacht.

Wenn Sie sich via SSH anmelden möchten, muss das AMI den Schlüsselwert beim Starten abrufen und /root/.ssh/authorized_keys (oder der entsprechenden Datei für das entsprechende Benutzerkonto im AMI) anhängen. Benutzer können Instances des AMI mit einem Schlüsselpaar starten und sich ohne Root-Passwort anmelden.

Viele Verteilungen, u. a. Amazon Linux und Ubuntu, verwenden das cloud-init-Paket zum Einfügen von Anmeldeinformationen für öffentliche Schlüssel für einen konfigurierten Benutzer. Wenn die Verteilung cloud-init nicht unterstützt, fügen Sie dem System-Startup-Skript (z. B. /etc/rc.local) den folgenden Code hinzu, um den öffentlichen Schlüssel abzurufen, den Sie beim Start für den Root-Benutzer angegeben haben.

Anmerkung

Im folgenden Beispiel ist die IP-Adresse http://169.254.169.254/ eine lokale (link-local) Adresse und nur von der Instance aus gültig.

IMDSv2
if [ ! -d /root/.ssh ] ; then mkdir -p /root/.ssh chmod 700 /root/.ssh fi # Fetch public key using HTTP TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \ && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/my-key if [ $? -eq 0 ] ; then cat /tmp/my-key >> /root/.ssh/authorized_keys chmod 700 /root/.ssh/authorized_keys rm /tmp/my-key fi
IMDSv1
if [ ! -d /root/.ssh ] ; then mkdir -p /root/.ssh chmod 700 /root/.ssh fi # Fetch public key using HTTP curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/my-key if [ $? -eq 0 ] ; then cat /tmp/my-key >> /root/.ssh/authorized_keys chmod 700 /root/.ssh/authorized_keys rm /tmp/my-key fi

Dies funktioniert für jedes Benutzerkonto, nicht nur für root.

Anmerkung

Beim erneuten Bündeln einer Instance basierend auf dem AMI wird der Schlüssel eingebunden, mit dem es gestartet wurde. Damit der Schlüssel nicht eingebunden wird, löschen (oder entfernen) Sie die authorized_keys-Datei oder schließen Sie diese Datei vom erneuten Bündeln aus.

Deaktivieren von sshd-DNS-Prüfungen (optional)

Durch das Deaktivieren von sshd-DNS-Prüfungen wird die sshd-Sicherheit beeinträchtigt. Wenn bei der DNS-Auflösung allerdings ein Fehler auftritt, funktioniert die SSH-Anmeldung weiterhin. Wenn Sie die sshd-Prüfungen nicht deaktivieren, wird die Anmeldung durch Fehler bei der DNS-Auflösung verhindert.

Deaktivieren von sshd-DNS-Prüfungen

  1. Öffnen Sie die Datei /etc/ssh/sshd_config in einem Textbearbeitungsprogramm und suchen Sie nach folgender Zeile:

    #UseDNS yes
  2. Ändern Sie die Zeile folgendermaßen:

    UseDNS no
Anmerkung

Der Speicherort dieser Konfigurationsdatei kann von Ihrer Verteilung abweichen. Das ist auch der Fall, wenn Sie nicht OpenSSH verwenden. Ist dies der Fall, schlagen Sie in der entsprechenden Dokumentation nach.

Identifizierung der eigenen Person

Derzeit besteht keine einfache Möglichkeit, die Person zu erkennen, die ein gemeinsames AMI bereitgestellt hat, da AMIs lediglich anhand ihrer Konto-ID identifiziert werden können.

Wir empfehlen, dass Sie eine Beschreibung des AMI und die AMI ID im Amazon EC2 forum veröffentlichen. Das Forum ist eine praktische zentrale Anlaufstelle für Benutzer, die neue gemeinsame AMIs testen möchten.

Eigenschutz

Wir empfehlen, keine empfindlichen Daten oder empfindliche Software auf AMIs zu speichern, die Sie teilen. Benutzer, die ein gemeinsames AMI starten, könnten es erneut bündeln und als ihr eigenes registrieren. Gehen Sie folgendermaßen vor, um keine Sicherheitsrisiken zu übersehen:

  • Wir empfehlen, die --exclude directory-Option für ec2-bundle-vol zu verwenden, um die Verzeichnisse und Unterverzeichnisse zu überspringen, die geheime Informationen enthalten. Schließen Sie beim Bündeln des Abbilds vor allem alle öffentlichen/privaten SSH-Schlüsselpaare von Benutzern und SSH-authorized_keys-Dateien aus. Die öffentlichen AMIs von Amazon speichern diese in der /root/.ssh-Datei für das Root-Konto und /home/user_name/.ssh/ für normale Benutzerkonten. Weitere Informationen finden Sie unter ec2-bundle-vol.

  • Löschen Sie vor dem Bündeln immer den Shell-Verlauf. Wenn Sie mehrere Pakete im selben AMI hochladen, wird Ihr geheimer Zugriffsschlüssel im Shell-Verlauf gespeichert. Das folgende Beispiel muss der letzte ausgeführte Befehl vor dem Bündeln in einer Instance sein.

    [ec2-user ~]$ shred -u ~/.*history
    Warnung

    Die in der Warnung oben beschriebenen Einschränkungen von shred gelten auch hier.

    Hinweis: Bash schreibt den Verlauf der aktuellen Sitzung beim Beenden auf den Datenträger. Wenn Sie sich nach dem Löschen von ~/.bash_history von der Instance ab- und anschließend wieder anmelden, werden Sie feststellen, dass die ~/.bash_history-Datei neu erstellt wurde und alle Befehle enthält, die während der vorherigen Sitzung ausgeführt wurden.

    Neben Bash schreiben auch andere Programme Verlaufsdaten auf den Datenträger. Seien Sie vorsichtig und entfernen Sie unnötige DOT-Dateien und -Verzeichnisse.

  • Zum Bündeln einer ausgeführten Instance sind Ihr privater Schlüssel und das X.509-Zertifikat erforderlich. Legen Sie diese Daten und anderen Anmeldeinformationen an einem Speicherort ab, der nicht gebündelt wird (z. B. den Instance-Speicher).