How does dfinity protect against using many update calls to make canister run out of cycles?

General DFINITY
1

if the developer is the one that pays for all dapp transactions, An attacker could create many update calls and therefore making the canister run out of cycles to execute, so the developer will be paying for dos attacks, how is that solved?

2

Canister ingress message inspection

This will let you set an access list of which principals can make update calls. Only the calls which get through will have cycles charged.

1 Like
3

The Boundary Nodes stop Denial of Service attacks, they are your first line of defense, DFINITY takes care of them.

The only thing missing is a way to report / inform DFINITY of DoS sources or attacks that somehow make it through the Boundary Nodes.

1 Like
4

One small caveat: Ingress message inspection, as the name implies, only works for ingress messages, i.e. messages coming through the HTTP interface of the Internet Computer. They don’t apply to messages from other canisters. However, one simple measure to guard against attacks from other canisters is to require some cycles to be attached to that message.

1 Like
5

but if we want to create an app that is public, we can’t have an access list, everyone can make update calls right, which may be subject to ddos attacks?

6

The interface of a IC canister is a very different interface than a web server, and has a different attack surface. A web server doesn’t get replicated like a canister does. On the IC, attacking a canister means attacking the subnet. An attacker will find their data packets ‘sandboxed’ as they cannot perform any privilege escalation attack. Due to its design requirements, Dfinity created their own LLVM for use on the IC, and you better believe that they are tight-lipped when it comes to talking about it. I can’t get anything out of them other than ‘it’s different and was designed to prevent any shell breakout attacks’.

The boundary nodes are supposed to stop DDOS attacks. At the least, this should mean handling a brute force DDOS. I don’t know how this filtering works, but ‘it does work’ is my current operative response. I know that in Cryptocurrency, that is about the worst response to give. But I believe that there have already been instances where this DDOS protection has worked.

Everyone making an update call means anonymous users all updating the same global value(s) on the smart contract. Race conditions would make that value only useable as a source of semi-randomness. As privilege scanning/attacks are such a common attack vector for DDOS, I’d like to think that when they say that the boundary nodes stop DDOS attacks, they are including this vector in that discussion.

1 Like
7

True, but the question here is not about privilege escalation, it is about sending lots of spurious update requests to a canister, causing it to burn through its cycles (either entirely or just at a higher rate than necessary).

It is all open sourced, so you can look into it if you’re curious. Also, I somewhat doubt that you’d get such an evasive answer out of the gate. I would understand, though, if people didn’t have the time to go into too much detail.

It’s your run-of-the-mill rate limiting per subnet, per canister, per IP address, etc. It is very likely open source itself (I don’t keep track of what is open sourced and what isn’t).

Canisters are actors. I.e. they are single threaded. And if they weren’t I doubt that any decent developer would just write code that accesses the same global state in parallel without any synchronization mechanism.

You can still implement DDoS protection of your own, if this is something you are worried about. You keep track of recent load, where that load is coming from (i.e. who signed the ingress messages); what sorts of requests you are getting, etc. And then if load is high; and it’s all coming from the same user; or it’s all identical/similar calls; you can implement rate limiting of your own when inspecting ingress messages.

I suppose a DDoS protection library may be written that could be applied to any canister.

8

Did you mean canister sandbox, not LLVM here?

LLVM is a toolchain for compiling program that the Rust compiler uses under the hood. I am pretty sure that the Internet Computer source code is compiled using standard Rust, which uses standard LLVM.
I never heard about a custom LLVM for Internet Computer. Forking LLVM to create some custom version of it would be a huge engineering effort and I don’t know what would be the benefit of it.

If you meant canister sandboxing, then there are public resources explaining it:

Canister sandboxing uses a common technique of process isolation with SELinux. If you have concrete technical questions about it, I’d be happy to answer.

4 Likes