Kurzfassung

  • ARTEMIS ist ein quelloffenes System, das vom Betreiber selbst bereitgestellt wird. Es gleicht aktuelle BGP-Beobachtungen mit der lokal definierten Routing-Absicht ab und ergänzt Kontext, den öffentliche Kollektoren allein nicht liefern können.
  • Eine Studie von FORTH und CAIDA aus dem Jahr 2018 berichtete unter den getesteten Bedingungen von einer Erkennung binnen Sekunden und einer Neutralisierung in weniger als einer Minute; dies ist keine allgemeine Garantie für den Produktionsbetrieb.
  • Zur Eindämmung kann ARTEMIS spezifischere Routen ankündigen oder eigene Verfahren auslösen. Filter, veraltete Richtlinien, unvollständige Sichtbarkeit und weitreichende Berechtigungen können eine schnelle Reaktion jedoch in einen zweiten Vorfall verwandeln.
  • Die Tragfähigkeit des Projekts hängt nun von Release-Disziplin, überzeugenden Nachweisen zur Einführung und einer transparenten Abgrenzung gegenüber Code BGP ab: Kommerzielle Betreuung kann den offenen Code stützen, ohne die Geschichte des Forschungsprojekts zu ersetzen.

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

Im CAIDA-Jahresbericht 2019 heißt es, ARTEMIS habe binnen weniger Sekunden eine reale Routenübernahme erkannt, die ein /30-Präfix von Internet2 betraf. Der Fall ist wichtig, weil er die Evidenz über synthetische, von den Forschenden selbst vorbereitete Ankündigungen hinausführt. In einem an der Einführung beteiligten Netz änderte sich tatsächlich eine Route, und das System erkannte die Abweichung schnell genug, um die Untersuchung zu unterstützen.

Der Bericht liefert keine allgemeingültige Verteilung der Erkennungszeiten. Das /30 war ein bestimmtes Präfix in einem bestimmten Routing-Kontext, beobachtet über die Quellen, die genau dieser Bereitstellung zur Verfügung standen. Ein anderer Vorfall kann sich anders ausbreiten, kürzer dauern oder die angeschlossenen Kollektoren überhaupt nicht erreichen. Der Bericht belegt für sich genommen auch keine böswillige Absicht und beschreibt nicht sämtliche Auswirkungen auf der Datenebene.

Die sachgerechte Schlussfolgerung ist enger: Im Rahmen des CAIDA-Einführungsprogramms erkannte ARTEMIS einen dokumentierten realen Vorfall binnen weniger Sekunden.

Praxisfälle sind gerade dann wertvoll, wenn ihre Grenzen erhalten bleiben. Sie zeigen, wie sich das Programm bei einer realen Änderung verhält, wie der Betreiber gewarnt wird und welche Belege nach dem Ereignis bestehen bleiben. Für die Bewertung der Produktionsreife wären zusätzliche Vorfallsaufzeichnungen – einschließlich Fehlalarmen, übersehenen Ereignissen und Ergebnissen der Eindämmung – hilfreicher als eine weitere eindrucksvolle Zeitangabe.

Eine BGP-Warnung kann binnen 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 erschien und sich auszubreiten begann. Das teilt dem Betreiber mit, dass die Kontrollebene nicht mehr dem erwarteten Bild entspricht. Ein solcher Beleg stellt für sich genommen jedoch nicht fest, wer die Änderung vorgenommen hat, ob sie irrtümlich war, ob der Verkehr dem neuen Pfad folgte, ob Nutzer betroffen waren und welche Maßnahme den Dienst wiederherstellt, ohne ein neues Problem zu erzeugen.

ARTEMIS wurde genau für den Zwischenraum zwischen Erkennung und Handlung entwickelt. Der Name steht für Automatic and Real-Time dEtection and MItigation System, doch die ungewöhnliche Groß- und Kleinschreibung sollte das Betriebsmodell nicht verdecken. Es handelt sich nicht um einen zentralen Dienst, der das gesamte Internet sieht und fremde Netze aus der Ferne repariert.

Eine Organisation stellt das Programm in ihrer kontrollierten Infrastruktur bereit, definiert den als legitim betrachteten Routing-Zustand, bindet öffentliche und private Beobachtungen ein und entscheidet, wie weit das System gehen darf, wenn tatsächliche Daten von der Richtlinie abweichen. Das Versprechen des Projekts ist kontextbezogene Geschwindigkeit; seine Grenze besteht darin, dass sowohl Kontext als auch Befugnisse lokal bleiben.

ARTEMIS ist daher eher ein Instrument im Leitstand des Betreibers als eine „Internetpolizei“. Es kann Belege ordnen, die Suche in Routing-Updates verkürzen und eine zuvor abgestimmte Reaktion vorbereiten. Es nimmt dem Betreiber jedoch nicht die Notwendigkeit einer eigenen Beurteilung ab. Die endgültige Entscheidung kann sich auf das globale Routing, Beziehungen zu vorgelagerten Netzen und den Kundenverkehr auswirken. Die Qualität der Reaktion hängt deshalb von Menschen, Konfiguration und eingeübten Befugnissen ebenso stark ab wie vom Detektor.

BGP übermittelt Erreichbarkeit, bevor es Berechtigungen belegen kann

Das Border Gateway Protocol ermöglicht unabhängig verwalteten Netzen, Informationen über Erreichbarkeit auszutauschen und eigene Richtlinien anzuwenden. Ein autonomes System kündigt an, Verkehr zu bestimmten IP-Präfixen zustellen zu können; benachbarte Netze entscheiden, ob sie diese Routen annehmen, bevorzugen und weiterverbreiten. Dieses Modell ließ das Internet organisationsübergreifend ohne zentrale Steuerung skalieren. 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 schlechte Ankündigung attraktiv machen. Wenn zwei Routen Präfixe derselben Länge abdecken, wenden Netze ihre Richtlinien und Pfadauswahlregeln an. Kündigt ein Angreifer oder ein fehlerhaft konfiguriertes Netz ein spezifischeres Unterpräfix an, lenkt die übliche Regel des längsten Präfixabgleichs den Verkehr in der Regel überall dort auf die engere Route, wo sie angenommen wurde. Dies ist keine besondere Angriffsfunktion, sondern die normale Regel zur Auswahl des präzisesten Ziels.

Deshalb kann eine äußerlich kleine Ankündigung den Verkehr schnell an sich ziehen, selbst wenn die legitime aggregierte Route weiterhin sichtbar bleibt.

Der Begriff „Übernahme“ ist als Kurzform praktisch, kann aber eine Absicht unterstellen, die Routing-Nachrichten nicht offenlegen. Ein nicht autorisierter Ursprung kann böswillig oder versehentlich sein oder mit einer legitimen geschäftlichen Änderung zusammenhängen, die nicht in die Überwachungsrichtlinie aufgenommen wurde. Ein manipulierter Pfad kann zum Abfangen von Verkehr dienen, doch ein einzelnes Update der Kontrollebene beweist nicht, dass ein Abfangen tatsächlich stattfand.

ARTEMIS ist am nützlichsten, wenn es eine Warnung als Abweichung zwischen beobachtetem und beabsichtigtem Routing behandelt und Attribution sowie Folgenabschätzung dem umfassenderen Reaktionsprozess überlässt.

Ein Ereignis mit identischem Präfix konkurriert mit der legitimen Route gleicher Länge. Das Ausmaß der Verbreitung hängt von den Richtlinien und der Pfadauswahl in den Netzen ab, die beide Ankündigungen erhalten haben. Teile des Internets können die unerwartete Route bevorzugen, während andere weiterhin den rechtmäßigen Ursprung verwenden. Das Ergebnis kann partielle Erreichbarkeit, regionale Unterschiede und eine verwirrende Mischung aus Erfolgen und Ausfällen statt einer einzigen klaren Störung sein. Die Erkennung muss daher nicht nur das Vorhandensein einer Route berücksichtigen, sondern auch, wo und wie sie sich verbreitet.

Ein Unterpräfix-Ereignis zieht Verkehr gewöhnlich stärker an, weil die Regel des längsten Präfixes der engeren Route Vorrang gibt. Kündigt ein Netz normalerweise ein /20 an und ein anderer Ursprung ein darin enthaltenes /24, leiten Router, die das /24 angenommen haben, den dafür bestimmten Verkehr üblicherweise zum Unterpräfix. Deaggregation ist zugleich eine verbreitete Abwehr: Der legitime Betreiber kündigt gleich spezifische oder noch spezifischere Routen an, um die Bevorzugung zurückzugewinnen. Die Methode hat jedoch eine harte Grenze: Viele Netze filtern IPv4-Routen länger als /24 und IPv6-Routen länger als /48.

