Anti-DDoS Protection for ISPs and Hosting

A stateful firewall, which is what our SkyGuard engine is, does not judge each packet in isolation. It keeps a table of active sessions and knows whether a packet belongs to a connection that was actually established. Most DDoS traffic is out of context: ACKs with no preceding SYN, DNS or NTP replies nobody asked for, fragments without a header, traffic from spoofed source addresses. A stateless filter needs a separate rule for each of those, while a stateful firewall drops them by definition because they match no known session. Protection therefore does not depend on whether we managed to write a rule for the exact attack vector in time.

Two modes are available: always-on and on-demand. In always-on the filter sits permanently in the traffic path and works around the clock. In on-demand you decide which prefixes we cover and when we engage protection. What matters is what happens underneath: there is no box waiting for a detection alarm to wake it up. SkyGuard, our own filtering engine, runs without interruption and verifies every packet that passes, so mitigation has no spin-up stage and starts with the first attack packet.

It changes the path, and there is no point pretending otherwise: protected traffic has to run through our network, because that is where the filter sits. The difference is where we take it. We do not hand it to an outside provider or send it to a scrubbing center in another country. We scrub it in our own infrastructure in Poland and connect wherever you already are: a cross-connect at Equinix WA, LIM DC, DataHouse or Korbank, a VLAN at THINX, TPIX, POZIX, WRIX, 1-IX or 1PL, or a GRE tunnel. The path stays domestic and short, and the filtering itself adds no further hops. During the quote we can check together on a traceroute how that path looks from your network.

At layers 3 and 4: SYN, ACK, RST and FIN floods, UDP amplification and reflection (DNS, NTP, memcached, SSDP, CLDAP), fragmentation attacks, high-pps floods and spoofed-source traffic. On top of that comes layer 7 filtering, where we look at the content of a request rather than only the packet header, so queries that imitate user traffic but make no sense for the protected service are dropped. The exact scope of L7 filtering is agreed at turn-up, because it depends on the protocols you run.

Yes, and it is one of the reasons we filter statefully. In a reflection attack the attacker spoofs your subscriber's address and sends queries to CDN nodes, open DNS resolvers, NTP servers, memcached, CLDAP or SSDP. The replies arrive from real, trusted addresses, so an IP blocklist either misses them or blocks genuine CDN traffic to your subscribers along the way. A stateful firewall settles it differently: nobody on your network sent a query that reply would match, so the packet is dropped while those same CDNs stay fully available to your users.

We handle them well, because our protection does not rely on per-IP thresholds, and those are exactly the weak point in carpet bombing. In this attack the flood is spread thinly across hundreds of addresses in a prefix, so no single address looks suspicious and classic detection stays quiet while the total saturates the uplink. We check every packet against session state across the whole prefix at once, and spreading an attack over more addresses does not make those packets part of real connections. We also do not have to blackhole hundreds of addresses or divert the entire prefix.

Yes, and with CGNAT it matters even more, because hundreds of subscribers sit behind one public address. An attack on that address is an outage for all of them at once, and a blackhole from your upstream means exactly the same thing. We filter the traffic ahead of your port and never cut the address off, so the CGNAT pool keeps serving subscriber traffic while the junk is dropped.

The simplest setup is protection together with our Protected IP Transit, because then we filter traffic that already passes through us. Mixed scenarios are possible too, where we carry only part of your traffic or only the prefixes you point at us in on-demand mode. Tell us your current topology and who serves you today, and we will say plainly what can be done without rebuilding your network.

No. We are not a filtering setup built on RTBH or FlowSpec. RTBH means dropping the attacked address into a blackhole, cutting it off along with all legitimate traffic, which in practice gives the attacker the outcome they were after. FlowSpec distributes coarse rules over BGP that hit an entire prefix, port or protocol. We work at the level of a single session and a single packet: the address under attack stays reachable, and only what does not belong to an established connection is dropped.

Networks where one targeted address breaks the service for many customers at once: ISPs, hosting and dedicated server providers, colocation, game hosting, e-commerce and SaaS platforms, and VoIP operators. In those networks you cannot protect a single service, because the attack saturates the link or the state tables before it reaches its target. The filtering has to happen higher up, at the carrier edge.

It is not a requirement. If you have your own ASN and address space, we announce your prefixes over BGP and the protection covers the whole prefix rather than individual services. If you do not hold your own resources, we can provide addressing as part of the service. Either way we apply route filtering and RPKI validation.

Send us your traffic profile, the services you want protected and the target location. We will prepare a filtering profile matched to your protocols, agree the thresholds and quote the port together with the contracted bandwidth. Configuration itself is usually a matter of working days rather than weeks, provided the port or cross-connect is already available.