The Border Gateway Protocol (BGP) is widely regarded as the dominant routing protocol on the Internet. Having been in use since the Internet was commercialized, BGP version 4 boasts a legacy of over a decade. In practice, BGP has proven to be highly effective, largely due to its simplicity and resilience, which have been pivotal in its integral role within the global Internet infrastructure. However, it is important to note that BGP inherently also has some performance and security issues.
Given that BGP serves as the primary driving force behind the Internet, it becomes crucial to prioritize the security of devices dedicated to running this protocol. Unfortunately, the prevalence of vulnerabilities due to misconfigurations continues to be a recurring issue. To address this concern, we have provided several recommendations based on trustworthy data.
There are various configurable mitigations available to enhance the security of BGP connections between BGP neighbors. It is important to note that relying solely on one mitigation may not provide comprehensive protection for the BGP service. To effectively mitigate the common threats mentioned above, it is recommended to implement most, if not all, of the following mitigation methods:
Access Control Lists (ACLs) on routers serve the purpose of preventing undesirable or malicious traffic from reaching the router in the first place. This effectively blocks unwanted traffic and minimizes the risk to the router. To ensure effective control, ACLs should specifically permit only legitimate BGP traffic from authorized BGP neighbors. After creating the ACLs, it is crucial to apply them to the interface connected to the trusted BGP neighbors for inbound traffic filtering.
Router(config)# access-list access-list-number permit tcp host {trusted-BGP-neighbor-addr} host {local-bgp-addr} name eq bgp
Router(config)# access-list access-list-number permit tcp host {trusted-BGP-neighbor-addr} eq bgp host {local- bgp-addr} name
Router(config)# access-list access-list-number deny tcp any any eq bgp Router(config)# access-list access-list-number deny tcp any eq bgp any
To prevent unauthorized BGP traffic, you can create an ACL with two logical sections. The first section includes rules to permit traffic from known BGP neighbors, while the second section denies all other BGP traffic. Since BGP sessions can be initiated by either neighbor, each permitted neighbor will require two lines in the ACL.
For example, the first line allows a trusted neighbor to initiate a BGP session, and the second line allows return traffic from a BGP session established by the host. After permitting each trusted host, you must apply a deny statement for all other BGP traffic. These rules can be inserted before or after any existing ACL rules for the given interface.
Here is an sample of how you can create and apply these ACLs to the host 10.1.1.1 with remote neighbor 10.1.1.2. In this scenario, the existing security policy allows all traffic through interface FastEthernet 0/0, and the objective is to filter unknown BGP connections.
Router(config)# access-list 101 permit tcp host 10.1.1.2 host 10.1.1.1 eq bgp
Router(config)# access-list 101 permit tcp host 10.1.1.2 eq bgp host 10.1.1.1
Router(config)# access-list 101 deny tcp any any eq bgp
Router(config)# access-list 101 deny tcp any eq bgp any
Router(config)# access-list 101 permit any any
Router(config)# interface FastEthernet 0/0
Router(if-config)# ip access-group 101 in
In Juniper, an Access Control List (ACL) is also referred to as a filter policy. Each policy consists of a set of rules that contain matching criteria and the desired action. Most filter policies comprise multiple rules.
Following a similar approach to the Cisco example, the first term in the below example permits a trusted neighbor to initiate a BGP session. The second term enables return traffic from a BGP session established by the host. To handle any remaining BGP traffic, a deny statement is required. Finally, the last term allows for other non-BGP traffic to pass. The ACL is then applied to an interface.
user@Router# edit firewall family inet filter [FilterName]
user@Router# set term [TermName1] from source-address [local-bgp-addr]
user@Router# set term [TermName1] from destination-address [trusted-BGP-neighbor-addr] user@Router# set term [TermName1] from destination-port [port/protocol]
user@Router# set term [TermName1] then accept
user@Router# set term [TermName2] from source-address [local-bgp-addr]
user@Router# set term [TermName2] from destination-address [trusted-BGP-neighbor-addr]
user@Router# set term [TermName2] from source-port [port/protocol]
user@Router# set term [TermName2] then accept
user@Router# set term [TermName3] from destination-port [port/protocol]
user@Router# set term [TermName3] then reject
user@Router# set term [TermName4] then accept
user@Router# edit interface fe-0/1/0 unit 0 inet
user@Router# set filter input/output [FilterName]
Control Plane Policing (CoPP) is a security feature that safeguards the router’s control plane against DoS attacks. CoPP allows administrators to manage and rate-limit traffic flow to the control plane. By treating route processor resources as distinct objects with their input interface, CoPP protects the router processor. It helps prevent overwhelming the processor with malicious or unnecessary traffic, thereby ensuring optimal performance.
Create an Access Control List (ACL) to match the desired traffic. Build a class-map that tags the traffic with a specific Quality of Service (QoS) label or class, using the ACL. Create a policy-map to apply the policy to each class. This step allows for different actions or policies, such as police and drop. Apply the policy map to the control plane. Implementing these steps will enhance the readability and comprehension of the CoPP configuration in the Cisco IOS syntax.
Router(config)# access-list access-list-number permit protocol {tcp|udp} {any | host {source-addr|name} eq port number {any|host {source-addr} name}} eq port number
Router(config)# class-map {match-all|match-any} class-map-name
Router(config-cmap)# match access-group access-list-index
Router(config-cmap)# exit
Router(config)# policy-map policy-map-name
Router(config-cmap-)# class class-map-name
Router(config-cmap-c)# police pps [burst-normal] [burst-max] conform-action action exceed-action action [violate-action action]
Router(config-cmap-c-police)# exit
Router(config-cmap-)# exit
Router(config)# control plane
Router(config-cp)# service-policy {input|output} policy-map-name
The next sample demonstrates the steps needed to rate limit all BGP traffic from the trusted neighbor 10.1.1.3 and discard any other BGP traffic aimed at the control plane. The ACL entries that match the BGP packets to and from 10.1.1.3 with the permit action will trigger a match to the “BGP-Policy”. Consequently, the packets will be policed (rate-limited) and allowed through by the CoPP. The packets will be allowed to pass as long as the number of packets stays below the defined threshold (4000 bps in this case). Please note that the rate-limiting parameters provided serve as an example only. Depending on user requirements or hardware constraints, they should be adjusted accordingly for each device.
Router(config)# access-list 101 permit tcp host 10.1.1.3 any eq bgp
Router(config)# access-list 101 permit tcp host 10.1.1.3 eq bgp any
Router(config)# access-list 102 deny tcp host 10.1.1.3 any eq bgp
Router(config)# access-list 102 deny tcp host 10.1.1.3 eq bgp any
Router(config)# access-list 102 permit tcp any any eq bgp
Router(config)# access-list 102 permit tcp any eq bgp any
Router(config)# class-map match-all COPP-BGP
Router(config-cmap)# match access-group 101 “
Router(config-cmap)# exit
Router(config)# class-map match-all DROP-BGP
Router(config-cmap)# match access-group 102
Router(config-cmap)# exit
Router(config)# policy-map BGP-Policy “
Router(config-cmap-)# class COPP-BGP
Router(config-cmap-c)# police 4000 1500 conform-action transmit exceed-action drop
Router(config-cmap-c-police)# exit
Router(config-cmap-)# class DROP-BGP
Router(config-cmap-c)# drop
Router(config-cmap-)# exit
Router(config)# control plane
Router(config-cp)# service-policy input BGP-Policy
One notable difference between Cisco and Juniper is that Juniper uses the Loopback 0 interface as the control plane interface. Configuring CoPP in Juniper involves three basic steps:
user@Router# set firewall policer [policy-name] filter-specific
user@Router# set firewall policer [policy-name] if-exceeding bandwidth-limit [bits-per-second-bandwidth- value] burst-side-limit [bust-value]
user@Router# set firewall policer [policy-name] then discard
user@Router# set firewall filter [filter-name] term [rule-name] from protocol [protocol-name] destination-port [Port/Protocol]
user@Router# set firewall filter [filter-name] term [rule-name] from source-address [ip-address] user@Router# set firewall filter [filter-name] term [rule-name] then policer [policy-name]
user@Router# set interfaces [interface-name] unit [interface-unit-number] family inet filter input [filter- name]
user@Router# set firewall policer BGP-Policy filter-specific
user@Router# set firewall policer BGP-Policy if-exceeding bandwidth-limit 40000 burst-side-limit 1500
user@Router# set firewall policer BGP-Policy then discard
user@Router# set firewall filter CoPP-Filter term BGP from protocol tcp destination-port bgp user@Router# set firewall filter CoPP-Filter term BGP from protocol tcp source-port bgp
user@Router# set firewall filter CoPP-Filter term BGP from source-address 10.1.1.3/32 user@Router# set firewall filter CoPP-Filter term BGP then policer BGP-Policy
user@Router# set interface lo0 unit 0 family inet filter input CoPP-Filter
The BGP maximum prefix feature provides admins with the ability to manage the number of prefixes received from a neighbor. By limiting the number of BGP prefixes learned from a specific neighbor, it helps prevent a single neighbor from overwhelming router resources. When configured, this feature terminates the neighbor relationship when the number of received prefixes exceeds the configured maximum limit.
To define the maximum number of prefixes accepted from BGP neighbors before terminating the BGP session, use the neighbor maximum-prefix command.
Router(config-router)# neighbor {ip-address | neighbor-group-name} maximum-prefix maximum [threshold] [restart restart-interval] [warning-only]
Router(config-router)# neighbor 10.1.1.3 maximum-prefix 10 80 restart 60
user@Router# edit routing-options
user@Router# set maximum-prefixes [limit] threshold [percent-limit-warning]
user@Router# edit routing-options
user@Router# set maximum-prefixes 10 threshold 80
Prefix filtering allows a network admins to permit or deny specific prefixes for each BGP neighbor, preventing BGP from inadvertently adding unwanted or illegitimate routes to the routing table. This configuration ensures that only the correct routes are accepted (inbound) or advertised (outbound). Similar to white listing, prefix filtering can be configured to only permit known or legitimate prefixes and deny others (as defined by the network policy) that are sent to or received from each BGP neighbor. The configured prefix lists should be applied to each BGP neighbor in both inbound and outbound directions.
Prefix lists can specifically allow only those prefixes that are permitted by the routing policy of a network, which is an example of white list-based filtering. If this configuration is not feasible due to the large number of prefixes, a prefix list can specifically block known undesirable prefixes (a technique known as black list filtering).
Below is the syntax for Cisco IOS to configure a prefix-list and apply it to a neighbor. To add additional lines to the prefix-list simply put in a new sequence number. Similar to ACLs, the order of prefix-lists is very important. Since prefix-lists are processed top to bottom and stop processing a route once it matches a single line, white list prefix-list administrators should always put more specific prefixes near the beginning and less specific near the end.
Router(config)# ip prefix-list {list-name [seq number] {deny|permit} network/length}
Router(config)# router bgp {AS-number}
Router(config-router)# neighbor {ip-address | neighbor-group-name} prefix-list {prefix-list name} [in|out]
The BGP neighbor at 11.1.1.1 can be managed through either white listing or black listing. With white listing, only routes from 1.1.1.0/24 and 1.2.2.0/24 are accepted. On the other hand, with blacklisting, the 1.1.1.0/24 and 1.2.2.0/24 routes are rejected while all other routes are accepted. It’s worth mentioning that in this example, the prefix-list is applied in the inbound direction to limit the routes learned from a neighbor. However, if the “out” keyword had been used, these prefix-lists would limit the routes advertised by the router.
Router(config)# ip prefix-list Ingress-White seq 5 permit 1.1.1.0/24 Router(config)# ip prefix-list Ingress-White seq 10 permit 1.2.2.0/24 Router(config)# ip prefix-list Ingress-White seq 15 deny 0.0.0.0/0 le 32 Router(config)# router bgp 65001
Router(config-router)# neighbor 11.1.1.1 prefix-list Ingress-White in
Router(config)# ip prefix-list Ingress-Black seq 5 deny 1.1.1.0/24 Router(config)# ip prefix-list Ingress-Black seq 10 deny 1.2.2.0/24 Router(config)# ip prefix-list Ingress-Black seq 15 permit 0.0.0.0/0 le 32 Router(config)# router bgp 65001
Router(config-router)# neighbor 11.1.2.1 prefix-list Ingress-Black in
Juniper routers config filters follow a slightly different approach. Juniper separates the prefix list from the corresponding action, which is achieved through the use of a prefix-list object. This object contains a grouped list of all the desired prefixes. Subsequently, a policy-statement is created, which can include multiple term statements. Each term statement determines whether to permit or deny the prefix-list objects. Finally, the policy-statement is applied in the desired direction, either inbound or outbound, to the intended BGP group:
user@Router# edit policy-options prefix-list [list-name] user@Router# set [prefix-address]
user@Router# edit policy-options policy-statement [policy-name] term [term-name]] user@Router# set from prefix-list [list-name]
user@Router# set then accept/reject
user@Router# edit protocols bgp group [group-name] user@Router# set type [internal/external]
user@Router# set local-address [local-ip-address] user@Router# set [import|export] [import/export-policy] user@Router# set neighbor [neighbor-ip-address]
BGP Prefix Filters with Autonomous System (AS) path access lists can be used to filter illegitimate prefixes from the BGP routing tables. AS path access allows network admins to filter inbound and outbound prefixes based on the AS number. When combined, AS Path Access Lists and Prefix Lists create a robust set of BGP route filters, ensuring only desired traffic routes and preventing unwanted routes.
The first step to configure an AS-path filter on Cisco routers is to create an AS-path ACL. This ACL utilizes regular expressions for AS-path matching. Once the AS-path ACL is generated, it can be associated with the desired BGP neighbor using the following syntax.
Router(config)# ip as-path access-list number {permit|deny} regexp
Router(config-router)# neighbor ip-address filter-list number {in/out}
Router(config)# ip as-path access-list 1 permit ^1000$
Router(config)# ip as-path access-list 2 permit ^$
Router(config-router)# neighbor 11.1.1.1 filter-list 1 in
Router(config-router)# neighbor 11.1.1.1 filter-list 2 out
Define the desired regular expressions separately from the policy by creating as-path objects. Utilize the created as-path objects when creating policies. Each policy can accept or reject different AS paths and may have multiple terms. Link the policies to a BGP group, specifying the inbound or outbound direction.
user@Router# edit policy-options
user@Router# set as-path [as-path-name] [regular-expression]
user@Router# edit policy-options policy-statement [policy-name] term [term-name] user@Router# set from as-path [as-path-name]
user@Router# set then accept/reject
user@Router# edit protocols bgp
user@Router# set group [group-name] import [import-policy] user@Router# set group [group-name] export [export-policy]
user@Router# edit policy-options
user@Router# set as-path From-AS-1000 “^1000$” user@Router# set as-path From-AS-Local “1005”
user@Router# edit policy-options policy-statement Match-AS-1000 term 1
user@Router# set from as-path From-AS-1000
user@Router# set then accept
user@Router# edit policy-options policy-statement Match-AS-Local term 1
user@Router# set from as-path From-AS-Local
user@Router# set then accept
user@Router# edit policy-options policy-statement Match-AS-Local term 2
user@Router# set then reject
user@Router# edit protocols bgp
user@Router# set group AS-1000 import Match-AS-1000
user@Router# set group AS-1000 export Match-AS-Local
Authenticating between BGP neighbors confirms the legitimacy and trustworthiness of the neighbors. It also verifies their communication and ensures that only routes learned from trusted neighbors are added to the routing table. Without BGP authentication, a malicious user can spoof a neighbor’s IP address, establish BGP connections, and potentially manipulate BGP routing tables.
To enable neighbor authentication, the authentication password must be enabled on both sides of the peering session. It is important to adhere to the local password policy in terms of length and complexity. For optimal security, ensure that this password is shared out-of-band.
Router(config-router)# neighbor ip-address password string
Juniper offers a more advanced configuration option for BGP neighbor authentication. Key differences include authentication algorithms and setting a key start time. The key start time allows for pre-configuration of BGP sessions on both sides before switching to new keys at a specified time. This reduces downtime and maintains an active session during BGP authentication configuration. The initial step in configuring BGP authentication in Juniper involves defining a key-chain object and entering a strong password for neighbor authentication. The subsequent step is to associate the key-chain with a BGP group, effectively enabling BGP authentication:
user@Router# edit security authentication-key-chains key-chain [key-chain-name]
user@Router# set key [key-identifier] secret [password]
user@Router# set key [key-identifier] start-time [YYYY-MM-DD.HH:MM)
user@Router# edit protocols bgp group [group-name]
user@Router# set authentication-key-chain [key-chain-name]
user@Router# set authentication-algorithm [md5|hmac-sha-1-96|aes-128-cmac-96]
The BGP TTL security check protects BGP against DoS attacks and route manipulation attempts. When the security check is enabled, it sets the expected final TTL value for incoming packets from each external BGP neighbor. As an IP packet moves towards its final destination, its TTL value decreases for each router hop. The BGP TTL security check compares the received packet’s TTL value to the expected TTL value for the BGP session. If the TTL value is less than the expected value, the packet is dropped. If the TTL value is equal to or greater than the expected value, the check is passed and the session establishes.
Router(config)# router bgp as-number
Router(config-router)# neighbor ip-address ttl-security hops hop-count
user@Router# edit protocols bgp group [group-name]
user@Router# set neighbor [neighbor-ip-address]
user@Router# set multihop ttl [ttl-value]
The “bgp log-neighbor-changes” command in Cisco devices enables logging of BGP neighbor status changes (up or down) and resets for troubleshooting network connectivity problems and measuring network stability. Unexpected neighbor resets may indicate high error rates or packet loss in the network, requiring further investigation.
To display the log for neighbor changes, use the “show logging” command. It is considered a best practice to send all logging to a syslog server. In this example, we provide the syntax to enable local logging. Please refer to the vendor guidance to configure logging to a syslog server.
Router(config-router)# bgp log-neighbor-changes
Juniper devices procedures are similar. The only command that is required is set log- updown within the protocol bgp configuration.
user@Router# edit protocol bgp
user@Router# set log-updown
BGP relies on the Transmission Control Protocol (TCP) as its transport protocol, making it susceptible to TCP-based attacks. Here are the most common BGP threats: