41. Appendix 4 – Network Integration Guideline for Wanguard Filter

This appendix describes how to configure the network for traffic scrubbing by Wanguard Filter, starting from a couple of common deployment scenarios of the filtering server.

Wanguard Filter, hereby referred simply as Filter, can be deployed following two scenarios:

● In-line filtering. This deployment scenario can have two possible implementations, depending on the role of the filtering server on the forwarding path:

◦ Routing mode

◦ Bridging mode

● Out-of-line filtering. Due to the complexity of this solution, this appendix will further focus on this setup.

When the Out-of-line filtering solution is deployed, then the following two major operations have to be considered, operations that have to be performed from network point of view:

1. Traffic diversion – how the traffic for a certain destination (IP-Victim) is diverted from network to the filtering server

2. Traffic forwarding or Re-injection – how the cleaned traffic is put back on network to be routed / forwarded towards its destination (IP-Victim)

The information provided here regarding router configurations is for informational purposes only. Please refer to the appropriate router user guides for more detailed and up-to-date information.

41.1. Understanding the Traffic Diversion Method

The method relies on a basic routing principle implemented on all routers according to which a router selects the path with the longest prefix match present on routing table (also known as the “most specific” entry from routing table).

BGP has been chosen as routing protocol to inject/advertise the most specific redirect-prefix (e.g. a /32 for IPv4, a /128 for IPv6) towards Internet Border Router (IBR). The IBR is the router which assures routing between ISP and the internal network (customer network).

To simplify, we will consider an IPv4-Victim. In this case, Filter sends a BGP routing update towards IBR for IPv4-Victim/32 with a next-hop to itself forcing the IBR to choose the path to IPv4-Victim via Filter. The main condition for this to work is to have the redirect announcement to be the best from BGP election process and from Routing-Table Manager (RTM).

If on the routing-table there is already a /32 present, then additional configuration have to be made in order to assure that redirect-announcement will be inserted into the routing table and used to deciding the forwarding path.

Please refer to the following logical diagram that describes the high-level process of detection-diversion-cleaning and re-injection. The following terminology is used:

● Divert-from router – Router from which traffic, initially intended for the victim, is diverted towards Filter (e.g. IBR) – this router has to receive a redirect-prefix via BGP

● Inject-to router – Router where Filter will forward the cleaned traffic towards the attacked destinations (IP-Victims)

● Next-hop router – Router that is usually the next-hop to the destinations according to the routing-table on the Divert-from router before traffic diversion is activated.

Figure-1. Logical Diagram for an Enterprise Network – how traffic diversion works

From a configuration point of view the following steps have to be performed:

1. Configure traffic-diversion using BGP as the signaling method

2. Configure an appropriate clean traffic-injection method to send clean traffic back on the network to be forwarded towards the victim

41.1.1. BGP Configuration Guideline

This section provides a general guideline for BGP configuration on the Filter server and on a Divert-from router. The guidelines provided in this section apply to the BGP configuration on any router from which Filter diverts traffic.

To simplify, the following examples are provided using eBGP (external BGPv4). This solution is not limited to eBGP, iBGP may be considered as well, depending on existing network setup, case in which “set nexthop-self” feature might be required.

The steps below have to be followed:

1. Configure BGPd on Filter with an easily recognizable autonomous system number. This can be a private ASN for eBGP (e.g. ASN16bit 64512-65534) or your own public ASN in case you are using iBGP. The BGPd sends routing information only when it diverts traffic. This route appears in the router’s routing tables. Using a recognizable value allows you to easily identify the redirect-prefixes in the router’s routing tables.

2. Configure additional precaution measures to prevent any undesirable routing behavior:

a. Configure Filter to not accept any prefix/advertisements from Divert-from router

b. Configure Divert-from router to not advertise any prefix towards Filter

c. Configure Divert-from router to accept only redirect-prefixes from Filter (e.g. /32 prefixes)

