[Support] jbreed - nessus


Recommended Posts

10 hours ago, chilled_penguin said:

Hi, so everything is working except i moved to traefik 2 and can*t get it working with it. Did you by any chance change your traefik as well?

Without the proxy i got it running. :/

Kind regards

 

I currently don't have an environment to test this and haven't used Nessus via a proxy before. 

 

Based on past posts here, it appears others have had it working. If there is something I can add to the Nessus container to make it easily configurable, then I'll happily add it. Just need some guidance on what is needed to get it working, or if I have the time I'll see about making a use case in my lab to test with it. I'll have to do some research on what changes are made to Nessus for doing this.

 

Link to comment
  • 4 weeks later...

Thank you for this docker.

I'm getting an error when I try to launch the GUI:

 

Your connection is not private

Attackers might be trying to steal your information from MyServerIP (for example, passwords, messages, or credit cards). Learn more

NET::ERR_CERT_INVALID

 

Is this a problem? I can't start it in Chrome, but if I use a different browser, I can override these warnings and get to the startup page...

 

Thanks.

Link to comment
1 minute ago, volcs0 said:

Thank you for this docker.

I'm getting an error when I try to launch the GUI:

 

Your connection is not private

Attackers might be trying to steal your information from MyServerIP (for example, passwords, messages, or credit cards). Learn more

NET::ERR_CERT_INVALID

 

Is this a problem? I can't start it in Chrome, but if I use a different browser, I can override these warnings and get to the startup page...

 

Thanks.

This is due to using a self signed certificate, which is generally the same issue when accessing the UnRaid login page.

 

To fix this you must create a local certificate authority, create a CSR, sign the certificate with the root CA, then upload it to the application. You would then need to install this root CA into your local machine you access these from, which if I recall Chrome uses the same CA store as we explorer although Firefox you have to import it into directly.

 

Most of the time you can simply bypass this by choosing I understand or something of that nature to continue to the page. This I believe is listed under an "advanced" button on the page  I'm unsure on which chrome settings would need to change to permit this, but I imagine there is likely a browser setting that allows you to accept the certificate if this isn't available. Not many people go through the hassle of setting up a local CA to get the green lock. 

Link to comment
  • 1 month later...

Hoping this is the right topic:

 

I'm having trouble installing greenbone. I can get to the webui but I can't log in. I have another docker on the main port so I changed GB's webui port. Does this template require the default port or is there something I'm missing? 

 

Link to comment
On 7/17/2020 at 8:25 AM, Chezro said:

Hoping this is the right topic:

 

I'm having trouble installing greenbone. I can get to the webui but I can't log in. I have another docker on the main port so I changed GB's webui port. Does this template require the default port or is there something I'm missing? 

 

Chezro, you can change the port mapping on either of the containers. 

 

For doing it here, modify host port 1 on the docker configuration page. This will map the port you set to the containers internal port 8843.

Link to comment
  • 3 weeks later...

Had this set up on 1 server and did a few scans, it worked great. Went to set it up on another server and the webgui will not connect on either server now. Any suggestions or advice on how I can remedy this? Here is a copy of the log file from one of the servers.

 

 

