ARTEMIS und die Minute zwischen einer BGP-Warnung und einer sicheren Reaktion

Zusammenfassung

• ARTEMIS ist ein von Betreibern eingesetztes Open-Source-System, das aktuelle BGP-Beobachtungen mit der lokalen Routing-Absicht vergleicht und Netzen damit Kontext liefert, den öffentliche Kollektoren allein nicht bereitstellen können.
• Die Forschung von FORTH und CAIDA aus dem Jahr 2018 berichtete unter den getesteten Bedingungen von einer Erkennung innerhalb von Sekunden und einer Neutralisierung innerhalb einer Minute; das Ergebnis ist keine allgemeine Garantie für den Produktivbetrieb.
• Die Abwehr kann spezifischere Routen ankündigen oder individuelle Abläufe auslösen. Filter, veraltete Richtlinien, unvollständige Sichtbarkeit und weitreichende Zugangsdaten können eine schnelle Reaktion jedoch zu einem zweiten Vorfall machen.
• Das Projekt ist heute auf disziplinierte Veröffentlichungen, glaubwürdige Einsatzbelege und eine transparente Abgrenzung zu Code BGP angewiesen. Dessen kommerzielle Wartung kann die offene Software erhalten, ohne ihre Forschungsgeschichte zu ersetzen.

Eine reale Routenänderung zeigte, warum Sekunden erst der Anfang sind

Dem Jahresbericht von CAIDA für 2019 zufolge erkannte ARTEMIS innerhalb von Sekunden eine reale Routenübernahme, die ein /30-Präfix von Internet2 betraf. Das Ereignis ist bedeutsam, weil es die Evidenz über synthetische, von den Forschenden entworfene Ankündigungen hinausführt. In einem am Einsatz beteiligten Netz änderte sich eine reale Route, und das System erkannte die Abweichung schnell genug, um eine Untersuchung zu unterstützen.

Der Bericht belegt keine allgemeingültige Verteilung der Erkennungszeiten. Ein /30 ist ein bestimmtes Präfix in einem bestimmten Routing-Kontext, das über die für diesen Einsatz verfügbaren Datenquellen beobachtet wurde. Ein anderes Ereignis kann sich anders ausbreiten, kürzer andauern oder außerhalb der verbundenen Kollektoren bleiben. Der Bericht beweist für sich genommen auch weder eine böswillige Absicht noch sämtliche Auswirkungen auf der Datenebene. Die belastbare Schlussfolgerung lautet, dass ARTEMIS während des Einsatzprogramms von CAIDA ein gemeldetes reales Ereignis innerhalb von Sekunden erkannte.

Fallstudien sind gerade dann wertvoll, wenn ihre Grenzen erhalten bleiben. Sie zeigen, wie sich die Software bei tatsächlichen Änderungen verhält, wie Betreiber die Warnung erhalten und welche Belege anschließend verfügbar sind. Mehr Vorfallsaufzeichnungen, darunter Fehlalarme, übersehene Ereignisse und Ergebnisse von Gegenmaßnahmen, würden die Reife für den Produktivbetrieb stärker belegen als eine weitere plakative Zeitangabe.

Eine BGP-Warnung kann innerhalb von Sekunden eintreffen und dennoch die wichtigsten Fragen offenlassen. Ein Routenkollektor kann zeigen, dass ein unbekanntes autonomes System ein Präfix angekündigt hat oder dass eine spezifischere Route erschienen ist und sich auszubreiten beginnt. Diese Evidenz zeigt dem Betreiber, dass die Steuerungsebene nicht mehr dem erwarteten Muster entspricht.

Sie belegt für sich genommen jedoch nicht, wer die Änderung vorgenommen hat, ob sie versehentlich erfolgte, ob der Datenverkehr dem neuen Pfad folgte, ob Nutzer geschädigt wurden oder welche Reaktion den Dienst wiederherstellt, ohne ein weiteres Problem zu verursachen.

ARTEMIS wurde für diese Lücke zwischen Erkennung und Handlung entwickelt. Der Name steht für Automatic and Real-Time dEtection and MItigation System, doch das großgeschriebene Akronym sollte nicht vom Betriebsmodell ablenken. ARTEMIS ist kein zentraler Dienst, der das gesamte Internet überwacht und fremde Netze aus der Ferne repariert. Eine Organisation setzt die Software in einer von ihr kontrollierten Infrastruktur ein, definiert den als legitim betrachteten Routing-Zustand, bindet öffentliche und private Beobachtungen an und entscheidet, wie weit das System bei Abweichungen von der Richtlinie gehen darf.

Das Versprechen des Projekts ist Geschwindigkeit mit Kontext; seine Einschränkung besteht darin, dass Kontext und Befugnis lokal sind.

ARTEMIS ähnelt daher weniger einer Internetpolizei als einem betreibereigenen Instrument für den Kontrollraum. Es kann Evidenz ordnen, den Zeitaufwand für die Suche in Routenaktualisierungen verringern und eine zuvor abgestimmte Reaktion vorbereiten. Es kann dem Betreiber die Beurteilung nicht abnehmen. Die endgültige Entscheidung kann das globale Routing, Beziehungen zu Upstream-Anbietern und den Kundenverkehr betreffen. Die Qualität der Reaktion hängt deshalb ebenso von Menschen, Konfigurationen und eingeübten Befugnissen ab wie vom Detektor.

BGP kann Erreichbarkeit vermitteln, bevor es Befugnis nachweisen kann

Das Border Gateway Protocol ermöglicht unabhängig betriebenen Netzen, Informationen zur Erreichbarkeit auszutauschen und lokale Richtlinien anzuwenden. Ein autonomes System kündigt an, dass es eine Gruppe von IP-Präfixen erreichen kann; benachbarte Netze entscheiden, ob sie diese Routen akzeptieren, bevorzugen und weitergeben. Diese Struktur machte das Internet über Organisationen hinweg skalierbar, die keinen gemeinsamen Controller verwenden. Das ursprüngliche Protokoll versieht jedoch nicht jede Aussage über Ursprung oder Pfad mit einem kryptografischen Nachweis.

Ein fehlerhafter Export, eine veraltete Konfiguration oder eine absichtliche Ankündigung kann daher eine Route einführen, die nicht existieren sollte.

Die Routenauswahl kann eine fehlerhafte Ankündigung attraktiv machen. Wenn zwei Routen dieselbe Präfixlänge abdecken, wenden Netze je nach Betreiber unterschiedliche Richtlinien und Pfadauswahlregeln an. Kündigt ein Angreifer oder ein irrtümlich handelndes Netz ein spezifischeres Unterpräfix an, leitet der normale Abgleich nach dem längsten Präfix den Verkehr in der Regel zur enger gefassten Route, sofern diese akzeptiert wird. Dieser Mechanismus ist keine besondere Angriffsfunktion, sondern die gewöhnliche Regel, nach der Router das präziseste Ziel auswählen.

Deshalb kann eine scheinbar kleine Ankündigung den Verkehr schnell umleiten, selbst wenn das legitime Aggregat weiterhin sichtbar ist.

Der Begriff „Hijack“ ist eine nützliche Kurzform, kann aber eine Absicht unterstellen, die aus den Routing-Nachrichten nicht hervorgeht. Ein nicht autorisierter Ursprung kann böswillig oder versehentlich sein oder aus einer legitimen geschäftlichen Änderung entstehen, die noch nicht in der Überwachungsrichtlinie abgebildet wurde. Ein manipulierter Pfad kann zum Abfangen von Verkehr dienen, doch eine Aktualisierung der Steuerungsebene beweist keine Abfanghandlung.

ARTEMIS funktioniert daher am besten, wenn es eine Warnung als Abweichung zwischen beobachtetem und beabsichtigtem Routing behandelt und Zuordnung sowie Auswirkungen einem umfassenderen Vorfallsprozess überlässt.

Ein Ereignis mit identischem Präfix konkurriert bei gleicher Präfixlänge mit der legitimen Route. Seine Reichweite hängt von den Richtlinien und Pfadentscheidungen der Netze ab, die beide Ankündigungen erhalten. Einige Teile des Internets können die unerwartete Route bevorzugen, während andere weiterhin den legitimen Ursprung verwenden. Das Ergebnis können partielle Erreichbarkeit, regionale Unterschiede und eine verwirrende Mischung aus Erfolg und Ausfall statt eines eindeutigen Totalausfalls sein. Die Erkennung muss daher nicht nur beachten, ob eine Route existiert, sondern auch, wo und wie sie sich ausbreitet.

