1. Home
  2. Docs
  3. Chainlink Node Setup
  4. Chainlink Node Security
  5. Node Security Requirements

Node Security Requirements

Best Security and Operating Practices

The following information provides a set of best security and operating practices that node operators can utilize to enhance the security and reliability of their infrastructure.

Restricting Access    

To run a Chainlink node, the Operator UI port does not need to be open on the internet for it to correctly function. Due to this, we recommend restricting access to all of the services required over the internet.

Minimum Requirements:

  • SSH (port 22 or changed from the default) is open, and access to the node is granted via SSH tunnelling. This is done typically by adding -L 6688:localhost:6688 to your SSH command.
  • Access to the Ethereum client that the Chainlink node uses is restricted to solely the Chainlink node. This includes ports 8545 and 8546, but excludes 30303 for P2P traffic.

Recommended:

  • The use of a VPN restricts access to only those who are signed into the VPN in order to access internal resources. For example, this can be achieved by using something like OpenVPN Access Server.
  • With the use of the VPN, all traffic between Chainlink nodes and Ethereum clients is routed internally rather than over the internet. For example, all servers are placed in an internal subnet range such as 10.0.0.0/16 and use these IP addresses for communicating.

Failover Capabilities    

To ensure there is very minimal downtime, failover capabilities are required on both the Chainlink and Ethereum clients so that if any one server fails, the service is still online.

Minimum Requirements:

  • Chainlink nodes are using a PostgreSQL database that are not on the same servers as the Chainlink nodes. (See Remote DB Setup Below)
  • At least two Chainlink nodes are running at any one time, with both of them pointing to the same database to ensure failover if one fails.

Ethereum-specific:

  • Ethereum client websocket connectivity is fronted by a load balancer, used by the Chainlink nodes. Here is an example on how to set up a load balancer.
    • If a VPN and internal routing is configured, SSL is not needed but still recommended, as all traffic is purely internal.
    • If both Ethereum and Chainlink nodes are public facing without a VPN, SSL is required to ensure that no communication between both can be intercepted.

Set the Remote DATABASE_URL Config    

If you want to use your Chainlink node with a remote PostgreSQL database, see the Connecting to a Remote Database page at this point. Use the example below to configure your DATABASE_URL setting in your environment file.

{External Link} Medium.com Tutorial Postgresql Remote Install

You can also use Cloud Launcher to set up PostgreSQL on Compute Engine with just a few clicks.

Gcloud > Marketplace > Database > 

Possible Postgresql Database Management Applications available on gCloud Marketplace.

Connecting a MySQL client from Compute Engine

https://cloud.google.com/sql/docs/mysql/connect-compute-engine

Connecting to a Remote Database

Chainlink Official Documentation: https://docs.chain.link/docs/connecting-to-a-remote-database

Obtain Information About Your Database 

In order to connect to a remote database, you will need to obtain information about the database and server. Take note of the database’s:

  • Server or IP
  • Port
  • Username
  • Password
  • Database name

The user must be the owner of the desired database. On first run, the migrations will create the tables necessary for the Chainlink node.

Set Your DATABASE_URL Environment Variable    

Below is an example for setting the DATABASE_URL environment variable:

DATABASE_URL=postgresql://$USERNAME:$PASSWORD@$SERVER:$PORT/$DATABASE

You will need to change the following placeholders to their real values:

  • $USERNAME: The database username (must be owner)
  • $PASSWORD: The user’s password
  • $SERVER: The server name or IP address of the database server
  • $PORT: The port that the database is listening on
  • $DATABASE: The database to use for the Chainlink node

Disaster Recovery    

Problems occur and when they do, the right processes need to be in-place to ensure that as little downtime as possible occurs. The main impediment to incurring large amounts of downtime in the context of Chainlink node operators is a fully corrupted Ethereum node that requires a re-sync.

Due to the challenge of recovering an Ethereum client, we recommend:

  • Daily snapshots of the Ethereum chain on a separate server than what the Chainlink node is connected to.
  • An Ethereum client start-up process that pulls down the latest template of the chain and syncs it to the latest height.

With this process in-place, the elapsed time of full disaster is kept to a minimum.

Was this article helpful to you? Yes 1 No

How can we help?

Leave a Reply

Your email address will not be published. Required fields are marked *