Avoid DDOS attacks

This is a technical post. It is mainly here to inform you if you have any interest in core development.


As some of you may know, uCoin software handles 6 types of documents:

  • Identity
  • Certification
  • Membership
  • Transaction
  • Block
  • Peer

These documents are generated both by:

  • uCoin (Block & Peer)
  • Sakia/uCoinApp/Cesium (Identity, Certification, Membership and Transaction)

For now, few controls are made to avoid these documents to flood our uCoin instance if, for example, Sakia had a bug and looped on identity creation, flooding a node with billion of identities and making them being written in the database.

Definition: DDOS

The general idea of DDOS attack is the flood. That is, adding a lot more data than expected somewhere.

For example, a DDOS attack happens very oftenly when a new super game is launched: all the new players come at the same time to play, which makes a lot of concurrent connections and makes the gaming service overwhelmed and likely unusable (we can remember Diablo 3 launch).

Our DDOS concerns

What are the potential DDOS sensitive points in uCoin? We could be scared by:

Blockchain flood

Imagine if people could send many blocks in a row: the network could lose its synchronization, no more agree on a current block and making impossible to have a shared currency. This is a critical point.

This attack was solved out-of-the-box by Bitcoin system: using a proof-of-work system. uCoin uses such a system, and we consider to be safe on that side.

Network flood

Like for Diablo 3: too much connections in a short period of time.

This is the hardest attack to counter, because it is a physical network level attack, uCoin does not have any power on it. However, uCoin is P2P and DDOS attack likely does not work on large number of targets. So if we have enough nodes on the network, some nodes could be DDOSed and the currency could continue to live.

Data flood

What if Sakia made a loop in Identity creation, and sent 1 billion identities to a node (even if it might require a week, we have to consider the case).

This is the object of my post: currently uCoin only apply few rules to avoid this attack. So any client could overwhelm your node with data, and likely saturate your disk on long term.

Countering data flood

@Inso and I discussed of possible solutions in this github issue.

To sum discussion up: each node sandbox will be limited in size for each document.

So as long as the sandbox has room for new documents, it just accepts it like it does today.

So if you send a valid identity, it will just be added to the pool (note how this has nothing to deal with blockchain - we are in the sandbox, the part before the blockchain).

But to avoid attackers to flood all the sandboxes of the network and making any new data rejected, we would add rotations: each sandbox would be a kind of flow where new entites replaces the olders.

These sandboxes would also introduce priorities: an identity with a certification is more likely to be written to the blockchain, so we will prefer to keep it and reject the identity which has no certification. But we could also sort identities against their creation date, proximity with the WoT, etc … the number of possible criterias is just depending on our imagination :slight_smile:

We would implement a similar algorithm on each document.

Now you can’t say you were not aware.

This will be integrated in the next coming versions of uCoin 0.20.0.

4 « J'aime »