AWS blockiert Verbindungen zu meinem On-Premises-Dienst

 (consulting.m3047.net)
1 Punkte von GN⁺ 2024-09-01 | 1 Kommentare | Auf WhatsApp teilen
  • Das öffentliche Internet könnte sich in ein fragmentiertes Ökosystem aufspalten, das von großen Cloud-Anbietern dominiert wird; das Blockieren von On-Premises-Zugriffen aus AWS ist ein operatives Beispiel für diese Entwicklung.
  • Betroffen sind vor allem TCP-Verbindungsversuche, die Clients innerhalb von AWS zu On-Premises-Diensten aufbauen; ausgehende Verbindungen lokaler Clients zu in AWS gehosteten Diensten bleiben weiterhin möglich.
  • Die betriebenen On-Premises-Dienste umfassen Web, eine Trualias-Demo, DNS und SMTP; DNS bietet UDP, TCP-Fallback sowie eingeschränkten öffentlichen Zugriff auf Sicherheitstelemetrie.
  • Die AWS-Blockade begann als Reaktion auf übermäßigen Ping-Traffic und abusive Crawler/Scanner; derzeit werden 53 CIDRs aus dem AWS-Adressraum verwaltet, die als Ziel oder Quelle von Missbrauch beobachtet wurden.
  • Wenn große Cloud-Anbieter forensische Informationen wie Reverse DNS, Whois, DNS-Namensräume und Missbrauchsmuster nicht besser veröffentlichen, kann sich eine Fragmentierung verstärken, die Nutzer innerhalb der Cloud kaum bemerken.

Möglichkeit der Fragmentierung durch große Clouds

  • Wenn große Cloud-Anbieter zu einer „too big to fail“-bulletproof infrastructure werden, können sie direkt zur Fragmentierung des Internets beitragen.
  • Das ist noch kein vollständig eingetretenes Phänomen, wird aber als etwas gesehen, das bereits begonnen hat oder bald sichtbar werden könnte.
  • Das Cloud-native Ökosystem verfügt im Vergleich zum tatsächlichen Internet über maßgeschneiderte Infrastruktur; einzelne Cloud-Dienste sind eher um unterscheidbare Funktionen herum aufgebaut als um eine gemeinsame Architektur.
  • Viele Dienste funktionieren innerhalb einer bestimmten Cloud in sich geschlossen, und es gibt Hürden für eine transparente Interoperabilität mit dem allgemeinen Internet.
  • Die Cloud-native Community behandelt das allgemeine Internet wie eine externe Ressource und interagiert stärker mit dem Ökosystem eines bestimmten Cloud-Anbieters als mit dem Internet selbst.

Kommerzialisierung des öffentlichen Internets

  • Vor 1989 gab es keinen allgemeinen öffentlichen Zugang zum Internet; es war ein eher privates Netzwerk für Regierungs-, Militär-, Forschungs- und Bildungseinrichtungen.
  • Die NSF verwaltete den Kern des Backbones, und der frühe öffentliche Zugang wurde unter der Bedingung von nichtkommerziellem Traffic erlaubt.
    • Kommerzielle Dienste an sich waren nicht verboten, aber Traffic über den NSFNet-Backbone durfte kein Werbe- oder Paid-Service-Traffic sein.
  • Kommerzielle Anbieter bauten ein separates kommerzielles Internet auf, und 1995 deaktivierte NSFNet den öffentlichen Zugang.
  • Nach der großen Auslese um das Jahr 2000 überlebten Modelle auf Basis von Werbung anhand von Nutzerverhaltensdaten und dem Verkauf von Nutzerverhaltensdaten.
  • In der aktuellen KI-Welle fällt besonders auf, dass zugängliche Inhalte massenhaft gesammelt, bereinigt und für das Training von Modellen genutzt werden; Kuratierung und Training finden überwiegend in der Cloud statt, zunehmend durch die Cloud-Anbieter selbst.

