Drei Sicherungen, die verhindern, dass ein Kunden-BGP-Gateway Routen durchsickern lässt

Ein dediziertes Gateway pro Kunde, das wir bauen und betreiben, mit internem Peering zu unserem Policy-Gateway über private AS-Nummern, ist das richtige Design: Isolation, eine Policy, die dem Kunden gehört, und Routing, das sich von selbst anpasst. Das BGP ist intern in unserer Plattform, keine Session, die der Kunde betreibt. Es bedeutet aber auch, dass Sie nun viele kleine BGP-Speaker betreiben, und eine einzige unachtsame Einstellung auf irgendeinem davon kann Routen ankündigen, die es niemals ankündigen dürfte. Dieser Artikel beschreibt, wie das passiert, und die drei Sicherungen, die wir auf jedes Kunden-Gateway setzen, damit es nicht passieren kann.

Warum Gateways pro Kunde überhaupt BGP sprechen

Ein gemeinsam genutzter VPN-Konzentrator mit statischen Routen sieht einfacher aus, bis Sie ein Subnetz hinzufügen, einen Kunden zwischen Firewalls verschieben oder den Ausfall eines Gateways überstehen müssen. Mit einem dedizierten Gateway pro Kunde, das jeweils ein privates AS innerhalb unserer Plattform betreibt und mit einem zentralen Policy-Gateway peert, ist das Hinzufügen eines Netzes eine Ankündigung, und der Verlust eines Pfads ist ein Rückzug, der von selbst konvergiert. Die Policy des Kunden bleibt am Edge des Kunden, und die Transit-Policy bleibt zentral.

Der Preis dafür ist, dass jedes Gateway nun das Routing für alle beeinflussen kann. Es braucht also Leitplanken, die nicht davon abhängen, dass jemand vorsichtig ist.

Wie Leaks tatsächlich entstehen

In den meisten veröffentlichten Post-mortems ist die Ursache eines Route-Leaks aus einem Edge-Gerät selten ein exotischer BGP-Fehler. Es ist Redistribution. Jemand aktiviert «redistribute connected» oder «redistribute static», um sich Tipparbeit zu sparen, und das Gateway beginnt, seinen eigenen WAN-Link, seinen VPN-Tunnel-Pool, ein Management-Subnetz oder eine Route anzukündigen, die es von woanders gelernt hat. Auf einer Open-Source-Firewall mit Routing-Daemon ist diese Option oft nur ein Häkchen entfernt.

Sobald eine geleakte Route upstream akzeptiert wird, kann der Verkehr für dieses Prefix zum falschen Gateway gezogen werden, oder das Netz eines Kunden wird von Orten aus erreichbar, von denen aus es das nicht sein sollte. Nichts stürzt ab. Der Verkehr geht einfach irgendwohin, wo niemand ihn erwartet.

Sicherung eins: Ankündigung mit expliziten network-Statements

Ein Gateway sollte genau die Prefixes ankündigen, die dem Kunden gehören, einzeln aufgeführt, und sonst nichts. In FRR, das unter vielen Routing-Plugins von Firewalls steckt, sieht das so aus:

router bgp 64601
 bgp router-id 10.0.0.2
 neighbor 10.0.0.1 remote-as 64600
 address-family ipv4 unicast
  network 198.51.100.0/27
  neighbor 10.0.0.1 prefix-list CUSTOMER-OUT out
 exit-address-family

Das network-Statement kündigt nur ein Prefix an, das tatsächlich in der Routing-Tabelle vorhanden ist. Ein Tippfehler kündigt also nichts an, statt etwas Falsches.

Sicherung zwei: eine passende ausgehende Prefix-List

Doppelt hält besser. Selbst mit expliziten network-Statements erlaubt eine ausgehende Prefix-List nur die eigenen Prefixes des Kunden und verwirft alles andere:

ip prefix-list CUSTOMER-OUT seq 10 permit 198.51.100.0/27
ip prefix-list CUSTOMER-OUT seq 100 deny any