Wenn ein Betreiber bereits Präfixe dieser Länge ankündigt, steht ihm möglicherweise keine weltweit akzeptierte engere Route zur Verfügung.

ARTEMIS berücksichtigt außerdem „Squatting“ und bestimmte Richtlinienverstöße, darunter das in den Projektunterlagen beschriebene No-Export-Szenario. Diese Kategorien sind wichtig, weil ein Routing-Vorfall nicht immer darin besteht, dass ein fremdes Netz das Präfix eines Opfers ankündigt. Eine Route kann einen erlaubten Ursprung haben und dennoch über eine unerwartete Beziehung austreten. Ein Überwachungssystem benötigt ausreichend Richtlinienkontext, um solche Fälle zu unterscheiden, ohne vorzugeben, BGP-Daten legten sämtliche privaten Vereinbarungen zwischen Netzen offen.

ARTEMIS integriert die Routing-Absicht des Betreibers in den Detektor

Externe Überwachungsdienste haben einen offensichtlichen Vorteil: Sie sammeln Daten aus vielen Teilen des Internets, ohne jedes Netz zur Bereitstellung eines vollständigen Systems zu zwingen. Ebenso offensichtlich ist der Nachteil. Ein Dritter sieht angekündigte Präfixe und Pfade, weiß aber möglicherweise nicht, welche Ursprungswechsel, Ersatzanbieter, Verfahren zur Verkehrssteuerung oder Notfallankündigungen der Betreiber für zulässig hält. Allgemeine Regeln können daher einen subtilen Richtlinienverstoß übersehen oder wegen einer geplanten Änderung Alarm schlagen.

ARTEMIS verändert den Beobachtungspunkt. Der Detektor wird von der Organisation betrieben, deren Adressraum gefährdet ist, und diese legt auch die Referenz fest. Öffentliche Kollektoren liefern weiterhin einen breiten externen Überblick, doch ihre Beobachtungen werden anhand privaten Wissens über geschützte Präfixe, erlaubte Ursprungs-AS, zulässige Nachbarn und ausgewählte Pfadbeziehungen interpretiert. Lokale Datenströme von Routern ergänzen Ereignisse, die öffentliche Kollektoren nicht sehen.

Darin liegt die prägende Idee des Projekts: Unvollständige globale Daten werden nützlicher, wenn sie mit einer ausdrücklich definierten lokalen Absicht abgeglichen werden.

Mit der Platzierung des Detektors im geschützten Netz verlagert sich auch die Verantwortung dorthin. Die Organisation, die ARTEMIS betreibt, muss entscheiden, wem die Richtliniendatei gehört, wie Änderungen geprüft werden, welche Warnungen das Netzbetriebszentrum erreichen, welche Schlussfolgerungen das Sicherheitsteam ziehen darf und wer eine neue Routenankündigung genehmigen kann. Das Programm macht diese Verantwortung sichtbar. Es kann eine Institution nicht dazu zwingen, sie gut wahrzunehmen.

ARTEMIS fordert den Betreiber auf, geschützte Präfixe, legitime autonome Ursprungssysteme, akzeptable Nachbarschaftsbeziehungen und ausgewählte Routing-Regeln zu definieren. Mit dieser Referenz kann der Detektor eine präzisere Frage stellen als ein universeller externer Dienst. Statt zu beurteilen, ob eine Route vor dem Hintergrund der weltweiten Historie ungewöhnlich wirkt, prüft das System, ob sie die erklärte Absicht eines bestimmten Netzes verletzt.

Der Vorteil ist nur so zuverlässig wie diese Erklärung selbst. Netze wechseln Anbieter, fügen Anycast-Standorte hinzu, verlagern Ursprungs-AS, richten vorübergehende Ersatzpfade ein und veröffentlichen bei Störungen Notfallankündigungen. Eine im Januar korrekte Richtlinie kann bis Juni veraltet sein. Erreicht eine Änderung die Router, nicht aber ARTEMIS, kann der Detektor einen schwerwiegenden Fehlalarm auslösen. Werden Regeln zur Unterdrückung von Störmeldungen übermäßig erweitert, kann ein echter Verstoß auf dem Papier als „erlaubt“ erscheinen.

Damit verwandelt das System eine technische Konfiguration in eine institutionelle Vereinbarung. Routing-Techniker, Sicherheitsabteilung und Änderungsmanagement müssen sich darüber einigen, was die Datei bedeutet, wer sie bearbeiten darf und wie schnell sie dem Produktionsnetz folgt. Lokaler Kontext beseitigt falsch-positive und falsch-negative Ergebnisse nicht; er verlagert ihre wichtigste Ursache dorthin, wo der Betreiber sie steuern kann.

Eine Routing-Sicherheitsregel verdient dieselbe Disziplin wie Programmcode, der den Kundenverkehr beeinflussen kann. Änderungen benötigen benannte Verantwortliche, Prüfung, Versionshistorie, Tests und eine mit einer genehmigten Netzänderung verknüpfte Begründung. Der Betreiber muss beantworten können, wann ein Präfix, Ursprung oder Nachbar hinzugefügt wurde, wer dies genehmigte und welcher Vorfall oder welches Projekt die Entscheidung begründete. Eine gewöhnliche Konfigurationsdatei kann einen solchen Prozess unterstützen, jedoch nur, wenn die Organisation sie nicht als einmaligen Teil der Installation behandelt.

Tests sollten positive und negative Szenarien umfassen. Eine geplante legitime Route muss ohne Alarm passieren. Die Ankündigung eines identischen Präfixes durch einen unzulässigen Ursprung sollte erwartungsgemäß klassifiziert werden. Ein Unterpräfix-Ereignis muss die richtige Schwere auslösen, und ein No-Export-Verstoß darf nicht mit einer Ursprungsübernahme verwechselt werden. Historische Wiedergabe hilft bei der Prüfung dieser Fälle; eine Testumgebung bestätigt, dass Benachrichtigungen und Eindämmungsverfahren die erwarteten Daten erhalten.

Diese Disziplin begrenzt auch organisatorische Drift. Wenn die Person, die ARTEMIS erstmals bereitgestellt hat, die Organisation verlässt, muss die Richtlinie für den nächsten Betreiber verständlich bleiben. Ein Detektor, dessen Logik von undokumentiertem Erinnerungswissen abhängt, ist keine zuverlässige Infrastruktur – selbst wenn sein Code offen ist und die Quellen mit geringer Verzögerung arbeiten.

FORTH und CAIDA machten aus einer Forschungsfrage einen Betriebsablauf

Das Projekt entstand durch die Zusammenarbeit von Forschenden der Foundation for Research and Technology-Hellas im Umfeld der Universität Kreta und von CAIDA an der University of California, San Diego. FORTH brachte Fachwissen zu Routing-Schutz und Systemtechnik ein. CAIDA ergänzte Infrastruktur zur Internetmessung, Erfahrung mit BGPStream und Beziehungen, die halfen, die Entwicklung in Forschungs- und Bildungsnetze zu überführen. ARTEMIS war daher von Beginn an mehr als ein Erkennungsalgorithmus: Das Projekt verband Protokollwissen, Messsysteme und Zugang zu Betreibern.

Die Finanzierung folgte demselben gemischten institutionellen Modell. In der Projektgeschichte erscheinen europäische und amerikanische Forschungsprogramme, der Community Projects Fund des RIPE NCC, ein NSF-EAGER-Einführungsprojekt, das US-Heimatschutzministerium und der Comcast Innovation Fund. Die Unterstützung von RIPE im Jahr 2017 half, den Prototyp in ein Werkzeug für Betreiber zu verwandeln; ein Zuschuss von 50.000 Euro finanzierte 2019 die Prüfung der Datenebene mit RIPE Atlas.

Diese Mittel zeigen, wie gemeinnützige Forschung zu einsetzbarer Software wurde, legen aber nicht die heutigen Kosten für die Betreuung produktiver Installationen offen.

Die institutionelle Geschichte ist für eine korrekte Zuordnung wichtig. ARTEMIS ist weder eine eigenständig gegründete Stiftung noch ein CAIDA-Dienst oder ein FORTH gehörender globaler Detektor. Es handelt sich um quelloffene Software unter der BSD-3-Clause-Lizenz, mit Forschungstradition und einem heutigen kommerziellen Betreuer. Seine Entwicklung lässt sich zutreffender als Abfolge von Kooperationen denn als Eigentum einer einzelnen Organisation beschreiben.