Blockieren von AWS-Verbindungen bei On-Premises-Diensten

  • Eingehender AWS-Zugriff auf On-Premises-Server wird größtenteils deaktiviert.
  • Technisch geht es hauptsächlich um TCP-Traffic, bei dem sich Client und Server anhand des initialen Handshakes unterscheiden lassen.
    • Verbindungsversuche von Clients innerhalb von AWS zu On-Premises-Diensten werden blockiert.
    • Clients im lokalen Netzwerk können sich mit in AWS gehosteten Diensten verbinden.
  • Lokal werden mehrere öffentlich im Internet erreichbare Dienste betrieben.
    • Webdienste
    • Trualias-Demo
    • DNS-Server
    • SMTP-E-Mail-Server
  • Seit Jahren gilt eine No-crawl-Policy, und die bereitgestellten Assets richten sich hauptsächlich an einzelne Internetnutzer.
  • Der DNS-Server nutzt UDP und TCP-Fallback und stellt eingeschränkte öffentliche Sicherheitstelemetrie bereit.
    • Beispielabfrage: dig @131.191.85.30 'fail2ban;*.keys.redis.athena.m3047' txt
    • Sie kann auch für Dienste nützlich sein, die in der Cloud laufen; wer sich im Betrieb darauf verlassen möchte, sollte aber vorher Kontakt aufnehmen.

Reverse DNS und SMTP-Ausnahme

  • Wenn nur Webdienste das Problem wären, könnten andere Gegenmaßnahmen wie Reverse-DNS-Abfragen genutzt werden.
  • Cloud-Anbieter betreiben Reverse DNS häufig schlecht, was zur Erzählung passt, dass Ressourcen in der Cloud temporär seien.
  • AWS macht Reverse DNS besser als viele andere Cloud-Anbieter, und man hört, dass sich Reverse DNS für Instanzen konfigurieren lässt; selbst ausprobiert wurde das jedoch nicht.
  • Für SMTP gibt es eine Ausnahme.
    • Solange es keine besonders gravierenden Probleme gibt, werden Verbindungen zu Mailservern erlaubt, auch wenn andere Dienstverbindungen blockiert werden.
    • Technisch kann SMTP auch ohne korrektes Reverse DNS betrieben werden, praktisch nehmen Gegenstellen ohne korrektes Reverse DNS aber keine Mail an.
  • Durch die Bewertung von Reverse DNS lässt sich eine erste Einschätzung treffen, ob ein SYN von einem legitimen Mailserver stammt.
    • Reputationsdienste können Reverse DNS bewerten.
    • Es gibt Muster, die bei gemieteten und temporären Ressourcen häufig vorkommen.
  • Schon die Existenz oder Form von Reverse DNS kann eine vernünftige Einschätzung ermöglichen, ob eine Adresse zu einem Cloud-Anbieter gehört.

Warum das Blockieren von AWS-Adressen begann

  • Ausgangspunkt war das Blockieren identifizierbarer Netblocks einiger missbräuchlicher Dienste, woraus später ein Proof of Concept für das selektive Blockieren kleiner Hosting-Anbieter wurde.
  • Im Fall von AWS war der Ausgangspunkt übermäßiger Ping-Traffic.
    • Ping ist ein verbindungsloses Protokoll, sodass die Quelladresse gefälscht werden kann.
    • Antworten auf gefälschte Ping-Anfragen gehen nicht an den Angreifer, sondern an den tatsächlich gefälschten Zielort.
  • Um endlose Ping-Antworten einzudämmen, müssen temporäre Firewall-Regeln erstellt werden; wegen der Größe von Amazon werden daraus jedoch sehr viele Regeln.
  • Es wurde begonnen, AWS-Adressbereiche zu sammeln; derzeit gibt es 53 CIDRs, die AWS-Adressraum repräsentieren, der als Ziel oder Quelle von Missbrauch beobachtet wurde.
  • Zeitweise werden auch temporäre Firewall-Regeln in doppelter Anzahl beobachtet.
  • Das Blockieren von abusive Crawlern und Scannern, die bei einem „too big to fail“-Cloud-Anbieter gemietet wurden, ist ein nützlicher Nebeneffekt; wenn sie aus den Weblogs verschwinden, fehlt nichts.

