AWS RDS is a managed relational database service that allows users to rapidly set up fully operational instances on the cloud and use them as data sources within applications. The AWS RDS is one of the more popular services that AWS provides and has been a favourite amongst customers for having a wider range of Engine types to pick from.
The default configurations of RDS instances do not enforce encrypted client connections which allows unsecured clients to connect leaving the door open for man-in-the-middle type of attacks. This instructional guide takes you through the steps that you can take to minimise the risk associated with this setting and even fix the misconfiguration in the case of certain RDS engine types.
We recently published an article that shows how you can detect this misconfiguration within your environment. Once you have identified the vulnerable instance of RDS, you can follow the steps below to update to a more secure configuration.
Note: These steps are not valid for MySQL and MariaDB RDS engine types as the configuration to make network connections secure is uneditable.
Click on the database in your list of RDS instances. If you have a database cluster, click on the “Regional Cluster” DB identifier
Click on the “Configuration” tab in the bottom pane and note the DB Parameter group. This will be “DB cluster parameter group” in the case of an RDS cluster. We will need to create a Parameter group for the same Engine type where the values are altered.
In the left pane of the console, select Parameter groups
Click on Create a parameter group and select the parameter group family and type. The type will be based on whether the DB parameter group was for a cluster or not. Make the same selection here.
Once the Parameter group is created, click on it and search for the following configurations based on the type of the parameter group.
Select the parameter and click on the “Edit Parameters” button. Change the value in the drop down as per the table above.
Click on “Save changes”. Now that the parameter group is created, it needs to be assigned to the standalone DB or the cluster.
Select the cluster name or the database instance (in case standalone) and click on Modify. In the “Additional Configuration” section, under the Database Options”, you can now choose the newly created Parameter group name. Click on “Continue” at the bottom of the page
In the next page you can either select this change to be applied immediately or schedule it based on the maintenance window.
If you are using the MySQL or MariaDB RDS engine (not Aurora) then the value for require_secure_transport is not editable.
As there is no way to currently modify the require_secure_transport option for the MySQL and MariaDB engine types, it is recommended that all clients connecting to these database instances must use secure connections. This is the default in all clients, however, this can easily be changed via command line or in code and you need to inspect the clients to ensure that such insecure connections are not being made.
It is also a good security practice to keep the RDS inside a VPC away from the public Internet and to practice basic security hygiene like having strong passwords, keeping snapshots private and enabling encryption at rest for snapshots and the database itself.
When an AWS RDS instance is created, an appropriate parameter group is applied to the DB instance. These parameter groups contain settings for the database at the engine layer. During our research we discovered that the setting that enforces transport layer security is disabled on all database engine types with the ability to modify it, also being absent for certain types of databases.
Since AWS RDS cannot enforce clients to connect using a secure connection, it is possible for insecure clients to make a connection which could be attacked and data could be stolen or modified in transit. In this post we saw how we can enable the security feature on some database engine types. In the case of MySQL and MariaDB there is no way to change the option at all and you must resort to ensuring the client always makes secure connections and other security best practises like making sure the RDS is not exposed to the Internet.
