Skip to content

Latest commit

 

History

History
31 lines (21 loc) · 3.1 KB

open-bgp-daemons.md

File metadata and controls

31 lines (21 loc) · 3.1 KB
Raw
title date tags
Open BGP Daemons: There's So Many of Them
2023-11-08 00:02:00 -0800
BGP
security

A while ago, the Networking Notes blog published a link to my "Will Network Devices Reject BGP Sessions from Unknown Sources?" blog post with a hint: use Shodan to find how many BGP routers accept a TCP session from anyone on the Internet.

The results are appalling: you can open a TCP session on port 179 with over 3 million IP addresses.

{{

}}

Most of those IP addresses immediately close the connection1, but over 380.000 IP addresses send back BGP OPEN and BGP NOTIFICATION (go away) messages revealing the Router ID and Autonomous System Number (ASN).

{{

}}

{{

}}

To make matters worse, for Shodan to displays the BGP messages:

  • A BGP-speaking device must be reachable from the global Internet (not a good idea).
  • It must accept TCP sessions on port 179 from unknown IP addresses (bad, but that's how this world works).
  • It must be able to complete TCP session establishment, which means that it's sending BGP TCP packets with TTL much greater than one and not checking the incoming TTL (can't make a public comment, we're in the NSFW territory).
  • It must send a few BGP messages before closing the session. While there might be a number of open-source BGP daemons exhibiting that behavior, I found a single networking vendor in that category in my tests (and yes, they do set TTL to 255 on EBGP sessions by default just to make sure they can reply to anyone who wants to talk with them).

The reality is probably less dramatic. Any BGP-speaking router might have dozens of interfaces with dozens of IP addresses you can reach from the Internet. Still, that's a lot of potentially vulnerable devices2.

Finally, Shodan allows you to limit your queries to organizations or IP prefixes. If you're running BGP in your network (in particular, if you're a service provider), do yourself a favor, check whether your routers are exposed to the Internet, and deploy a few ACLs on Internet-facing interfaces.

Footnotes

  1. not perfect, but not terribly wrong either. See the previous blog post for details. ↩

  2. Don't tell me no networking vendor ever had a parsing bug that would cause the device (or routing daemon) to crash when receiving a well-crafted message. See this blog post and this presentation for some fun details. ↩