Detections
Analytics

4.1.4 Ensure Bogon Filtering is set (where EBGP is used)

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

Bogon prefixes should be filtered when using eBGP.

 Rationale:
 Bogon Networks are those IP Address blocks which should never appear on the Internet. Examples include loopback addresses, RFC1918 private addresses and IP blocks which have not yet been assigned by the IANA (Internet Assigned Numbers Authority) to one of the RIRs (Regional Internet Registries). If traffic arrives at your network edge from a Bogon network, the traffic is almost certainly malicious and should be filtered. Studies have shown instances where as much as 60% of DoS attack traffic is being sourced from Bogon or Martian (a subset which includes RFC1918 and RFC3330 networks) addresses.
 As a rule Bogon traffic should also be filtered from leaving the network as it may be malicious or represent a possible information leak. Either way, return traffic would not get back. Bogon information can be obtained from a number of sources such as:
 - IANA - Obtain the current IPv4 assignments list, anything that is shown as Unallocated or Reserved is a Bogon.
 - Team Cymru provides, what is effectively, the definitive Bogon list in a range of formats and through a BGP Route Server project.
 - RIPE NCC also provides lists of Unallocated, Martian and combined Bogon space.
 An important point to remember about Bogon filtering is that the addresses that make up Bogon space change. Unallocated addresses get allocated, reserved networks may be re-purposed, etc. If you keep your Bogon filters static, you may accidently block valid traffic from these addresses. Ensure you have a procedure to keep your Bogon lists up to date!

 NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

JUNOS offers a variety of options for filtering Bogons and Martians, which is why this item is not scored. Some of the more common options are discussed below.
 1 - The Martian Table Most Martian space (but not all, else you would not be able to use your router on private networks) is blocked using the Martian Routing Table, which is discussed elsewhere in this Benchmark and configured under the [edit routing-options martians] hierarchy. Route updates for prefixes in this special table are ignored, so adding Bogons here will prevent them being learned through any routing protocol.
 2 - Ingress Prefix Filtering Ingress Filtering should be used on eBGP sessions to prevent your own prefixes being advertised back to your network or, in the case of ISP networks, customer networks advertising prefixes other than those allocated to them.
 The other filtering types are covered previously. Prefix lists are configured under the [edit policy-options] hierarchy, but are discussed here as they are applied under the [edit protocols bgp <group name>] hierarchy. First configure a policy:
 [edit policy-options]
 user@host#edit policy-statement <policy name> term <term name>
 [edit policy-options policy-statement <policy name> <term name>]
 user@host#set from route-filter <network>/<mask> <exact | orlonger | prefix-length-range <start>-<end>> reject
 The last stage should be repeated for each prefix required, but as several options are shown, a couple of examples are given below:
 [edit policy-options <policy name> <term name>]
 user@host#set from route-filter 0.0.0.0/0 exact reject
 user@host#set from route-filter 10.0.0.0/8 orlonger reject
 user@host#set from route-filter 0.0.0.0/0 prefix-length-range /29-/32 reject
 The first line in the example rejects a default route advertised to the router and only that route. The second line will filter any route from the 10.0.0.0/8 range, for instance 10.1.1.0/24 or 10.2.0.0/16. The final line is a little more complex, this will reject any route with a mask length of /29, /30, /31 or /32 (generally eBGP routes should be summarized into larger prefixes than this). Having defined a policy, we need to apply it.
 As with most other BGP configuration options, you can apply the policy at Global, Group or Neighbor levels as suites your needs. In this example we will apply the policy to a group containing all our eBGP peers:

 [edit protocols bgp group <group name>]
 user@host#set import <policy name/s>
 3 - Peering with a Bogon Route Server As far as I am aware, the idea of using a BGP Peering session to a Route Server for updates on Bogon networks was hatched by Team Cymru and they offer a free, public Bogon Route Server, which you can peer with to keep you Bogon list up to date. The theory works equally well by peering to a route server of your own, allowing a greater degree of control over your Bogon list updates for your organization if desired. First a static route is created and configured to discard traffic. An address that is reserved for Test or Example networks is used, you may need to allow this /32 prefix in the Martian Table:

 [edit routing-options]
 user@host#set static route 192.0.2.1/32 discard no-readvertise retain
 An import policy should be set to match prefixes from the route servers AS and the Community (if used) for Bogon updates, setting the next hop to 192.0.2.1 and accepting the route.

 [edit policy-options]
 user@host#edit policy-statement <policy name> term <term name>
 [edit policy-options policy-statement <policy name> term <term name>]
 user@host#set from protocol bgp as-path <peer AS> community <community>
 user@host#set then next-hop 192.0.2.1
 Finally the BGP Peering and Group is configured with the import policy above and not to export. In addition security options covered in other recommendations should be used:

 [edit protocols bgp <group name>]
 user@host#set type external description 'bogon route servers'
 user@host#set import <policy name>
 user@host#set peer-as <AS of Route Server>
 user@host#set neighbor <neighbors IP>
 user@host#set local-address <local IP to use for peering>

 Default Value:
 Most Martians are filtered by default, most Bogons are not.

See Also

https://workbench.cisecurity.org/files/2278

Item Details

References: CSCv7|12

Plugin: Juniper

Control ID: e8764ebb418ba284cc83537055effd3109d097f49c043f47dd447ae11309a369