6

From a security standpoint I'd like to understand who can peer with my node. Let's say I make the chainspec public, and someone comes along with a different node binary, and peers with my node, with a malicious pallet, would that happen or something would prevent such a thing from happening?

I ask this because I am trying to understand what kind of security threats, besides keys being stolen & DoS, are possible on the node itself.

Improve this question
5
  • If you are the bootstrapping node (first node that instantiates the network), then any other node can temporarily peer with your node. The scenario you present is a bit odd, nothing would happen. If the runtime is altered (malicious pallet) then you are running different chains, so in this case there are no repercussion for your chain, also recall that the runtime is apart of the chain, therefore you'd have a differing genesis state.
    – infinitesimallySmart
    Commented Apr 6, 2022 at 14:11
  • This link may be of use to you github.com/paritytech/substrate/tree/master/client/network, in particular the section on discovery mechanisms
    – infinitesimallySmart
    Commented Apr 6, 2022 at 14:19
  • @infinitesimallySmart yes it's just a ridiculous example that I managed to think of, the general question was, besides variables like "spec_version" and "impl_version", what makes a node peer. I know that when you change the runtime you may bump up the spec_version which can cause your node to still peer, but they may have different runtimes.
    – Purple_Turtle
    Commented Apr 6, 2022 at 16:26
  • 1
    There is too little focus on one question in this question IMHO... might you re-title this to be more specifically one question? we can of course open more related questions :) "Can malicious node peering occur?" "What can malicious peers do to attack my node?" ...
    – Nuke
    Commented Apr 6, 2022 at 17:27
  • @DanShields of course this question could use a more concise title indeed.
    – Purple_Turtle
    Commented Apr 30, 2022 at 10:50

1 Answer 1

Reset to default
2

The primary thing that nodes look for is a common ProtocolID, this is what peers at the LibP2P layer your node will try and communicate with at all.

This is best outlined in this issue to replace protocolId with the genesis hash, where failure to set a unique ID can lead to nodes of different networks (even IPFS nodes) start to communicate but because they are incompatible protocols above this, just case noise and bloat your node's bandwidth.

One mitigation here is traditional: use firewalls to ensure that you are screening out connections you do not want. Substrate in itself only protects what happens once it receives messages, and should not be tasked with more resource intensive tasks like DOS protection. Also a good firewall and opsec will make it much harder for your node to be compromised in general, where you likely store your keys for nodes' network ID and possibly validator associated signing keys.

Improve this answer

Your Answer

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

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