Tenable Nessus¶

Description¶

Tenable Nessus is a leading vulnerability scanner developed by Tenable, widely regarded as the gold standard for identifying security weaknesses across networks, systems, applications, and cloud environments. Nessus performs comprehensive scans to detect software flaws, missing patches, misconfigurations, default credentials, and insecure protocols that could be exploited by attackers.

Docker setup¶

Before starting the setup, make sure Docker is installed on your machine, as it will be used to deploy and run the Nessus container.

1. Create a working directory for Nessus:

   sudo mkdir nessus && cd nessus
   

2. Make the following Docker Compose YAML file:

   docker-compose.yml

   services:
       nessus:
           image: 'tenable/nessus:latest-oracle'
           volumes:
               - './nessus_data:/data'
               - '/var/run/docker.sock:/var/run/docker.sock'
           network_mode: "host"
           restart: always
           container_name: nessus
   

3. Deploy the container:

   sudo docker compose up -d
   

Application setup¶

1. Access the HTTPS web console via the host machine's LAN IP address: https://192.168.1.x:8834.

2. Wait for Nessus to initialize. Then, select which Nessus product you want to install:

   Essentials Professional Expert

   • Free vulnerability scanner for up to 16 IP addresses per scanner.
   • Same core scanning engine as paid versions.
   • Ideal for students, personal labs, and those evaluating vulnerability management solutions.
   • Community support and basic documentation.

   • Try for free
   • Unlimited asset scanning, advanced reporting, and professional support.
   • Suitable for security teams, consultants, and businesses needing regular assessments across many devices.
   • Includes features like extensive policy templates and integration support.

   • Try for free
   • Adds external attack surface scanning (e.g., domains, cloud infrastructure), domain monitoring, and advanced cloud configuration assessment.
   • Designed for enterprises with advanced security and compliance needs; offers clustering and large-scale automation capabilities.

3. Create a username and password that you will use to log in to Nessus.

4. Wait for Nessus to download and initialize the remaining plugins.

Basic vulnerability scan setup¶

Log in to Nessus. A new Welcome to Nessus page will appear, prompting you to launch a host discovery scan to identify what hosts on your network are available to scan.

1. In Targets, type in the gateway address of your local network followed by /24. Click Submit.

   Example: 192.168.1.1/24

   This will scan all the devices on your network.

   Gateway address

   To find the gateway address, enter this command in your Linux terminal:

   ip route | grep default
   

   It will be the first address (after default via).

2. Wait for the discovery scan to complete. Then, select the hosts you want to scan for vulnerabilities and click Run Scan.

   Nessus Essentials host limit

   The selected hosts count towards the 16 host limit on the Nessus Essentials license.

3. Now wait for the Basic Network Scan to complete. Once finished, click on the host with the most vulnerabilities and you will see a list of vulnerabilities ranked from Low to Critical severity. Some tests are marked as Info for 'informational'.

These are my scan results:

Basic scan results

Vulnerability analysis and remediation¶

Vulnerability A: Outdated Apache version¶

URL               : http://192.168.1.14:8749/
Installed version : 2.4.62
Fixed version     : 2.4.64

To see debug logs, please visit individual host

From the vulnerability details, it appeared there was an application using an outdated version of Apache. For this vulnerability, the attack vectors include HTTP response splitting and Server-Side Request Forgery (SSRF). To investigate this further, I checked what application was using TCP port 8749 on the host:

$ sudo ss -tulnp | grep :8749  

tcp   LISTEN 0      4096                       0.0.0.0:8749       0.0.0.0:*    users:(("docker-proxy",pid=5966,fd=7))
tcp   LISTEN 0      4096                          [::]:8749          [::]:*    users:(("docker-proxy",pid=5991,fd=7))

The port points to a Docker proxy, which means that there is a container using an outdated version of Apache. I ran the following command to find what container is serving data on port 8749:

$ sudo docker ps --format '{{.ID}} {{.Names}} {{.Ports}}' | grep 8749  

4e4ac50ae257 freshrss 0.0.0.0:8749->80/tcp, [::]:8749->80/tcp

The FreshRSS container was the culprit. Upon further research, I found out that the installed version (1.26.0) was behind the current version (1.27.1). I then updated the container and rescanned the host to confirm the remediation.

Vulnerability A rescan results

As expected, the vulnerability was remediated.

My vulnerability report:

Host IP: 192.168.1.14  
Time Detected: Nov. 15, 2025 @ 15:51  
Scan Policy: Basic Network Scan  
Vulnerability: Apache 2.4.x < 2.4.64 Multiple Vulnerabilities  
Description: The version of Apache httpd installed on the remote host is prior to  
2.4.64. It is, therefore, affected by multiple vulnerabilities as referenced in the  
2.4.64 advisory.  

