Our Security Policy

All servers, services and databases owned, managed and hosted by blockNXT adhere to the following security policies. These policies are defined and maintained by the operator (  support@blocknxt.com )

  1. Servers and Infrastructure are listed in the company inventory and configuration management database with clear details on the name, location, purpose and tied back to customer who and for which purpose the server is being hosted for

  2. We consume dedicated servers with preferred hosting vendors ( Webnx, OVH, Equinix and a few other private players ) and cloud servers from AWS. A dedicated server or VPC level segregation is implemented for each node to avoid any exposure between environments.

  3. All servers are running the latest approved version of Ubuntu LTS or CentOS equivalent as specified by the current standards accessible in the internal Wiki.

  4. Servers are accessed with rsa keys only via bastion servers - and no password based authentication is allowed to servers. On creation of a new server the configuration script automatically limits the server to be accessed on port/xxx with UFW, Fail2Ban enabled.

  5. In case of private or dedicated hosted pools for customers, the servers are protected behind the authorized jump server ip addresses.

  6. Servers are updated and patched on a monthly schedule for security patches and every 3 months for feature patches. Servers are scanned with well known vulnerability management and port scanners, and remediated within 1 week of findings.

  7. Private keys used by applications are generated on an Air-gapped keygen server only and checked into a key vault hosted on the keygen server which is also backed up to a secure offline vault hardware.

  8. For proof of stake protocols, we use additional scripts and services that will auto transfer the reward balance to a distinct wallet every epoch. We recommend and support the separation of staking, withdrawal authorities to limit exposure on medium and larger stake accounts.

  9. Data deletion and decommissioning guidelines are retained as required when cancelling server subscriptions or exiting dedicated server environments. A 3 pass disk wipe is done to remove all info before servers are released

  10. All automation / scripts are peer reviewed, approved and deployed to our private repo before it can be consumed on our servers. Where possible we prefer the deployment of custom built binaries instead of using generic ones.