Restricted Advance Shell - examples of challenges

The logviewer is way to slow, during troubleshooting I definitly need the console ability.
Expressed other way around - I see NO acceptable reason to deactiviate it.
Thats independant of licensed / not licensed !
Our technicians are using the home-license for their home and family, like it's planned and for troutbleshooting the cli is needed - definitly.
I can't understand the reason behind thinking aout disabling that feature...

I've done a little research and I really don't think any major competitor offers unrestricted shell access to their underlying OS. Fortinet's CLI is not a UNIX shell, it's a highly-restricted shell similar to Sophos' CLI, and it's my impression that other competitors are similar.

So in that sense, Sophos has been offering something that their major competitors haven't and they're now saying they are moving towards withdrawing it. I can also imagine that security-wise, the Advanced Shell is pretty much impossible to audit well. A much-restricted, custom CLI (such as Sophos has and Fortinet, et al, offers) would make a lot of sense from that direction.

That said, Sophos needs to not just enhance their GUI -- which is the point of this thread -- but also enhance their CLI so that log viewing, traffic monitoring (iftop) and other real-time tools are available for the kind of troubleshooting you're talking about. (ASCII-based tools may be primitive, but they are fast and low-overhead.)

@Billybob No, I get it. You're hung up on an inconsistency between something they give away for free and something they pay the bills with.

But you are assuming this is the end of it. No more shoes dropping. I had assumed that (it didn't bother me is it does you) but someone in this long thread pointed out the obvious sequence I hadn't seen: this is the first step towards Sophos eliminating Advanced Shell in all products. Advanced Shell is not offered by Fortinet, PAN, Cisco: they offer a CLI. That's "industry standard" and it's less error-prone and more secure than shell access.

So it makes sense that "not industry standard practice" is real, and they're staging their way to eliminating it. They suspect they're close for simple use cases (i.e. most home use), and know they're not close for paid users. So eliminate it entirely for home users, gather feedback of things that home users commonly do that are impossible without shell access, and fix it: better logging, extra checkboxes and parameter fields in the GUI, add a commend or options to the CLI.

Once they get past this, then the next step is a big one, and will probably require substantial beefing up of the CLI. That step is to eliminate shell access even for paid versions. Better to put as much into the GUI as they can first, but what doesn't work well needs to go into the CLI. Then they eliminate the error- and exploit-prone shell access. which aligns with their commercial competitors.

@Samuel: You're reading something here that wasn't said. A CLI is highly restricted compared to unrestricted shell access. By definition. And for reliability and security reasons. You are restricted to only doing things related to legitimate firewall/routing tasks. The Advanced Shell lets you do anything: delete files, edit logs, exfiltrate arbitrary information, install arbitrary software.

So, yes, highly-restricted -- in a good sense. The fact that Sophos has had to allow direct shell access is itself an indictment of other parts (GUI and CLI) of their system.

As for Fortinet powering up/down more reliably or other issues, that's a separate issue.

Wayne Folta said:

Advanced Shell is not offered by Fortinet, PAN, Cisco: they offer a CLI. That's "industry standard" and it's less error-prone and more secure than shell access.

Checkpoint offers a bash shell on all their firewalls over the "expert mode". (TAC endorser's people to use It; They even have a full documentation on how you can use bash to do fine-tuning over kernel parameters for better performance.)

On Fortigate you can execute some commands such as ls, kill or cat with "fnsysctl". (You can do a lot of debbuging with it.)

Cisco Firepower also have an "expert mode" which gives you shell access. (Not recommended by Cisco, also you're alone if you make any mistakes on it.)

PAN never offered a shell access, but their CLI always worked well. (Different from Sophos.)

*Just some of my thoughts...

Thanks for the specifics. I've been going on my impressions, not based on usage.

`fnsysctl` isn't a shell, though, right? It lets you run certain commands. But that's pretty much par for a CLI. They're going to eventually call out to actual commands, some of which are named the same as they are on the system. "grep", "tcpdump", "kill". But it's my impression that you are restricted as to what you can do. For example, in Sophos' case, "tcpdump" from the CLI does not take all of the arguments that you get from the shell and it even renames some of the arguments that it does allow.

Whether a CLI is implemented entirely in C or C++ or something and only uses library calls -- a lot of work considering that a Linux/UNIX OS will have hundreds of executables ready to do those jobs -- or they will validate and filter arguments and use OS executables. Or maybe both. (I suspect Sophos CLI uses both methods.)

Checkpoint is interesting. Cisco is surprising, I didn't know that. In either case, I think Sophos is bringing to bear Sophos Labs and their MTR work and "living off of the land" is a big cybersecurity threat right now, so providing shell access is actually a bad practice.

I think your last point is the key: Sophos offered Advanced Shell and it's essentially been a crutch that justified them not improving the CLI or the GUI. PAN didn't need to do that. Fortinet mostly-didn't need to do that, Cisco is the odd one here

To be honest here, do you have a home license on v19 EAP?

Can't you just "ssh firewall -t /bin/sh" and move on with your life? Or they actually blocked anything involving "/bin/sh"?

I'm currently on a XG appliance, so I can't verify if this works.

I hate that this system bottoms out so early in the replies, so we end up "replying" to whoever posted right before us instead of who we were replying to -- once replies reach some (shallow) depth. So not sure if you were replying to me. (I have an XGS appliance, so also can't test.) I could swear that I've read that home users can't work around this with SSH. I could be mis-remembering, though.

(On a lighter note, I have a cool little script I did to stream `tcpdump` output to my laptop for unlimited captures, and I worked it all out with `expect` and going through the CLI that appears if you just `ssh`. Would have been much simpler if I'd thought about `-t` working.)

Wayne Folta said:

I hate that this system bottoms out so early in the replies, so we end up "replying" to whoever posted right before us instead of who we were replying to -- once replies reach some (shallow) depth

I hate it too!!!! At least if they switch to discourse.org...

Yes it works. With "ssh admin@firewall -t /bin/sh". So i'm fine without shell access 

This will be addressed until GA. 

It's amazing how much effort and energy Sophos is pumping into this restriction. Features requested from customers years ago are still not implemented, "workarounds" for real problems that are years old are still the "solutions" you get from Sophos Support, but this will get fixed in no time? Sophos is such a joke nowadays.

Thanks for your Feedback. 

Thanks for your Feedback.