GOpenCNR-Sicherheits- und Offenlegungsrichtlinie

Wie diese Richtlinie zu der von Gelhaus Solutions steht

GOpenCNR fällt unter die Richtlinie zur Offenlegung von Schwachstellen von Gelhaus Solutions, und alles darin gilt auch hier: wie Sie melden, die Reaktionszeiten, der sichere Hafen, Nennung und Kennungen. Diese Seite ergänzt, was für ein Netz besonders ist: was abgedeckt ist, was am meisten zählt und was ein Test nie tun darf, denn die Hubs transportieren den Datenverkehr von Mitgliedern, die nie zugestimmt haben, Teil eines Tests zu sein, und der Agent läuft auf ihren Routern.

GOpenCNR gehört mit voller Abdeckung zum Geltungsbereich der CVE Numbering Authority von Gelhaus Solutions, und Kennungen werden vergeben, wie es die Offenlegungsrichtlinie beschreibt.

Konten, die Anmeldung, der zentrale API-Zugang, das Transparenzlog und die Agent-Core-Bibliothek, auf der der Join-Agent aufbaut, gehören zu GOpenCSR; für sie gilt die GOpenCSR-Sicherheits- und Offenlegungsrichtlinie. Namen, Resolver und Zertifikate gehören zu GOpenCDR; für sie gilt dessen Sicherheits- und Offenlegungsrichtlinie. Wenn Sie nicht sicher sind, wohin ein Befund gehört, melden Sie ihn hier: Jeder Weg erreicht dieselbe Person.

Wie Sie melden

Schreiben Sie an contact@gplatform.org oder reichen Sie die Meldung über GAdvisory ein. Beide Wege erreichen dieselbe Person und setzen dasselbe Verfahren in Gang. Verschlüsseln Sie alles Heikle mit dem Schlüssel, dessen Fingerabdruck in der Offenlegungsrichtlinie steht. Bitte eröffnen Sie kein öffentliches Issue.

Schreiben Sie „GOpenCNR“ in den Betreff und zusätzlich „dringend“, wenn die Meldung Schlüsselmaterial, das RPKI, ein Leck geschlossener Präfixe oder die Hubs betrifft. Solche Meldungen werden zuerst gelesen.

Die security.txt von GOpenCNR unter https://cnr.gplatform.org/.well-known/security.txt verweist auf diese Seite, ebenso die Fußzeile jeder GOpenCNR-Seite.

Was abgedeckt ist

• Das Portal und die Registry-API unter cnr.gplatform.org, einschließlich des GOpenCNR-Teils des zentralen API-Zugangs, csr.gplatform.org/api/cnr/v1.
• RDAP, Whois, der IRR-Server und NRTMv4 sowie jeder Export: der signierte Export und seine Git-Kopie, die Exporte im dn42-Format und die RPKI-Dateien in JSON, SLURM und für BIRD.
• Die Hubs und der Hub-Modus: der Hub von Tier 0, die Hub-Software, die zertifizierte und Community-Hubs betreiben, gehostete Router sowie die Filter, Weiterleitungsprüfungen und Schlüssel, die die Hubs halten.
• Der Join-Agent auf jeder Plattform, mit seiner Anmeldung, seinen signierten Anfragen, seinen Bundles und seinen Updates, und der Bundle-Builder, der die Bundles erzeugt.
• Das RPKI: die Zertifizierungsstelle, das Repository über RRDP und rsync, der TAL und die RTR-Caches.
• Der Route-Collector, die Präfix-Warnungen, das Looking Glass und die Netzkarte.
• Die Kommandozeilenwerkzeuge gocnr und gocnrctl.

Worüber wir am liebsten hören