Der erste öffentliche Meilenstein war eine Demonstration auf der ACM SIGCOMM 2016. Der zentrale Schritt bestand darin, Überwachung und Eindämmung in einer Schleife zu verbinden. Viele Systeme können eine verdächtige Route erkennen, nachdem Daten gesammelt wurden. ARTEMIS stellte eine andere Frage: Kann ein Betreiber ein Ereignis früh genug sehen und bereits eine praktische Gegenmaßnahme vorbereitet haben, damit der Vorfall nicht stundenlang zwischen Dashboards, E-Mails und manuellen Router-Sitzungen weitergereicht wird?

Eine Demonstration ist keine ausgereifte Produktionsbereitstellung. Sie zeigt, dass Komponenten in einer vorgegebenen Konfiguration zusammenarbeiten können und dass die Forschungsfrage konkret genug für einen öffentlichen Versuch ist. Die Arbeit von 2016 bestimmte jedoch die weitere Richtung: Live-Beobachtungen, eine interne Darstellung des legitimen Routings, Klassifizierung und eine vorbereitete Ankündigung. Diese Abfolge machte die Reaktionszeit von einer organisatorischen Nachbetrachtung zu einer Systemeigenschaft.

Das Projekt wurde durch Berichte von Betreibern beeinflusst, nach denen die Reaktion auf eine Routenübernahme Stunden dauern konnte. Die Verzögerung entstand nicht nur durch langsame Kollektoren. Teams mussten die Zugehörigkeit des Präfixes bestätigen, die Verbreitung untersuchen, klären, ob die Änderung geplant war, die richtigen Ansprechpartner beim Anbieter finden und eine sichere Gegenankündigung vorbereiten. ARTEMIS verkürzt mehrere dieser Schritte, indem es Richtlinien und Verfahren neben der Überwachung hält. Die menschlichen und geschäftlichen Beziehungen rund um eine Route bleiben jedoch außerhalb des Codes.

Der 2018 in IEEE/ACM Transactions on Networking erschienene Beitrag formulierte die einprägsamste Aussage zu ARTEMIS: die Neutralisierung einer BGP-Übernahme innerhalb einer Minute. Die Forschenden testeten den Ansatz in realen Experimenten und berichteten unter den geprüften Bedingungen von einer Erkennung binnen Sekunden und einer Eindämmung vor Ablauf einer Minute. Das Ergebnis war bedeutsam, weil es zeigte, dass das betroffene Netz nicht zwingend auf einen externen Dienst, eine Reihe von Telefonaten und eine manuell erstellte Gegenankündigung warten muss.

Die Aussage wird irreführend, wenn sie vom Experiment getrennt wird. Die Erkennungszeit hängt davon ab, ob das Ereignis einen angeschlossenen Beobachter erreicht, wie schnell die Quelle das Update liefert, ob die Detektorregeln passen und ob das System selbst ordnungsgemäß arbeitet. Die Eindämmungszeit hängt von der Präfixlänge des Opfers, seinen Routing-Befugnissen, den Filtern der Anbieter, der Verbreitung und dem gewählten Genehmigungsverfahren ab. Ein Netz mit verpflichtender menschlicher Bestätigung kann eine sicherere Entscheidung treffen und mehr Zeit benötigen.

Ein Netz mit sofortiger Automatisierung reagiert schneller, übernimmt jedoch zusätzliches Risiko.

Eine verantwortungsvolle Schlussfolgerung muss begrenzt bleiben. ARTEMIS zeigte, dass ein eng integriertes betreiberseitiges System einen zuvor häufig wesentlich längeren Prozess stark verkürzen kann. Es bewies nicht, dass jede Übernahme sichtbar ist, jede Gegenroute angenommen wird oder jedes Produktionsteam eine autonome Deaggregation erlauben sollte. Das Ergebnis ist als experimentell bestätigtes Entwicklungsziel zu lesen, nicht als universelle Garantie.

Mehrere unvollständige Ansichten ergeben ein brauchbares Vorfallsbild

ARTEMIS kann mehrere öffentliche Quellen verwenden, weil kein Kollektor sämtliche Routen sieht. RIPE RIS und das RouteViews-Projekt der University of Oregon beziehen BGP-Updates von ausgewählten Peers an verteilten Sammelpunkten. CAIDA BGPStream stellt einen gemeinsamen Mechanismus für Zugriff und Normalisierung von Routing-Daten aus mehreren Quellen bereit. Jeder Dienst erweitert das Sichtfeld des Betreibers, spiegelt aber nur die Netze wider, die sich mit seinen Kollektoren verbunden haben, sowie die Geografie dieser Sitzungen und die zeitlichen Eigenschaften der Datenströme.

Partielle Sichtbarkeit hat praktische Folgen. Ein Ereignis kann sich in einer Region verbreiten, ohne einen einzigen an die jeweilige Bereitstellung angeschlossenen Kollektor zu erreichen. Eine sehr kurze Ankündigung kann zurückgezogen werden, bevor der Datenstrom sie liefert. Eine Route kann Kunden des Opfers über eine private Beziehung betreffen, die in offenen Daten nicht vertreten ist. Die Kombination mehrerer Kollektoren reduziert einige blinde Flecken, liefert aber nur eine größere Stichprobe und keine allwissende Kopie der globalen Kontrollebene.

Die richtige betriebliche Frage lautet daher nicht „Hat ARTEMIS das Internet gesehen?“, sondern „Welche Beobachter sahen diese Ankündigung, wie schnell sahen sie sie und welcher Teil des Ereignisses könnte außerhalb der Stichprobe geblieben sein?“ Diese Formulierung fördert die Erhaltung der Herkunft jeder Warnung und verhindert, dass das Fehlen in einem einzelnen Datenstrom als Beweis dafür gilt, dass die Route nicht existierte.

RIPE NCC stellte im Februar 2019 einen öffentlichen Prototyp von RIS Live vor, um BGP-Nachrichten mit wesentlich geringerer Verzögerung als bei der periodischen Verarbeitung von Archiven bereitzustellen. ARTEMIS war eines der Beispiele für den Bedarf an einem solchen Datenstrom. Ein Sicherheitssystem kann nicht binnen Sekunden reagieren, wenn seine wichtigste Beobachtung erst viele Minuten später eintrifft. Ein Echtzeitstrom ermöglicht dem Detektor dagegen, Updates beim Eingang an den Kollektoren auszuwerten.

Eine geringere Verzögerung verändert die Beobachtungsgrenzen nicht. RIS Live bildet weiterhin die mit dem RIPE Routing Information Service verbundenen Peers und die von ihnen exportierten Routen ab. Bleibt eine Übernahme lokal, wird sie vor dem Kollektor gefiltert oder betrifft sie einen durch eine andere Beziehung verborgenen Pfad, kann der entscheidende Beleg im Datenstrom fehlen. Auch Zuverlässigkeit ist wichtig: Ein Ausfall des Datenstroms oder eine änderung wirkt wie Stille, wenn die Überwachung nicht zwischen „keine verdächtigen Routen“ und „keine Daten“ unterscheidet.

Deshalb ist der Zustand einer Quelle Bestandteil des Sicherheitsmodells. Der Betreiber muss wissen, ob jeder Monitor zeitnah arbeitet, verspätet ist, abgeschaltet wurde oder ein ungewöhnliches Update-Volumen liefert. Ein Detektor, der bei beeinträchtigten Eingangsdaten selbstbewusst Normalität meldet, kann gefährlichere Unkenntnis erzeugen als ein offensichtlicher Ausfall.

Echtzeitüberwachung beantwortet die Frage, was gerade erscheint; Routing-Informationsbanken und Update-Archive liefern Kontext. RIPE RIS und RouteViews veröffentlichen historische Daten, anhand derer sich Ursprünge und Pfade vor dem Vorfall, der Beginn der Änderung und ihre Dauer erkennen lassen. CAIDA BGPStream vereinfacht die Verarbeitung dieser Aufzeichnungen über einen gemeinsamen Mechanismus und ermöglicht ARTEMIS, Ereignisse wiederzugeben und Regeln anhand früheren Routing-Verhaltens zu prüfen.

Die Wiedergabe ist für technische Tests und Analysen nützlich. Ein Team kann feststellen, ob eine neue Regel ein bekanntes Ereignis erkannt hätte, die Abfolge bis zu einer Warnung rekonstruieren oder Einsatzkräfte schulen, ohne eine aktive Produktionsroute zu verändern. Historische Daten zeigen außerdem wiederkehrende Ankündigungen, die einzeln anomal wirken, aber zu einem etablierten Ersatzverfahren gehören. Die Grenze bleibt bestehen: Das Archiv erfasst die Sicht der Kollektoren, nicht das gesamte Ereignis, und eine frühere Topologie bildet nicht jede aktuelle Beziehung nach.

