Information
As a best practice, a service provider should only accept customer prefixes that have been assigned to that customer and any peering autonomous systems. A multi-homed customer with BGP speaking routers connected to the internet or other external networks could be breached and used to launch a prefix deaggregation attack. Without ingress route filtering of customers, the effectiveness of such an attack could impact the entire IP core and its customers.
NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.
Solution
Configure all eBGP routers to reject inbound route advertisements from a CE router for prefixes that are not allocated to that customer.
set policy-options route-filter-list customer1-routes <customer route 1/mask> orlonger
set policy-options route-filter-list customer1-routes <customer route 2/mask> orlonger
set policy-options route-filter-list customer1-routes-ipv6 <customer route 1/prefix> orlonger
set policy-options route-filter-list customer1-routes-ipv6 <customer route 2/prefix> orlonger
<additional route-filter-list for other customers>
set policy-options policy-statement bgp-accept-cust1-routes term 1 from route-filter-list customer-routes
set policy-options policy-statement bgp-accept-cust1-routes term 1 from route-filter-list customer-routes-ipv6
set policy-options policy-statement bgp-accept-cust1-routes term 1 then accept
set policy-options policy-statement bgp-accept-cust1-routes term 2 then reject
<additional policies for other customers>
set protocols bgp group customer1 import bgp-accept-cust1-routes
set protocols bgp group customer1 neighbor <address> import bgp-accept-cust1-routes
Note: An import filter is only required at the group, or the neighbor, level but not both unless the specific neighbor requires a different import filter than the group.