Sophos Firewall: v19.5 MR2: Feedback and experiences

Would be a relief to be able to also use FQDN objects in ACL exception rules, so you can use a DNS entry for proper remote support address maintenance

Hello ddcool,

a FQDNs have long been supported in ACLs...

Regards

alda

Yes - every kind of objects should be consistently avaliable through all of Sophos firewall. This is a must-have!

Overall, this release is not to tackle the way, how Customers/Partner work today. So if you are doing access to your firewall like that "today" it will not change anything.

It is only to automatically increase the security of all customers, who do not use it at all. If you are not using WAN for 90 Days, likely you wont use it at all. So customers will get a setting removed, which highly reduce there attack surface at no cost. 

Sophos is working on a way to improve the product in the future for partner access and customer access. And there are multiple approaches to this situation, like described above. 

But those approaches are not covered in this Release, it is only to reduce the attack surface for all customers, who are currently not using it. 

Do you mean SSL VPN access? The way this update reads to me, if nobody connects to the User Portal in 90 days, that user portal will have WAN access turned off. And the User Portal is necessary for Sophos Connect. Plus, I don't like turning on SSL VPN on firewalls that don't need it, as, well... It's a security risk, after all.

Or do you mean access over IPSec tunnels? I really don't want to make > 1000 tunnels manually. Plus then I have all my customers cross-connected, so, that's a pretty big security risk.

Using the Access means a successful Login. 

SSLVPN and IPsec VPN is not impacted by this change. 

Sophos Connect does not need User Portal. The User Portal is only needed, if the OVPN does not work, or you need a OVPN in the first place (It will connect to the User Portal and download the OVPN). This process will be reworked in the next major release. 

We make changes to the SSL VPN settings here and there that require a new .ovpn file for users. I'll admit that I love Sophos Connect for this, since the changes essentially auto-deploy. Are you saying that a successful Sophos Connect connection won't necessarily reset the 90-day timer on User Portal access?

I may not be sure what you're referring to when you say "Using the Access" though. If Sophos Connect only defaults to pulling the .ovpn file when the locally cached .ovpn settings fail, then accessing SSL VPN won't usually reset the User Portal 90-day window. If it pulls the .ovpn settings every time in the background using the User Portal, then it would reset that window.

Ultimately I just want to know the best way to keep WebAdmin and User Portal access going for my clients where it's only used maybe a few times a year, and from possibly-changing public IP addresses. I can update an FQDN as needed for WebAdmin, but we've had clients in the past go from SSL VPN users connecting once a year, to once a week, because they transitioned some people to WFH. We can go in and re-enabled when this happens of course, but it's hard to explain to the clients why their SSL VPN stopped working if it's by design and can't be changed.

We would just prefer it stayed working, but just be hardened instead. Public-facing logins can be pretty locked down with industry standard stuff: 2FA, Captcha, geo-blocking, failure timeouts and IP auto-bans, active check-in and monitoring with error reporting, third-party code reviews, etc. Much of this is already implemented, but just not fully tied together.

RCEs happen. Geoblocking, 2FA, Captcha etc, cannot protect you against 0Day RCEs. Generally speaking, your strategy should be to keep services unavailable, if not needed. 

Every successful login to user portal / webadmin will reset the timer. So essentially, if you need to change the config of OVPN in generell, you could enable the user Portal again. By the way, as mentioned will there be a new way to download the config in the future without the User Portal. 

I agree that no software or hardware is perfect. Bugs happen, and it's impossible to say otherwise in any solution. And I don't like keeping access open when not necessary, especially in a security device. The smaller the surface area, the safer!

I'm just saying that the tools aren't finished yet to maintain management. (FQDN in ACL rules, and multi-tenant rule deployment.) We really, really need those tools to retain manageability across > 1000 devices. As FQDNs are not available in ACL rules, we have to manually update all our firewalls in case of an access IP change.

We currently rely on SSL VPN with 2FA as our backup access. As that doesn't get accessed much for firewalls that don't need SSL VPN, the .ovpn files can become outdated, since the process to retrieve them isn't automated. That makes our backup access unreliable going forward. It also means that the user portal needs to be turned back on and off manually any time a client needs to add a new remote-only worker, or anytime an existing worker needs to use SSL VPN if they haven't used it after a change that triggers a new .ovpn file.

Usually the latter gets discovered by a user after-hours, so this will trigger an increase in after-hours support calls for us. A way for Sophos Connect to not need the User Portal is also needed ASAP for these scenarios, and should have coincided with this charge.

I want to note that I'm not trying to be argumentative for the sake of argument. I applaud the charge to disable WAN access in a default deployment for the people who just drop in a firewall without actually understanding the necessities of security. I'm just arguing for a focus on the features needed for those of us that manage multi-tenant deployments, which is pretty much every MSP out there. Shutting down other access should be done *with* the roll-out of other solutions, not when in a "coming soon" state.

We will not install the update for our customers for precisely these reasons. We don't care about the user portal itself. But the VPN configuration must be able to be retrieved or updated at any time.

Gerhard Seemüller said:

We don't care about the user portal itself. But the VPN configuration must be able to be retrieved or updated at any time.

I raised this issue in this post - Sophos Connect and delivery of configuration via User Portal

At the time, Karlos reported that Sophos plan to change this behaviour:

"We've brought your concerns up internally and our Development Team is currently in the works for a new method that would eliminate the need for the User Portal to be exposed on the WAN for SSL VPN RA use. We plan to implement this in the future release."

Can someone at Sophos confirm that this is still planned?

 JasP  - Yes, that feature is being worked on and is planned for v20.0

 JasP  - Yes, that feature is being worked on and is planned for v20.0

Giridhar Katti said:

JasP  - Yes, that feature is being worked on and is planned for v20.0

Thanks for confirming that, it is good to hear.

I was a little concerned that with the changes in this release regarding WAN access, that this had been dropped, and the current changes were regarded as a solution to the problem, which they clearly aren't for this particular issue.

How long do we have to postpone updates then?

You shouldn't have to postpone updates. You can keep the WAN access to the user portal with an ACL rule like this:

Or even better, if you know that VPN access only comes from specific countries, lock down the Source Network to only those countries.

I'm curious if that won't be overwritten.

No, ACL rules won't be overwritten, even if User Portal is not actively being used on WAN. 

However as others have said, keeping User Portal or Admin open on WAN when not required/in use is a security risk, and not recommended.

Good to hear. It is necessary for VPN provisioning. In some environments, the user portal is also used for clientless access connections, so turning it off is out of the question.