flowShield is our self-developed, highly flexible and performant Anti-DDoS solution to filter attacks on network (and partly application) level. DDoS-Attacks are filtered automatically. Most customers dont even notice a ongoing mitigation.

In order to mitigate attacks on HTTP, we provide a inline reverse-proxy called flowProxy, which acts as transparent validation proxy, forcing the client to interact. flowProxy needs to be activated manually by the customer, either using our customer area or api.

flowShield Features

Below, you’ll get an overview, how we mainly mitigate DDoS-Attacks on network level.

Technical overview

flowShield DDoS-Filters are based on x86 comodity hardware using powerful AMD EPYC / Threadripper CPUs with a extensive amount of powerful cpu cores to process our packet filtering logic. Network connectivity is done using Mellanox ConnectX 100Gbit (SmartNIC) network cards for ultimate performance including FPGA based hardware acceleration. Each filter can handle up to 400Gbit of linerate ingress traffic. Incoming ethernet packets are processed directly from the NIC ringbuffer using (eBPF based) XDP, which provides us with really high packet I/O while bypassing slower parts of the Linux Network Stack.

The controlplane of our DDoS-Protection is written in Go, which loads the eBPF Bytecode into the Kernel Space of the individual NIC. Beside of that, flowshield-controlplane offers rich metrics using a inbuilt Prometheus Exporter, Apache Kafka Connectivity to handle realtime flexrule deployment and logging. The userspace application heavily relies on (lockless) BPF Map based communication with the flowshield-dataplane loaded into the Kernel.

TTD (Time-To-Detect)

DDoS Attacks are usually detected within 2-10 seconds depending on the size of the attack. This applies also for Carpet Bombing Attacks, which might target whole subnets instead of single hosts.


Flowrules are rules, which get deployed on our flowanalyzer infrastructure, which controls our DDoS-Protection. Flowrules can be utilized to trigger certain types of DDoS-Mitigation stages at specific amounts of traffic. Flowrules can match the following:

  • IP-Protocol (e.g. 6 -> TCP)

  • Packetsize (0-2000 bytes, range)

  • Source-Ports (0-65535, range)

  • Dest-Ports (0-65535, range)

  • Traffic Rate (either pps/mbits)

While the following actions can be taken:

  • Log Event

  • Activate Layer4 + Log

  • Activate Layer7 + Log

In the future, we might also provide the ability to announce flowspec routes or blackhole ip-addresses.


