Connecting Internal Vulnerability Scanning Solutions

 

The platform allows you, through it’s Connected Accounts page, to integrate a number of external scanning solutions.

NOTE: If your supported solution is already cloud-based and/or is Internet-facing then it’s even easier to link the platform to your chosen scanning solution. Just follow the https://rootshellsecurity.atlassian.net/wiki/spaces/PK/pages/1312292887 guide to get started.

Access Controls for the Platform

For those scanning solutions that are only internal to your infrastructure and organisation (i.e. the scanners are not exposed to the Internet) you will need to allow access from the platform application platform through your Internet firewall(s) or via a Reverse Proxy. This is necessary so that the platform can establish an inbound connection to your scanning solution(s) and retrieve scan results.

The platform uses a predetermined set of public IP addresses from which connections to any of your internal scanning platforms are established. Awareness of these platform public IP addresses allows you to define more granular Source-based access policies/rules on your Internet firewall(s) or other associated access controls.

The region in which your Platform is located will determine the public IP addresses of the Platform. Please refer to this article to check the region of your Platform

Please refer to this article for details of the Platform’s public IP addresses:

 

https://rootshellsecurity.atlassian.net/wiki/spaces/PK/pages/1383825409

Example Deployment - Platform access to Nessus via NAT/PAT Firewalls

Using Tenable’s Nessus Professional platform in the following example, if your organisation has deployed one or more ‘standalone’ Tenable Nessus Professional scanners across your internal network, and you are not using Tenable’s centralised scanner management platforms (e.g. Tenable.IO or Tenable.SC), each scanner must be exposed to the platform application via your primary Internet firewall(s) allowing the platform to retrieve scan results from each of the scanner’s API

image-20240313-130300.png

This example assumes the Tenable Nessus Professional Scanner is using the default management port of TCP-8834. If you are using alternative ports, please adjust firewall rules accordingly.

Assume the following scenario:

  1. An organisation has a single office network with a single Internet connection protected by a Firewall

  2. The organisation’s platform tenant is within the UK Region

  3. A Tenable Nessus Professional Scanner is deployed on the internal office network using a static private IP address of 192.168.100.1

  4. The organisation has an available/spare public IP address of a.b.c.d and this will be used for the Tenable Nessus Professional Scanner

  5. On the firewall, a NAT Rule and an Access Rule will be needed to permit access from the Platform:

    1. A NAT Rule will be required to map the available public IP address of a.b.c.d to the scanner’s private IP address of 192.168.100.1

    2. An Access Rule will be required to permit access from the platform to the public IP address mapped to the scanner (a.b.c.d) on TCP Port 8834

NAT Rule

External IP Address

Internal IP Address (Nessus)

External IP Address

Internal IP Address (Nessus)

a.b.c.d

192.168.100.1

Access Rule:

Adjust Source IP Addresses for the relevant region in which your platform tenant is hosted.

Source IP Addresses

Destination IP Address

Protocol & Port (Nessus)

Source IP Addresses

Destination IP Address

Protocol & Port (Nessus)

35.177.37.166

35.179.71.236

18.135.82.75

 

a.b.c.d

 

TCP-8834

Example Deployment - Platform access to Nessus via Reverse Proxies

Using Tenable’s Nessus Professional platform in the following example, if your organisation has deployed one or more ‘standalone’ Tenable Nessus Professional scanners across your internal network, and you are not using Tenable’s centralised scanner management platforms (e.g. Tenable.IO or Tenable.SC), each scanner must be accessible to the platform application via an interim Reverse Proxy allowing the platform to retrieve scan results from each of the scanner’s API

image-20240313-130500.png

Assume the following scenario:

  1. An organisation has a Reverse Proxy exposed to the Internet that governs access to HTTP/HTTPS web services and applications hosted on internal or DMZ network(s).

  2. The Reverse Proxy is accessible on a public IP address of a.b.c.d

  3. The organisation’s platform tenant is within the UK Region

  4. A single ‘standalone’ Tenable Nessus Professional Scanner is deployed on the internal office network using a static private IP address of 192.168.100.1

  5. The organisation has a valid public DNS A record for scanner1.mydomain.com that resolves to the IP address of the Reverse Proxy’s public IP address of a.b.c.d

  6. On the Reverse Proxy host, a site/forwarding rule will be required as follows:

    1. Accepts client-side SSL/TLS requests for https://scanner1.mydomain.com:8834.

    2. Establishes a server-side SSL/TLS connection to the internally-hosted Tenable Nessus Professional web application hosted at https://192.168.100.1:8834

Reverse Proxy Site Rule

Client-Side Request URL

Server-Side Request URL

Client-Side Request URL

Server-Side Request URL

 

Example Deployment - Platform access to Burpsuite Enterprise via NAT/PAT Firewalls

 

Information regarding the Burpsuite Enterprise Deployment Architecture can be found here

This following example assumes the Burpsuite Enterprise Manager is using the default web management port of TCP-8080. If you are using alternative ports, please adjust your firewall access rules and any address translation rules accordingly.

