AWS Builder Center

Builder Center

Performing internal Vulnerability Assessment on a private EC2 instance using Tenable Nessus in AWS

Performing internal Vulnerability Assessment on a private EC2 instance using Tenable Nessus in AWS

This guide demonstrates how to deploy and scan a target EC2 instance inside a private subnet using Tenable Nessus. It covers instance configuration, application deployment using user data, secure access via AWS Systems Manager, hostname resolution, and credentialed scanning setup. By the end of this lab, you will have a working internal scanning setup that reflects common cloud security practices in AWS environments.

J.R. De Guzman

AWS Authorized Instructor (AAI) | Former Network Engineer | Cybsecurity Support Engineer

Introduction

In the previous parts of this series, I walked through installing Tenable Nessus Professional on Amazon Linux 2023 and securely migrating the scanner from a public subnet to a private subnet using an AMI.
With the scanner now running in a private environment, the next step is to simulate a real-world scenario by introducing a target host within the same VPC and performing a vulnerability assessment.
This article is part of a multi-part series demonstrating how to deploy, secure, and operate Tenable Nessus within AWS using private subnet architectures and AWS-native access patterns.
This article focuses on setting up a target EC2 instance, deploying a sample web application, configuring hostname-based scanning, and running a credentialed Nessus scan. The goal is to demonstrate how vulnerability scanning can be performed securely within private subnets using AWS Systems Manager for access, without exposing resources to the public internet.

Prerequisites

Before proceeding, ensure that the environment from the previous articles is already in place.
This article builds on the following:
At this point, you should already have:
  • A VPC already configured
  • A public subnet with an Internet Gateway and NAT Gateway
  • A private subnet with outbound routing through the NAT Gateway
  • A Nessus EC2 instance running in the private subnet
  • Access to the Nessus instance through AWS Systems Manager

Architecture Overview

Internal AWS security scanning with Nessus
This lab uses a simple internal scanning design inside one VPC.
Example layout:
  • VPC CIDR: 10.0.0.0/16
  • Public Subnet (us-east-1a): 10.0.0.0/24
  • Private Subnet (us-east-1b): 10.0.1.0/24
The public subnet hosts the NAT Gateway.
The private subnet hosts:
  • the Nessus scanner
  • the target EC2 instance
The private subnet route table should include:
1
0.0.0.0/0 → NAT Gateway
This allows outbound access for package installation and updates without exposing the target host directly to the internet.

Step 1 - Confirm the Network Placement

Before launching the target host, verify that:
  • Your Nessus instance is already running in the private subnet
  • Your target EC2 will also be launched in the private subnet
  • Your NAT Gateway is in the public subnet
  • Your private route table sends outbound traffic to the NAT Gateway
This keeps the target host internal while still allowing outbound package downloads during instance initialization.

Step 2 - Launch the target EC2 Instance

Navigate to:
EC2 > Instances > Launch Instance
Configure the instance as follows:
  • Name: target-ec2
  • AMI: Amazon Linux 2023
  • Instance Type: t3.micro
  • VPC: Same VPC as the Nessus instance
  • Subnet: Private subnet (10.0.1.0/24)
  • Auto-assign Public IP: Disabled

Security group configuration

  • Create security group
    • Security group name:
1
target-ec2-sg
Configure the inbound rules.
Add SSH inbound rule:
  • Type: SSH
  • Source type:Custom
  • Source: Nessus security group
Add HTTP inbound rule:
  • Type: HTTP
  • Source type:Custom
  • Source: Nessus security group
This ensures that only the Nessus instance can reach the target host over SSH and HTTP.

Configure storage

Use a small general-purpose root volume for the lab:
  • Volume type: gp3
  • Size: 8 GiB
  • Delete on termination: Enabled
This is sufficient for Amazon Linux 2023, Apache, PHP, and the sample web application.

IAM Profile

If you want to connect to the target host through Session Manager, attach an IAM role that includes:
1
AmazonSSMManagedInstanceCore