Analysis: Outdated version of Apache detected listening on TCP port 8749 through a  
Docker proxy. Vulnerable Docker container found out to be 'freshrss'. The container  
was updated to latest version, remediating the vulnerability.

Status: CLOSED | TRUE POSITIVE | REMEDIATED

Vulnerability B: Outdated JQuery library¶

URL               : https://192.168.1.14:8384/vendor/jquery/jquery-2.2.2.js
Installed version : 2.2.2
Fixed version     : 3.5.0

To see debug logs, please visit individual host

This time, a JavaScript library called JQuery was detected as outdated and vulnerable to a XSS attack. This library is used by an application on port 8384.

I performed the same steps as the previous vulnerability to find the root cause:

$ sudo ss -tulnp | grep :8384  

tcp   LISTEN 0      4096                       0.0.0.0:8384       0.0.0.0:*    users:(("docker-proxy",pid=7338,fd=7))                                                                     
tcp   LISTEN 0      4096                          [::]:8384          [::]:*    users:(("docker-proxy",pid=7345,fd=7))

Again, the problem originated from a Docker container:

$ sudo docker ps --format '{{.ID}} {{.Names}} {{.Ports}}' | grep 8384  

3e08c688b427 syncthing 0.0.0.0:8384->8384/tcp, 0.0.0.0:21027->21027/udp, [::]:8384->8384/tcp, [::]:21027->21027/udp, 0.0.0.0:22000->22000/tcp, [::]:22000->22000/tcp, 0.0.0.0:22000->22000/udp, [::]:22000->22000/udp

After determining the Syncthing Docker container as the root cause, I manually updated it (referring to the latest version listed on its Docker Hub repository), and then rescanned the host to confirm the remediation.

Surprisingly, the same vulnerability was detected again, meaning the JQuery library was not updated. I tried a different approach, this time changing the Docker image repo from the LinuxServer.io one to the official one offered by Syncthing (syncthing/syncthing:latest), and deployed it as a brand new container.

The result was the same, so I did further research on the project's GitHub Issues page and came across this posting. It turns out that Syncthing has multiple outdated JavaScript libraries that need updating. Therefore, if I want this vulnerability to disappear, then all I can do is wait for the library to be updated, or use a different file synchronization tool.

All in all, the risk of this XSS vulnerability is only moderate, and only exploitable in specific attack scenarios requiring prior access. To mitigate this risk, I enabled HTTPS and set a complex password in the Syncthing web console.

My vulnerability report:

Host IP: 192.168.1.14  
Time Detected: Nov. 15, 2025 @ 15:51  
Scan Policy: Basic Network Scan  
Vulnerability: JQuery 1.2 < 3.5.0 Multiple XSS  
Description: According to the self-reported version in the script, the version of JQuery  
hosted on the remote web server is greater than or equal to 1.2 and prior to 3.5.0. It  
is, therefore, affected by multiple cross site scripting vulnerabilities.  

Analysis: Outdated version of JQuery detected, used by 'syncthing' Docker container  
listening on TCP port 8384 through a Docker proxy. The container was updated to the  
latest official version. Vulnerability still remains, but is negligible. Awaiting  
update of vulnerable JavaScript library 'jquery-2.2.2' -> 'jquery-3.5.0'.

Status: CLOSED | FALSE POSITIVE | AWAITING REMEDIATION

Vulnerability C: SMB Signing not required¶

The final notable vulnerability that was discovered on this host was related to SMB signing. SMB signing is important because it ensures the integrity and authenticity of the data exchanged over the SMB protocol between clients and servers. This is a crucial security feature to protect network communications and shared data from interception and tampering.

The remediation of this vulnerability involves enabling SMB signing on the Linux host's Samba share. I did this by adding two lines under the [global] section of the host's smb.conf file:

sudo nano /etc/samba/smb.conf

[global]
## smb signing
   client signing = mandatory
   server signing = mandatory

sudo systemctl restart smbd nmbd

After another scan, the result showed a successful remediation:

Vulnerability C rescan results

My vulnerability report:

Host IP: 192.168.1.14  
Time Detected: Nov. 15, 2025 @ 15:51  
Scan Policy: Basic Network Scan  
Vulnerability: SMB Signing not required  
Description: Signing is not required on the remote SMB server. An unauthenticated,  
remote attacker can exploit this to conduct man-in-the-middle attacks against the  
SMB server.  

Analysis: Mandatory SMB signing was detected as disabled on Linux Samba share.  
Samba configuration file was changed to require SMB signing from clients. The  
vulnerability was remediated.

Status: CLOSED | TRUE POSITIVE | REMEDIATED