Assume the following scenario:

  1. An organisation has a single office network with a single Internet connection protected by a Firewall

  2. The organisation’s the platform tenant is within the UK Region

  3. A Burpsuite Enterprise solution is deployed on the internal office network with the Burpsuite Enterprise Manager assigned a static private IP address of 192.168.100.1.

  4. The organisation has an available/spare public IP address of a.b.c.d and this will be used for the Burpsuite Enterprise Manager

  5. On the firewall, a NAT Rule and an Access Rule will be needed to permit access from Prism:

    1. A NAT Rule will be required to map the available public IP address of a.b.c.d to the Manager’s private IP address of 192.168.100.1

    2. An Access Rule will be required to permit access from the platform to the public IP address mapped to the Manager (a.b.c.d) on TCP Port 8080

NAT Rule

External IP Address

Internal IP Address (Manager)

External IP Address

Internal IP Address (Manager)

a.b.c.d

192.168.100.1

Access Rule:

Source IP Addresses

Destination IP Address

Protocol & Port (Manager)

Source IP Addresses

Destination IP Address

Protocol & Port (Manager)

35.177.37.166

35.179.71.236

18.135.82.75

 

a.b.c.d

 

TCP-8080

Example Deployment - Platform access to Burpsuite Enterprise via Reverse Proxies

 

Information regarding the Burpsuite Enterprise Deployment Architecture can be found here

Assume the following scenario:

  1. An organisation has a Reverse Proxy exposed to the Internet that governs access to HTTP/HTTPS web services and applications hosted on internal or DMZ network(s).

  2. The organisation’s platform tenant is within the UK Region

  3. A Reverse Proxy is accessible on a public IP address of a.b.c.d

  4. A Burpsuite Enterprise solution is deployed on the internal office network. The Burpsuite Enterprise Manager is assigned a static private IP address of 192.168.100.1.

  5. The organisation has a valid public DNS A record for burpsuite.mydomain.com that resolves to the IP address of the Reverse Proxy’s public IP address of a.b.c.d

  6. On the Reverse Proxy host, a site/forwarding rule will be required as follows:

    1. Accepts client-side SSL/TLS requests for https://burpsuite.mydomain.com:8080

    2. Establishes a server-side SSL/TLS connection to the internally-hosted Burpsuite Enterprise web application hosted at https://192.168.100.1:8080

Reverse Proxy Site Rule

Client-Side Request URL

Server-Side Request URL

Client-Side Request URL

Server-Side Request URL

Example Deployment - Platform access to Rapid7 InsightVM Security Console via NAT/PAT Firewall

Using Rapid7’s InsightVM Security Console in the following example, if your organisation has deployed an InsightVM Security Console platform (with one or more InsightVM scan engines), the InsightVM Security Console API must be accessible to the Platform application to retrieve scan results from the InsightVM Security Console.

Assume the following scenario:

  1. An organisation has a single office network with a single Internet connection protected by a Firewall

  2. The organisation’s platform tenant is within the UK Region

  3. A InsightVM Security Console is deployed on the internal office network using a static private IP address of 192.168.100.1

  4. The organisation has an available/spare public IP address of a.b.c.d and this will be used for the InsightVM Security Console

  5. On the firewall, a NAT Rule and an Access Rule will be needed to permit access from the Platform:

    1. A NAT Rule will be required to map the available public IP address of a.b.c.d to the InsightVM Security Console’s private IP address of 192.168.100.1

    2. An Access Rule will be required to permit access from the platform to the public IP address mapped to the InsightVM Security Console (a.b.c.d) on TCP Port 3780

NAT Rule

External IP Address

Internal IP Address

(InsightVM Security Console)

External IP Address

Internal IP Address

(InsightVM Security Console)

a.b.c.d

192.168.100.1

Access Rule:

Source IP Addresses

Destination IP Address

Protocol & Port

(InsightVM Security Console)

Source IP Addresses

Destination IP Address

Protocol & Port

(InsightVM Security Console)

35.177.37.166

35.179.71.236

18.135.82.75

 

a.b.c.d

 

TCP-3780

Example Deployment - Platform access to Rapid7 InsightVM Security Console via Reverse Proxies

Using Rapid7’s InsightVM Security Console in the following example, if your organisation has deployed an InsightVM Security Console platform (with one or more InsightVM scan engines), the InsightVM Security Console API must be accessible to the platform application to retrieve scan results from the InsightVM Security Console. This can be achieved via an interim Reverse Proxy allowing the platform to retrieve scan results from the InsightVM Security Console API

 

 

Assume the following scenario:

  1. An organisation has a Reverse Proxy exposed to the Internet that governs access to HTTP/HTTPS web services and applications hosted on internal or DMZ network(s).

  2. The Reverse Proxy is accessible on a public IP address of a.b.c.d

  3. The organisation’s platform tenant is within the UK Region

  4. A InsightVM Security Console is deployed on the internal office network using a static private IP address of 192.168.100.1

  5. The organisation has a valid public DNS A record for r7console.mydomain.com that resolves to the IP address of the Reverse Proxy’s public IP (a.b.c.d )

  6. On the Reverse Proxy a site/forwarding rule will be required as follows:

    1. Accepts client-side SSL/TLS requests for https://r7console.mydomain.com:3780

    2. Establishes a server-side SSL/TLS connection to the internally-hosted InsightVM Security Console web application hosted at https://192.168.100.1:3780

Reverse Proxy Site Rule

Client-Side Request URL

Server-Side Request URL

Client-Side Request URL

Server-Side Request URL

https://r7console.mydomain.com:3780

https://192.168.100.1:3780