Serie „Coders Conquer Security Infrastructure as Code“: Unzureichender Schutz der Transportebene

Wenn Sie als Entwickler mehr darüber erfahren möchten, wie Sie mit der Bereitstellung sicherer Infrastructure as Code (IaC) in Ihrem Unternehmen beginnen können, sind Sie hier genau richtig. Dies ist das nächste Kapitel unserer IaC-Serie, das Ihnen dabei helfen soll, Ihre Kenntnisse über IaC-Sicherheits-Best-Practices zu vertiefen.

Bevor wir beginnen: Wie sind Sie mit der Herausforderung aus dem letzten Teil zurechtgekommen? Wenn Sie das Thema unsichere Kryptografie gemeistert haben, schauen wir uns nun den unzureichenden Schutz der Transportschicht an, bevor wir in die Details eintauchen:

Möchten Sie mehr erfahren und die volle Punktzahl erreichen? Lesen Sie weiter:

In unserem letzten Artikel haben wir über die Bedeutung sicherer Kryptografie zum Schutz wichtiger oder persönlicher Daten gesprochen, die von Anwendungen und Programmen gespeichert werden. Eine starke Verschlüsselung fungiert als letzte Verteidigungslinie. Selbst wenn es einem Angreifer gelingt, diese Daten zu stehlen, bleiben die in den Dateien eingeschlossenen Informationen dank der starken Verschlüsselung geschützt.

Der Schutz ruhender Daten ist jedoch nur ein Teil einer umfassenden Datensicherheitsstrategie. Wann immer berechtigte Benutzer auf geschützte Daten zugreifen müssen, müssen diese an sie übertragen werden. Gelegentlich tauschen Anwendungen im Rahmen eines gesamten Workflows Daten mit anderen Programmen aus. Wenn die Transportschicht nicht geschützt ist, ist sie sowohl für externe Spionage als auch für unbefugte interne Einsichtnahme anfällig. Daher kann ein unzureichender Schutz der Transportschicht schwerwiegende Probleme verursachen.

Dies ist ein häufiges Problem. Die Sicherheitsorganisation OWASP führt sogar eine eigene Seite zum Thema unzureichender Schutz der Transportschicht.

Warum ist ein unzureichender Schutz der Transportschicht gefährlich?

Wenn Sie Ihre Transportschichten nicht ausreichend schützen, ist es für versierte Hacker relativ einfach, Informationen, die zwischen Ihren Benutzern und Ihren Anwendungen fließen, mithilfe von Techniken wie Man-in-the-Middle-Angriffen abzufangen. Der wohl gefährlichste Aspekt dieser Art von Spionage ist, dass sie für interne Cybersicherheitsplattformen oder Scans nahezu unsichtbar bleibt, da sie außerhalb Ihres Netzwerks und Ihrer Kontrolle stattfindet.

Zum Beispiel in einer Docker-Umgebung, in der ein Nginx-Dienst bereitgestellt wird:

services:
 nginx:
   image: localhost:5000/scw_nginx
   build: ./nginx
   secrets:
     - nginx_cert
     - nginx_key
   volumes:
     - type: bind
       source: ./nginx/nginx.conf
       target: /etc/nginx/nginx.conf
       read_only: yes
   ports:
     - 80:8443
   networks:
     - frontend
   deploy:
     restart_policy: *default-restart_policy
     resources: *default-resources_policy

Die Nginx-Dienstkonfiguration verschlüsselt oder schützt die Verbindung nicht, wodurch alle über diesen Link ausgetauschten Informationen anfällig für eine Vielzahl von Angriffen oder Spionage sind.

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

Oft ist das erste Anzeichen dafür, dass jemand Ihre Transportschichten ausspioniert, wenn eine große Anzahl gestohlener Benutzerpasswörter bei nachfolgenden Angriffen verwendet wird. Wenn andere Daten wie Kundeninformationen, Finanzunterlagen oder wichtige Firmengeheimnisse über eine unsichere Transportschicht gestohlen werden, bemerken Sie möglicherweise nie, dass Sie kompromittiert wurden.

Und es ist nicht nur die Transportschicht zwischen Benutzern und Anwendungen, die Schutz erfordert. Im Backend kommunizieren viele Anwendungen miteinander und mit Servern, die weiter hinten in der Workflow-Kette liegen. Obwohl diese interne Kommunikation im Allgemeinen nicht anfällig für externe Spionage ist, können Daten für Benutzer zugänglich werden, die zwar Zugriff auf das Netzwerk haben, aber nicht autorisiert sind, bestimmte hochgradig geschützte oder sensible Informationen einzusehen.

Die Transportschichten für einen umfassenden Datenschutz korrekt absichern

Der Schutz von Transportschichten erfolgt am besten bereits während der Erstellung der Anwendungen. Dieser Prozess beginnt mit einer sicheren Backend-Infrastruktur. Für Websites sollte alles über HTTPS abgewickelt werden. Mischen Sie niemals HTTP- und HTTPS-Infrastrukturen. Sie sollten Ihre Websites sogar so einrichten, dass ungesicherte HTTP-Anfragen automatisch auf die HTTPS-Infrastruktur umgeleitet werden.

Im obigen Beispiel wäre eine korrekte Methode zum Schutz der Transportschicht:

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

In diesem Beispiel sind alle Verbindungen zum Nginx-Dienst stark verschlüsselt. Der Server-Abschnitt der Nginx-Konfiguration enthält lediglich listen 8443 ssl , um SSL zur Absicherung der Verbindungen zu erzwingen.

Um Ihre Daten vor internen Bedrohungen zu schützen, sollten Entwickler ein starkes Transportverschlüsselungsprotokoll wie TLS 1.2 einsetzen. Sobald TLS 1.2 oder ein gleichwertiges Protokoll implementiert ist, sollten schwächere Protokolle wie SSL v2 vollständig aus Ihrer Infrastruktur entfernt und dauerhaft blockiert werden.

Denken Sie immer daran, dass die Absicherung einer Anwendung erst dann vollständig ist, wenn sowohl ruhende Daten als auch die Transportebenen ausreichend geschützt sind. Nur so können Sie einen lückenlosen End-to-End-Schutz für Daten gewährleisten – sowohl intern als auch bei der Übertragung an autorisierte externe Nutzer.
Besuchen Sie die Secure Code Warrior-Blogseiten für weitere Einblicke in diese Schwachstelle und erfahren Sie, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Secure Code Warrior-Schulungsplattform ausprobieren, um Ihre Cybersicherheitskenntnisse stets auf dem neuesten Stand zu halten.