Normale Ansicht

Ältere BeiträgeHaupt-Feeds

DDoS-Report zeigt 65 Prozent mehr Angriffe als im 2. Quartal

27. Oktober 2023 um 08:56

Cloudflare hat seinen quartalsweise erscheinenden DDoS-Report veröffentlicht. Er zeigt die weltweiten DDoS-Angriffstrends im dritten Quartal, die gegenüber Q2 stark angestiegen seien, so Cloudflare.

Die Angriffe auf HTTP/2 hätten dabei hauptsächlich zu dem Gesamtanstieg des HTTP-DDoS-Angriffe im dritten Quartal beigetragen, heißt es im Report. Unter anderem sei im dritten Quartal der bislang größte Angriff aller Zeiten mit 201 Millionen rps (Anfragen pro Sekunde) gemessen worden. Cloudflare habe aber auch weitere hyper-volumetrischen HTTP-DDoS-Angriffe verhindert, von denen 89 mehr als 100 Millionen Anfragen pro Sekunde erreicht hätten.

Die Glücksspiel- und Glücksspielunternehmen seien dabei eines der Hauptziele gewesen und hätten das größte Volumen an HTTP-DDoS-Angriffsdatenverkehr im Vergleich zu anderen Branchen auf sich gezogen. Damit habe das Glücksspiel als Angriffsziel die Branche der Kryptowährung aus dem letzten Quartal überholt. Der Report ist online abrufbar.

Cloudflare betriebt nach eigene Angaben eines der größten Netzwerke der Welt, das mehr als 300 Städte in über 100 Ländern umfasse. Über dieses Netz bediene man in der Spitze über 64 Millionen HTTP-Anfragen pro Sekunde und etwa 2,3 Milliarden DNS-Anfragen pro Tag.

Die englische Version des vollständigen DDoS-Reports finden Sie hier.

Der Beitrag DDoS-Report zeigt 65 Prozent mehr Angriffe als im 2. Quartal erschien zuerst auf Linux-Magazin.

Firefox 114 verbessert DNS-over-HTTPS-Verwaltung

09. Juni 2023 um 07:14

Der neuen Version 114 des Browsers Firefox hat Mozilla einige nützliche kleine Änderungen spendiert. So lässt sich gezielter nach Lesezeichen und in der lokalen History suchen. Die Liste mit den Erweiterungen darf man zudem umsortieren.

Diese Liste öffnet sich, sobald man auf das entsprechende Symbol in der Adressleiste klickt. In ihr zeigt Firefox sämtliche Erweiterungen an, sortierte diese aber bislang selbst.

Wer die Schaltfläche für die Lesezeichen aktiviert hat, kann über das dahinter wartende Menü direkt nach Lesezeichen suchen. Analog erlauben die Chronik-, Bibliotheks- und Anwendungsmenüs schnell eine Seite in der Chronik aufzuspüren.

Weitere Änderungen betreffen die Sicherheit. Zunächst unterstützt Firefox 114 die Authentifizierung über USB-Geräte, die nach dem FIDO2/WebAuthn-Standard arbeiten. Des Weiteren sind die DNS-over-HTTPS-Einstellungen in die Gruppe „Datenschutz & Sicherheit“ gerutscht. Dort lassen sich auch die Ausnahmen für DNS over HTTPS verwalten.

Der Beitrag Firefox 114 verbessert DNS-over-HTTPS-Verwaltung erschien zuerst auf Linux-Magazin.

Fallstricke beim Einsatz von NTP und verschlüsseltem DNS

30. Dezember 2022 um 20:45

Viele der Technologien, die wir heutzutage einsetzen, haben eine lange Geschichte hinter sich. Moderne Ansätze, sie nachzurüsten, können in bestimmten Szenarien jedoch unangenehme Auswirkungen haben. Ein kleines Beispiel möchte ich euch heute vorstellen.

Craig Younkins hat in seinem Blog auf Medium ein kurzes Szenario beschrieben, das verschlüsseltes DNS (DoH/DoT) und NTP involviert. Normalerweise gibt es bei so einem Setup wenig Probleme: der Client synchronisiert seine Zeit über NTP, kann Abweichungen ausgleichen und seine DNS-Anfragen über TLS-verschlüsselte Verbindungen abwickeln. Dabei hat der Client jederzeit seine vertrauenswürdigen Zertifikate lokal gespeichert, ebenso die Standardserver für NTP, die üblicherweise durch einen Hostname nach dem Muster *.pool.ntp.org adressiert werden.