Ein Unterpräfix-Ereignis hat häufig eine direktere Anziehungskraft, weil der Abgleich nach dem längsten Präfix der engeren Route Vorrang gibt. Kündigt ein Netz normalerweise ein /20 an und kündigt ein anderer Ursprung darin ein /24 an, senden Router, die das /24 akzeptieren, den Verkehr für diese Adressen im Allgemeinen zum Unterpräfix. Deaggregation ist zugleich eine verbreitete Abwehr: Der legitime Betreiber kündigt gleich spezifische oder noch spezifischere Routen an, um die Präferenz zurückzugewinnen.

Diese Abwehr stößt jedoch an eine feste Grenze, weil viele Netze IPv4-Routen mit einer Länge über /24 und IPv6-Routen mit einer Länge über /48 filtern. Ein Betreiber, der bereits Präfixe dieser Länge ankündigt, verfügt möglicherweise über keine weltweit akzeptierte engere Route.

ARTEMIS berücksichtigt außerdem Squatting und ausgewählte Richtlinienverstöße, darunter ein in den Projektunterlagen beschriebenes No-Export-Muster. Diese Kategorien sind relevant, weil Routing-Vorfälle nicht darauf beschränkt sind, dass ein Fremder das Präfix eines Opfers als Ursprung ankündigt. Eine Route kann einen autorisierten Ursprung besitzen und dennoch über eine unerwartete Beziehung exportiert werden. Ein Überwachungssystem benötigt genügend Richtlinienkontext, um solche Fälle zu unterscheiden, ohne vorzugeben, dass BGP-Daten sämtliche privaten Vereinbarungen zwischen Netzen offenlegen.

ARTEMIS integriert die Routing-Absicht des Betreibers in den Detektor

Externe Überwachungsdienste haben einen offensichtlichen Vorteil: Sie können Informationen aus vielen Teilen des Internets sammeln, ohne dass jedes Netz ein vollständiges System betreiben muss. Ihr Nachteil ist ebenso wichtig. Ein Dritter kann angekündigte Präfixe und Pfade sehen, weiß aber möglicherweise nicht, welche Ursprungsänderungen, Ersatzanbieter, Traffic-Engineering-Pfade oder Notfallankündigungen der Betreiber als legitim betrachtet. Allgemeine Regeln können deshalb subtile Richtlinienverstöße übersehen oder bei geplanten Änderungen Alarm schlagen.

ARTEMIS kehrte die Perspektive um. Der Detektor wird von der Organisation betrieben, deren Adressraum gefährdet ist, und diese Organisation liefert die verbindliche Sollbeschreibung. Öffentliche Kollektoren stellen weiterhin eine breite externe Sicht bereit, doch ihre Beobachtungen werden anhand privaten Wissens über geschützte Präfixe, autorisierte Ursprungs-AS, zulässige Nachbarn und ausgewählte Pfadbeziehungen interpretiert. Lokale Router-Datenquellen können Ereignisse ergänzen, die öffentliche Kollektoren nicht sehen.

Diese Kombination ist die prägende Idee des Projekts: Unvollständige globale Evidenz wird nützlicher, wenn sie mit ausdrücklich erklärter lokaler Absicht verglichen wird.

Die Platzierung des Detektors innerhalb des geschützten Netzes verlagert auch die Verantwortung nach innen. Ein Netz, das ARTEMIS unterhält, muss entscheiden, wer für die Richtliniendatei zuständig ist, wie Änderungen geprüft werden, welche Warnungen das Network Operations Center erreichen, welche Schlüsse das Sicherheitsteam ziehen darf und wer eine neue Route autorisieren kann. Die Software kann diese Verantwortung sichtbar machen. Sie kann die Institution nicht dazu bringen, sie gut wahrzunehmen.

ARTEMIS verlangt vom Betreiber, geschützte Präfixe, legitime Ursprungs-AS, zulässige Nachbarschaftsbeziehungen und ausgewählte Routing-Regeln festzulegen. Diese Sollbeschreibung ermöglicht dem Detektor eine präzisere Frage, als sie ein allgemeiner Überwachungsdienst stellen kann. Statt zu entscheiden, ob eine Route im Vergleich zur globalen Vergangenheit ungewöhnlich wirkt, kann das System bestimmen, ob die Route gegen die erklärte Absicht des Netzes verstößt.

Dieser Vorteil ist nur so zuverlässig wie die Erklärung selbst. Netze wechseln Anbieter, fügen Anycast-Standorte hinzu, verlagern Ursprungs-AS, richten vorübergehende Ersatzpfade ein und schalten bei Ausfällen Notfallankündigungen. Eine im Januar korrekte Richtlinie kann im Juni falsch sein. Erreicht eine betriebliche Änderung die Router, aber nicht ARTEMIS, kann der Detektor einen schwerwiegenden Fehlalarm erzeugen. Wird die Richtlinie zur Unterdrückung von Störungen unvorsichtig erweitert, kann ein tatsächlicher Verstoß auf dem Papier autorisiert werden.

Das System macht aus einer technischen Konfiguration damit einen institutionellen Vertrag. Routing-Technik, Sicherheitsbetrieb und Änderungsmanagement müssen sich darüber einigen, was die Datei bedeutet, wer sie bearbeiten darf und wie schnell sie dem Produktivbetrieb folgt. Der lokale Kontext des Projekts beseitigt falsch-positive und falsch-negative Ergebnisse nicht; er verlagert ihre wichtigste Ursache an einen Ort, den der Betreiber steuern kann.

Eine Routing-Sicherheitsregel verdient dieselbe Disziplin wie Software, die den Kundenverkehr beeinflussen kann. Änderungen sollten benannte Verantwortliche, Prüfungen, einen Versionsverlauf, Tests und eine mit einer genehmigten Netzänderung verknüpfte Begründung besitzen. Der Betreiber sollte beantworten können, wann ein Präfix, Ursprung oder Nachbar hinzugefügt wurde, wer dies genehmigte und welcher Vorfall oder welches Projekt die Entscheidung rechtfertigte. Eine einfache Konfigurationsdatei kann diesen Prozess unterstützen, sofern die Organisation sie als mehr als einen einmaligen Installationsschritt behandelt.

Tests sollten positive und negative Fälle umfassen. Eine legitime geplante Route sollte ohne Warnung passieren. Eine Ankündigung mit identischem Präfix durch einen nicht autorisierten Ursprung sollte die erwartete Klassifizierung auslösen. Ein Unterpräfix-Ereignis sollte den richtigen Schweregrad zeigen, und ein No-Export-Verstoß darf nicht mit einer Ursprungsübernahme verwechselt werden. Die Wiedergabe historischer Daten kann diese Prüfungen unterstützen, während eine Staging-Umgebung verifizieren kann, dass Benachrichtigungen und Abwehr-Wrapper die vorgesehenen Daten erhalten.

Diese Disziplin begrenzt auch die Gefahr institutioneller Abwanderung von Wissen. Wenn die Person, die ARTEMIS ursprünglich eingerichtet hat, die Organisation verlässt, sollte die Richtlinie für den nächsten Betreiber verständlich bleiben. Ein Detektor, dessen Logik von nicht dokumentierter Erinnerung abhängt, ist keine zuverlässige Infrastruktur, selbst wenn sein Code offen und die Latenz seiner Datenquellen gering ist.

FORTH und CAIDA machten aus einer Forschungsfrage einen Betreiberablauf

Das Projekt entstand aus der Zusammenarbeit von Forschenden der Foundation for Research and Technology-Hellas im Umfeld der University of Crete und CAIDA an der University of California San Diego. FORTH brachte Arbeiten zu Routing-Sicherheit und Systemen ein. CAIDA steuerte Infrastruktur für Internetmessungen, Fachwissen zu BGPStream und Beziehungen bei, die halfen, den Entwurf in Forschungs- und Bildungsnetze zu überführen. Das Projekt war daher nie nur ein Erkennungsalgorithmus; es verband Protokollwissen, Messsysteme und Zugang zu Betreibern.

Die Finanzierung folgte demselben gemischten institutionellen Muster. Im Projektverlauf erscheinen europäische und US-amerikanische Forschungsprogramme, Unterstützung durch den RIPE NCC Community Projects Fund, ein NSF-EAGER-Einsatzprojekt, das US Department of Homeland Security und der Comcast Innovation Fund. Die Unterstützung durch RIPE im Jahr 2017 half, den Prototyp zu einem betreiberorientierten Werkzeug weiterzuentwickeln. Eine Förderung von 50.000 Euro finanzierte 2019 Arbeiten zur Verifizierung auf der Datenebene mithilfe von RIPE Atlas.

Diese Förderungen zeigen, wie Forschung im öffentlichen Interesse zu einsetzbarer Software wurde, geben jedoch keinen Aufschluss über die heutigen Kosten für die Wartung produktiver Installationen.

