Der Umfang von DDoS-Angriffen hat in den letzten Jahren massiv zugenommen, die Reaktionen der Branche auf solche Angriffe aber auch. In diesem Blogpost werfen wir einen Blick darauf, was Branchenverbände und ein modernes CDN tun können, um Ihren Traffic zu schützen.

Das TLS Support Team unterstützt Kunden bei der Verwaltung von Zertifikaten – ganz gleich, ob es sich dabei um eines oder Tausende handelt. Nachdem unser Team zahlreichen Kunden geholfen habt, ihre DNS- und TLS-Konfigurationen an ihre Bedürfnisse anzupassen, kann es Ihnen fünf Best Practices empfehlen.

Layer-7-Angriffe, die auf Anwendungen abzielen und Anfragen versenden, die zur Überlastung Ihrer Origin-Server könnten, versuchen oft, sich unter den anderen Netzwerk-Traffic zu mischen und erfordern gezieltere Gegenmaßnahmen als Layer-3- und Layer-4-Angriffe. Hier sind fünf Best Practices, um sich auf solche Angriffe vorzubereiten.

Wir wissen, dass die Innovationen von Signal Sciences auch bereits im Gartner Magic Quadrant for Web Application Firewalls 2019 gewürdigt wurden. Und genau diese Art von Innovationen sind der Grund, warum wir so begeistert sind, dass Fastly und Signal Sciences jetzt am selben Strang ziehen. 

Die größte Kategorie schwer vorhersehbarer Schwachstellen bei der Gestaltung von Sicherheitslösungen bilden Side-Channel-Angriffe. In diesem Blogpost beschäftigen wir uns mit einigen der grundlegenderen und ausgefalleneren Side-Channel-Angriffe, die das Sicherheitsbewusstsein im Laufe der Jahre geprägt haben.

Die Übernahme von Signal Sciences durch Fastly – und damit ein riesiger Schritt in Richtung unserer Vision von moderner, einheitlicher Webanwendungs- und API-Sicherheit – ist geschafft. Auf unserem gemeinsamen Weg zur Entwicklung einer besonders sicheren, performancestarken Plattform lassen wir uns von unserem Leitgedanken inspirieren, Developern die Zügel in die Hand zu geben und zusammen mit ihnen ganz neue Möglichkeiten zu erschließen.

Die Einhaltung der WAF Best Practices ist unerlässlich, um die Sicherheit Ihres Unternehmens und Ihrer Kunden zu gewährleisten. Erfahren Sie mehr über neue Vorschriften und unsere Sicherheitstipps.

Am 29. Juli um 00:00 Uhr UTC wurde Fastly von einem Kunden (Kunde X) gemeldet, dass eine einzelne Protokollzeile, die für einen anderen Kunden (Kunde Y) bestimmt war, im Protokollsystem des Kunden X gelandet war. Fastly begann sofort mit der Untersuchung und stellte fest, dass bei einem komplexen Zusammentreffen von Umständen eine Log-Zeile an einen verkehrten Logging-Service geleitet werden kann. Wir konnten die Ursache auf einen Fehler in der Programmlogik zurückführen, die von Fastly zur Verbesserung der Leistung im April 2012 eingeführt worden war. Dieser einmalige Bericht eines Kunden ist der einzige Fall in acht Jahren, der Fastly bekannt ist, in dem alle erforderlichen Umstände zur gleichen Zeit zusammen kamen.

Sicherheit war schon immer ein Teil von Fastlys DNA. Das gilt nicht nur für unsere Produkte, sondern auch für unsere Vision als vertrauenswürdige und sichere moderne Plattform. Wir freuen uns, Ihnen heute mitteilen zu können, dass wir die Absicht haben, Signal Sciences zu erwerben.

Mike Johnson, CISO bei Fastly, und Ben Kero, Senior DevOps Engineer bei Brave Software, geben praktische Ratschläge, wie Sie ganzheitlichere Sicherheitspraktiken in Ihrer CI/CD-Pipeline verankern können.

Fastly wurde am 21. Mai 2020 um 13:30 Uhr UTC über das Problem informiert. Fastly hat daraufhin sofort eine Untersuchung eingeleitet und identifiziert, welche Origin-Server mit einer Testportnummer in der Redirect-Antwort antworteten, um nach der Schwachstelle und möglichen Lösungen zu suchen. Nach der Untersuchung benachrichtigte Fastly potenziell betroffene Kunden erstmals am 15. Juli 2020 um 04:30 Uhr UTC. Diese Schwachstelle ist eine Variante einer [bereits früher gemeldeten Schwachstelle](/security-advisories/cache-poisoning-leveraging-various-x-headers) und letztlich das Ergebnis der Zusammensetzung von cachefähigen Origin-Antworten auf der Basis von nutzerdefinierten Daten. Das Problem tritt auf, wenn ein Angreifer eine HTTPS-Anfrage stellt und im Host-Header eine Portnummer angibt, die eigentlich für keine Services verwendet wird. Es ist möglich, eine Ressource so zu cachen, dass zukünftige Requests nicht mehr korrekt bearbeitet werden können.

Wenn Sie Webanwendungen ausschließlich anhand Ihrer Sicherheitsanforderungen evaluieren, verpassen Sie möglicherweise eine der wichtigsten Chancen, Ihre Secure DevOps-Kultur erfolgreich entwicklerzentriert auszubauen.

Fastly hat eine lange Tradition in Sachen Sicherheit, die weit über unser Portfolio an Web-App- und API-Sicherheitsprodukten hinausgeht. Unsere Philosophie, Entwicklern die Zügel in die Hand zu geben, unser Fokus auf die Community und unsere werteorientierte Kultur tragen alle auf wichtige Weise zu unserer Sicherheits-DNA bei. Wie, verraten wir Ihnen in diesem Post.

TLS 1.3 ist für Fastly Kunden jetzt verfügbar. Die neueste Version des TLS-Protokolls, TLS 1.3, wurde entwickelt, um die Performance und Sicherheit des über HTTPS ausgelieferten Traffics zu verbessern.

Am 11. November 2019 um 21:57 Uhr UTC hat Fastly einen neuen Build seiner HTTP/2-Terminierungssoftware auf zwei Fastly Cache-Servern im Rechenzentrum in Minneapolis-St.Paul (STP) bereitgestellt. Diese Build enthielt einen Verarbeitungsfehler, der die Wiederverwendung von Verbindungen zwischen internen Fastly Systemen betraf (unabhängig vom HTTP/2-Multiplexing) und dazu führte, dass einige eingehende HTTP/2-Anfragen für Services von Fastly Kunden eventuell fälschlicherweise an eine Gruppe von bis zu 20 verschiedenen Services und Origin-Servern von Fastly Kunden weitergeleitet wurden. Dies führte dazu, dass einige Client-Anfragedaten an verkehrte Origin-Server von Kunden gesendet und eine Antwort von diesen verkehrten Origin-Servern zurückgesendet wurde. Die Kunden, auf deren Origin-Servern diese Anfragen fälschlicherweise eingingen, haben diese verkehrt weitergeleiteten Anfragedaten möglicherweise geloggt. Fastly wurde erstmals am 12. November 2019 um 23:07 Uhr UTC von einem Kunden über einen Client-Fehler informiert. Am 13. November 2019, um 00:50 Uhr UTC, wurde der gesamte Kunden-Traffic des betroffenen Rechenzentrums umgeleitet. Fastly hat sofort eine Untersuchung eingeleitet und am 14. November 2019 um 00:31 Uhr UTC das Vorhandensein von falsch gerouteten Anfragedaten in den Logs eines Kunden bestätigt. Wir schätzen, dass dieser Fehler in dem Zeitraum von 27 Stunden 0,00016 % des weltweiten Anfrage-Traffics betraf. Es ist unwahrscheinlich, dass die betroffenen Client-Anfragen von außerhalb Nordamerikas kamen. Da Fastly keine Kundenlogdaten speichert, können wir nicht mit Sicherheit sagen, ob eine betroffene Anfrage falsch weitergeleitet wurde.