Das Problem

Der Fallstrick: vergisst der Client die Zeit komplett, kann er in einem Deadlock landen und gegebenenfalls die Zeit nicht mehr synchronisieren. So ein Szenario kann auftreten, wenn ein System ausgeschaltet wurde und keine Real-Time-Clock in der Hardware verbaut wurde, die über eine eigene Batterieversorgung (i. d. R. Knopfzelle) verfügt. Bei einigen günstigen Routern bzw. IoT-Geräten wie dem Raspberry Pi ist das der Fall.

Findet das System keinen Anhaltspunkt über die aktuelle Zeit, so startet es, je nach Implementierung, meist beim Unix-Timestamp 1 bzw. am 01.01.1970. Dies kann jedoch in Verbindung mit TLS eine gefährliche Wirkung entfalten, da für die Zertifikatsvalidierung auf das aktuelle Datum zurückgegriffen wird – schließlich verfügen die meisten Zertifikate über einen festen Gültigkeitszeitraum, der nur wenige Monate umfasst.

Das Ergebnis: alle mit TLS abgewickelten DNS-Anfragen über die NTP-Server schlagen fehl. Dabei ist hervorzuheben, dass NTP selber unverschlüsselt weiterhin abläuft, es können lediglich die IP-Adressen der Server nicht ermittelt werden.

Lösungen

Damit soetwas nicht passiert, können Administratoren auf verschiedene Art und Weise vorbeugen. Eine erste Möglichkeit wäre, wie im Artikel beschrieben, das Hinterlegen von IP-Adressen im NTP-Client. Damit umgeht man DoH/DoT und kann direkt mit der NTP-Synchronisation fortfahren. Nachteil dieser Variante ist jedoch, dass es einerseits nur wenige NTP-Server mit wirklich statischen Adressen gibt (einer der wenigen Anbieter ist z. B. die NIST) und andererseits NTP generell eher auf Hostnames arbeitet, um z. B. einen Lastausgleich sicherzustellen.

Die zweite Variante wäre der Einsatz spezieller DHCP-Optionen wie Option 42, mit der beim Bezug der Netzwerkkonfiguration auch durch den DHCP-Server bestimmte IPv4-Adressen empfohlen werden können. In der Regel handelt es sich um lokale IPv4-Adressen, wenn lokal ein eigener NTP-Server betrieben wird, der seine Zeit mit höherrangigen Servern wiederum synchronisiert. DHCPv6 verfügt mit Option 56 über ein Äquivalent. (Q, RFC 2132 sec. 8.3., RFC 5908)

Es gibt allerdings auch spannendere Methoden: so ist der Ansatz von tlsdate, die Zeit über den TLS-Handshake von Internetdiensten wie Google oder Wikipedia zu extrahieren. Darüber hinaus wird momentan bei der IETF die Entwicklung von roughtime vorangetrieben, das hierfür ein eigenes kryptographisches Protokoll einsetzt. (Q, draft-ietf-ntp-roughtime-07, Artikel von Cloudflare)

Wer ein Dateisystem wie ext4 nutzt, findet darüber hinaus im Superblock aus dem vergangenen Mount hilfreiche Zeitangaben. Diese mount time und write time werden nämlich in der Regel bei jedem Mount und Schreibvorgang gesetzt und können als Anhaltspunkt für die Systemzeit des vergangenen Starts dienen - genug, um bei regelmäßig verwendeten Systemen immerhin die DoH-Anfrage für die initiale NTP-Namensauflösung abzuwickeln. (Q)

Fazit

Verschiedene komplexe Komponenten wie DoH/DoT und NTP können bei bestimmten Randbedingungen zu Situationen führen, die man bei der Erstkonfiguration vermutlich nicht vor Augen hatte. Wer jedoch mit dafür anfälligen Systemen ohne Real-Time-Clock arbeitet, kann auf verschiedene Strategien zur Abhilfe setzen: einerseits können Anhaltspunkte für die Zeit aus dem vergangenen Start gesucht werden oder zunehmend Protokolle genutzt werden, die genau dieses Problem adressieren.

❌
❌