Die institutionelle Geschichte ist für die Zuordnung wichtig. ARTEMIS ist weder eine eigenständig eingetragene Stiftung noch ein Dienst von CAIDA oder ein FORTH gehörender globaler Detektor. Es handelt sich um Open-Source-Software unter der BSD-3-Clause-Lizenz mit einer Forschungsgeschichte und einem heutigen kommerziellen Betreuer. Der Entwicklungsweg lässt sich am besten als Folge von Kooperationen und nicht als Eigentum einer einzelnen Organisation verstehen.

Der erste öffentliche Meilenstein war eine Demonstration auf der ACM SIGCOMM im Jahr 2016. Entscheidend war damals die Verbindung von Überwachung und Abwehr in einem geschlossenen Ablauf. Viele Systeme können eine verdächtige Route erkennen, nachdem sie genügend Evidenz gesammelt haben. ARTEMIS fragte, ob ein Betreiber das Ereignis schnell genug erkennen und bereits über eine praktikable Gegenmaßnahme verfügen könnte, sodass der Vorfall nicht stundenlang zwischen Dashboards, E-Mails und manuellen Router-Sitzungen weitergereicht werden müsste.

Eine Demonstration ist kein ausgereifter Produktiveinsatz. Sie zeigt, dass Komponenten in einer definierten Umgebung zusammenarbeiten können und dass das Forschungsproblem konkret genug für eine Vorführung ist. Die Arbeit von 2016 gab dennoch die Richtung für alles Folgende vor: aktuelle Beobachtungen, eine interne Sicht auf legitimes Routing, Klassifizierung und eine vorbereitete Ankündigung. Diese Abfolge machte die Reaktionszeit von einem organisatorischen Nachgedanken zu einer Systemeigenschaft.

Der Entwurf stützte sich auf Erfahrungen von Betreibern, nach denen die Reaktion auf Routenübernahmen Stunden dauern konnte. Die Verzögerung entstand nicht nur durch langsame Routenkollektoren. Teams mussten die Inhaberschaft bestätigen, die Ausbreitung prüfen, feststellen, ob das Ereignis geplant war, die richtigen Kontakte bei Upstream-Anbietern finden und eine sichere Gegenankündigung erstellen. ARTEMIS konnte mehrere dieser Schritte verkürzen, indem Richtlinien und Abläufe in der Nähe des Überwachungssystems gehalten wurden. Die menschlichen und geschäftlichen Beziehungen rund um die Route blieben jedoch außerhalb des Codes.

Der 2018 in IEEE/ACM Transactions on Networking veröffentlichte Beitrag lieferte die einprägsamste Aussage zu ARTEMIS: die Neutralisierung von BGP-Hijacking innerhalb einer Minute. Die Forschenden bewerteten den Ansatz in realen Experimenten und berichteten unter den getesteten Bedingungen von einer Erkennung innerhalb von Sekunden sowie einer Abwehr innerhalb einer Minute. Dieses Ergebnis war bedeutsam, weil es zeigte, dass ein betroffenes Netz nicht zwangsläufig auf einen Drittanbieterdienst, eine Telefonkette und eine manuell zusammengestellte Gegenankündigung warten musste.

Die Formulierung wird irreführend, wenn sie vom Experiment getrennt wird. Die Erkennungszeit hängt davon ab, ob das Ereignis einen verbundenen Monitor erreicht, wie schnell die Datenquelle die Aktualisierung liefert, wie die Regeln des Detektors darauf reagieren und ob das System fehlerfrei arbeitet. Die Abwehrzeit hängt von Präfixlänge, Routing-Befugnis, Upstream-Filtern, Ausbreitung und dem gewählten Genehmigungsprozess ab. Ein Netz, das eine menschliche Bestätigung verlangt, kann eine sicherere Entscheidung treffen und länger benötigen. Ein Netz, das sofort automatisiert handelt, kann schneller reagieren und ein höheres Risiko akzeptieren.

Die verantwortbare Schlussfolgerung ist begrenzt. ARTEMIS zeigte, dass ein eng integriertes System auf Betreiberseite einen Prozess erheblich verkürzen kann, der zuvor häufig deutlich länger dauerte. Es bewies nicht, dass jede Routenübernahme sichtbar ist, jede Gegenroute akzeptiert wird oder jedes Produktionsteam eine autonome Deaggregation erlauben sollte. Das Ergebnis ist als durch ein Experiment gestütztes Entwurfsziel und nicht als allgemeine Garantie zu verstehen.

Mehrere unvollständige Sichtweisen ergeben einen brauchbaren Vorfallsdatensatz

ARTEMIS kann mehrere öffentliche Quellen nutzen, weil kein einzelner Kollektor jede Route sieht. RIPE RIS und das RouteViews-Projekt der University of Oregon empfangen BGP-Aktualisierungen von ausgewählten Peers an verteilten Sammelpunkten. CAIDA BGPStream stellt einen Rahmen für den Zugriff auf und die Normalisierung von Routing-Daten aus mehreren Quellen bereit. Jeder Dienst erweitert das Sichtfeld des Betreibers, spiegelt aber zugleich die Netze wider, die sich für ein Peering mit seinen Kollektoren entscheiden, sowie die Standorte dieser Sitzungen und den zeitlichen Verlauf der Datenquellen.

Diese partielle Sichtbarkeit hat praktische Folgen. Ein Ereignis kann sich in einer Region ausbreiten und die von einem Einsatz verwendeten Kollektoren nie erreichen. Eine sehr kurze Ankündigung kann zurückgezogen werden, bevor die Datenquelle sie übermittelt. Eine Route kann Kunden des betroffenen Netzes über eine private Beziehung beeinträchtigen, die in den öffentlichen Daten nicht vertreten ist. Die Kombination von Kollektoren verringert einige blinde Flecken, erzeugt aber nur eine größere Stichprobe und keine allwissende Kopie der globalen Steuerungsebene.

Die richtige betriebliche Frage lautet daher nicht: „Hat ARTEMIS das Internet gesehen?“ Sie lautet: „Welche Beobachter sahen diese Ankündigung, wie schnell sahen sie sie und welcher Teil des Ereignisses könnte noch außerhalb der Stichprobe liegen?“ Diese Formulierung ermutigt Betreiber, die Herkunft jeder Warnung festzuhalten und das Fehlen in einer einzelnen Datenquelle nicht als Beweis dafür zu behandeln, dass eine Route nicht existierte.

RIPE NCC führte im Februar 2019 den öffentlichen Prototyp RIS Live ein, um BGP-Nachrichten mit wesentlich geringerer Verzögerung als bei der periodischen Verarbeitung von Archiven zu übertragen. ARTEMIS wurde zu einem Beispiel dafür, weshalb eine solche Datenquelle wichtig ist. Ein Sicherheitssystem kann nicht innerhalb von Sekunden reagieren, wenn seine wichtigste Beobachtung erst viele Minuten später eintrifft. Ein Live-Datenstrom ermöglicht dem Detektor, Aktualisierungen bei ihrem Eingang bei den Kollektoren auszuwerten.

Die geringere Latenz ändert nicht, was die Kollektoren beobachten können. RIS Live spiegelt weiterhin die Peers wider, die mit dem RIPE Routing Information Service verbunden sind, und die Routen, die diese Peers exportieren. Bleibt eine Routenübernahme lokal, wird sie vor Erreichen eines Kollektors gefiltert oder betrifft sie einen hinter einer anderen Beziehung verborgenen Pfad, kann die Datenquelle die entscheidende Evidenz vollständig verfehlen.

Auch die Zuverlässigkeit ist wichtig: Ein Ausfall des Datenstroms oder eine änderung kann wie Stille wirken, sofern der Überwachungsdienst nicht zwischen „keine verdächtigen Routen“ und „keine Daten“ unterscheidet.

Deshalb gehört der Zustand der Datenquellen in das Sicherheitsmodell. Ein Betreiber muss wissen, ob jeder Monitor aktuell, verzögert, getrennt oder mit einem ungewöhnlichen Volumen an Aktualisierungen aktiv ist. Ein Detektor, der einen eindeutigen Status anzeigt, während seine Eingaben beeinträchtigt sind, kann eine gefährlichere Form der Unwissenheit erzeugen als ein ausdrücklich gemeldeter Ausfall.

Echtzeitüberwachung beantwortet, was gerade erscheint, während Routing Information Bases und Aktualisierungsarchive Kontext liefern. RIPE RIS und RouteViews veröffentlichen historische Daten, aus denen hervorgehen kann, welche Ursprünge und Pfade vor einem Vorfall sichtbar waren, wann eine Änderung begann und wie lange sie anhielt. CAIDA BGPStream erleichtert die Verarbeitung dieser Datensätze über einen gemeinsamen Rahmen und ermöglicht ARTEMIS, Ereignisse wiederzugeben und Regeln anhand früheren Routing-Verhaltens zu testen.

