Skip to content

BaerChain Super node security architecture

weidong edited this page Apr 9, 2020 · 3 revisions

BaerChain Super node security architecture

Super Node Hardware Configuration Requirements

  • In order to ensure the normal operation of the super node, Will use the following three servers.

    1. MainNode server: Ensure that transaction data communicates with other nodes.(Must be configured)
    
    2. BackupNode server: When an exception occurs in the public server, quickly switch to the standby server to communicate with other nodes. (Choose whether to configure)
    
    3. QueryNode server: Provides a server to externally query data using the RPC interface.(Recommended configuration)
    

MainNode require at least:

  • CPU: 64 Core
  • Disk: 1024G SSD
  • RAM:1024GB
  • bandwidth: 10 Gigabit

QueryNode server at least:

  • CPU: 8 Core
  • RAM:16GB
  • bandwidth: 10 Gigabit

Super node security target

  • Protect the outbound server from normal communication and operation
  • Enhance the overall anti-attack capability of the initial main network
  • Protect node security

Super node needs attention

  • DDoS the initial state of the main network
  • RPC abuse
  • Communication failure

Super node core design

  • Multiple jump nodes (small node traffic forwarding, large node high protection)
  • Multi-link high availability

Super node core defense

  • The block node recommends closing the RPC. If you need to open it, confuse the port and set up high protection and other protection.
  • Prevent the server from scanning the high-defense network and modify the port 30303 (the same as the RPC 8081) to the maximum number of ports 80, 443 or 22 on the entire network. This can effectively increase the attacker's positioning cost.

Super node total architecture

  • In order to cope with possible DDoS attacks, the node should prepare multiple servers. After the attack arrives, it can communicate with the standby server at any time to ensure that the main network starts smoothly and continues to be out of the block. First, each node should have at least one public server, one standby server, and a query server. The IP of the public server can be publicized so that the transaction data and the main network can communicate normally. The IP of the standby server only informs the current super node and does not disclose it to avoid simultaneous DDoS attacks. If the IP of the public server is known by the attacker (for example, scanning all IPv4 addresses of the entire network) and encounters DDoS attacks, the nodes cannot communicate normally. At this time, you can switch to the standby outbound server to connect to the virtual intranet to ensure 21 super nodes. Uninterrupted normal communication.

Super node design description

  • Public server (publicly available in the community node list) In the absence of an attack, the peripheral node communicates through the public server IP that is published.
  • Standby server (communication node shared only with other trusted super nodes) When an attacker attacks a public server through a public node list, causing the public server to be unavailable, it can communicate through the alternate server. (Private nodes can be scanned by the entire network, so it is not completely secure)
  • Query server The node where the RPC is located is completely isolated from the super node and the defense is set up to ensure that the attack on the RPC by the external network cannot affect the super node.

Super node security hardening scheme

  • RPC security Block RPC. If it is not necessary, it is recommended to disable RPC access.
  • Turn on SSL If you really need to provide RPC services externally, it is recommended to use nginx for reverse proxy and add HTTPS.
  • Turn on logging Start the node incoming logging parameters and record the necessary RPC request logs.
  • Non-root boot brcd It is recommended to compile with the same environment as the super node. After the compilation is complete, copy the executable file and related files to the super node server. Create a normal user account and use it to start the node, avoiding the use of root and reducing the risk.

other

  • It is strongly recommended to collect, store, and analyze related important logs, including: complete communication logs of RPC and P2P ports, host login logs, system logs of hosts, and running logs of node-related programs.
  • If a mature cloud service provider is used, their consoles have a number of threat intelligence related modules that can be used as a reference for timely detection of anomalies.

Clone this wiki locally