BGP Best Security Practices on Juniper Routers

Border Gateway Protocol or BGP, is a gateway protocol that enables the Internet to exchange routing information between AS or Autonomous Systems. It is used by Large Enterprise and Service Providers.

Here are the recommended Best Security Practices that need to be implemented on your Juniper Routers.

  1. Authentication need to be set for all peering using MD5

set protocols bgp group <group_name> authentication-key <MD5 key>

There are few supported authentication that you can use

  • aes-128-cmac-96 Cipher-based Message Authentication Code (AES128) (96 bits)
  • hmac-sha-1-96 Hash-based Message Authentication Code (SHA1) (96 bits)
  • md5 Message Digest 5

set protocols bgp group <group_name> authentication-algorithm <authentication type>

Verification:

show bgp neighbor | match “Authentication key is configured”
show bgp neighbor <Peer IP> | match “Authentication key is configured”

darwin@JUNIPER-re0> show bgp neighbor 192.168.0.173
Peer: 192.168.0.173+61073 AS 65535 Local: 192.168.0.174+179 AS 65536
Description:  BGP Peer1
Group: BGP-Group1 Routing-Instance: master
Forwarding routing-instance: master
Type: External State: Established Flags: <Sync RSync>
Last State: EstabSync Last Event: RecvKeepAlive
Last Error: Cease
Export: [ OUT-IPv4  ] Import: [ IN-IPv4 ]
Options: <Preference AuthKey LogUpDown AddressFamily PeerAS Multipath PrefixLimit Refresh>
Authentication key is configured

2. Configure Bogon Filtering

According to https://www.team-cymru.com/bogon-networks definition of bogons:

Bogons are defined as Martians (private and reserved addresses defined by RFC 1918, RFC 5735, and RFC 6598) and netblocks that have not been allocated to a regional internet registry (RIR) by the Internet Assigned Numbers Authority.

A bogon prefix is a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPNs or other tunnels) should never have an address in a bogon range. These are commonly found as the source addresses of DDoS attacks.

By default, Juniper has default and configured martian routes, they are filtered by default, but most Bogons are not.  To view:

show route martians table <routing table name>

Example:

darwin@JUNIPER-re0> show route martians table inet

inet.0:
0.0.0.0/0 exact — allowed
0.0.0.0/8 orlonger — disallowed
127.0.0.0/8 orlonger — disallowed
192.0.0.0/24 orlonger — disallowed
240.0.0.0/4 orlonger — disallowed
224.0.0.0/4 exact — disallowed
224.0.0.0/24 exact — disallowed

darwin@JUNIPER-re0> show route martians table inet6

inet6.0:
::1/128 exact — disallowed
ff00::/8 exact — disallowed
ff02::/16 exact — disallowed

Configure Bogon prefixes manually using Ingress Prefix Filtering.

a. Set the Bogon route filter list

set policy-options route-filter-list <filter_name> <IP address>  <options>

*options:
address-mask Mask applied to prefix address
exact Exactly match the prefix length
longer Mask is greater than the prefix length
orlonger Mask is greater than or equal to the prefix length
prefix-length-range Mask falls between two prefix lengths
through Route falls between two prefixes
upto Mask falls between two prefix lengths

Example:

set policy-options route-filter-list BOGON-PREFIXES 10.0.0.0/8 upto /32
set policy-options route-filter-list BOGON-PREFIXES 100.64.0.0/10 upto /32
set policy-options route-filter-list BOGON-PREFIXES 198.51.100.0/24 upto /32
set policy-options route-filter-list BOGON-PREFIXES 203.0.113.0/24 upto /32
set policy-options route-filter-list BOGON-PREFIXES 127.0.0.0/8 upto /32
set policy-options route-filter-list BOGON-PREFIXES 169.254.0.0/16 upto /32
set policy-options route-filter-list BOGON-PREFIXES 172.16.0.0/12 upto /32
set policy-options route-filter-list BOGON-PREFIXES 192.0.2.0/24 upto /32
set policy-options route-filter-list BOGON-PREFIXES 192.168.0.0/16 upto /32
set policy-options route-filter-list BOGON-PREFIXES 198.18.0.0/15 upto /32
set policy-options route-filter-list BOGON-PREFIXES 224.0.0.0/3 upto /32

b.  Create policy to reject all these Bogon routes

set policy-options policy-statement <policy name> term <term name> from route-filter-list <filter name>
set policy-options policy-statement <policy name> term <term name> then reject

