Most of our customers do not even know that they have WEDOS Global Protection enabled. They only see a website that is running quietly and does not even notice the attacks. But only a few hours earlier, it may have been a problematic website that was overloading the server and affecting other customers. Within five minutes, our support team redirected the traffic from the server to more than one hundred anycast reverse proxies, which immediately started filtering the traffic. So what is happening under the hood? There is surprisingly a lot of technology behind it. Let us take a closer look.
Architecture: two platforms, seven layers
The protection runs on two independent and functionally identical platforms. Each platform runs on different hardware.
Inside each platform, traffic is processed in seven layers, from the entry L4 layer, through load balancing and cache (Varnish), to the final layer that sends traffic to the customer’s origin server. Six of these layers run on HAProxy and the seventh layer is the cache. Each layer has three separate configuration profiles depending on the type of traffic:
- vip — reserved for enterprise customers
- general — normal traffic
- attack — a profile activated when an attack is detected, with stricter rules
This is why the HAProxy configuration is so large. Across both platforms, six HAProxy layers and three profiles, there are around 140 thousand lines of configuration. However, it is important to understand that these are not hundreds of thousands of unique decisions. The attack profile mostly uses the same base as general and differs mainly in specific limits and actions. The real amount of unique decision logic is therefore much smaller than the number of lines may suggest. The HAProxy configuration must still be explicit and repeated, because every layer and profile must be possible to audit and change independently, without the risk of breaking the rest of the system.
The brain of the system: Lua modules
HAProxy itself can route and filter traffic based on rules, but the decision logic — in other words, “is this an attack or not?” — is provided by a set of our own modules written in Lua. Together, they contain more than 9 thousand lines of code divided into specialised parts, for example:
- dns_reader.lua (more than 4,000 lines) — an asynchronous DNS client and cache. It continuously loads configuration rules stored in DNS TXT records and resolves the origin servers of individual domains.
- log_logic.lua (more than 2,500 lines) — it normalises and evaluates logs from the whole infrastructure in real time. This is an important part of the decision process, not only something used for later analysis.
The other modules handle tasks such as JA4 fingerprinting, which identifies clients by the fingerprint of their TLS handshake and is much more reliable than classic User-Agent headers. Other modules handle CMS classification, where some rules are custom-made, and bot classification, which helps separate legitimate crawlers from other automated traffic. More modules are added over time.
This layer is supported by the Varnish/AVC configuration, with more than 9 thousand lines of YAML across both platforms, which handles caching and additional processing at the application level.
The data that feeds the system
Decision logic is only as good as the data it works with. WEDOS Global Protection maintains more than 100 MB of continuously updated lists, including IP ranges, ASN mappings, geolocation data, JA4 fingerprints and DNS maps, stored in more than 220 files. Most of these lists are downloaded and updated automatically. They are not manually written data, but production input that must stay synchronised with real internet traffic. There are also regex lists used to recognise patterns in requests and more than 270 templates for error and challenge pages that are displayed when the system considers traffic suspicious.
Administration: one application, 34 thousand lines
Above the whole infrastructure is a new administration application that we will deploy soon. Technically, it is one HTML+JS file with more than 34 thousand lines of code. The source code is fully readable and there is no minified build.
Who works on it and why it is sensitive
WEDOS Global Protection is security infrastructure, and this comes with one important principle: only a small group of people has access to the source code and the core decision logic. This is not about trust, but about security. The more people know the exact details of how the system detects attacks, the easier it could be to use this knowledge to bypass the protection. Security systems are therefore designed so that sensitive logic is separated from a large group of people.
At the same time, many more people take part in the real development process than only those who commit code to the repository. The system is tested, feedback is collected and ready parts of configuration can come from outside the core development team and are then integrated into the production setup. This can include proposals for new rules, tuning thresholds based on real incidents or feedback from production traffic. This model — a small core team with access to the source code and a wider group involved in testing and cooperation — is exactly what this type of security infrastructure needs.
Unlike WEDOS Hosting, WEDOS Global Protection is much better known abroad, where we have several large and important partners. We also receive feedback from them, compare it with our logs and use it to improve the whole system.
What to take away from this
WEDOS Global Protection is not a one-time product that was built and then finished. It is a living system that is improved every week based on new types of attacks and changes in internet traffic. Behind a simple switch in the administration are tens of thousands of lines of our own logic, hundreds of thousands of lines of configuration divided into layers and profiles, and a constant flow of current threat data from across the internet. Access to the heart of the system is limited for security reasons. The hardware and connectivity behind the system are another complex part of the whole solution.