Auswirkungen für Cloud-Nutzer

  • Die meisten beliebten Ressourcen oder Ressourcen, die wahrscheinlich in der Cloud deployt werden, sind auf GitHub gehostet.
  • Wer andere Ressourcen in der Cloud deployt, muss ein eigenes Repository für das Staging pflegen.
  • Wenn das Repository in AWS liegt, können Updates nicht mehr geprüft werden.
    • Die Prüfung muss vom Desktop aus erfolgen.
    • Sie muss von privat gehosteten Ressourcen aus erfolgen.
    • Eine separate Vereinbarung kann besprochen werden.
  • Einen Zustand mit nur Smartphone, S3-Bucket und EC2-Instanz kann man schwerlich als „im Internet sein“ bezeichnen, aber vom Smartphone aus sollte der Zugriff auf solche Ressourcen möglich sein.

Eindämmung von Datendiebstahl und unbeabsichtigte Nutzung

  • Datendiebstahl, bei dem Open-Source-Material ohne Erlaubnis für unbeabsichtigte Zwecke zweckentfremdet wird, ist ebenfalls eine Bedrohung, die eigene Gegenmaßnahmen erfordert.
  • Die AWS-Blockade wirkt auch als eine solche Gegenmaßnahme.
  • Materialien zu cats, bunnies und birds werden ebenfalls im Kontext von Gegenmaßnahmen behandelt.
    • cats und bunnies erscheinen, weil es sehr viele einschlägige Videos gibt und einige davon käuflich sind.
    • birds sind auf OSI-Schicht 2 effektiver und in einem RFC als Methode zur Übertragung von IP-Datagrammen dokumentiert.

Erforderliche öffentliche Informationen großer Cloud-Anbieter

  • Große Cloud-Anbieter sollten ein besseres System zur Verbreitung forensischer Informationen bereitstellen als heute.
  • DNS und Whois können Werkzeuge zur Verbreitung potenziell nützlicher Informationen sein.
  • Ein großer Anbieter sollte eigenes Reverse DNS betreiben können.
  • Whois für einzelne Adressen, zusätzliche in Reverse DNS kodierte Informationen und separate öffentliche Informationen im DNS-Namensraum können erforderlich sein.
  • Auch ein Storm Center Blog, der aktuelle Missbrauchsmuster und betroffene Adressblöcke behandelt, wäre ein möglicher Ansatz.
  • Für SMTP gibt es neben Reverse DNS auch SPF, das über DNS-TXT-Records veröffentlicht wird.
  • Schon anhand einer einzelnen IP-Adresse sollten Informationen auffindbar sein, die folgende Fragen beantworten:
    • Ob die Ressource hinter dieser Adresse Pings sendet
    • Wie viele Pings sie sendet
    • Ob sie ausgehende TCP-Verbindungen aufbaut
    • Zu welchen Diensten sie Verbindungen aufbaut
    • Wer die Ressource kontrolliert
    • Ob die Ressource angegriffen wird
    • Um welche Art von Angriff es sich handelt
    • Welche Gegenmaßnahmen andere Ressourcen im Internet anbieten sollen
  • Geeignete Gegenmaßnahmen helfen allen, falsch ausgerichtete dagegen nicht.

Folgen eines fragmentierten Internets

  • Wenn sich diese Praxis verbreitet, kann sie zu einem balkanized internet führen.
  • Menschen, die ihr Online-Leben innerhalb der Blase großer Cloud-Anbieter verbringen, bemerken die Unannehmlichkeiten möglicherweise größtenteils nicht.
  • Selbst wenn sie Unannehmlichkeiten bemerken, können sie diese als Folge der Wahl eines bestimmten Cloud-Anbieters wahrnehmen.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-01