Die Wiedergabe ist für Technik und Prüfung nützlich. Ein Team kann untersuchen, ob eine neue Richtlinie ein bekanntes Ereignis erkannt hätte, die Abfolge bis zu einer Warnung reproduzieren oder Einsatzkräfte schulen, ohne eine reale Produktionsroute zu verändern. Historische Evidenz kann außerdem wiederkehrende Ankündigungen sichtbar machen, die für sich genommen ungewöhnlich aussehen, aber eine etablierte Ersatzkonfiguration darstellen. Die Einschränkung besteht darin, dass ein Archiv die Sicht der Kollektoren und nicht das gesamte Ereignis bewahrt und dass eine frühere Topologie nicht jede aktuelle Beziehung abbilden kann.

Ein ausgereifter Einsatz kann Wiedergaben in die Änderungskontrolle integrieren. Bevor ein neuer Ursprung, Upstream-Anbieter oder eine Exportregel in Produktion geht, kann der Betreiber die überarbeitete Sollbeschreibung anhand repräsentativer historischer Daten testen und bestätigen, dass gewöhnliches Routing dadurch nicht zu einem dauerhaften Alarm wird. Diese Praxis macht die Konfiguration des Detektors zu einem prüfbaren Sicherheitsartefakt statt zu einer Datei, die nur bearbeitet wird, nachdem sie Störungen verursacht hat.

Öffentliche Daten bilden nur eine Seite des Entwurfs. ARTEMIS kann lokale Aktualisierungen über ExaBGP oder private Sitzungen des BGP Monitoring Protocol empfangen. ExaBGP kann als programmierbarer BGP-Speaker dienen und Routenereignisse an andere Software weiterleiten. BMP ermöglicht Routern, Routing-Informationen an ein Überwachungssystem zu exportieren, ohne dieses System an der Weiterleitungsentscheidung zu beteiligen. Diese Quellen können die eigenen Nachbarschaften und den Routenzustand des geschützten Netzes zeigen, bevor die Informationen bei einem öffentlichen Kollektor sichtbar werden.

Lokale Datenquellen verbessern Aktualität und Kontext, bringen aber zugleich sensible Infrastruktur in die Plattform ein. BMP-Daten können umfangreich sein und interne Routing-Beziehungen offenlegen. Die Integration von ExaBGP verlangt besondere Kontrolle, weil dieselbe programmierbare Schnittstelle sowohl zur Ankündigung als auch zur Beobachtung von Routen verwendet werden kann. Zugangsdaten, Netzwerkerreichbarkeit, Nachrichtenvalidierung und die Trennung von Überwachung und Abwehr werden damit zu Sicherheitsgrenzen.

Ein gut konzipierter Einsatz verwendet öffentliche und private Datenquellen für unterschiedliche Zwecke. Öffentliche Kollektoren zeigen, wie sich eine Ankündigung über die unmittelbare Nachbarschaft des Betreibers hinaus ausbreitet. Lokale Quellen zeigen, was der Betreiber und seine Router direkt beobachteten. Ein Widerspruch zwischen beiden ist nicht zwangsläufig ein Fehler; er kann genau die Evidenz liefern, die erforderlich ist, um zu verstehen, wo die Ausbreitung endete oder eine Richtlinie wirksam wurde.

Die Anwendung trennt Beobachtung, Erkennung und Evidenz

Die heutige Plattform ist eine aus mehreren Containern bestehende Microservice-Anwendung und nicht lediglich ein Skript, das einen Datenstrom liest. Überwachungsdienste verbinden sich mit öffentlichen und privaten Datenquellen, normalisieren eingehende BGP-Informationen und veröffentlichen Ereignisse. Erkennungsdienste verarbeiten diese Ereignisse und wenden Betreiberregeln an. Speicher, APIs, Weboberfläche, Benachrichtigungen und Überwachung ergänzen diesen Kern.

Die Trennung ermöglicht, Komponenten unabhängig zu skalieren oder ausfallen zu lassen, und erleichtert die Ergänzung einer neuen Datenquelle, ohne die gesamte Anwendung neu zu schreiben.

Modularität vervielfacht zugleich die Abhängigkeiten. Ein Monitor kann fehlerfrei arbeiten, während der Detektor stillsteht. Der Nachrichtenbus kann Ereignisse annehmen, während die Datenbank nicht verfügbar ist. Die Weboberfläche kann einen alten Vorfall laden, obwohl die aktuelle Verarbeitungskette unterbrochen ist. Die Container-Orchestrierung kann einen Dienst neu starten und damit einen wiederkehrenden Absturz verdecken. Der Betrieb benötigt deshalb Zustandsprüfungen, die den vollständigen Weg von der Quelldatenquelle bis zur Warnung beschreiben, statt nur zu melden, dass einzelne Container laufen.

Docker Compose senkt die Einstiegshürde für einen kontrollierten Einsatz, während Kubernetes-Unterstützung zu Organisationen passt, die bereits Containerplattformen betreiben. Keine der beiden Methoden macht das System zu einem verwalteten globalen Dienst. Das einsetzende Netz bleibt für Kapazität, Aktualisierungen, Geheimnisse, Speicher, Sicherungen und Vorfallszugriff verantwortlich.

Ein Nachrichtenbus ermöglicht Überwachungs-, Erkennungs- und Benachrichtigungsdiensten, Ereignisse auszutauschen, ohne dass ein Prozess alle anderen direkt steuert. Dieser Entwurf kann Aktualisierungsspitzen aufnehmen und Verbrauchern unterschiedliche Verarbeitungsgeschwindigkeiten erlauben. Er wirft zugleich Fragen zu Reihenfolge, Duplikaten und Rückstau auf. Ein Routing-Vorfall kann Tausende Aktualisierungen, Rücknahmen und Pfadänderungen umfassen. Das System muss deshalb genügend Reihenfolge und Herkunft bewahren, damit ein Betreiber das Geschehen rekonstruieren kann.

Persistenter Speicher verschafft ARTEMIS einen Vorteil gegenüber einem flüchtigen Alarm. Aktualisierungen, Warnungen, Konfigurationsstände und Vorfallsentscheidungen können für spätere Prüfungen aufbewahrt werden. Die Projektarchitektur hat PostgreSQL-bezogene Komponenten, Timescale-ähnlichen Speicher und das Hasura-API-Ökosystem verwendet. Diese Entscheidungen unterstützen Abfragen und Integrationen, schaffen jedoch zugleich ein sensibles Archiv für Routing- und Betriebsevidenz, das Aufbewahrungsgrenzen, Zugriffskontrollen und verlässliche Sicherungen benötigt.

Prüfbarkeit ist nicht dasselbe wie Gewissheit. Ein vollständiger Datensatz dessen, was das System empfangen hat, kann belegen, wie ARTEMIS zu einer Warnung gelangte. Er kann nicht beweisen, dass das System jede relevante Route empfangen hat oder dass die Betreiberregeln richtig waren. Die Datenbank sollte daher Quelle und Vertrauensgrad und nicht nur eine endgültige Vorfallsbezeichnung bewahren.

Die Weboberfläche stellt Vorfälle, Systemzustand und Routing-Beobachtungen in einer Form dar, die ein Netz- oder Sicherheitsbetriebsteam nutzen kann. Benachrichtigungen können Warnungen per E-Mail, über mobile Kanäle oder individuelle Integrationen senden, während Grafana-Dashboards den Dienstzustand und Ereignistrends zeigen können. Diese Funktionen machen aus einem Forschungsmechanismus ein betriebliches Produkt, weil das Reaktionsteam Priorisierung, Verlauf und eine gemeinsame Sicht statt roher BGP-Aktualisierungen benötigt.

Die Oberfläche kann auch falsches Vertrauen erzeugen. Eine rote Vorfallskarte ist eine aus Beobachtungen und Regeln abgeleitete Klassifizierung und keine unabhängige Feststellung böswilliger Absicht. Eine Karten- oder Pfadansicht kann vollständig wirken, obwohl sie nur ausgewählte Kollektoren darstellt. Benachrichtigungen können zu Störungen werden, wenn geplante Änderungen nicht in der Richtlinie abgebildet sind. Alarmmüdigkeit kann dazu führen, dass das eine wichtige Ereignis ignoriert wird.

Gute Betriebspraxis hält die Benutzeroberfläche mit der Verifizierung verbunden. Einsatzkräfte sollten die Quellaktualisierungen prüfen, öffentliche und lokale Datenquellen vergleichen, den aktuellen RPKI-Status kontrollieren, Tests auf der Datenebene ausführen und dokumentieren können, warum ein Vorfall eskaliert, ignoriert oder abgeschlossen wurde. Das Dashboard ist nützlich, wenn es diesen Weg verkürzt, nicht wenn es ihn ersetzt.

Ein Routenmuster kann weder Motiv noch Auswirkungen beweisen