1. Jeden Weg, ein geschlossenes Präfix von außerhalb seiner Zielgruppe zu erreichen, im Routing oder in der Weiterleitung, oder an die inneren Schlüssel eines Mitglieds zu gelangen, mit dem Sie nicht kommunizieren dürfen.
2. Jeden Weg, geschlossene Routen nach außen gelangen zu lassen: eine geschlossene Route zu einem Community-Hub, einem Transit-Mitglied, einer direkten Sitzung, einer Netzverbindung, dem öffentlichen Looking Glass, den veröffentlichten Dumps des Collectors oder sonst jemandem außerhalb ihrer Zielgruppe zu bringen, oder zu erfahren, wer zu einer Zielgruppe gehört.
3. Jeden Weg, die Endpunktadresse eines Mitglieds zu erfahren, ohne ein von ihm akzeptierter Peer zu sein, oder den bürgerlichen Namen und das Land eines Mitglieds, ohne Tier 0 zu sein: aus einer Seite der Registry, einem Export, RDAP, Whois, dem Looking Glass, der Netzkarte oder dem Transparenzlog, auch indem Sie herausfinden, wofür ein gesalzener Hash im Log steht.
4. Jeden Weg, Anfragen des Agenten oder Bundles zu fälschen oder zu wiederholen: sich ohne gültiges Token anzumelden, als Agent eines anderen aufzutreten, eine signierte Anfrage nach Ablauf ihrer 60 Sekunden oder mehr als einmal angenommen zu bekommen oder einen Agenten ein Bundle oder ein Update anwenden zu lassen, das wir nicht signiert haben, oder ein Bundle mit einer niedrigeren Seriennummer als dem laufenden.
5. Jeden Weg, einen Hub eine Route annehmen zu lassen, die er ablehnen müsste: von einem anderen Ursprung als dem des Routenobjekts, ungültig nach RPKI oder ASPA, spezifischer als ein Routenobjekt, außerhalb der Bereiche von GOpenCNR, eine Default-Route oder über die Max-Prefix-Grenze hinaus. Ebenso jeden Weg, einen Hub Pakete weiterleiten zu lassen, deren Quelle außerhalb des Adressraums des Absenders liegt, oder ihn Datenverkehr zwischen dem Internet und Mitgliedern transportieren zu lassen.
6. Jeden Weg, eine RPKI-Signatur anders als über den vorgesehenen Pfad zu erhalten: die Online-Zertifizierungsstelle für Adressraum signieren zu lassen, den die Registry nicht führt, den Schlüssel des Vertrauensankers außerhalb einer Zeremonie zu verwenden oder einen einmaligen EE-Schlüssel nach seiner Signatur wiederzugewinnen.
7. Jeden Weg, eine Zuteilung ohne die nötige Prüfung zu erhalten: eine Größe über dem Standard, ein geschlossenes Präfix, einen Transfer oder eine Rücknahme ohne Freigabe durch Tier 0 nach dem Vier-Augen-Prinzip, einen Pool ohne Antrag eines Rats, die Freigabe einer eigenen Anfrage oder eine Änderung der Registry ohne gültige Signatur des Inhabers oder ohne ihren Eintrag im Transparenzlog.
8. Jeden Weg, den Rechten des Agenten auf dem Router eines Mitglieds zu entkommen: von seinen Netzwerkrechten oder seinem privilegierten Helfer zu etwas, das der Agent nicht verwaltet, von einem Bundle zu Befehlen, die der Agent nie ausführen dürfte, oder von einem gehosteten Router zu einem anderen auf demselben Hub.

Regeln für Tests

Das Netz transportiert Datenverkehr von Mitgliedern, die nie zugestimmt haben, dass an ihnen getestet wird, und der Agent läuft auf ihren Routern. Deshalb gelten hier eigene Regeln, zusätzlich zu denen der Offenlegungsrichtlinie.

• Testen Sie an Ihrem eigenen Adressraum, Ihren eigenen Routern und Geräten und Ihrem eigenen gehosteten Router. Nutzen Sie die Registry-Sandbox und den Sandbox-Hub, wo immer sie das Problem zeigen können.
• Scannen Sie keine anderen Mitglieder. Scans zwischen Mitgliedern sind verboten; die Prüfung der Erreichbarkeit scannt Ihren eigenen Adressraum, wenn Sie sie anfordern.
• Keine Dienstverweigerung. Führen Sie keine Lasttests durch, fluten Sie nichts und versuchen Sie nicht, die Hubs, das RPKI-Repository, die RTR-Caches, RDAP, Whois, die API oder das Portal zu erschöpfen, und verwenden Sie keinen Hub, um Datenverkehr gegen irgendwen zu reflektieren oder zu verstärken.
• Testen Sie Hubs, die Sie nicht selbst betreiben, nicht über die normale Nutzung als Mitglied hinaus. Um ein Problem mit Filtern oder Weiterleitung zu zeigen, nutzen Sie Ihren eigenen Adressraum, den Sandbox-Hub oder einen Hub, den Sie selbst betreiben.
• Kündigen Sie auf einem laufenden Hub keinen Adressraum an, den Sie nicht halten, und versuchen Sie dort nicht, geschlossene Routen nach außen gelangen zu lassen.
• Testen Sie dn42, NeoNetwork oder deren Mitglieder nicht über die Netzverbindungen.
• Greifen Sie nur auf das zu, was Sie brauchen, um das Problem zu zeigen. Erreichen Sie Daten oder Datenverkehr anderer, hören Sie auf, behalten Sie nichts davon und sagen Sie es uns.
• Kein Social Engineering gegenüber unseren Mitarbeitenden, Hub-Betreibern oder Mitgliedern, keine physischen Angriffe und nichts, was auf unsere eigene Hardware zielt, einschließlich des Schlüsselspeichers (HashiCorp Vault) und des Netzes dahinter.
• Behalten Sie die Einzelheiten bis zum abgestimmten Termin für sich.