Meinungen auf Hacker News

  • Die großen Cloud-Anbieter veröffentlichen alle maschinenlesbare Listen ihrer IP-Bereiche
    Beispiele: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-rang...
    https://www.microsoft.com/en-us/download/details.aspx?id=565...
    https://support.google.com/a/answer/10026322?product_name=Un... usw.

    • Ich habe es heute nicht geprüft, aber Amazons JSON-Datei verschleiert zum Beispiel gewissermaßen, dass sie unabhängig von der tatsächlichen Eigentümerschaft faktisch 3.0.0.0/8 nutzen
      Auf Spiele wie „versuchen wir mal, Amazons riesige JSON-Liste zu blockieren“ habe ich keine Lust, und es sind nur 53 Regeln. Ein gewisses Maß an Nebenwirkungen kann ich verkraften, und auch Websites auf AWS sind weiterhin gut erreichbar

  • Im heutigen Internet ist es verrückt, wie schnell aggressiver Traffic einsetzt, sobald man Infrastruktur öffentlich macht
    Kürzlich habe ich für eine Anycast-Konfiguration ein /23-Subnetz per BGP angekündigt, und sobald die Route aktiv war und Traffic zum Router floss, explodierte tcpdump mit Portscans auf alle IPs im Bereich
    Natürlich lag das nicht an der Route selbst; offenbar scannen viele Akteure alle IP-Bereiche wahllos und dauerhaft. Dieser Bereich war jahrelang nicht angekündigt, er konnte also auch nicht auf irgendeiner Liste aktiver Server gestanden haben
    Dass interne Webdienste wie GitLab immer noch direkt im Internet exponiert werden, finde ich schockierend. Meiner Meinung nach sollte man mindestens eine zusätzliche Schutzschicht wie ein VPN davor setzen, damit der Dienst im öffentlichen Internet nicht auffindbar ist
    Öffentlich erreichbar ist nur SSH auf einem einzelnen Bastion-Host, und selbst das würde ich später gern durch eine VPN-Schicht ersetzen und abschaffen

    • Es ist besser, die Erwartungen neu zu justieren. Portscans sind nichts Besonderes und kaum etwas, das man als Angriff bezeichnen würde; sie sind eher so etwas wie die Hintergrundstrahlung des Internets
      So wie es im Weltraum Hintergrundstrahlung gibt, gibt es im Internet die Hintergrundstrahlung des Internets. Wenn man keine verwundbaren Dienste betreibt, entspricht das Risiko solcher Portscans ungefähr dem, in einem Monat eine Banane mehr zu essen
      Es stört nur, weil man es direkt auf der Konsole sieht. Das ist so, als würde man mit einem überempfindlichen Geigerzähler ins Flugzeug steigen und sich erschrecken; wenn man es nicht wüsste, würde es einem nicht schaden
      Dass interne Dienste im Internet exponiert werden, überrascht mich ebenfalls, aus zwei Gründen: Ich vertraue den Authentifizierungssystemen der meisten Programme nicht, und ich möchte nicht, dass von außen sichtbar ist, welche internen Dienste ich nutze. Das hat teils eher mit Privatsphäre zu tun als mit reiner technischer Sicherheit
      Umgekehrt können Dinge, die im Internet sein müssen und von denen man glaubt, dass sie eine starke Eingangstür haben oder ausreichend sandboxed sind, den ganzen Tag im Internet stehen
      Portscans sind die Internetversion davon, durch eine Stadt zu laufen und zu notieren, in welchen Häusern Licht brennt. Das kann etwas stalkerhaft wirken, ist aber öffentliche Information
      Nebenbei: ssh -w erstellt zwar ein VPN-Tunnel-Interface, konfiguriert aber nicht automatisch den Rest wie ein echtes VPN-Produkt
    • Wenn du darüber noch eine VPN-Schicht legen möchtest, würde mich interessieren, welche VPN-Software du verwenden würdest. Persönlich habe ich nichts gefunden, das sich für mich so vertrauenswürdig anfühlt wie OpenSSH
    • Falsch konfiguriertes öffentliches SSH darf man auf keinen Fall online stellen. Es kann im wörtlichen Sinne innerhalb weniger Sekunden kompromittiert werden
      Das Internet fühlt sich zunehmend wie das an, was hinter der Blackwall in Cyberpunk passiert
    • Das ist nicht nur eine Sache von „heutzutage“. Schon vor 25 Jahren war es ziemlich üblich, dass exponierte Webserver ständig von Skripten oder Bots geprüft wurden, und das sah man häufig in den Web-Access-Logs
      Wenn man die Logs für abgewiesene Zugriffe der Firewall aktivierte, kamen dauerhaft Versuche auf bekannte und unbekannte Ports herein
      Wenn man etwas exponiert, darf es selbst bei tief versteckten Webkomponenten nicht zu einer Tür in die Daten und Infrastruktur werden
      Was sich seit damals etwas geändert hat, sind die Quellen des Traffics und die Kriterien dafür, ob man ihn annehmen oder blockieren sollte. Die Zahl legitimer Server und Dienste, Proxys auf Endnutzerseite, Cloud-Anbieter und Crawler ist stark gestiegen
    • Das klingt nach einem Problem, das speziell IPv4 betrifft. Wenn man ausschließlich auf IPv6 setzt, wäre IP-Scanning für böswillige Akteure nicht praktisch unmöglich?

  • Wirklich schade. Damit läuft man Gefahr, dass die eigenen Inhalte in Suchmaschinen überhaupt nicht auftauchen, auch nicht von Marginalia erfasst und nicht in der Wayback Machine gespeichert werden.
    Wenn man genau das will, kann es sinnvoll sein, alle Clouds und Rechenzentren zu blockieren. Je nachdem, wo ein kleiner ISP sein CGNAT-Gateway betreibt, könnte man sogar dessen Nutzer aussperren. Unwahrscheinlich, aber nicht unmöglich.
    Der einzige im Text als tatsächlicher Missbrauch erwähnte Fall scheint ein Ping mit gespoofter Quelladresse zu sein. Ob die gespooften Ping-Pakete von AWS kamen, lässt sich nicht wissen. Die Quelladresse ist nämlich die Adresse, an die der Spoofer die Antwort geschickt haben möchte, nicht die Adresse des Spoofers.
    Eine deutlich weniger invasive Gegenmaßnahme wäre, Ping auf etwa 10 pro Sekunde rate-zulimiten.
    Das Internet wird zwar balkanisiert, aber der Hauptgrund sind weniger IP-Range-Blockaden als die Siloisierung sozialer Medien für Werbe- und Datenerlöse sowie der Trend, aus KI-Trainingsdaten Umsatz zu ziehen. Fälle wie der Exklusivvertrag zwischen Reddit und Google passen eher dazu.
    Ich kann die Denkweise schwer nachvollziehen, sich über die Balkanisierung der IP-Konnektivität zu beklagen, während man wegen einiger Pings einen bestimmten Anbieter blockiert. Die Balkanisierung erzeugt die blockierende Seite.

    • In heutigen Suchmaschinen erscheint kaum noch etwas außer riesigen, werbeverseuchten Content-Farmen und großen Sites wie Wikipedia, Stack Overflow, großen Nachrichten- und Medienseiten oder YouTube.
      Es ist schon eine ganze Weile her, dass persönliche Blogs oder kleine Hobbyseiten in den Suchergebnissen auftauchten.
      Wenn ich Wikipedia oder Stack Overflow brauche, kann ich direkt dort suchen. Ich wünschte, es gäbe eine Option, die „üblichen Verdächtigen“ auszublenden und mehr Long-Tail-Inhalte zu sehen.
    • Das wirkt wie ein Klagen darüber, zu Maßnahmen „gezwungen“ worden zu sein, die Balkanisierung verursachen können.
      Der Gesamttenor fühlt sich allerdings eher so an, als würde ein Mückenstich zu einer großen historischen Erzählung verwoben.
    • Warum sollte selbst ein kleiner ISP ein CGNAT-Gateway außerhalb seines eigenen IP-Space betreiben?
      Ein CGNAT-Gateway in der Cloud zu betreiben, dürfte viele Probleme machen. Die Abonnenten hätten dann keine Residential-IP mehr, könnten Dienste wie Netflix eventuell nicht nutzen und würden bei Cloudflare oder Google wahrscheinlich häufiger Bot-Schutz-CAPTCHAs sehen.
      Ich frage mich, ob es tatsächlich bekannte Fälle gibt.
    • Mich interessiert, welche Annahme dahintersteht, „nicht in Suchmaschinen aufzutauchen“ als Nachteil oder Schaden zu sehen. Ich teile diese Sicht nicht, versuche sie aber zu verstehen.
    • Der Autor hat schon seit Langem gesagt, dass er eine No-Crawling-Policy verfolgt. Wahrscheinlich kümmert es ihn nicht, und angesichts der Enshittification von Google könnte es sogar die richtige Entscheidung sein.

  • Hetzner, DigitalOcean, Linode, OVH und Contabo blockiere ich schon seit einiger Zeit.
    Das geht in pfBlocker NG per ASN-Blockierung, oder auch mit UFW-Regeln: https://blog.abctaylor.com/ufw-and-firewalld-rules-to-block-...

    • Wenn man so pauschal blockiert, können legitime Organisationen die Site eventuell nicht erreichen. Wenn die Site etwas verkauft, kann das ein Problem sein.
      Zum Beispiel könnte eine Organisation WireGuard oder eine andere VPN-Lösung selbst bei einem Cloud-Anbieter betreiben; wenn Leute darüber zugreifen, erscheint die ausgehende IP als IP des Cloud-Anbieters.
    • Viele große und kleine Unternehmen nutzen heute VPNs oder ähnliche Lösungen mit Exit-Nodes in der Cloud. Solche Blockaden können am Ende dazu führen, dass man von Arbeitsrechnern aus Websites nicht mehr erreicht.
    • Oje, warum sogar Hetzner?
    • Ich finde, es sollte wie in der realen Welt auf Gegenseitigkeit beruhen. Wenn jemand einen Anbieter blockiert, sollte dieser Anbieter zurückblockieren dürfen.
      Das ließe sich sogar automatisieren. Dann wäre es fair, und jede Partei wüsste, was passiert. Oder man nimmt statt solcher Sandkasten-Spielchen gleich echte Waffen.

  • Mein erster Gedanke war, dass echte Desktops, die auf AWS laufen, insbesondere Dienste wie Amazon Workspaces, blockiert werden könnten.
    Allerdings scheint auch der IP-Space solcher Dienste öffentlich dokumentiert zu sein, sodass man diese IPs bei Bedarf separat erlauben kann.
    Trotzdem ist es mit einem Proxy oder VPN sehr einfach, solche Blockaden zu umgehen.

    • Für dich mag das einfach sein. Aber wenn man sieht, wie viele Leute heute in Richtung Serverless gehen, scheint selbst die Mehrheit der Techniker die eigene Netzwerktechnik oder Infrastruktur nicht selbst anfassen zu wollen.

  • Vor langer Zeit haben Dutzende Amazon-Server angefangen, unsere On-Premises-Server auszubremsen, also habe ich genau das gemacht.
    Vielleicht war es irgendein SSO-Versuch, aber wir konnten es nie vollständig nachverfolgen. Ich habe einfach ein Skript geschrieben, das regelmäßig die Liste der Amazon-IP-Ranges herunterlädt und alle blockiert, und es dabei belassen.

  • Ich verstehe es. Wenn ich große Teile des Internets von etwas, das ich gebaut habe, abmauern wollte, würde ich dasselbe tun. Es ist nicht viel anders, als ganze Länder zu blockieren.
    Ich verstehe auch den Wunsch, den Lärm zu reduzieren und nur einen „kleinen Freundeskreis“ zuzulassen.
    Allerdings mache ich das nur für bestimmte Dienste, nicht für die gesamte Domain. Meinen Mumble-Server öffne ich nur für die 3–4 Länder, in denen meine Freunde sind, und schließe Cloud-Anbieter aus. Mein Tech-Blog bleibt weltweit für alle sichtbar.
    Ich stehe fest auf der Seite, dass geteiltes Wissen allen nützt. Wenn meine Notiz zum Modem-Initialisierungsstring eines 300-Baud-C64-Modems auch nur einer einzigen Person hilft, muss diese Person nicht denselben Schmerz durchmachen wie ich, und die Welt wird ein kleines bisschen besser.
    Ich verstehe, dass dieser Wunsch aus verschiedenen Gründen entstehen kann. Das ist okay. Jeder soll es so machen, wie er will.

    • Mein Zen InterSLIP Dialing Script ist buchstäblich um die ganze Welt gegangen.
      Amazon ist zu groß, um es zu ignorieren. Ich verstehe, dass ein großer Teil des ICMP- und SYN-Traffics Müll ist. Ich möchte ebenfalls beim Blockieren helfen und habe tatsächlich standardmäßig Gegenmaßnahmen eingerichtet.
      Das Problem ist, dass Amazon meine Gegenmaßnahmen „im großen Maßstab“ triggert, und das macht es lästig. Amazon hilft nicht dabei, Spreu vom Weizen zu trennen. Es läuft auf Dinge hinaus wie: „Schick uns ein PCAP zum Ping-Problem.“
      Wenn ich Amazon Material schicke und nie eine Antwort bekomme, lerne ich nichts. Ich brauche weder guten noch schlechten Traffic von ihnen, noch gespooften Traffic, der sie angreift.
      Wenn sie mir nicht dabei helfen wollen, ihnen zu helfen, brauche ich das alles nicht. Ich halte mein Leben einfach nur simpel.

  • Wenn ich so etwas sehe, vermisse ich das alte Internet. Es ist wirklich schwer zu erklären, wie großartig das Internet vor der Kommerzialisierung war.
    Die bittere Genugtuung, genau vorhergesehen zu haben, dass es so kommen würde, ist als Ausgleich für das Verlorene bei Weitem nicht genug.

    • Ach ja, klar. Nostalgischer Unsinn. Im Internet ging es von Anfang an ums Geld.

  • AWS ist im Vergleich zu DigitalOcean, OVHcloud, ColoCrossing, Scaleway, Tencent und sogar Google geradezu Pfadfinder-Niveau.
    Besonders DigitalOcean halte ich für einen furchtbaren Fehler, was das Marketing an die „Cybersecurity“-Community angeht.

    • Tatsächlich steht im Beitrag, dass „als Proof of Concept einige kleinere Hosting-Anbieter blockiert“ wurden, und genau das ist DigitalOcean. Aus dem Grund, den du genannt hast.

  • Offenlegung von Interessenkonflikten: AWS ist derzeit mein Arbeitgeber.
    Vielleicht übersehe ich etwas Offensichtliches, aber wenn der Autor glaubt, dass der Ping-Traffic gespooft wurde, wie kann er dann wissen, dass AWS die Quelle ist?

    • AWS hat einen sehr schlechten Ruf als Quelle enormer Mengen an Missbrauch sowie minderwertiger Scraper und Crawler. Schlechte Crawler und echte Angriffe sind oft schwer zu unterscheiden.
      Aus Erfahrung habe ich viel zu oft erlebt, dass überwältigend viel Traffic von AWS kam, und in manchen Fällen lief es auf dieselbe Lösung hinaus: ganz AWS zu blockieren.
      Ich weiß nicht, ob AWS sich nicht darum kümmert oder ob die Reaktion langsam ist. Vielleicht ist auch das Melden zu schwierig.
      Das Offensichtliche, das du übersehen hast, ist Folgendes: AWS ist eine riesige Quelle von „schlechtem“ Traffic, und es ist viel zu schwierig, fehlkonfigurierte Kunden abzustellen, während es für böswillige Akteure viel zu einfach ist, absurde Kapazitäten zu mieten.
      Ich habe kaum je gesehen, dass GCP oder Azure im gleichen Ausmaß Quellen für derart verrückten Traffic sind.