29 Beiträge getaggt mit „Sicherheit“

Eines der Kernversprechen der Blockchain-Technologie wie Ethereum ist ein gewisses Maß an Anonymität. Teilnehmer, bekannt als Validatoren, sollen hinter einem Schleier kryptografischer Pseudonyme agieren, um ihre reale Identität und damit ihre Sicherheit zu schützen.

Eine aktuelle Forschungsarbeit mit dem Titel „Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue“ von Forschern der ETH Zürich und anderer Institutionen enthüllt jedoch einen kritischen Fehler in dieser Annahme. Sie demonstrieren eine einfache, kostengünstige Methode, um den öffentlichen Bezeichner eines Validators direkt mit der IP-Adresse der Maschine zu verknüpfen, auf der er läuft.

Kurz gesagt, Ethereum-Validatoren sind bei weitem nicht so anonym, wie viele glauben. Die Ergebnisse waren so bedeutend, dass die Forscher von der Ethereum Foundation eine Bug Bounty erhielten, was die Schwere des Datenlecks anerkannte.

Wie die Schwachstelle funktioniert: Ein Fehler im Gossip​

Um die Schwachstelle zu verstehen, benötigen wir zunächst ein grundlegendes Bild davon, wie Ethereum-Validatoren kommunizieren. Das Netzwerk besteht aus über einer Million Validatoren, die ständig über den Zustand der Kette „abstimmen“. Diese Abstimmungen werden als Attestierungen bezeichnet und über ein Peer-to-Peer-Netzwerk ($P2P$-Netzwerk) an alle anderen Knoten übertragen.

Bei so vielen Validatoren würde die Übertragung jeder Abstimmung an alle anderen das Netzwerk sofort überlasten. Um dies zu lösen, implementierten die Designer von Ethereum eine clevere Skalierungslösung: Das Netzwerk ist in 64 verschiedene Kommunikationskanäle, bekannt als Subnetze, unterteilt.

• Standardmäßig abonniert jeder Knoten (der Computer, auf dem die Validator-Software läuft) nur zwei dieser 64 Subnetze. Seine Hauptaufgabe ist es, alle Nachrichten, die er auf diesen beiden Kanälen sieht, gewissenhaft weiterzuleiten.
• Wenn ein Validator eine Abstimmung abgeben muss, wird seine Attestierung zufällig einem der 64 Subnetze zur Übertragung zugewiesen.

Hier liegt die Schwachstelle. Stellen Sie sich einen Knoten vor, dessen Aufgabe es ist, den Datenverkehr für die Kanäle 12 und 13 zu verwalten. Den ganzen Tag leitet er treu Nachrichten nur von diesen beiden Kanälen weiter. Doch dann sendet er Ihnen plötzlich eine Nachricht, die zu Kanal 45 gehört.

Das ist ein starker Hinweis. Warum sollte ein Knoten eine Nachricht von einem Kanal verarbeiten, für den er nicht zuständig ist? Die logischste Schlussfolgerung ist, dass der Knoten selbst diese Nachricht generiert hat. Dies impliziert, dass der Validator, der die Attestierung für Kanal 45 erstellt hat, auf genau dieser Maschine läuft.

Die Forscher nutzten genau dieses Prinzip aus. Indem sie eigene Abhörknoten einrichteten, überwachten sie die Subnetze, von denen ihre Peers Attestierungen sendeten. Wenn ein Peer eine Nachricht von einem Subnetz sendete, das er nicht offiziell abonniert hatte, konnten sie mit hoher Sicherheit ableiten, dass der Peer den ursprünglichen Validator hostete.

Die Methode erwies sich als schockierend effektiv. Mit nur vier Knoten über drei Tage lokalisierte das Team erfolgreich die IP-Adressen von über 161.000 Validatoren, was mehr als 15 % des gesamten Ethereum-Netzwerks entspricht.

Warum das wichtig ist: Die Risiken der Enttarnung​

Die Preisgabe der IP-Adresse eines Validators ist keine triviale Angelegenheit. Sie öffnet die Tür für gezielte Angriffe, die einzelne Betreiber und die Gesundheit des Ethereum-Netzwerks insgesamt bedrohen.

1. Gezielte Angriffe und Belohnungsdiebstahl Ethereum kündigt einige Minuten im Voraus an, welcher Validator den nächsten Block vorschlagen soll. Ein Angreifer, der die IP-Adresse dieses Validators kennt, kann einen Denial-of-Service (DDoS)-Angriff starten, ihn mit Datenverkehr überfluten und offline schalten. Wenn der Validator sein Vier-Sekunden-Fenster zum Vorschlagen des Blocks verpasst, geht die Gelegenheit an den nächsten Validator in der Reihe über. Wenn der Angreifer dieser nächste Validator ist, kann er dann die Blockbelohnungen und wertvollen Transaktionsgebühren (MEV) beanspruchen, die dem Opfer zugestanden hätten.

