Filtering BGP to the Router - TCP/179
One of the first sections of the RFP discusses filtering TCP/179 from reaching the control plane of your router. The relevant RFC 7454 text is:
The BGP speaker needs to be protected from attempts to subvert the
BGP session. This protection SHOULD be achieved by an Access Control
List (ACL) that would discard all packets directed to TCP port 179 on
the local device and sourced from an address not known or permitted
to become a BGP neighbor. Experience has shown that the natural
protection TCP should offer is not always sufficient, as it is
sometimes run in control-plane software. In the absence of ACLs, it
is possible to attack a BGP speaker by simply sending a high volume
of connection requests to it.
The idea is that you should accept BGP (tcp on port 179) packets only from those peers that you have actually configured BGP with. This is fairly simple to implement and follows the general philosophy of only allowing connection attempts/data from the hosts you actually anticipate/configure. This should be configured on the management interface of the router (Juniper), where the destination/source is implicitly the router proper. If it were configured on a "normal" router interface the filter will need to specific enough that unauthorized BGP to the router was filtered but other BGP would not be (Cisco); we wouldn’t want to accidentally filter someone else’s multi-hop BGP session that is just transiting the interface.
Finally, while these examples touch on IPv4, don’t forget about your IPv6 sessions! You’ll need to implement the filters for that address family also, as well are for each routing instance!
Juniper Example:
This example uses the apply-path command in JunOS to automatically build a prefix-list based on who you have configured BGP with. In other words, as you add new BGP peers, or remove old ones, the prefix-list is automatically updated. This makes the maintenance of this on a Juniper relativly easy. The filter "input-strict-in" is applied on the lo0 management interface via the term "allow-bgp", where the automatically-built prefix-list is referenced. You should be aware that some QFX/EX platforms have limitations on filtering, both in terms of what can be filtered on and how much filtering programming space they have.
prefix-list BGP-PEERS {
apply-path "protocols bgp group <*> neighbor <*>";
lo0 {
unit 0 {
family inet {
filter {
input-list input-strict-in;
}
}
family inet6 {
filter {
input-list input-strict-in;
}
}
}
}
filter input-strict-in {
term allow-bgp {
from {
source-prefix-list {
BGP-PEERS;
}
protocol tcp;
port bgp;
}
then accept;
}
<additional terms>
Some Juniper code versions and/or platform combinations may not allow for both v4 & v6 addresses in the same prefix list/apply-path. In these cases something like the following should help with the specific address-family:
prefix-list BGP-Peers-v4 {
apply-path "protocols bgp group <*> neighbor <*.*.*.*>"; }
prefix-list BGP-Peers-v6 {
apply-path "protocols bgp group <*> neighbor <*:*>"; }
Here are some references for the Juniper “apply-path” command:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB29448&actp=RSS
Cisco XR Example:
The Cisco example is a bit less elegant. A specific access-list contains the source addresses for the BGP peers we wish to allow through. The list needs to be updated each time you configure, or deconfigure, a new BGP peer. The list is then applied to the various external and internal interfaces. Note how the destination is specified in the DENY. This is needed so only generalized BGP destined for the router is denied, and not BGP sessions transiting the interface. You can find more by referencing "infrastructure ACL’s" on the CIsco site.
ipv4 access-list input-strict-in
...
remark Only permit BGP session for peers
permit tcp host 192.0.2.1 host 192.0.2.2 eq bgp
deny tcp any host 192.0.2.2 eq bgp
...
interface type interface-path-id
ipv4 access-group input-strict-in ingress
Brocade Example:
Brocade supports a “receive ACL” for both IPv4 & IPv6. This provides a single configuration point for blocking traffic destined to the control plane.
access-list 101 permit tcp host 1.2.3.4 host 4.3.2.1 eq bgp
access-list 101 deny tcp any host 4.3.2.1 eq bgp
access-list 101 permit ip any any
ip receive access-list 101 sequence 10
Here are some references for v4 & V6 “receive ACL’s”