More Ivanti attacks may be on horizon, say experts who are seeing 9x surge in endpoint scans Ivanti VPN users should stay alert as IP scanning for the vendor's Connect Secure and Pulse Secure systems surged by 800 percent last week, according to threat intel biz GreyNoise. The team at the internet monitoring company said this is the kind of pattern that usually precedes exploitation and public disclosure of new …
Secure by design, pfft. They don't know what that is and they certainly don't think its important.
They were told of an internal application username and password being sent to syslog on an error condition, They dismissed it.
Do you know how old that password was? Based on what it was, I'm sure it had not been changed since it was created 20+ years ago.
I started with the product when it was Juniper SSL VPN and later Pulse Secure so the capability likely still exists in their firmware.
The ports have the ability to be configured to require that a client digital certificate be present on the connecting computer. No cert = no access. By "no access" I mean you do not even see a login page.
I did this for remote access for a thousand-plus employee company and once it was implemented we had zero people complaining they could not access the system so it is a remarkable stable capability. Even better, the device logs do not even record the attempt so the logs are far, far smaller and only legit traffic shows up. We used the perimeter firewall logs to see who was scanning the device or otherwise trying to gain access without a cert.
While we stood up a standalone CA solely for remote access, in a pinch someone could use the AD client cert likely already present on all of their computers. If you allow the use of personal devices you're already in a bit of hurt but that is easily handled by issuing the people their own cert and directions on how to import the root and the client cert into their device. We used our "secure" HTTPS-based email system to deliver the certs.
During a pen test by one of the most respected companies in the world they made zero progress. I even told them exactly what I did and they still could not get past the client cert requirement.
As Carl Sagan used to say, paraphrased, there are "billions and billions" of possible IP addresses in the world and you just locked every IP address out of your remote access if they do not have a cert issued by your CA.
Good luck.
PS: This technique also is an excellent way to restrict access to other systems without relying on the source IP address. We had partners that changed to AWS IP addresses, for example, and they said we needed to allow all IP addresses associated with AWS East. Yeah, no. What we did was stand up a separate URL to access our APIs and attach a client cert requirement. Then we issued them their own corporate client cert. Once the contract or engagement ended we simply revoked their cert and their access was locked out.
I'm sure there are other uses we never thought of.
Certificate-based access is definitely the way to go, and i reckon anyone who uses Ivanti has the infrastructure to set up their own CA. (if you're pedantic, technically everyone has the infra to set up a CA)
Handing them out to people via e-mail is not ideal, also because you don't have control over the device (or anti-virus for that matter).
But sometimes you just need to make things work, and you massively reduced your attack service and made logs a lot easier to investigate.
I'm not sure why that would matter because it didn't matter to us. It sounds like you're not using a two factor system like SecurID to login to remote access. If not, adding the client cert adds a second factor.
The client cert simply got people access to the system so they could then login by SecurID and then access the backend system they were logging into. Essentially, the way I did it the client cert was used as a third factor: Client cert, SecurID username, SecureID token code.
I apologize for not seeing your earlier post. I just added the instructions on how I did it. Maybe those will help someone else as well or maybe help you figure out what the difference in the implementation is.
This may not be exact nowadays but should get you close enough:
Import the CA Root certificate in .cer format into Ivanti.
System -> Configuration -> Certificates - Trusted Client CAs
Click Import CA Certificate…, browse to the CA Root certificate location, select it, click Open and click Import Certificate
--------------------------
Create a Virtual Port on a different private IP address than the Internal Port (assuming you're using NAT on the perimeter firewall). The Internal Port will continue to be used by people who do not have a client cert yet until you block its public IP address on the firewall.
The Virtual Port is bound to the physical Internal Port but will have a different PUBLIC IP address and will require a trusted client certificate to connect to it. Or, if everyone already has a client cert, just move the external URL/public IP from the Internal Port to the new Virtual Port and immediately take the next week off of work. :)
Network -> Internal Port - > Virtual Ports
Click New Port…, fill in the parameters and click Save Changes
Clicking Save Changes causes an automatic services restart on the appliance.
-------------------------
Set the new Virtual Port to require a client certificate to connect. This is the sole change needed to enable or disable client certificate authentication if there is a problem connecting.
System -> Configuration -> Security -> SSL Options
Move the new virtual port you just created to the right-hand column.
Click Save Changes
-------------------------
Now we need to bind the appropriate User Role so it uses the new Virtual Port we just created instead of the Internal Port.
User Roles -> (remote access role name) -> General -> VLAN/Source IP
Change the Select Source IP: setting from the Internal Port IP address to the Virtual Port and click Save Changes
Congratulations! Client Authentication using a digital certificate is now enabled.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
