Tres salvaguardas que impiden que un gateway BGP de cliente filtre rutas

Un gateway dedicado por cliente, que nosotros construimos y operamos, haciendo peering internamente con nuestro gateway de políticas sobre números de AS privados, es el diseño correcto: aislamiento, una política que les pertenece y un routing que se adapta por sí solo. El BGP es interno a nuestra plataforma, no una sesión que ejecute el cliente. También significa que ahora opera muchos pequeños BGP speakers, y que un único ajuste descuidado en cualquiera de ellos puede anunciar rutas que nunca debería anunciar. Este artículo cubre cómo ocurre eso y las tres salvaguardas que ponemos en cada gateway de cliente para que no pueda ocurrir.

Por qué los gateways por cliente hablan BGP

Un concentrador VPN compartido con rutas estáticas parece más simple, hasta que tiene que añadir una subred, mover un cliente entre firewalls o sobrevivir al fallo de un gateway. Con un gateway dedicado por cliente, cada uno con un AS privado dentro de nuestra plataforma y en peering con un gateway de políticas central, añadir una red es un anuncio, y perder un camino es una retirada que converge sola. La política del cliente se queda en el edge del cliente, y la política de tránsito se queda en el centro.

El precio es que cada gateway puede ahora influir en el routing de todos. Así que necesita barreras que no dependan de que nadie tenga cuidado.

Cómo ocurren las fugas en realidad

En la mayoría de los post-mortems publicados, la causa de una fuga de rutas desde un dispositivo de edge rara vez es un bug exótico de BGP. Es la redistribución. Alguien activa «redistribute connected» o «redistribute static» para ahorrarse teclear, y el gateway empieza a anunciar su propio enlace WAN, su pool de túneles VPN, una subred de gestión o una ruta que aprendió de otro sitio. En un firewall de código abierto con un daemon de routing, esa opción suele estar a una casilla de distancia.

Una vez que una ruta filtrada se acepta aguas arriba, el tráfico para ese prefijo puede ser atraído hacia el gateway equivocado, o la red de un cliente puede volverse alcanzable desde sitios desde los que no debería. Nada se cae; el tráfico simplemente va a algún lugar inesperado.

Salvaguarda uno: anunciar con sentencias network explícitas

Un gateway debería anunciar exactamente los prefijos que pertenecen al cliente, listados uno a uno, y nada más. En FRR, que está debajo de muchos plugins de routing de firewalls, eso tiene este aspecto:

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

La sentencia network solo anuncia un prefijo que está realmente presente en la tabla de routing, así que una errata no anuncia nada en lugar de anunciar algo erróneo.

Salvaguarda dos: una prefix list saliente que coincida

Cinturón y tirantes. Incluso con sentencias network explícitas, una prefix list saliente permite solo los prefijos propios del cliente y deniega todo lo demás:

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

Si algo intenta alguna vez anunciar más, esta lista lo descarta a la salida. Refléjela también en el lado receptor: el gateway central acepta de cada cliente solo los prefijos asignados a ese cliente.

Salvaguarda tres: sin redistribución, y comprobar que sigue apagada

La redistribución está desactivada, y forma parte de la configuración que se verifica, no de una suposición. En FRR puede comprobarlo en una línea:

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

Un resultado vacío es el único resultado aceptable. Como algunas interfaces de firewall exponen la redistribución como una cómoda casilla, esta comprobación pertenece a la verificación de cada construcción, no solo al diseño original.

Compare con un gateway bueno conocido antes de la entrega

Tres salvaguardas evitan las fugas. No evitan el otro fallo común de los gateways por cliente: un ajuste que difiere de los gateways que funcionan, provocando una VPN que «no conecta» o que conecta sin alcanzar nada. Una regla de paso ausente para el puerto VPN en la interfaz WAN, el NAT saliente dejado en modo automático, una regla de interfaz más restrictiva de lo previsto, una opción de autenticación sutilmente distinta: cada una es fácil de pasar por alto a simple vista.

La cura es mecánica. Configure cada gateway a través de su API, nunca a mano, después extraiga los mismos ajustes de un gateway de referencia probado y del nuevo y compárelos campo a campo:

• Ajustes de la instancia VPN: protocolo, puerto, cifrados, modo de autenticación, rutas y DNS enviados al cliente.
• Reglas de firewall de la WAN para el puerto VPN y los diagnósticos.
• Reglas en la propia interfaz VPN.
• Modo y reglas del NAT saliente.
• Configuración BGP, incluido el campo de redistribución.

Cualquier diferencia que no esté explícitamente prevista para este cliente bloquea la entrega. Ninguna credencial sale del edificio hasta que la comparación está limpia. Lleva segundos y sustituye una tarde de resolución de problemas en remoto con un usuario que solo quiere trabajar.

Acceso por persona, bien hecho

Un certificado de cliente por persona, firmado por una autoridad de certificación que pertenece al cliente, más una credencial, significa que un portátil perdido es un certificado revocado y nadie más se ve afectado. Una dirección de túnel fija por persona permite que la política del firewall siga a un individuo a través de sus dispositivos.

Lista de comprobación para sus propios gateways

• ¿Se anuncia cada prefijo de cliente con una sentencia network explícita?
• ¿Hay una prefix list saliente en cada sesión de cliente, y otra entrante que coincida en el centro?
• ¿Un grep de redistribute devuelve vacío en todos los gateways?
• ¿Se configuran los gateways a través de una API, con el resultado comparado contra una referencia buena conocida antes de la entrega?
• ¿El acceso remoto es por persona, con certificados que puede revocar individualmente?

Cada gateway de cliente que construimos tiene estas salvaguardas, en su propio segmento y con su propio firewall. Si quiere acceso privado a su plataforma construido de esa manera, con gusto le ayudamos.

Hable con un ingeniero

Related (rows[1])

Relacionado: Conectividad privada: gateways VPN y líneas dedicadas · Firewalls perimetrales gestionados · Backbone cifrado multisede: la malla DMVPN