Eine ausgereifte Bereitstellung kann die Wiedergabe in das Änderungsmanagement aufnehmen. Bevor ein neuer Ursprung, Anbieter oder eine Exportregel produktiv eingesetzt wird, prüft der Betreiber die aktualisierte Referenz anhand repräsentativer historischer Daten und stellt sicher, dass normales Routing nicht zu einem dauerhaften Alarm wird. Die Detektorkonfiguration wird damit zu einem prüfbaren Sicherheitsartefakt statt zu einer Datei, die erst nach dem Auftreten von Störmeldungen bearbeitet wird.

Öffentliche Daten sind nur eine Seite der Architektur. ARTEMIS kann lokale Updates über ExaBGP oder private Sitzungen des BGP Monitoring Protocol beziehen. ExaBGP arbeitet als programmierbarer BGP-Sprecher und leitet Ereignisse an andere Anwendungen weiter. BMP ermöglicht Routern, Routing-Informationen an ein Überwachungssystem zu exportieren, ohne dieses an der Paketweiterleitungsentscheidung zu beteiligen. Solche Quellen zeigen die eigenen Nachbarschaften und den Routenzustand des geschützten Netzes, bevor die Informationen einen öffentlichen Kollektor erreichen.

Lokale Datenströme verbessern Aktualität und Kontext, bringen jedoch sensible Infrastrukturinformationen in die Plattform ein. BMP-Daten können umfangreich sein und interne Routing-Beziehungen offenlegen. Die Integration von ExaBGP erfordert strenge Kontrollen, weil dieselbe programmierbare Schnittstelle Routen nicht nur beobachten, sondern auch ankündigen kann. Zugangsdaten, Netzzugriff, Nachrichtenprüfung und die Trennung von Überwachung und Eindämmung werden zu Sicherheitsgrenzen.

Eine gut konzipierte Bereitstellung verwendet öffentliche und private Datenströme für unterschiedliche Aufgaben. Öffentliche Kollektoren zeigen die Verbreitung einer Ankündigung außerhalb der unmittelbaren Umgebung des Betreibers. Lokale Quellen zeigen, was das Netz selbst und seine Router beobachtet haben. Eine Abweichung zwischen beiden ist nicht zwingend ein Fehler; sie kann belegen, wo die Verbreitung endete oder eine Richtlinie wirkte.

Die Anwendung trennt Beobachtung, Erkennung und Belege

Die moderne Plattform ist eine aus mehreren Containern bestehende Microservice-Anwendung und nicht nur ein einzelnes Skript, das einen Datenstrom liest. Überwachungsdienste verbinden sich mit öffentlichen und privaten Quellen, normalisieren eingehende BGP-Informationen und veröffentlichen Ereignisse. Erkennungsdienste beziehen diese Ereignisse und wenden die Regeln des Betreibers an. Um den Kern liegen Speicher, API, Weboberfläche, Benachrichtigungen und Überwachung. Die Trennung erlaubt Komponenten, unabhängig zu skalieren oder auszufallen, und erleichtert das Hinzufügen einer neuen Quelle, ohne das gesamte System neu zu schreiben.

Die Modularität vervielfacht zugleich die Abhängigkeiten. Ein Monitor kann ordnungsgemäß arbeiten, während der Detektor angehalten ist. Der Nachrichtenbus nimmt Ereignisse an, obwohl die Datenbank nicht verfügbar ist. Die Weboberfläche zeigt einen alten Vorfall, während der Live-Verarbeitungspfad unterbrochen ist. Der Orchestrator startet einen Container neu und verbirgt damit wiederholte Abstürze. Betriebsprüfungen müssen deshalb den vollständigen Weg von der Quelle bis zur Warnung abdecken und dürfen nicht nur melden, dass einzelne Container laufen.

Docker Compose senkt die Einstiegshürde für eine kontrollierte Bereitstellung; die Unterstützung von Kubernetes eignet sich für Organisationen, die bereits Containerplattformen betreiben. Keine der beiden Varianten macht das System zu einem global verwalteten Dienst. Das bereitstellende Netz bleibt für Kapazität, Updates, Geheimnisse, Speicher, Sicherungen und Notfallzugriff verantwortlich.

Der Nachrichtenbus ermöglicht Überwachungs-, Erkennungs- und Benachrichtigungsdiensten den Austausch von Ereignissen, ohne sämtliche Prozesse direkt einer einzigen Instanz unterzuordnen. Dieses Modell kann Update-Spitzen auffangen und Verbrauchern unterschiedliche Verarbeitungsgeschwindigkeiten erlauben. Es wirft jedoch auch Fragen nach Reihenfolge, Duplikaten und Rückstau auf. Ein Routing-Vorfall kann Tausende Updates, Rücknahmen und Pfadänderungen erzeugen. Das System muss daher genügend Abfolge und Herkunft bewahren, damit der Betreiber den Verlauf rekonstruieren kann.

Dauerhafter Speicher verschafft ARTEMIS einen Vorteil gegenüber einer einmaligen Warnung. Updates, Warnungen, Konfigurationsstände und Vorfallsentscheidungen können für spätere Analysen aufbewahrt werden. In der Architektur kamen PostgreSQL-Komponenten, Speicher nach dem Timescale-Prinzip und das Hasura-API-Ökosystem zum Einsatz. Diese Lösungen unterstützen Abfragen und Integrationen, schaffen aber zugleich ein sensibles Archiv von Routing- und Betriebsbelegen, das Aufbewahrungsfristen, Zugriffskontrollen und zuverlässige Sicherungen benötigt.

Prüfbarkeit ist nicht mit Gewissheit gleichzusetzen. Eine vollständige Aufzeichnung der empfangenen Daten kann belegen, wie ARTEMIS zu einer Warnung gelangte. Sie beweist nicht, dass das System alle wesentlichen Routen sah oder die Betreiberregeln korrekt waren. Die Datenbank sollte daher Quelle und Vertrauensgrad speichern, nicht nur die endgültige Vorfallskennzeichnung.

Die Weboberfläche stellt Vorfälle, Systemzustand und Routing-Beobachtungen in einer für ein Netzbetriebs- oder Sicherheitszentrum geeigneten Form dar. Benachrichtigungen übermitteln Warnungen per E-Mail, an mobile Kanäle oder eigene Integrationen; Grafana-Dashboards zeigen den Dienstzustand und Ereignistrends. Diese Funktionen machen aus einem Forschungsmechanismus ein Betriebsprodukt: Ein Reaktionsteam benötigt Prioritäten, Historie und eine gemeinsame Sicht statt roher BGP-Updates.

Die Oberfläche kann auch falsche Sicherheit erzeugen. Eine rote Vorfallskarte ist eine Klassifizierung anhand von Beobachtungen und Regeln, kein unabhängiger Beweis für böswillige Absicht. Eine Karte oder Pfaddarstellung kann vollständig wirken, obwohl sie nur ausgewählte Kollektoren repräsentiert. Wenn geplante Änderungen nicht in der Richtlinie erscheinen, werden Benachrichtigungen zu Störgeräuschen; Alarmmüdigkeit erhöht dann die Wahrscheinlichkeit, ein tatsächlich wichtiges Ereignis zu übersehen.

Gute Praxis verbindet die Oberfläche mit einer Überprüfung. Die zuständige Person sollte die ursprünglichen Updates öffnen, öffentliche und lokale Datenströme vergleichen, den aktuellen RPKI-Status prüfen, Tests der Datenebene durchführen und dokumentieren können, warum ein Vorfall eskaliert, ignoriert oder geschlossen wurde. Ein Dashboard ist nützlich, wenn es diesen Weg verkürzt, nicht wenn es ihn ersetzt.

Ein Routing-Muster beweist weder Motiv noch Folgen

Die ARTEMIS-Forschung entwickelte eine Klassifizierung, die Ereignisse nach Präfixbeziehungen, Manipulationen des AS-Pfads, Richtlinien und möglichen Auswirkungen auf der Datenebene unterscheidet. Die Implementierung unterstützt anhand von Belegen der Kontrollebene eine bestimmte Teilmenge dieser Muster: identische Präfixe und Unterpräfixe mit falschem Ursprung, Squatting und bestimmte Exportverstöße. Die Klassifizierung gibt Betreibern eine gemeinsame Sprache und ermöglicht unterschiedliche Regeln für verschiedene Ereignisse.