d. Configure Filter to advertise the redirect-prefixes with well-known community no-advertise – this would prevent redirect-prefixes/announcements to be propagated to other peers through BGP. The no-export community might be used in case redirect-prefix has to be advertised to additional routers, or Route-Reflectors are used in-between Filter and Divert-from router. Both communities will prevent BGP-redirect-announcements to be advertised towards upstream providers. However, a good practice is to mark this announcement with a dedicated BGP community to distinguish between redirect and black hole announcements.

3. To ease the troubleshooting process, you may consider the soft-reconfiguration inbound command on Divert-from-router during the setup procedures.

41.1.2. Quagga / FRR BGPd Configuration

Wanguard is capable of sending and withdrawing BGP announcements via the BGPd daemon provided by the Quagga routing software suite (https://www.quagga.net). Newer Linux distributions like CentOS 8 don’t support Quagga but support FRR (https://frrouting.org). FRR is a fork of Quagga, so the configuration differences are minimal.

You will have to do a few distribution-specific configuration steps:

Debian 9+, Ubuntu 18+CentOS 8CentOS 7Older Debian or Ubuntu

Install Quagga, then remove the loopback binding (” -A 127.0.0.1”) from the /lib/systemd/system/bgpd.service file.

[root@localhost ~]# apt install quagga
[root@localhost ~]# nano /lib/systemd/system/bgpd.service
[root@localhost ~]# systemctl daemon-reload

To be able to start the bgpd service, create a basic configuration file. Setting a password for the bgpd daemon is usually enough to get it started. Replace “bgppass” with your own password. On these systems, bgpd starts only when zebra is running.

[root@localhost ~]# echo 'password bgppass' > /etc/quagga/bgpd.conf
[root@localhost ~]# echo 'enable password bgppass' >> /etc/quagga/bgpd.conf
[root@localhost ~]# chown quagga /etc/quagga/bgpd.conf
[root@localhost ~]# touch /etc/quagga/zebra.conf
[root@localhost ~]# systemctl start zebra
[root@localhost ~]# systemctl enable zebra
[root@localhost ~]# systemctl start bgpd
[root@localhost ~]# systemctl enable bgpd

Note

Wanguard needs to connect to bgpd on the public IP of the server, even if the connection will be made from the server itself via the WANsupervisor service. This is why the string “-A 127.0.0.1”, which is used for binding bgpd to the loopback interface, must be deleted.

Connect to the bgp daemon with telnet on localhost port 2605 (default bgpd port) and enter the previously-defined password (“bgppass”) when requested.

[root@localhost ~]# telnet 127.0.0.1 2605
localhost> enable
localhost# config terminal
localhost(config)#

Configure routing on BGPd using the commands shown in the following example. Please note that you can use the prefix-list, route-map, or distribute-list method for filtering outgoing routing information. To have a uniform approach, the following example uses route-maps. Optionally, BGP authentication can be configured to increase security and avoid any illegal BGP announcement which may lead to a security breach.

localhost(config)# router bgp <Wanguard-Filter-AS-number>
localhost(config-router)# bgp router-id <Wanguard-Filter-IP-address>
localhost(config-router)# neighbor <Router-IP-address> remote-as <Router-AS-number>
localhost(config-router)# neighbor <Router-IP-address> description <description>
localhost(config-router)# neighbor <Router-IP-address> password <BGP MD5 password>
localhost(config-router)# neighbor <Router-IP-address> route-map Wanguard-Filter-in in
localhost(config-router)# neighbor <Router-IP-address> route-map Wanguard-Filter-out out
localhost(config-router)# exit
localhost(config)# route-map Wanguard-Filter-in deny 10
localhost(config-route-map)# exit
localhost(config)# route-map Wanguard-Filter-out permit 10
localhost(config-route-map)# set community no-advertise <Wanguard-Filter-community>
localhost(config-route-map)# exit
localhost(config)# write
localhost(config)# exit

To display the bgpd configuration, enter the show running-config command from the “enable” command level. In the following example, the router’s AS number is 1000, and the BGPd AS number is 65000.

The following partial sample output is displayed:

localhost# show running-config
... skipped ...
router bgp 65000
bgp router-id 192.168.1.100
neighbor 192.168.1.1 remote-as 1000
neighbor 192.168.1.1 description divert-from router
neighbor 192.168.1.1 soft-reconfiguration inbound
neighbor 192.168.1.1 route-map Wanguard-Filter-in in
neighbor 192.168.1.1 route-map Wanguard-Filter-out out
!
route-map Wanguard-Filter-in deny 10
!
route-map Wanguard-Filter-out permit 10
set community no-advertise
!
line vty
... skipped ...

Wanguard connects to bgpd using the BGP Connector component documented in the Configuration » Components » BGP Connector chapter. Make sure that the wanbgp package is installed on the bgpd server.

41.1.3. ExaBGP Configuration

Use ExaBGP 4.x instead of Quagga or FRR if you need to use Flowspec. Wanguard connects to ExaBGP using the BGP Connector component documented in the Configuration » Components » BGP Connector chapter. Make sure that the wanbgp package is installed on the exabgp server. ExaBGP 4.0 and ExaBGP 4.2 have different configuration steps:

ExaBGP 4.2ExaBGP 4.0

On distributions running python 3.8, such as Ubuntu 20, install exabgp from the master git branch. For other distributions, install ExaBGP 4.2 from pip, not from your distribution’s repository.

[root@localhost ~]# apt install python3-pip # on Debian/Ubuntu
[root@localhost ~]# yum install python3-pip # on CentOS/Red Hat
[root@localhost ~]# pip3 install exabgp

Create the named pipe:

[root@localhost ~]# exabgp --fi > /usr/local/etc/exabgp/exabgp.env
[root@localhost ~]# mkdir /run/exabgp
[root@localhost ~]# chown nobody /run/exabgp
[root@localhost ~]# mkfifo /run/exabgp/exabgp.{in,out}
[root@localhost ~]# chown nobody /run/exabgp/exabgp.{in,out}
[root@localhost ~]# chmod 600 /run/exabgp/exabgp.{in,out}

Assuming that the exabgp configuration file is /etc/exabgp.conf, start it in daemon mode with a command such as:

env exabgp.log.destination=syslog exabgp.daemon.daemonize=true exabgp /etc/exabgp.conf

Enter /run/exabgp/exabgp.in in the ExaBGP Pipe field from the ExaBGP Connector.

41.1.4. Cisco Router BGP Configuration

This section describes the router’s BGP configuration used when configuring traffic diversion. The syntax of the commands is taken from the BGP configuration of a Cisco router. The following configuration steps show the commands used to configure BGP on a 72xx Cisco router:

r7200(config)# ip bgp-community new-format
r7200(config)# ip community-list standard <Wanguard-Filter-community-name> permit no-advertise
r7200(config)# ip community-list standard <Wanguard-Filter-community-name> permit <Wanguard- Filter-community>
r7200(config)# route-map Wanguard-Filter-in permit 10
r7200(config-route-map)# match community <Wanguard-Filter-community-name> exact
r7200(config-route-map)# exit
r7200(config)# route-map Wanguard-Filter-out deny 10
r7200(config-route-map)# exit
r7200(config)# router bgp <Router-AS-number>
r7200(config-router)# bgp log-neighbor-changes
r7200(config-router)# neighbor <Wanguard-Filter-IP-address> remote-as <Wanguard-Filter-ASn>
r7200(config-router)# neighbor <Wanguard-Filter-IP-address> description <description>
r7200(config-router)# neighbor <Wanguard-Filter-IP-address> soft-reconfiguration-inbound
r7200(config-router)# neighbor <Wanguard-Filter-IP-address> route-map Wanguard-Filter-out out
r7200(config-router)# neighbor <Wanguard-Filter-IP-address> route-map Wanguard-Filter-in in
r7200(config-router)# exit

To display the router configuration, enter the show running-config command from the router global command level. In the following example, the router’s AS number is 1000 and the BGPd AS number is 64000. The following partial output is displayed:

r7200# show running-config
... skipped ...
router bgp 1000
bgp log-neighbor-changes
neighbor 192.168.1.100 remote-as 64000
neighbor 192.168.1.100 description Filter appliance
neighbor 192.168.1.100 soft-reconfiguration inbound
neighbor 192.168.1.100 route-map Wanguard-Filter-out out
neighbor 192.168.1.100 route-map Wanguard-Filter-in in
no synchronization
!
ip bgp community new-format
ip community-list expanded Wanguard-Filter permit no-advertise
ip community-list expanded Wanguard-Filter permit <Wanguard-Filter-community>
!
route-map Wanguard-Filter-in permit 10
      match community Wanguard-Filter exact match
!
route-map Wanguard-Filter-out deny 10
!
... skipped ...

41.1.5. Juniper BGP Configuration

To get ExaBGP to work with Juniper to divert traffic via Flowspec, the BGP neighbor needs to accept legacy-redirect-ip-action:

junos> show configuration protocols bgp group WANGUARD neighbor X.X.X.X family inet flow
prefix-limit {
 maximum 50;
}
no-validate NO-VALIDATE;
legacy-redirect-ip-action {
 receive;
}

41.2. Understanding the Traffic Forwarding Methods

This section provides some details about the traffic forwarding methods typically used with Wanguard. A traffic forwarding method must be used to re-inject cleaned traffic from the Filter server back to network in order to reach its destination.

Couple of options can be identified depending on the existing network setup and depending on which device has the role of Divert-from, Inject-to, and Next-hop router:

1. Layer 2 Forwarding Method

2. Layer 3 Forwarding Method

41.2.1. Layer 2 Forwarding Method

The following characteristics will describe this option:

● Filter system, Divert-from router, and Next-hop router are on the same network or VLAN sharing the same subnet

● Divert-from and Inject-to routers are two different devices

● Next-hop and Inject-to routers are the same device

Figure-2. Logical Diagram for Layer 2 Forwarding (* same steps as per Fig.1)

While the above solution assumes one Divert-from and one Inject-to router, couple of variations may be considered starting from this option:

a) Multiple Divert-from routers

