A recent report from one of our indexers revealed that many indexers expose their subql-coordinator ports publicly despite our guidance not to. This may lead to a bad actor changing your service, so we urge every indexer review their security controls immediately.
Who are affected?
Indexers with the following might have controller account at risk.
- Expose subql-coordinator’s api port (8000 in the default settings) to the public internet
- Run subquerynetwork/indexer-coordinator <= v1.3.6
Be on the lookout for any malicious transactions from Metamask for your old controller account. A bad actor could insert malicious source code into the indexer admin app to ask you to sign a malicous transaction
How to fix?
- Immediately apply firewall rules to secure coordinator ports (see guidance here). Only the proxy’s HTTP & P2P port should be exposed publicly. SSH should be secured and not exposed publicly
- Upgrade subquerynetwork/indexer-coordinator to >= v1.3.8 (instructions here)
- Scan all the
.ssh/authorized_keys
of all your accounts, (/root
and other/home/*
). Delete any malicious or suspicious records, if you are not sure, delete the file, then restart - Assign a new controller account in indexer admin - Instructions to create and activate a new controller account. Withdraw the all tokens from your previous controller as well
Best practices
- Only expose the following ports publicly.
443
for nginx → indexer-proxy for HTTPS indexers,80
for indexer-proxy for non-HTTPS indexers7370
for indexer-proxy’s p2p
- subql-coordinator’s api port (
8000 / TCP
in the default settings): This port should be configured to only allow access from your own IP address or via your secured VPN as it is used byindexer_coordinator
. - Run SubQuery services under non-root user
- Consider using selinux to further enhance the security
Other external resources
- You may want to consider using the Indexer toolkit developed by web3cdn. (it is not official application, please use at your own risk)