Forschung innerhalb dieser Regeln ist willkommen, und der sichere Hafen der Offenlegungsrichtlinie deckt sie ab.

Was nicht abgedeckt ist

• Befunde in Software Dritter, die wir unverändert betreiben, etwa BIRD, FRR, WireGuard, IRRd, Routinator, rpki-client, BGPalerter, HashiCorp Vault, Temporal oder PostgreSQL. Melden Sie diese dem jeweiligen Projekt; wir helfen dabei und spielen die Korrektur ein.
• Schwächen von BGP, des RPKI oder von WireGuard selbst ohne Auswirkung, die GOpenCNR besonders betrifft.
• dn42 und NeoNetwork und deren Registries.
• Was eine Einrichtung bauartbedingt offenlegt und auf ihrer Kennzeichnung sagt: dass ein Hub-Betreiber den Datenverkehr eines gehosteten Routers auf seinem Hub sieht oder dass Hubs den Datenverkehr eines Routers sehen, der Hop-by-Hop läuft. Ein Weg, auf dem jemand anderes diesen Datenverkehr sehen kann, ist abgedeckt.
• Befunde, die einen bereits kompromittierten Router oder ein kompromittiertes Gerät oder administrativen Zugang zu einem fremden Hub voraussetzen, es sei denn, GOpenCNR verschlimmert sie.
• Ausgaben automatischer Scanner ohne nachgewiesene Auswirkung, fehlende Header ohne Auswirkung sowie Ratenbegrenzungen, Filter und Sperren, die wie beschrieben funktionieren.
• Missbrauch durch ein Mitglied, etwa Scans oder Angriffe aus dem Adressraum von GOpenCNR; dafür gilt der Meldeweg an abuse@gplatform.org nach der Richtlinie zur zulässigen Nutzung.

Wenn ein Schlüssel kompromittiert sein könnte

Wenn Sie glauben, dass der Schlüssel des RPKI-Vertrauensankers, der Schlüssel der Online-Zertifizierungsstelle, der Schlüssel, mit dem Bundles signiert werden, der Schlüssel, mit dem Releases signiert werden, oder die Schlüssel eines Hubs offengelegt sein könnten, schreiben Sie sofort, mit „dringend“ und „Key“ im Betreff. Tier 0 kann nach seinem Notfallverfahren sofort handeln, das nur aussetzen oder verschärfen darf, nie lockern, und das nach 90 Tagen endet, wenn es nicht bekräftigt wird. Jede Notfallmaßnahme wird im Transparenzlog veröffentlicht und nachträglich überprüft. Was in diesem Fall mit dem RPKI geschieht, regelt die RPKI-Zertifizierungspraxis.

Könnte einer Ihrer eigenen Schlüssel offengelegt sein, etwa der Schlüssel Ihres Agenten, der WireGuard-Schlüssel eines Routers oder Geräts oder ein Automatisierungsschlüssel, widerrufen Sie ihn sofort im Portal. Der Ablauf zum Austausch listet jede Änderung auf, die der Schlüssel signiert hat, und die Objekte, die er signiert hat, bleiben gesperrt, bis Sie sie erneut signieren.

Probleme, die keine Schwachstellen sind

Eine abgelehnte Route, eine gesperrte Sitzung, eine Präfix-Warnung, die Sie sich nicht erklären können, ein veraltetes Repository oder zwei Validatoren, die nicht übereinstimmen, sind nicht immer eine Schwachstelle, aber wir wollen ebenso schnell davon hören. Schreiben Sie an dieselbe Adresse.