b) Multiple Inject-to routers

c) Combination of above and/or multiple VLANs in between Divert-from and Inject-to routers

Considering the last scenario, the Filter system has to be connected to each VLAN and to have static routes for each destination via the Inject-to/Next-hop routers.

Warning

Any special L2 configuration on Filter interface (e.g. bonding, VLAN-tagging, etc) will impact the scrubbing/forwarding performance of Filter. Hardware optimizations from NICs are also bypassed.*

When the VLAN/LAN cannot be extended to also include the Filter system on it, then a dedicated point-to-point connection might be considered between (Filter and Divert-from) or (Filter and Inject-to/Next-hop)

Figure-3. Logical Diagram Layer 2 Forwarding – dedicated cross-connects (* same steps as per Fig.1)

41.2.2. Layer 3 Forwarding Method

The following characteristics will describe this option:

1. Divert-from and Inject-to routers are the same device – referred in this case as “the router”

2. Depending on Next-hop router role we may have following sub-options:

a) Next-hop router is on dedicated device, but is not directly connected to Filter

b) Next-hop router is on the same device as Diver-from/Inject-to routers

In scenario 2a, a routing loop issue may occur between Divert-from/Inject-to router and Filter:

• Filter sends a BGP redirect announcement to Divert-from router (e.g. a /32 prefix route)

