How To secure Aerospike database servers

Knowledge Base Operating
1

The Aerospike Knowledge Base has moved to https://support.aerospike.com. Content on https://discuss.aerospike.com is being migrated to either https://support.aerospike.com or https://docs.aerospike.com. Maintenance on articles stored in this repository ceased on December 31st 2022 and this article may be stale. If you have any questions, please do not hesitate to raise a case via https://support.aerospike.com.

How To secure Aerospike database servers

Context

When using Aerospike with externally routable IP addresses - public IPs - it is extremely important to secure access to Aerospike so that only approved client applications can have access.

Method

In order to secure Aerospike, the following steps should be taken:

  1. If running the Enterprise Edition, enable Aerospike security. Refer to the Security Guide documentation for details. This includes enabling username-password authentication with access control and TLS transport encryption. TLS encryption can be performed with server-side-only authentication (client authenticating to ensure it is connecting to the correct server), or mutual-authentication (the server also receives client certificates and authenticates them against a certificate authority). These steps should provide sufficient authentication to ensure a targeted or MITM attack will not expose the data.
  2. Block off access to Aerospike servers from sources other than approved client applications. Since Aerospike is a backend database only specific applications need access to, this should be secured with a firewall. The below explains common ways to firewall Aerospike off from other sources.
  3. Be sure to block off the info port using either your security groups in AWS or a firewall/iptables if on baremetal H/W - default 3003 (Aerospike dedicated INFO command port from the external access). Although this port is automatically disabled when enabling security, it is good practice to still close off access to that port.

Securing the Aerospike cluster intra node communication ports

Secure Aerospike heartbeat and fabric ports so that only other Aerospike servers can access them. In AWS, this can be done by creating a security group with the relevant rules and assigning that security group to all Aerospike server nodes. On bare-metal hardware, either a H/W firewall can be used, or iptables rules may be added.

Assuming the fabric and heartbeat ports are 3001 and 3002, the following rules must be created to ensure Aerospike can function correctly:

  • INCOMING: from:AEROSPIKE_SERVERS:ANY toPort:3001 ALLOW
  • INCOMING: from:AEROSPIKE_SERVERS:ANY toPort:3002 ALLOW
  • OUTGOING: fromPort:ANY to:AEROSPIKE_SERVERS:3001 ALLOW
  • OUTGOING: fromPort:ANY to:AEROSPIKE_SERVERS:3002 ALLOW

There is no need for any other application/server to communicate with Aerospike on these ports and therefore all other communication for those ports should be blocked off.

Securing the Aerospike client access port

Aerospike and client applications in AWS
  1. Create a security group for Aerospike servers (example name aerospike_server)
  2. Create a security group for Aerospike client applications (example name aerospike_client)
  3. Within the aerospike_server security group, create a rule allowing the service port access to VMs within the aerospike_client group. An example rule would look as follows: ALLOW INCOMING FROM: aerospike_client_security_group:ANY TO_PORT:3000
  4. Within the aerospike_client security group, allow aerospike_server outgoing connection to the service port. An example rule would look as follows: ALLOW OUTGOING FROM_PORT:ANY TO:aerospike_server_security_group:3000
  5. Assign the aerospike_client security group to the client application VMs
  6. Assign the aerospike_server security group to the Aerospike server VMs
  7. Ensure there are no other security group assigned to the Aerospike server, which would allow a more permissive access to the service port. Should these exist, remove the more permissive rules accordingly.

Following the above actions, only the client applications within the aerospike_client security group will have access to the Aerospike servers (VMs with the aerospike_server security group).

Aerospike in AWS with client applications elsewhere
  1. Create a security group for Aerospike servers (example name aerospike_server)
  2. Within the aerospike_server security group, create a rule allowing the service port access to the client application IPs/ranges. An example rule would look as follows: ALLOW INCOMING FROM:client.application.ip.address:ANY TO_PORT:3000
  3. Assign the aerospike_server security group to all aerospike servers
  4. Remove any permissive rules in any assigned security groups that allowed open access to the service port in Aerospike.
Aerospike on bare-metal

If using Aerospike on bare-metal H/W, two options exist for securing Aerospike access:

  1. Using a H/W firewall to only allow client application IPs to connect to the service port is preferrable. Unfortunately net_conntrack has its limitations, and using iptables may introduce latencies or packet drops in a high throughput (TPS) system.
  2. Should using a H/W firewall not be an option, iptables rules may still be implemented, noting the above warning. The rules woud simply allow access to the service port only to IPs/ranges from which the client applications are coming.
XDR

The above rules can be easily adjusted to allow for XDR to function accordingly. XDR ships data from a source cluster to one or more destination clusters the same way a client would write data into one or more clusters. With that in mind, for XDR to function properly:

  1. The aerospike_server example security group rules must be assigned to the destination cluster (destination cluster being the ‘server’ for XDR shipping)
  2. The aerospike_client example security group rules must be assigned to the source cluster (source cluster being the ‘client’ for XDR shipping)

If using firewalls other than AWS security groups, the relevant rules also apply in the same way: treat the source cluster as a client and the destination cluster as a server for the purpose of firewall rule creation.

Info port

The info port (for issuing info commands through telnet) is configured through the info stanza and has its port typically configured to 3003. The easiest way to close off this port is to remove the following stanza from aerospike.conf if present.

 info {
                port 3003
        }

When this stanza is removed the info port will be closed and issuing info command via telnet through it will not be possible.

Notes

Keywords

FIREWALL AWS IPTABLES AEROSPIKE SECURITY

Timestamp

September 2020