Tech Tinkering

A little adventure getting OpenVAS (Vulnerability Analysis tool) working.   Originally thought I had it running on my AAO netbook but it was too slow/weak.   Retracing my steps here on a bigger/faster x86 machine just to to see if it really runs .... It Does Run!

Background:  It LOOKED like Greenbone/OpenVAS was pre-installed on the Parrot HTB Edition but apparently not quite right ... here are notes from attempts to get it working.  

Step by Step

Greenbone/OpenVAS appears to be installed w/ Parrot menu items for most of the GVM setup and admin.  Just a few tweaks to get it all working.  This should be the quick step-by-step on a new install of ParrotOS (If interested, see below for my original debug.) 

1. update/upgrade
   
   sudo apt update
   sudo apt upgrade
    

2. <reboot-a-roooo - just to get the witches out>
   
   

3. Run gvm-setup .... via GUI:  Applications->Pentesting-Vulnuerability Analysis->Openvas Greenbone->GVM Setup
   // VERY long run and verbose - make SURE you record admin password! //
   
   Final output (make note admin password!!):
   
   [+] GVM feeds updated
   [*] Checking Default scanner
   [*] Modifying Default Scanner
   Scanner modified.
   
   [+] Done
   [*] Please note the password for the admin user
   [*] User created with password 'xxxxxxxx-yyyy-zzzz-yyyy-xxxxxxxx'.
   
   [>] You can now run gvm-check-setup to make sure everything is correctly configured
   
   

4. IF you run gvm-check-setup as suggested, it will probably fail in step 1 and tell you that it is missing the scanner ... something like this:
   
   Step 1: Checking OpenVAS (Scanner)... 
   ERROR: No OpenVAS Scanner found.
       FIX: Please install OpenVAS Scanner.

5. It wasn't really missing ... just looking in the wrong place (see #3 below). Copy a couple files from "/usr/lib64/"  to "/usr/lib/" to fx this, specifically: 
   
   sudo cp /usr/lib64/libopenvas_nasl.so.21 /usr/lib/.
   sudo cp /usr/lib64/libopenvas_misc.so.21 /usr/lib/.
   
   