• Divert-from router will send all traffic for that Victim-IP to Filter

• Filter cleans the traffic and returns the cleaned traffic to the same router – Inject-to/Divert-from

• The Inject-to router has the redirect route /32 in its routing table and will send back the clean-traffic towards the Filter system resulting a routing loop

There are a couple of solutions to overcome this issue (these are suggestions and the best solution shall not be limited on these):

1. Using GRE (Generic Routing Encapsulation) or any L3-tunneling between Filter and Next-hop router – in this case, routing loop is avoided by pushing clean traffic over the GRE-tunnel to Next-hop router through Divert-from/Inject-to router, bypassing in this way the /32 diversion-route from Divert-from/Inject-to:

Figure-4. Logical Diagram Layer 3 Forwarding using GRE (* same steps as per Fig.1)

2. Using PBR (Policy Base Routing) to override the normal routing decision from Divert-from/Inject-to router:

Figure-5. Logical Diagram Layer 3 Forwarding using PBR (* same steps as per Fig.1)

Warning

PBR may impact router performance – depending on platform type, some optimizations may exist. However, by default PBR relays on packet-by-packet processing (process-switching) which have a significant impact on router’s CPU.

In case multiple Next-hop routers exist, then the following have to be considered too:

• multiple GRE tunnels have to be deployed and static routes at Filter level have to be considered, or