Example:
set policy-options policy-statement  INFILTER term 1 from route-filter-list BOGON-PREFIXES
set policy-options policy-statement  INFILTER-v4 term 1 then reject

c. Import the Policy

set protocols bgp group <group_name> import <filter_name>

Example:

set protocols bgp group PEER-IPv4 import BOGON-PREFIXES

3. Ingress Filtering should be configured for eBGP peers

When peering with eBGP routers or with different AS, ingress filtering is a must

a. Deny prefixes belonging to your own AS

set policy-options route-filter-list <filter name> <prefix> exact <option>
set policy-options policy-statement <policy name>  term <term name> from route-filter-list <filter name>
set policy-options policy-statement <policy name>  term <term name> then reject

Example:
your own prefixes:
200.200.200.0/24
111.111.0.0/16

set policy-options route-filter-list OWN-PREFIXES 200.200.200.0/24 upto /32
set policy-options route-filter-list OWN-PREFIXES 111.111.0.0/16upto /32
set policy-options policy-statement INGRESS-FILTER term 1 from route-filter-list OWN-PREFIXES
set policy-options policy-statement INGRESS-FILTER term 1 then reject

b. Allow prefixes by filtering via AS or community
Note: It is best to have a default reject on the last statement
AS:

set policy-options as-path <aspath name> <as path>
set policy-options policy-statement <policy name> term <term name> from as-path <aspath name>
set policy-options policy-statement <policy name> term <term name> then accept
set policy-options policy-statement <policy name> term <term name> then reject
set protocols bgp group <bgp grup name> import <policy name>

Example:

set policy-options as-path PEER1 12345
set policy-options policy-statement  PEER1-IN-v4 term PEER1 from as-path PEER1
set policy-options policy-statement  PEER1-IN-v4 term PEER1 then accept
set policy-options policy-statement PEER1-IN-v4 term REJECT then reject
set protocols bgp group PEER1-BGP-GROUP import PEER1-IN-v4

BGP Community:

set policy-options community <community name> members <value>
set policy-options policy-statement <policy name> term <term name> from community <community name>
set policy-options policy-statement <policy name> term <term name> then accept

Example:
set policy-options community PEERCOMM members 65555:888
set policy-options policy-statement  PEER1-IN-v4 term PEER1 from community PEERCOMM
set policy-options policy-statement  PEER1-IN-v4 term PEER1 then accept
set policy-options policy-statement PEER1-IN-v4 term REJECT then reject
set protocols bgp group PEER1-BGP-GROUP import PEER1-IN-v4

4. Configure BGP adjacency changes logging

set protocols bgp group <BGP group name> log-updown

5. Configure RPKI for Validation of Origin on eBGP Peers
RPKI or Resource Public Key Infrastructure is use to allow public AS to sign their IPv4 and IPv6 prefixes that they originate to create a Route Origination Authorizations or ROA certificate through their RIR or Regional Internet Registry like APNIC, ARIN etc. This means that those prefixes being received by the BGP router from their eBGP peers need to go through first to an RPKI Validator Server where it maintains all the ROAs by RIRs, and from their to decide what to do with the prefixes.

valid – Prefix, AS and Prefix length all matching a valid ROA
invalid – ROA exists for that specific prefix but either Prefix length or Origin AS is not matching
unknown – no matching ROA exists ( can be the IPv4/IPv6 owner has not created ROA yet with RIR)

a.  Configure the RPKI validator

set routing-options validation group <group name> session <RPKI Server address> port <port number> local-address <address>

Example:
RPKI Validator server IP: 192.168.100.88
Router’s Local IP: 192.168.20.55

set routing-options validation group  RPKI session 192.168.100.88 port 8322 local-address 192.168.20.55

b. Create the policy

set policy-options policy-statement <policy name > term <term name > from protocol bgp validation-database valid
set policy-options policy-statement <policy name > term <term name > then accept
set policy-options policy-statement <policy name > term <term name > from protocol bgp validation-database invalid
set policy-options policy-statement <policy name > term <term name >then reject

Example:
set policy-options policy-statement RPKI term VALID from protocol bgp validation-database valid
set policy-options policy-statement RPKI term VALID then accept
set policy-options policy-statement RPKI term INVALID from protocol bgp validation-database invalid
set policy-options policy-statement RPKI term VALID then reject

c. Import the policy

set protocols bgp group <group name>  import <policy name>
or
set protocols bgp neighbor <peer IP> import <policy name>

Example:
set protocols bgp group PEER1-BGP-GROUP import RPKI
or
set protocols bgp neighbor 200.200.0.2 import RPKI

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *