Ablaufdatum 06.04.2021

Am 6. April 2021 lief unerwartet ein Wildcard-TLS-Zertifikat ab. Es ist peinlich, wenn ein Zertifikat abläuft, aber es war uns wichtig, unsere Geschichte hier zu veröffentlichen, in der Hoffnung, dass auch andere unsere Lektion lernen und ihre Systeme verbessern können. Wenn du oder deine Organisation eine Zertifikatsüberwachung nutzt, kann dies als nützliche Mahnung dienen, nach Lücken in einem solchen System zu suchen.

Das abgelaufene Zertifikat wurde von vielen internen Diensten bei Epic verwendet – zu vielen, um genau zu sein. Trotz unserer Bemühungen, das Ablaufdatum unserer Zertifikate zu überwachen, hatten wir nicht alle Bereiche, in denen Zertifikate verwendet werden, vollständig abgedeckt. Nachdem das Zertifikat abgelaufen und erneuert worden war, kam es zu einer Reihe von unerwarteten Ereignissen, die den Ausfall verlängerten. Dazu haben wir in diesem Beitrag mehr Details.

Kernkomponenten wie unsere Identitäts- und Authentifizierungssysteme waren davon betroffen, und diese Dienste sind mit vielen anderen Diensten in unserem gesamten Ökosystem verbunden. Die folgenden Auswirkungen wurden beobachtet bzw. gemeldet:

Die Anmeldung bei Epic-Konten schlug bei allen Produkten fehl, die diese Form der Authentifizierung verwenden, einschließlich Fortnite, Rocket League, Houseparty, Epic Online Services und Epic Games Store.
Unterbrechungen von Live-Spielen bzw. Diensten auf allen Plattformen
Käufe über den Epic Games Launcher waren nicht möglich.
Unerwartetes Verhalten beim Epic Games Launcher: Inhalte wurden nicht geladen und der Offline-Modus funktionierte nicht.
Die Produkt- und Marketing-Websites von Epic Games waren nicht verfügbar oder beeinträchtigt, einschließlich der Unreal Engine-Websites.
Mehrfache Probleme mit internen Tools beeinträchtigten die Möglichkeiten der Epic-Mitarbeiter, Probleme zu lösen oder zu behandeln.

Dieser Beitrag soll einen detaillierten Einblick geben, was passiert ist, was wir gelernt haben und welche Schritte wir in Zukunft unternehmen werden.

Was ist passiert?

Es traten drei große Ereignisabfolgen auf:

Ein abgelaufenes Zertifikat verursachte einen Ausfall bei einem großen Teil der internen Backend-Service-to-Service-Aufrufe und der internen Management-Tools
Unerwartete, signifikante Zunahme des Datenverkehrs zum Epic Games Launcher, unterbrochener Dienst für den Epic Games Launcher und die Funktionen zur Inhalteverteilung
Eine fehlerhafte Version der Epic Games Store-Website, die auf ungültige Artefakte und Assets verwies, wurde als Teil der automatischen Skalierung bereitgestellt und beeinträchtigte das Erlebnis im Epic Games Store

1) Zertifikat abgelaufen

Am 6. April um 12:00 Uhr UTC lief ein TLS-Zertifikat ab. Dieses Zertifikat wurde für einen großen Teil der internen Kommunikation der gesamten Back-End-Plattform von Epic verwendet. Wir verwenden TLS-Verschlüsselung zwischen unseren Back-End-Diensten für dienstübergreifende API-Aufrufe und interne Verwaltungstools. Dieses Zertifikat wird für eine interne DNS-Zone verwendet, die nicht öffentlich zugänglich ist.

Um 12:00 Uhr UTC kam der Datenverkehr zwischen den Back-End-Systemen zum Stillstand. Sechs Minuten später, um 12:06 Uhr UTC, wurde der Vorfall gemeldet und unser Vorfallprozess gestartet. Es wurden viele Warnmeldungen ausgelöst. Zudem ermutigen wir auch immer alle Mitarbeiter, Probleme mit weitreichenden Auswirkungen zu melden, wenn sie diese bemerken. Jeder Vorfall wird von unserem rund um die Uhr aktiven Live Ops-Team gesichtet, das unseren Vorfall-Management-Prozess in Gang setzt. Als die erste interne Meldung eintraf, richtete unser Vorfall-Management-Tool und -Prozess automatisch einen Slack-Kanal ein und die relevanten Beteiligten wurden eingeladen bzw. über den Vorfall benachrichtigt.

