Skip to end of metadata
Go to start of metadata

This document details best practices to configure Security Groups in AWS for ClustrixDB. Using the default Security Group Firewall Settings provided by Amazon can get customers up and running quickly, but these settings do not provide the best database network security. Before you put critical data into your ClustrixDB or use it in production, Clustrix strongly recommends that you understand and implement the network security guidelines described here.

Designing an AWS Security Group for maximum security will minimize risk with the following strategies:

  • Lockdown network ports for intra-node communication
  • Limit external access to network ports for application access and administrative control

Configure a Locked Down Security Group 

Ports Required for ClustrixDB

This page summarizes the list of ports used by ClustrixDB. If using network security such as firewalls or security groups, the following network traffic must be allowed.

Internal Access Between ClustrixDB Nodes

These network ports are required for communication between ClustrixDB nodes. They must each be accessible by other nodes within the cluster.

ProtocolPortUseReason
TCP22SSHAdministration and upgrade
TCP, UDP2048Control PortClustrixDB specialized administrative tool
TCP, UDP2424 Nanny Portnanny - ClustrixDB process manager
TCP3306SQL

Database communication

TCP7888clxdbiDatabase interface for ClustrixGUI
TCP, UDP24378 - 24410MultiportClustrixDB internode communication

External Access

These network ports are used to access ClustrixDB externally from your applications and for cluster administration.

ProtocolPort                UseReason
TCP22SSHRemote management and cluster access   
TCP8080*HTTPClustrixGUI
TCP3306SQLDatabase access
TCP3581Health CheckHeartbeat monitor for cluster

*for root installs. Non-root installations will use port 80. 

Use a VPC

The security group configuration described in this page will secure your cluster whether it is deployed in EC2 or a VPC. However, there are some important security differences between EC2 and VPC to consider:

  • In EC2, the servers are connected to the AWS public network, directly accessible from the internet. Thus it is very important to properly configure your security group to only allow access to the correct ports from known sources. Using a VPC, the nodes are on a private network behind a gateway, isolated from the public network, thus much more secure.
  • When using a load balancer in EC2, it is open to the world. You can not control the traffic allowed to connect to the load balanced port with ACLs or a security group (see AWS docs on this). This makes the database ACLs the only security control to the DB access, which is a high-security risk. In a VPC, load balancers have full security groups giving full control over traffic allowed to connect. This is the main reason why we really recommend deploying ClustrixDB in a VPC and not in EC2. 
  • A VPC gives you more flexibility in your security settings with multiple subnets (front-end, back-end), network ACLs, security groups, internal and external load balancers.
  • A VPC allows you to use the ClustrixDB AMI with Enhanced Networking enabled.
For the security reasons above, we strongly recommend deploying ClustrixDB in a VPC.

Deploy within a Security Group

AWS EC2 Security Groups support securing these ports so they can only be accessed by members of the Security Group used by your ClustrixDB nodes. If you have successfully formed a ClustrixDB cluster in AWS you already have rules that refer to these ports in your Security Group, although they may not be restricted only to Security Group members.  

If you desire access to these ports for administrative or testing purposes, you can log into any of the database nodes with SSH first, then run commands that require access to any of these ports from there.

To secure these ports, simply replace your current Security Group rules that refer to the ports listed above with new rules that list the Security Group ID instead of a network range. The example below shows the steps to replace open rules for TCP port 2048 with self-referencing rules. Perform the same steps for each of the ports listed to complete the secure intra-node configuration.

In order to completely set up your security group, you will need to gather the following information: 

  • The security group ID for the group assigned to the nodes ( you can find your security group id in the security group page in the EC2 portal). For the purpose of the example below, we will use security group ID: sg-0d36b666
  • We recommend dedicating the security group to the ClustrixDB nodes. No other resource should be assigned to this security group. This allows for the group's self-referencing rules to only apply to ClustrixDB nodes. 
  • Whether multiport is enabled. If enabled, you need to know the number of nodes and number of cores per node. For the purpose of the example below, we will use 3 nodes, with 8 cores each. 
  • The application servers source IPs. For the purpose of the example below, we will use private IP range  10.0.0.1/24 and EC2 public IPs 54.144.155.202 and 54.144.155.211 (ie there is a private VPC subnet dedicated for app servers, as well as 2 individual servers in public space EC2) 
  • The administrative client source IPs. For the purpose of the example below, the administrative client IP is 198.100.10.204 (a normal public IP, like your outgoing office IP) 
  • The Load balancer's source security group.

To learn how to create and manage your security groups in either EC2 or VPC, visit the documentation for Amazon EC2 Security Groups for Linux Instances

Secure back-end TCP and UDP Ports for intra-node communication

ClustrixDB nodes use a series of ports for node-to-node communication. We call them the back-end ports as they only need to be opened between each node of the cluster. Back-end communication can be isolated to a dedicated network subnet, although not required. 

Back-end ports are listed above. For all nodes in the cluster, these ports need to be allowed access from all the other cluster nodes. Since the security group is dedicated to the nodes of the cluster, we can allow access to all resources assigned to that security group. This is described as a self-referencing rule: for group A, allow access to port X when source is group A. This allows for a much simpler security group configuration. 

Secure front-end TCP ports for Application and Administrative Access

