Willkommen zu allesnurgecloud.com – Ausgabe #212
Vermutlich hast du dir noch keine neuen iPhone Socken bestellt – bin mal gespannt, wann es die für das Pixel für 9,99€ gibt oder ob die Oma einfach selber strickt und die unter den Weihnachtsbaum legt – zu iPod Zeiten waren die günstiger.
Dass der japanische Investor SoftBank seinen 5,83 Milliarden Dollar Anteil an Nvidia verkauft hat, hast du bestimmt auch mitbekommen. Nun sollte man die Börse im Auge behalten und StopLoss nicht vergessen 🙂
Etwas turbulent ging es die Woche in der Docker / Traefik Ecke zu. Docker 29.0.0 brach Traefik-Kompatibilität, da die API-Version von 1.24 auf 1.44 angehoben wurde. Traefik 3.6.0 (und ältere Versionen) nutzte noch API 1.24, was zu 404-Fehlern bei allen verwalteten Services führte. Als Workarounds dienten das Downgrade auf Docker 28.5.2 oder das Setzen von DOCKER_MIN_API_VERSION=1.24 via systemd-Override – Traefik 3.6.1 wurde inzwischen als Hotfix veröffentlicht und behebt das Problem dauerhaft (Reddit dazu) – Danke an Alex fürs Einsenden.
Happy Bootstrapping Podcast
In der aktuellen Folge 147 spreche ich Matthias Schnizler vom Stuttgarter Startup silberthal.de – hier bekommst du durchdachte Küchenprodukte, welche mit Hilfe von Kommentaren und Feedback zu anderen Artikeln entstehen – also Bewertungen von Pfannen auf Amazon werden analysiert, dann wird die beste Pfanne gebaut. Hab wieder einiges gelernt, Matthias war zur Aufnahme in Shanghai, da hier einer der Co-Founder sitzt und direkt vor Ort Kontakte pflegt und Sourcing betreibt. – hör gerne mal in Folge 147 rein (Spotify / Apple).
Wenn dir die Podcast Folgen zu lang sind, kannst du gerne auch den Newsletter dazu abonnieren – erscheint jeden Montag (in der Regel).
allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:
Datacenter-Milliarden: Google investiert 5,5 Mrd. € in Deutschland, Anthropic 50 Mrd. $ in USA
Google kündigt eine Investition von 5,5 Milliarden Euro in Deutschland an – verteilt bis 2029. Ein neues Datacenter in Dietzenbach ergänzt den bestehenden Standort in Hanau, der seit 2023 läuft. Die Initiative sichere 9.000 Jobs und durchschnittlich 1 Milliarde Euro jährlich zum BIP beitragen.
Innovativ: Die Abwärme aus Dietzenbach wird an das lokale Fernwärmenetz von Energieversorgung Offenbach (EVO) angeschlossen und soll über 2.000 Haushalte versorgen – Googles erstes Heat-Recovery-Projekt in Deutschland nach einem Pilotprojekt in Finnland. Parallel erweitert Google seine 24/7 Carbon-Free Energy (CFE) Partnership mit Engie bis 2030 und strebt 85% CO2-freie Energie für 2026 an. Die Cloud-Regionen in Deutschland bieten Vertex AI mit Gemini-Modellen und werden von Kunden wie Mercedes-Benz und Koenig & Bauer genutzt.
Neben der Infrastruktur investiert Google in Office-Standorte: Das historische Arnulfpost-Gebäude in München wird für 2.000 Mitarbeiter umgebaut (30.000 qm, Fertigstellung Ende 2026). In Frankfurt bezieht man die 24. Etage des Global Tower, in Berlin entstehen drei zusätzliche Stockwerke mit TechTalk-Raum an der Spree.
Anthropics 50-Milliarden-Wette
In den USA kündigt Anthropic laut Trending Topics eine 50-Milliarden-Dollar-Investition in KI-Rechenzentren an. Gemeinsam mit Fluidstack, das bereits GPU-Cluster für Meta, Midjourney und Mistral betreibt, entstehen maßgeschneiderte Anlagen in Texas und New York – Betriebsstart 2026. Die Initiative schafft 800 permanente Arbeitsplätze plus 2.400 Jobs im Bausektor. Parallel betreibt Amazon einen dedizierten Data-Center-Campus für Anthropic auf 1.200 Acres in Indiana (11 Milliarden Dollar).
Die Finanzierung der 50 Milliarden bleibt unklar, entsprechende Investments wurden nicht kommuniziert. Anthropic bedient mittlerweile über 300.000 Business-Kunden, die Zahl der Großkunden mit über 100.000 Dollar Run-Rate-Revenue hat sich versiebenfacht. Zum Vergleich: OpenAI hat bereits 1,4 Billionen Dollar an langfristigen Infrastruktur-Commitments durch Deals mit Nvidia, Broadcom und Cloud-Providern gesichert.
Anthropic prognostiziert Break-even bis 2028 – deutlich vor OpenAI, das für dasselbe Jahr 74 Milliarden Dollar operative Verluste erwartet.
Die AWS Sovereign Cloud in Brandenburg hatte ich in Newsletter 192 analysiert – dort investiert Amazon 7,8 Milliarden Euro bis 2040. Wobei, souverän – auf LinkedIn war Sönke etwas überrascht, wie solch ein Deal dann strukturiert wird – denn natürlich gehören der Amazon, Inc. aus den USA alle 25.000 Geschäftsanteile der Amazon Germany Holdco 1 GmbH.
Google Announces €5.5 Billion Investment in Germany, including AI Infrastructure, through 2029
Google Cloud: Drei Account-Suspendierungen ohne Grund
Der Gründer des SSL-Zertifikatsdienstes SSLMate, Andrew Ayer, berichtet in einem ausführlichen Blog-Post und The Register greift die Geschichte auf, wie Google Cloud seinen Account dreimal suspendiert hat – jedes Mal mit einer anderen Begründung und ohne vorherige Warnung.
Chronologie der Suspendierungen
Die erste Sperrung erfolgte im Mai 2024, als Ayer versuchte sich einzuloggen und eine Meldung über Richtlinienverstöße erhielt. Die Wiederherstellung war kafkaesk: Google verlangte Informationen, die nur über den gesperrten Account zugänglich waren. Nach teilweiser Wiederherstellung wurde der Account erneut gesperrt – diesmal aus einem anderen Grund.
Zwei Wochen vor Veröffentlichung: Alle Kundenintegrationen fielen aus, diesmal wegen angeblicher Richtlinienverstöße. Die Wiederherstellung erfolgte schnell, da Ayer bereits wusste, welche Informationen Google benötigte.
Letzter Freitag: Dritte Suspendierung, diesmal wegen „Terms of Service Violation“. Nach seinem Appeal kam eine automatische E-Mail, die den kompletten Zugang zu Google Cloud sperrte. Erst nach Medienaufmerksamkeit auf Hacker News wurde der Account wiederhergestellt.
SSLMate nutzt die Google Cloud hauptsächlich für Kundenintegrationen mit Cloud DNS und Cloud Domains. Ayer hatte ein System entwickelt, das Service Accounts pro Kunde erstellt – basierend auf Googles eigener Dokumentation. Das System ist sowohl sicher als auch benutzerfreundlich: keine langlebigen Credentials und keine „confused deputy“ Schwachstellen.
Jetzt muss Ayer zwischen drei Optionen wählen, von denen nur zwei gleichzeitig möglich sind:
- Keine gefährlichen langlebigen Credentials
- Einfaches Setup für Kunden
- Sicher vor willkürlichen Account-Sperrungen
OpenID Connect als Alternative wäre technisch die Lösung, aber Google macht das Setup unnötig kompliziert: Aus einem einfachen Ein-Schritt-Prozess werden sieben komplexe Schritte mit abhängigen Ressourcen-IDs.
Das bizarre Detail: Ein einziger Kunde hatte während aller drei Suspendierungen weiterhin funktionierenden Zugriff – obwohl dessen Service Account im gleichen gesperrten Projekt lag wie alle anderen.
Die Geschichte erinnert an den UniSuper-Vorfall, bei dem Google einen kompletten Pensions-Fonds-Account löschte. Ayers Fazit: „Ich kann mich nicht auf ein Google-Konto für produktive Anwendungsfälle verlassen“ – eine Einschätzung, die andere Entwickler teilen.
Tja, Augen auf beim Cloud-Einkauf. „Don’t be evil“ scheint lange vorbei.
Google Just Suspended My Company’s Google Cloud Account for the Third Time
Anzeige
Buchtipp: „The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data“
Nach dem DevOps Klassiker aus letzter Woche geht es diese Woche weiter mit dem weniger bekannten Nachfolger – The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data“.
Wir begleiten Maxine, eine Senior Developer, die zur Strafe ins Phoenix Project verbannt wird, nachdem sie angeblich zu einem Payroll-Ausfall beigetragen hat. Was sie dort vorfindet: Bürokratie-Wahnsinn. Nichts geht ohne endlose Meetings, Genehmigungen und Papierkram. Deployment? Dauert Wochen. Änderungen? Brauchen fünf Unterschriften. Produktiv arbeiten? Unmöglich. Klingt bekannt, oder?
Dann trifft sie auf eine Gruppe von „Rebellen“ – Entwickler, die das System kippen wollen, um wieder das zu tun, wofür sie eigentlich da sind: Probleme lösen und Software bauen. Das Buch zeigt genial, einfach wie Technical Debt und unnötige Komplexität ganze Unternehmen lahmlegen können – und wie man das ändern kann. Macht Spaß beim Lesen!
Was mir besonders gefällt: Man sieht endlich mal die Perspektive der Entwickler. Die unsichtbaren Strukturen, die man braucht, damit ein Dev-Team produktiv sein kann. Und die verheerenden Folgen, wenn diese Strukturen fehlen.
Verlinkt ist die englische Variante aber auch das Teil gibt es als „Projekt Unicorn“ mit irgendwie strangem Cover auf Deutsch.
Netflix demokratisiert Incident Management mit incident.io
Netflix hat sein Incident Management grundlegend transformiert: von einem zentralen SRE-Team zu demokratisiertem Prozess, bei dem jedes Engineering-Team eigene Incidents managen kann..
Früher lag Incident Management beim CORE Team (Critical Operations and Reliability Engineering) mit Jira + einem Slack-Channel. Das skalierte nicht: Mit tausenden Microservices brachen ständig Dinge, die nicht erfasst wurden. Das interne „OOPS“-Template (operational surprises) hatte begrenzte Akzeptanz. Zahllose kleinere Incidents gingen unbemerkt unter – verpasste Chancen zum Lernen und Verbessern.
Die Lösung: Incident.io als „Paved Road“
Nach dem Prinzip „build only when necessary“ evaluierte Netflix externe Tools statt In-House-Entwicklung. Incident.io erfüllte vier zentrale Anforderungen: Intuitive Bedienung, Integration interner Daten, ausgewogene Anpassbarkeit und einladendes Design.
Die Transformation in Zahlen:
- 4 Monate: 20% der Engineering Teams nutzen das Tool
- 6 Monate: über 50% Adoption
- Mindset-Shift: Von „große Ausfälle“ zu „jede Störung, die Aufmerksamkeit verdient“
Was den Unterschied machte:
Intuitives Design: Engineers beschrieben die Platform als „jolly“ – sie motiviert tatsächlich zum Öffnen von Incidents. Funktionen lassen sich beim Nutzen entdecken, es sei kein Training nötig.
Interne Integrationen: Netflix-Kontext (Teams, Services, Domains) direkt eingebunden. Automatisierungen binden automatisch die richtigen Teams ein und befüllen Incident-Felder aus Alerts vor. Das reduziere die kognitive Last während eines Incidents massiv.
Organisatorisches Investment: Kompakte Dokumentation, Cheat Sheets, Demo-Videos plus Roadshows durch die Engineering-Teams. Balance zwischen schlank und strukturiert.
Ausgewogene Anpassbarkeit: Teams passen Workflows an ihre Bedürfnisse an, aber Kern-Elemente bleiben konsistent – jeder kann jeden Incident firmenweit schnell verstehen.
Man habe durch die Umstellung einen Erfolgreichen Wandel zu selbstbestimmten Engineers und einer von sich aus wachsende nIncident-Management-Kultur erreicht. Der Prozess entwickele sich hierbei weiter, wie auch das Tooling selbst.
Netflix betreibt bei Medium ein Engineering Blog, hier kann ich ein Abo empfehlen – zur Engineering Culture bei Netflix gibt es bei „The Pragmatic Engineer“ eine 1-stündige Podcast Episode (Netflix Engineering Kultur im Vergleich mit anderen Orgs).
Kennst du Incident.io und hast es in Verwendung? Schreib mir gerne, wie du das findest und was du daran cool findest.
Empowering Netflix Engineers with Incident Management
Ruhe im Alltag: Realistische Erwartungen statt Illusion
Die Produktivitätsberaterin Ashley Janssen untersucht in ihrem Blog-Artikel, was es wirklich bedeutet, „ruhig“ zu sein – und warum viele Menschen dabei unrealistischen Erwartungen nachjagen. Ihr Fazit: Ein vollständig chaos-freies Leben sei eine Illusion, die zwangsläufig zu Enttäuschungen führt.
Die drei Stufen der Ruhe: Janssen unterscheidet zwischen drei verschiedenen Konzepten: Dinge beruhigen, einen Zustand der Ruhe erreichen und ein chaos-freies Leben führen. Während die ersten beiden Ziele erreichbar sind, bleibt das dritte aufgrund der sich ständig ändernden externen und internen Faktoren unerreichbar.
Die Autorin empfiehlt, Klarheit darüber zu gewinnen, was Ruhe in der aktuellen Lebensphase bedeutet – mit drei Kindern unter fünf Jahren sieht das anders aus als später. Zentral ist die Fähigkeit, feste Grenzen zu setzen und bewusst zu wählen, was man in sein Leben einlässt. Ähnliche Gedanken zur Produktivität und zum Umgang mit Chaos hatte ich bereits in Newsletter 155 diskutiert. Marissa schreibt gerade nicht viel zu diesen Themen und daher hab ich mal geschaut, wer sich noch mit Produktivität und Remote beschäftigt.
Viele Chaos-Faktoren wie Arbeitsfristen, Familienverantwortung oder Gesundheitsprobleme lassen sich nicht kontrollieren. Stattdessen geht es darum, das eigene Reaktionsverhalten zu ändern und bewusst Dinge auszuschließen, die erwiesenermaßen Chaos verursachen.
Hört sich in der Theorie auch eher einfacher an, als es glaub in der Praxis dann ist. Naja, auch hier ist wohl gut, wenn man seine Erwartungshaltung etwas reduziert und manche Dinge einfach akzeptiert.
What It Really Means To Be Calm
MongoDB Atlas gekündigt: 90% gespart durch Hetzner Umzug
Das Prosopo Team zahlte $3.000+/Monat für MongoDB Atlas (AWS-hosted) – für ein paar hundert GB Daten. Nach der Migration zu Hetzner: $160/Monat. Eine 90%-Ersparnis bei besserer Performance.
Der Free Tier war perfekt zum Starten, doch Scaling wurde teuer. Die Breakdown vor Migration: M40 Instance $1.000, Continuous Backup $700 und – Achtung – Data Transfer (Internet) $1.000. Letzteres war der Killer: Prosopo nutzt multiple Cloud Provider für Resilienz, daher läuft viel Traffic übers Internet. Bei AWS-only wären Data Transfer Costs minimal („Same Region“ nur $10), aber das schafft ja einen Single Points of Failure.
Bonus-Ironie: Trotz $3.000/Monat kein Support – das kostet extra.
Warum Hetzner? High-Performance Dedicated Server zu einem Bruchteil der AWS-Kosten, predictable Flat-Rate Pricing, starke EU-Datacenter (Privacy-Requirements) und keine Data Transfer Fees zwischen App-Servern und DB. Die Lösung: Ein großer Server mit 256GB RAM und fast SSDs für $160/Monat statt Atlas Replica Set. Falls später Distributed Setup nötig ist, kann man einfach Nodes hinzufügen.
Für die Migration wurden dann 500GB Daten via mongodump gezogen, ein Restore auf Hetzner durchgeführt und diverse Scripts für Changes während der Migration ausgeführt. Interessantes Setup: Proxmox auf physikalischem Host, Ubuntu VM, MongoDB in Docker. VM im private Subnet (10.0.0.x), Host handled DHCP/NAT/Port Forwarding. Traefik als Reverse Proxy für SSL – spart Wrestling mit MongoDB’s eigenen SSL Certs.
DIY bedeutet aber mehr Verantwortung: Ansible (Server Provisioning), Docker, mongodump (Backups), OpenObserve (Logging/Alerting), UFW (Firewall), WireGuard (VPN). Backups jetzt: mongodump + Cron + Hetzner Storage Box, compressed & encrypted.
Der Atlas-Monitoring-Fail: Atlas zeigte Connection Leaks – aber ließ keine Admin Shell Commands zu um Connections zu killen. Bei Connection Limit erreicht: Services manuell killen. Mit eigenem Server: direkter Zugriff via MongoDB Shell.
Die Specs im Vergleich:
- Atlas M40: 8 vCPU, 16GB RAM, 380GB SSD
- Hetzner: 8-core Xeon W-2145, 256GB RAM, 4x 3,84TB NVMe SSD RAID 5
Performance hat sich stark verbessert – Specs sind höher, Indexes bleiben meist in Memory. Für kleine Teams mit nur wenig Ressourcen und hohem Kostenbewusstsein ist DIY sinnvoll und lohnenswert. Bei weiterem Wachgstum mögen Hosted Solutions wieder Sinn machen, aber aktuell: happy mit dem Setup.
Aber Achtung: Am Anfang des Artikels wird mit Single Point of Failures argumentiert, und man habe die hohen Cloud Kosten aufgrund der Verteilung über die Clouds/Regionen. Hier hat man nun einen Server, an dem alles hängt. Kann auch funktionieren, je nachdem, wie man das selber mit sich ausmacht.
We cut our Mongo DB costs by 90% by moving to Hetzner
Open Source Blackout: Wenn Package Registries streiken würden
PHPUnit-Entwickler Sebastian Bergmann malt in einem dystopischen Gedankenexperiment das Szenario eines weltweiten Package-Registry-Ausfalls. Was würde passieren, wenn Packagist, NPM, Maven Central, PyPI und crates.io gleichzeitig offline gehen?
Die Zahlen sind beeindruckend: NPM verzeichnet 184 Milliarden Downloads pro Monat, PyPI 89 Milliarden, Maven Central über 1 Billion pro Jahr. Moderne Anwendungen bestehen zu über 80% aus Open-Source-Komponenten. Ohne diese Infrastruktur müssten Unternehmen das 3,5-Fache ihres Softwarebudgets ausgeben. Harvard-Forscher schätzen den Wert von Open-Source-Software auf 8,8 Billionen Dollar.
Die bittere Realität
Diese kritische Infrastruktur wird von unterbezahlten Freiwilligen und gemeinnützigen Organisationen betrieben, während Milliarden-Unternehmen enormen Wert daraus ziehen. Die konservativen Einsparungen durch Open Source werden auf 100 Milliarden Dollar jährlich geschätzt – die Investitionen in die Infrastruktur sind „lächerlich unzureichend“.
OpenSSF, Packagist und andere Registries fordern: Entwickler sollen richtiges Caching implementieren, Unternehmen in die Infrastruktur investieren, Tool-Entwickler nachhaltige Designs wählen. Das WiX Toolset führte kürzlich eine Open Source Maintenance Fee ein – ein Modell, das Schule machen könnte. Sentry spendete letztes Jahr $750.000 an Open Source Maintainer, im Jahr davor waren das noch $500.000. Das Announcement für dieses Jahr müsste bald kommen, ich behalte das im Auge.
Bergmann warnt zusätzlich vor der Abhängigkeit von US-Infrastruktur (GitHub, AWS, Azure) und plädiert für europäische Souveränität.
Ich finde – er hat recht – man sollte sich zumindest mal selbst auditieren und prüfen, welche Services in Verwendung sind und auf welcher Cloud die laufen. Wenn sie dann alle in US-EAST-1 bei AWS laufen, hat man ggf. ein anderes Problem 😉
Tata Motors: 70TB durch AWS-Keys im Frontend-Code zugänglich
Security-Forscher Eaton beschreibt in einem ausführlichen Blog-Post, wie er Indiens größten Autohersteller durch simple Fehler kompromittieren konnte. Die Schwachstellen wurden bereits 2023 entdeckt und über Indiens CERT-IN gemeldet.
Auf der E-Commerce-Plattform E-Dukaan fand Eaton AWS-Credentials im Klartext im Frontend-Code – verwendet, um eine lächerliche 4 KB Datei mit Steuercodes herunterzuladen. Die Keys ermöglichten Zugriff auf zahlreiche S3-Buckets mit Kundendatenbank-Backups, 40 GB Bestellreports und hunderttausenden Rechnungen inklusive PAN-Nummern.
Im Fleet-Management-System FleetEdge waren die AWS-Keys zwar „verschlüsselt“, aber der Decrypt-Code war ebenfalls im Frontend vorhanden. Diese Keys erschlossen weitere Buckets mit über 70 TB an Daten, darunter ein Data Lake mit Dateien seit 1996. Zusätzlich hatte Eaton Schreibzugriff auf mehrere Websites.
Tableau-Backdoor und weitere Schwachstellen
Im E-Dukaan-Code fand sich eine Funktion für „Trusted Tokens“ – diese ermöglichte Login in Tableau nur mit Username, ohne Passwort. Nach Identifikation des Server-Admin-Usernames hatte Eaton vollständigen Zugriff auf sämtliche internen Dashboards, Finanzreports und Dealer-Daten. Zusätzlich lag der Token für das Testfahrzeug-Tracking-System Azuga offen im JS-Code – kann also nix passieren, alles ist sicher.
Ähnliche Credential-Leaks sind ein bekanntes Problem, wie der Datadog Report aus 2024 zeigt. Die gemeldeten Schwachstellen wurden nur zögerlich behoben – die AWS-Keys blieben über vier Monate aktiv, bis Januar 2024.
Das Tool GitLeaks hatte ich in Ausgabe 201 erst empfohlen – das man auf jeden Fall Sinn, sowas in der Art im eigenen CI/CD Prozess im Default einzubauen – ohne „Pass“ geht nichts davon live.
Hacking India’s largest automaker: Tata Motors
Anthropic erklärt Claude-Qualitätsprobleme: 3 Infrastruktur-Bugs
Anthropic veröffentlicht einen detaillierten technischen Postmortem zu Qualitätsproblemen, die Claude zwischen August und September betrafen. Die KI-Firma betont: „Wir reduzieren niemals die Modellqualität aufgrund von Nachfrage, Tageszeit oder Serverlast“ – die Probleme waren ausschließlich infrastrukturbedingt.
Drei überlappende Bugs verursachten die Degradierung: Ein Context Window Routing Error leitete ab 5. August kurze Anfragen fälschlicherweise an Server für 1M Token Context Windows um. Nach einer Load-Balancing-Änderung am 29. August waren zeitweise 16% aller Sonnet 4-Requests betroffen. Besonders problematisch: Das „sticky“ Routing bedeutete, dass betroffene Nutzer dauerhaft auf falschen Servern landeten.
Ein Output Corruption Bug auf TPU-Servern (25. August) verursachte bizarre Ergebnisse – englische Prompts produzierten plötzlich thailändische oder chinesische Zeichen, Code enthielt offensichtliche Syntaxfehler. Der dritte Bug war ein XLA:TPU Compiler-Fehler bei der Token-Generierung, ausgelöst durch Mixed-Precision-Arithmetik zwischen bf16 und fp32.
Die Detection war schwierig: Evaluations erkannten die Probleme nicht, da Claude oft gut von isolierten Fehlern recovered. Zudem verhinderten interne Privacy-Kontrollen den direkten Zugriff auf problematische Nutzerinteraktionen. Anthropic reagiert mit sensitiveren Evaluations, kontinuierlichem Monitoring auf Produktionssystemen und besseren Debug-Tools.
Gar nicht so einfach, so eine Infrastruktur zu betreiben – bin mir nicht sicher, gibt es solche Reports auch bei OpenAI?
Jedenfalls gut, dass man so transparent damit umgeht – auch wenn es etwas länger gedauert hat wie bei einem Hyperscaler.
A postmortem of three recent issues
OSINT und Pretexting: Wenn öffentliche Daten zur Waffe werden
Security-Forscher Sebastian Furmanczak erklärt in einem ausführlichen Artikel, wie Angreifer durch Open Source Intelligence (OSINT) die Grundlage für raffinierte Social-Engineering-Attacken schaffen. Der Beitrag zeigt detailliert, welche öffentlichen Informationsquellen Kriminelle systematisch ausnutzen – und warum technische Sicherheitsmaßnahmen allein nicht ausreichen.
Die Recherche-Phase kann Wochen oder Monate dauern. Angreifer durchforsten LinkedIn und Xing für Organigramme, analysieren Stellenanzeigen für eingesetzte Technologien (wer Kubernetes-Kenntnisse sucht, nutzt vermutlich AWS), studieren Finanzberichte im Bundesanzeiger und nutzen Plattformen wie NorthData für Geschäftsführer-Netzwerke. DNS-Records offenbaren verwendete Services wie Salesforce oder Mailchimp, die sich perfekt für gefälschte Rechnungen eignen.
Besonders perfide: Manipulierte USB-Sticks mit Firmenlogo, die auf dem Gelände platziert werden. Moderne Varianten wie der Rubber Ducky von Hak5 melden sich als Tastatur an und führen binnen Sekunden automatisierte Befehle aus. USB-Killer zerstören Hardware durch Hochspannungsentladungen.
Mit KI-Tools wie ElevenLabs lassen sich aus 30 Minuten Podcast-Material täuschend echte Stimmen klonen – Voice-Deepfake-Angriffe sind längst Realität. Ein britisches Unternehmen verlor 2024 durch einen gefälschten Videoanruf 25 Millionen USD.
Furmanczak referenziert die Klassiker von Kevin Mitnick („The Art of Deception“) und Robert Cialdinis Prinzipien der Beeinflussung – die psychologische Grundlage bleibt zeitlos gültig.
Und nun? Immer aufpassen, was man wo teilt – ist man eh öffentlich unterwegs, auf Social Media oder mit einem Podcast – am Besten die Familie und Freunde informieren, dass sie im Zweifel immer erstmal zurückrufen oder auf einem anderen Weg den Kontakt suchen sollen.
OSINT und Pretexting: Wie Angreifer öffentlich Informationen für sich nutzen
Schmunzelecke
„I Powered My House Using 500 Disposable vapes“ ist eigentlich gar nicht so witzig, aber ich wollte es euch nicht vorenthalten – bei YouTube.
Iammarkzuckerberg.com kannte ich bisher auch nicht, Speziell der Part „Interesting Things That Have Happened to Me Because My Name is Mark Zuckerberg“ bringt dich bestimmt zum lachen, Auszug:
- My personal Facebook account has been disabled five times and my business account four times because Facebook believes I am impersonating a celebrity or using a fake name (click to see full document)
- I was sued by the state of Washington due to mistaken Identity. They thought I was the founder of FaceBook who was accused of endangering an adult in need of services. (click to see full document)
- ….
💡 Link Tipps aus der Open Source Welt
Opsmate – LLM-Powered SRE Copilot
Opsmate ist ein KI-gesteuerter SRE-Assistent, der bei der Analyse und Lösung von Production-Problemen hilft. Das Tool ermöglicht es, komplexe Troubleshooting-Aufgaben in natürlicher Sprache zu beschreiben, ohne sich Command-Line-Syntax merken zu müssen.
Features:
- Natural Language Interface: Führe Commands mit natürlicher Sprache aus
- Advanced Reasoning: KI-gestützte Problemanalyse und Root-Cause-Analysis
- Multi-LLM Support: OpenAI, Anthropic, xAI out-of-the-box
- Multiple Runtimes: Local, Docker, Kubernetes und Remote-VM-Unterstützung
- Observability: Prometheus-Integration für Time-Series-Dashboards via Natural Language
- Knowledge Management: Domain-spezifisches Wissen einbinden und nutzen
- Web UI & API: Zugriff über Webinterface oder REST API
- Plugin System: Erweiterbar durch Custom Plugins
Installation & Setup:
bash
# Installation via uv (empfohlen)
uv tool install -U opsmate
# API-Key setzen
export OPENAI_API_KEY="sk-proj..."
# Commands ausführen
opsmate run "what's the gpu of the vm"
# Probleme lösen
opsmate solve "what's the k8s distro of the current context"
# Web UI starten
opsmate serve # http://localhost:8080Production Deployment: Für Kubernetes gibt es den opsmate-operator mit CRD-basiertem Task-Scheduling, Multi-Tenancy und automatischem Resource Management.
Bald kommen dann die „Ich hab 10 Engineers mit Opsmate ersetzt“ Beiträge – ich bring die dann natürlich auch.
https://github.com/opsmate-ai/opsmate
dysk – Modernes Filesystem Info Tool
dysk ist ein Linux/Mac Utility zum Anzeigen von Filesystem-Informationen, entwickelt als moderne Alternative zu df. Das Tool (früher bekannt als lfs) bietet eine übersichtlichere und flexiblere Darstellung von Disk-Usage-Daten.
Features:
- Übersichtliche Tabellen: Farbcodierte Ausgabe mit Balkendiagrammen für die Auslastung
- Flexible Spaltenauswahl: Wähle genau die Metriken, die du brauchst
- Multiple Output-Formate: Tabelle, JSON, CSV für weitere Verarbeitung
- Advanced Filtering: Filtere nach Filesystem-Typ, Mount-Point oder Größe
- Sortierung: Nach beliebigen Spalten sortierbar
- Inode-Information: Zeigt auch Inode-Usage an
- Docker-Volume Support: Erkennt auch spezielle Volumes
- Cross-Platform: Linux, macOS und Windows (neu)
Beispiel-Output:
bash
# Standard-Ausgabe mit Balken
dysk
# JSON-Format für Scripting
dysk --json
# Nur bestimmte Spalten
dysk --columns filesystem,size,used,use
# Nach Filesystem-Typ filtern
dysk --filter-type ext4Library: Das zugrunde liegende lfs-core Crate kann in eigenen Rust-Anwendungen verwendet werden, um Filesystem-Daten programmatisch abzurufen. Den Beispiel Output findest du bei GitHub – Packages für diverse Linux Betriebssysteme dann hier.
dysk macht Filesystem-Monitoring deutlich angenehmer durch seine moderne Darstellung und flexible Konfigurationsmöglichkeiten.
❓ Feedback & Newsletter Abo
Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.
Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren: