Link Local-Addressen bei AWS

Im sogenannten APIPA/Link Local-Bereich (siehe RFC 3927) sind auf AWS EC2-Instanzen mehrere Dienste erreichbar, von denen der Metadata Service mit Abstand der Bekannteste und Wichtigste ist. Allerdings gibt es dort auch andere Services (siehe Post „Default DNS-Server in AWS VPCs“), die in der Dokumentation teils recht versteckt sind:

169.254.169.123              AWS eigener NTP-Server seit 2017
169.254.169.250/251      Microsoft KMS-Server zum Check von Windowslizenzen
169.254.169.253              DNS Endpunkt, falls DNS Support im VPC aktiv ist
169.254.169.254              Metadataservice auf Port 80

Die IPs mit 169er Prefix sind übrigens von Security Groups völlig unabhängig, da sie auf Hypervisorebene direkt verarbeitet werden. Deswegen findet sich auch kein „Metadata-Agent“ auf den Instanzen und die Route für den 169.254er Bereich zeigt auf das normale Netzwerkinterface. Der Zugriff kann aufgrund dieser Implementation nur auf der OS-Ebene eingeschränkt werden – was aber nicht ratsam ist, da damit auch EC2 Rollen nicht mehr funktionieren.

Durch die Verwendung des RFC 3927 Addressbereichs umgeht AWS elegant Routingprobleme, die bei der Nutzung von RFC1918-Addressen in Hybridumgebungen sonst entstehen könnten. Dasselbe Prinzip wird übrigens auch bei den Default-Transfernetzen bei VPN-Verbindungen angewandt, die aus dem 169.254er Bereich ausgewählt werden.

Default DNS-Server in AWS VPCs

AWS reserviert in jedem Subnetz die dritte IP (bei einer 24er Maske also die x.x.x.2) für Ihren DNS-Server. Sobald man mit Network ACLs arbeitet, geht man daher davon aus, dass die DNS-Queries innerhalb des Subnetzes der Instanz stattfinden. Allerdings findet sich versteckt in den Dokumentationen der Hinweis, dass es sich bei „Subnetz+2“ nur um eine Reservierung handelt, der DNS aber eigentlich auf „VPC+2“ liegt – selbst wenn dort überhaupt kein Subnetz konfiguriert ist.

Dieses Problem kann man elegant umgehen, indem der DNS Endpunkt auf dem lokalen Interface genutzt wird. Während die Existenz des Metadata-Services auf der 169.254.169.254 weithin bekannt ist, ist nämlich der DNS auf 169.254.169.253 eher unbekannt.

Bei Security Groups findet sich eine weitere Besonderheit im Zusammenhang mit DNS: Sofern man ausgehende Regeln explizit konfiguriert hat, ist der default DNS-Server implizit auch freigegeben – selbst wenn udp/53 nicht in den erlaubten Regeln vorhanden ist. Ein externer DNS Server, der z.B. im on-Premise Netzwerk steht, braucht allerdings eine explizite Freigabe.

 

Sicherheit bei AWS: CIS Benchmarks

Wer sich mit AWS-Sicherheit beschäftigt, kennt die Differenzierung zwischen „Security of the Cloud“ (Amazonseitig) und „Security in the Cloud“ (Betreiberseite). Auf die Zuständigkeiten beim Accountsetup, Firewalls und Monitoring wird immer wieder hingewiesen – oft fehlt im Praxisbetrieb aber eine ausführliche Richtschnur, welche Punkte für ein gutes Setup sinnvoll und wichtig sind.

Ende Februar ist nun der „CIS Amazon Web Services Foundations“-Benchmark erschienen, der eine strukturierte Übersicht über die grundlegendsten Tätigkeiten beinhaltet und eine Checkliste hierfür direkt mitliefert.

Das CIS (Center for Internet Security) ist eine herstellerunabhängige Organisation, die unter anderem solche Sicherheitsleitlinien und Checklisten herausgibt. Die bereitgestellten Dokumenten decken dabei einen großen Umfang ab, von Webbrowsern über Serverprozesse bis Betriebssystem-Hardening ist fast alles vertreten. Der nun herausgegebene Benchmark ergänzt die schon länger existierenden Benchmarks für Betriebssysteme (u.a. Amazon Linux, Ubuntu, Windows, SLES12) und oft genutzten Daemons (z.B. Apache, SQL Server, Tomcat, MySQL), die sich auch in den meisten AWS-Projekten wiederfinden.

Wem das Durcharbeiten der für Betriebssysteme sehr langen Dokumente zuviel Arbeit ist, der kann mittlerweile auch im Amazon Marketplace vorgehärtete AMIs des CIS erwerben.