Detection and filtering#
Add prefixes#
The first step of the detection and filtering configuration is to define which IP prefixes you want to protect with LiveShield.
Go to the “Filtering” menu option.
Click “+” button in the “Filtering Rules” section to add new prefix. After that, a dialog will appear.
Settings explained:
Name: A friendly name for your prefix. Just for your reference. You can leave it blank, then LiveShield will generate one automatically.
Prefix: The IP prefix you want to protect. You can enter IPv4 or IPv6 prefix in CIDR notation (e.g., 192.0.2.0/24 or 2001:db8::/32).
Maximum timeout: The maximum duration (in seconds) for which an attack will be marked as detected for IP addresses in this prefix. 0 means end all rules immediately when the attack is over. We recommend setting it to around 5 minutes (300 seconds) to improve efficiency.
Blackholing profile: Select the blackholing profile to be used when an attack is detected on this prefix. For more information please refer to Blackholing section.
Dump packet count: Number of packets to capture in single pcap file when an attack is detected on this prefix. These packets can be used for further analysis. Set to 0 to disable packet capturing. We recommend 100 or 200 if you want to use packet capturing.
Traffic diversion (VRF): (Optional) If you want to redirect traffic to some other device or scrubbing center, you can put here VRF route target in format XXX.XXX.XXX.XXX:YY. LiveShield will generate FlowSpec redirect route when any attack is detected on this prefix.
BGP Router restriction: (Optional) If you have multiple BGP routers configured in LiveShield, you can restrict rule generated for this prefix to be sent only to specific BGP routers. Just select one or more routers from the list. If none is selected, rules will be sent to all configured BGP routers matching the prefix IP version and supporting FlowSpec.
Event pipe: (Optional) You can select specific event pipe for this prefix. If none is selected, default event pipe will be used. For more information about event pipes, please refer to Event Pipelines section.
Override ALL Emails: (Optional) If your Event pipe contains email notification actions, you can override all email recipients for this prefix by entering new email address here. Leave it blank to use email addresses defined in the event pipe.
Override ALL Webhook URLs: (Optional) If your Event pipe contains webhook notification actions, you can override all webhook URLs for this prefix by entering new URL here. Leave it blank to use webhook URLs defined in the event pipe.
Let’s assume we own prefix 192.168.100.0/24 and we want to protect it with LiveShield. We’ll not use blackholing right now, just FlowSpec rules.
This should give you following result:
You can now proceed to add more prefixes or start configuring thresholds for specific protocols.
Thresholds#
In order to start configuring thresholds, click the edit button on the right side of the prefix entry. Scroll down to the “Thresholds” section.
Click the “Add Threshold” button to add a new threshold. A new record will appear. Here you will be able to define the maximum allowed packets per second (pps) and/or bits per second (bps) for a specific protocol. This applies per IP address in the specified prefix. So if you set threshold for IP protocol to 10k (pps), each IP address in that subnet can send up to 10k packets per second before an attack is detected. If any IP address exceeds that limit, an attack will be detected and mitigation rules will be generated for that IP address only.
Settings explained:
Protocol: Select protocol for which you want to define threshold.
Timeout: How long (in seconds) any rule generated by this threshold should stay active after the attack is over. If this exceeds the “Maximum timeout” defined for the prefix, the global prefix timeout will be used instead. A value of 0 means rules will be removed immediately after the attack is over. We recommend setting it to at least 30 seconds.
pps Threshold: Packets per second threshold. If the traffic for the selected protocol exceeds this value, an attack will be detected. Set to 0 to disable pps based detection.
bps Threshold: Bits per second threshold. If the traffic for the selected protocol exceeds this value, an attack will be detected. Set to 0 to disable bps based detection.
Prefiltering: After an attack is detected, LiveShield can immediately apply typical rules for the selected protocol to mitigate the attack while it is still gathering more data to create more precise rules. This increases mitigation speed and it’s recommended for typical DDoS protocols like NTP, DNS, CHARGEN, SSDP, SNMP, IPFRAG, etc. However if you enable it for the IP protocol, it will cut IP traffic completely. So be aware before enabling it for useful protocols like IP, UDP, TCP etc. In that case you may want to configure Advanced Filtering instead.
Packet dump: If enabled, LiveShield will capture packets matching this threshold when an attack is detected. The number of packets captured is defined by the “Dump packet count” setting in the prefix configuration. Captured packets can be used for further analysis.
Advanced filtering: Here you can select an advanced filtering profile. It is recommended for useful, more general protocols like TCP and UDP. For more details please refer to Advanced Filtering section.
Hint
You can use “k”, “M” and “G” suffixes when entering pps and bps values. For example, entering “10k” will be interpreted as 10,000.
Supported protocols:
IP: All IP traffic
IPFRAG: Fragmented IP packets
TCP: All TCP traffic
TCP-SYN: TCP SYN packets
UDP: All UDP traffic
DNS: DNS traffic (non fragmented)
NTP: NTP traffic (non fragmented)
SSDP: SSDP traffic (non fragmented)
CHARGEN: CHARGEN traffic (non fragmented)
SNMP: SNMP traffic (non fragmented)
INVALID: Invalid packets. Just for detection purposes, no rules will be generated for this protocol. Invalid packets should be dropped by default at your network edge.
HTTP: HTTP traffic incoming on port 80. Unencrypted traffic only.
RDP: RDP traffic (non fragmented)
ICMP: ICMP traffic, all types. Applies also to ICMPv6.
CLDAP: CLDAP traffic (non fragmented)
UDP_SMALL: Small UDP packets (<= 1 byte of UDP payload). Highly recommended to enable prefiltering for this protocol.
MEMCACHED: Memcached traffic (non fragmented)
WSD: WSD traffic (non fragmented)
IPSEC_UDP: IPsec UDP traffic (non fragmented). Port 500 and 4500 NAT-T.
SIP: SIP traffic (non fragmented)
VXWORKS: VxWorks traffic (non fragmented). Used in reflection attacks.
DVR_DHCPDISCOVER: DVR DHCPDISCOVER traffic (non fragmented). Used in reflection attacks.
Hint
We recommend enabling prefiltering for typical often abused protocols: ICMP, NTP, DNS, CHARGEN, SSDP, SNMP, RDP, CLDAP, UDP_SMALL, MEMCACHED, WSD, VXWORKS and DVR_DHCPDISCOVER to improve mitigation speed.
If you use one of these protocols for legitimate high-volume traffic, please add another more specific prefix entry with different thresholds and/or prefiltering disabled for that protocol. In that case you might still want to use Advanced Filtering to protect against attacks while allowing legitimate traffic.
For protocols like TCP and UDP we recommend using Advanced Filtering instead of prefiltering. This is to avoid cutting all TCP or UDP traffic completely during an attack.
In general, thresholds and protocols should be selected based on services and traffic running on particular IPs in your network. You can create more specific prefix entries with different thresholds. For example, if you run public HTTP server on IP 192.168.100.10, you probably don’t want to enable prefiltering for HTTP protocol and probably you want higher thresholds. You can then create new prefix 192.168.100.10/32 and configure it differently than 192.168.100.0/24.
Hint
Most specific prefix always takes precedence in filtering rules. Just like in normal routing.
Example of thresholds configuration for prefix:
As you see, we have defined multiple thresholds for different protocols.
We configured IP protocol with 10Gbps thresholds and enabled packet dump, just to detect abnormal traffic spikes.
Then we set IPFRAG to 10kpps, because in properly configured network, fragmentation shouldn’t occur.
For TCP we set 5Gbps, 500kpps and enabled advanced filtering rather than prefiltering, because we don’t want to cut all TCP traffic during an attack. We prefer more precise filtering based on pattern learning.
For TCP-SYN we set 5kpps because we don’t host any service there. This IP range is for residential customers. So in this case we can easily set low value and enable prefiltering to cut TCP-SYN completely.
For UDP we set 500kpps and 5Gbps with advanced filtering again, to avoid cutting all UDP traffic.
Because we don’t host any NTP, DNS we set just 5kpps with prefiltering enabled to cut that traffic immediately when an attack is detected. We did same for other well-known abused protocols.
Because ICMP is not that important for us, we set low threshold of 2kpps with prefiltering enabled, so that during an ICMP flood, ICMP traffic will be filtered.
Because we don’t officially host any HTTP servers in this prefix, we set a threshold of 100kpps, 1Gbps with prefiltering enabled. This doesn’t count HTTPS traffic and client originated web traffic.
For RDP we set limit a little bit higher to 20kpps, because some of our customers use RDP heavily.
UDP_SMALL is set to 50kpps with prefiltering enabled, because 0-1 byte UDP packets are rarely used in legitimate traffic and such small packets are often abused in dense DDoS attacks. Quick spike of thousands of small UDP packets may cause network devices to overload due to high packet rate, even if total bandwidth is low.
For SIP protocol we set 50kpps because some customers might use VoIP. We enabled prefiltering to cut SIP traffic once exceeded but you can also use advanced filtering if you want more slower but precise mitigation.
For all protocols we enabled packet dump, so that when an attack is detected, we can later analyze captured packets to improve our defenses.
Important
Please keep in mind that these values are just examples. You should adjust thresholds according to your network traffic profile and services you run.
If you are configuring it for the first time, we recommend disabling all prefiltering and advanced filtering at first, just to monitor your traffic and see if any false-positive attacks are detected. You can then adjust thresholds and gradually enable prefiltering and advanced filtering. Another option is to disable FlowSpec rule import on your BGP routers at the beginning.