Die ARTEMIS-Forschung entwickelte eine Taxonomie, die Ereignisse nach Präfixbeziehung, AS-Pfad-Manipulation, Richtlinie und möglichen Auswirkungen auf der Datenebene unterscheidet. Die Implementierung unterstützt anhand der Evidenz aus der Steuerungsebene eine definierte Auswahl dieser Muster, darunter Ursprungsfälle mit identischem Präfix oder Unterpräfix, Squatting und ausgewählte Exportverstöße. Eine Taxonomie gibt Betreibern eine einheitliche Sprache und hilft dem Detektor, unterschiedliche Regeln auf unterschiedliche Ereignisse anzuwenden.

Die Kategorien müssen an das gebunden bleiben, was die Daten zeigen. Ein Pfad, der mit einem unerwarteten Nachbarn beginnt, kann auf ein erfundenes Segment, ein Route Leak oder eine autorisierte, aber nicht in der Richtlinie dokumentierte Änderung hindeuten. Ein nicht autorisierter Ursprung kann ein Fehler statt eines Angriffs sein. Selbst eine absichtliche Ankündigung kann darauf ausgelegt sein, Verkehr zu verwerfen, einen Dienst zu imitieren oder Verkehr unterwegs zu beobachten. BGP-Aktualisierungen allein können diese Ergebnisse nicht unterscheiden.

Sorgfältige Sprache schützt sowohl Genauigkeit als auch Reaktionsqualität. „Vermutete Routenübernahme“ oder „Richtlinienverstoß“ ist in der Warnphase meist sicherer als „Angriff“. Der stärkere Begriff kann verwendet werden, nachdem Routeninhaberschaft, Betreiberkontakte und Evidenz auf der Datenebene ihn stützen. Diese Zurückhaltung schwächt die Sicherheit nicht; sie verhindert, dass das Vorfallssystem Unsicherheit in eine Behauptung umwandelt, die andere Teams anschließend als Tatsache wiederholen.

BGP-Nachrichten beschreiben Aussagen zur Erreichbarkeit und Pfadinformationen, die zwischen Netzen ausgetauscht werden. Sie zeigen nicht jedes Paket, das der ausgewählten Route folgt. Nach einer verdächtigen Ankündigung kann Verkehr verworfen, abgefangen und weitergeleitet oder von einem imitierenden Dienst beantwortet werden. Er kann auch unbeeinträchtigt bleiben, weil sich die Route nicht bis zu den Netzen ausbreitete, über die die relevanten Nutzer verbunden sind. Verschiedene Teile des Internets können gleichzeitig unterschiedliche Auswirkungen erleben.

Diese Grenze ist für ARTEMIS zentral. Der Detektor kann zeigen, dass eine Route gegen die Richtlinie des Betreibers verstieß und an bestimmten Beobachtungspunkten erschien. Er kann aus dem AS-Pfad kein Motiv ableiten und nicht garantieren, dass ein Traceroute denselben Weg wie Anwendungsverkehr in der entsprechenden Richtung nimmt. Verschlüsselung, DNS-Verhalten, Caching, Anycast und Anwendungs-Failover können das Nutzererlebnis zusätzlich verändern. Die Warnung der Steuerungsebene ist daher Evidenz für einen Vorfall und nicht der gesamte Vorfall.

Eine brauchbare Reaktion verbindet mehrere Datensätze. BGP-Evidenz belegt die Ankündigung und ihre Ausbreitung. Tests auf der Datenebene untersuchen Erreichbarkeit und Pfade von ausgewählten Standorten. Diensttelemetrie zeigt Fehler, Latenz und Kundenauswirkungen. Kontakte zu Upstream-Anbietern klären, ob die Route autorisiert oder irrtümlich war. Keiner dieser Datensätze ist vollkommen, doch gemeinsam unterstützen sie eine Entscheidung, die eine einzelne Datenquelle nicht tragen kann.

Die Förderung durch den RIPE Community Projects Fund im Jahr 2019 unterstützte eine Erweiterung von ARTEMIS, die mithilfe von Traceroute-Messungen über RIPE Atlas die Auswirkungen erkannter Ereignisse untersuchte. Diese Arbeit erkannte eine Einschränkung des ursprünglichen Ablaufs auf der Steuerungsebene an. Eine Route kann in BGP gefährlich wirken und kaum beobachtbare Auswirkungen besitzen, während eine geringe Ausbreitung dennoch eine wichtige Kundengruppe treffen kann. Sonden auf der Datenebene ergänzen Evidenz dazu, wohin der Verkehr offenbar fließt und ob Endpunkte erreichbar bleiben.

RIPE Atlas verfügt über ein verteiltes Sondennetz, doch die Verteilung der Sonden ist ungleichmäßig, und das gewählte Ziel reagiert möglicherweise nicht so, dass der Pfad erkennbar wird. Traceroute kann durch Filterung, Lastverteilung, Tunnel und asymmetrisches Routing beeinflusst werden. Der Vorwärtspfad von einer Sonde zum Ziel muss nicht dem Weg entsprechen, den der Kundenverkehr in Gegenrichtung nimmt. Eine fehlgeschlagene Messung kann einen Ausfall, einen nicht antwortenden Hop oder eine testspezifische Einschränkung bedeuten.

Der praktische Gewinn ist keine Gewissheit, sondern eine bessere Priorisierung. Wenn BGP-Kollektoren ein nicht autorisiertes Unterpräfix zeigen und Sonden in mehreren Regionen die Erreichbarkeit verlieren oder ihren Pfad zum unerwarteten Ursprung ändern, besitzt der Betreiber stärkere Evidenz für eine Eskalation. Ist das Ereignis auf der Steuerungsebene nur bei einem Kollektor sichtbar und bleiben die Tests auf der Datenebene stabil, kann das Team untersuchen, bevor es globale Ankündigungen verändert. Die Entscheidung bleibt kontextabhängig, ist aber weniger blind.

Deaggregation kann Verkehr nur zurückholen, wenn das Routing-System sie zulässt

Die bekannteste Reaktion von ARTEMIS ist die Deaggregation. Ein betroffenes Netz, das ein breites Präfix ankündigt, kann spezifischere Routen erzeugen, sodass die normale Auswahl nach dem längsten Präfix den Verkehr zum legitimen Netz zurückzieht. Die Methode nutzt bestehendes BGP-Verhalten und kann sich schnell ausbreiten, weshalb sie sich für das experimentelle Ziel des Projekts „innerhalb einer Minute“ eignete. Sie belässt die Befugnis außerdem beim betroffenen Netz, statt eine Zusammenarbeit des unerwarteten Ursprungs vorauszusetzen, bevor sich der Dienst erholen kann.

Deaggregation hat strenge Grenzen. Viele Netze filtern IPv4-Routen mit einer Länge über /24 und IPv6-Routen mit einer Länge über /48, um Tabellenwachstum und betrieblichen Missbrauch einzudämmen. Ein betroffenes Netz, das bereits ein /24 oder /48 ankündigt, kann möglicherweise keine spezifischere Route erzeugen, die im weiteren Internet akzeptiert wird. Upstream-Anbieter können zusätzlich beschränken, was ein Kunde ankündigen darf. Routenobjekte, Präfixfilter oder RPKI-Daten müssen die Gegenmaßnahme möglicherweise ebenfalls zulassen.

Die Ausbreitung erfolgt weder sofort noch einheitlich, sodass alte und neue Pfade gleichzeitig bestehen können.

Ein vorbereiteter Betreiber sollte diese Grenzen vor einem Vorfall kennen. Welche Präfixe können deaggregiert werden? Welche Upstream-Anbieter akzeptieren sie? Welche Routenfilter und Route Origin Authorisations decken den Notfallzustand bereits ab? Wie werden die Routen nach der Wiederherstellung zurückgezogen? ARTEMIS kann einen Wrapper auslösen, doch dessen Erfolg hängt von Vereinbarungen außerhalb der Anwendung ab.

Projektunterlagen sprechen von automatischer Abwehr, und die Forschung umfasst einen geschlossenen Ablauf, in dem die Erkennung eine Gegenankündigung auslösen kann. Detaillierte Betriebsbeschreibungen zeigen zugleich manuelle Bestätigung und individuelle Wrapper. Beides kann zutreffen, weil Einsätze unterschiedliche Autonomiestufen wählen. Die belastbare Formulierung lautet, dass ARTEMIS eine automatisierte oder vom Betreiber autorisierte Abwehr über konfigurierbare Abläufe unterstützt.

Das Risiko ist asymmetrisch. Eine verzögerte Reaktion kann einen Ausfall oder eine Abfanghandlung verlängern. Eine falsche automatische Reaktion kann unnötige spezifischere Routen ankündigen, gegen Richtlinien eines Upstream-Anbieters verstoßen, interne Annahmen offenlegen oder Instabilität erzeugen, während der ursprüngliche Vorfall noch untersucht wird. Eine veraltete Sollregel kann eine geplante Routenänderung in einen vermeintlichen Notfall verwandeln. Besitzt der Wrapper weitreichende Router-Zugangsdaten, kann eine Kompromittierung von ARTEMIS selbst zu einem Routing-Angriff werden.

