DDoS Protection

All-inclusive DDoS protection

The DDoS mitigation service is based on a cloud-based solution that is built on top of the 18 filtering centers we have in Europe and the US.

Scrubbing centers are built in all the mentioned data centers and all are interconnected with each other, totaling an active filtering capacity of 2.1 Tbps at the moment.
This is a 100% proprietary Voxility solution, we do not use hardware or software from other companies in the industry.
The service is delivered as:
– Extra-option on any dedicated server rented in Voxility data centers or any colocation service (with Voxility internet).
– Secure Uplink (physical link between us and the customer, if we are present in the same location)
– Anti-DDOS tunnel, standard GRE or L2TP tunnel established over the Internet between your infrastructure and the Internet. (edge layer) and ours.

Global DDoS Protection

In order to better understand how Voxility DDOS mitigation works and can be used, please check the following information:

To start with , the service can be used on demand or always on, it is up to you.

Most customer prefer on-demand approach as they want to keep the traffic in their network as much as possible. Whenever your current solution is not working anymore you can start rerouting the /24 (or more)  affected Inbound traffic through Voxility DDOS mitigation cloud.

Voxility solution inspects Layer 2, 3, 4 and 7, which are actually all layers that are relevant to be inspected.

Our protection is designed to work under the following parameters:

–      Block very large attacks 1Tbps+ for any type of reflection attack like: DNS Amplification, NTP Amplification, Quake Amplification, Chargen, etc.

–      Block any type of UDP attack that is not directed through specific open ports (TCP are all open)

–      TCP is protected with no syn-proxy (at this time because it works with any network setup – we are developing one leg of traffic syn-proxy) with possibility of layer7 (HTTP/HTTPS) protection over ports: 80,443,2078,2083,2087,2095,2096

–      Layer 7 is only for HTTP/HTTPS

–      On UDP we are supporting these applications:

 

 

 

UDP

1025 – 65535 53 ALLOW – with DNS specific inspection / filtering
1025 – 65535 1194 ALLOW – OpenVPN whith generic inspection / filtering
1025 – 65535 7000 – 8999 (original: 7777) ALLOW – with SA-MP specific inspection / filtering
1025 – 65535 2011 – 2110, 9000 – 9999 (original: 9987) ALLOW – with Teamspeak specific inspection / filtering

( NOTE: 2011 – 2110 range is reserved for Teamspeak Licensing

and it is not designed to work with client connections! )

1025 – 65535 27000 – 29000 ALLOW – With “Steam-Server” inspection / filtering
1025 – 65535 2300 – 2400 ALLOW – With “ARMA3” inspection / filtering
27016 – 27025 1025 – 65535 ALLOW – With “Steam-Client” inspection / filtering

Please note that these ports are fixed (you can see that we have ranges not only single port), however we can add applications on request – usually it takes a few days. These applications are protected by advanced traffic inspection processing filters.

What would pass through protection and it is not meant to filter at this time:

–      exploits

–      viruses

–      different attack types that do not use bandwidth (like exploits / 0day / hacking)

Besides TCP and UDP, the only protocols allowed are GRE and some types of ICMP, but we don’t advice you to use / rely on any of them – as mentioned, the protection it’s not designed to allow VPN through it.

More details on the type of DDoS attacks that are easily filtered:

Ø  IP non-existing protocol attack such as Flood with IP packets with reserved values in protocol field;

Ø  Attack with fragments such as sending mangled IP fragments with overlapping, over-sized payloads to the target machine;

Ø  ICMP attacks such as: ICMP Flood, Smack, Smurf attack (OBSOLETE);

Ø  IGMP attacks such as: IGMP flood;

Ø  TCP attacks such as: SYN Flood, SYN-ACK Flood, ACK Flood, FIN Flood, RST Flood, TCP ECE Flood, TCP NULL Flood, TCP Erroneous Flags Flood, TCP Xmas, Fake Session, SRC IP Same as DST IP;

Ø  UDP attacks such as: General Random UDP Floods, Fraggle, DNS query, DNS Amplification (+DNSSEC), NTP Amplification, SNMPv2, NetBIOS, SDP, CharGEN, QOTD, BitTorrent, Kad, Quake Network Protocol, Steam Protocol;

Ø  HTTP attacks such as: Slowloris (Apache / IIS Attack), R-U-Dead-Yet (RUDY), HTTP Object Request Flood;

Ø  Other category attacks such as:  Misused Application Attack, Slow Read attack.

