Using Terraform to set up a VPC with vulnerability scanners (Tenable Nessus & Rapid7 Nexpose)

Intro & Backstory

Maybe you’ve heard the good news? Amazon is no longer requiring submission of their pentesting form to test your own cloud-based apps on services like EC2 and RDS. The wait is over!

No really, sometimes you would have to wait a week before getting approval. So woot, the wait is over!

Story Time

Back in November last year, I accidentally racked up a $1,500 AWS bill playing around with Terraform and Splunk. How did that happen you ask? Well not having proper billing alarms and closing the laptop before entering right value to the following prompt would do it:

terraform destroy
Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.
Enter a value:

It didn’t help that I was traveling so off my usual habit of logging into the console. I ultimately ended up calling Amazon and begging for mercy.

Anywho, I’m back with a new post showing you how to provision a VPC with the following requirements:

  • Public and Private subnet
  • Internet Gateway to connect the VPC to the internet and NAT Gateway included so host in private subnet can also connect to the internet
  • Linux target sits in private subnet
  • Scanners sit in the public subnet (not that it needs to be said but please don’t do this in your PROD environment)
  • One scanner must be Tenable’s Nessus and the other needed to be Rapid7’s Nexpose.

Heads up: I’m not going to compare the scan results of these two scanners at the end of this; I just wanted to create a VPC with scanners ready-to-go as practice. I’ll let whoever is thinking about procuring these products for their environment make the final call on that.

Go time

You’ll need to get the following things before beginning:

  • Nessus Home License Key and rpm file
  • Nexpose Community 1-Year License Key and bin file
  • Terraform (You’ll need the proper level of IAM access to create resources)
  • Clone handy-dandy Terraform scripts from repo here
  • AWS Key Pair — We’ll create this first

Here is quick breakdown of the directory I’m working out of:

├── files
│   ├── Nessus-8.2.3-es7.x86_64.rpm
│   └── Rapid7Setup-Linux64.bin
├── keys
│   └── testing-key.pem
├── main.tf
└── variables.tf

First — the AWS Key

To access our scanners via SSH and for the scanners to be able to scan our internal target via credentialed scan (for more accurate scan results), we’ll need an SSH key. This key will be applied to all the instances during creation.

In the console under EC2, select Key Pairs, and Create Key Pair.

When you create this key pair, the private key will then be downloaded to your computer.

I called my key testing-key which is reflected in the variables.tf file. I moved this key in the keys folder and the executables in the files folder.

Preparation

Switching over to the variables.tf, I updated this file with my IP Address (in /32 notation), ensured my key name matched, region was set and I was using the latest RHEL 7 AMI ID.

This file is super helpful to make a change in one place versus going line by line in the main.tf file. If this file looks good, onward to the next commands.

Ensure you are in same directory has the main.tf and variable.tf files.

If you haven’t already, please read each of these files line by line before launching as generating these resources (Elastic IP, 3 EC2s, NAT Gateway, etc) will cost a little bit of money.

# prepare directory
terraform init
# update the configuration files in canonical format and style
terraform fmt
# provides a preview of the resources that will be created
terraform plan

Launch

When you are ready, run the following:

# create resources
terraform apply

It can take up to 15 minutes (gotta transfer 800+ MB Nexpose file) to provision everything but when it is complete, you should be able to access to interfaces of both scanners.

# nessus 
https://<aws_public_ip_address:8834>
# nexpose
https://<aws_public_ip_address:3780>

When you access Nessus, it will prompt you to create an admin user with a password. Next, you’ll paste in the activation key and let it complete the set up.

Side Note: It was nice being able to use the same activation key over and over when rebuilding the VPC. Nexpose requires, at least from what I experienced, you to get another key or at least deactivate the first one (I didn’t spend much time figuring this out though) if previously used.

The Nexpose build was a little different. When setting up Nexpose, I added the username/password as a flag during the install command (Line 216 main.tf). This is the same username and password you’ll need to log into Nexpose when it’s ready.

After you’ve logged in, you’ll be prompted to enter an activation key and you are free to roam around the GUI.

Scanning

As I stated earlier, I’m not going to compare the scan results of these tools. I will say that during the first scan of the linux target, Nexpose crashed less than a minute after the scan launch since it ran out of memory. But to be fair, I was using a t3.medium which is definitely lower than the recommendation (4 CPUs & 8 GBs RAM minimum) for both of these. However, Nessus on the same instance type, completed the scan no issues. This may be an important resource consideration to some so I thought I’d point that out.

When scanning, use the Class A (10.0.2.x ) of the target host (get this from the console) and upload the private key, that was downloaded earlier, when setting up public key authentication for the scan. No password is needed. When the scan configuration is complete, launch and wait for results to appear.

Also, I don’t recommend scan this hosts with both scanners at the same time.

FIN

When I was done testing, I ran:

terraform destroy

And this time, actually wrote yes when prompted. I also logged into the console to verify that no resources existed.

Terraform has a good community and lots of great documentation so you’re in good company if just beginning. I hope this has been helpful to someone. Thanks for reading!

// Small rant

While Tenable has kept their AMI somewhat up to date (2018.03 Amazon AMI — a year old?), Rapid7, what are you doing? Why are you offering your product on Ubuntu 14 when it reaches end-of-life next month? You even recommend at least Ubuntu 16 on your website.

This seems crazy to me that a vulnerability scanner is sitting on an OS that has basically reached EOL.

I understand these are mostly used for evaluation purposes but maybe it’s time for an update no? Just curious. By the way, thank you for the dark theme built natively into your product. #darkthemeforlife