Am Donnerstag, dem 9. August, wurden auf der „Black Hat USA 2018“-Konferenz Forschungsergebnisse zu Cache-Poisoning-Angriffen auf Websites veröffentlicht, die hinter einer Caching-Infrastruktur betrieben werden. Bei diesen Angriffen konnten Angreifer beliebige Inhalte in den Cache eines Opfers injizieren. Fastly Servicekonfigurationen, die die Interaktion zwischen Headern, die Backends zur Auswahl von Inhalten verwenden, nicht berücksichtigen, können anfällig sein. Dieses Risiko kann durch einen VCL-Patch oder durch die Änderung von Backend-Konfigurationen komplett abgewehrt werden.

Am 6. August 2018 wurde eine Schwachstelle in der Linux-Kernel-TCP-Implementierung, genannt SegmentSmack, öffentlich bekannt gegeben. Diese Schwachstelle ermöglichte es einem entfernten Angreifer, einen Denial-of-Service-Angriff auf einen Zielserver auszuführen, indem er einfach eine TCP-Verbindung zum Server herstellte und bestimmte Segmente über diese Verbindung sendete. Wir haben bereits vor dieser Bekanntmachung mit der Sicherheitsgemeinschaft zusammengearbeitet, um diese Schwachstelle in unseren Edge-Netzwerken zu beheben. Sie stellen für Fastly Kunden keine Gefahr dar.

Am Mittwoch, den 3\. Januar, wurden Untersuchungen zu einer Art von Schwachstellen veröffentlicht, die bestimmte Prozessoren betreffen. Diese Schwachstellen könnten es einem Nutzer, der in der Lage ist, Code auf einem System ausführen, ermöglichen, über Sicherheitsgrenzen hinweg unbefugten Zugriff auf Informationen zu erlangen. Fastly hat eine erste Analyse dieser Schwachstellen abgeschlossen und glaubt nicht, dass sie eine unmittelbare Bedrohung für Fastly Kunden darstellen.

Vom 31\. August bis zum 4\. November setzte Fastly eine Version von Varnish ein, die einen Sicherheitsfehler enthielt, der in einem begrenzten und nicht standardisierten Konfigurationssatz Anfragetexte an Origin\-Server anderer Kunden weitergab. In diesen Fällen wäre ein Anfragetext, der an den Service eines betroffenen Fastly Kunden geschickt wurde, in einer fehlerhaften Anfrage an den Origin\-Server eines anderen Kunden enthalten gewesen, die möglicherweise in den Zugriffslogs dieses Origin\-Webservers aufgezeichnet wurde. Fastly hat eine umfassende Bewertung durchgeführt, um herauszufinden, welche Kunden am ehesten von diesem Problem betroffen sind. Diese Kunden wurden direkt von Fastly Customer Engineering kontaktiert.

Am Montag, dem 14. November 2016, veröffentlichten Sicherheitsexperten einen Artikel mit dem Titel „Measuring the Security Harm of TLS Crypto Shortcuts“. Neben anderen Erkenntnissen über die TLS-Implementierung an mehreren Standorten, wurde in dem Artikel festgestellt, dass Fastly die TLS-Sitzungstickets nicht oft wechselt, was die Wirksamkeit der Forward Secrecy einschränkt. Obwohl Fastly nicht direkt von den Forschern kontaktiert wurde, war es schon vorher auf das Problem aufmerksam gemacht worden und die Schwachstelle wurde am Freitag, den 11. November, korrigiert. Kunden brauchen nichts zu unternehmen, um von dem Fix zu profitieren.