2. Bedrohungen der Netzwerk-Verfügbarkeit und -Sicherheit Ein gut ausgestatteter Angreifer könnte diese „Sniping“-Angriffe wiederholt durchführen, wodurch die gesamte Blockchain verlangsamt oder zum Stillstand gebracht werden könnte (ein Liveness-Angriff oder Verfügbarkeitsangriff). In einem schwerwiegenderen Szenario könnte ein Angreifer diese Informationen nutzen, um ausgeklügelte Netzwerk-Partitionierungsangriffe zu starten, die potenziell dazu führen könnten, dass verschiedene Teile des Netzwerks über die Historie der Kette uneinig sind und somit deren Integrität gefährdet wird (ein Safety-Angriff oder Sicherheitsangriff).

3. Eine zentralisierte Realität enthüllen Die Forschung beleuchtete auch einige unbequeme Wahrheiten über die Dezentralisierung des Netzwerks:

• Extreme Konzentration: Das Team fand Peers, die eine erstaunliche Anzahl von Validatoren hosteten, darunter eine IP-Adresse, die über 19.000 betrieb. Der Ausfall einer einzelnen Maschine könnte einen überproportionalen Einfluss auf das Netzwerk haben.
• Abhängigkeit von Cloud-Diensten: Rund 90 % der lokalisierten Validatoren laufen auf Cloud-Anbietern wie AWS und Hetzner, nicht auf den Computern von Solo-Home-Stakern. Dies stellt einen erheblichen Zentralisierungspunkt dar.
• Versteckte Abhängigkeiten: Viele große Staking-Pools behaupten, ihre Betreiber seien unabhängig. Die Forschung fand jedoch Fälle, in denen Validatoren aus verschiedenen, konkurrierenden Pools auf derselben physischen Maschine liefen, was versteckte systemische Risiken birgt.

Gegenmaßnahmen: Wie können sich Validatoren schützen?​

Glücklicherweise gibt es Möglichkeiten, sich gegen diese Enttarnungstechnik zu verteidigen. Die Forscher schlugen mehrere Gegenmaßnahmen vor:

• Mehr Rauschen erzeugen: Ein Validator kann sich entscheiden, mehr als zwei Subnetze – oder sogar alle 64 – zu abonnieren. Dies erschwert es einem Beobachter erheblich, zwischen weitergeleiteten und selbst generierten Nachrichten zu unterscheiden.
• Mehrere Knoten verwenden: Ein Betreiber kann die Validator-Aufgaben auf verschiedene Maschinen mit unterschiedlichen IPs aufteilen. Zum Beispiel könnte ein Knoten Attestierungen verwalten, während ein separater, privater Knoten nur zum Vorschlagen von Blöcken mit hohem Wert verwendet wird.
• Privates Peering: Validatoren können vertrauenswürdige, private Verbindungen mit anderen Knoten herstellen, um ihre Nachrichten weiterzuleiten und so ihren wahren Ursprung innerhalb einer kleinen, vertrauenswürdigen Gruppe zu verschleiern.
• Anonyme Broadcasting-Protokolle: Fortgeschrittenere Lösungen wie Dandelion, das den Ursprung einer Nachricht verschleiert, indem es sie über einen zufälligen „Stamm“ leitet, bevor sie weit verbreitet wird, könnten implementiert werden.

Fazit​

Diese Forschung veranschaulicht eindringlich den inhärenten Kompromiss zwischen Leistung und Datenschutz in verteilten Systemen. In seinem Bestreben zu skalieren, hat Ethereums $P2P$-Netzwerk ein Design angenommen, das die Anonymität seiner kritischsten Teilnehmer beeinträchtigt.

Indem die Forscher diese Schwachstelle ans Licht brachten, haben sie der Ethereum-Community das Wissen und die Werkzeuge an die Hand gegeben, die zur Behebung erforderlich sind. Ihre Arbeit ist ein entscheidender Schritt zum Aufbau eines robusteren, sichereren und wirklich dezentralen Netzwerks für die Zukunft.

In Startups im Silicon Valley ist Docker Compose eines der bevorzugten Tools für die schnelle Bereitstellung und Verwaltung containerisierter Anwendungen. Bequemlichkeit geht jedoch oft mit Sicherheitsrisiken einher. Als Site Reliability Engineer (SRE) bin ich mir bewusst, dass Sicherheitslücken zu katastrophalen Folgen führen können. Dieser Artikel teilt die besten Sicherheitspraktiken, die ich in meiner tatsächlichen Arbeit bei der Kombination von Docker Compose mit Ubuntu-Systemen zusammengefasst habe, um Ihnen zu helfen, die Vorteile von Docker Compose zu nutzen und gleichzeitig die Systemsicherheit zu gewährleisten.

