Potential attack: out of band ddos to own close group

It would be handled to the point where decryption was tried, then it would be seen as junk. So not all the way up the stack but the node would be disconnected form us as it would be seen as faulty.

the connection would be closed as it could not communicate. I am not sure what you mean with a half open connection here. There used to be attacks in hhtp where asking for many pages slowly used up all the sockets, maybe that is what you mean. For us that would not work too well as nodes don’t connect to multiple IP:port combos but only a known ip:port combo, except for clients, whose connection is a lower priority than a node. (late Sunday night, so I might be missing your point here)

1 Like

Meaning the requesting node would disconnected for sending junk?

For the rest, I’m going way back. I’ve been out of the network security scene for quite some time… And pretty sure I was thinking of a half open port scan. Sending syn, waiting for syn/ack, but not finishing connection. I was never a DoS type of person. My knowledge of techniques is quite limited. But that’s what I was thinking of.

1 Like

Yes that’s right.

Ah yes, I see what you mean. Makes sense now. For vaults you could do that but only to one IP:PORT, as that would be all the negotiated connection, would allow. So you would not connect, but that makes you not be part of voting or possibly connected to less and quorum honest nodes. So it could backfire really.


If a vault came under attack, this could be reported to other vaults in the close group and then, node aging changes could be suspended until the attack ended by majority consensus - Hence nullifying any benefit to the attacker?

Or something like that …

This all started with my idea of DoSing a target’s connection, not really the service itself. The discussion has migrated into that though. Detecting this on the service (SafeNet node software) could be done. However, if the attacker is successful (trying to get an elder kicked out by timing it out), getting an S.O.S. out might be hard.

The original thought was just bogging someone’s connection down so they are slower to respond. Something along the lines of those super competitive first person shooter players paying a botnet to DDoS their competitors so they can win the prize pool. It doesn’t kick them off the server, but does lag them enough to give the attacker an advantage on response time due to ping.
This is what I had in mind with the original post. I’m not sure how the mechanics of it work, but obviously even without running a service (listening for a connection from any IP) it’s able to be done.


This wouldn’t protect from other sorts of DDoS, where the rogue node orchestrating the attack wouldn’t even be known. The packets would be coming from a range of different sources without even a hint they have anything to do with the destination’s being a Safe Network node. If it’s behind NAT, the attack wouldn’t even reach (or target) the Safe node itself, just the last known public IP, the router.

The problem is that nodes know too much about their close group or section. @Stark’s first response, about separating nodes from their peers with an additional step, seems to be a good idea to mitigate this.


I think the overhead of this would be crushing. I like it from a security standpoint, but having to proxy every single communication from every group decision while coming to consensus would knock lots of residential connection out of contention for being nodes.


Not sure about that. The Tor network is three hops by default and one can stream video on that without a hiccup on residential.

I didn’t have time to find the network diagrams on GitHub but I believe the following is a thread (a bit dated) that describes the indirection resulting from by having different vault personas (ex.data holders vs. data managers) that eliminates the threat described in the original version of the OP with regard to farming.


As far as general out of band ddos protection against malevolent nodes in your routing table goes, I think that is a valid concern and becomes part of malice detection. However, it seems to me that a few simple and naive iptables scripts would offer a lot of protection against this in the case of out of band communications from a botnet. For example, some “SafeWall” settings might include dropping all packets ip addresses not in your routing table (or those whitelisted by you, like a network printer).

Protection from adversaries in your routing table that spoof the IP address of good nodes in your routing table is something interesting to consider… But dirvine’s comment about the difficulty of spoofing seems like this would be a challenging exploit.


While such white-listing would be fine for a dedicated Safe server, would it be practical for someone running a node from a home computer or phone?

WRT farming, the idea isn’t to keep requesting a chunk, it would be do slow down other nodes that also host the same chunks that the attacker does, so that the attacker would be the first to respond said chunk. Thus being rewarded with the ability to make a farm attempt.

@TylerAbeoJordan beat me to the next point.

1 Like

What is the likelihood of that? I thought data was spread over the whole network and not within a particular close group.

I think I’m not really understanding something here.

That’s why I put in my first post “my understandings” I kind of hoped I was wrong on this particular point, but I haven’t been correct… A close group all manage the same data. That’s why when you get churned it’s kind of a big deal because you have to re-download all the new data the new group is managing.

Data is spread out across the whole network in xor space, which spreads it out in physical space as well, which is great. But to the best of my knowledge, everyone in the group is all making sure that data piece ‘A’ is well protected. If not, that puts a wrench in a big part of this discussion, which would be great.


I don’t know for sure either, just been working off of my assumptions. I suppose someone will give a hard answer to that soon.

Regardless of that point though, wouldn’t slowing down the other nodes still give the attacker some form of advantage?

I understood you. IIUC the different data manager vs data holder personas protect against your scenario. See image below. Your ddos would be occurring at the data manager level (DM)

The adversary would need to own one or more data manager nodes as well as the corresponding pmid storage nodes in order to benefit. IMO because of the random placement of nodes in the network, achieving this comes down to brute force probabilities. Note the layer of indirection between the data managers and the actual stored data.


It is if you want to be SAFE. :upside_down_face:


To be clear, each specific chunk is managed by one section.

But you were correct on this point.

This part is not final either. In a section the notion of groups may still exist, we have not removed those. So the section elders make decisions, but adults etc. obey decisions. So in Alpha 4 there is the possibility the groups still exist in a section. It does not alter too much, but just for info, the data will be in a section for sure, but more likely within the close group in that section.

With alpha3 we are not focussing on data but a4 will mean we must and that is OK. Ultimately I would like much larger sections that contain many groups.


Sorry for bumping an old thread but are there any ideas whether this attack will be mitigated?

An attacker could deploy a huge number of vaults that would behave like any other vault but would collect the IP addresses of their entire sections. At a later time, it would take a relatively small effort to shut down a significant portion of the network purely from the IP side and the bad nodes could still go on undiscovered even after that.


maybe this helps:

1 Like