* Posts by RJX

14 publicly visible posts • joined 8 Jul 2009

More Ivanti attacks may be on horizon, say experts who are seeing 9x surge in endpoint scans

RJX

Re: This probably is astonishingly easy to defend from

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.

RJX

How to enable client cert authentication in years past with Pulse Secure (now Ivanti)

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.

RJX

This probably is astonishingly easy to defend from

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.

AWS boss: Don't want to come back to the office? Go work somewhere else

RJX

"Return to office" and "working together" are a smokescreen for cutting employees

Our HR department started spouting that nonsense at an "all hands" meeting about how being in the same building fostered cooperation and achieved better results. When they asked for questions I raised my hand and asked if that meant we were not working cooperatively and were getting poor results when working with our fellow employees in other offices. I then helpfully added "Because you know, we're really working remotely with them and they don't know if we're in the office or at home."

That was the last meeting I was invited to during my two week notice of quitting. :) Everyone was thinking it but I was the only one who could say it out loud without fear of repercussions. I probably got the check box for "Do not rehire" checked. Don't care because there were many reasons why I quit.

IBM Consulting is done playing around, orders immediate return to office

RJX

Blah, blah, blah. Amazon tried the same thing and had to modify their policy to tell people they may not get promoted. How old generation is that thinking, even forgetting that IBM is a corporate dinosaur?

To all of the execs and managers talking about working effectively and collaboration being the reason, how many office locations do you have? Because every time an employee in one office works with an employee in another office it's the same as working remotely. That has not hurt companies a bit.

JPMorgan exec claims bank repels '45 billion' cyberattack attempts per day

RJX

The one thing I was certain of before I retired from bank cybersecurity was that the numbers reported publicly were woefully low. For people who pooh-pooh things like port scans, let's do an analogy to your home. A port scan is the same thing as an unauthorized person walking up to your home and trying every door to see if it's unlocked and pushing on every window to see if it opens.

If you looked out the window at night and saw an endless stream of people walking up to your home and trying to get in how good would you sleep?

Familiarity breeds contempt and that's how that article and some of the comments read. We'll be reading about your organizations over at www.databreaches.net if we have not already done so, multiple times.

Ivanti zero-day exploits explode as bevy of attackers get in on the act

RJX

Meh. Just convince management to let you do your job the right way.

We deployed the predecessor, the Juniper remote access version. Then we upgraded to the Pulse Secure version when Juniper spun them off. And now it's the Ivanti version.

We have as close to a zero percent chance of an RCE or any other compromise as there is regardless of patch status or version. How did we do that?

It's dirt-simple to require a client certificate on the connecting computer in order to even connect to the port of the remote access box. We spun up a Certificate Authority for all remote connections (remote access, API, whatever) and we require a client certificate to even connect to the port. No cert means you don't even get a banner, just a dropped connection because you can't get past the port to anything else.

As a bonus the remote access log files drop to almost nothing because even scanners and attackers won't get logged, just connections with the proper client certificate. We can still see the unauthorized connection attempts in the firewall logs but not in the Ivanti logs.

In the words of a major pen testing company (that almost anyone in the business would recognize) when they could not do a thing to us:

"NOBODY DOES THAT!"

And that's the problem. We have a few thousand client certs authorized and the rest of the 3 billion people on Planet Earth with Internet access think nothing's there even if they dial up the URL.

Suits ignored IT's warnings, so the tech team went for the neck

RJX

Haha, did the same thing to the CIO, with his approval

All plants were connected to to HQ with a lousy T1 yet he had 100 M/bps connectivity. He got tired of the complaints and said 1.5 M/bps was good enough for anyone. Since he had a DHCP reservation we used QoS to throttle him to T1 speed. After three days he threw in the towel and approved the connectivity upgrades.

Automation is great. Until it breaks and nobody gets paid

RJX

Had automation delete the entire Accounting department. Twice. In two days. And...

Reviewing my overnight security alerts before heading into work showed that every account in the Accounting Department was deleted at 7:15 AM. Odd. I went into work and asked my team members what happened. Blank stares as they scrambled to check the alerts they ignored. The security manager chuckled when he came in and said "Apparently we don't need an Accounting department."

