Protect your BGP Sessions from DDoS Attacks

Posted on

Networks that think they are “DDoS resilient” get surprised when their BGP Sessions go down from an easily crafted DDoS. BGP port (179) is left open to the Internet and is an easy target for a low-level attack that will knock down your BGP session. Shodan’s BGP Report 325,082 open port 179 instances (June 2023). That is 325,082 BGP sessions connected to organizations that are at risk. That is huge, so we double-checked with Shadowserver on their vulnerable BGP session dashboard. As of July 1st, 2023, Shadowserver has seen around 394,000 accessible BGP servers that are reachable, scalable, and easily DDoSed!

How easy is it to DDoS your BGP session?

The BGP Process on a network device is in the route processor. The data paths to the route processor are NOT the same speed as the data plane. The Control Plane (routing and control protocols) and Management Plane (telnet, SSH, SNMP, NetConf, etc.) are at ETHERNET speeds of less. Some devices have 10 Mbps ethernet chips throttled down on the device’s interconnection fabric.

DDoS traffic ‘punts’ from the data plane and goes through the supporting internals at lower speeds.

Lower speeds mean you do not need a volumetric attack on the organization. A 400Gbps link to the Internet can be knocked out with a crafted 100Mbps attack on port 179.

How Bad Can It Get?

The Shadowserver Foundation quickly added two new reports and a dashboard view of all the open BGP ports (see illustration). These open ports are seen because Shadowserver scans them. If they are scalable, they are attackable. That means you do not need massive DDoS to knock down a link. All you need is a small DDoS and disrupt the BGP session.

Shadowserver has made it easy for organizations with two new reports:

This is a report on your network’s open BGP sessions.

View on Shadowserver’s Dashboard

Step-by-Step Guide to Quickly Protect BGP Sessions

Take the time to ask the question …. Do we have our BGP ports protected? If not, work with your peers to deploy an Infrastructure ACL (iACL) to cover all your network devices, deploy specific data plane ACLs on your routers/switches to protect them, work with your vendor to deploy their “Control Plane Protection,” work with your peers to configure General Purpose TTL Security Mechanism (GTSM) on all you BGP peering sessions, and set up appropriate monitoring so you know when people are trying to DDoS you port 179. This approach establishes a layered BGP session defense for each router/switch.

None of these tasks require any CAPEX. Your network devices can do all of this TODAY. Here is a step-by-step guide to help your organization architect BGP Session Resiliency.

RECOMMENDATION! Read through RFC 7454 – BGP Operations and Security.

Step 1 – Set up an Infrastructure ACL (iACL) on your Network to protect your Routing Control Plane.

Infrastructure ACLs (iACLs) are essential to protect your network! These ACLs are Explicit Permit ACLs. That means EVERYTHING is DENIED by DEFAULT. You then explicitly permit the IPv4/IPv6 blocks, protocols, source IP/port, destination IP/port, and other fields.

Routes had problems with large ACLs that checked all packets in the past. This is no longer the case. Most of the large broadband providers in the US deploy Exploitable Port Filters that combine the iACL with port filtering to protect their customers (see Filtering Exploitable Ports and Minimizing Risk from the Internet and from Your Customers)

BGP protection happens with an iACL rule that blocks BGP access to your router’s control and management plane and EXPLICITLY PERMITTING the BGP speakers who need to “BGP Peer” with your router.

How would you configure this policy? It would be specific to your network and topology. There are many paths to success. Explore the options, talk to your peers, consult with your vendors, and WRITE DOWN THE POLICY!

Step 2 – Set up an Infrastructure ACL on your Router/Switch to Protect your Route Processor

Remember, DDoS Threat Actors can get inside your network. They can reflect off devices or use violated devices to attack you from within. “Defence in Depth” does not work in a world where you cannot trust anything. You need “Dipping Dot” security where everything is distrustful, and you put up protections. The network device’s iACL would protect the router from a port reflection attack inside the network.