Um 12:12 Uhr UTC war der Ablauf des Zertifikats bestätigt, von dem wir annahmen, dass es die Ursache für die Probleme war, und wir begannen mit dem Erneuerungsprozess. Um 12:37 Uhr UTC war das Zertifikat neu ausgestellt und wurde für unsere Back-End-Dienste bereitgestellt. Im Laufe der nächsten fünf bis 15 Minuten begannen die Load Balancer, das neue Zertifikat automatisch an die internen Endpunkte zu verteilen, und unsere Service-to-Service-HTTPS-Aufrufe wurden zusammen mit unseren Verwaltungsschnittstellen wiederhergestellt.

Unser Live Ops-Team, das diesen Vorfall sichtete, verwaltete in dieser Phase auch den Vorfall, indem es mit den Mitarbeitern kommunizierte und die nötigen Personen einsetzte, und um 12:38 Uhr UTC wurde ein Zoom-Anruf gestartet, um diejenigen zu koordinieren, die in Slack zusammengearbeitet hatten. Slack ist zwar ein gutes Kommunikationstool, aber in dringenden Situationen geht nichts über Live-Kommunikation in Echtzeit per Voice- oder Video-Chat. Updates zum Vorfall wurden regelmäßig über unsere Tools und Prozesse an die internen Betroffenen gesendet, um alle über das aktuelle Geschehen auf dem Laufenden zu halten. Zu diesem Zeitpunkt waren über 25 Personen direkt mit dem Problem beschäftigt und arbeiteten daran, während viele weitere es beobachteten: vom Spieler-Support, der Community, Engineering und Production über viele unserer verschiedenen Produkte und Teams hinweg.

Das Diagramm zeigt die Anzahl der Anfragen pro Minute an einen einzelnen Microservice, mit einem Abfall während des Zertifikatsausfalls und einem Anstieg zum Zeitpunkt der vollständigen Wiederherstellung.

Beitragende Faktoren

Die DNS-Zonen für diese interne Service-to-Service-Kommunikation wurden von unseren Zertifikatsüberwachungsdiensten nicht aktiv überwacht. Dies war ein Versäumnis unsererseits. Unsere Zertifikatsüberwachungsdienste beziehen sich auf vollständige DNS-Namespaces, nicht auf einzelne Endpunkte oder Zertifikate, und die Konfiguration für diese interne Zone fehlte. Wir haben diesen Bereich inzwischen zu unserer neueren Überwachungslösung verschoben, die diese Lücke schließt. Bereits vor diesem Vorfall hatten wir auch ein Projekt zur globalen Aktivierung und Konfiguration von AWS Config für unsere vielen Konten begonnen. Mit dieser globalen Konfigurierung können wir problemlos eine AWS-Config-Regel hinzufügen, die einen tiefgegliederten Schutzalarm für den Ablauf von Zertifikaten aktiviert.

Automatische Erneuerungen waren für dieses interne Zertifikat nicht aktiviert, und die dafür notwendigen Arbeiten waren nicht priorisiert worden, als sie Anfang des Jahres identifiziert wurden. Die entsprechenden Systeme und Dienste für eine automatische Verlängerung existieren zwar bereits, aber die Migration zur Nutzung dieser Funktionen war zum Zeitpunkt dieses Vorfalls noch nicht abgeschlossen. Wir waren überzeugt, mit unseren bestehenden Überwachungssystemen vor den Gefahren eines Zertifikatsablaufs besser geschützt zu sein, als es tatsächlich der Fall war. Wir werden daran arbeiten, dieses und andere Zertifikate auf automatische Erneuerung umzustellen. In der Zwischenzeit haben wir eine manuelle Prüfung aller unserer Zertifikate durchgeführt.

Das verwendete Service-to-Service-Wildcard-Zertifikat wurde über Hunderte von verschiedenen Produktionsdiensten hinweg installiert, und daher waren die Auswirkungen sehr weitreichend. Wir verwenden AWS ACM (AWS Certificate Manager) für die Verwaltung dieses Zertifikats. Dadurch konnten wir es schnell erneuern und in Minutenschnelle auf Hunderte von Produktionsdienste anwenden. Das Problem des abgelaufenen Zertifikats hatte nichts mit AWS ACM an sich zu tun, sondern mit der Verwaltung unseres eigenen Zertifikats. Wir werden daran arbeiten, den Anwendungsradius unserer Zertifikate einzugrenzen, und dazu gehört auch die Aktualisierung unserer Prozesse für die Zertifikatsnutzung mit AWS ACM.

