Live data from Hacker News

A DDoS in Asia Pacific

telegram.org

31–40 of 46 posts

Re: A DDoS in Asia Pacific

#31
post #30

Simple solution: move to OVH. Although they don't have servers in SE Asia, perhaps 100% uptime is more important than shaving 100ms off the ping time. (As far as I can tell they don't have real-time audio or video anyway).

What makes you think OVH could cope with a 200 Gbps DoS attack of this nature? A quick look at their services indicates they don't mention what kind of attacks they defend against, and SYN floods are some of the hardest to defend against.

They say they have facilities to clean 480Gbps of data, and 5Tbps of mostly spare inbound bandwidth, so their DDoS mitigation capacity is somewhere in that range (http://www.ovh.com/ca/en/a1171.protection-anti-ddos-service-...).

Re: A DDoS in Asia Pacific

#33
post #10

According to the founder [1], Telegram was even removed from Play Store for a few hours at the request of a South Korean competitor. For whatever reason, somebody in South Korea is seriously pissed off with Telegram. [1] https://twitter.com/durov/status/619486763032182784

Fucking assholes... Let the guys behind Telegram work, they're elevating the current level of messaging apps s big step further.

Re: A DDoS in Asia Pacific

#34
post #30

Earlier quoted context omitted.

What makes you think OVH could cope with a 200 Gbps DoS attack of this nature? A quick look at their services indicates they don't mention what kind of attacks they defend against, and SYN floods are some of the hardest to defend against.

They say they have facilities to clean 480Gbps of data, and 5Tbps of mostly spare inbound bandwidth, so their DDoS mitigation capacity is somewhere in that range ( http://www.ovh.com/ca/en/a1171.protection-anti-ddos-service-... ).

480Gbps across all their datacenters. Each datacenter only has 160Gbps, and I doubt that they'll devote all of that to one client.

Re: A DDoS in Asia Pacific

#35
post #34

Earlier quoted context omitted.

They say they have facilities to clean 480Gbps of data, and 5Tbps of mostly spare inbound bandwidth, so their DDoS mitigation capacity is somewhere in that range ( http://www.ovh.com/ca/en/a1171.protection-anti-ddos-service-... ).

480Gbps across all their datacenters. Each datacenter only has 160Gbps, and I doubt that they'll devote all of that to one client.

They do activate all 3 datacenters. https://www.ovh.com/ca/en/anti-ddos/hoovering-up.xml

Re: A DDoS in Asia Pacific

#36

Simple solution: move to OVH. Although they don't have servers in SE Asia, perhaps 100% uptime is more important than shaving 100ms off the ping time. (As far as I can tell they don't have real-time audio or video anyway).

OVH frequently has problems with false positives, or so some of their customers report. They may offer good value for non-critical services, but they aren't exactly known for 100% uptime.

Re: A DDoS in Asia Pacific

#37
post #36

Simple solution: move to OVH. Although they don't have servers in SE Asia, perhaps 100% uptime is more important than shaving 100ms off the ping time. (As far as I can tell they don't have real-time audio or video anyway).

OVH frequently has problems with false positives, or so some of their customers report. They may offer good value for non-critical services, but they aren't exactly known for 100% uptime.

I've been using them since March, and have had 100% uptime during that period. I haven't had any false positives, and the one time they did mitigate a DDoS I didn't even notice it. As I understand it you'll just have a slightly higher ping time when the DDoS is active. An occasional false positive with slightly higher ping time seems a better option than your site being guaranteed to get null-routed for 24 hours (as happened to me on iweb, although I managed to convince them to remove the null route after a few hours).

Re: A DDoS in Asia Pacific

#38
post #32

Question: Is this possible because they are using Linux servers? The Linux kernel adopted TCP Fast Open? https://www.ietf.org/mail-archive/web/tcpm/current/msg08204....

TCP Fast Open is a terrible idea, and RFC 7413 should be marked as historic so that no one actually tries to implement it. Google has given up on it in favor of QUIC and so should everyone else. QUIC allows for "zero RTT" requests that are also signed (preventing spoofing).

We started blocking these large requests over 3 years ago when we started seeing them. Interestingly enough, that was a full 6-9 months before Radware wrote an article and coined the term Tsunami SYN. We just called it "big SYN". The attack is trivially easy to stop, and anyone running a client that tries a TCP Fast Open should expect failure frequently.

Re: A DDoS in Asia Pacific

#39
post #30

Simple solution: move to OVH. Although they don't have servers in SE Asia, perhaps 100% uptime is more important than shaving 100ms off the ping time. (As far as I can tell they don't have real-time audio or video anyway).

What makes you think OVH could cope with a 200 Gbps DoS attack of this nature? A quick look at their services indicates they don't mention what kind of attacks they defend against, and SYN floods are some of the hardest to defend against.

SYN floods are pretty easy to defend against. Most devices do SYN cookies in hardware at line rate. We run midrange devices that have thwarted 40M PPS SYN floods without a problem. I'm not bragging or anything, just offering a datapoint that SYN floods are easy to stop.

Re: A DDoS in Asia Pacific

#40
post #30

Earlier quoted context omitted.

What makes you think OVH could cope with a 200 Gbps DoS attack of this nature? A quick look at their services indicates they don't mention what kind of attacks they defend against, and SYN floods are some of the hardest to defend against.

They say they have facilities to clean 480Gbps of data, and 5Tbps of mostly spare inbound bandwidth, so their DDoS mitigation capacity is somewhere in that range ( http://www.ovh.com/ca/en/a1171.protection-anti-ddos-service-... ).

Customer testimony on places like Webhosting Talk have cast all of those numbers into serious doubt. OVH is more likely to nullroute your IPs than it is to fight off a 300gig attack.
Post reply on HN