Falls jemals etwas versucht, mehr anzukündigen, verwirft diese Liste es auf dem Weg hinaus. Spiegeln Sie sie auch auf der empfangenden Seite: Das zentrale Gateway akzeptiert von jedem Kunden nur die Prefixes, die diesem Kunden zugewiesen sind.

Sicherung drei: keine Redistribution, und prüfen, dass sie aus bleibt

Redistribution ist deaktiviert, und das ist Teil der Konfiguration, die Sie verifizieren, keine Annahme. Auf FRR prüfen Sie das mit einer Zeile:

vtysh -c 'show running-config' | grep -i redistribute

Ein leeres Ergebnis ist das einzige akzeptable Ergebnis. Weil manche Firewall-Oberflächen die Redistribution als bequemes Kontrollkästchen anbieten, gehört diese Prüfung in die Verifikation Ihres Builds, nicht nur in das ursprüngliche Design.

Vergleich mit einem bekannt guten Gateway vor der Übergabe

Drei Sicherungen verhindern Leaks. Sie verhindern nicht die andere häufige Störung von Gateways pro Kunde: eine Einstellung, die von den funktionierenden Gateways abweicht und ein VPN verursacht, das «nicht verbindet» oder verbindet, ohne irgendetwas zu erreichen. Eine fehlende Pass-Regel für den VPN-Port auf der WAN-Schnittstelle, ein ausgehendes NAT, das im Automatikmodus geblieben ist, eine Schnittstellenregel, die restriktiver ist als beabsichtigt, eine geringfügig andere Authentifizierungsoption: Jede davon übersieht man mit dem bloßen Auge leicht.

Die Abhilfe ist mechanisch. Konfigurieren Sie jedes Gateway über seine API, nie von Hand, holen Sie dann dieselben Einstellungen von einem bewährten Referenz-Gateway und vom neuen Gateway ab und vergleichen Sie sie Feld für Feld:

• Einstellungen der VPN-Instanz: Protokoll, Port, Ciphers, Authentifizierungsmodus, gepushte Routen und DNS.
• WAN-Firewallregeln für den VPN-Port und die Diagnose.
• Regeln auf der VPN-Schnittstelle selbst.
• Modus und Regeln des ausgehenden NAT.
• BGP-Konfiguration, einschließlich des Felds für die Redistribution.

Jede Abweichung, die für diesen Kunden nicht ausdrücklich erwartet wird, blockiert die Übergabe. Keine Zugangsdaten verlassen das Gebäude, bevor der Vergleich sauber ist. Das dauert Sekunden und ersetzt einen Nachmittag Fehlersuche aus der Ferne mit einem Anwender, der einfach nur arbeiten will.

Zugang pro Person, richtig gemacht

Ein Client-Zertifikat pro Person, signiert von einer Zertifizierungsstelle, die dem Kunden gehört, plus ein Zugangsdatum, bedeutet: Ein verlorener Laptop ist ein widerrufenes Zertifikat, und niemand sonst ist betroffen. Eine feste Tunneladresse pro Person lässt die Firewall-Policy einer Person über Geräte hinweg folgen.

Checkliste für Ihre eigenen Gateways

• Wird jedes Kunden-Prefix durch ein explizites network-Statement angekündigt?
• Gibt es auf jeder Kunden-Session eine ausgehende Prefix-List und zentral eine passende eingehende?
• Kommt ein grep nach redistribute auf jedem Gateway leer zurück?
• Werden die Gateways über eine API konfiguriert, und wird das Ergebnis vor der Übergabe mit einer bekannt guten Referenz verglichen?
• Ist der Fernzugang pro Person eingerichtet, mit Zertifikaten, die Sie einzeln widerrufen können?

Jedes Kunden-Gateway, das wir bauen, hat diese Sicherungen, in seinem eigenen Segment und auf seiner eigenen Firewall. Wenn Sie privaten Zugang zu Ihrer Plattform so gebaut haben möchten, helfen wir gern.

Mit einem Ingenieur sprechen

Verwandt: Private Anbindung: VPN-Gateways und Standleitungen · Managed Perimeter-Firewalls · Verschlüsseltes Multi-Site-Backbone: das DMVPN-Mesh