2) Signifikante Zunahme des Datenverkehrs beim Epic Games Launcher-Dienst

Während die meisten Dienste sofort nach der Zertifikatserneuerung wiederhergestellt wurden, waren unsere Epic Games Launcher-Dienste weiterhin praktisch nicht verfügbar.

Nach der Ausstellung des Zertifikats stieg die Anzahl der Anfragen um 12:46 Uhr UTC plötzlich sprunghaft an, wodurch der Epic Games Launcher-Dienst überlastet wurde. Dieser Dienst ist ein wichtiger Backend-Dienst, der den Epic Games Launcher-Client unterstützt. Die erhöhte Anfragerate wurde durch eine unerwartete Logik für Wiederholungsversuche in den Clients verursacht, die sonst nur bei Ausnahmen festgestellt wurde. Wir haben im Laufe der Jahre viel an der Ausfallsicherheit des Epic Games Launcher gearbeitet, doch eine derart starke Zunahme von Anfragen kam unerwartet. Unsere Hosts erreichten die Grenzen der Verbindungsüberwachung und in der gesamten Infrastruktur gingen Pakete verloren, was die Wiederherstellung trotz der Steigerung unserer Backend-Anwendungsinfrastruktur auf 250 % zusätzlich erschwerte. Die Epic Games Launcher-Dienste versagten zunehmend bis zum völligen Ausfall. Zur Wiederherstellung mussten wir den Datenverkehr zum Backend erst begrenzen und dann schrittweise wieder steigern, während wir gleichzeitig die maximale Anzahl der Verbindungsüberwachung erhöhten.

Die große Anzahl von Epic Games Launcher-Clients erzeugte Millionen von Verbindungen zum Epic Games Launcher-Backend-Service und verschiedene Komponenten der Epic Games Launcher-Systeme wurden von der Last beeinträchtigt. Wir mussten den Datenverkehr zum Back-End drastisch reduzieren, um die Situation zu stabilisieren. Für diesen Dienst stehen normalerweise Burst-Kapazitäten zur Verfügung, doch diese konnten die bis zu 28-fache Last, die wir zu Beginn des Ausfalls beobachteten, nicht bewältigen.

Das Diagramm zeigt die Anzahl der Anfragen pro Minute an den Load Balancer des Epic Games Launcher-Backends. Der Datenverkehr wuchs zunächst um das 28-fache und betrug beim letzten Burst um 15:12 Uhr UTC das 40-fache der normalen Rate.

Während die Anzahl der Anfragen mehr als das 28-fache des Üblichen betrug, erschöpfte allein die Anzahl der Verbindungen zum Epic Games Launcher-Backend-Dienst den verfügbaren Speicherplatz für die Verbindungsüberwachung und führte so zu Paketverlusten und letztlich zu einer unzureichenden Vernetzung von Backend-Knoten. Unsere Backend-Verbindungslast stieg auf das 3.200-fache unserer normalen Rate. Der Anstieg der TCP-Verbindungen war deutlich höher als die Anzahl der Anfragen.

Das Diagramm zeigt die Anzahl neuer Verbindungen pro Minute zum Load Balancer des Epic Games Launcher-Backends mit einem 3.200-fachen Anstieg der Verbindungen im Vergleich zum normalen Spitzenwert.

Beitragende Faktoren

Das abgelaufene TLS-Zertifikat verursachte einen Ausfall, der ein unerwartetes Verhalten in unserem Launcher-Client auslöste. Unsere Untersuchung ergab, dass unser Client bei Wiederholungsversuchen eine lineare Logik für Wiederholungsversuche anstelle des erwarteten exponentiellen Backoffs verwendete. Ein zusätzlicher unerwarteter Fehler führte dazu, dass Millionen von Epic Games Launcher-Clients ihre Anfragen endlos wiederholten, um eine erfolgreiche Antwort zu erhalten. Diese beiden Fehler in der Client-Installationsbasis verursachten ein unbeabsichtigtes und unvorhergesehenes Aufrufmuster. Wir erlitten praktisch einen DDoS-Angriff durch unsere eigenen Clients und arbeiten derzeit mit Hochdruck daran, diese Fehler im Rahmen eines Epic Games Launcher-Updates zu beheben.

