Scanning RDS with Nessus

April 17, 2019 Kent Blackwell

Relational Database Services (RDS) offered by AWS can make hosting a DB much easier but present some new challenges when trying to perform automated benchmark or compliance scans. When it comes to the continuous monitoring requirement for FedRAMP, many of our clients run into issues when setting up their Nessus scanner. One of the most consistent reasons we hear is “I can’t scan RDS, there’s no actual host there, just a database in the cloud.” Indeed, this is true, if you scan your AWS subnet that holds the RDS instance endpoints you’ll return zero live hosts. However, not all is lost. Today we’ll review the steps needed to configure a Nessus policy that will run compliance benchmarks against an RDS database.

You’ll need two pieces of information before configuring the Nessus scan, the RDS endpoint URL or IP address and the master database username/password. The first piece can be found in your AWS console under RDS -> Databases -> Database_name. The second should be stored in a trusted password manager and hopefully not in an Excel sheet on your desktop.

 

blog1

 

With this information in-hand, head over to your Nessus management page and configure a new “Advanced Scan” policy.

The first thing we need to do is start stripping out the “vulnerability” scan part of the policy.  Under settings go to “Discovery” -> “Host Discovery” you want to DISABLE ping.  This is the number one issue we see with CSPs and their scans.  RDS instances won’t respond to an ICMP ping even if a security group that allows it has been attached to the instance. Because of this, Nessus will ping then skip over the IP by default when it doesn’t respond.   We’re not setting up a discovery scan, so disable this.

 

blog2

 

Next, browse to the “Port Scanning” page right below the “Host Discovery” page and modify the port scan range.  Pull the default value of “default” and instead substitute whatever port your database is running on (default values are 3306 for MySQL, 1433 for MSSQL,  5432 for Postgres and 1521 for Oracle).  Again, this isn’t a vulnerability or discovery scan but a targeted compliance scan.  No need to let Nessus scan another several thousand ports that won’t be open.

 

blog3

 

Next, we’ll configure our scan credentials and benchmarks.  Add your username and password under the “Credentials” tab.

 

blog4

 

Under the “Compliance” tab, pick your benchmark.  Today we’ll be using the MySQL 5.7 CIS Level 1 but any of the CIS or STIG benchmarks will fire against RDS hosts.

 

blog5

 

And you’re done!  Save the policy and head over to create a new scan.  Nothing special on this side, simply pick your policy, add your endpoint addresses and scan away!

 

blog6

About the Author

Kent Blackwell

Kent Blackwell is a Manager with Schellman. Kent has over 9 years of experience serving clients in a multitude of industries, including the Department of Defense and top cloud service providers. In this position, Kent leads test efforts against client's web applications, networks, and employees through social engineering campaigns. Additionally Kent works with Schellman’s FedRAMP and PCI teams to ensure customer’s compliance needs are met in a secure and logical manner.

More Content by Kent Blackwell
Previous Article
7 Cloud Myths Debunked
7 Cloud Myths Debunked

Don't let misconceptions cast a shadow over your organization's ability to get the most out of t...

Next Article
Top Tips for Improving Board Communication Around Security
Top Tips for Improving Board Communication Around Security

A panel of security professionals discuss the top three tips for how CISOs and risk officers ...

×



Subscribe now
to receive content updates once a week

First Name
!
Success
Error - something went wrong!