Availability for the Always-On Enterprise
Post Reply
jgh
Novice
Posts: 6
Liked: never
Joined: Mar 10, 2016 11:10 pm
Contact:

Feature Request: Please address SUDO security

Post by jgh » Mar 17, 2016 8:47 pm

1. Insecure sudo commands

Please supply sudo least privilege commands. At this time, I have this entry and it works perfectly, however still insecure:

Code: Select all

    Defaults:svc-veeam-guest!requiretty
    Cmnd_Alias VEEAM_FLR = /bin/uname, /usr/bin/scp, /bin/arch, /bin/mount, /bin/sh, /bin/rm, /tmp/*
    svc-veeam-guest ALL=(ALL) NOPASSWD: VEEAM_FLR
However, this is still more open that we would like. Specifically /bin/rm and /tmp/*. This is still far better than letting Veeam have access to run every command without a password on our systems.

2. Turn off !requiretty in SUDO configuration

If ssh -T is used to connect (as I believe the FLR is doing), the tty is disabled by default (the below is taken from the man page, and I've done this in practice many times)

Code: Select all

 -T      Disable pseudo-tty allocation.
3. Disable NOPASSWD in SUDO configuration

Since the password is supplied on the Veeam application when doing the backup, and the same credentials are used for the restore, is it possible to feed this password back through the API during restore operations and use a password? With this method, we could require the password and maintain more security for FLR Other-OS restores.

4. Remove SUDO configuration

At this time, if you have the restore update the /etc/sudoes file with the required commands for the restore, that access is left after the restore is complete. This is very insecure, as this leaves access open for this user irregardless of restore status.

These requests are a result of support ticket 01732540.

Thanks,
Jason

PTide
Veeam Software
Posts: 4307
Liked: 355 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Feature Request: Please address SUDO security

Post by PTide » Mar 21, 2016 4:09 pm

Hi,

Thanks for the heads up. We will discuss this internally and update the thread once we come to any conclusion.

Thank you.

chrisdearden
Expert
Posts: 1530
Liked: 225 times
Joined: Jul 21, 2010 9:47 am
Full Name: Chris Dearden
Contact:

Re: Feature Request: Please address SUDO security

Post by chrisdearden » Nov 25, 2016 1:44 pm

Was any conclusion reached on this ? particularly the NOPASSWD side.

tsightler
Veeam Software
Posts: 5191
Liked: 2070 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Feature Request: Please address SUDO security

Post by tsightler » Nov 25, 2016 7:36 pm 1 person likes this post

To play devils advocate, requiring a password for SUDO doesn't inherently add any significant security for an automation/service accounts. Requiring a password for SUDO is normally done to protect interactive accounts since those are most at risk from simple attacks like, for example, a user sitting down at an unlocked terminal.

However, for automation/service accounts, the only additional protection it provides is if an attacker somehow manages to get access to this service account but not have the SUDO password. This is a measurable risk with a persistently running service, but Veeam is not a persistent service, the account is used only as long as is required to perform the request action and then it is logged out. No interactive users should be using the same account and no persistent services are running to provide an attack vector.

If we support a SUDO password for the Veeam service account we would also have to store this password in our database (i.e. both the key/password to login to account and the password to SUDO stored in the same place) and, more importantly, because SUDO requires the password to be provided in plain-text, we'd have to decrypt the stored password and send it across the SSH tunnel in plain-text. Of course this should still be safe because the SSH tunnel is itself encrypted, but it's questionable if requiring the decryption of a password and sending it in plan-text to a shell is really adding much safety to an SSH authenticated session.

chrisdearden
Expert
Posts: 1530
Liked: 225 times
Joined: Jul 21, 2010 9:47 am
Full Name: Chris Dearden
Contact:

Re: Feature Request: Please address SUDO security

Post by chrisdearden » Nov 26, 2016 8:33 am

In this instance, I believe the customer was running centrify, so just needed to re authenticate with the same password?

tsightler
Veeam Software
Posts: 5191
Liked: 2070 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Feature Request: Please address SUDO security

Post by tsightler » Nov 26, 2016 6:56 pm 1 person likes this post

I know Centrify offers an alternative to sudo, DirectAuthorize (dzdo) and perhaps it does not have a NOPASSWD equivalent since I believe it authenticates to AD groups so it may need the password again regardless. My response was more to the older post in this thread that implied it could improve security as I believe at best it a net-neutral move from a security perspective.

That being said, most tools that use sudo do at least offer support for sudo that requires a password, so I'm not arguing against including it as a feature so much as simply pointing out that it's not really going to change the security profile very much.

joebranca
Novice
Posts: 8
Liked: never
Joined: Oct 28, 2015 9:36 pm
Full Name: Joe Brancaleone
Contact:

[MERGED] Linux FLR credentials - 2FA support or workarounds?

Post by joebranca » Oct 25, 2017 11:11 pm

We are working on our Unix PaaS team to convince them to get their VMS off Networker backups on to Veeam for a standardized backup service. The snag right now appears to be FLR credentials. Our Security group has set out goals for all admin-ed servers to be using two factor authentication (Duo in our case), and local root SSH is obviously disabled. So this seems to pose a problem for our Linux FLR operations, as I assume there are no plans to implement 2FA capabilities in FLR operations. So that is a feature request at least.

What is the best workaround? Dedicate a local user account on each Linux VM, using SSH keys, and add to sudoers? The other problem is one of our Linux admins does not like giving generalized root privilege to an account like this, he would rather button it down to what specific processes are needed to be run by the user, but I can't seem to find information on that either.

I hope that is clear, and thanks in advance for any pointers. It seems the increasingly restrictive access policies being implemented especially with our Linux VMs is making self service FLR less and less doable, at least in a straightforward way.

joe

joebranca
Novice
Posts: 8
Liked: never
Joined: Oct 28, 2015 9:36 pm
Full Name: Joe Brancaleone
Contact:

Re: Linux FLR credentials - 2FA support or workarounds?

Post by joebranca » Oct 31, 2017 8:44 pm

Bumping --- anyone else running into restrictive Linux access scenarios with FLR operations?

Post Reply

Who is online

Users browsing this forum: patrick.shea, rickrbyrne, vhernandez and 38 guests