Ein interessanter beitragender Faktor hierbei ist die Länge des ursprünglichen Ausfalls. Mit der Dauer des Ausfalls stieg auch die Wahrscheinlichkeit, dass mehr Clients aufgrund der fehlerhaften Wiederholungslogik kontinuierlich unser Back-End aufrufen würden. Wäre der ursprüngliche Ausfall kürzer gewesen, hätten vermutlich nicht genug Clients das System mit stetigen Wiederholungsversuchen überlastet. Nur ein Ausfall dieser Länge konnte die fehlerhafte Logik aufdecken. Wir werden dies mithilfe von Änderungen am Aufrufmuster beheben.

Unsere Warnmeldung für die Verbindungsüberwachung wurde nicht hinlänglich verstanden. Diese Warnmeldung wurde während des Vorfalls für den Epic Games Launcher-Dienst ausgelöst. Obwohl verschiedene Teams die Bedeutung dieser Warnmeldung kennen, waren die Beschreibung der Warnmeldung und ihre Benachrichtigung nicht eindeutig genug und es war nicht bekannt, dass diese Situation bei allen Verbindungen dieser Hosts, einschließlich der Konnektivität mit einem internen Redis-Cluster, zu Paketverlusten führen würde. Während die Konnektivität mit dem Redis-Cluster beeinträchtigt war, versuchte das Team unter Hochdruck, die Ursache herauszufinden. Die Caching-Mechanismen standen im Verdacht, eine Rolle zu spielen. Später stellte sich heraus, dass Paketverluste der Grund dafür waren, da die Verbindungsüberwachungstabelle bei mehreren hunderttausend aktiven Verbindungen nicht mehr ausreichte. Im weiteren Verlauf des Vorfalls erhöhten wir die maximale Anzahl für die Verbindungsüberwachung auf über eine Million pro Knoten, aber Erweiterungen der Verbindungsüberwachung erfolgen in unserer Infrastruktur nicht augenblicklich, sondern nehmen eine gewisse Zeit in Anspruch. Wir werden unsere Warnmeldung aktualisieren, um deutlicher zu machen, dass ohne eine Behebung größere Netzwerkprobleme verursacht werden.

Die Hochskalierung führte dazu, dass neue Knoten sofort die Grenzen der Verbindungsüberwachung erreichten. Da unsere Infrastruktur mit Verbindungen überlastet war, was zu umfangreichen Paketverlusten führte, mussten wir den Gesamtdatenverkehr zur Infrastruktur reduzieren und den erlaubten Datenverkehr langsam erhöhen. Wir versuchten zunächst, AWS WAF (Web Application Firewall) zu verwenden, um den eingehenden Datenverkehr auf eine Teilmenge zu reduzieren, aber unsere Konfiguration schränkte den Datenverkehr noch nicht genug ein. Das Problem beruhte nicht auf AWS WAF, sondern auf unserem eigenen festgelegten Regelsatz. Aus Zeitgründen verwendeten wir dann die Zielwerte unseres AWS-Load Balancers, um einen Teil des Datenverkehrs umzuleiten. Dies führte zusammen mit der Erhöhung der maximalen Anzahl für die Verbindungsüberwachung schließlich zum Erfolg. Die Verwendung der WAF verzögerte die Wiederherstellung der Epic Games Launcher-Dienste, was jedoch nicht an AWS lag. Wir werden einen Standardprozess entwickeln, um den Datenverkehr in solchen kritischen Situationen mithilfe von AWS WAF, Load Balancer-Zielwerten oder anderen AWS-Technologien umgehend zu entlasten.

3) Ungültige Assets auf der Epic Games Store-Website

Nach der Erneuerung unseres Zertifikats und der Wiederherstellung des Epic Games Launcher-Dienstes gingen wir um 15:12 Uhr UTC dazu über, alle Clients freizugeben, die den Epic Games Store aufriefen. Aufgrund der Dauer des Ausfalls riefen deutlich mehr Clients als normal Inhalte des Epic Games Store auf, der automatisch hochskaliert wurde. Gegen 15:30 Uhr UTC begannen wir mit der Untersuchung etwaiger verbliebener Nachwirkungen.

