RPKI | Ständige Verbindungsabbrüche am Standort vor Ort (Büro)

[Xela69]

Des Pudels Kern:

Hier in Deutschland wird keiner einen Provider finden, der RPKI implementiert, weder Telekom noch Vodafone oder O2 und so weiter. Wer möchte kann dies mit https://rpkitest.nlnetlabs.net/ testen und wird einen Smiley mit einem Hängemaul sehen. Ein altbekanntes Deutschland spezifisches Problem. Absicht??? Allerdings die Datenzentren schon, z.B. NTT, Global Access und andere sicherlich auch. Was könnte man nun machen, damit die Verbindungen zum Standort vor Ort nicht fehlgeroutet werden bzw. nicht abbrechen? Eine Instanz im Datenzentrum aufsetzen, welche die Verbindungen annimmt und einen Tunnel zum Standort vor Ort bereitstellen (via IP, kein DNS!, DNS kann ausfallen/manipuliert werden). Der Smiley wird lächeln. Und die Verbindungen bleiben bestehen!

Vorteil mit dem Tunnel vom Datenzentrum zum Standort vor Ort ist auch, Geolocation. Es wird nach aussen die IP vom Datenzentrum, nicht vom Büro angezeigt. Sprich von aussen wird nicht gesehen, dass die Infrastruktur am Standort vor Ort steht.

Win:Win !!!

Ein Grund weniger für die Feinde in der Weite, eine Bombe gezielt auf den Standort zu werfen. Oder die Gauner und Ganoven da draussen erfahren nicht, dass da ein fetter Serverraum am Standort vor Ort ist.

Ist das die Absicht, die dahinter steckt?

Nicht vergessen: viewtopic.php?t=184359#p1304673

[Livingston]

Nicht vergessen: viewtopic.php?t=184359#p1304673

Kann man getrost vergessen. Du hast in dem letzten Beitrag des verlinkten Threads klar gemacht, worum es Dir geht: Selbstdarstellung

[Xela69]

Vielen Dank für dein Feedback. Es tut mir leid, wenn mein Beitrag als Selbstdarstellung rüberkam, das war nicht meine Absicht. Ich möchte gerne konstruktiv zur Diskussion beitragen. Könntest du mir sagen, was genau diesen Eindruck erweckt hat? Das würde mir helfen, mich zukünftig klarer auszudrücken.

[thunder11]

Wer möchte kann dies mit https://rpkitest.nlnetlabs.net/ testen und wird einen Smiley mit einem Hängemaul sehen. Ein altbekanntes Deutschland spezifisches Problem

Also ich hab das einen lachenden Smiley, was auch immer das heißen mag

testing valid ROA...[passed ipv4]

AS137409 was not able to reach our RPKI invalid BGP route from prefix 203.23.179.0/24 as witnessed by your public IP 203.23.179.51

[Xela69]

Code: Alles auswählen

~$ curl http://api.db-ip.com/v2/free/203.23.179.51
{
    "ipAddress": "203.23.179.51",
	"continentCode": "EU",
	"continentName": "Europe",
	"countryCode": "DE",
	"countryName": "Germany",
	"stateProv": "Lower Saxony",
	"city": "Stinstedt",
}

Darüber wäre ich jetzt zum positiven sehr überrascht!

Kann aber nicht sein: https://irrexplorer.nlnog.net/prefix/203.23.179.51

No (covering) RPKI ROA found for route objects

[unitra]

Was soll man denn auf so einen Beitrag antworten.

Keine IP Präfixe vorhanden, keine AS Nummer, kein BGP Peer, wo ist die relevante RPKI Konfiguration? Wen interessiert in der IP Welt ob deine Firma für die Du arbeitest, Anwälte anbindet? Das ist eine komplett sinnlose Information für das Problem. Schreibe den Fachsupport an, da wo Du diesen RPKI Präfix rauslässt. Für Netzwerkanbindungen mit IP Präfixen gibt es immer eine Anleitung und Vorlagen wie man so etwas konfiguriert. Immer. Du solltest Dir deinen Vertrag den Du unterschrieben hast eventuell noch einmal durchlesen, da gibt es einen NDA (Non Disclosure Agreement) oder Verschwiegenheitsvereinbarung oder auch Geheimhaltungsvertrag.

Was erwartest Du in einem in einem Fachfremden Forum für Antworten auf so eine Frage? Ich vermute Dir ist nicht klar dass Du hier im komplett falschen Forum bist für diese Frage. Andere habe es schon geschrieben, und ich sehe das genau so. Du suchst nach Aufmerksamkeit, die Lösung dieser Frage ist Dir komplett egal.

[Edit fix typo]

[uname]

Ich kenne RPKI nicht. Aber mit korrektem VPN braucht das kein Mensch. Leider scheint VPN nicht zuverlässig genug zu sein, dass Angriffe über MitM denkbar sind. Vielleicht eher die Ursache unsicheres VPN diskutieren als einen doppelten Boden einziehen.