I. Härtung der Ubuntu-Systemsicherheit​

Vor der Bereitstellung von Containern ist es entscheidend, die Sicherheit des Ubuntu-Hosts selbst zu gewährleisten. Hier sind einige wichtige Schritte:

1. Ubuntu und Docker regelmäßig aktualisieren​

Stellen Sie sicher, dass sowohl das System als auch Docker auf dem neuesten Stand gehalten werden, um bekannte Schwachstellen zu beheben:

sudo apt update && sudo apt upgrade -y
sudo apt install docker-ce docker-compose-plugin

2. Docker-Verwaltungsberechtigungen einschränken​

Kontrollieren Sie die Docker-Verwaltungsberechtigungen streng, um Privilege-Escalation-Angriffe zu verhindern:

sudo usermod -aG docker deployuser
# Verhindert, dass normale Benutzer leicht Docker-Verwaltungsberechtigungen erhalten

3. Ubuntu-Firewall (UFW) konfigurieren​

Beschränken Sie den Netzwerkzugriff angemessen, um unbefugten Zugriff zu verhindern:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

4. Docker- und UFW-Interaktion korrekt konfigurieren​

Standardmäßig umgeht Docker UFW, um iptables zu konfigurieren, daher wird eine manuelle Steuerung empfohlen:

Die Docker-Konfigurationsdatei ändern:

sudo nano /etc/docker/daemon.json

Folgenden Inhalt hinzufügen:

{
  "iptables": false,
  "ip-forward": true,
  "userland-proxy": false
}

Den Docker-Dienst neu starten:

sudo systemctl restart docker

Adressen in Docker Compose explizit binden:

services:
  webapp:
    ports:
      - "127.0.0.1:8080:8080"

II. Docker Compose Sicherheit Best Practices​

Die folgenden Konfigurationen gelten für Docker Compose v2.4 und höher. Beachten Sie die Unterschiede zwischen Nicht-Swarm- und Swarm-Modus.

1. Container-Berechtigungen einschränken​

Container, die standardmäßig als Root laufen, bergen hohe Risiken; wechseln Sie zu Nicht-Root-Benutzern:

services:
  app:
    image: your-app:v1.2.3
    user: "1000:1000"  # Non-root user
    read_only: true    # Read-only filesystem
    volumes:
      - /tmp/app:/tmp  # Mount specific directories if write access is needed
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

Erklärung:

• Ein schreibgeschütztes Dateisystem verhindert Manipulationen innerhalb des Containers.
• Stellen Sie sicher, dass gemountete Volumes auf die notwendigen Verzeichnisse beschränkt sind.

2. Netzwerkisolation und Port-Management​

Interne und externe Netzwerke präzise aufteilen, um die Offenlegung sensibler Dienste gegenüber der Öffentlichkeit zu vermeiden:

networks:
  frontend:
    internal: false
  backend:
    internal: true

services:
  nginx:
    networks: [frontend, backend]
  database:
    networks:
      - backend

• Frontend-Netzwerk: Kann öffentlich zugänglich sein.
• Backend-Netzwerk: Streng eingeschränkt, nur interne Kommunikation.

3. Sicheres Geheimnismanagement​

Sensible Daten sollten niemals direkt in Compose-Dateien abgelegt werden:

Im Einzelmaschinenmodus:

services:
  webapp:
    environment:
      - DB_PASSWORD_FILE=/run/secrets/db_password
    volumes:
      - ./secrets/db_password.txt:/run/secrets/db_password:ro

Im Swarm-Modus:

services:
  webapp:
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    external: true  # Managed through Swarm's built-in management

Hinweis:

• Die nativen Swarm Secrets von Docker können externe Tools wie Vault oder AWS Secrets Manager nicht direkt nutzen.
• Wenn externer Geheimnisspeicher benötigt wird, integrieren Sie den Leseprozess selbst.

4. Ressourcenbegrenzung (An Docker Compose Version anpassen)​

Container-Ressourcenlimits verhindern, dass ein einzelner Container Host-Ressourcen erschöpft.

Docker Compose Einzelmaschinenmodus (v2.4 empfohlen):

version: '2.4'

services:
  api:
    image: your-image:1.4.0
    mem_limit: 512m
    cpus: 0.5

Docker Compose Swarm-Modus (v3 und höher):

services:
  api:
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M