Zunächst sah alles normal aus, bis wir interne Berichte über Layoutprobleme und Fehler im Store erhielten, die wir bestätigen und reproduzieren konnten. Als wir die Details untersuchten, stellten wir fest, dass der Web-Client (über den ein Benutzer epicgames.com besuchen und mit dem Store interagieren würde) versuchte, eine eindeutige Asset-ID abzurufen, die in unserem CDN nicht vorhanden war. Wir überprüften unsere Container-Versionen, die in der gesamten Infrastruktur eingesetzt werden, und konnten bestätigen, dass alle gleich waren. Wie konnte dieselbe Anwendungsversion dann unterschiedliche Werte für statische Assets ausgeben?

Irgendetwas stimmte hier nicht. Es war ein sehr verwirrender Moment des Vorfalls, und letztendlich stellten sich viele der Signale, die wir zur Verfügung hatten (wie z. B. eingesetzte Versionen), als falsche Signale heraus. Wir konnten die Skalierung des Epic Games Store-Back-Ends mit einer Zunahme von 403-Fehlern auf unserem CDN in Verbindung bringen, was uns dazu veranlasste, die neuen Instanzen genauer zu untersuchen. Als wir den Inhalt lokal auf die neuen Instanzen übertrugen, stellten wir fest, dass der zurückgegebene Inhalt ungültig war. Wir konnten dies auf einen unerwarteten Container-Push zu einem neuen, am Vortag durchgeführten CI/CD-Workflow zurückführen, der ansonsten nichts mit den Geschehnissen dieses Vorfalls zu tun hatte. Diese Ergebnisse waren immer noch überraschend, aber nachdem wir dies schließlich entdeckt hatten, konnten wir die Container-Version schnell zurücksetzen, die ungültigen Instanzen beenden und den Datenverkehr wiederherstellen.

Dieses Problem hätte bei jeder großen Hochskalierung in diesem Zeitraum auftreten können, aber da wir normalerweise einen großen Toleranzbereich in der Infrastruktur haben, trat dieses Problem erst beim großen Hochskalieren des Epic Games Store durch den Datenverkehr des Epic Games Launcher auf.

Beitragende Faktoren

Der Ausfall des Zertifikats führte zu Problemen mit dem Epic Games Launcher, die nach der Wiederherstellung zu einer Flut von Anfragen an den Epic Games Store führten, die wiederum zu einem Hochskalieren der Epic Games Store-Systeme führten. Das wird erwartet und ist begrüßenswert.

Unsere Signale und Daten über den Stand der Versionen in unserer Anwendungsinfrastruktur verleiteten uns fälschlicherweise zu der Annahme, dass unser Infrastrukturneinsatz einheitlich sei. Wir haben unser Versionierungsschema geändert, um diese Fehldiagnose in Zukunft zu vermeiden.

Bei einer kürzlichen Änderung an der CI/CD-Pipeline für den Epic Games Store kam es zu einer Fehlkonfiguration, die das Anwendungsartefakt unerwartet aktualisierte. Dies wurde mit einer Änderung an unserer CI/CD-Pipeline korrigiert, wodurch die unerwarteten Änderungen rückgängig gemacht wurden. Unsere Änderung des Versionsschemas wird verhindern, dass dies erneut passiert.

Zeitlicher Ablauf

12:00 Uhr UTC - Internes Zertifikat abgelaufen
12:06 Uhr UTC - Vorfall gemeldet und Vorfallmanagement gestartet
12:15 Uhr UTC - Erste Kundennachrichten vorbereitet
12:21 Uhr UTC - Bestätigung mehrerer großer Serviceausfälle durch mehrere Teams
12:25 Uhr UTC - Bestätigung, dass der Prozess der Neuausstellung des Zertifikats begonnen hat
12:37 Uhr UTC - Das Zertifikat wird als neu ausgestellt bestätigt
12:46 Uhr UTC - Bestätigte Wiederherstellung einiger Dienste
12:54 Uhr UTC - Verbindungsüberwachung als Problem für den Epic Games Launcher-Dienst entdeckt
13:41 Uhr UTC - Epic Games Launcher-Dienstknoten neu gestartet
15:05 Uhr UTC - Grenzwerte für die Verbindungsüberwachung für den Epic Games Launcher-Dienst erhöht
15:12 Uhr UTC - Erste Anzeichen einer Wiederherstellung des Epic Games Launcher-Dienstes
15:34 Uhr UTC - Epic Games Store-Webservice hochskaliert
15:59 Uhr UTC - Erste Berichte über fehlende Assets im Epic Games Store
16:57 Uhr UTC - Problem der unterschiedlichen Versionen des Epic Games Store-Webservice entdeckt
17:22 Uhr UTC - Version des Epic Games Store-Webservice korrigiert
17:35 Uhr UTC - Vollständige Wiederherstellung