Flexrules are intended to allow us configuring the ddos-filters dynamically. Flexrules act similar to well known Router ACLs. Flexrules can match the following conditions:

  • Source-IP (Start-End Range)

  • Destination IP-Prefix (e.g.

  • IP-Protocol (e.g. 6 -> TCP, 17 -> UDP)

  • Source-Port (Start-End Range)

  • Destination-Port (Start-End Range)

  • Packet-Length (Start-End Range)

  • Packet Payload (string, 30 bytes max)

  • Common TCP Flags

The following (numbered) actions are possible:

  • 0: Discard without any further action

  • 2: Accept, if ratelimit for flexrule reached, than discard

  • 3: Accept, if ratelimit for Source-IP reached, than discard

  • 4: Filter normal until ratelimit reached, than discard

  • 10: Handle with UDP GQC Challenge and apply custom settings such as ratelimits

The action numbers are also reflected by our APIv3.


Echo-Reply packets are ratelimited to 1500 packets per destination ip-address. Once the ratelimit is reached, echo-reply packets are discarded. Echo-Request packets are ratelimited to 1500 packets per destination ip-address. Once the ratelimit is reached, the filter starts answering echo-request packets with echo-reply, packets will be no longer forwarded to the affected ip-address.



Anomalies such as packets with invalid tcp flag combinations or same source as destination port are discarded.


Ratelimits might be applied depending on the amount of packets a single client generates.


Every tcp syn packet is authenticated against a so called Synproxy as well as stateful filters. The Synproxy implementation might cause the very first connection attempt to be reset. Usually, this will cause the client to retry the connection, afterwards the tcp handshake is finished.


UDP Anomaly

Anomalies are well known source-ports used for udp reflection attacks, udp traffic on well known tcp ports such as 22, 25, 80, 443. Beside of that, anomalies are invalid checksums as well as same source as destination port.

UDP Challenge

The following ports are filtered using challenge response authentication:

  • Port 53: All DNS traffic is replied with DNS Truncate, forcing to client to reconnect using TCP

  • Port 2300-2400: Allows only traffic for Arma3/DayZ servers, some packets are cached using Game-Query-Cache

  • Port 9000-9999: Allows only traffic for Teamspeak3 servers, some packets are cached using Game-Query-Cache

  • Port 27000-28000: Allows only traffic for Source Engine Gameservers, some packets are cached using Game-Query-Cache

  • Port 30000-32000: Allows only traffic for FiveM Gameservers, getinfo/getstatus Queries are cached using Game-Query-Cache

UDP Game-Query-Cache

Game-Query-Cache (GQC) is our solution against complex UDP Floods targeting Game- and Voiceservers (such as Teamspeak). The idea behind of the Game-Query-Cache is, to offload as much traffic as possible on the DDoS-Filters (basically the edge), in order to always reply on specific sets of traffic. Game-Query-Cache has been implemented for several portranges and helps to keep Gameservers online, even under very complex attacks.

In order to operate correctly, the customer is supposed to not apply any ratelimits on the protected server. Otherwise, GQC will not work correctly, which will render the protected service offline. All GQC activity is logged and can be reviewed by our customer support staff.

UDP Applications

The following port-ranges has been implemented specifically to operate the following gameservers:

  • 2300-2400: DayZ and Arma 3, as well as Arma 3 Query

  • 5761-5794: Atlas

  • 7000-8999: Generic Games

  • 9000-9999: Teamspeak3

  • 12800-13100: Hurtworld

  • 19132: Minecraft Pocket Edition

  • 22000-22020: Rage-MP / MTA

  • 22126: Rage-MP / MTA

  • 23000-23200: Battlefield

  • 27000-28000: All Source Engine / Query Games such as Counter Strike 1.6, Counter Strike Source, Counter Strike GO, The Ship, Garrys Mod, Nuclear Dawn, Call of Duty Modern Warfare 3, Starbound, Space Engineers, 7 Days to Die, Rust, Quake Live, ARK: Survival Evolved, Valheim, Mordhau

  • 30000-32000: FiveM GTA-MP

  • 36123-36128: Stormworks

Please use the recommended ranges. If you miss a game, please contact our customer service. We will analyze the game in question and add specific filters.

UDP Ratelimit

We have implemented very specific ratelimits for well known udp destination port-ranges. A default rate-limit of 120pps is applied for every source ip-address. Default limits are overrided by custom defined ratelimits. Please make sure to operate your service within custom defined default portrange. For example, Source Engine Games cant be operated stable outside of port 27000-28000, as the ratelimit of 120pps might be too low.

UDP Deep-Packet-Inspection

Some specific packet content of well known attack samples is discarded depending on it’s payload. Therefore, DPI has been implemented.

UDP Firstconnect

In order to filter spoofed udp packets, we have implemented a intelligent algorythm, which tracks the state of a udp packet and reacts accordingly (either accept/discard). The firstconnect filter typically filters all other remaining bad traffic.

Well known technical impact

During active DDoS-Filters, you might notice some impact, such as:

  • Incoming DNS replies are limited to,, and our own dns caches. Traffic from alternative dns resolvers can be allowed through flexrules.

  • ICMP Traffic might be ratelimited, discarded or replied - icmp packetloss or higher latency might occur (doesnt affect other protocols)

  • TCP Traffic enforces authentication, which might cause the connection to be reset at the first connection attempt

  • UDP Traffic might be ratelimited or enforces reconnection under some circumstances

Please note: ICMP traffic will be ratelimited/replied/discarded. Do not take stability of ICMP traffic into account, whenever the DDoS-Filters are active. Packetloss for ICMP or unusual behavior doesnt mean, there is anything going wrong.

If you encounter any other impact, please contact our customer support. Due to extensive logging and flow collection, we are mostly able to track down any reported anomaly.

flowProxy Features

flowProxy is a inline HTTP client validation reverseproxy, which is activated transparently. Beside of other well known ddos mitigation providers such as companies called C****flare, we dont require you to change your dns records. flowProxy filters are activated on network level, which allows transparent activation.

flowProxy is activated by customer area or API. You can call the API (for example) based on the amount of requests your server is reporting, e.g. by periodically checking the server status. Alternatively, you can permanently switch on flowProxy.

Technical details

flowProxy is a modified, well known reverse proxy, using our own program code to validate visitors based on the possibility if they can interact with the page. Coupled with L7-Captcha, our self written high performance captcha generator, we provide a full stack Layer7 DDoS-Protection solution.

flowProxy runs on comodity x86 hardware and uses Intel 10G network cards to provide even enough headroom for pretty large POST floods. Incoming traffic is prefiltered using a netmap application, which blocks repeatedly abusive clients on network level (IP Ban).

Typical layer7 floods ranging between 500 up to 50.000 requests per second. We have several technical implementations in place to filter even larger attacks.

flowProxy redirects traffic transparently on the following ports:

  • Port 80 - HTTP

  • Port 443 - HTTPS

  • Port 8443 - HTTPS

  • Port 30000-32000 HTTP/HTTPS - FiveM specific caching / filtering

All requests are sent from the following ranges:





Please make sure to whitelist the above ranges. You can use the X-Forwarded-For header to obtain the visitors real ip-addresses using for example apache mod_remoteip or nginx header mapping.


Currently we provide the ability to define custom challenges such as automated Javascript AES, Button Click as well as Captcha. Depending on the complexity of layer7 attacks, the best approach might be Captcha authentication.

SSL Certificates

Customers are supposed to upload their own ssl certificate upfront. Otherwise, the default (invalid) certificate is served. Please check our customer area as well as API docs for further information.

FiveM Game Filter

We have implemented a FiveM specific caching/filtering proxy on Port 30000-32000. The filter is intended to reply with cache content or block malicious HTTP floods targeting the HTTP server of FiveM. The FiveM filter also blocks exploits intended to crash the FiveM server.

On-Premise Appliance

Beside of DDoS-Protected IP-Transit (over GRE/Crossconnect), we offer also the possibility to run your own DDoS-Filters on-premise, for example to implement redundancy scenarios. Our flowShield Appliance is a fully managed DDoS-Protection Stack, using KVM Virtualization coupled with PCI Passthrough, to detect and filter attacks on Layer3-7.

flowShield on-premise appliances are fully managed and 24/7 monitored, such as our own filters. Full management means, you dont need to care about the operation of your appliance. You just provide us with the hardware, we care about all other aspects.

Minimum hardware requirements:

  • Intel Xeon E5 Quadcore with at least +2,5GHz

  • 96GB Memory (64GB for l4-filter, 16GB for l7-filter, 8GB for analyzer, 8GB reserved)

  • Netmap supported Intel or Mellanox 10G/40G NICs (per 10G - 2 CPU Cores, one rx + one tx)

  • 2x 250GB Disk for OS + Virtual Machines

Please contact our customer support for a pricing quote.