Die Kategorien müssen an das gebunden bleiben, was die Daten tatsächlich zeigen. Ein Pfad, der mit einem unerwarteten Nachbarn beginnt, kann ein manipuliertes Segment, ein Routenleck oder eine zulässige, nicht in der Richtlinie dokumentierte Änderung bedeuten. Ein nicht autorisierter Ursprung kann ein Fehler statt eines Angriffs sein. Selbst eine absichtliche Ankündigung kann auf das Verwerfen von Verkehr, die Nachahmung eines Dienstes oder die Beobachtung von Transit ausgerichtet sein; BGP-Updates allein unterscheiden diese Folgen nicht.

Vorsichtige Terminologie schützt Genauigkeit und Reaktionsqualität. In der Warnphase sind „Verdacht auf Routenübernahme“ oder „Richtlinienverstoß“ gewöhnlich sicherer als das Wort „Angriff“. Eine stärkere Formulierung sollte erst nach Prüfung der Routenzugehörigkeit, Kontaktaufnahme mit dem Betreiber und Analyse von Daten der Übertragungsebene verwendet werden. Diese Zurückhaltung schwächt die Abwehr nicht; sie verhindert, dass ein Klassifikator Unsicherheit in eine Behauptung verwandelt, die andere Teams als Tatsache wiederholen.

BGP-Nachrichten beschreiben Aussagen über Erreichbarkeit und Pfade, die Netze untereinander austauschen. Sie zeigen nicht jedes Paket, das einer ausgewählten Route folgte. Nach einer verdächtigen Ankündigung kann Verkehr in einem schwarzen Loch enden, abgefangen und weitergeleitet werden, eine Antwort von einem nachgeahmten Dienst erhalten oder unverändert bleiben, wenn sich die Route in den Netzen der betreffenden Nutzer nicht verbreitet hat. Verschiedene Teile des Internets können gleichzeitig unterschiedliche Folgen erleben.

Diese Grenze ist für ARTEMIS zentral. Der Detektor kann zeigen, dass eine Route die Richtlinie des Betreibers verletzte und an bestimmten Beobachtungspunkten erschien. Er leitet kein Motiv aus dem AS-Pfad ab und garantiert nicht, dass ein Traceroute denselben Weg nimmt wie der Anwendungsverkehr. Verschlüsselung, DNS-Verhalten, Zwischenspeicherung, Anycast und Anwendungsumschaltungen verändern die Nutzererfahrung zusätzlich. Eine Warnung der Kontrollebene ist deshalb ein Beleg für einen Vorfall, aber nicht der gesamte Vorfall.

Eine nützliche Reaktion verbindet mehrere Aufzeichnungen. BGP-Daten belegen die Ankündigung und ihre Verbreitung. Tests der Datenebene prüfen Erreichbarkeit und Pfade von ausgewählten Standorten. Diensttelemetrie zeigt Fehler, Verzögerungen und Auswirkungen auf Kunden. Kontakte mit Anbietern klären, ob die Ankündigung genehmigt oder irrtümlich war. Keine Quelle ist vollkommen, doch zusammen ermöglichen sie eine Entscheidung, die ein einzelner Datenstrom nicht liefern kann.

Ein Zuschuss aus dem RIPE Community Projects Fund 2019 unterstützte die Erweiterung von ARTEMIS um Traceroute-Messungen mit RIPE Atlas, um die Auswirkungen erkannter Ereignisse zu bewerten. Die Arbeit erkannte damit eine Grenze der ursprünglichen Kontrollebenenschleife an. Eine Route kann in BGP gefährlich wirken und Nutzer kaum beeinträchtigen, während ein kleines Verbreitungsgebiet eine besonders wichtige Kundengruppe treffen kann. Messsonden der Datenebene liefern zusätzliche Informationen über den mutmaßlichen Verkehrspfad und die Erreichbarkeit von Endpunkten.

RIPE Atlas verfügt über ein verteiltes Netz von Sonden, deren Standorte jedoch ungleichmäßig verteilt sind; zudem kann das ausgewählte Ziel so antworten, dass der Pfad verborgen bleibt. Traceroute wird durch Filterung, Lastverteilung, Tunnel und asymmetrisches Routing beeinflusst. Der Hinweg von der Sonde zum Ziel muss nicht dem Rückweg des Kundenverkehrs entsprechen. Eine fehlgeschlagene Messung kann einen Ausfall, einen nicht antwortenden Knoten oder eine Einschränkung des konkreten Tests bedeuten.

Der praktische Gewinn besteht nicht in vollständiger Gewissheit, sondern in besserer Priorisierung. Wenn BGP-Kollektoren ein nicht autorisiertes Unterpräfix zeigen und Sonden in mehreren Regionen die Erreichbarkeit verlieren oder den Pfad zu einem unerwarteten Ursprung ändern, bestehen stärkere Gründe für eine Eskalation. Ist das Ereignis der Kontrollebene nur bei einem Kollektor sichtbar und bleiben die Tests stabil, kann das Team weiter untersuchen, bevor es globale Ankündigungen verändert. Die Entscheidung bleibt kontextabhängig, wird aber mit weniger Blindheit getroffen.

Deaggregation gewinnt Verkehr nur zurück, wenn das Routing-System sie zulässt

Die bekannteste Reaktion von ARTEMIS ist die Deaggregation. Ein Opfer, das ein breites Präfix ankündigt, kann spezifischere Routen veröffentlichen, damit die normale Auswahl des längsten Präfixes den Verkehr zum legitimen Netz zurückführt. Die Methode nutzt das Standardverhalten von BGP und kann sich schnell ausbreiten, weshalb sie zum experimentellen Ziel „innerhalb einer Minute“ passte. Sie belässt die Handlung außerdem beim Opfer und verlangt vor Beginn der Dienstwiederherstellung keine Zusammenarbeit des unerwarteten Ursprungs.

Deaggregation unterliegt harten Grenzen. Viele Netze filtern IPv4-Routen länger als /24 und IPv6-Routen länger als /48, um Tabellenwachstum und Missbrauch zu begrenzen. Ein Opfer, das bereits ein /24 oder /48 ankündigt, kann möglicherweise keine spezifischere Route veröffentlichen, die im breiten Internet angenommen wird. Anbieter beschränken außerdem die zulässigen Kundenankündigungen; Routing-Objekte, Präfixfilter oder RPKI-Daten müssen den Notfallzustand erlauben. Die Verbreitung erfolgt weder sofort noch einheitlich, weshalb alte und neue Pfade nebeneinander bestehen können.

Ein vorbereiteter Betreiber kennt diese Grenzen im Voraus. Welche Präfixe lassen sich deaggregieren? Welche Anbieter nehmen sie an? Welche Routenfilter und Route Origin Authorisations decken den Notfallzustand bereits ab? Wie werden die Routen nach der Wiederherstellung zurückgezogen? ARTEMIS kann ein externes Verfahren auslösen, dessen Erfolg jedoch von Vereinbarungen außerhalb der Anwendung abhängt.

Die Projektunterlagen sprechen von automatischer Eindämmung; die Forschung umfasst eine geschlossene Schleife, in der die Erkennung eine Gegenankündigung auslöst. Detaillierte Betriebsbeschreibungen zeigen zugleich manuelle Bestätigung und nutzergesteuerte Abläufe. Beide Aussagen sind vereinbar, weil Bereitstellungen unterschiedliche Autonomiestufen wählen. Die sichere Formulierung lautet: ARTEMIS unterstützt automatisierte oder vom Betreiber genehmigte Eindämmung über konfigurierbare Arbeitsabläufe.

Das Risiko ist asymmetrisch. Eine Verzögerung kann einen Ausfall oder ein Abfangen verlängern. Eine fehlerhafte automatische Reaktion kann unnötige spezifischere Routen ankündigen, Anbieterrichtlinien verletzen, interne Annahmen offenlegen oder Instabilität verursachen, während das ursprüngliche Ereignis noch untersucht wird. Eine veraltete Referenz kann eine geplante Änderung in einen falschen Notfall verwandeln. Wenn ein externes Verfahren weitreichende Router-Berechtigungen besitzt, wird eine Kompromittierung von ARTEMIS selbst zu einem Angriff auf das Routing.

Sicherere Automatisierung ist mehrstufig. Das System reichert zunächst die Warnung an, prüft mehrere Datenströme, den RPKI-Status und die Datenebene und bereitet anschließend eine präzise Routenänderung vor. Maßnahmen mit hoher Wirkung werden von einem Menschen genehmigt; risikoärmere Fälle können richtliniengesteuert automatisch ablaufen. Geschwindigkeitsbegrenzungen, enge Berechtigungen, Simulation, Änderungsprotokolle und geprüfte Rücknahmen sind wichtiger als das Etikett „automatisch“. Das Ziel ist nicht, manuelle Arbeit um ihrer selbst willen zu erhalten, sondern zu verhindern, dass Geschwindigkeit die Rechenschaftspflicht zerstört.