Sicherere Automatisierung erfolgt stufenweise. Das System kann zunächst die Warnung anreichern, mehrere Datenquellen prüfen, den RPKI-Status verifizieren, Tests auf der Datenebene ausführen und die genaue Routenänderung vorbereiten. Ein Mensch kann Maßnahmen mit großen Auswirkungen genehmigen, während Fälle mit geringerem Risiko richtlinienbasiert automatisiert werden können. Ratenbegrenzungen, eingeschränkte Zugangsdaten, Simulationen, Änderungsprotokolle und ein getesteter Rücksetzpfad sind wichtiger als die Bezeichnung „automatisch“.

Ziel ist nicht, manuelle Arbeit um ihrer selbst willen zu erhalten, sondern sicherzustellen, dass Geschwindigkeit die Rechenschaftspflicht nicht beseitigt.

RPKI stärkt einen Teil der Evidenzkette

Die Resource Public Key Infrastructure ermöglicht Adressinhabern, Route Origin Authorisations zu erstellen, die festlegen, welche autonomen Systeme bestimmte Präfixe bis zu welcher maximalen Länge als Ursprung ankündigen dürfen. Router oder Richtliniensysteme können eine Route mithilfe der Route Origin Validation als gültig, ungültig oder nicht gefunden einstufen. Dies ergänzt einen Teil von BGP, der sonst auf verteiltem Vertrauen beruht, um kryptografische Evidenz. Es handelt sich um eine vorbeugende Kontrolle, weil andere Netze einen nicht autorisierten Ursprung ablehnen oder schlechter priorisieren können, bevor Verkehr ihm folgt.

ARTEMIS arbeitet auf einer anderen Ebene des Vorfalls. Es kann den RPKI-Validierungsstatus als Evidenz verwenden, vergleicht Routen aber zusätzlich mit privaten Betreiberregeln, zeichnet das Ereignis auf, kombiniert öffentliche und lokale Datenquellen und verbindet Erkennung mit Reaktion. RPKI validiert nicht den gesamten AS-Pfad, und die Einsatzrichtlinien sind nicht einheitlich. Eine Route kann RPKI-gültig sein und dennoch gegen eine erwartete Nachbarschaftsbeziehung verstoßen oder über einen nicht vorgesehenen Pfad weitergegeben werden.

Eine Route kann ungültig sein, weil eine legitime betriebliche Änderung nicht in der ROA abgebildet wurde.

Die Systeme ergänzen einander daher. RPKI kann die Zahl nicht autorisierter Ursprungsrouten verringern, die im weiteren Internet akzeptiert werden. ARTEMIS kann dem betroffenen Netz zeigen, was beobachtet wird, ausgewählte Muster über eine einfache Ursprungsvalidität hinaus erkennen und die Reaktion organisieren. Künftige Mechanismen zur Pfadautorisierung wie ASPA können die Evidenz zu Beziehungen stärken. Sie beseitigen jedoch nicht die Notwendigkeit, tatsächliche Ankündigungen von Netzen und die Auswirkungen von Vorfällen auf Dienste zu überwachen.

Pilotprojekte führten ARTEMIS über das Labor hinaus, ohne Marktgröße zu belegen

CAIDA berichtete über einen von der NSF unterstützten experimentellen Einsatz von ARTEMIS mit Internet2, Great Plains Network und Merit in den Jahren 2018 und 2019. Diese Pilotprojekte waren bedeutsam, weil Forschungs- und Bildungsnetze reale Präfixe, Upstream-Anbieter, Änderungsprozesse und Dienstpflichten besitzen. Betreiber konnten testen, ob sich die Software in die vorhandene Überwachung einfügte, ob die Regeln ihre Routing-Absicht erfassten und wie Warnungen in die Vorfallsreaktion gelangen würden.

Die Beleglage ist glaubwürdig, aber begrenzt. Ein Pilotprojekt kann Installation, technische Rückmeldungen und eine ausgewählte betriebliche Nutzung nachweisen. Es belegt weder eine kontinuierliche produktive Abdeckung noch den aktuellen Versionsstand oder die Leistung in jedem Netztyp. Die Projektwebsite veröffentlicht außerdem Aussagen von Fachleuten im Umfeld von AMS-IX, Internet2 und ESnet und zeigt Organisationslogos.

Diese Verweise deuten auf Tests oder Nutzung hin, sollten aber nicht in die Behauptung umgewandelt werden, jede genannte Organisation sei heute ein zahlender Kunde oder das Projekt besitze einen bekannten globalen Marktanteil.

Diese Unterscheidung ist wichtig, weil Routing-Sicherheitssoftware häufig unsichtbar eingesetzt wird. Ein Betreiber kann einen internen Fork betreiben, nur die Überwachung ohne Abwehr nutzen oder nach einem Versuch aufhören. Das Fehlen einer vollständigen Erhebung macht das Projekt nicht bedeutungslos, verhindert aber eine präzise Aussage zur Verbreitung. Benannte Fälle sind stärkere Evidenz als eine große, unbelegte Zahl.

Betreiberkontrolle bringt Integrations- und Softwarelieferkettenlasten mit sich

ARTEMIS wird unter der BSD-3-Clause-Lizenz verbreitet. Ein Betreiber kann den Code prüfen, ihn in kontrollierter Infrastruktur ausführen, Integrationen anpassen und vermeiden, sensible Richtlinien an einen verpflichtenden zentralen Anbieter zu senden. Dieses Modell passt zum entscheidenden Vorteil des Projekts, weil die wertvollste Sollbeschreibung innerhalb des Netzes liegt. Es gestattet außerdem kommerzielle Nutzung und Forks, sodass Code BGP und andere Parteien Dienste auf der offenen Grundlage entwickeln können.

Kontrolle bringt Arbeit mit sich. Die Plattform umfasst Container, einen Nachrichtenbus, Datenbanken, APIs, eine Webanwendung, Benachrichtigungssysteme und Datenquellenintegrationen. Jede Komponente benötigt Aktualisierungen, Zugangsdaten, Netzwerksegmentierung, Sicherungen und Überwachung. Das System speichert sensible Routing-Richtlinien und kann Zugangsdaten enthalten, mit denen sich Ankündigungen beeinflussen lassen. Ein Produktiveinsatz besitzt daher eine wesentlich größere Angriffsfläche als der ursprüngliche Erkennungsalgorithmus.

Die offene Lizenz gibt einem Betreiber einen Ausweg aus der Abhängigkeit von einem einzelnen Betreuer, schafft aber nicht automatisch eine Supportorganisation. Jemand muss weiterhin Aktualisierungen testen, Abhängigkeiten prüfen und den Code verstehen, wenn sich eine Datenquelle oder Router-Schnittstelle ändert. Für kleinere Netze können ein einfacheres Warnwerkzeug oder ein verwalteter kommerzieller Dienst leichter zu betreiben sein, auch wenn sie weniger lokale Kontrolle bieten.

Ein produktiver ARTEMIS-Dienst muss während derselben Netzinstabilität verfügbar bleiben, aufgrund derer Betreiber ihn benötigen. Datenquellenverbindungen, Nachrichtenbus, Datenbank, API, Oberfläche, Benachrichtigungskanal und Authentifizierung bilden eine gemeinsame Dienstkette. Redundanz auf Containerebene hilft nur, wenn auch Zustand, Speicher und externe Abhängigkeiten auf Ausfälle vorbereitet sind. Ein neu gestarteter Monitor kann nicht gespeicherte Aktualisierungen nicht wiederherstellen, und eine replizierte Oberfläche kann keinen Vorfall anzeigen, den die Erkennungsverarbeitung nicht verarbeitet hat.

Der Betriebsentwurf sollte deshalb ausdrückliche Zustände eingeschränkter Leistung enthalten. Fällt eine öffentliche Datenquelle aus, sollte das System melden, dass die Abdeckung geringer geworden ist, statt weiterhin einen undifferenziert fehlerfreien Status anzuzeigen. Ist die Datenbank nicht verfügbar, muss der Detektor Ereignisse möglicherweise lokal aufbewahren oder die Abwehr stoppen, weil keine Prüfevidenz geschrieben werden kann. Fällt der Identitätsanbieter aus, sollte ein Notfallzugriff möglich sein, ohne ein dauerhaft unkontrolliertes Konto zu hinterlassen.

Diese Entscheidungen werden von der Hijack-Taxonomie nicht beschrieben, bestimmen aber, ob aus der Forschungsidee verlässliche Infrastruktur wird.

