Untrusted Node DDOS Risk?

While looking through my node’s log, I see an untrusted node attempting to initiate communication.

The node ID: 1QzDKGHDeyuRxbvZhcwHU3syxTYtU1jHy5duAKuPxja3XC8ttk appears in other posts on this forum. So, I assume that this particular node is free running and/or not carefully monitored by the operator.

As I understand the identity process… each node since 17 includes a signed x509 cert as a trust root… called the node’s “identity”… So, the above listed untrusted node must be missing its signed x509 cert. Is that correct?

Also when I check this node on Storjnet I don’t see any uptime information, just that the GeoIP seems to be Paris, France.

So, what protections, if any, are there against an untrusted node DDoS-ing the network with numerous rejected requests? And, is there any method that a node operator may protect against such by dropping packets from the offending incoming IP address?

Is the satellite used by Storjnet for gathering info about nodes. This has been stopped to protect privacy of Storj nodes. The repeating entries inside everyone’s log merely shows the number of attempts satellite tries to access node’s information. You can compare this as a failed login attempt which is not at all similar to DDOSing. Only trusted satellites can access any node’s information.


While this is good information, it doesn’t address the broader implications of what DDoS-ing of the Storj network might look like. Each node is receiving packets from the old information gathering node. While the data on the network is only accessible via signed nodes, each node is still processing the received packets from all untrusted nodes as well. Processing the untrusted packets requires at least some processing power…

In the generic IP world, there are numerous methods to bringing down a known IP host via flooding that host with packets from many different sources simultaneously. While no packet retrieves any information from the target host, the host eventually can’t process all the incoming packets and shuts down.

Typically, an IP host can employ packet dropping techniques or other rate limiting procedures in order to avoid being flooded with random requests from numerous simultaneous sources. So, my post was two fold…

  1. What is the purpose of the specific node (if known)?
  2. In general how does the Storj network handle the possibility of a DDoS attack as described above?

You’ve answered question 1…

Which leads to question 1a… Why is the node still running if its purpose is no longer needed?

collecting statistics every 5 minutes (storjnet.info) I would not call a DDOS attack :wink:

uptimerobot.com can also check every few seconds …

but I’m curious to answer your second question

Storj is a peer-to-peer network with numerous medium to small nodes. Some of those nodes are tiny, consisting of Raspberry Pi SOC boards.

The specific “ping” node listed is not a concern. But what would be a concern is some malicious actor downloading the Storj node program and setting up a large collection of small untrusted nodes whose only purpose is to flood the Storj network and bring it down.

Right now the entire network consists of 2287 nodes. So, a malicious State actor could very easily spend a few thousand dollars and have 3 or four spam nodes per current trusted Storj nodes.

In such scenario, what could a given node operator do to prevent that operator’s node from being knocked offline and/or shut down… especially considering that many of the trusted 2287 nodes are probably running other services as well.

Where did you get this information?

Because he can do it, that is freedom …
Because he doesn’t do it maliciously …
Because StorjLabs does not provide statistics …

ask at http://storjnet.info/ at the bottom of the page is contact

DDoS is always tricky. If someone targets you, you’re going down. It’s as simple as that. However, taking the entire network down gets harder and harder with scale. Right now it’s a few thousand nodes, so I think you could still do some damage by taking a significant portion down. But at 10x the size it’s already going to be hard to make that same impact. This doesn’t really protect individual nodes, but there is no way for storj to do that. Especially since there is no specific need to attack the storj software in order to take a node down. Just flooding it with any data would do it.