Thoughts on Security Best Practices for Factom ANO

Nodes running on the Factom network generally fall into three categories — Federated Nodes, which actually acknowledge and order entries and transactions in Factom, Audit Nodes, which duplicate and audit the work done by the Federated Nodes and are always ready to replace a Federated Node that might go offline, and Follower Nodes, with which the outside requests to go on-chain can be forwarded to a Federated Node.

Authority Nodes are the set of Federated Nodes and Audit Nodes, both of which may receive rewards generated by the system.

Ø Some main security issues

HashQuark has been working collaboratively with SlowMist to help secure Factom ANO validation nodes and its smooth deployment, and here are some main security issues we are trying to address:

- DDoS attacks to Authority Nodes

- Intrusion attacks to Validator Nodes

- Software/hardware shutdown concerning Authority Nodes

- Offline signature scheme for coinbase address and node efficiency

Ø The recommended architecture

Each Authority Node Operator (ANO) is currently running two nodes, as is shown in the figure above.

Given that Asia now remains an uncharted region for Factom ANO deployment, we recommend that more ANO can be deployed in Asia to ensure a more decentralized Factom network.

Ø Recommendations to Address DDoS Attacks

It is advised that the Authority Nodes should be run in the internal network and that the Follower Nodes deployed to synchronize blocks and verify transactions. Keep the IP addresses for the Follower Nodes private to defend them against DDoS attacks.

Deploy the same Master Authority Node and Standby Authority Node for hot standby, and this backup node will be activated once the Master Validator Node fails. With the Standby Node, the Federated Node will be easily performing the brain swap while it needs to be updated so that the node might not be perceived as going offline.

Also, a node log monitoring platform shall be in place for data collection, analysis, and visualization, keeping track of the key parameters of all node servers including CPU load, disk I/O, network I/O, and the process number.

Ø Good Practices to Keep Authority Nodes against Intrusions

Make sure the host is deployed with a single service, and start the node-related process alone. Avoid using the host for multiple purposes.

Prevent the private Follower Nodes from being scanned or located through the entire network, and modify the synchronization port 8108 to the maximum number of ports 80, 443 or 22 on the entire network. This may make it much more costly for each possible attack.

Disable other non-relevant service ports, open the required ones only, and execute strict security rules on AWS or Google Cloud. Note that this is required for both the cloud server and the operating system firewall.

Change the default 22 port for SSH. Configure SSH to allow login using the encrypted key only, disable login with password, and make sure the SSH port is only accessible to our operations and maintenance IP.

With enough budget, the advanced HIDS (Host-based Intrusion Detection System) is recommended to cope with server attacks. Also, the OSSEC open source project can be the best practice to go for.

Ø How to Avoid Software/Hardware Unexpected Shutdowns

- An off-site server room is required for the purpose of remote disaster recovery.

- Standby redundancy is needed for power supply at the server room.

- Standby redundancy is needed for key hardware with high losses.

• Make sure each Authority Node has both Master and Standby running on it.

Ø Offline signature scheme

Upon the first creating of node information and the key, the node owner shall compile serveridentity using the source code, and create the private keys and fullidentity.sh in an off-line environment before copying the key and performing the document in a safe online environment. Kindly note that Level 4 will be of the highest level.

Once the coinbase address and node efficiency need to be set up or updated, the node owner shall compile factom-identity-cli using the source code, and create the script in an off-line environment before copying and performing it in a safe online environment.

Ø Details about Configuration

- Before the Authority Nodes are perceived as part of Factom’s official Docker Swarm, the node owner shall download the certificate from the Factom GitHub, add it to /etc/docker/daemon.json, and boot Docker service using a non-root account, in case that the server rights might be accessed via the Docker.

- The ports below need to be opened for the Authority Nodes:

Open TCP/UDP port 2376 only to 52.48.130.243 & 18.203.51.247 for secure Docker encrypted communication with Docker Swarm Master.

Open TCP/UDP port 2222 to 52.48.130.243 & 18.203.51.247 to allow communications between Swarm and filebeat container.

Open TCP port 8108 to the Follower Nodes with dedicated MainSpecialPeers

Open TCP port 8088 for RPC to 52.48.130.243 & 18.203.51.247 for debugging

Open TCP port 8090 for Control Panel to 52.48.130.243 & 18.203.51.247 for the monitor

- The ports below need to be opened for the Follower Nodes:

Open 8108 to sync blocks;

Ensure that document factomd.conf and certificate downloaded from the Factom GitHub and the mirroring from Docker hub are fairly secure;

Open port 8090 to nodes offering RPC while adding TLS certificate and password

Allow access to Control Panel 8090 only via VPN in the internal network, and set readonly for ControlPanelSetting