Yes, “zero trust” extends inside the network. The router’s iACL would permit all the data plane traffic but have explicit ACLs to protect the control and management plane of the router.

Step 3 – Control Plane Protection

Many routers have some type of control plan protection. These are ACLs and rate limiters inside the router that apply policy before the packet arrives on the BGP process. It would be worth reading RFC 6192 Protecting the Router Control Plane. This is a peer-reviewed RFC providing collected practices for control plane protection.

Work with your vendor to explore these options. Here are a couple of examples:

Step 4 – General Purpose TTL Security Mechanism (GTSM)

Most BGP sessions are one hop away. If the session is one-hop way, then the Time To Live (TTL) of the packet would be between 254 – 250 (depending on the TCP checks). A simple security approach would be to check the TTL of the packet. If it is between 255 and 250, then the packet is safer. If the TTL of the packet is 180, then it is many hops away and most likely a bad packet.

GTSM is a technique configured on the routers to use this “predictable TTL” as another security tool.

GTSM by itself will not stop DDoS Flood from reaching your route processor. But, if you know the TTL Range of the BGP sessions, your vendor’s ACL might allow you to put the TTL range into the iACL or Control Plane ACL.

Step 5 – TCP AO (replacing BGP MD5)

TCP Authentication Option (TCP-AO)TCP Authentication Option (TCP-AO) replaces the BGM MD5 feature. RFC 5925 ‘The TCP Authentication Option would now be used between BGP peers. TCP AO protects very low-volume TCP state attacks that would drop the session.

Most BGP session DDoS attacks are volumetric attacks that focus on saturating the control plane to the BGP session. BUT, BGP Session RST attacks have happened in the past.

Take a moment to watch SwiNOG#38 | TCP Authentication Option: How it works and where it can be used | Remi Locherer | Arista to get an excellent TCP-AO update.

Finally – Monitor for Session Attacks

Monitor the layers of defense. You need to alarm and investigate if an attacker is trying to hit your BGP Session. BGP Session attacks indicate an experienced and sophisticated attacker who has done their homework. When you see this, investigate. BGP might have been protected, but the threat actor might be trying something else.

How to monitor for BGP Session attack attempts? The options depend on your network telemetry architecture. It could be as simple as an ACL log, Netflow/IPFIX, or one of your security tools.

Extra – Don’t Use the Physical Interface as the BGP IPs

The most resilient networks will ensure their BGP Peering subnets are not advertised on protected physical links or architected in a way where they cannot be externally targeted. For example, putting your BGP session on a separate IP block from the connected interface is one way to make it harder for a threat actor to find what to target.

There are multiple approaches that all need to match your network topology, your peer’s topology, and your vendor’s capabilities. In essence, this approach works – but needs to be architected into your BGP peering.

What about ….

What about BFD (Bidirectional Forwarding Detection RFC5880), BGP Hold Timers, and Route Flap Damping (RFC2439)? These are BGP Resiliency Widgets. They are widgets, sprockets, and cogs that must be part of your BGP Resiliency architecture. These do have value. They are used. But, they are architected into a BGP resiliency architecture. Seek conversations with your peers, the operations community, and other operators about what they do.

How to get Help?

Call your BGP peers and upstream providers. Ask to have a “meaningful conversation on BGP Security.” People who configure BGP are a unique community who helps each other. Why? Because we are all interconnected with each other. Helping each other add more BGP Resiliency benefit everyone.

Notice …. I did not say, “talk to your vendor.” Vendors are not running the network. They are selling you the widgets. Talk to your peers who configure and maintain BGP.

To find out more, watch this Security Workshop Video from APRICOT 2022 – Session 4.1 – Protecting Routers, Switches, and Network Devices (APRICOT 2022 – Day 4)

Time to Take Action

None of these BGP protective measures REQUIRE CAPEX! Do you commit to protecting your organization from a focused and targeted BGP attack? What do you tell your boss when a small attack volume knocks out the business?

What will your Board of Directors say to the US SEC when the absence of BGP Security BCPs impacts shareholder interest?