Setting user permissions...
Modifying ID for nobody...
Modifying ID for the users group...
Adding nameservers to /etc/resolv.conf...
Extracting packaged nessus debian package: Nessus 8.10.0...
Changing owner and group of configuration files...
Creating symbolic links...
Cleaning up...
Starting Nessus : .
[Mon Aug 3 22:34:47 2020][29.1][op=_qdb_map][name=services-udp.db][fd=-1][map_sz=38575]: complete
[Mon Aug 3 22:34:47 2020][29.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete
[Mon Aug 3 22:34:47 2020][29.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete
[Mon Aug 3 22:35:07 2020][29.1][op=qdb_sync][name=upgrades.db][fd=5][map_sz=0][file_size=55]: complete
[Mon Aug 3 22:35:08 2020][29.23][sched=100][pid=22][plugin=nessusd_www_server6.nbin][instr=0xb4ba] : Error: Could not find function 0xf00001af
call stack:
-----------
[0b4ba:Saucer::Client.request+67] call, addr(0xf00001af), -, # ???? () [C func]
[0d572:TelemetryService.submit+39] refcall, fp(1), string#629, # from: fp(1)
[0d509:TelemetryService.sendStartupTelemetry+136] call, addr(0x800007), -, # TelemetryService.submit()
[12c69:send_backend_starting_telemetry+5] refcall, fp(0), string#2935, # from: fp(0)
[12c2d:main+18] call, addr(0x12c64), -, # send_backend_starting_telemetry()
[2dd57:main+13298] call, addr(0x12c1b), -, # main()

[Mon Aug 3 22:35:09 2020][29.23][sched=100][pid=22][plugin=nessusd_www_server6.nbin][instr=0x2a039] : Invalid index for hash table
call stack:
-----------
[2a039:utils::parseResponse+45] larray, r#26, fp(2),
[0d575:TelemetryService.submit+42] call, addr(0x2a00c), -, # utils::parseResponse()
[0d509:TelemetryService.sendStartupTelemetry+136] call, addr(0x800007), -, # TelemetryService.submit()
[12c69:send_backend_starting_telemetry+5] refcall, fp(0), string#2935, # from: fp(0)
[12c2d:main+18] call, addr(0x12c64), -, # send_backend_starting_telemetry()
[2dd57:main+13298] call, addr(0x12c1b), -, # main()

[Mon Aug 3 22:35:09 2020][29.23][sched=100][pid=51][plugin=nessusd_www_server6.nbin][instr=0xd086] : Error: Could not find function 0xf000020c
call stack:
-----------
[0d086:Socket.accept+36] call, addr(0xf000020c), -, # ???? () [C func]
[07984:Mug::Connection.on_client+46] refcall, fp(2), string#692, # from: fp(2)
[217cc:!anon5+4] refcall, fp(-2), string#4816, # from: fp(-2)
[2dd58:main+13299] eop, -, -,

[Mon Aug 3 22:35:09 2020][29.23][sched=100][pid=52][plugin=nessusd_www_server6.nbin][instr=0xd086] : Error: Could not find function 0xf000020c
call stack:
-----------
[0d086:Socket.accept+36] call, addr(0xf000020c), -, # ???? () [C func]
[07984:Mug::Connection.on_client+46] refcall, fp(2), string#692, # from: fp(2)
[217cc:!anon5+4] refcall, fp(-2), string#4816, # from: fp(-2)
[2dd58:main+13299] eop, -, -,

[Mon Aug 3 22:35:09 2020][29.23][sched=100][pid=53][plugin=nessusd_www_server6.nbin][instr=0xd086] : Error: Could not find function 0xf000020c
call stack:
-----------
[0d086:Socket.accept+36] call, addr(0xf000020c), -, # ???? () [C func]
[07984:Mug::Connection.on_client+46] refcall, fp(2), string#692, # from: fp(2)
[217cc:!anon5+4] refcall, fp(-2), string#4816, # from: fp(-2)
[2dd58:main+13299] eop, -, -,

[Mon Aug 3 22:35:25 2020][29.1][op=qdb_sync][name=plugins-desc.db][fd=22][map_sz=0][file_size=178979610]: complete
[Mon Aug 3 22:35:25 2020][29.1][op=qdb_sync][name=plugins-code.db][fd=7][map_sz=0][file_size=2789806079]: complete
[Mon Aug 3 22:35:45 2020][29.1][op=_qdb_map_lowmem][name=plugins-code.db.15964941251616699263][fd=7][map_sz=0][file_size=2789806079]: complete
[Mon Aug 3 22:35:46 2020][29.1][op=_qdb_map_lowmem][name=plugins-desc.db.15964941451807749847][fd=19][map_sz=0][file_size=178979610]: complete

Link to comment
  • 6 months later...
Setting user permissions...
Modifying ID for nobody...
Modifying ID for the users group...
Adding nameservers to /etc/resolv.conf...
Extracting packaged nessus debian package: Nessus 8.10.0...
Changing owner and group of configuration files...
Creating symbolic links...
Cleaning up...
Starting Nessus : .
[Thu Feb 4 11:00:52 2021][30.1][op=_qdb_map][name=services-udp.db][fd=-1][map_sz=38575]: complete
[Thu Feb 4 11:00:52 2021][30.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete
[Thu Feb 4 11:00:52 2021][30.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete
[Thu Feb 4 11:00:52 2021][30.1][op=qdb_sync][name=upgrades.db][fd=5][map_sz=0][file_size=55]: complete
[Thu Feb 4 11:01:02 2021][30.23][sched=100][pid=53][plugin=nessusd_www_server6.nbin][instr=0xd779] : Error: Could not find function 0xf000020c

call stack:
-----------
[0d779:Socket.accept+36] call, addr(0xf000020c), -, # ???? () [C func]
[07bb2:Mug::Connection.on_client+46] refcall, fp(2), string#707, # from: fp(2)
[22d1e:!anon5+4] refcall, fp(-2), string#4934, # from: fp(-2)
[2eb54:main+10121] eop, -, -,

[Thu Feb 4 11:01:14 2021][30.1][op=qdb_sync][name=plugins-desc.db][fd=19][map_sz=0][file_size=187756524]: complete
[Thu Feb 4 11:01:14 2021][30.1][op=qdb_sync][name=plugins-code.db][fd=7][map_sz=0][file_size=2967368547]: complete
[Thu Feb 4 11:02:05 2021][30.1][op=_qdb_map_lowmem][name=plugins-code.db.16124364741952786213][fd=7][map_sz=0][file_size=2967368547]: complete
[Thu Feb 4 11:02:08 2021][30.1][op=_qdb_map_lowmem][name=plugins-desc.db.1612436525562718452][fd=19][map_sz=0][file_size=187756524]: complete

similar issue to above poster. I last ran this back in november and it worked fine, but now it fails to update plugins or run scans.

Link to comment
  • 1 month later...

Heya,

 

Is there any chance the container can be updated to use a more recent version of Nessus please, as the current version reports Vulnerabilities with itself (1 High, 2 Low).

I have been manually updating it myself, by downloading the deb file and running "dpkg -i <path_to_deb>" which seems to work, but would be useful to have it done by default.

 

Thanks.

Link to comment
On 4/2/2021 at 6:14 AM, timethrow said:

Heya,

 

Is there any chance the container can be updated to use a more recent version of Nessus please, as the current version reports Vulnerabilities with itself (1 High, 2 Low).

I have been manually updating it myself, by downloading the deb file and running "dpkg -i <path_to_deb>" which seems to work, but would be useful to have it done by default.

 

Thanks.

 

Sure thing! Let me know how it looks.

 

Link to comment
On 2/4/2021 at 4:20 AM, SimplifyAndAddCoffee said:

Setting user permissions...
Modifying ID for nobody...
Modifying ID for the users group...
Adding nameservers to /etc/resolv.conf...
Extracting packaged nessus debian package: Nessus 8.10.0...
Changing owner and group of configuration files...
Creating symbolic links...
Cleaning up...
Starting Nessus : .
[Thu Feb 4 11:00:52 2021][30.1][op=_qdb_map][name=services-udp.db][fd=-1][map_sz=38575]: complete
[Thu Feb 4 11:00:52 2021][30.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete
[Thu Feb 4 11:00:52 2021][30.1][op=_qdb_map][name=services-tcp.db][fd=-1][map_sz=40899]: complete
[Thu Feb 4 11:00:52 2021][30.1][op=qdb_sync][name=upgrades.db][fd=5][map_sz=0][file_size=55]: complete
[Thu Feb 4 11:01:02 2021][30.23][sched=100][pid=53][plugin=nessusd_www_server6.nbin][instr=0xd779] : Error: Could not find function 0xf000020c

call stack:
-----------
[0d779:Socket.accept+36] call, addr(0xf000020c), -, # ???? () [C func]
[07bb2:Mug::Connection.on_client+46] refcall, fp(2), string#707, # from: fp(2)
[22d1e:!anon5+4] refcall, fp(-2), string#4934, # from: fp(-2)
[2eb54:main+10121] eop, -, -,

[Thu Feb 4 11:01:14 2021][30.1][op=qdb_sync][name=plugins-desc.db][fd=19][map_sz=0][file_size=187756524]: complete
[Thu Feb 4 11:01:14 2021][30.1][op=qdb_sync][name=plugins-code.db][fd=7][map_sz=0][file_size=2967368547]: complete
[Thu Feb 4 11:02:05 2021][30.1][op=_qdb_map_lowmem][name=plugins-code.db.16124364741952786213][fd=7][map_sz=0][file_size=2967368547]: complete
[Thu Feb 4 11:02:08 2021][30.1][op=_qdb_map_lowmem][name=plugins-desc.db.1612436525562718452][fd=19][map_sz=0][file_size=187756524]: complete

similar issue to above poster. I last ran this back in november and it worked fine, but now it fails to update plugins or run scans.

 

Strange. I'll see if I can replicate this. I did just update the core .deb components which may have been an issue; however, I personally haven't seen this.

 

If having issues still, possibly consider re-deploying on a new volume mount or deleting the container with the volume data and re-deploying. What's strange in your error is it appears to be related to the nessusd_www_server6 plugin calling a function that is/was unavailable. Have you tried going to the console and manually updating the plugins?

Link to comment
  • 2 months later...

Hey, 

 

Sorry if this has already been addressed but I keep getting the "Report outdated / end-of-life Scan Engine / Environment (local)"

 

Installed GVM Libraries (gvm-libs) version: 11.0.1

Latest available GVM Libraries (gvm-libs) version: 20.8.1

 

Is there a way to manually update this?

Link to comment
  • 3 weeks later...
  • 3 weeks later...
On 6/28/2021 at 12:28 PM, wgstarks said:

After a bit of googling I found a website that will provide the code-

https://www.tenable.com/products/nessus/nessus-essentials

 

Thanks! My activation email was never sent after requesting one within the setup workflow of Nessus Essential, so this did the trick! 

 

From my experience, it should be noted (if not already above) that you must have a business email address when requesting an activation code. Some quick research pointed to this not always being the case, so something to keep in mind. I originally tried with my Gmail but that didn't work. 

 

Crossing my fingers installing goes smoother this time. I tried several weeks ago and gave up after setup appeared to hang on "Initializing - Compiling plugins...". I gave up after a couple hours of the loading bar not moving. Looks to be doing the same thing but will give it awhile to see what happens. Can anyone else chime in on whether this is normal?

Initializing.JPG

Link to comment
4 hours ago, ThatTallGuy21 said:

 

Thanks! My activation email was never sent after requesting one within the setup workflow of Nessus Essential, so this did the trick! 

 

From my experience, it should be noted (if not already above) that you must have a business email address when requesting an activation code. Some quick research pointed to this not always being the case, so something to keep in mind. I originally tried with my Gmail but that didn't work. 

 

Crossing my fingers installing goes smoother this time. I tried several weeks ago and gave up after setup appeared to hang on "Initializing - Compiling plugins...". I gave up after a couple hours of the loading bar not moving. Looks to be doing the same thing but will give it awhile to see what happens. Can anyone else chime in on whether this is normal?

Initializing.JPG

 

So I'm still having this same issue. My session sat on "Initializing" from 9:05am ET until 1:35pm ET and appeared to do nothing. Since it didn't move, I refreshed the page and got the "This site can't be reached" message. Then I restarted the Nessus docker container and the GUI now displays but still says "Initializing". 

 

Is this normal to sit on "compiling plugins" for this long? Any suggestions on how to resolve?

Link to comment

Happy to report back that at 9pm ET last night, after letting the install do its thing for a large portion of yesterday, that I was able to successfully login through the GUI and execute my first scan. This thing is pretty cool. Really appreciate the work to make this happen. 

 

  • What is everyone testing? Are you entering in a range of IPs which include your server? 
    • I ended up testing a pretty large range of IPs across my entire network. Hoping to see Nessus capture everything on my network.
  • Any particular type of test that you recommend? 
  • Anyone recommend using any particular plugin?
Edited by ThatTallGuy21
Link to comment
  • 1 month later...
On 6/9/2021 at 3:37 PM, bilboswaggins said:

Hey, 

 

Sorry if this has already been addressed but I keep getting the "Report outdated / end-of-life Scan Engine / Environment (local)"

 

Installed GVM Libraries (gvm-libs) version: 11.0.1

Latest available GVM Libraries (gvm-libs) version: 20.8.1

 

Is there a way to manually update this?

 

I came here to ask the same question - any way to get this updated? TIA

Link to comment
4 hours ago, ThatDude said:

 

I came here to ask the same question - any way to get this updated? TIA

 

Glad you pinged me as I am able to get this handled today as I have some time on my hands. Been pretty busy and this keeps slipping my mind given it continues to work with updated plugins; however, I may look into creating an automated pipeline for publishing updates here soon if I can make the time out of my schedule to work this.

 

Just re-packaged a new container update that I am spinning up for a test (wouldn't want to push an update and break everyone's functional scanner) before publishing it. I should have it up here shortly. 😁

 

Link to comment
On 7/16/2021 at 5:53 AM, ThatTallGuy21 said:

Happy to report back that at 9pm ET last night, after letting the install do its thing for a large portion of yesterday, that I was able to successfully login through the GUI and execute my first scan. This thing is pretty cool. Really appreciate the work to make this happen. 

 

  • What is everyone testing? Are you entering in a range of IPs which include your server? 
    • I ended up testing a pretty large range of IPs across my entire network. Hoping to see Nessus capture everything on my network.
  • Any particular type of test that you recommend? 
  • Anyone recommend using any particular plugin?

 

Awesome! For me, I normally spin this up and run a scan on a known subnet of my internal network and when not in use I power the container off. I've used Nessus in an Enterprise environment for benchmarks (compliance), vulnerability scans using credentials/uncredentialed, etc. I recommend going to a Nessus forum if you want to work with others on specifics on the usage of the scanner.

 

Have a good weekend!

Link to comment
8 hours ago, ThatDude said:

 

I came here to ask the same question - any way to get this updated? TIA

 

Just to give you a heads up, I just pushed an update updating Nessusd to the latest version as well as updating the base image and other dependencies.

 

Let me know if you have any issues. 

 

 

UPDATE 1 5:30PM MST: No issues with the package and it functioning; however, if deploying an update/upgrade it appears there is some bug that causes a 404 error. Working on a fix right now, which involves backing up /config/opt/nessus/var/nessus (which is the configuration files for a user), cleaning up the whole previous install, then re-installing the new package. I think since I just copied the deb into the path there is something that it doesn't like. I plan to have this fixed today within the next hour or so. I don't recommend updating just yet!

 

UPDATE 2 6:00PM MST: I believe to have a patch in place that i published. Doing a final test to make sure all is well. I recommend if you have anything important (IE: license for non-free) to backup the var/nessus folder and store it elsewhere. This can be done by accessing the console. Wouldn't be a bad idea to do this anyways if this is used on a business/production system. I imagine most UnRaid instances are for small home use and I know personally I wouldn't have an issue re-doing my configurations; however, this is probably not the same for a select few.

 

 

If anyone is still having issues, please feel free to post your logs. I should have time over this 3-day weekend to work with anyone who is running into issues in debugging it. Seems each time I go for a simple patch it works fine except for upgrading where a volume and data is present. If all is well, I may look into making a CI/CD pipeline to auto-update the core components on a regular schedule, but I have to figure out good tests it can run before merging into the production version. 

Edited by jbreed
Issue with update
Link to comment

Heya,

 

Thanks for the update. Since updating this, the docker image use has gone from around ~1.5GB to 9.8GB, and has maxed out my docker image, I have given it another 5GB and its still growing.

 

Is this expected, i.e. are there alot of changes or new files in this update, or are there any new paths we may need to map?

 

This is the tail end of the Docker Log;

 

config/opt/nessus/var/nessus/tmp/fetch_feed_file_tmp_32_2140101596_1745818318
config/opt/nessus/var/nessus/plugins-code.db.16305872481236034445
tar: config/opt/nessus/var/nessus/plugins-code.db.16305872481236034445: Cannot write: No space left on device
config/opt/nessus/var/nessus/plugins-desc.db.163058740051507450
Setting user permissions...
Modifying ID for nobody...
Modifying ID for the users group...
Adding nameservers to /etc/resolv.conf...
Backing up Nessus configuration to /config/nessusbackup.tar
tar: Removing leading `/' from member names
/config/opt/nessus/var/nessus/
/config/opt/nessus/var/nessus/tools/
/config/opt/nessus/var/nessus/tools/bootstrap-from-media.nbin
/config/opt/nessus/var/nessus/tools/nessusd_www_server6.nbin
/config/opt/nessus/var/nessus/tools/tool_dispatch.ntool
/config/opt/nessus/var/nessus/logs/
/config/opt/nessus/var/nessus/nessus-services
/config/opt/nessus/var/nessus/plugins-core.tar.gz
/config/opt/nessus/var/nessus/tenable-plugins-a-20210201.pem
/config/opt/nessus/var/nessus/users/
/config/opt/nessus/var/nessus/nessus_org.pem
/config/opt/nessus/var/nessus/tenable-plugins-b-20210201.pem
/config/opt/nessus/var/nessus/tmp/
/config/opt/nessus/var/nessus/tmp/nessusd
/config/opt/nessus/var/nessus/tmp/nessusd.service
Cleaning up old Nessus installation files
Extracting packaged nessus debian package: Nessus 8.15.1...
mkdir: cannot create directory '/tmp/recover': File exists

 

 

Thanks

 

EDIT: I couldn't get to the bottom of it, and no matter how much extra space I gave the Docker Image, within a few moments it used it all. So I ended up deleting the image, and moving the old appdata and starting a fresh. This solved the disk usage issue, however, on this clean install I had a couple of issues where nessus would not start, going to the console and starting the nessusd service manually worked. Will see how it goes over the next few days. - Thanks again for updating it :)

Edited by timethrow
Give Update
Link to comment
6 hours ago, timethrow said:

Heya,

 

Thanks for the update. Since updating this, the docker image use has gone from around ~1.5GB to 9.8GB, and has maxed out my docker image, I have given it another 5GB and its still growing.

 

Is this expected, i.e. are there alot of changes or new files in this update, or are there any new paths we may need to map?

 

This is the tail end of the Docker Log;

 

config/opt/nessus/var/nessus/tmp/fetch_feed_file_tmp_32_2140101596_1745818318
config/opt/nessus/var/nessus/plugins-code.db.16305872481236034445
tar: config/opt/nessus/var/nessus/plugins-code.db.16305872481236034445: Cannot write: No space left on device
config/opt/nessus/var/nessus/plugins-desc.db.163058740051507450
Setting user permissions...
Modifying ID for nobody...
Modifying ID for the users group...
Adding nameservers to /etc/resolv.conf...
Backing up Nessus configuration to /config/nessusbackup.tar
tar: Removing leading `/' from member names
/config/opt/nessus/var/nessus/
/config/opt/nessus/var/nessus/tools/
/config/opt/nessus/var/nessus/tools/bootstrap-from-media.nbin
/config/opt/nessus/var/nessus/tools/nessusd_www_server6.nbin
/config/opt/nessus/var/nessus/tools/tool_dispatch.ntool
/config/opt/nessus/var/nessus/logs/
/config/opt/nessus/var/nessus/nessus-services
/config/opt/nessus/var/nessus/plugins-core.tar.gz
/config/opt/nessus/var/nessus/tenable-plugins-a-20210201.pem
/config/opt/nessus/var/nessus/users/
/config/opt/nessus/var/nessus/nessus_org.pem
/config/opt/nessus/var/nessus/tenable-plugins-b-20210201.pem
/config/opt/nessus/var/nessus/tmp/
/config/opt/nessus/var/nessus/tmp/nessusd
/config/opt/nessus/var/nessus/tmp/nessusd.service
Cleaning up old Nessus installation files
Extracting packaged nessus debian package: Nessus 8.15.1...
mkdir: cannot create directory '/tmp/recover': File exists

 

 

Thanks

 

Very odd. It appears the /tmp/recover directory was never cleaned up after doing the update causing it to try and create the directory and fail due to it being there already. Here is what the bottom of that log file should look like. Looks like I should check for this within the startup script.

 

 

config/opt/nessus/var/nessus/plugins-attributes.db.new
config/opt/nessus/var/nessus/tenable-plugins-20210201.pem
Changing owner and group of configuration files...
Creating symbolic links...
Cleaning up deb file used for install..
Cleaning up backup files extracted for an update..
Starting nessusd service...
nessusd (Nessus) 8.15.1 [build 20272] for Linux
Copyright (C) 1998 - 2021 Tenable, Inc.

Cached 0 plugin libs in 0msec
Processing the Nessus plugins...

All plugins loaded (0sec)
Setting user permissions...
Modifying ID for nobody...
Modifying ID for the users group...
Adding nameservers to /etc/resolv.conf...
Changing owner and group of configuration files...
Starting nessusd service...
nessusd (Nessus) 8.15.1 [build 20272] for Linux
Copyright (C) 1998 - 2021 Tenable, Inc.

 

 

Console into the container and get the results of:

# bash

# df -h

 

This will tell you what the disk usage is looking like. The backup tar file for me is 1.6G (could gzip it to further compress) with the whole volume mount sitting at 49G (/config). Not sure how you were seeing such small disk usage before to be honest.

root@2917db0051dc:/config# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop2      120G  6.8G  112G   6% /
tmpfs            64M     0   64M   0% /dev
tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup
shm              64M     0   64M   0% /dev/shm
shfs            466G   49G  417G  11% /config
/dev/loop2      120G  6.8G  112G   6% /etc/hosts
tmpfs           7.8G     0  7.8G   0% /proc/acpi
tmpfs           7.8G     0  7.8G   0% /sys/firmware

 

I'll look into adding a handler for the recovery of the backup file as well as add compression to further shrink it; however, I imagine it won't be a big difference. Have you logged in and updated all of your plugins? You could get a bash terminal and run 'du' to locate large files to understand what is using the space. If you take a look at the startup script, this is the basic logic flow:

1. Backup the Nessus user data to /config, which is a volume mount as a tar file

2. Delete the /config/opt directory

3. Unpackage the .deb Nessus installation back to the /config directory, which deploys /config/opt and nessus will be under this

4. Unpackage backup tar file to /tmp/recover

5. Move main backup components into the nessus installation (users, database, etc)

6. Cleanup the /tmp/recover and .deb file removal (doesn't delete the actual backup .tar file)

 

 

UPDATE: Pushed an update correcting how the backup and recovery tar was working. You can probably free up over 1-2G by opening a console and deleting the /config/nessusbackup.tar if you don't care to have a backup residing on the volume.

 

Edited by jbreed
pushed a new update
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.