3

TL;DR: How distributed open-source apps like Scuttlebutt are secured from DoS and hackers who can make custom version of application?

I'm struggle with designing an open-source distributed application architecture. I want to create an application consisting of open source server, client, and provider. Client sends requests to one random provider instance that have list of all instances both client and server, and sends it to one of the random server, which, after processing the information, sends a result request back to the client. Every part of this distributed app is open-source, so everyone can create their own instance of client, provider, server, and everything seems to be fine, but what if some programmers will have bad intentions, and they will change client code in the way, that it will send millions of requests (DoS attack) to the specific, not random provider, or change providers with, so it will send all requests to one specific server? Also they can change server code, so if client expects to get a specific picture from server database, hacker will send some inappropriate pictures to all avaible clients.

If I hardcode some kind of verification, like hashing of important functions of API, then hacker will just remove this in his own fork. Therefore, I cannot solve this problem in any way, except by making the code of one of the parts private. For example I can make provider application with private code, so it will check hash of both client and server, and if this check fails - provider will delete this instance from list of instances. This solution sounds good, but in this case, the whole project will no longer be open source.

Summarize: I want to create an open source distributed application, so everyone can make their own instance, improve it, add new functionality, but how can I secure it, so this ability to create custom versions should not be misused for DoS, sniffing, or information corruption in conjunction with all many different versions working together.

I don't quite familiar with this topic, so I'll be glad if you can give me advice, a link to an article on a similar topic, or a book.

Improve this question
5
  • 3
    Start by thinking of the why an attacker might want to hack the system, and the build it so those goals are unprofitable to break. That might mean configurable keys, limited visibility, reputation, web of trust or even something like proof of work. But it depends entirely on the application
    – user1937198
    Jan 12, 2021 at 2:58
  • 3
    In other words any secure internet system, including open source ones must assume all other nodes are potentially malicious, and not trust anything without some form of verification.
    – user1937198
    Jan 12, 2021 at 3:00
  • 2
    How does a Client know which Providers exist? How does a Provider know which Servers exist? You can't build those lists by scanning the internet, so those are your first line of defense.
    – Bart van Ingen Schenau
    Jan 12, 2021 at 6:41
  • @BartvanIngenSchenau I don't need to scan the Internet. I was thinking about initial list of IPs, so Client tries to connect any of Provider IP, and if success, then updates the IP list.
    – Daniil Miroshnykov
    Jan 12, 2021 at 13:53
  • @user1937198 I think I understand what you mean. The first thought that comes to my mind is to use some kind of public-key cryptography, maybe RSA, so each node should check public keys of other nodes, and if public keys are invalid, or key owner node has suspicious behavior depending on metrics like count of requests, the node that performs the verification remembers this public key and block all requests signed with this it. That's looks like a good solution.
    – Daniil Miroshnykov
    Jan 12, 2021 at 14:11

1 Answer 1

Reset to default
3

You don't try to protect the code. You make it so each instance protects itself from bad instances. What difference does it make whether it's a modified version that automatically sends porn to everyone, or a human sitting in front of a monitor, manually sending porn to everyone?

And you work out a solution to each attack separately.

To prevent overloading, you just stop answering requests from IP addresses that send too many requests. If you want you can send back a response saying "rate limit exceeded" (i.e. "please STFU") but make sure not to overload your upstream bandwidth by sending too many of those.

Note that anyone on the whole Internet can overload your downstream bandwidth, and they don't even have to install your software, they just have to know which IP address to overload. There's nothing you can do about that except for buying more bandwidth than the attacker.

If a client can request a specific picture from a database, and you want to make sure it's the right one, you can make sure the client knows the hash (e.g. SHA256 hash) of the picture. If the hash doesn't match, the server sent the wrong picture, so just pretend the server didn't send anything, and then the server will have no advantage to sending the wrong picture (when it could just send nothing).

To prevent someone sending you lots of porn, you add a "block user" feature. To prevent them creating new users and sending you lots of porn, you add a "block all users not on my friends list" feature. You may also consider using a Proof of Work algorithm when sending the first message to user, to make it more expensive for an attacker to spam lots of messages to different users.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.