This shouldn’t be news to you, but people are trying to hack your phone, your laptop, your application server and yes, even your database server. To rephrase it as a corollary of Murphy’s Law:

Anything than can be hacked will inevitably be turned into a bitcoin miner

That Aerospike isn’t as ubiquitous as MySQL does not insulate its users from being hacked – all software has vulnerabilities. The most recent example for a potential exploit of Aerospike was CVE-2020-13151, which is addressed by Aerospike Database 5.1.

The intention of this blog post is to remind you to periodically stop and think about how you’ve secured your Aerospike cluster.

Securing the Aerospike Ports

Like with any database, access to open ports on your Aerospike nodes should only be available to your applications and monitoring system. It is bad practice to leave these ports open to just any IP address on the internet. If you do so, there’s a decent chance you’ll be getting hacking attempts through them.

A good starting point is the knowledge base article on How To secure Aerospike database servers. If you are unfamiliar with the ports on your Aerospike database, you should read the Network Configuration section of the operations manual.

Securing UDFs

User-Defined Functions are a mechanism for extending the functionality of the database, though it comes with a performance cost, when compared to native functionality. Whenever possible, a UDF should be migrated to the native operations that can be performed on the Aerospike data types.

It is useful to keep track of new developer features, through The Aerospike Standup, the announcements in the discussion forum, and the release notes. Almost every quarterly release of the database includes new developer features, potentially making your current UDFs obsolete.

UDFs also pose an attack vector, as was discussed in the July 30th blog post accompanying Aerospike Database 5.1: Security Enhancements including HashiCorp Vault Integration. Therefore, if you are not using UDFs, you should disable them. Disabling UDFs is controlled by setting the configuration parameter disable-udf-execution, which was added to versions 4.5.3 through 5.1.0.

Aerospike Enterprise Edition users who make use of UDFs should enable-security. The data-admin privilege should only be granted to trusted admin users, while applications should be limited to no more than the read-write-udf privilege.  Admin users should inspect UDF modules ahead of registering them, ensuring that no malicious code is uploaded into the Aerospike cluster.

Aerospike Community Editions users who make use of UDFs must restrict access to the cluster to trusted applications, as described above.