From 426321b67ed5ed39f6863491df37f1fccd8f53b4 Mon Sep 17 00:00:00 2001 From: "ollie.j" Date: Mon, 29 Apr 2024 18:58:47 +0900 Subject: [PATCH 1/3] Add securing-nodes.md --- docs/nodes/core-cell/securing-nodes.md | 31 ++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 docs/nodes/core-cell/securing-nodes.md diff --git a/docs/nodes/core-cell/securing-nodes.md b/docs/nodes/core-cell/securing-nodes.md new file mode 100644 index 0000000000..6a8d6b3df8 --- /dev/null +++ b/docs/nodes/core-cell/securing-nodes.md @@ -0,0 +1,31 @@ +# Securing nodes + +Node security is a critical aspect of a secure blockchain network. Depending on the type of node, the operator needs to pay attention to security. + +- Consensus Node (CN): CNs are responsible for proposing and validating new blocks. A compromised CN can create malicious blocks or disrupt the blockchain. Certainly, the misbehaviour of a few nodes is blocked by the BFT consensus. However, they can still cause bad blocks or round changes that degrade the stability of the network. Therefore, core cell operators should maintain their nodes responsibly. +- Proxy Node (PN): PNs communicates with nodes on the Internet on behalf of CNs. While a PN does not sign blocks by itself, a security breach of a PN can damage the network. Its p2p key can be used to connect to the CN's restrictive network. A compromised PN can also neutralise the transaction filtering such as the spam filter. +- Endpoint Node (EN): ENs provide public access to the network for the applications. While an EN has no authority to manipulate the blocks, a security breach of an EN can pose trust issues. A compromised EN can serve false information including block data and account states. It can drop or censor incoming transactions if the app is directly connected to the EN. + +## Node security + +Follow the security best practices whenever possible. To list a few: + +- Keep the operating systems and installed software up-to-date. +- SSH security. Disable remote root login, disable password login, and prefer public-key authentication. +- Nodes should be run on a dedicated machine. To reduce the risk of malware via supply chain attacks, refrain from installing other software, especially the ones that connect to the Internet. The machine or virtual machine must be used for node operation purposes only. +- Install firewalls. Keep the open ports minimal and whitelist the maintenance and operator IP addresses. Be careful when opening the SSH, RPC, or debug ports. For CNs and PNs, the p2p port should be restricted to an explicit list of peer CN and PN IPs. Even if the p2p stack has a vulnerability the attack opportunity is effectively blocked or restricted to the known nodes. +- Cloud security. When the node is operating on cloud virtual machines, properly manage the cloud accounts (e.g. AWS IAM roles) according to the cloud provider's best practices. The cloud accounts may not have access to SSH, but they can copy the disk contents or open a serial console. + +## Key security + +There are two major cryptographic keys managed by a node. + +- node key or p2p key: A 32-byte secp256k1 ECDSA private key. It's used in the p2p rlpx communication as well as signing the blocks. +- BLS node key: A 32-byte BLS12-381 private key. It's used to sign the RANDAO field in the blocks. + +Because the signing must happen automatically unattended, those keys have to be stored on the disk or entered via the command line. At this point, node security is critical in protecting the keys from theft. + +In the future, the nodes could support storing the keys in an external provider such as key management systems (KMS) or hardware security modules (HSM). Note that node security is still important even with these key management mechanisms. The keys cannot be copied but a compromised node can command signing malicious payload. + +On top of key theft, key loss is also a risk to manage. It is recommended to backup the node keys in an encrypted keystore file, and preserve in an offline storage. + From 08c36c81eb9c1c5b6f1e5c365ae5a798d29b5348 Mon Sep 17 00:00:00 2001 From: "ollie.j" Date: Tue, 30 Apr 2024 16:32:02 +0900 Subject: [PATCH 2/3] Polish --- docs/nodes/core-cell/securing-nodes.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/docs/nodes/core-cell/securing-nodes.md b/docs/nodes/core-cell/securing-nodes.md index 6a8d6b3df8..0ec1285e7a 100644 --- a/docs/nodes/core-cell/securing-nodes.md +++ b/docs/nodes/core-cell/securing-nodes.md @@ -3,7 +3,7 @@ Node security is a critical aspect of a secure blockchain network. Depending on the type of node, the operator needs to pay attention to security. - Consensus Node (CN): CNs are responsible for proposing and validating new blocks. A compromised CN can create malicious blocks or disrupt the blockchain. Certainly, the misbehaviour of a few nodes is blocked by the BFT consensus. However, they can still cause bad blocks or round changes that degrade the stability of the network. Therefore, core cell operators should maintain their nodes responsibly. -- Proxy Node (PN): PNs communicates with nodes on the Internet on behalf of CNs. While a PN does not sign blocks by itself, a security breach of a PN can damage the network. Its p2p key can be used to connect to the CN's restrictive network. A compromised PN can also neutralise the transaction filtering such as the spam filter. +- Proxy Node (PN): PNs communicate with nodes on the Internet on behalf of CNs. While a PN does not sign blocks by itself, a security breach of a PN can damage the network. Its p2p key can be used to connect to the CN's restrictive network. A compromised PN can also neutralise the transaction filtering such as the spam filter. - Endpoint Node (EN): ENs provide public access to the network for the applications. While an EN has no authority to manipulate the blocks, a security breach of an EN can pose trust issues. A compromised EN can serve false information including block data and account states. It can drop or censor incoming transactions if the app is directly connected to the EN. ## Node security @@ -11,21 +11,20 @@ Node security is a critical aspect of a secure blockchain network. Depending on Follow the security best practices whenever possible. To list a few: - Keep the operating systems and installed software up-to-date. -- SSH security. Disable remote root login, disable password login, and prefer public-key authentication. -- Nodes should be run on a dedicated machine. To reduce the risk of malware via supply chain attacks, refrain from installing other software, especially the ones that connect to the Internet. The machine or virtual machine must be used for node operation purposes only. +- Enhance SSH security by disabling remote root login, switching off password-based login, and opting for public-key authentication. +- Always operate nodes on dedicated machines. To reduce the risk of malware via supply chain attacks, refrain from installing other software, especially the ones that connect to the Internet. The machine or virtual machine must be used for node operation purposes only. - Install firewalls. Keep the open ports minimal and whitelist the maintenance and operator IP addresses. Be careful when opening the SSH, RPC, or debug ports. For CNs and PNs, the p2p port should be restricted to an explicit list of peer CN and PN IPs. Even if the p2p stack has a vulnerability the attack opportunity is effectively blocked or restricted to the known nodes. -- Cloud security. When the node is operating on cloud virtual machines, properly manage the cloud accounts (e.g. AWS IAM roles) according to the cloud provider's best practices. The cloud accounts may not have access to SSH, but they can copy the disk contents or open a serial console. +- Prioritize cloud security. When the node is operating on cloud virtual machines, properly manage the cloud accounts (e.g. AWS IAM roles) according to the cloud provider's best practices. The cloud accounts may not have access to SSH, but they can copy the disk contents or open a serial console. ## Key security There are two major cryptographic keys managed by a node. -- node key or p2p key: A 32-byte secp256k1 ECDSA private key. It's used in the p2p rlpx communication as well as signing the blocks. +- Node key or p2p key: A 32-byte secp256k1 ECDSA private key. It's used in the p2p rlpx communication as well as signing the blocks. - BLS node key: A 32-byte BLS12-381 private key. It's used to sign the RANDAO field in the blocks. Because the signing must happen automatically unattended, those keys have to be stored on the disk or entered via the command line. At this point, node security is critical in protecting the keys from theft. -In the future, the nodes could support storing the keys in an external provider such as key management systems (KMS) or hardware security modules (HSM). Note that node security is still important even with these key management mechanisms. The keys cannot be copied but a compromised node can command signing malicious payload. - +In the future, the nodes could support storing the keys in an external provider such as key management systems (KMS) or hardware security modules (HSM). Note that node security is still important even with these key management mechanisms. Although the keys cannot be copied, a compromised node can still initiate the signing of malicious payloads. On top of key theft, key loss is also a risk to manage. It is recommended to backup the node keys in an encrypted keystore file, and preserve in an offline storage. From b32850c2566cf8772ece8c0319361bcc7689f664 Mon Sep 17 00:00:00 2001 From: "ollie.j" Date: Tue, 30 Apr 2024 16:34:34 +0900 Subject: [PATCH 3/3] Refer node-security in the sidebar --- docs/nodes/core-cell/{securing-nodes.md => node-security.md} | 4 ++-- sidebars.js | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) rename docs/nodes/core-cell/{securing-nodes.md => node-security.md} (98%) diff --git a/docs/nodes/core-cell/securing-nodes.md b/docs/nodes/core-cell/node-security.md similarity index 98% rename from docs/nodes/core-cell/securing-nodes.md rename to docs/nodes/core-cell/node-security.md index 0ec1285e7a..7363c123e2 100644 --- a/docs/nodes/core-cell/securing-nodes.md +++ b/docs/nodes/core-cell/node-security.md @@ -1,4 +1,4 @@ -# Securing nodes +# Node Security Node security is a critical aspect of a secure blockchain network. Depending on the type of node, the operator needs to pay attention to security. @@ -6,7 +6,7 @@ Node security is a critical aspect of a secure blockchain network. Depending on - Proxy Node (PN): PNs communicate with nodes on the Internet on behalf of CNs. While a PN does not sign blocks by itself, a security breach of a PN can damage the network. Its p2p key can be used to connect to the CN's restrictive network. A compromised PN can also neutralise the transaction filtering such as the spam filter. - Endpoint Node (EN): ENs provide public access to the network for the applications. While an EN has no authority to manipulate the blocks, a security breach of an EN can pose trust issues. A compromised EN can serve false information including block data and account states. It can drop or censor incoming transactions if the app is directly connected to the EN. -## Node security +## Operation security Follow the security best practices whenever possible. To list a few: diff --git a/sidebars.js b/sidebars.js index 6ab2b429a8..76674153ac 100644 --- a/sidebars.js +++ b/sidebars.js @@ -335,7 +335,8 @@ const sidebars = { ], }, 'nodes/core-cell/monitoring-setup', - 'nodes/core-cell/h-a-setup', + 'nodes/core-cell/h-a-setup', + 'nodes/core-cell/node-security', ], }, {