User data

Under Advanced details > User data, paste the following:
1
2
3
4
5
6
7
#!/bin/bash
sudo dnf install -y httpd wget php-fpm php-mysqli php-json php php-devel unzip
sudo dnf install -y httpd mysql
sudo wget https://aws-tc-largeobjects.s3.us-west-2.amazonaws.com/CUR-TF-100-RESTRT-1/267-lab-NF-build-vpc-web-server/s3/lab-app.zip
sudo unzip lab-app.zip -d /var/www/html/
sudo systemctl start httpd
sudo systemctl enable httpd
This installs Apache, PHP, and deploys the sample web application automatically at launch.
After reviewing the configuration, launch the instance.

Step 3 - Connect to the target host

Since the target host is in a private subnet and has no public IP, connect through AWS Systems Manager.
In the AWS Management Console:
  • Go to EC2 > Instances
  • Select the target EC2 instance
  • Click Connect
  • Choose the Session Manager tab
  • Click Connect
This opens a browser-based shell session to the target host.

Step 4 - Configure the Hostname

Once connected to the target host, set a custom hostname.
Run:
1
sudo hostnamectl set-hostname target1demo-ec2.internal
Verify it:
1
hostname
Expected output:
1
target1demo-ec2.internal
Using a hostname instead of only a private IP makes the lab more realistic and easier to manage.

Step 5 - Verify the web application deployment

Check that Apache is running:
1
sudo systemctl status httpd
Check that the web files were extracted:
1
ls /var/www/html
You should see the application files under /var/www/html.
If you want to verify locally from the instance itself, run:
1
curl http://localhost
If Apache and the web application were deployed successfully, you should see HTML output.

Step 6 - Access the web application from your local machine