DDos protection has 3 states:

–      “sensor” > detects and redirects the traffic only when an attack is detected. This is normally a matter of seconds.

Please note that in the few seconds it takes the sensor to kick in, customer services may be affected if the volume of the DDOS attacks is already bigger than the uplink contracted capacity.

–      “always on” > traffic is always filtered, good for servers that are very sensitive to abrupt load of traffic, but we do not recommend this status unless is necessary

–      always off” > doesn’t filter the traffic whatever happens – this is not recommended and it is available only on request.

Ø  For first 2 states you can ask us to disable layer 7 filtering (which is activated by default) or use the available API (find attached).

Also, in the API – at “How to” initial section you have the commands that can return you the info related to the status of each IP

Ø  We have implemented anti-spoof for TCP (layer 3) to HTTP bots (layer 7). These are just examples.

Ø  If you are using our anti-DDoS with layer 7 filtering (reverse proxy), when you receive an attack toward web server port 80, the content of your site is cached by DoS filter. Only non-cached filtered traffic will reach your server. Reverse Proxy is an army of web servers that cache your content and multiplies the capacity of your server hundreds of times.

As a side effect it accelerates web-content delivery. Content that cannot be cached is passed to your server after the user-initiated session is checked against possible malformations.

How Layer7 mitigation works:

  1. Client tries to access your web page – the DDOS protection serves a dummy page that sets a cookie and sends back to the client to refresh page
  2. If client is a real browser, it will set the cookie and re-access your web page, but this time the protection will see the cookie and allow him to pass and access the page from your server.

Regarding SLA for DDOS mitigation

There are multiple ways to tackle the SLA in what regards a DDOS mitigation service.

  1. Service availability – depends a lot on how it is delivered.

If the service is delivered via Secure uplink (cross-connect) we guaranteed availability 99.9% Internet Access, including maintenances (Normally this are not included with any other operator)

Might result in a total of 2h loss of connectivity in a quarter.

We start measuring a failure when most of the Internet is not reachable via this service. It includes downtimes caused by maintenances, technician mistakes, equipment failure etc. Failures of the cables (cross-connects) used to connect to this service are subject of a different SLA and do not count as a failure.

Maintenance (like software upgrades) or other operational mistakes will result in outages. Maintenance typically lasts 15 minutes and it is planned.

When the uptime guarantee for a calendar quarter is not met we will credit back your account as follows: 1 month of this service price for 99.2% or better uptime; 2 months of this service price for uptime of 99% or better; 3 months of this service price for less than 99%.

Excluded from any uptime compensations are Force Majeur and downtime caused by customer actions or abuse of the service.

If you also have an anti-DDOS tunnel as a backup, this should make service availability go to 99.99%.

If you have only the anti-DDOS tunnel service, there are multiple factors to keep in mind as the traffic will be passing a 3rd parties (other networks) to reach you.

  1. Service efficiency – this is where we encounter difficulties to put it in numbers (how I did above) as this is not entirely dependent on Voxility.

To start with, the service works under the parameters described at the beginning of the email.

The general solution is made to protect networks and not specific applications’ traffic or filter exploits attacks which also depend on customer application.

If there is a new type of DDOS attack passing the protection, we have a team of engineers available to update the filters accordingly. Depending on how complex the attack is it can take up to 24-48 hours to completely solve the problem. This time estimation is given based on previous experiences. Most issues are solved a lot faster, of course.  

Our team needs traffic captures from customer side, we analyze them and update the filters accordingly, in real time. This is how the process works.

What is important to know is that we can’t protect encrypted traffic (VPN like) as we can’t inspect it. This is a problem with any DDOS mitigation provider.

Encrypted VPN services like SSL VPN, IPsec Tunnels using UDP protocol are filtered (dropped in most cases) in mitigation mode, while services on TCP, like https/S3/TLS Exchange are supported.

VoIP traffic and anything similar based on UDP in general (different ports from the ones we support in our list) cannot be properly protected through our general DDOS mitigation solution as there are too many false-positives.

This is where the Expert SLA is normally needed as we would be building an in-line appliance with custom filtering rules tailored to your application and type of traffic. This involves and extra hardware appliance and a solution built from scratch, customized on customer needs. It is independent from the general cloud service and the filtering capacity is limited to the uplinks connected in the hardware box.

In this case, if the DDOS volume overwhelms the box capacity, traffic will be rerouted through the cloud-based solution (2Tbps+ capacity).