RPKI stärkt nur ein Glied der Beweiskette

Die Resource Public Key Infrastructure ermöglicht Adressinhabern, Route Origin Authorisations zu erstellen, die festlegen, welche autonomen Systeme bestimmte Präfixe und Maximallängen ankündigen dürfen. Router oder Richtliniensysteme führen Route Origin Validation durch und klassifizieren eine Route als gültig, ungültig oder nicht erfasst. Dadurch erhält jener Teil von BGP, der sonst auf verteiltem Vertrauen beruht, einen kryptografischen Beleg. Die Kontrolle ist proaktiv: Andere Netze können einen nicht autorisierten Ursprung ablehnen oder herabstufen, bevor Verkehr über ihn läuft.

ARTEMIS arbeitet auf einer anderen Ebene des Vorfalls. Es kann den RPKI-Prüfstatus als Beleg verwenden, vergleicht Routen aber zusätzlich mit privaten Betreiberregeln, zeichnet das Ereignis auf, verbindet öffentliche und lokale Datenströme und verknüpft Erkennung mit Reaktion. RPKI prüft nicht den vollständigen AS-Pfad, und die Einführung ist nicht universell. Eine Route kann nach RPKI gültig sein und dennoch eine erwartete Nachbarschaftsbeziehung verletzen oder über einen unerwünschten Pfad abfließen. Umgekehrt kann eine legitime Änderung ungültig erscheinen, wenn sie nicht in die ROA aufgenommen wurde.

Die Mechanismen ergänzen sich daher. RPKI reduziert die Zahl nicht autorisierter Ursprünge, die im breiten Internet angenommen werden. ARTEMIS zeigt dem Opfer tatsächliche Beobachtungen, erkennt bestimmte Muster jenseits der einfachen Ursprungsgültigkeit und organisiert die Reaktion. Künftige Verfahren zur Pfadautorisierung wie ASPA können Belege zu Beziehungen stärken, beseitigen aber nicht die Notwendigkeit zu beobachten, was Netze tatsächlich ankündigen und wie sich Ereignisse auf Dienste auswirken.

Pilotprojekte führten ARTEMIS aus dem Labor, bewiesen aber keine Marktgröße

CAIDA berichtete über eine von der NSF unterstützte experimentelle Einführung von ARTEMIS gemeinsam mit Internet2, Great Plains Network und Merit in den Jahren 2018 und 2019. Diese Pilotprojekte sind wichtig, weil Forschungs- und Bildungsnetze über reale Präfixe, Anbieter, Änderungsprozesse und Dienstverpflichtungen verfügen. Betreiber konnten prüfen, ob sich das Programm in die vorhandene Überwachung einfügt, ob die Regeln ihre Routing-Absicht abbilden und wie Warnungen in die Vorfallsreaktion eingehen.

Die Belege sind überzeugend, aber begrenzt. Ein Pilotprojekt bestätigt Installation, technische Rückmeldungen und eine bestimmte betriebliche Anwendung. Es beweist weder eine kontinuierliche Produktionsabdeckung noch die Aktualität der Version oder eine gleiche Wirksamkeit in allen Netztypen. Die Projektwebsite veröffentlicht außerdem Aussagen von Technikern mit Verbindungen zu AMS-IX, Internet2 und ESnet und zeigt Organisationslogos. Das deutet auf Tests oder Nutzung hin, erlaubt aber nicht, jede Organisation als aktuellen zahlenden Kunden zu bezeichnen oder dem Projekt einen bekannten weltweiten Marktanteil zuzuschreiben.

Die Unterscheidung ist wichtig, weil Bereitstellungen von Routing-Sicherheitssoftware häufig unsichtbar bleiben. Ein Betreiber kann einen internen Fork einsetzen, sich auf Überwachung ohne Eindämmung beschränken oder nach einem Test aufhören. Das Fehlen eines vollständigen Registers macht das Projekt nicht unbedeutend, verhindert aber eine genaue Messung seiner Verbreitung. Benannte Fälle sind aussagekräftiger als eine große unbestätigte Zahl.

Betreiberkontrolle bedeutet Aufwand für Integration und Schutz der Software-Lieferkette

ARTEMIS wird unter der BSD-3-Clause-Lizenz verbreitet. Der Betreiber kann den Code untersuchen, ihn in kontrollierter Infrastruktur ausführen, Integrationen ändern und muss sensible Richtlinien nicht an einen einzigen verpflichtenden zentralen Anbieter übermitteln. Dieses Modell entspricht dem zentralen Vorteil des Projekts: Die wertvollsten Referenzinformationen sollten im eigenen Netz verbleiben. Die Lizenz erlaubt sowohl kommerzielle Nutzung als auch Forks, sodass Code BGP und andere Beteiligte Dienste auf der offenen Grundlage aufbauen können.

Kontrolle erfordert Arbeit. Die Plattform umfasst Container, Nachrichtenbus, Datenbanken, APIs, Webanwendung, Benachrichtigungssysteme und Verbindungen zu Datenströmen. Jede Komponente benötigt Updates, Zugangsdaten, Netzsegmentierung, Sicherungen und Überwachung. Das System speichert sensible Routing-Richtlinien und kann über Befugnisse verfügen, die Ankündigungen beeinflussen. Die Angriffsfläche einer Produktionsbereitstellung ist daher wesentlich größer als die des ursprünglichen Erkennungsalgorithmus.

Eine offene Lizenz bietet dem Betreiber einen Ausweg aus der Abhängigkeit von einem einzelnen Betreuer, schafft aber nicht automatisch einen Supportdienst. Jemand muss weiterhin Updates prüfen, Abhängigkeiten untersuchen und den Code verstehen, wenn sich ein Datenstrom oder eine Router-Schnittstelle ändert. Für ein kleines Netz kann ein einfacheres Warnwerkzeug oder ein verwalteter kommerzieller Dienst geeigneter sein, auch wenn dadurch weniger lokale Kontrolle verbleibt.

Ein produktiver ARTEMIS-Dienst muss während derselben Netzinstabilität funktionsfähig bleiben, wegen derer der Betreiber ihn benötigt. Verbindungen zu Datenströmen, Nachrichtenbus, Datenbank, API, Oberfläche, Benachrichtigungskanal und Authentifizierungsschicht bilden eine gemeinsame Dienstkette. Redundanz auf Containerebene hilft nur, wenn Zustand, Speicher und externe Abhängigkeiten ebenfalls ausfallsicher ausgelegt sind. Ein neu gestarteter Monitor stellt nicht gespeicherte Updates nicht wieder her; eine replizierte Oberfläche zeigt keinen Vorfall, wenn der Erkennungspfad ihn nicht verarbeiten konnte.

Die Betriebsarchitektur muss deshalb Degradationsmodi ausdrücklich berücksichtigen. Fällt ein öffentlicher Datenstrom aus, sollte das System die verringerte Abdeckung melden, statt weiterhin einen nicht unterscheidbaren „gesunden“ Zustand anzuzeigen. Ist die Datenbank nicht verfügbar, muss der Detektor Ereignisse gegebenenfalls lokal zwischenspeichern oder die Eindämmung anhalten, weil keine prüfbaren Belege aufgezeichnet werden können. Bei Ausfall des Identitätsanbieters muss ein Notfallzugriff möglich bleiben, jedoch nicht über ein dauerhaft unkontrolliertes Konto.

Diese Entscheidungen gehören nicht zur Taxonomie von Routenübernahmen, bestimmen aber, ob eine Forschungsidee zu zuverlässiger Infrastruktur wird.

Die Plattform benötigt außerdem ein eigenes Leistungsbudget. Eine Spitze legitimer Updates während einer großen Routing-Änderung kann Monitore und Speicher stärker belasten als eine einzelne Übernahme. Interne Warteschlangen dürfen einen nahezu in Echtzeit arbeitenden Datenstrom nicht unbemerkt in einen verspäteten Vorfallsbericht verwandeln. Kapazitätstests, Aufbewahrungsfristen der Datenbank und Rückstaukontrolle des Nachrichtenbusses gehören aus demselben Grund in die Planung wie Routenfilter und Präfixlängen: Sie begrenzen die Reaktionsgeschwindigkeit, die das System glaubwürdig versprechen kann.

ARTEMIS verbindet Webkomponenten, Container-Images, Datenbank, Nachrichtenaustausch, APIs, Authentifizierung und Netzwerkbibliotheken. Diese Architektur erleichtert Erweiterungen, doch jede Abhängigkeit wird zu einer potenziellen Schwachstelle oder Ausfallquelle. Ein Fehler in der Benutzeroberfläche kann Routing-Richtlinien offenlegen. Ein kompromittiertes Image kann Warnungen verändern. Ein zu weitreichendes API-Token kann Zugriff auf Vorfallsdaten gewähren; Zugangsdaten in der Eindämmungsumgebung können Routenänderungen erlauben.

