We recently replaced a firewall which prompted running an external scan against our Network. This uncovered vulnerable cipher suites in our current Kaseya 9.4 VSA. A Google search lead me to editing KaseyaEdgeServices.config from instructions for version 9.3 and experience lead me to run IISCrypto. Using the recommended KaseyaEdgeServices.config did not seem to remove all the vulnerable Cipher Suites and disabling TLS 1.0 through IIS Crypto broke communications between the VSA and the database...so I reset everything to default.
Is there a knowledge base article on properly removing vulnerable setting from VSA 9.4 and/or is 9.5 more secure or easier to lock down? Things have stabilized enough we will probably bite the bullet and move to 9.5 soon but I suspect the issue will still be there.
TIA for any insight you can offer.
You'll need customize config from support -- i have yet to test this but it worked the last time we did it, and it got reset when we updated VSA. I just got this config file from support earlier last week (although it does NOT disable TLS -- unsure if you can without affecting the edge/iis interactions) :
"ListenPorts": [ 80, 443, 5721 ],
It still only rates a B from SSL Labs but our external scanner doesn't report any available exploits any more. I appreciate the help.
We used the KB artical helpdesk.kaseya.com/.../115001229112
And it broke the on-prem VSA. Had to open a ticket with Kaseya and they had to redo the SSL cert and a few other things. Appears three kaseya services no longer were able to start once we put the new config file in production and had to revert back. Even reverting back, the services did not start and the VSA was inoperable.
Had to open a second case with Kaseya for them to review the first case and update the KB doc to include this possible issue.
Am in waiting mode now for them to review.
Yes, i found with ours that TLSv1.0 is needed to communicate with the database so it cannot be disabled. In the config provided in that script you would need to change it to "DisableTLSv1_0": false,