In BGP Flow spec mode FastNetMon can detect and isolate patterns of malicious traffic and filter it out using high performance filters on your routers.
As first step of detection Flow Spec logic relies on thresholds. FastNetMon checks all hosts against specified in hostgroup configuration threshold every second. When any your host crosses threshold, FastNetMon creates “traffic capture request”.
To continue please configure thresholds using this guide.
After capture request creation, FastNetMon will collect all traffic to specified host. By default, FastNetMon captures 500 (for mirror/SPAN mode) or 20 (for sFlow v5, Netflow, IPFIX) packets.
By default FastNetMon captures all traffic to / from specific host and it may lead to blocks of legitimate traffic in some rare cases. You can switch it to new logic which process only traffic which actually triggered threshold (i.e. only UDP traffic when attack was triggered by UDP threshold) and it can be enabled this way:
sudo fcli set main threshold_specific_ban_details true sudo fcli commit
You can change number of collected packets that way but we normally do not recommend setting it to very low value as it may cause issues for pattern detection:
sudo fcli set main ban_details_records_count 5 sudo fcli commit
If it cannot capture this amount of packets for 120 second (can be configured using bucket_traffic_collection_timeout starting from 2.0.359) it removes “traffic capture request” as orphaned and removes it completely.
You can find such cases in log file /var/log/fastnetmon/fastnetmon.log:
[WARN] We've found orphaned bucket for IP: 10.251.23.1 [WARN] It has 3 parsed packets [WARN] And 3 raw packets [WARN] We will remove it
In this case, FastNetMon declares attack as false positive and does not apply any actions.
When FastNetMon successfully captures attack sample then tries hard to find best match using all possible configurations of BGP Flow spec rules, for example:
- almost all packets come from IP XX to port YY
- almost all packets use fragmentation flag and come from port ZZ
- almost all packets use protocol M and come from IP XX
After that, FastNetMon orders all rules by number of packets / bytes which match each rule. For example, it may get following intermediate results:
- port=53 protocol=udp 100 packets 10 packets
- port=53 source_ip=11.22.33.44 protocol=udp 5 packets
- port=53 source_ip=11.33.88.22 protocol=udp 5 packets
FastNetMon is interested in finding best possible (which covers as many packets as possible) and shortest rule (which has less parameters ).
In this example FastNetMon will select first rule because it shortest and has much more packets that other.
After finding best coverage rule for malicious traffic it announces it to BGP Flow Spec router and then it filters out this malicious traffic.
In same time FastNetMon excludes all traffic which matches this new Flow Spec rule from processing and starts monitoring if any threshold is crossed again. In this case all traffic of previously known attacks is filtered and it looks for new patterns in this case to address multi vector attacks. If that happens it captures sample of traffic and applies same logic again and again until it filters out attack.
Normally, FastNetMon can create around 5-10 rules for each host to filter out attack.
To learn more about our detection engine we recommend enabling debug logging and then checking /var/log/fastnetmon/fastnetmon.log:
sudo fcli set main logging_level debug sudo fcli commit
For next step, you need to have working BGP peering session. Please enable flow spec AFI on router’s side and then we could start.
Enable flow spec for your peering connection
sudo fcli set bgp connection_to_my_router ipv4_flowspec enable
Enable flow spec globally:
sudo fcli set main gobgp_flow_spec_announces enable
We could specify action type for FastNetMon’s announces (accept, discard, redirect, rate-limit):
sudo fcli set main gobgp_flow_spec_default_action discard
For rate-limit you could specify actual rate (usually “bytes per second” but please check with your network vendor):
sudo fcli set main gobgp_flow_spec_rate_limit_value 1000
For redirect (supported starting from 2.0.364) you can specify target ASN (16 bit) and target Community (32 bit):
sudo fcli set main gobgp_flow_spec_v4_redirect_target_as 65535 sudo fcli set main gobgp_flow_spec_v4_redirect_target_community 4294967295 sudo fcli commit
Apply changes:
sudo fcli commit
When FastNetMon detects new attack and creates BGP Flow Spec rule you will be able to see it here:
sudo fcli show flowspec
By default, FastNetMon enables Flow Spec mitigations for all hostgroups. Starting from 2.0.355 you can switch to logic which enables them on hostgroup basis:
sudo fcli set main flow_spec_per_hostgroup_management true
After that you can enable it only for specific hostgroup:
sudo fcli set hostgroup global enable_bgp_flow_spec true
For testing purposes we can prepare custom announce (please replace our example addresses here by your real addresses specified in networks list)
sudo fcli set flowspec '{ "source_prefix": "4.0.0.0/32", "destination_prefix": "127.0.0.0/32", "destination_ports": [ 80 ], "source_ports": [ 53, 5353 ], "packet_lengths": [ 777, 1122 ], "protocols": [ "tcp" ], "fragmentation_flags": [ "is-fragment", "dont-fragment" ], "tcp_flags": [ "syn" ], "action_type": "rate-limit", "action": { "rate": 1024 } }'
Then check that it appeared in list of blocked traffic rules:
sudo fcli show flowspec
And check BGP daemon output:
gobgp global rib -a ipv4-flow
Output should be like this:
Network Next Hop AS_PATH Age Attrs *> [destination:127.0.0.0/24][source:4.0.0.0/24][protocol: tcp][destination-port: =80][source-port: =53 =5353][tcp-flags: syn][packet-length: =777 =1122][fragment: is-fragment dont-fragment]fictitious 00:01:36 [{Origin: ?} {Extcomms: [discard]}]
We have multiple flags to exclude specific fields from flow spec rule generation and you can enable them if you prefer:
sudo fcli set main flow_spec_do_not_process_ip_fragmentation_flags_field false sudo fcli set main flow_spec_do_not_process_length_field false sudo fcli set main flow_spec_do_not_process_source_address_field false sudo fcli set main flow_spec_do_not_process_tcp_flags_field false
To configure BGP Flow spec on router side you can use our official guides for flowing vendors:
By default FastNetMon executes full validation for all Flow Spec announces using following logic:
- Source prefix should be exactly /32
- Destination prefix should be exactly /32
- Source prefix should belong to networks_list
- Destination prefix should belong to networks_list
If you accept risks related with injection of wide unrestricted rules you could disable validation this way:
sudo fcli set main flow_spec_execute_validation disable sudo fcli commit
FastNetMon can do variety of actions when it creates new BGP Flow spec filtering rule:
IPv6 support for Flow Spec mode is not available but it has high priority on our roadmap.
If you run BGP Flow Spec mitigation in environment with constrained bandwidth you may be in position when BGP Blackhole may be needed to avoid network overload. In this case you can configure BGP Blackhole logic using this guide. BGP Flow Spec uses same thresholds as BGP Blackhole and that’s why these modes cannot be used in same time in fully automated mode but you can manually run bgp blackhole commend manually this way even if you run BGP Flow Spec mode:
sudo fcli set blackhole 1.2.3.4
After these actions FastNetMon will announce BGP Blackhole announce for affected host and will stop generating BGP Flow Spec rules. As an option to automate this logic you can use this script.
BGP Flow Spec is an RFC standard which works smoothly with majority of vendors on market but for some vendors you may need to use vendor specific flags.
On 6Wind VSR you may experience issues with BGP Flow Spec rules containing more then 1 port. FastNetMon itself does not use such rules and it will work with with following router.
Huawei routers may not accept BGP Flow Spec announces which have TCP Flags and IP fragmentation flags unless you specify following options in FastNetMon configuration:
sudo fcli set main flow_spec_fragmentation_options_use_match_bit true sudo fcli set main flow_spec_tcp_options_use_match_bit true sudo fcli commit
Some models of Arista and Extreme routers have no ability to accept BGP Flow Spec announces which include IP fragmentation flags. To stop FastNetMon’s attack mitigation engine from using these fields you can set following flags:
sudo fcli set main flow_spec_do_not_process_ip_fragmentation_flags_field true sudo fcli commit
In addition to standard actions such as accept, discard or rate-limit we have option to specify single or multiple next hop addresses as target. It based on following RFC draft and can be enabled following way:
sudo fcli set main gobgp_flow_spec_next_hop_ipv4 10.3.44.6 sudo fcli set main gobgp_flow_spec_next_hop_ipv4 10.3.44.7 sudo fcli commit
Optionally you can inject such next hops manually:
sudo fcli set flowspec '{ "source_prefix": "4.0.0.0/32", "destination_prefix": "127.0.0.0/32", "destination_ports": [ 80 ], "source_ports": [ 53, 5353 ], "packet_lengths": [ 777, 1122 ], "protocols": [ "tcp" ], "fragmentation_flags": [ "is-fragment", "dont-fragment" ], "tcp_flags": [ "syn" ], "action_type": "accept", "ipv4_nexthops": ["11.22.33.44"] }'
We’re aware that Juniper support this capability in their routers.