Die Plattform benötigt zudem ein eigenes Leistungsbudget. Ein Schub legitimer Aktualisierungen während einer großen Routing-Änderung kann Monitore und Speicher stärker belasten als eine einzelne Routenübernahme. Interne Warteschlangen dürfen einen nahezu in Echtzeit eintreffenden Datenstrom nicht unbemerkt in einen verzögerten Vorfall verwandeln. Kapazitätstests, Datenbankaufbewahrung und Rückstau im Nachrichtenbus gehören aus demselben Grund in die Einsatzplanung wie Routenfilter und Präfixlängen: Sie begrenzen die Reaktionsleistung, die das System glaubwürdig versprechen kann.

ARTEMIS verbindet Websoftware, Container-Images, eine Datenbank, Nachrichtenkomponenten, APIs, Authentifizierung und Netzwerkbibliotheken. Diese Architektur macht das Projekt erweiterbar, doch jede Abhängigkeit ist eine mögliche Schwachstelle oder Fehlerquelle. Ein Fehler in einer Benutzeroberfläche kann Routing-Richtlinien offenlegen. Ein kompromittiertes Image kann Warnungen verändern. Ein zu großzügiger API-Token kann Vorfälle preisgeben, während Zugangsdaten eines Abwehr-Wrappers Routenänderungen ermöglichen können. Die Sicherheit des Detektors ist daher untrennbar mit der Sicherheit der zu seinem Betrieb verwendeten Software verbunden.

Open Source hilft, weil Betreiber Komponenten prüfen, Versionen festschreiben und Images selbst erstellen können. Es garantiert nicht, dass jede transitive Abhängigkeit geprüft wurde oder eine öffentliche Schwachstelle innerhalb der für ein Netz erforderlichen Frist behoben wird. Ein Produktionsteam benötigt ein Verzeichnis der Images und Bibliotheken, einen Prozess für deren Neuerstellung, eine Trennung zwischen schreibgeschützter Überwachung und schreibfähiger Abwehr sowie eine Möglichkeit, Sicherheitsaktualisierungen zu testen, ohne den Vorfallsverlauf zu verlieren.

Diese Anforderung verändert die Bewertung der Projektwartung. Eine neue Erkennungsfunktion kann mehr Aufmerksamkeit erhalten als eine Datenbankaktualisierung oder eine Fehlerbehebung an der Authentifizierung, obwohl Letztere für die Integrität des Dienstes wichtiger sein können. Sicherheitshinweise, reproduzierbare Builds, aktualisierte Abhängigkeiten und ein unterstützter Veröffentlichungszweig sind Belege betrieblicher Reife, selbst wenn sie dem Dashboard keine sichtbare Option hinzufügen.

Veröffentlichungen und Code BGP bestimmen die heutige Wartungsprüfung

Die jüngste im Recherchematerial identifizierte formale Version ist 2.3.0 mit dem Namen Cadmus und dem Datum 24. November 2022. Die Live-Demonstration zeigte zum Stichtag 5. August 2026 einen späteren, auf einem Commit beruhenden Build, und die aktuelle Projektwebsite blieb aktiv. Diese Tatsachen stützen die Schlussfolgerung, dass die Arbeit nach der letzten formalen Veröffentlichung fortgesetzt wurde. Sie werfen zugleich eine berechtigte Frage für den Produktivbetrieb auf: Welche Version ist getestet, unterstützt und für eine Aktualisierung geeignet?

Commit-Aktivität und eine funktionierende Demonstration zeigen Entwicklung. Eine semantische Veröffentlichung bietet eine andere Form der Sicherheit: eine benannte Basisversion, Veröffentlichungshinweise, Erwartungen an Abhängigkeiten und einen Stand, gegen den Betreiber testen können. Ein Projekt kann aktiv sein, während sein formaler Veröffentlichungsprozess zurückliegt. Eine aktuelle Demonstration kann Code ausführen, den kein Produktionsbetreiber ohne Prüfung übernehmen sollte.

Für Routing-Sicherheitsinfrastruktur ist Veröffentlichungsdisziplin Teil des Sicherheitsmodells. Betreiber müssen wissen, welche Zweige Fehlerbehebungen erhalten, wie Migrationen gehandhabt werden und ob ältere Abhängigkeiten weiterhin gefährdet sind. Eine neue Versionsmarke würde keine allgemeine Zuverlässigkeit belegen, doch eine veröffentlichte Support- und Sicherheitsrichtlinie würde die Unsicherheit stärker verringern als eine aktuelle Website allein.

Die Projektwebsite nennt Code BGP als heutigen Betreuer von ARTEMIS und beschreibt das Unternehmen als aus dem Projekt hervorgegangenes Start-up. Kommerzialisierung kann ein echtes Open-Source-Problem lösen. Routing-Sicherheitssoftware benötigt Menschen, die Integrationen pflegen, auf Schwachstellen reagieren, Einsätze unterstützen und Forschungsfunktionen nach dem Ende der ursprünglichen Förderungen in zuverlässigen Betrieb überführen.

Code BGP ist dennoch ein eigenständiges kommerzielles Unternehmen mit einem breiteren Produkt- und Kundenkontext. Es darf nicht als anderer Name für FORTH, CAIDA oder jeden Open-Source-Einsatz verwendet werden. Die öffentlichen Belege im Recherchematerial nennen weder Umsatz, Bewertung oder Kundenliste des Unternehmens noch die genaue Grenze zwischen Gemeinschaftsfunktionen und kommerziellen Fähigkeiten. Dieses Fehlen ist keine Kritik, sondern eine Grenze dessen, was ein Profil behaupten kann.

Die Beziehung schafft zwei Anreize, die übereinstimmen oder auseinanderlaufen können. Das offene Projekt profitiert, wenn kommerzielle Mitarbeitende getesteten Code und Dokumentation beitragen. Das Unternehmen profitiert, wenn das offene Projekt Vertrauen, Verbreitung und eine technische Grundlage für kostenpflichtige Dienste schafft. Der langfristige Maßstab ist, ob Veröffentlichungen, Sicherheitskorrekturen und Roadmap-Entscheidungen für Betreiber, die keine kommerziellen Kunden sind, ausreichend sichtbar bleiben.

Eine freizügige Lizenz stellt sicher, dass der Quellcode kopiert, verändert und kommerzialisiert werden kann. Sie stellt nicht sicher, dass ein anderes Team die Architektur versteht, eine Veröffentlichung reproduzieren oder die Wartung übernehmen kann, wenn die heutigen Fachleute ausscheiden. Die langfristige Kontinuität des Projekts hängt von Dokumentation, Tests, der Historie gemeldeter Probleme, Wissen über Abhängigkeiten und einem Beitragsweg ab, der über die Erbauer des ursprünglichen Forschungssystems hinausreicht.

Die Betreuung durch Code BGP kann diese Kontinuität stärken, indem erfahrene Fachleute an die Plattform gebunden bleiben. Sie kann praktisches Wissen zugleich in einer kommerziellen Organisation konzentrieren, obwohl das Repository öffentlich bleibt. Die Unterscheidung lässt sich anhand von Veröffentlichungshinweisen, öffentlichen Entwurfsdiskussionen, Reaktionen auf Berichte aus der Gemeinschaft und der Frage beobachten, ob Einsätze außerhalb des Kundenkreises genügend Informationen für einen sicheren Betrieb erhalten.

Ziel ist nicht, kommerziellen Wert zu verhindern. Eine gesunde Open-Core-Beziehung kann bezahlten Support mit öffentlicher Wartung verbinden. Das Risiko entsteht, wenn das offene Projekt zu einer historischen Demonstration wird, während der betriebliche Weg in nicht dokumentierte private Komponenten abwandert. Portabilität sollte deshalb praktisch geprüft werden: Kann ein unabhängiger Betreiber das System anhand der jeweils verfügbaren öffentlichen Dokumentation installieren, aktualisieren, prüfen und wiederherstellen?

ARTEMIS besetzt eine anspruchsvolle Mitte der Routing-Sicherheit

Das Feld der Routing-Sicherheit umfasst öffentliche Kollektoren, Forschungs- und Inferenzsysteme, Open-Source-Warnwerkzeuge, RPKI-Validatoren und kommerzielle Überwachungsplattformen. RIPE RIS, RouteViews und BGPStream liefern Daten und keinen betreiberspezifischen Vorfallsablauf. BGPalerter bietet ein anderes Open-Source-Überwachungsmodell. MANRS setzt betriebliche Normen, erkennt aber keine aktuellen Ereignisse. Kommerzielle Dienste können breite Überwachung und Unterstützung durch Fachleute bereitstellen, verfügen jedoch möglicherweise nicht über privaten lokalen Kontext, sofern der Kunde ihn nicht integriert.