• multiple entries on PBR matching each zone, depending on which option is chosen

When using GRE, you must run on Filter the standard Linux tool ip in order to create and route GRE / IP over IP tunnels that will be used to inject the cleaned traffic back into the network. You must then configure Filter (see Packet Filter Configuration) with the Outbound Interface set to the virtual network interface created by the tunnel.

Please refer to the below router configuration samples for both GRE and PBR options:

1. The GRE method (using Cisco CLI) – configuration from Next-hop router:

r7200(config)# interface Tunnel 1
r7200(config-if)# ip address <X.X.X.X> 255.255.255.252
r7200(config-if)# ip mtu 1500
r7200(config-if)# ip tcp adjust-mss 1456
r7200(config-if)# tunnel source <Y.Y.Y.Y> → where Y.Y.Y.Y is the IP from Next-hop router
r7200(config-if)# tunnel destination <Z.Z.Z.Z> → where Z.Z.Z.Z is the IP from Filter

Notes:

• source IP and destination IP have to be reachable

• default tunneling encapsulation is GRE

• routing of tunnel-destination must be assured (e.g. using static routes)

• Filter will have X.X.X.X-1 IP on its Tunnel interface

• If transport between Filter and Next-hop router supports jumbo frames, then adjust MTUs accordingly in order to avoid additional packet fragmentation, and implicitly performance degradation

2. The PBR method (using Cisco CLI):

r7200(config)#ip access-list standard Wanguard-Filter-IPScope
r7200(config-std-acl)#permit A.A.A.A/BB → multiple entries may exists
r7200(config-std-acl)#exit

r7200(config)#route-map Wanguard-Filter-PBR permit 10
r7200(config-route-map)# match ip address Wanguard-Filter-IPScope
r7200(config-route-map)# set ip next-hop <C.C.C.C> → where C.C.C.C is the IP of Next-hop
router which is direct connected to Divert-from router
r7200(config-route-map)#exit
r7200(config)#interface GigabitEthernet 0/0
r7200(config-if)#ip policy route-map Wanguard-Filter-PBR
r7200(config-if)#exit
r7200(config)#

On scenario 2b when only one device has all three roles: Divert-from, Inject-to, and Next-hop – neither of above options can be considered. PBR might be considered in case a “set interface” configuration may take traffic and put it on the right Layer 2 path to its destination; since this is dependent on the type of platform used for routing, this would have limited applicability and will not be treated further more.

For scenario 2b a much more elaborated solution has to be considered. The main idea is to separate virtually the routing domain used by Divert-from and Inject-to/Next-hop router – falling in this way somehow on Layer 2 Forwarding Method:

• use VRF-Lite by defining two VRF’s:

◦ one for “outside” where Divert-from router is (and also its BGP peering with upstream providers and Filter)

◦ and another one for “inside” where Inject-to/Next-hop router is

• Filter must have two Layer 3 interfaces/sub-interface:

◦ one in VRF-outside

◦ one in VRF-inside

• like on Layer 2 Forwarding Method, static routes have to be defined on Filter towards subnets destinations

• in order to assure normal routing between these two VRF’s, MPBGP have to be activated on “the router”; no MPBGP neighbor have to be defined

• on VRF’s definitions special policies for import/export Route-Targets(RT) have to be defined in the following manner:

◦ e.g. mark outside routes with RT 65000:100 and inside routes RT 65000:200

