flexrules

flexrules are customer configurable, so called flexible rules. It's primary advantage is customization, allowing customers to dynamically configure DDoS-Protection in real-time. Most vendors do not allow modifications, aurologic strives for flexibility.

When applying flexrules, aurologic recommends to be careful. Improper usage of flexrules may cause service unavailability or instability. flexrules are a powerful tool to rule network traffic differently.

Time-To-Deploy (TTD)

flexrules are almost immediately deployed. Due to it's event based architecture, minimal delay between API calls and flexrule placement may occur of up to 0.5 second.

Sequenced processing

flexrules using sequence numbers. The first sequence number for a destination ip-prefix, which is wether a single ip-address or a subnet, is always one (1). Due to it's sequenced processing architecture, flexrules require to be applied as closed-chain of rules.

A closed chain is for example having flexrules with sequence number 1,2,3,4,5 while 1,2,4,5 are an open chain. Processing for the second example will stop after flexrule sequence number 2, while the first example will process until flexrule sequence number 5.

Performance objected architecture always require a closed chain. Open chains are not possible and will represent the interrupted processing as described above.

The maximum number of rules is due to eBPF limitations ten (10). ten additional rules are reserved for global flexrules, injected before destination prefix specific ones.

From/Then behavior

flexrules work by matching packets and applying actions (from-then principle). They can match (from) ip-header specific fields such as source ip-address (or a prefix-list), protocol header fields such as source/destination port or tcp-flags, up to 30-byte payload content starting at a customer defined off-set (default is 0) up to typical internet MTU boundaries, packet payload length and geo location/as-number specific meta-data.

Applicable actions are ones such as:

• Discard -> DROP the packet
• Accept+Ratelimit -> Accept the packet but starting ratelimiting (dropping) packets at a certain packet-rate
• Accept+Ratelimit by Source address -> Same as before, but matches the source address and applies a rule maximum limit
• Adapt application profile -> Changes the application profile for packets matching the 'From' specific fields

There's several other actions available, such as matching flowTrack seen egress traffic, marking and matching packets based on it's marks or adjusting flowShield internals such as ratelimits and session timeouts.