Hinweis: In Nicht-Swarm-Umgebungen haben die Ressourcenlimits im deploy-Abschnitt keine Wirkung, achten Sie unbedingt auf die Compose-Dateiversion.

5. Container-Health-Checks​

Richten Sie Health-Checks ein, um Probleme proaktiv zu erkennen und Service-Ausfallzeiten zu reduzieren:

services:
  webapp:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s

6. Vermeiden Sie die Verwendung des Latest-Tags​

Vermeiden Sie die Unsicherheit, die der latest-Tag in Produktionsumgebungen mit sich bringt, erzwingen Sie spezifische Image-Versionen:

services:
  api:
    image: your-image:1.4.0

7. Angemessenes Log-Management​

Verhindern Sie, dass Container-Logs den Festplattenspeicher erschöpfen:

services:
  web:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

8. Ubuntu AppArmor Konfiguration​

Standardmäßig aktiviert Ubuntu AppArmor, und es wird empfohlen, den Docker-Profilstatus zu überprüfen:

sudo systemctl enable --now apparmor
sudo aa-status

Docker unter Ubuntu aktiviert AppArmor standardmäßig ohne zusätzliche Konfiguration. Es wird im Allgemeinen nicht empfohlen, SELinux unter Ubuntu gleichzeitig zu aktivieren, um Konflikte zu vermeiden.

9. Kontinuierliche Updates und Sicherheitsscans​

• Image-Schwachstellenscans: Es wird empfohlen, Tools wie Trivy, Clair oder Snyk in den CI/CD-Prozess zu integrieren:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image your-image:v1.2.3

• Automatisierter Sicherheitsupdate-Prozess: Images mindestens wöchentlich neu erstellen, um bekannte Schwachstellen zu beheben.

III. Fallstudie: Lehren aus Docker Compose Konfigurationsfehlern​

Im Juli 2019 erlitt Capital One eine schwerwiegende Datenschutzverletzung, die die persönlichen Daten von über 100 Millionen Kunden betraf 12. Obwohl die Hauptursache dieses Angriffs AWS-Konfigurationsfehler waren, waren auch Containersicherheitsprobleme beteiligt, die Ihrer beschriebenen Situation ähneln:

1. Container-Berechtigungsprobleme: Der Angreifer nutzte eine Schwachstelle in einer Web Application Firewall (WAF) aus, die in einem Container lief, aber über übermäßige Berechtigungen verfügte.
2. Unzureichende Netzwerkisolation: Der Angreifer konnte von dem kompromittierten Container aus auf andere AWS-Ressourcen zugreifen, was auf unzureichende Netzwerkisolationsmaßnahmen hinweist.
3. Offenlegung sensibler Daten: Aufgrund von Konfigurationsfehlern konnte der Angreifer auf eine große Menge sensibler Kundendaten zugreifen und diese stehlen.
4. Fehler bei der Sicherheitskonfiguration: Die Grundursache des gesamten Vorfalls war die Anhäufung mehrerer Fehler bei der Sicherheitskonfiguration, einschließlich Problemen bei der Container- und Cloud-Dienstkonfiguration.

Dieser Vorfall führte zu erheblichen finanziellen Verlusten und Reputationsschäden für Capital One. Es wird berichtet, dass das Unternehmen aufgrund dieses Vorfalls mit Geldstrafen von bis zu 150 Millionen US-Dollar sowie einer langfristigen Vertrauenskrise konfrontiert war. Dieser Fall unterstreicht die Bedeutung der Sicherheitskonfiguration in Container- und Cloud-Umgebungen, insbesondere im Berechtigungsmanagement, der Netzwerkisolation und dem Schutz sensibler Daten. Er erinnert uns daran, dass selbst scheinbar geringfügige Konfigurationsfehler von Angreifern ausgenutzt werden können, was zu katastrophalen Folgen führt.

IV. Fazit und Empfehlungen​

Docker Compose in Kombination mit Ubuntu ist eine bequeme Möglichkeit, Container-Anwendungen schnell bereitzustellen, aber Sicherheit muss während des gesamten Prozesses integriert werden:

• Container-Berechtigungen und Netzwerkisolation streng kontrollieren.
• Lecks sensibler Daten vermeiden.
• Regelmäßige Sicherheitsscans und Updates.
• Es wird empfohlen, bei zunehmender Unternehmensgröße auf fortschrittliche Orchestrierungssysteme wie Kubernetes zu migrieren, um eine stärkere Sicherheitsgarantie zu erhalten.

Sicherheit ist eine kontinuierliche Praxis ohne Endpunkt. Ich hoffe, dieser Artikel hilft Ihnen, Ihre Docker Compose + Ubuntu Bereitstellungsumgebung besser zu schützen.