The sysadmins, being sysadmins, recovered the accounts from the AD Dumpster, pronounced it a "glitch" that had never happened before so it would not happen again and they would do nothing else to investigate.

Yup, the next morning at 7:15 AM the entire Accounting Department got deleted again.

Now everyone is taking it seriously. Now.

At a meeting that afternoon they said the mass deletion was caused by a script they wrote to sync Oracle HR with AD, a script that ran at 7:15 AM. The script erroneously assumed that if a department did not have a manager then the department did not exist. So rather than just disabling the accounts it deleted them.

Turned out the Accounting Manager had gone on medical leave so he was removed as the department manager, leaving that position blank in Oracle HR.

Everyone in the meeting thought it was good they they had found the problem and prepared to leave because it really was no big deal, right?

Until I said "Wow, it's a good thing the CEO didn't go on medical leave, right? That script might have deleted every account in the company!"

Heads turned, faces got a shocked look, and that's when the sysadmin manager admitted that was exactly what would have happened.

---------------

Then they did a similar thing years later. They wrote a script to delete ex-employee Exchange mailboxes 90 days after the employees left the company. It worked great, until it didn't.

We were in a legal battle and there was a court order to preserve certain mailboxes for legal discovery. Some of the mailboxes were for departed senior managers. Their script dutifully deleted their mailboxes after 90 days because everyone forgot about it. Then the archive purge killed the backups some months later.

Then we were ordered to produce those mailboxes and Whoops! Their little automation script caused a massive legal problem with the court, you know, destruction of evidence...

Finally, after that disaster, senior managers ordered the sysadmins to put EVERY script they used into the Source Code system where they needed to check scripts out to use them or to modify them. The sysadmins whined and they got told that all code run on production systems was programming and now need explicit manager approval via a Change Control ticket, so they made it worse by complaining.

Security needs to learn from the aviation biz to avoid crashing

RJX

Re: Until someone has to go to jail for doing it wrong?

I spent a quarter-century in corporate aviation maintenance, avionics and electrical specifically. I then moved into IT and was absolutely appalled at the practices. I still am 20 years later.

One "threat of jail" that actually worked was Sarbanes-Oxley in the US. SarBox had the threat of jail for the CEO and CFO.

Due to our fiscal year end date we were in the very first group that had to comply. The CEO and CFO were in learning mode a lot. A lot of sloppiness was corrected because of the threat of jail. The same thing was experienced when I worked for a bank in IT security years later.

In aviation, the way cockpit voice recorders and flight data recorders got the blessing of the airline pilot union was a federal law guaranteeing that neither could be used in enforcement actions.

The ISACS in the US are good for info sharing but sharing needs to lead to learning and too often companies do not care until they get smacked upside the head by an incident.

Oracle to release on-prem software usage tools to prep cloud switch

RJX

Yeah, no kidding. That was the first thing to pop in my mind as I read that article. But I've experienced it myself. Managers become so enamored with a vendor that they refuse to look at alternatives. Then they retire and the new person is appalled at how much the company is paying, finds a new vendor/product, and hundreds of thousands of dollars or more are saved annually.

At one company that used AT&T forever, the telecom manager finally retired and the new person, who had experience from other companies because they had not been there for decades, was totally shocked. They started auditing the AT&T invoices and finally convinced AT&T to send in their own person to audit their own invoices. (AT&T refused to believe her audit.) There was a quarter of a million dollars in overcharges found by the AT&T person. Per year.

It's kind of like home and auto insurance companies. Once you finally get upset at the price increases and begin looking at alternatives, you discover you've been way over-paying for less coverage.

BOFH: Putting the gross in gross insubordination

RJX

Kind of hard for a satellite to track someone inside a building. You'd have to nuke the whole building from orbit.

RJX

Exactly, that's the beauty of it. Apple devices will warn you if they detect you're being tracked by an AirTag that's not yours. Android devices have a scanner app available but it must be run manually.

CompuServe signs off

RJX

Trivia: Why were no digits higher than 7 used in CS IDs?

Because the original computers used by CompuServe used octal and not hexidecimal.

Regards,

72270,650