In general, there are two ways to use our Mitigation service:
1. A GRE Tunnel with or without BGP
2. A cross connect within an Equinix data center
Our solution works inline and analyzes every packet that travels towards your network.(Incoming)
The TTM(time-to-mitigate) is under 10 seconds.
As it is expensive and not economical to commit spare n*100G Uplinks from bigger Carriers to mitigate DDoS
attacks in the higher 3 figure numbers, we depend on other transit providers for this.
This allows us to mitigate the smaller attacks up to 400Gbps in-house which is four times more than the biggest recorded attack
that we've seen enter the network.
Yes, we offer 100% custom mitigation for customers who need it. This service is charged extra.
Examples are:
- Changing thresholds
- Blocking protocols/ports completely
- Whitelist/Blacklist by Source ASN number
- Whitelist/Blacklist by IP address
- TCP based session timers
- UDP based session timers
- Payload, TCP flags etc matching(Actions: allow, drop, blacklist)
SmartMitigate is our own solution based on eBPF and XDP.
It mitigates all remaining traffic on the application layer(Layer 7) for well known
online games and services.
Yes, we provide you with our JSON based REST API.
The API shows you ongoing and stopped attacks, as well as the size of the attack.
Note: The size of the attack might not be 100% correct and is just the traffic that we received on our
end.
Attacks can also be viewed in our Customer Interface. This provides even more statistics, with detailed graphs during the full duration
of the attack.
1.: Because the system works in-line(inline) with the normal peace time traffic, it is able to see an
attack from the first to the last stage. No attack for now.
2.: The systems analyzes the s-flow samples and sees an attack pattern. It will then trigger an incident
to the incident management service and reports the attack.
3: The mitigator will continue to mitigate the attack with the available countermeasures.
4: The mitigator notices that the attack is over. It notifies the incident management service again and
stops the attack.
We understand that customers want to know how well our (or any other) DDoS mitigation works.
However, we prohibit excessive and constant attacks on the customers rented IP space to „test“ our
service.
This behaviour does not reflect the way DDoS protection works. If we notice this previously
stated behaviour, actions will be taken against the customer. This can also involve blackholing or null
routing /32 hosts.
Note: This is not to compare with customers who receive many attacks daily
We do not limit the amount of attacks you receive per minute, hour, day and month.
If an attack is too large to be filtered by us, our external DDoS mitigation provider „Voxility“ will
mitigate most of the attack before it reaches our network. If an attack impacts other customers(for
example congesting our uplinks), we need to take action.
We are working customer-first, that means, we will take the least affecting method to mitigate an
attack that impacts our network. If these countermeasures do not work, we need to talk to our
external DDoS mitigation provider.
If they are also unable to mitigate the attack, we need to null route the /32 host that is attacked.
Note: This is a rare-case scenario and we have no real world incidents where the null routing was
neccessary.
AS203446 does not give any SLAs regarding the DDoS mitigation services. However, about 98% of all
attacks can be mitigated.
DDoS attacks are evolving on a daily basis and the attackers also get smarter. This is the reason we
cannot give any real SLA on our service.
It is not unlikely that an attack may not be mitigated in the
way the customer expects it to be mitigated.
We do not mitigate Layer 7 SSL directly, but can apply countermeasures to limit the impact, for example:
- Forcing the client to re-negotiate the SSL handshake
- Rate limit by Source IP/Client
If an attack is detected, TCP Authentication will be enabled.
It protects your server from TCP floods by verifying the sender of a TCP packet as a real client.
If the client does not re-transmit the initial SYN packet, the tcp session will never be established and does not reach your server.
Clients that were previously connected to the service(for example a Minecraft server) are already known to the DDoS mitigator and thus, are not dropped.
Only new connections are verified.
In most cases, the mitigation of an attack will happen in under 10 seconds. If the attack type changes throughout the mitigation, the Mitigator will adapt
to this and extract BPF filters that match the attack traffic if possible.
UDP connections are also validated and authenticated if there is an ongoing UDP attack, but this does
not impact clients in 99% of the cases, however, clients may be forced to re transmit their first udp
connections too. Again, this only impacts clients who establish a connection after an attack started
AI based filters are also generated against UDP attack traffic.
