[buro9]

> I never need to do anything, but I don't think these attacks are real anyway

What would it take to convince you an attack is real when it has been 100% mitigated and you never saw it in your backend infrastructure?

I ask as the engineering manager for DDoS protection at Cloudflare, and we stop a lot of attacks. But I feel this tension in the communication and product offering... if we do our job well enough that a customer's system does not see the attack, how does a customer see and feel the value?

An example is that as a reverse HTTP proxy we are implicitly also a full TCP proxy for HTTP traffic and so we receive significantly large SYN or ACK floods. We stop these 100% by virtue of being the terminating TCP proxy, but also by using connection tracking, anycast, XDP + eBPF, and so forth... you won't see a single one of these SYN or ACK packets hitting your infrastructure... so what would we have to communicate to convince you that the attack existed?

[regecks]

>What would it take to convince you an attack is real when it has been 100% mitigated and you never saw it in your backend infrastructure?

I was running node_exporter, which exports a lot of detailed network info from my kernel to Prometheus. During the time intervals leading upto, during, and after the attack, there is nothing there. Not even a blip.

I don't find it likely that OVH completely prevented any kind of volumetric attack from hitting me with zero detection latency. I just have doubts about there existing a perfect technology that doesn't have any false positives and also kicks in instantly. I'll keep an open mind.

[IAmGraydon]

Simple reporting with relevant metrics, not logs.

[rmdashrfstar]

Do you publish metrics on “attacks prevented” (or access to logging and monitoring) for customers?

[buro9]

Yes.

For HTTP customers there are full SIEM logs under Firewall > Overview on our dashboard, and for paid tiers there are drill-down analytics in addition to the full SIEM logs. There is also log push to receive near real-time full HTTP logs into Google or AWS for your own analysis and these show if a firewall feature touched the request or if it was served from cache.

In addition for HTTP customers we show graphs of SYN floods, etc for the IPs your web properties are advertised on.

For L4 customers via Magic Transit we also have Network Analytics showing what we received at our edge network and a log of attacks detected and mitigated.

There is still lots of room for improvement... that's really what I'm asking, what does the ideal system look like for someone where they see and understand the data and trust it.

For example, is it valuable to see the attack landscape and what is happening across our systems even when you are not the target? Would that help give perspective to attacks that do target you, and also increase faith that this system exists and is stopping attacks when attacks do not target you?

[bberenberg]

These are great examples of technical details, but they're difficult to translate into impact and business value.

Would 100k SYN floods have slowed me site down? Would it have taken it offline? Would it have caused the site to remain up but corrupt data on the backend for some reason?

Off the top of my head, I would think about offering a "replay attack against your staging infra" feature on higher tier plans. The price point should help prevent someone leveraging you as an attack platform, and customers will be able to understand the value that you're bringing to the table in a much more practical way.

[staticautomatic]

I'd build a (metaphorical) visualization of the customer under siege, so they can watch it while they're being attacked and see what they'd be up against without your protection.

[hashhar]

I think it'd be helpful to highlight the impact on YOUR infrastructure for an attack i am facing.

Will help add perspective to how disruptive the attacks are.

[tudorw]

Yes, also perhaps some guidance figures on what the impact would have been had these measures not been in place.

[buro9]

Hard to answer the impact on your systems had we not stopped it... we don't know the full capability of your systems. Whether you can take a 10k packets per second ACK flood or a 1M pps ACK flood, or the 100M pps ACK flood depends on a lot of things we aren't privy to.

What we can tell you is the frequency, size and nature of attacks that Cloudflare sees, and when we can clearly identify that an attack was unambiguously targetting you specifically then we can tell only you about that too.

If there were a global dashboard which was vague about the target and source, merely the frequency, size and nature... would that be valuable?

[hashhar]

> If there were a global dashboard which was vague about the target and source, merely the frequency, size and nature... would that be valuable?

Yes.

> What we can tell you is the frequency, size and nature of attacks that Cloudflare sees, and when we can clearly identify that an attack was unambiguously targetting you specifically then we can tell only you about that too.

Yes.

Also, even if you could tell us WHAT kind of attack it was that would be helpful too.

[tudorw]

I should have made it clear I'm not a user,feeling your frustration at being 'invisble', that given, yes, I think a dashboard as you described, perhaps you could have some interactive option to enter your system config to allow you to see how that would have affected your infrastructure?

[OrgNet]

Maybe describe how big the attack was in a communication with the customer? ie: how many connections per second, bandwidth used, etc? If you could trace the attacker and prosecute them, that you be a lot better, of course (and possibly the way that would gain the most confidence). In other words, if any of your claims could be confirmed by a third party, it would be good. Or you could propose to them to be hit by the attack for a set amount of time before you move in.

[zzzcpan]

You are looking at it as if DDoS protection provides some additional value to customers they don't comprehend, but not as a basic necessity for hosting providers to ensure competitive quality of service they can offer customers, which is how it is in competitive markets. Trying to convince customers about attacks to fake perceived value is the same as trying to convince customers of edge nodes failing over to other nodes, but you don't do that, don't you? Think about why you don't do that. Faking perceived value is AV companies level of shadiness.