Die besondere Position von ARTEMIS ist die Verbindung von Betreiberkontrolle, ausdrücklicher Sollbeschreibung, mehreren öffentlichen und lokalen Datenquellen, offenem Code und optionaler Abwehr. Diese Position ist zugleich anspruchsvoll. Ein Netz muss über Routing-Fachwissen verfügen, Richtlinien pflegen und eine Plattform mit mehreren Diensten betreiben. Das Projekt eignet sich deshalb möglicherweise am besten für Organisationen, die Routing-Sicherheit als Kernkompetenz und nicht als Dashboard-Abonnement betrachten.

Der Vergleich sollte nicht auf eine Funktionstabelle reduziert werden. Verschiedene Modelle platzieren Vertrauen und Arbeit an unterschiedlichen Stellen. Ein verwalteter Dienst zentralisiert Fachwissen und Beobachtung. Ein betreibergeführtes System hält Richtlinien und Maßnahmen näher am Netz. Die entscheidende Frage lautet, welche Partei genügend sehen, sicher handeln und bei unvollständiger Evidenz rechenschaftspflichtig bleiben kann.

ARTEMIS Lite erschien 2023 in Unterlagen der RIPE-Gemeinschaft als verwandter, leichterer Ansatz, der einen Teil des Aufwands für die Bereitstellung verringern sollte. Die Existenz einer Lite-Variante ist Evidenz dafür, dass der Umfang der vollständigen Plattform für kleinere Teams schwierig sein kann. Eine aus mehreren Containern bestehende Umgebung mit persistentem Speicher, mehreren Datenquellen und individueller Abwehr kann für einen großen Betreiber angemessen und für ein Netz übermäßig sein, das zunächst klare Sichtbarkeit und verlässliche Warnungen benötigt.

Ein leichteres System sollte nicht als gleichwertig beschrieben werden, nur weil es Name und Zweck teilt. Das Recherchematerial beschreibt ARTEMIS Lite als funktional eingeschränkt, und Aussagen aus Präsentationen benötigen eine unabhängige Bestätigung. Entscheidend ist der Ausgleich zwischen geringeren Betriebskosten und möglicherweise fehlendem Kontext, fehlenden Integrationen, fehlendem Verlauf oder fehlenden Reaktionsmechanismen. Ein kleinerer Einsatz kann dennoch wertvoll sein, wenn er diese Grenzen offen beschreibt.

Die Verbreitung hängt davon ab, wie viel institutionelle Infrastruktur das Werkzeug voraussetzt. Ein Projekt kann technisch offen und für Betreiber ohne Fachleute für Container, Datenbanken und Routing-Sicherheit dennoch unzugänglich bleiben. Paketierung, sinnvolle Voreinstellungen und ein stufenweiser Weg von der Überwachung über die Erkennung bis zur Abwehr können darüber entscheiden, ob sich die Architektur weiter verbreitet als eine weitere Forschungsarbeit.

Das eigentliche Produkt ist ein gesteuerter Rückkopplungskreislauf

ARTEMIS macht BGP nicht in einem Schritt vertrauenswürdig. Es legt einen Kreislauf um ein Protokoll, das ohne vollständige Autorisierung entwickelt wurde. Der Betreiber erklärt das beabsichtigte Routing. Öffentliche und lokale Datenquellen zeigen einen Teil des beobachteten Routings. Der Detektor identifiziert Abweichungen. Speicher und Oberflächen ordnen die Evidenz. Menschen oder genehmigte Automatisierung wählen eine Reaktion, und die Datenquellen zeigen anschließend, ob sich die Ausbreitung verändert. Der Vorfall kann mit dokumentierter Begründung abgeschlossen, ignoriert, zurückgenommen, eskaliert oder ruhend belassen werden.

Dieser Kreislauf ist der dauerhafteste Beitrag des Projekts. Er erkennt an, dass Routing-Sicherheit weder ein einmaliges Zertifikat noch ein entfernter Alarm ist. Sie ist eine Betriebspraxis, in der Richtlinien ausdrücklich formuliert, Beobachtungen mit Herkunftsnachweisen aufbewahrt und Reaktionsbefugnisse vor einem Notfall vorbereitet werden müssen. Der Wert des Systems liegt darin, Unsicherheit schnell genug zu verringern, damit das Netz handeln kann, und nicht darin, vorzugeben, die Unsicherheit sei verschwunden.

Die Grenzen sind ebenso aufschlussreich. Routenkollektoren liefern nur partielle Sichtbarkeit. Die Sollbeschreibung kann veraltet sein. Evidenz aus der Steuerungsebene kann weder Motive noch sämtliche Auswirkungen auf den Verkehr beweisen. Eine technisch gültige Gegenmaßnahme kann gefiltert werden oder Schaden verursachen. Auch Open-Source-Code benötigt dauerhafte Wartung. ARTEMIS ist am stärksten, wenn diese Grenzen in den Ablauf eingebaut und nicht hinter der Schlagzeile einer Reaktion innerhalb einer Minute verborgen werden.

Eine BGP-Anomalie kann ein Network Operations Center, ein Security Operations Center oder beide erreichen. Das Routing-Team versteht Präfixe, Upstream-Richtlinien und die Risiken geänderter Ankündigungen. Das Sicherheitsteam ist möglicherweise besser darauf vorbereitet, Identitäten, Diensttelemetrie und mögliche böswillige Aktivitäten miteinander zu verknüpfen. ARTEMIS überschreitet diese Zuständigkeitsgrenzen. Das ist nur dann nützlich, wenn die Warnung genügend Evidenz enthält, damit beide Teams vom selben Ereignis ausgehen, statt getrennte Untersuchungen mit unterschiedlichen Annahmen zu beginnen.

Die Übergabe sollte zwischen Beobachtung, Richtlinie und Auswirkung unterscheiden. Das System beobachtete eine Route an benannten Datenquellen. Die Route verstieß gegen eine bestimmte Sollregel. Dienstprüfungen oder RIPE-Atlas-Sonden zeigten eine definierte Auswirkung, oder eine Auswirkung wurde noch nicht festgestellt. Der Betreiber kontaktierte einen Upstream-Anbieter oder Routenursprung, und eine Antwort steht noch aus.

Diese Struktur verhindert, dass das NOC ein Sicherheitsproblem als gewöhnliches Routing abtut, und hindert das SOC daran, eine nicht autorisierte Ankündigung als Angriff zu bezeichnen, bevor die betrieblichen Tatsachen bekannt sind.

Eine gemeinsame Sprache verbessert auch das Lernen nach Vorfällen. Ein Fall kann als geplante, in der Richtlinie fehlende Änderung, versehentliches Route Leak, vermutete Routenübernahme, bestätigtes böswilliges Ereignis oder ungeklärte Anomalie abgeschlossen werden. Diese Ergebnisse sollten in Regeln, Ablaufpläne und Vereinbarungen mit Upstream-Anbietern zurückfließen. Ohne diesen Kreislauf kann der Detektor zu einer Maschine für die Erzeugung von Tickets werden statt zu einem System, das die Routing-Kontrolle verbessert.

Die schnellste Warnung ist nicht immer die nützlichste. Ein Detektor kann bei der ersten unerwarteten Aktualisierung auslösen und den Einsatzkräften die Feststellung überlassen, dass die Datenquelle veraltet, die Route geplant oder ein neuer Ursprung vom vermeintlichen Opfer autorisiert war. Umgekehrt kann das Warten auf jeden Kollektor und jeden Test auf der Datenebene den Vorteil einer frühen Reaktion zunichtemachen.

ARTEMIS benötigt eine Kennzahl zwischen reiner Erkennungslatenz und endgültigem Vorfallsabschluss: die Zeit, die erforderlich ist, um genügend vertrauenswürdige Evidenz zusammenzustellen, damit der autorisierte Betreiber eine vertretbare Entscheidung treffen kann.

Diese Kennzahl lässt sich aufteilen. Wie schnell traf die erste Beobachtung ein? Wie viele unabhängige Datenquellen bestätigten sie? War die relevante Richtlinie aktuell? Ergänzten RPKI oder lokales BMP weitere Evidenz? Wie lange dauerten Dienstprüfungen? Wann erhielt die verantwortliche Person die Warnung, und wann wurde eine Reaktion genehmigt? Erzielte die Gegenmaßnahme die beabsichtigte Ausbreitung, und wurde sie ordnungsgemäß zurückgenommen? Diese Fragen zeigen, wo Verzögerung tatsächlich entsteht, statt das gesamte Ergebnis dem Erkennungsalgorithmus zuzuschreiben.

Eine Kennzahl für belastbare Entscheidungen verhindert zudem gefährliche Optimierung. Das System sollte nicht dafür belohnt werden, schneller zu handeln, wenn es dabei weniger Evidenz verwendet oder unnötige Routing-Änderungen erzeugt. Der beste Einsatz verringert Unsicherheit und Reaktionszeit gemeinsam und bewahrt zugleich einen Datensatz, der nach dem Vorfall geprüft werden kann.