[Xela69]

Fragt man die KI nach Lösungen, werden folgende vorgeschlagen:

1. Community-Unterstützung: Beteiligen Sie sich an Diskussionen in Foren oder bei Netzwerktreffen, um das Bewusstsein für die Wichtigkeit von RPKI zu schärfen und möglicherweise eine kollektive Lösung zu finden.

2. Anbieter kontaktieren: Kontaktieren Sie Ihren Internetanbieter und fragen Sie nach deren Plänen zur Implementierung von RPKI. Manchmal kann Kundenfeedback dazu führen, dass Anbieter ihre Prioritäten ändern.

3. VPN oder Tunnel: Nutzen Sie einen VPN-Dienst oder einen Tunnel, der RPKI unterstützt. Dies könnte helfen, indem es die Sicherheit des Routings verbessert und potenziell Geolocation-Probleme löst.

4. Eigenes RPKI-Setup: Wenn Sie über die nötige technische Expertise verfügen, könnten Sie ein eigenes RPKI-Setup für Ihre Netzwerke einrichten. Dies erfordert jedoch Zugang zu einem RPKI-Validator und die Möglichkeit, Ihre Routing-Entscheidungen entsprechend anzupassen.

Bei Punkt 1 sind wir ja gerade dabei. Bei Punkt 2 stösst man auf Granit. Punkt 3 habe ich am Anfang vorgeschlagen. Punkt 4, interessiert mich sehr. Wo erhält man solch einen Zugang und wie werden diese Anpassungen durchgeführt?

[Livingston]

Du hast ja selbst in Deinem Eingangspost den anderen Thread erwähnt, in dem Du nix als heiße Luft produziert hast, und worauf Du nach eigenem Bekunden auch mächtig stolz bist.
Soll das hier das nächste Windei werden?

Ich schau mir das mal in Ruhe von meinem Kinositzplatz aus an.

[Xela69]

