In BGP Blackhole mode FastNetMon can announce your own host (or subnet for this host) with specified BGP community. You can use this approach for traffic diversion to cloud scrubbing center or to completely block all (incoming and outgoing) traffic to this host in your network.
In this mode, FastNetMon tracks number of counters for each host in your network (number of bytes, packets and flows per second for different types of traffic). And if some of your hosts crosses this baseline value then FastNetMon will create BGP announce automatically.
To start with BGP Blackhole automation you need to set thresholds using this guide.
Then enable ban actions globally:
sudo fcli set main enable_ban enable
If you’re configuring IPv6 blackhole then you need to set this command:
sudo fcli set main enable_ban_ipv6 enable sudo fcli commit
Then you could check blocks for hosts which exceeds this threshold:
sudo fcli show blackhole
For testing purposes you may manually blackhole some host:
sudo fcli set blackhole 1.2.3.4
To unblock host you need to use UUID from previous command and issue following command:
sudo fcli delete blackhole d9b1885f-6d9b-4167-9e3e-0a3198bacee9
To run some automatic block / mitigation actions we offer huge variety of options:
- BGP Blackhole for IPv4
- BGP Blackhole for IPv6
- Email alerts
- Bash Script call
- JSON script call
- Mikrotik route integration
- Cloud based DDoS scrubbing center traffic diversion via API
- Cloud based DDoS scrubbing center traffic diversion via BGP
- VyOS route management
- Web callback
- InfluxDB / Grafana alert
We recommend enabling email alerts before enabling BGP mode to confirm correctness of thresholds configuration.
Automatic unblock
When attack finished FastNetMon can automatically unblock blocked IP address. This capability can be enabled this way:
sudo fcli set main unban_enabled true sudo fcli commit
By default FastNetMon unblocks host after 12 minutes and this time can be changed this way in seconds:
sudo fcli set main ban_time 600 sudo fcli commit
In addition to unconditional unblock by timeout FastNetMon has capability to check if attack finished before doing unblocking for it. This logic is enabled by default on all new installations. You can manually enable it this way:
sudo fcli set main unban_only_if_attack_finished true sudo fcli commit
Attack confirmation logic
For simplicity reasons beginning of this guide omits explanation of attack confirmation logic. In reality after some host crosses threshold FastNetMon does not block it immediately. Instead, it creates traffic capture request. We do it to capture context of attack for email alerts and script callback.
After capture request creation, FastNetMon will collect all traffic to / from specified host. By default, FastNetMon captures 500 (for mirror/SPAN mode) or 20 (for sFlow v5, Netflow, IPFIX) packets.
If you want you can adjust number of packets this way:
sudo fcli set main ban_details_records_count 5 sudo fcli commit
If it cannot capture this amount of packets for 60 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. In this case, FastNetMon declares attack as false positive and does not apply any actions.
If you use sampled Netflow/IPFIX/sFlow v5 you can reduce this value to 2-3 packets or even set it to single packet. In this case, FastNetMon will block host almost immediately after receiving initial alert but you will lost ability to understand attack’s traffic.
If you enable traffic buffer capability attack confirmation step will be skipped and attack will be triggered immediately. In this case FastNetMon will retrieve attack’s sample from in-memory traffic buffer which stores packets and flows for last X seconds. This sample will be used for script callbacks and email alerts.
In addition to option to announce /32 or /128 hosts which are under attack FastNetMon can announce whole networks where attacked host is located. It may be useful for DDoS scrubbing centre diversion or internal network policy changes (i.e. to move prefix under attack to in-house scrubbing or move it to another ISP).
In addition to BGP based integration we have native integration with multiple DDoS scrubbing centers via API.