Open BGP Daemons: There's So Many of Them
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.
-
not perfect, but not terribly wrong either. See the previous blog post for details. ↩︎
-
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. ↩︎
Most vendors have an easy option fix this. Nokia SROS does apply-path which you can use to generate dynamic filters for your configured BGP sessions:
https://infocenter.nokia.com/public/7750SR222R1A/index.jsp?topic=%2Fcom.nokia.Router_Configuration_Guide%2Fapply-path_-d638e1823.html
Then, ofcourse, use this ip-prefix-list on your interface towards the corresponding exchange.
That's a really cool feature. Unfortunately (AFAIK) most vendors don't offer something similar, or hopefully I haven't looked hard enough.
"apply-path" is also a Junos feature (https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/ref/statement/apply-path-edit-policy-options.html)