◦ on VRF-outside:

• import the routes having outside-RT (e.g. 65000:100) and also inside-RT (e.g. 65000:200)

• export routes with outside-RT – excepting the redirect/diversion routes

◦ on VRF-inside:

• import the routes having inside-RT and specific routes having outside-RT: the default -route and/ or all other outside routes excepting the routes for diversion learned from Filter

• export routes with inside-RT

In this way, the inside routing table will not know about the /32 redirect prefix and will forward/route traffic normally.

For a better understanding please refer to Figure-6 and configuration on “router” using Cisco-CLI as example:

Figure-6. Logical Diagram Layer 3 Forwarding using VRF-Lite (* same steps as per Fig.1)

r7200(config)#ip extcommunity-list standard VRF-Inside permit rt 65000:200
r7200(config)#route-map VRF-Inside-Import deny 10
r7200(config-route-map)#match community Wanguard-Filter → The Wanguard-Filter community has  been already configured above; this will deny redirect-routes
r7200(config-route-map)#exit
r7200(config)#route-map VRF-Inside-Import permit 20 → This will allow any other routes
r7200(config-route-map)#exit
r7200(config)#
r7200(config)#ip vrf Outside
r7200(config-vrf)#rd 65000:100
r7200(config-vrf)#route-target import 65000:100
r7200(config-vrf)#route-target import 65000:200
r7200(config-vrf)#route-target export 65000:100
r7200(config-vrf)#exit
r7200(config)#
r7200(config)#ip vrf Inside
r7200(config-vrf)#rd 65000:200
r7200(config-vrf)#route-target import 65000:100
r7200(config-vrf)#route-target import 65000:200
r7200(config-vrf)#import map VRF-Inside-Import
r7200(config-vrf)#route-target export 65000:200
r7200(config-vrf)#exit
r7200(config)#
r7200(config)# interface Loopback0 → This is needed to have a BGP router-id (any existing Loopback from global can be reused)
r7200(config-if)# ip address <Z.Z.Z.Z/32>
r7200(config-if)#no shut
r7200(config-if)#exit
r7200(config)#
r7200(config)# interface <to Upstream Provider>
r7200(config-if)#ip vrf forwarding Outside → Warning! This will remove IP address from interface/IP-address has to be reconfigured again
r7200(config-if)#exit
r7200(config)#
r7200(config)# interface <to Filter off-ramp interface>
r7200(config-if)#ip vrf forwarding Outside → Warning! This will remove IP address from interface/IP-address has to be reconfigured again
r7200(config-if)#exit
r7200(config)#
r7200(config)# interface <to Filter on-ramp interface>
r7200(config-if)#ip vrf forwarding Inside → Warning! This will remove IP address from interface/IP-address has to be reconfigured again
r7200(config-if)#exit
r7200(config)#
r7200(config)# interface <to Inject-to/Next-hop>
r7200(config-if)#ip vrf forwarding Inside → Warning! This will remove IP address from interface/IP-address has to be reconfigured again
r7200(config-if)#exit
r7200(config)#
r7200(config)#router bgp 65000 → You may use your ASN instead of 65000
r7200(config-router)# no synchronization
r7200(config-router)#bgp log-neighbor-changes
r7200(config-router)#no auto-summary
r7200(config-router)#address-family vpnv4
r7200(config-router-af)# no synchronization
r7200(config-router-af)#exit-address-family
r7200(config-router)# address-family ipv4 vrf Inside
r7200(config-router-af)# no synchronization
r7200(config-router-af)# redistribute connected
r7200(config-router-af)# redistribute <other IGP/static if needed>
r7200(config-router-af)#exit-address-family
r7200(config-router)# address-family ipv4 vrf Outside
r7200(config-router-af)# no synchronization
r7200(config-router-af)# redistribute connected
r7200(config-router-af)# redistribute <other IGP/static if needed>
r7200(config-router-af)#exit-address-family
r7200(config-router)#exit
r7200(config)#

If too many GRE tunnels or PBR entries have to be configured/maintained, consider the VRF-Lite solution.