How to access API's of an SVM OnPrem server?
You can essentially use the same URL for Cloud but replace csi7.secunia.com with your OnPrem Server URL. So the URL to login would look like: https://ONPREMSERVER.com/csi/api/?uid=&action=manuallogin The link here: https://helpnet.flexerasoftware.com/csi/api/Default.htm#helplibrary/Login_API_Information.htm#svm_api_login_2776300157_1208920%3FTocPath%3DLogin%2520API%7C_____1 Gives instructions on what is needed from a POST request to URL mentioned. You may want to try using an APP like POSTMAN to make a POST Request to the URL. You'll then want to enter parameters in the Body for username and password. You may also want to take a look at the powershell sample shown here: https://helpnet.flexerasoftware.com/csi/api/Default.htm#helplibrary/Appendix_A___Sample_API_Code.htm#svm_api_appendixa_912118870_1206716%3FTocPath%3DAppendix%2520A%2520-%2520Sample%2520API%2520Code%7C_____1
This should get you started with using the API's of an onPrem SVM server.
The iTunes installer is architecture sensitive. It only allows the 32bit version of iTunes to install on 32bit OS's. This can be problematic with the package created by SVM, as the wizard in Step 4 of 4 allows and defaults the System Applicability to Both 32-bit and 64-bit Systems.
However, if you try to install the 32bit version of iTunes on a 64bit OS you may see this error.
You may see this in the SecuniaPackage.log:
Package architecture does not match system architecture. Aborting
Software Vulnerability Manager is an active product with no end of life scheduled. Below are previously released versions along with the end of life dates for these earlier versions of the product.
End of Standard Lifecycle
End of Limited Lifecycle
Lifecycle as of Today
Software Vulnerability Manager (SVM) 2018 Cloud (Formerly CSI)
Standard Life Cycle
Software Vulnerability Manager (SVM) 2018 On Premise (Formerly CSI)
Standard Life Cycle
Corporate Software Inspector (CSI) On Premise
Standard Life Cycle
Software Vulnerability Research (SVR) (Formerly VIM)
Standard Life Cycle
Vulnerability Intelligence Manager (VIM)
Vulnerability Intelligence Manager (VIM) On Premise
The date format used is YYYY-MM-DD
Versions not listed should be assumed as past extended lifecycle Read a complete description of the Flexera lifecycle and end-of-life policy
Flexera understands the desire for coverage of Red Hat OpenJDK, but is unable to effectively track it on Windows systems due to inconsistent and conflicting identification information coming from Red Hat. While we do cover it on RHEL, we cannot properly cover the Windows versions with Secunia Advisories.
Users often require additional help for the logical process workflow when it comes to integrating the Software Vulnerability Manager 2019 software to their internal WSUS or SCCM servers for patching.
In most, users need additional elaboration on what is the right sequence of steps to integrate SVM and what actions will be needed to troubleshoot expected errors that come in their way as part of the deployment process.
The SVM VA server will generate a self-signed SSL certificate when you choose to use SSL. These instructions will explain how to swap it for your certificate and key pair.
Once you've run through the SVM Virtual Appliance (VA) setup wizard and have selected to use SSL you'll find that the server is set up with a self-signed SSL certificate. In some environments that isn't an ideal solution as the act of propagating the public key from this certificate to all endpoints can be daunting. Below you'll find step by step instructions on how to replace the generated certificate with your own. 1. Obtain and transfer your public and private keys to your SVM VA. Once you have access to the file(s) this can be easily transferred to your server with a tool like WinSCP. 2. If your certificate is packaged together in a PFX file, you can do the following to prepare your public and private key files.
Extract the private key:
openssl pkcs12 -in cert_name.pfx -nocerts -out csi.key
Remove the password from your key, so httpd will start without prompting:
mv csi.key csi.key.secure openssl rsa -in csi.key.secure -out csi.key
Generate the public certificate:
openssl pkcs12 -in cert_name.pfx -clcerts -nokeys -out csi.crt
If you have a PEM file that has the two keys instead of a pfx you'll want to change the pkcs12 to x509 to match the format of the certificate. If you have another certificate format you'll need to adjust accordingly. Please refer to the openssl manual page for further details
3. Next, we need to replace the existing self-signed certificate files with the ones we now have on hand.
We can find the location for the existing key pair in the virtual host definition for Apache which is found in /etc/httpd/conf.d/secunia-ssl.conf . Here is what the certificates paths look like in virtual host file
SSLCertificateFile /etc/pki/tls/certs/csi.crt SSLCertificateKeyFile /etc/pki/tls/private/csi.key
The important lines from the virtual host are the SSLCertificateFile and SSLCertificateKeyFile directives. These tell Apache which public and private key to use for the SSL connection and this lets us know what files we need to replace.
4. Remove the existing certificate key pair and replace it with yours.
Begin with deleting the old public key:
Delete the old private key:
Copy new public key
cp csi.crt /etc/pki/tls/certs/
Copy new private key
cp csi.key /etc/pki/tls/private/
5. Restart Apache
service httpd restart
After restarting Apache you are all set. Your connections to the SVM Server will occur using the newly implemented certificate.
Summary: This article explains how you can enable logging at SVM-on-premise Server for troubleshooting. Steps:
Log in to your SVM-On-premise server via putty session :
Open the configuration file at the following location /usr/local/Secunia/config.ini:
Edit the logging settings in config.ini to following:
DEBUG_LEVEL = 3 LOG_LEVEL_GENERAL ='LOG_DEBUG'
Tail the /var/log/messages file for errors and troubleshooting:
tail -f /var/log/messeges
tail -n 1000 /var/log/messeges
Important: Please remember to switch back the logging setting after the troubleshooting otherwise it will take a lot of space at the SVM On-premise server.
Backup SVM-On-premise Database To backup your SVM-On-premise Database:
mysqldump -u [user] -p [database_name] > [filename].sql
Replace [user] with your username and password (if needed).
The [database_name ] is the path and filename of the database.
The > command specifies the output.
[filename ] is the path and filename you want to save the dump file as.
To backup of an entire Database :
mysqldump --all-databases --single-transaction --quick --lock-tables=false > full-backup-$(date +%F).sql -u root -p
To include more than one database in the backup :
sudo mysqldump -u [user] -p [database_1] [database_2] [database_etc] > [filename]. sql
Important: If you have dual SVM-on-premise Application and DB server setup. Then edit the following part of the above commands to take the backup.
mysql -u [user] -p -h <Database Sever Name>
Restore SVM-On-premise Database Make sure you have the most recent backup of your DB at /usr/local/Secunia/csi/backup
Log in to your DB server :
mysql -u [user] -p
First Drop the Database you want to recover :
Drop database <Database Name>;
Create the Database according to Database backup file name:
create database <Database Name>;
Exit from your DB and go to your DB backup location:
exit; cd /usr/local/Secunia/csi/backup
Restore an SVM-on-premise backup:
mysql -u [user] -p [database_name] < [filename].sql
Important: If you have dual SVM-on-premise Application and DB server setup. Then edit the following part of the above commands to restore the backup.
mysql -u [user] -p -h <Database Sever Name>
The SVM on-premise user is unable to log in at SVM On-premise console and getting a Connection Failed Error. Please follow the below steps to resolve your issue. Steps:
Log in to your DB server
mysql -u root -p
Search the private DB user (The private DB is usually a customer id of the server)
select user, host, password from mysql.user;
Run the following command to update the user
update mysql.user set host = '%' where user = 'enter DB user here';
Run the command to flush the privileges and restart the DB service
FLUSH PRIVILEGES; or mysql or mariadb service restart
Stop the following services
service httpd stop service haproxy stop
Run the dbpdb.sh from /usr/local/Secunia/csi/install and follow instructions
cd /usr/local/Secunia/csi/install ./dbpdb.sh
Start the apache and haproxy service
service httpd start service haproxy start
Important: Stopping and restarting services are handled in dbpdb.sh script now and this feature is only available in RPM's and not VA(Virtual Appliance).
Flexera Software Vulnerability Manager components have built-in security mechanisms for the validation of the target server they connect and submit scan data to. This 'CRL check' as it's called, has the sole purpose to confirm that the data the Agent has collected (or Daemon) is sent back securely. For more information and details on what online CRL validation websites must be white-listed, see this KB.
SVM Agents are installed successfully on the domain clients and the Agent service is running fine. Few or many of them, however, fail to report back check-ins and scan results to their master server.
SVM Daemon fails to submit data back to its target server to which it connects and reports back to. It could also happen that the Software Vulnerability Manager IE Plugin or SCCM Plugin fails to load too.
Agent's (or Daemon's) log file displays the following WinHttp error which prevents any of the aforementioned to communicate successfully to Flexera Cloud servers. No scans are received timely.
[Date and Time] Error when sending WinHttp request (12175) [Date and Time] Connection error.... [Date and TIme] Error in HttpRequest: status=499, StatusText="A security error occurred' ,winCode=12175
In 99% of the cases, the root cause is blocking somewhere on the network. It could be the local area network, the domain network, or security controls on the boundaries of the network perimeter. This issue can be reproduced by blocking all URLs on the local Windows Firewall and triggering an Agent scan in the command-line interface, as easy as it could happen without expectation when some security networks have explicit deny procedures in place to disallow everything that is not explicitly allowed on the corporate firewall, the corporate proxy, or another security device with blocking/filtering functions.
Flexera Support sees the following problems more often than not at the customer sites:
a) The required online CRL URLs for certificate revocation are not all white-listed at the Proxy/Firewall. b) There is a Proxy on the network, but the client(s) facing WinHttp 12175 have netsh proxy set = Direct. c) Content-inspection Proxy is stripping the original certificate and the security validation breaks. d) The Agent/Daemon/Plugins are run with user credentials insufficient to bypass the Proxy/Firewall.
The first and most appropriate solution which Flexera suggests to customers is to avoid workarounds and to whitelist the required by the Software Vulnerability Manager online CRL URLs at the Firewall/Proxy of your network. Other workarounds may not work as best as white-listing the product.
Agents / Daemon can be routed to submit their scan data through a Proxy. You can route the Daemon via its setup wizard interface. You can route the Agent out with the command-line option '-x proxy:port'. You should use the SVM Agent proxy logic workflow that shows how exactly to install it against a Proxy.
This routing is custom and it's done by setting proxy forwarders (f.e. in the registry) that directs all Agents or Daemon outbound traffic to the correct Proxy server that makes sure the path to CRL servers is cleared, at least to the best of your controls. Your job is to get it bypassed through your network.
The following figure shows a Wireshark trace example of a CRL verification request sent by SVM Daemon.
The Agent can be routed in many ways as you have seen in the other KB which we referenced above. The simple way of forwarding the Agent for testing purposes and recommended the first use case is:
csia.exe -c -x <192.168.10.102>:<8888> [-x proxy:port]
As part of each request for data submission to its master server where it submits all data, the Agent or the Daemon will execute a parallel security validation of the target server's SSL certificate.
CRL checks are a security mechanism used for non-repudiation purposes that is used by Windows and the Software Vulnerability Manager functionality as a whole to always make sure that the target server receiving the data is not a bogus one, that is the intended server where scan data is correlated, and that customer data is protected at maximum. Everyone should consider CRL highly in terms of security .
In some circumstances, the Agent will call Windows CryptoAPI that will then send the CRL traffic through WInHttp, while the Agent is at the same time using WinInet (if that is what you configured as default). Then, your connection settings will all look good, but in essence, the Agent will be routing CRL to a wall.
When the netsh configuration is set to Direct, but there's a proxy you have configured for the Agent with the -x command-line parameter, the Agent is acting as a router and sending the different requests to their predefined path. Since the netsh configuration is the default proxy configuration on Windows, one of the two required network routes is closed since "Direct" will send the Agent packets to no avail.
To see the Windows default Network Shell proxy configuration:
netsh winhttp show proxy
To configure the system default winhttp proxy to a different server:
netsh winhttp set proxy = <proxy: port>
When the Agent, Daemon, or LocalSystem proxy netsh configuration is set wrong, you will see:
WinHttp request (12175); status = 499 - "A security error occurred".
Steps To Reproduce
Replicate with SVM Daemon:
Perform these steps on a test host! 1. Install the Daemon on a client and configure the correct proxy forwarding in the installation wizard. 2. Stop the SVM Daemon service. 3. Go to Windows Registry and enable maximum verbose logging for the SVM Daemon. 4. Block the IP address at the local Firewall for the below sites (use ping to get their regional IPs):
5. In the elevated command-line interface, execute this command to clean the LocalSystem URL cache:
certutil -URLcache * delete
6. Configure LocalSystem to forward WinHttp requests through 'Direct' instead of using the right Proxy:
netsh winhttp reset proxy
7. Restart the Daemon service and wait for some time until it performs few requests that will fail.
Replicate with the SVM Agent:
Perform these steps on a test host!
1. Block the IP address at the local Firewall for the below sites (use ping to get their regional IPs):
2. Clean the local machine cache:
certutil -URLcache * delete
3. Configure your system to forward WinHttp requests through 'Direct ' instead of your actual Proxy:
netsh winhttp reset proxy
4. Run a scan with the SVM Agent in an elevated command line:
csia.exe -c -x <YourProxy>:< YourPort>
At this point, the Agent will fail almost instantly with the WinHttp 12175 "A security error occurred" msg.
In environments where Proxy is actively used you shall re-direct your Agents / Daemon traffic through the correct proxy server using the installation interface of the Daemon, or command-line for the Agent. You can also deploy a crafted Agent package with Proxy configuration directly through WSUS/SCCM.
Your organization should ensure that URL addresses required for CRL verification of all Agent hosts, the SVM front-end interface plugins, the SCCM Plugin, and the SVM Daemon are whitelisted at the corporate Proxy and Firewall, and you should certainly avoid using content-inspection SSL filtering.
You can configure the Time-To-Live packet settings at your proxy to define how long should one CRL record be kept alive at the proxy server. Flexera recommends increasing this setting for the CRL sites to 7 days because this will ensure that your hosts can verify CRL directly against your proxy and may not even send the requests outside. The URL data will be re-cached once per 7 days by the Proxy server.
Disable Certificate Revocation altogether
Go at the registry and navigate to HKLM at:
SYSTEM\CurrentControlSet\Services\Flexera Corporate Software Inspector Daemon\
Double-click on "Image Path" entry and append at the end of the line after the "--service-launch" entry:
--ignore-crl --ignore-ca --ignore-an
Restart the SVM Daemon service under services.msc for the changes to take immediate effect.
You can install (run) the Agent with additional ignore settings, but Flexera discourages you from doing so. That will disable CRL check altogether for the Agent, but it could be used for getting a quick fix.
--ignore-crl --ignore-ca --ignore-cn
On rare occasions, the problem would simply be that the Service Account under which Agents / Daemon is being run on Clients is not permitted to send traffic externally. Confirm that the Service Account (or LocalSystem) is granted the ability to bypass the Proxy and send traffic to Flexera Cloud (https://*.secunia.com).
Related KB Articles
Summary : This article helps you to create your own code signing certificate with an internal PKI structure which you can use for signing the SVM 3rd party packages. Solution: Please look at the following Flexera Level 400 using your own certificate training video. This will help you create your own code signing certificate for signing the SVM 3rd party packages. https://www.youtube.com/watch?v=ILkt1esNRIQ&feature=youtu.be
Symptoms: Internal Error 500 after the publishing of the SVM 3rd party packages. The package gets published but unable to edit the published packages.
Diagnosis: The following issues appear when the sps_packages table is missing/not complete or the SVM on-premise has been updated to latest version but the following table sps_packages have not been updated correctly. Please follow the below steps to verify the issue. Log in to your DB server
mysql -u root -p
Check the ca.csi_pdb_info table if you are on the latest version of SVM-on-premise.
select * from ca.csi_pdb_info;
Please Note: If you already at the latest version. then follow the solution steps otherwise, first try to update your SVM on-premise to the latest version. Solution:
Select the private DB which ends with your server customer-id.
select the count of sps_packages table and check if have any count value.
select count(*) from sps_packages;
If the count is Zero then execute the below commands.
drop table sps_packages;
CREATE TABLE `sps_packages` ( `id` int(11) NOT NULL AUTO_INCREMENT, `account_id` int(11) NOT NULL, `guid` char(36) NOT NULL, `xmlText` mediumtext DEFAULT NULL, `package_type` tinyint(4) DEFAULT NULL, `product_id` int(11) DEFAULT NULL, `product_name` varchar(255) DEFAULT NULL, `vendor_name` varchar(100) DEFAULT NULL, `secure_version` varchar(255) DEFAULT NULL, `min_version` varchar(100) DEFAULT NULL, `patched_version` varchar(255) DEFAULT NULL, `architecture` tinyint(3) unsigned NOT NULL DEFAULT 0, `version_rule_id` int(11) DEFAULT NULL COMMENT 'Version Rule Id to keep track of the packages/solutions related to the insecure installation', `sps_params` varchar(500) DEFAULT NULL, `created_at` datetime DEFAULT NULL, `vpm_id` int(11) DEFAULT 0, PRIMARY KEY (`id`), UNIQUE KEY `guid` (`guid`), KEY `guid_idx` (`guid`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Symptoms: The SVM agents are showing check-in date and time in single host agents tab but the last scan field is not updating.
Solution: Log in to your SVM on-premise Linux server via putty session and check the below things.
Check the space at the server with the following command: Df -h If the server didn't have enough space available, please try to add more space at the SVM on-premise Linux server.
Check the scan daemon service if it is running fine: service scandaemon status if the scandaemon service is not running then please execute the following command: service scandaemon start
You have performed scanning of Clients with the Software Vulnerability Manager after installing a brand new server instance, or after performing a server upgrade from a lower version, but the scans are not being returned in the Web UI view under Completed Scans after these are being sent to the server. At first sight, the Agent/SVM does not indicate a technical problem with sending the scan result.
This article teaches you to create and configure an SVM agent uninstall task sequence that can be deployed to domain clients using SCCM which will uninstall SVM local agent installed on them.
You can use a task sequence in SCCM to execute a commandline command to target machines. The command used will uninstall the SVM agent from the host machine.
In SCCM "Configuration Manager Console" navigate to Software Library > Operating Systems > Task Sequences. Right click on Task Sequences and "Create Task Sequence".
When choosing "Select a new task sequence to be created" select Create a new custom task sequence. Click Next.
Give it a Task sequence name. Click Next.
On Summary Step, Click Next.
On Completion Step, it should say "Success: The task sequence has been created successfully." Click Close.
Back in the Task Sequences View, Right click on the newly created task sequence and "Edit".
Click "Add" > "General" > "Run Command Line"
Set the "Command line:" field to:
Set the "Start in:" field to:
C:\Program Files (x86)\Flexera Software\Corporate Software Inspector Agent
Hit the Ok button to save.
Right Click on the Task Sequence > "Deploy"
Deploy as needed to Collections.
Software vulnerability Manager 2019 On-premises edition for Ubuntu operating system which is provided as Virtual Appliance (VA) and the RPM for RHEL 6 Operating system is end of life. Flexera will not release newer versions for these operating systems. Upgrade your operating systems to the latest supported versions.
We will not release the R10 version, which includes patch automation for Ubuntu-based Virtual Appliance and the RPM for RHEL 6 operating systems. We recommend our customers upgrade their operating systems to the relevant supported versions.
Ubuntu 14.04 LTS
Ubuntu 14.04 LTS reached end of life on April 30, 2019. We recommend our customers upgrade to newer and supported virtual appliance which is based on CentOS 7.
CentOS VA migration from Ubuntu VA
Red Hat Enterprise Linux 6 version is also end of life. We recommend upgrading your operating system to RHEL 7 which offers more features and extended support.
Further documentation and installation guides are available on our helpnet site. Please contact Flexera Support if you need further assistance.
You have published Software Vulnerability Manager patches to System Center Configuration Manager and the patches had installed nicely on corporate systems. The System Center server is showing the packages' installation statistics, but the "Available" menu in the Software Vulnerability Manager does not seem to reflect that data and you cannot evaluate installation success from the SVM interface. How do you make the Software Vulnerability Manager read the SCCM data and reflect it?
SVM normally reads the installation data from the WSUS database. SCCM does not mandatory push installation statistic data to WSUS unless you enable that optionally in the Software Update Point configuration of your SCCM server after having planned how much data that will load at the WSUS DB.
1. Open the SCCM Administration console and navigate to the Software Update Point configuration.
2. Enable the WSUS reporting events on the first page after the configuration window opens.
When using the SVM application with an on prem server infrastructure, you may experience the application locking up. The root issue of this can possibly be a problem with the vuln_track database since the functionality of the application can rely heavily on the health of this database.
Many times, the best way to debug a technical problem with the Software Vulnerability Manager Agent scanners is to create a log file that shows what the Agent does and where it fails to submit the scans. The log file is the fastest way to diagnose and evaluate the Agent performance, and the issues that block it.
In the vast of cases, customers prefer to run the SVM Agent under the LocalSystem account as the recommended practice by Flexera goes. However, this makes it harder to debug the Agent manually using manual CMD commands, because as soon as the user opens CMD with their account, the Agent runs under their user's context, and not as it is installed under the LocalSystem account, therefore possibly yielding different test results as it would have generated if the test is ran under LocalSystem.
To go around this problem, you would enable logging for the SVM Agent without using the command line, by appending logging on the fly at the Agent configuration settings at the Windows registry.