We have a HA cluster, activpe/passive even, and we literally loose 0 ping packets. Obviously there is packet loss, but the downtime is sub 1 second. Patching Forti is not really a problem IMHO. Just gotta stay on tested and tried minor versions, but always up to date bugfix version.
Yeah, it’s been rough keeping up with them lately. At least I’m out of the MSP game now, so I only have to patch a handful of firewalls now, instead of dozens of them!
Yeah, but compare Fortinet to Palo’s CVSS Scores:
Tomorrow, all will be revealed… cross fingers…
So regular non-MSP customers are no longer privy to advance notifications?
Advanced notifications for some. We move a decent amount of FortiGates and received zero notification. I will definitely bring this up with our FortiNet contact, because this is unacceptable.
But just for the sake of information: How did you receive the notification? Mail, phone, etc.
anced notifications have always been subject to TLP classification; most like these are a “need to know basis and no more”. Recently FortiNet have moved these notifications into higher tier services such as Elite Support/MSSP certified partners. It is more likely that quit
no firmware yet for me! 6k/7k chassis with SSL-VPN enabled. Working on approval to shut that down until we get firmware an/or see the PSIRT
Yeah, i saw that. They do say the risk is mitigated if SSL VPN is not enabled in the blog post. They left that out of the PSIRT write up though, which leaves me wondering if there isn’t more to that story…
According to the FMG compatibility matrix, FortiOS 7.2.5 is supported by FMG 7.2.3, so as long your Fortimanager is up-to-date on that version, managing the firewalls post-update should not be an issue.
Well, I don’t work for Fortinet, but if I had to guess, I would say to allow admins an opportunity to patch devices ahead of disclosure of the vulnerability. That seems like a reasonable conclusion to me.
Bottom of the article:
"Timely and ongoing communications with our customers is a key component in our efforts to best protect and secure their organization. There are instances where confidential advance customer communications can include early warning on Advisories to enable customers to further strengthen their security posture, prior to the Advisory being publicly released to a broader audience. This process follows best practices for responsible disclosure to ensure our customers have the timely information they need to help them make informed risk-based decisions. For more on Fortinet’s responsible disclosure process, visit the Fortinet Product Security Incident Response Team (PSIRT) page: https://www.fortiguard.com/psirt_policy."
Fortinet is known to push out security patches prior to disclosing critical vulnerabilities to give customers time to update their devices before threat actors reverse engineer the patches.
Because all decent providers receive advanced notification, so should have already completed or be in the process of patching to mitigate this vulnerability if equipment is affected. The firmware is released, a few days of grace period, then disclosures are dropped.
The exception is if the exploit is in the wild. With this scenario however, Fortigates now support virtual patching on management interfaces,so Fortinet will be able to push fixes for most future vulnerabilities via FortiGuard automatically with no patching needed.
For a recent high criticality update, a lot of customers were irritated that the bug was disclosed before the updates were made available, as this led to rapid reverse engineering of the patches and lot of overtime at various service providers playing catch up and calming confused customers.
Just disabled it today!
If all you’re going off of is number of CVEs, you’re better off going with Fortinet. Not only has PAN-OS had more vulnerabilities over the past few years, but the number of critical vulnerabilities is much, much higher as well:
Source: https://www.cvedetails.com
Palo Alto is a great firewall, but the grass isn’t greener on the other side of the fence.
You will find your options for enterprise NGFWs to be pretty limited.
Yes, if SSLVPN is completely disabled. no portals, no ports open, fully restricted, then you are fine even if it’s unpatched. It’s an auth bypass vulnerability, can’t bypass the auth if you never open the channel.
Yes this is a vulnerability in SSL-VPN daemon, if the interface is unreachable then nothing touches this process. Fortigate will usually turn down ssvpnd process if it is not configured.
Official announcement is scheduled for tomorrow. I expect you’ll see the PSIRT shortly after.
For site to site device or user’s mobile connections? When our users were using IPSec they’d get blocked at some locations. SSL alleviates that, but not without compromise (pardon the pun) as we see here.
I think for hub/spoke connections IPSec is preferred. We use it for a persistent connection to AWS.