Die Sicherheit des Detektors ist deshalb untrennbar mit der Sicherheit der zugrunde liegenden Software verbunden.

Offener Code hilft: Der Betreiber kann Komponenten untersuchen, Versionen festschreiben und Images selbst erstellen. Offenheit garantiert jedoch nicht, dass jede transitive Abhängigkeit geprüft wurde oder eine öffentliche Schwachstelle innerhalb der für ein bestimmtes Netz erforderlichen Frist behoben wird. Ein Produktionsteam benötigt ein Verzeichnis der Images und Bibliotheken, einen Prozess für Neuaufbauten, eine Trennung zwischen schreibgeschützter Überwachung und schreibberechtigter Eindämmung sowie eine Möglichkeit, Sicherheitsupdates zu prüfen, ohne die Vorfallshistorie zu verlieren.

Damit ändern sich auch die Kriterien für die Projektpflege. Eine neue Erkennungsfunktion ist sichtbarer als ein Datenbankupdate oder eine Korrektur der Authentifizierung, obwohl Letztere für die Integrität des Dienstes wichtiger sein können. Sicherheitsbulletins, reproduzierbare Builds, aktualisierte Abhängigkeiten und ein unterstützter Release-Zweig belegen betriebliche Reife, selbst wenn im Dashboard keine neue Schaltfläche erscheint.

Releases und Code BGP bestimmen die heutige Prüfung der Projektpflege

Das letzte im Forschungspaket genannte formell gekennzeichnete Release ist Version 2.3.0 Cadmus vom 24. November 2022. Zum Stichtag 5. August 2026 zeigte die Live-Demonstration einen späteren Commit-Stand, und die Projektwebsite war weiterhin aktiv. Das bestätigt, dass die Arbeit nach dem letzten formellen Release fortgesetzt wurde, wirft zugleich aber eine berechtigte Produktionsfrage auf: Welche Version ist geprüft, unterstützt und für ein Upgrade geeignet?

Commit-Aktivität und eine funktionierende Demonstration belegen Entwicklung. Ein semantisches Release liefert eine andere Art von Vertrauen: eine benannte Basisversion, Release-Hinweise, erwartete Abhängigkeiten und einen Bezugspunkt für Betreibertests. Ein Projekt kann trotz eines zurückliegenden Release-Prozesses aktiv bleiben; eine aktuelle Demonstration kann zugleich Code verwenden, den ein Produktionsnetz ohne eigene Prüfung nicht übernehmen sollte.

Für Routing-Sicherheitsinfrastruktur ist Release-Disziplin Teil des Sicherheitsmodells. Betreiber müssen wissen, welche Zweige Korrekturen erhalten, wie Migrationen erfolgen und ob ältere Abhängigkeiten verwundbar bleiben. Ein neues Tag würde keine allgemeine Zuverlässigkeit beweisen, doch eine veröffentlichte Support- und Sicherheitsrichtlinie würde die Unsicherheit stärker verringern als eine funktionierende Website allein.

Die Projektwebsite bezeichnet Code BGP als heutigen Betreuer von ARTEMIS und beschreibt das Unternehmen als aus dem Projekt hervorgegangenes Start-up. Kommerzialisierung kann ein reales Problem quelloffener Software lösen. Routing-Sicherheitswerkzeuge benötigen Menschen, die Integrationen pflegen, auf Schwachstellen reagieren, bei Bereitstellungen helfen und Forschungsfunktionen nach dem Ende der ursprünglichen Fördermittel in einen beständigen Betrieb überführen.

Code BGP ist zugleich ein eigenständiges kommerzielles Unternehmen mit einem breiteren Produkt- und Kundenkontext. Es darf nicht als anderer Name für FORTH, CAIDA oder eine offene Bereitstellung verwendet werden. Die öffentlichen Materialien des Pakets legen weder Umsatz, Bewertung oder Kundenliste des Unternehmens noch die genaue Grenze zwischen öffentlichen Funktionen und kommerziellen Möglichkeiten offen. Dies ist kein Vorwurf, sondern eine Grenze dessen, was das Profil behaupten darf.

Die Verbindung schafft zwei Gruppen von Anreizen, die übereinstimmen oder auseinanderlaufen können. Das offene Projekt profitiert, wenn kommerzielle Mitarbeitende geprüften Code und Dokumentation beitragen. Das Unternehmen profitiert, wenn das offene Projekt Vertrauen, Verbreitung und eine technische Grundlage für kostenpflichtige Dienste schafft. Die langfristige Prüfung besteht darin, ob Releases, Sicherheitskorrekturen und Entscheidungen zur Roadmap für Betreiber, die keine kommerziellen Kunden sind, ausreichend sichtbar bleiben.

Die freizügige Lizenz garantiert die Möglichkeit, den Quellcode zu kopieren, zu verändern und zu kommerzialisieren. Sie garantiert nicht, dass ein anderes Team die Architektur versteht, ein Release reproduziert oder die Betreuung übernimmt, wenn die heutigen Fachleute ausscheiden. Die Kontinuität des Projekts hängt von Dokumentation, Tests, Vorgangshistorie, Kenntnis der Abhängigkeiten und einem Weg für neue Mitwirkende ab, der über die Personen hinausgeht, die das ursprüngliche Forschungssystem entwickelt haben.

Die Betreuung durch Code BGP kann diese Kontinuität stärken, indem erfahrene Techniker in der Nähe der Plattform bleiben. Sie kann praktisches Wissen aber auch innerhalb eines kommerziellen Unternehmens konzentrieren, obwohl das Repository öffentlich bleibt. Der Unterschied zeigt sich in Release-Hinweisen, offenen Designdiskussionen, der Reaktion auf Beiträge aus der Gemeinschaft und darin, ob nichtkommerzielle Bereitstellungen genügend Informationen für einen sicheren Betrieb erhalten.

Das Ziel besteht nicht darin, kommerziellen Wert zu verhindern. Ein gesundes Open-Core-Modell kann kostenpflichtige Unterstützung mit öffentlicher Projektpflege verbinden. Das Risiko entsteht, wenn das offene Projekt zu einer historischen Demonstration wird und der funktionsfähige Weg in undokumentierte private Komponenten abwandert. Die Übertragbarkeit sollte daher praktisch geprüft werden: Kann ein unabhängiger Betreiber das System anhand der aktuell verfügbaren öffentlichen Materialien installieren, aktualisieren, prüfen und wiederherstellen?

ARTEMIS besetzt eine anspruchsvolle Mitte der Routing-Sicherheit

Zum Feld der Routing-Sicherheit gehören öffentliche Kollektoren, Forschungssysteme zur Ableitung von Zusammenhängen, offene Warnwerkzeuge, RPKI-Validatoren und kommerzielle Überwachungsplattformen. RIPE RIS, RouteViews und BGPStream liefern Daten, aber keinen auf einen bestimmten Betreiber zugeschnittenen Vorfallsablauf. BGPalerter bietet ein anderes offenes Überwachungsmodell. MANRS definiert Betriebsnormen, erkennt jedoch keine Ereignisse in Echtzeit. Kommerzielle Dienste können breite Beobachtung und Unterstützung durch Analysten bieten, verfügen ohne Integration beim Kunden aber häufig nicht über dessen privaten lokalen Kontext.

Die besondere Position von ARTEMIS ergibt sich aus Betreiberkontrolle, ausdrücklich definierter Referenz, mehreren öffentlichen und lokalen Datenströmen, offenem Code und optionaler Eindämmung. Diese Position ist zugleich anspruchsvoll. Das Netz benötigt Routing-Fachleute, eine gepflegte Richtlinie und die Fähigkeit, eine Plattform aus mehreren Komponenten zu betreiben. Das Projekt eignet sich daher wahrscheinlich besser für Organisationen, bei denen Routing-Sicherheit eine interne Kompetenz ist und nicht nur ein weiteres Dashboard-Abonnement.

Ein Vergleich darf nicht auf eine Funktionstabelle reduziert werden. Unterschiedliche Modelle verteilen Vertrauen und Arbeit auf unterschiedliche Weise. Ein verwalteter Dienst zentralisiert Wissen und Beobachtung. Ein betreiberseitiges System hält Richtlinie und Handlung näher am Netz. Die praktische Frage lautet, welche Seite genügend sieht, sicher handelt und rechenschaftspflichtig bleibt, wenn die Belege unvollständig sind.