Because the target host is in a private subnet, you cannot open the website directly using its private IP from your laptop.
Instead, use AWS Systems Manager port forwarding.
From your local machine, run:
1
2
3
4
aws ssm start-session `
--target <INSTANCE-ID_OF_TARGET_EC2_INSTANCE>`
--document-name AWS-StartPortForwardingSession `
--parameters "portNumber=80,localPortNumber=8080"
Then open your browser and go to:
1
http://localhost:8080
Accessing a private EC2 web app via SSM port forwarding
Why localhost:8080?
In this command:
  • portNumber=80 refers to port 80 on the target EC2 instance
  • localPortNumber=8080 refers to port 8080 on your local machine
This means your browser connects to localhost:8080, and Systems Manager forwards that traffic to port 80 on the target host.
Port 8080 is commonly used as a local alternative to port 80 because it avoids local privilege or port conflict issues.

Step 7 - Configure hostname resolution on the Nessus instance

Now connect to the Nessus EC2 instance and update its /etc/hosts file so it can resolve the target hostname.
Open the file:
1
sudo vi /etc/hosts
Add an entry like this:
1
10.0.1.161 target1demo-ec2.internal
Save the file.
  • Press ESC in the keyboard
  • Type :wq
  • Hit Enter
This allows Nessus to scan the target using the hostname instead of only the IP address.

Step 8 - Access the Nessus UI

From your local machine, start the Nessus port-forwarding session:
1
2
3
4
5
aws ssm start-session `
--region us-east-1 `
--target <INSTANCE-ID_OF_NESSUS_INSTANCE> `
--document-name AWS-StartPortForwardingSession `
--parameters "portNumber=8834,localPortNumber=8834"
Then open:
1
https://localhost:8834
Log in using your existing Nessus credentials.

Step 9 - Create and Configure a Basic Network Scan

In the Nessus web interface:
  • Go to Scans
  • Click New Scan
  • Select Basic Network Scan

General Settings

Under Settings > Basic > General, configure:
  • Name: AWS-Target-Hostname-Scan
  • Targets: target1demo-ec2.internal

Report Configuration

Under Settings > Report, enable the following:
  • Hide results from plugins initiated as a dependency
  • Allow users to edit scan results
  • Designate hosts by their DNS name
  • Display hosts that respond to ping
  • Display unreachable hosts
These options improve report clarity and ensure hosts are identified by hostname instead of IP address.

Configure Credentials (Recommended)

To perform a credentialed scan, configure SSH access to the target instance.
Go to:
Credentials > SSH
Set the following:
  • Authentication method: password
  • Username: ec2-user
Prepare the Target Instance for Authentication
If password authentication has not yet been configured, perform the following steps on the target EC2 instance using AWS Systems Manager Session Manager:
Set a Password for ec2-user
1
sudo passwd ec2-user
Enable SSH Password Authentication
1
sudo vi /etc/ssh/sshd_config
Update the following line:
1
PasswordAuthentication yes
Save the file:
Press ESC > type :wq > press Enter
  1. Restart the SSH service
1
sudo systemctl restart sshd
Return to Nessus and complete the remaining fields:
  • Password (unsafe!): Enter the password you configured
  • Elevate privileges with: sudo
  • sudo user: root
  • sudo password: (leave blank)
Leave all other fields as default.
After completing the configuration:
  • Click Save
  • From the dropdown, select Launch

Step 10 - Review the Scan Results

After the scan completes, Nessus should identify findings such as:
  • Open ports such as 22 and 80
  • Apache HTTP Server
  • PHP-related components
  • Web application exposure
  • Missing patches
  • Service or configuration findings
The exact results will depend on the installed packages and plugin coverage available during the scan.

Scan results

Successful Nessus scan with identified vulnerabilities
OS identification result from Nessus scan

Monitoring

Monitoring EC2 instances during Nessus scanning through Amazon CloudWatch
This view shows real-time Amazon CloudWatch metrics for both the Nessus scanner and the target EC2 instance during the vulnerability scan. Key metrics such as CPU utilization, network traffic, and packet activity provide visibility into system behavior while the scan is running.
The observed spikes in network and packet metrics reflect active scanning activity initiated by Nessus, while CPU usage remains stable, indicating efficient resource utilization.
Monitoring these metrics helps ensure that the scanning activity does not negatively impact system performance and provides additional visibility into the overall health of the environment during security assessments.

Design Considerations and Alternatives

Private DNS vs /etc/hosts

For production environments:
  • Use Amazon Route 53 Private Hosted Zones
  • Avoid manual host file management

NAT Gateway vs VPC Endpoints

  • NAT Gateway enables outbound internet access
  • Consider VPC Endpoints to:
    • Reduce cost
    • Keep traffic within AWS network

Nessus vs Amazon Inspector

  • Nessus: deep, customizable scanning
  • Inspector: fully managed AWS-native service

Key Takeaways

  • Vulnerability scanning can be performed entirely within a private subnet without exposing instances to the internet
  • AWS Systems Manager enables secure access and port forwarding without requiring SSH or public IP addresses
  • Security groups can be used to restrict access between the scanner and target host
  • Hostname-based scanning requires proper local name resolution (e.g., /etc/hosts)
  • Credentialed scans provide deeper visibility, including installed packages and missing patches
  • Amazon Linux disables password-based SSH authentication by default, which impacts credentialed scan configuration
  • Informational findings such as hostname inconsistencies may appear in lab setups and do not affect scan accuracy
  • Amazon CloudWatch metrics help validate that scanning activity does not impact instance performance

Conclusion

In this article, we set up a target EC2 instance and performed a vulnerability scan using Tenable Nessus within a private AWS environment. By leveraging AWS Systems Manager, security groups, and internal networking, the entire workflow was completed without exposing any resources publicly.
This approach reflects a more secure and practical design for cloud environments, where scanning and assessment activities are performed internally. While this lab uses a simplified setup, the same principles can be applied to more complex architectures.
For Tenable customers deploying in AWS, this demonstrates how to integrate vulnerability scanning into a controlled and secure environment while maintaining visibility into system health and potential risks.
# cloud-security# cybersecurity# network-security# security-best-practices# application-security
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article