There are 3 TCP network ports that are used to access your ClustrixDB from your database application and for day-to-day administration: 

  • TCP Port 80 is used to access the ClustrixGUI Administration UI.
  • TCP Port 22 is used to access the command line for advanced management and configuration tasks.
  • TCP Port 3306 is used to access the ClustrixDB using the MySQL protocol, typically from your front-end application and by your Database Administrators for development and management purposes.

In a typical secure configuration, you will limit access to TCP Ports 80 and 22 to the network CIDR range that maps to the public IPs for your administrative clients (typically exposed through your firewall), and you will limit access to TCP Port 3306 to your administrative client CIDR range and also to the range of IPs used by your application servers (if they are outside your firewall).

Secure ClustrixDB Intra-Node TCP and UDP Ports

This example will walk you through security one of the ports used for ClustrixDB intra-node communication, namely TCP port 2048. Securing the other ports used for intra-node communication is done in a similar fashion.

For this example, assume that the Security Group rules used for your ClustrixDB AWS instances look similar to the following before modifying them for a secure configuration. Note that in this example, all of the required ports are open to all networks.The goal of this step is to limit this access. 

Step 1 - Identify the Security Group 

Find the Security Group ID of the Security Group being used by your ClustrixDB instances. In the EC2 Management Console, navigate to NETWORK & SECURITY -> Security Groups, and select the Security Group from the list. You will find the Security Group ID on the Details tab, as shown below.

Step 2 - Create a custom TCP Rule

Select the Inbound tab to view the Security Group rules, and delete the current rule referring to TCP port 2048 by clicking the Delete Action. The Action will now change to Undelete as shown below.

 

     

Step 3 - Specify a self-referencing rule

Be sure Custom TCP rule is selected for "Create a new rule:", and specify the new self-referencing rule by specifying the Security Group ID for the Source, and 2048 for the port range. Then add it by clicking Add Rule as shown below.

 

Step 4 - Apply Rule Changes

Your rule changes will now be reflected as in the highlighted rows below. Finally, click Apply Rule Changes to update the Security Group.

 

The Security Group Inbound rules will now look like the following.

 

If you have running EC2 instances that use the update Security Group, the changes will typically be applied to them within a few moments. There can be a momentary loss of connectivity between running instances when Security Group rules are changed, which may be noticeable within ClustrixGUI. 

Step 5 - Create more Custom Rules

Once you have completed the rule changes for TCP port 2048, continue to make the changes similarly for TCP ports 22, 80, 2424 and 24378 and for UDP ports 24378. Once you have made the changes for all of the intra-node communication ports, your Security Group rules will look similar to the following, with your Security Group ID substituted for the one in the example.

Limit ClustrixDB Application and Administrative Access

There are 3 TCP network ports that are used to access your ClustrixDB from your database application and for day-to-day administration: 80, 22, and 3306.

TCP Port 80 is used to access the ClustrixGUI Administration UI.

TCP Port 22 is used to access the command line for advanced management and configuration tasks.

TCP Port 3306 is used to access the ClustrixDB using the MySQL protocol, typically from your front-end application and by your Database Administrators for development and management purposes.

In a typical secure configuration, you will limit access to TCP Ports 80 and 22 to the network CIDR range that maps to the public IPs for your administrative clients (typically exposed through your firewall), and you will limit access to TCP Port 3306 to your administrative client CIDR range and also to the range of IPs used by your application servers (if they are outside your firewall).

Limit External Access to Your Administrative Clients and Application Servers

This example will walk you through locking down one of the ports used for administrative and application access, namely TCP port 3306, the MySQL protocol port. Locking down the other ports used for administrative access is done in a similar fashion. We chose port 3306 for the example to demonstrate locking down ports to both administrative clients and application servers. For the other ports, you will typically only need to lock down access to your administrative clients.

Assume that the Security Group rules used for your ClustrixDB AWS instances look similar to what was configured in the last example. Notice that all of the ports required for external access are open to all networks.

For this example, assume that your administrative clients are NAT'd to a single public IP defined by 66.211.103.164/32, and that your application servers all reside on a single public network defined by 99.114.137.0/27. You will substitute the appropriate network ranges for your administrative clients and application servers. Using the procedures described in the previous example, we will replace the rule for TCP port 3306 with 2 new rules to expose the ClustrixDB nodes only to clients on the two specified networks.

Step 1 Delete default configuration

Select the Inbound tab to view the Security Group rules, and delete the current rule referring to TCP port 3306 by clicking the Delete Action. The Action will now change to Undelete as shown below.

Step 2 Create a new MySQL Rule

Be sure MySQL is selected for "Create a new rule:", and specify the new rule by specifying the first network range for the Source, and 3306 for the port range. Then add it by clicking Add Rule as shown below.

Your TCP rules will now look like the following.

Step 3 Configure additional network ranges for MySQL

Be sure MySQL is selected for "Create a new rule:", and specify the new rule by specifying the second network range for the Source, and 3306 for the port range. Then add it by clicking Add Rule, after which your rules will look like the following. 

Step 4 - Apply Rule Changes

Finally, click Apply Rule Changes to commit the new rules into the Security Group.

Step 5 - Review Final Security Group Configuration

In the previous section, ports 80, and 22 have already been opened to the Security Group. Now we need to add rules for HTTP and SSH with the CIDR range for your administrative clients, in this example assumed to be 66.211.103.164/32. When you are done, you will have Security Group rules that look similar to the following, with the changed rules highlighted.

 

 

Now that you have created your security group, you can continue with ClustrixDB AWS Installation Guide.  

Questions? Please see Clustrix support offerings.

  • No labels