Polkadot wave card chain: verify node security and usability aspects

In this article, I will discuss two topics in terms of verifying the security and usability of a node. I know that the tips presented here only cover the tip of the iceberg of the "security and usability" of POS authentication nodes. However, I found them to be useful for providing minimal security and usability for your test cases.

Protection verification node

Exposing blockchain or cryptographic services over the Internet can attract attackers to try to attack your system. So it is best to be prepared to take any steps to reduce the risk of being compromised.

While running my polladat verification node, I observed a large number of attackers trying to force my ssh password.

• Popular Science | Read the Bitcoin Schnorr signature in one article
• Plasma: Ethereum chain scalability framework combat part 1
• Technical Guide | Web3.js is based on the Ethereum Javascript API

The first thing I did was to install SSHGuard. So what is SSHGuard? As Andrew Schartzmeyer described in his blog:

Sshguard monitors the server's logging activity. When the log shows that someone is attacking, sshguard will take appropriate measures to prevent the attack.

In our case, we use it to protect our SSH port. The installation process is very simple. By default, it will start to check /var/log/auth.log on the Ubuntu server (which records SSH attacks, etc.) .

Run the following command on the Ubuntu server to install SSHGuard, which will use iptables as the system firewall. Iptables is a program for configuring and managing the kernel netfilter module.

Apt-get update apt-get install -y sshguard

When sshguard blocks any malicious user (by blocking its IP address), it uses the sshguard chain. Prepare the sshguard chain and ensure that the chain is triggered when a new incoming connection is detected, and finally restart sshguard.

In the example below, sshguard starts blocking an attempt after four failed login attempts, and gradually increases the blocking time if the attacker continues to attack.

To see the blocked IP address, run the following command:

With this simple setup, you can ensure that your sensible sshd port is protected from stupid attackers trying to hack into your system.

Polkadot verifies the entry port of the node

Which port is required by the polkadot validator. Verify that the node requires three inbound ports:

1. 30333 is used for the port of the Peer2Peer protocol;
2. 9933 for RPC;
3. 9944 is used for WebSocket (WS) communication;

Ideally, the authentication node will only expose these three ports and the sshd port that allows you to log in to the system.

Polkadot verifies the outbound port of the node

Some thoughts on the protection and verification of the outbound port of the program. As described in the security.stackexchange thread

Https://security.stackexchange.com/questions/24310/why-block-outgoing-network-traffic-with-a-firewall

Incoming traffic blocking only blocks unsolicited traffic from reaching your internal network. However, if you receive malware on your internal computer (by running an untrusted executable or exploiting a vulnerability), you will still be attacked.

Blocking outgoing traffic helps limit corruption by preventing malware from connecting to command and control servers or clearing data.

Therefore, in the production verifier node, this may be considered critical, but be aware of:

In a highly secure environment, the idea of ​​outbound filtering seems to be a natural process. However, this is a very large and complicated matter.

To illustrate this, I ran a quick exercise by analyzing the communication mode of the verification node.

To this end, I used the excellent tool Wire Shark.

“Wireshark is the world's most important and widely used network protocol analyzer. It allows you to understand what is happening on your network at a micro level and is a fact of many commercial and non-profit corporations, government agencies and educational institutions. (usually legal) standards."

In order to get the WireShark input file, I have to run the tcpdump command on my validator node…

And load it into Wire Shark. As shown in the screenshot below. Verify that the node uses a large number of outbound ports.

This is expected to take into account that the Validator will use the Peer2Peer communication scheme to communicate with 45 authentication nodes in other networks.

To protect the outbound port, it is beyond the scope of this article to consider how the underlying P2P library works (consider protection test nodes).

However, it is worth mentioning that the payment card industry data security standard only requires organizations that provide credit cards (also some sort of verifier) ​​to do so.

PCI DSS Requirements 1.2.1 focuses on the organization of policies and procedures that limit traffic to the inbound and outbound traffic that is absolutely necessary for business purposes. PCI Requirements 1.2.1 stipulates that “limit inbound and outbound traffic to the traffic required by the cardholder data environment and explicitly deny all other traffic.” The goal of PCI Requirement 1.2.1 is to limit traffic to only necessary. , the required protocol, port or service, and provide business reasons for the required ELE.

So what are the minimum requirements for running the Polkadot Validator node in a production environment.

So let's switch to the second topic of this article.

Improve the availability of the verification node

I am running the Validator POC-2 node in 7×24 mode and trying to minimize the cuts (because my node is not available).

Despite this, the process will receive a termination signal from time to time, causing the process to be started.

In order to automate this task and minimize the reduction probability, I wrote a small cron job script that was executed every minute.

The script to be triggered (monitorValidator.sh) will check if the polladot process is not running

To install crontab, execute the following command

If the verifier process is still running, this will result in a check every 60 seconds or it will restart.

In the public report, one problem is to "create and run a node cluster service for polkadot" (https://github.com/w3f/web3 collaboration/issues/43) in order to coordinate the collaboration of teams working in Web3 space. The availability issue will be resolved.

Cosmos is more mature than Polkadot and it covers a number of topics, including:

• Provides a sentinel node architecture, an infrastructure example that mitigates DDOS on the GAIA/COSMOS Hub Network Verifier node.

"To alleviate this problem, multiple distributed nodes (sentinel nodes) are deployed in the cloud environment. It is difficult to affect the verifier nodes due to the ease of expansion. New sentinel nodes can appear during DDOS attacks and can use gossip The network integrates them into the transaction flow."

• Tendermint HSM Key Management System (KMS)

"A lightweight service designed to be deployed with GAIAD services (ideally on a separate physical host) that provides the following features:

• High availability access to the verification program signing key;
• Prevent double signatures even when the verification process is affected;
• The hardware security module stores the verification program key, which can be used after the host is damaged."

That's the way it is today, at least on the surface of the tip of the verification program, you have completed the first step to ensure and improve usability.

In the context of security and usability, it will be interesting to see how polkadot evolves over time.

This article reprinted from the public number: blockchain research laboratory – Haina College will focus on: blockchain technology, product community, economic model and other comprehensive knowledge system output.

Welcome to contact the author: csschan1120

We will continue to update Blocking; if you have any questions or suggestions, please contact us!