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 erstellen AWS Marketplace, finden Sie im AWS Marketplace Verkäuferleitfaden unter Bewährte Methoden zum Erstellen von AMIs Richtlinien, Richtlinien und Best Practices.

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

• Sicheres Teilen und Verwenden öffentlicher AMIs

• Public AMI Publishing: Hardening and Clean-up Requirements

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 von passwortbasierten Fernanmeldungen für den Stammbenutzer

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 von passwortbasierten Fernanmeldungen für den Stammbenutzer

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-Host-Schlüsselpaare in /etc/ssh. Dadurch wird SSH gezwungen, neue eindeutige SSH-Schlüsselpaare zu generieren, wenn jemand eine Instance mit Ihrem AMI startet, wodurch die Sicherheit verbessert und die Wahrscheinlichkeit von "man-in-the-middle" -Angriffen verringert wird.

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" 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 kann auf jeden Benutzer angewendet werden. Sie müssen es nicht auf den root-Benutzer beschränken.

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 Sie 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.

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 Images vor allem alle öffentlichen/privaten SSH-Schlüsselpaare von Benutzern und SSH-authorized_keys-Dateien aus. Die öffentlichen Amazon-AMIs speichern diese für den Stamm-Benutzer in /root/.ssh und für normale Benutzer in /home/user_name/.ssh/. Weitere Informationen finden Sie unter ec2-bundle-vol.

• Löschen Sie vor dem Bündeln immer den Shell-Verlauf. Wenn Sie versuchen, mehr als einen Bundle-Upload im selben AMI durchzuführen, enthält der Shell-Verlauf Ihren Zugriffsschlüssel. 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).