ARTEMIS Lite erschien 2023 in Materialien der RIPE-Gemeinschaft als verwandter, vereinfachter Ansatz, der einen Teil des Bereitstellungsaufwands reduzieren sollte. Bereits die Existenz einer Lite-Variante zeigt, dass der Umfang der vollständigen Plattform für ein kleines Team belastend sein kann. Ein aus mehreren Containern bestehender Stack mit dauerhaftem Speicher, mehreren Datenströmen und eigener Eindämmung kann für einen großen Betreiber angemessen, für ein Netz, das zunächst klare Sichtbarkeit und zuverlässige Warnungen benötigt, jedoch überdimensioniert sein.

Ein vereinfachtes System darf nicht allein wegen des gemeinsamen Namens und Zwecks als gleichwertig gelten. Das Forschungspaket beschreibt ARTEMIS Lite als Variante mit reduziertem Funktionsumfang; Aussagen aus der Präsentation erfordern unabhängige Bestätigung. Der wesentliche Zielkonflikt besteht zwischen geringeren Betriebskosten und möglicherweise fehlendem Kontext, Integrationen, Historie oder Reaktionsmechanismen. Eine kleine Bereitstellung bleibt nützlich, wenn sie diese Grenzen offen ausweist.

Die Verbreitung hängt davon ab, wie umfangreich die institutionellen Voraussetzungen des Werkzeugs sind. Ein Projekt kann technisch offen und dennoch für Betreiber ohne Fachleute für Container, Datenbanken und Routing-Sicherheit unzugänglich bleiben. Paketierung, sinnvolle Standardeinstellungen und ein stufenweiser Weg von Überwachung über Erkennung bis zur Eindämmung können darüber entscheiden, ob sich die Architektur über einen einzelnen Forschungsbeitrag hinaus verbreitet.

Das eigentliche Produkt ist eine kontrollierte Rückkopplungsschleife

ARTEMIS macht BGP nicht durch eine einzelne Handlung vertrauenswürdig. Es legt eine Schleife um ein Protokoll, das ursprünglich keine vollständige Autorisierung enthielt. Der Betreiber beschreibt das gewünschte Routing. Öffentliche und lokale Datenströme zeigen einen Teil der tatsächlichen Lage. Der Detektor findet eine Abweichung. Speicher und Oberflächen ordnen die Belege. Menschen oder eine genehmigte Automatisierung wählen eine Reaktion; anschließend zeigen die Datenströme, ob sich die Verbreitung geändert hat.

Ein Vorfall kann behoben, als unerheblich eingestuft, nach Rücknahme der Route geschlossen, eskaliert oder mit dokumentierter Begründung unbehandelt gelassen werden.

Diese Schleife ist der beständigste Beitrag des Projekts. Sie erkennt an, dass Routing-Sicherheit weder auf ein einmaliges Zertifikat noch auf eine entfernte Warnung reduziert werden kann. Sie ist eine Betriebspraxis, in der Richtlinien ausdrücklich formuliert sein müssen, Beobachtungen ihre Herkunft behalten und Reaktionsbefugnisse vor dem Notfall vorbereitet werden. Der Wert des Systems liegt darin, Unsicherheit schnell genug einzugrenzen, damit ein Netz handeln kann – nicht darin, vorzugeben, die Unsicherheit sei verschwunden.

Die Einschränkungen sind ebenso aufschlussreich. Routenkollektoren sehen nur einen Teil der Welt. Die Referenz kann veralten. Belege der Kontrollebene beweisen weder Motiv noch sämtliche Folgen für den Verkehr. Eine technisch mögliche Eindämmung kann gefiltert werden oder Schaden verursachen. Offener Code benötigt weiterhin fortlaufende Betreuung. ARTEMIS ist am stärksten, wenn diese Grenzen in den Arbeitsablauf eingebaut und nicht hinter einer Überschrift über eine Reaktion binnen einer Minute verborgen werden.

Eine BGP-Anomalie kann das Netzbetriebszentrum, das Sicherheitszentrum oder beide zugleich erreichen. Das Routing-Team versteht Präfixe, Anbieterrichtlinien und das Risiko geänderter Ankündigungen. Das Sicherheitsteam ist besser auf den Abgleich von Identitäten, Diensttelemetrie und möglicher böswilliger Aktivität vorbereitet. ARTEMIS überschneidet diese Bereiche. Nutzen entsteht nur, wenn die Warnung genügend Belege enthält, damit beide Teams am selben Ereignis arbeiten, statt getrennte Untersuchungen mit unterschiedlichen Ausgangsannahmen zu eröffnen.

Eine Vorfallsübergabe sollte Beobachtung, Richtlinie und Auswirkung trennen. Das System sah eine Route in konkret benannten Datenströmen. Die Route verletzte eine bestimmte Referenzregel. Dienstprüfungen oder RIPE-Atlas-Sonden zeigten eine konkrete Wirkung – oder eine Wirkung wurde bislang nicht festgestellt. Der Betreiber kontaktierte das vorgelagerte Netz oder den Ursprung der Route, und eine Antwort steht noch aus. Diese Struktur verhindert, dass das NOC eine Sicherheitsbedrohung als gewöhnliches Routing abtut oder das SOC eine unzulässige Ankündigung vor Feststellung der Betriebsfakten als Angriff bezeichnet.

Eine gemeinsame Sprache verbessert auch die Nachbereitung. Ein Fall kann als geplante, nicht in die Richtlinie eingetragene Änderung, versehentliches Routenleck, vermutete Übernahme, bestätigtes böswilliges Ereignis oder ungeklärte Anomalie geschlossen werden. Diese Ergebnisse sollten in Regeln, Anweisungen und Vereinbarungen mit Anbietern zurückfließen. Ohne diese Schleife droht der Detektor zu einer Maschine zur Erstellung von Tickets statt zu einem System zur Verbesserung der Routing-Kontrolle zu werden.

Die schnellste Warnung ist nicht immer die nützlichste. Ein Detektor kann beim ersten unerwarteten Update auslösen, bevor sich herausstellt, dass der Datenstrom verspätet war, die Route geplant wurde oder das vermeintliche Opfer einen neuen Ursprung autorisiert hatte. Andererseits würde das Warten auf jeden Kollektor und jeden Test der Datenebene den Vorteil einer frühen Reaktion zunichtemachen. ARTEMIS benötigt eine Messgröße zwischen der rohen Erkennungszeit und dem endgültigen Abschluss: Wie lange dauert es, ausreichend zuverlässige Belege zu sammeln und einem befugten Betreiber eine vertretbare Entscheidung zu ermöglichen?

Diese Größe lässt sich aufteilen. Wie schnell traf die erste Beobachtung ein? Wie viele unabhängige Datenströme bestätigten sie? War die relevante Richtlinie aktuell? Lieferten RPKI oder lokales BMP wesentliche zusätzliche Belege? Wie lange dauerten die Dienstprüfungen? Wann erhielt die verantwortliche Person die Warnung, und wann wurde die Reaktion genehmigt? Erzeugte die Eindämmung die erwartete Verbreitung, und wurde sie geordnet zurückgenommen? Diese Fragen zeigen, wo die Verzögerung tatsächlich entsteht, statt das gesamte Ergebnis dem Erkennungsalgorithmus zuzuschreiben.

Die Messgröße einer vertretbaren Entscheidung verhindert außerdem eine gefährliche Optimierung. Das System darf nicht für schnelleres Handeln belohnt werden, wenn dieses auf weniger Belegen beruht oder eine unnötige Routing-Änderung erzeugt. Eine bessere Bereitstellung reduziert gleichzeitig Unsicherheit und Reaktionszeit und bewahrt eine Aufzeichnung, die nach dem Vorfall geprüft werden kann.

Quellen

  • Projektwebsite von ARTEMIS
  • Die quelloffene ARTEMIS-Architektur auf RIPE Labs
  • Quell-Repository und Dokumentation von ARTEMIS
  • „ARTEMIS: Neutralizing BGP Hijacking within a Minute“
  • Betriebliche Erläuterung von ARTEMIS auf RIPE Labs
  • ARTEMIS-Demonstrationsbeitrag auf der ACM SIGCOMM 2016
  • ARTEMIS-Releases
  • CAIDA-Jahresbericht 2019
  • BGP-Nachrichtenstrom RIPE RIS Live
  • RouteViews der University of Oregon
  • CAIDA BGPStream
  • ExaBGP-Repository
  • Route Origin Validation, RFC 6811
  • Empfänger des RIPE Community Projects Fund 2019
  • Code BGP
  • Experimentelle ARTEMIS-Einführung bei CAIDA
  • ARTEMIS-Live-Demonstration
  • BGP Monitoring Protocol, RFC 7854
  • RIPE Atlas