Thread Info
  • Locked Locked
  • Replies 11 replies
  • Subscribers 6 subscribers
  • Views 28532 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Shell (loginuser) access to UTM

teched

Sophos has recently updated the documentation for 9.4 (and this applies to prior versions as well) and it now includes the following (underline added, for emphasis):

Note – Any modifications done by root will void your support. Even users not logged in as root have direct access to a lot of information on the UTM and should be considered privileged users. Therefore, it is strongly recommended to grant SSH access only to administrators in WebAdmin. For any configuration change, use WebAdmin instead.

To elaborate:  loginuser (and likely any other shell accounts on your UTM) has access to far more information and configuration capability than most administrators expect.

Sophos considered this a documentation issue and not a security issue in our exchange of emails.



This thread was automatically locked due to age.

  • Hi,

    Sophos suggest no root changes through CLI unless it is suggested.

    Thanks

  • in reply to sachingurung

    loginuser can do much of what root can do - including many things that most might expect loginuser can not or should not be able to do.

    This situation likely applies to SUM and iView v1 too.

  • in reply to teched

    Hi Teched, nice to see you back...;)

    Can you post some examples ?

  • Deliberately two weeks after the initial post and only a glimpse.

    $ pg_dumpall -U postgres

  • loginuser, or another local shell account, can access the configuration daemon and in this example shutdown a UTM:

    $ perl -e 'use Astaro::ConfdPlRPC ; my $c = Astaro::ConfdPlRPC->new; $c->system_shutdown; $c->disconnect;'

    The UTM configuration can also be read and modified through this mechanism.

  • in reply to teched

    Correct me if I am wrong, but isn't the only way you can execute any of these command on the shell is with the root or loginuser password? You'd have to be a pretty stupid network administrator to let your admin passwords out of your control...

  • in reply to Dlabun

    Dlabun said:

    Correct me if I am wrong...

    I am neither correcting nor confirming.   Non-response could be misinterpreted as non-correction and/or agreement.

  • Does this command still catch usernames and passwords used for authentication on the UTM in the latest versions?

    "tcpdump -i lo port 15723 -Xvn -s 0 | grep -A 4 '8018 0156 .... 0000 0101 080a'"

    The grep string is not well tested.

  • in reply to teched

    Hi Teched,

    I'm failing to understand the point that is being made and agree with the comment above about letting passwords be out of control.

    All SSH access should be heavily restricted to specific network nodes and at best using PSK in 99% of instances if it can be helped. Even for Loginuser there is the big in your face warning that politely says "Don't screw around in here please as we won't support you".

    Every install I do I exasperate the point of unless told by the Support team to do something in Shell, only ever use it for last port of call rebooting, diagnostics with top (and it's variants) and tcpdump. Additionally what you're highlighting a security issue of is the exact same security issue that a lot of OS' face, a non-administrative user on windows for example can do things to circumvent security protocols and give them "elevated" capabilities.

    Just want to understand the actual point you're trying to make.

    Emile

  • in reply to Emile Belcourt

    Unknown said:
    I ... agree with the comment above about letting passwords be out of control.

    I don't agree with the comment: One would not "have to be a pretty stupid network administrator to let your admin passwords out of your control."

     

    My points/purposes:

    Sophos has updated the documentation.

    Share information and knowledge so that informed decisions can be made.

    Provide specific examples to highlight the potentially non-obvious capabilities of local non-root users. (loginuser and others if they have been created)

    Indirectly highlight that local CLI users can get root/admin access.  (Reboot was just an example.)

    Highlight that root might get access to clear text usernames and passwords in some configurations.

    (New) Highlight that services listening on 0.0.0.0 might be exposed through firewall rules.  (I don't feel like making a new post and would be an extension to the idea that services listening on localhost are available to local users.  There may also be ways to configure the a UTM proxy for access: does confd still do HTTP/JSON?)

     

    This is much more for those who didn't/don't know than those that already do.