ivan_dubas

Hello
I'd like to inform you about serious vulnerability in VAC settings. This concerns to invalid Anti-Ddos settings on your network hardware.
This bug makes antiddos option absolutely useless. I kind of researcher and researched your antiddos protection.
Of course I'm speaking about "forced mode" when VAC already is blocking tcp SYN packets from spoofed ip addresses without valid ACK reply to SYN-ACK.
I'll explain the idea of bug just in 2 commands of famous tool for network stress-testing:

hping [A] -p -M [C] -a [D] -s [E] -PA -c 1 (SA flag works too)
hping [A] -p -M [C] -a [D] -s [E] -S -c 1

A - victim ip in OVH network
B - destination tcp port of victim
C - any random number (TCP sequence number, TCP ack must be 0)
D - spoofed ip address. Of course in real attack it will be --rand-source
E - any random source port. Perhaps not 80,443,3306,3389 or any other common tcp services and used in simple firewall rules.

There are several another successful combinations and this one just for example.

For some reason after receiving first packet VAC adds ip source to list of legitimate hosts and after that it receives any packets from this spoofed ip including SYN flood!
This is a disaster! I can guess that such behavior is some kind of "feature". But it is very dangerous feature especially for Kimsufi and SYS servers as they have weak hardware.
Many users have chosen OVH mainly due to ANTIDDOS option and I'm one of them.
Of course I don't plan to disclose this bug to public before you will fix it. But I have to say that it is very simple to modify hping3 or even write little source code from scratch for bypass OVH syn flood protection.
Definitely I have both and have already successfully tested on my OVH account. I have already seen tcp SYN-ACK attacks with help of reflection from real hosts. Second SYN-ACK packet from real host is accepted by VAC too.
This is incorrect behavior. Those attacks are from script kiddies. But perhaps clever hackers have already guessed about full scheme of successful attack. You had better fix bug ASAP before they start using it.

My second request: please improve firewall API so that tcp options have all possible flags and their combinations. For what purposes they are only "syn" and "established" now ? Absolutely useless. I can't imagine
situation where these flags will be useful. Their combination - yes but now separated using is only possible.

Third request about ip load balancer. Is it possible to configure balancer so that it didn't not send SYN to backend until tcp 3-way handshake will be established between client ip (from Internet) and balancer ip?

Thank you in advance!