Es ist faszinierend immer wieder zu beobachten, dass bei technischen Problemen, die vielen anderen sicherlich auch Interessieren, oft nicht gemeinsam an einer Lösung gearbeitet wird, sondern stattdessen alles immer wieder ins Lächerliche gezogen wird. Die im anderen Thread erwähnten Schwachstellen sind vom BSI katalogisiert worden und sind nicht zu vernachlässigen (https://wid.cert-bund.de/portal/wid/sec ... 9f51adbd88). Ich wünsche viel Spaß beim Zuschauen!

[uname]

Ich finde es auch falsch, wenn Sicherheitsbedrohungen oder Sicherheitsfunktionen einfach ignoriert werden. Mache ich aber auch gerne. Das liegt vielleicht bei mir daran, dass es Dinge sind, die vielleicht einfach nur teuer verkauft werden wollen. Hierzu gehört wohl RPKI oder auch OV-SSL-Zertifikate gegenüber kostenlosen Lets Encrypt-Zertifikaten, was jeweils nur geringen Mehrwert bringt. Ja ich kenne die Vorteile von OV-SSL, aber wer braucht die wirklich und wann? Aber in Firmen muss alles getan werden was geht. Gerne VPN, RPKI, OV-SSL, möglichst teuer und vom Marktführer. Geht ja um Sicherheit. Das eigentliche Risiko wird dabei vollkommen ignoriert. Und dazu gehören auch alle Angriffe, die von dir @Xela69 aufgeführt wurden. Das größte Problem ist meiner Meinung nach Schadcode auf dem Client - egal ob Software oder Hardware. Und natürlich auch der Anwender. Da hilft dann weder RPKI, VPN, TLS/SSL, OV-SSL, GPG, S/MIME, ... Vielleicht hätte ein alternatives Betriebssystem wie Debian gegenüber Windows geholfen. Oder Schulung der Mitarbeiter. Hilft beides aber auch nicht immer.

Insgesamt finde ich es interessant, wie man versucht ein Risiko wie Client-Manipulation durch ein weiteres Produkt wie RPKI zu bekämpfen. Ermöglicht RPKI aus Sicht des Clients nur den Zugriff zu einem festen Zielnetzwerk, welches auch zu meiner Firma gehört? Also kann ich oder mein Schadcode keine Verbindung ins echte Internet herstellen? Wer glaubt Sicherheit haben zu wollen, sollte als erstes sämtliche Kommunikationen ins Internet und damit außerhalb seiner Firma bzw. RPKI unterbinden.

Vorteil mit dem Tunnel vom Datenzentrum zum Standort vor Ort ...

Traditionell nutzt man hier möglichst ein VPN und gerne zusätzlich noch Firewalls auf den Routern. Das Risiko sind meiner Meinung nach die Clients. Der Mehrwert von RPKI erscheint mir eher gering und unverhältnismäßig. Bessere oder alternative Clients (evtl. virtualisiert), Virenscanner, alternative Betriebssysteme und Schulung der Mitarbeiter scheint mir eine sinnvollere Investition. Auch sollte man den Mitarbeitern das Internet verbieten. Wirklich. Denn das ist das eigentliche Problem. Vielleicht kann man alternativ dem Anwender einen zweiten Browser in einer Sandbox oder eine VM anbieten, die isoliert ist und alles vergisst. Der Originalbrowser würde dann entsprechend eingeschränkt. Würde deine Sicherheit wohl eher erhöhen. Aber sowas ist nicht wirklich teuer und damit bei Firmen eher unbeliebt.

[Xela69]

Habe ein wenig über Weihnachten recherchiert und eine kostengünstige Open-Source-Lösung gefunden:

Routinator von NLnet Labs ist ein RPKI-Relying-Party-Open-Source-Software-Tool, das zur Validierung von RPKI-Daten verwendet wird. Es dient dazu, die Herkunft von IP-Adressen zu überprüfen und sicherzustellen, dass IP-Routen autorisiert sind. Routinator selbst bestimmt jedoch keine Routen. Stattdessen validiert es die Informationen, die von den RPKI-Zertifikaten bereitgestellt werden, und hilft Netzbetreibern, Entscheidungen über die Annahme oder Ablehnung von Routen basierend auf diesen Informationen zu treffen. Die tatsächliche Routenentscheidung wird von den Router-Konfigurationen getroffen, die die validierten Daten als Input verwenden.

https://routinator.docs.nlnetlabs.nl/en ... index.html

https://github.com/NLnetLabs/routinator

Es funktioniert folgendermaßen:

1. Datenabruf: Routinator lädt RPKI-Daten von verschiedenen Trust Anchors herunter. Diese Daten enthalten Zertifikate und ROAs (Route Origin Authorizations), die angeben, welche Autonomous Systems (AS) berechtigt sind, bestimmte IP-Präfixe zu bewerben.

2. Validierung: Die heruntergeladenen RPKI-Daten werden validiert. Routinator überprüft die Signaturen der Zertifikate und stellt sicher, dass sie mit den veröffentlichten Trust Anchors übereinstimmen.

3. Erstellung einer Validierungsdatenbank: Nach der Validierung wird eine Datenbank mit den gültigen ROAs erstellt. Diese Datenbank wird dann von Netzbetreibern verwendet, um Routing-Entscheidungen zu treffen.

4. Bereitstellung der Daten: Die validierten Daten können über verschiedene Schnittstellen bereitgestellt werden, wie z.B. RTR (RPKI-to-Router Protocol) oder HTTP, um von Routern genutzt zu werden.

5. Integration: Netzbetreiber können die validierten Daten in ihre Routing-Policies integrieren, um sicherzustellen, dass nur autorisierte Routen akzeptiert werden.

Routinator hilft somit, die Sicherheit und Integrität des Internetroutings zu verbessern, indem es sicherstellt, dass nur vertrauenswürdige Routen verwendet werden.

Ein Beispiel für die Verwendung von Routinator wäre ein Internetdienstanbieter (ISP), der sicherstellen möchte, dass er nur autorisierte Routen von seinen Peers oder Kunden akzeptiert:

1. Installation und Konfiguration: Der ISP installiert Routinator auf einem Server innerhalb seines Netzwerks und konfiguriert ihn, um regelmäßig RPKI-Daten von den Trust Anchors (wie RIPE NCC, ARIN, etc.) herunterzuladen.

2. Regelmäßige Validierung: Routinator lädt die neuesten RPKI-Daten herunter, validiert die Zertifikate und erstellt eine Liste der gültigen ROAs. Diese Liste enthält Informationen darüber, welche Autonomous Systems (AS) berechtigt sind, bestimmte IP-Präfixe zu bewerben.

3. Bereitstellung der Daten: Routinator stellt diese validierten Daten über das RTR-Protokoll bereit, das von den Routern im Netzwerk des ISP genutzt wird.

4. Routing-Entscheidungen: Die Router verwenden die Informationen von Routinator, um zu entscheiden, ob sie eine Route annehmen oder ablehnen sollen. Wenn eine Route von einem AS kommt, das nicht in den validierten ROAs für das beworbene IP-Präfix enthalten ist, wird die Route abgelehnt.

5. Erhöhung der Sicherheit: Durch die Verwendung von Routinator kann der ISP sicherstellen, dass er nur legitime Routen in sein Netzwerk aufnimmt, was die Sicherheit und Zuverlässigkeit des Netzwerks erhöht.

Dieses Beispiel zeigt, wie Routinator als Teil einer umfassenden Sicherheitsstrategie im Routing eingesetzt werden kann, um das Risiko von Angriffen wie IP-Spoofing zu reduzieren.

Schadcode auf dem Client: Jede weiter installierte App birgt gefahren! Warum nicht alles über den Browser? Der ist meistens schon mit dabei.