6. one more fix before running check-setup again ... permissions on openvas.log file are probably wrong (see #7 below).  Fix as follows:
   
   sudo chown _gvm /var/log/gvm/openvas.log

7. gvm-check-setup should NOW WORK! (or Applications->Pentesting-Vulnuerability Analysis->Openvas Greenbone->GVM Check Setup)

chown _gvm /var/log/gvm/openvas.log

8. Stop/Started the GVM service and you SHOULD be able to access Greenbone login screen locally via https://127.0.0.1:9392
   // remember httpS!  it IS NOT listening on 80 //
   
   

9. Edit Service to permit access from other devices on the net (initially restricted to localhost)

sudo systemctl stop gsad.service
sudo systemctl disable gsad.service

edit /usr/lib/systemd/system/greenbone-security-assistant.service (which appears to be the same as /user/lib/systemd/system/gsad.service)
Changed the execstart line to look like this (it was 127.0.0.1)

ExecStart=/usr/sbin/gsad --listen 0.0.0.0 --port 9392

Bring it all back up

sudo systemctl enable gsad.service

sudo systemctl daemon-reload

sudo systemctl start gsad.service

Note:  My system periodically displays timeout when starting gsad.service ... BUT ... all was OK!   It must simply be slow ...

Job for gsad.service failed because a timeout was exceeded
See "systemctl status gsad.service" and "journalctl -xeu gsad.service" for details.

That should do it ...

***********************************************

Original Stumble-by-Stumble (prob a mess)sudo 

Notes from initial attempt to get it working ... useful or not?

via terminal or ssh:

1. • 1. Run gvm-setup .... VERY verbose, I should have piped the output to see if there were any errors.  But just relied on check-setup in between steps ....
        
        sudo gvm-setup
        
        Final output (make note admin password!!):
        
        [+] GVM feeds updated
        [*] Checking Default scanner
        [*] Modifying Default Scanner
        Scanner modified.
        
        [+] Done
        [*] Please note the password for the admin user
        [*] User created with password 'xxxxxxxx-yyyy-zzzz-yyyy-xxxxxxxx'.
        
        [>] You can now run gvm-check-setup to make sure everything is correctly configured
        
        

     2.  Run gvm-check-setup .. for the first time!!
        
        sudo gvm-check-setup
        
        ... and the answer IS ...
        
        gvm-check-setup 21.4.3
        Test completeness and readiness of GVM-21.4.3

Step 1: Checking OpenVAS (Scanner)...
ERROR: No OpenVAS Scanner found.
FIX: Please install OpenVAS Scanner.

ERROR: Your GVM-21.4.3 installation is not yet complete!

Please follow the instructions marked with FIX above and run this script again.

1. • 3.  According to /tmp/gvm-check-setup.log:  It appears to THINK we are missing openvas libraries "libopenvas_nasl.so.21" and "libopenvas_misc.so.21".  
        Some sort of libpath or build bug?
        
        Fix (?):  I copied both files from "/usr/lib64/"  to "/usr/lib/" ... to make it past this step
        
        sudo cp /usr/lib64/libopenvas_nasl.so.21 /usr/lib/.
        sudo cp /usr/lib64/libopenvas_misc.so.21 /usr/lib/.

1. • 4. Re-Run gvm-check-setup ... Attempt #2:
        
        sudo gvm-check-setup
        
        ... Getting closer! ...
        
        gvm-check-setup 21.4.33

 Test completeness and readiness of GVM-21.4.3

Step 1: Checking OpenVAS (Scanner)...  

       OK: OpenVAS Scanner is present in version 21.4.4.

       OK: Server CA Certificate is present as /var/lib/gvm/CA/servercert.pem.

Checking permissions of /var/lib/openvas/gnupg/*

       OK: _gvm owns all files in /var/lib/openvas/gnupg

       OK: redis-server is present.

       OK: scanner (db_address setting) is configured properly using the redis-server socket: /var/run/redis-openvas/redis-server.sock

       OK: redis-server is running and listening on socket: /var/run/redis-openvas/redis-server.sock.

       OK: redis-server configuration is OK and redis-server is running.

       OK: _gvm owns all files in /var/lib/openvas/plugins

       OK: NVT collection in /var/lib/openvas/plugins contains 115774 NVTs.

Checking that the obsolete redis database has been removed

       OK: No old Redis DB

       OK: ospd-OpenVAS is present in version 21.4.4.

Step 2: Checking GVMD Manager ...  

       OK: GVM Manager (gvmd) is present in version 21.4.5.

Step 3: Checking Certificates ...  

       OK: GVM client certificate is valid and present as /var/lib/gvm/CA/clientcert.pem.

       OK: Your GVM certificate infrastructure passed validation.

Step 4: Checking data ...  

       OK: SCAP data found in /var/lib/gvm/scap-data.

       OK: CERT data found in /var/lib/gvm/cert-data.

Step 5: Checking Postgresql DB and user ...  

       OK: Postgresql version and default port are OK.

gvmd      | _gvm     | UTF8     | C.UTF-8 | C.UTF-8 |  

       OK: At least one user exists.

Step 6: Checking Greenbone Security Assistant (GSA) ...  

Oops, secure memory pool already initialized

       OK: Greenbone Security Assistant is present in version 21.4.4.

Step 7: Checking if GVM services are up and running ...  

       Starting ospd-openvas service

the control process exited with error code.

See "systemctl status ospd-openvas.service" and "journalctl -xeu ospd-openvas.service" for details.

       Waiting for ospd-openvas service

       ERROR: ospd-openvas service did not start.

       Please check journalctl -xe

1. • 5. journalctl -xe says:
        
        

Sep 28 03:15:41 parrot openvas[2635]: init_openvas: Can not open or create log file or directory. Please check permissions of log files listed in /et>

Sep 28 03:15:47 parrot openvas[2636]: init_openvas: Can not open or create log file or directory. Please check permissions of log files listed in /et>

Sep 28 03:15:52 parrot systemd[1]: ospd-openvas.service: Control process exited, code=exited, status=1/FAILURE

░░ Subject: Unit process exited

░░ Defined-By: systemd

░░ Support: https://www.debian.org/support

░░  

░░ An ExecStart= process belonging to unit ospd-openvas.service has exited.

░░  

░░ The process' exit code is 'exited' and its exit status is 1.

Sep 28 03:15:52 parrot systemd[1]: ospd-openvas.service: Failed with result 'exit-code'.

░░ Subject: Unit failed

░░ Defined-By: systemd

░░ Support: https://www.debian.org/support

░░  

░░ The unit ospd-openvas.service has entered the 'failed' state with result 'exit-code'.

Sep 28 03:15:52 parrot systemd[1]: Failed to start ospd-openvas.service - OSPd Wrapper for the OpenVAS Scanner (ospd-openvas).

░░ Subject: A start job for unit ospd-openvas.service has failed

░░ Defined-By: systemd

░░ Support: https://www.debian.org/support

░░  

░░ A start job for unit ospd-openvas.service has finished with a failure.

░░  

░░ The job identifier is 3151 and the job result is failed.

Sep 28 03:16:19 parrot sudo[2640]:     tped : TTY=pts/1 ; PWD=/home/tped ; USER=root ; COMMAND=/usr/bin/journalctl -xe

Sep 28 03:16:19 parrot sudo[2640]: pam_unix(sudo:session): session opened for user root(uid=0) by tped(uid=1000)

1. • 6. Crap!   I forgot .... lets update/upgrade Parrot before I dig my grave any deeper
        
        sudo apt update; sudo apt upgrade
        
        

     7.  Re-Run check-setup .... no change.  Step 7 failed running ospd-openvas.service

        • systemctl status ospd-openvas.service says that it is down/disabled .... no surprise!

        • journalctl -xeu ospd-openvas.service was much more helpful:
          "init_openvas: Can not open or create log file or directory.  Please check permissions of log files"

        • /etc/gvm/ospd-openvas.conf claims log_file is /var/log/gvm/ospd-openvas.log, which is owned by root!   

          • Fix (?):  Hmmm?!  Everything else is owned by  _gvm user ... let's set openvas.log the same:   

chown _gvm /var/log/gvm/openvas.log

1. • 8. Re-Run gvm-check-setup ... Attempt #4:
        
        sudo gvm-check-setup
        
        ... I THINK we got it!  Made it through Step 7 AND 8 ...
        
        Step 7: Checking if GVM services are up and running ...  

       OK: ospd-openvas service is active.

       Starting gvmd service

       Waiting for gvmd service

       OK: gvmd service is active.

       Starting gsad service

       Waiting for gsad service

       OK: gsad service is active.

Step 8: Checking few other requirements...

       OK: nmap is present in version 21.4.4.

       OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is likely to work.

       WARNING: Could not find makensis binary, LSC credential package generation for Microsoft Windows targets will not work.

       SUGGEST: Install nsis.

       OK: SELinux is disabled.

       OK: xsltproc found.

       WARNING: Your password policy is empty.

       SUGGEST: Edit the /etc/gvm/pwpolicy.conf file to set a password policy.

It seems like your GVM-21.4.3 installation is OK.

1. • 9.  Stop/Started the GVM service and POOF!   I could access Greenbone login screen locally via https://127.0.0.1:9392
         

     10.  Many opinions on this one, but to enable LAN access to the Greenbone Web UI I simply edited the gsad service.  It is runs with a "--listen" parameter. 
         Step by step ... right-or-wrong

         • sudo systemctl stop gsad.service

         • sudo systemctl disable gsad.service

         • edit /usr/lib/systemd/system/greenbone-security-assistant.service (which appears to be the same as /user/lib/systemd/system/gsad.service)
           Changed the execstart line to look like this (it was 127.0.0.1)
           ExecStart=/usr/sbin/gsad --listen 0.0.0.0 --port 9392

         • Bring it all back up

           • sudo systemctl enable gsad.service

           • sudo systemctl daemon-reload

           • sudo systemctl start gsad.service

     11. sudo gvm-feed-update
         ... I think it was required, UI was constantly showing 'updating' on feed status.  Once feed-update was done, it was good to go!

     12.   

**********************

SAVE THIS ... it happened on the AAO but NOT this time around .... not sure what changed, but was a dickens to fix 

• Re-Run Check Setup AGAIN AGAIN .... Yikes!  Same thing.  This is NUTS!  
  "ERROR:  redis-server is not running or not listening on socket:  /var/run/redis-openvas/redis-server.sock" 

  • It IS Running but there is no such thing as /var/run/redis-openvas directory say nothing of redis-server.sock

  • There appear to be TWO versions of redis.conf in /etc/redis ...
    the current Service uses redis.conf, but there is also a redis-openvas.conf.  

    • No sign of 'socket' in redis.conf (but more comments than I've ever seen!)

    • Something strange with permissions on rdis stuff ... per my buddy chatgpt I'll set:
      sudo chmod 755 /etc/redis
      sudo chmod 644 /etc/redis/redis-openvas.conf

    • sudo systemctl disable redis-server.service
      sudo systemctl daemon-reload
      sudo systemctl enable redis-server.service
      sudo systemctl start redis-server.service

• gvm check set up AGAIN AGAIN AGAIN!   Hey!  made it through redis socket crap!   

Homebridge Tweak:  Adding Cameras to Apple Homekit world to integrate into IOS Home app and to see how they may fit into home automation.  The following uses older/cheap WiFi cameras that were previously interfaced using their own apps.  Not too difficult, here are a few notes and links from the activity. 

Camera Plugins:   Gadzooks!  There were 20 options when searching for Homebridge plugin @  https://www.npmjs.com/search?q=keywords%3Ahomebridge%20camera.    Settled on Homebridge Camera FFmpeg, it seems to works fine.  Installed plugin via Homebridge Config UI X .  Some camera naming oddities but plugin seems to do fine with multiple cameras. 

Interface strings for cameras:  There is a large database of working/tested configurations on GitHub, will submit our working configs to the DB if everything seems solid.   There is also a handy-looking RTSP directory @ https://security.world/rtsp/.  

Other useful links:

• https://ffmpeg.org/documentation.html

• https://www.videoproc.com/resource/h264-codec.htm

• https://write.corbpie.com/ffmpeg-list-all-codecs-encoders-decoders-and-formats/

Bottom-line:   Cameras work but of marginal utility, will play with adding MotionEye to our HomePi world to incorporate into home automation.

Background:  YouTube Add-on on Kodi stopped working in past year or so.  I simply stopped using it on my parent's MoviePi.  Created another MoviePi for our house and YouTube seemed to work fine ... FOR A WHILE.  I'll be back to figure this out and clean this up

I fugured this out a while ago - step-by-step is in MoviePi Recipe

Notes/Research 

• This guide walked me thru Google API Key - https://www.videoconverterfactory.com/kodi/youtube-api-key.html

• More on YouTube Add-On here - https://koditips.com/setup-use-youtube-kodi-addon/

• Web Interface - https://www.comparitech.com/kodi/kodi-web-interface/

The Big Issue:  Our "Smarthome" is getting outdated.  Hubs and devices purchased during the dawn of IoT are slowly being dropped from support

Little Issue:  We have a lone v1 Hue Light bulb  that was paired directly to a v1 Smartthings hub.  I needed to factory reset it and move to the Hue Hub in an attempt to get a few more years out of it.  Here's my How-to-collection and hopefully a procedure that works

Circa 2017 (some broken links):

• From smartthings forum:  https://community.smartthings.com/t/hue-bulb-factory-reset-solved-if-your-hue-bulb-is-on-a-zll-channel/84967, 

• http://thingsthataresmart.wiki/index.php?title=How_to_Reset_Philips_Hue_Bulbs

• Using Bulb Serial number and Hue App - MUCH Easier!  https://www.howtogeek.com/247801/how-to-troubleshoot-your-philips-hue-lights/
  This last one worked!  Simple!   Bulb operates fine via Hue app so I deleted the ST bulb!  Too Easy!

  • In Hue App:  Room Setup, add bulb to desired room - sos you can see it!

  • in Smartthings App:  Delete the old/original bulb.  It will still show in app after the move, but ST can't control it

Easier than the last time I tried this ... BUT ... 

ST "Smart Lighting" app is now gooffed upped!  When I try to adjust ANY Automations in the Smart Lighting App  - I see "Something Went wrong.  Please try to reinstall the SmartApp again" ... which is a pain in the arse because we have all sorts of  complicated lighting automations that were really hard to define on the stupid ST app in the first place.

Ack!  Rebooted the hub, reset all IOS ST apps, still the same ... will have to hand-record all automations and delete, re-add the "Smart Lighting App"(This is going to turn out bad, I just know it!) .  The topic is on fire on the ST support board @ https://community.smartthings.com/t/help-smart-lighting-app-issue-with-error-something-went-wrong-please-try-to-install-the-smartapp-again.  I put a watch on it and filled my email inbox!

I basically recreated all of the Smart Lighting App rules using the 'Automations' feature on the new ST app.  Really wasn't that bad to do.  I'll bet the ST folk are trying to get others to use this feature and get rid of the smart apps.  They should just say something on the forum!