Was sind die nächsten Schritte?

In den obigen Abschnitten haben wir die Umstände behandelt, die zu den unerwarteten Ereignissen und schließlich zum Ausfall am 6. April führten. Wir haben unsere nächsten Schritte im Zusammenhang mit den beitragenden Faktoren erwähnt, werden sie aber hier noch einmal wiederholen.

Die Probleme sind nicht auf eine einzelne Ursache zurückzuführen. Eine Vielzahl von Faktoren, sowohl technologischer als auch organisatorischer Art, trugen zu den Ereignissen bei. Der Umfang und die Länge des Ausfalls haben uns geholfen, nicht nur eindeutige Fehler in unseren Systemen zu erkennen, an deren Behebung wir arbeiten werden, sondern auch zuvor unhinterfragte Annahmen in einigen unserer internen Prozesse, insbesondere bei der Zertifikatsverwaltung.

Wir haben diesen Bereich sofort mit unserem neueren Zertifikatsüberwachungssystem abgedeckt und alle vorhandenen bekannten Zertifikate überprüft und werden uns weitere Lücken in unserer Zertifikatsüberwachung genauer ansehen und weitere zukunftssichernde Maßnahmen hinzufügen, wie z. B. die AWS Config-Überwachung für alle AWS ACM-basierten Zertifikate. Wir werden auch daran arbeiten, den Anwendungsradius jedes einzelnen Zertifikats zu reduzieren.

Wir werden die Aufrufmuster unseres Epic Games Launcher-Clients genauer unter die Lupe nehmen und in diesem Zusammenhang zeitnah einige der identifizierten Fehler beheben sowie unsere Fähigkeit verbessern, auf Situationen mit deutlich erhöhtem Datenverkehr zu reagieren. Mit der permanenten Erweiterung unserer Verbindungsüberwachungstabellen für diese Infrastruktur sollten wir in der Lage sein, eine ähnliche Menge an Last ohne größere Paketverluste zu bewältigen. Wenn man große Infrastrukturen betreibt, kann dies eine gute Erinnerung sein, die Grenzen der Verbindungsüberwachungstabelle und die Alarmierung zu überprüfen, wenn man diese Netzfilterfunktion verwendet. Außerdem dienen wir gerne als nützliche Mahnung, die Logik für Wiederholungsversuche der Clients zu überprüfen und insbesondere, wie sich alle Clients gemeinsam nach einem langen Ausfall verhalten könnten.

Für den Epic Games Store haben wir einen Fix implementiert, der das Ändern eines Live-Anwendungsobjekts verhindern sollte. In diesem Zusammenhang haben wir auch einen Fehler in unserer Asset-Generierung entdeckt und behoben.

Wir hoffen, dass dieser Vorfallsbericht zusätzliche Details zu den Ereignissen vom 6. April liefert. Wir hoffen, dass diese Details unsere Lernerfahrungen und Verbesserungen beleuchten und anderen helfen, ähnliche Probleme zu vermeiden.

Mach mit!

Dieser Beitrag wurde von unserem Reliability Engineering-Team mit viel Hilfe der vielen anderen großartigen Engineering-Teams hier bei Epic verfasst.

Interessierst du dich für diese Art von Problemen? Hast du eine Leidenschaft für Spiele und Spieldienste? Epic ist immer auf der Suche nach großartigen Talenten und wir stellen weltweit in allen Qualifikationsbereichen ein. Wenn du nach unseren offenen Stellen suchst, besuche unsere Epic Games-Stellenangebote.

Hat dir dieser Beitrag geholfen oder fandest du ihn interessant? Lass es uns unter public-incident-response@epicgames.com wissen.