5

Im in the unfortunate position of having to give someone who I do not fully trust privileged access to a webserver to finish work that they never completed.

They will access the server remotely (ie I will not be able to see their screen).

What can be done to a) proactively limit any potential damage and b) accurately log anything they do on the server for analysis afterwards, even if things seem ok?

They will be updating a web application.

Thanks in advance!

--- More informtion: The server is a Ubuntu AWS server.

Improve this question
5
  • What kind of access did you give that person? (SSH, FTP, etc.) What privileges does he have? (root/sudo access for example?) If he has root privileges, he can just hide every trace.
    – gertvdijk
    Dec 6, 2012 at 12:52
  • It will be SSH access. Root access will be required (via sudo). He doesn't know the system outside of the web application. Maybe there are obscurely hidden logging applications?
    – edo
    Dec 6, 2012 at 13:05
  • 1
    The only workaround I can think of is to use remote logging so that he can't wipe his traces out. If root access is really required, then you should use another workflow. For example, let him create a Puppet file in which he describes the target state of the machine configuration which you can examine and apply if you approve.
    – gertvdijk
    Dec 6, 2012 at 13:12
  • 1
    Limit them to the directory they need. Why exactly does he need root access?
    – Ramhound
    Dec 6, 2012 at 13:30
  • Is that "do not trust fully" as in "he's an idiot" or "do not trust fully" as in "I fully expect her to use any access she's given to try and exploit the server"?
    – Rob Moir
    Dec 6, 2012 at 17:25

4 Answers 4

Reset to default
2

You could give them an unprivileged account that has sudo access, but in /etc/sudoers you only give access to the command rootsh.

rootsh logs everything that takes place in a root shell, and you can push the logs to syslog and have them sent to an external server immediately.

It isn't bulletproof, but you must trust this person to some degree to even entertain the idea.

Improve this answer
1
  • Additionally within sudoers, specify the commands this user will want to run with the NOPASSWD option.
    – Wesley Werner
    Dec 6, 2012 at 13:29
1

Consider another approach, using a Configuration Management tool. One of which might suit your needs and is more powerful: Puppet.

Let the guy put all configuration to be done in a Puppet file. Advantages:

  • A very robust way of managing the configuration changes. All is in a file, rather than describing what has been done.
  • You will stay in control, as it lets you...
    • try the configuration on another machine and verify it.
    • decide to apply it whether it looks good or not.
    • pick the moment in time the changes take place
  • Reduce the time the changes are happening. It's automated.
  • You can repeat a similar configuration very easily just by customizing the configuration definition.

It boils down to this: the person responsible for the actual application configuration does not need shell access and it provides a way of separating responsibilities of him and the system administrator(s).

Update:

Big practical disadvantage too: it's a big elephant to smash this mosquito, so it might not fit your current situation. Not everyone is familiar with Puppet and low-quality Puppet definitions are worse than having a script setting it all up.

This leads me to another similar but simpler approach: let the guy develop a script that runs the necessary commands to change the configuration. It has some of the advantages listed above, yet does not require that much of an elephant of a tool.

Improve this answer
2
  • So, edo should implement a whole config management system from the ground up, to accomplish his request? I don't disagree that having Puppet is a good idea for many environments, but if he only has one webserver, this would be a huge timesink with little return.
    – mfinni
    Dec 6, 2012 at 16:38
  • @mfinni No, he could. It's just another approach suggested worth checking out and might be useful for other viewers of the question in a possible slightly other type of environment. It's an elephant, yes, yet provides other advantages too.
    – gertvdijk
    Dec 6, 2012 at 16:42
0

Take a snapshot / make a backup before they start.

Improve this answer
4
  • 1
    Not quite an answer I'm afraid. Damage in some forms might already have taken place (e.g. stealing SSL private key) and it doesn't log anything. It will only allows you to revert to an earlier state of the machine.
    – gertvdijk
    Dec 6, 2012 at 16:45
  • Agreed, good point
    – mike42
    Dec 6, 2012 at 16:48
  • Not entirely; one could diff the final machine with the snapshot at the end of the work, to examine what had changed.
    – MadHatter
    Dec 6, 2012 at 16:52
  • @MadHatter True. Yet, that probably hold an enormous amount of noise (log files, installed packages, etc.) and, it's not completely waterproof - for example, he could run a backdoor in a tmpfs which will survive until a reboot (yet that may be long enough to do more damage).
    – gertvdijk
    Dec 6, 2012 at 16:56
0

Set that account up so that he is given a screen session (can attach with -rx at any time), probably with script enabled...

Improve this answer
2
  • How does that prevent him doing harmful stuff? (e.g. running commands as root and then quickly wiping traces, using SFTP, using another SSH connection with forced-command, etc.)
    – gertvdijk
    Dec 6, 2012 at 16:48
  • If more than auditability is desired, dont give him root :) and sftp could be restricted to a nonprivileged account used to transfer stuff, serverside forced-command is your friend even, and a chattr +a on certain log/script files plus removing CAP_LINUX_IMMUTABLE will make it rather difficult to wipe traces....
    – rackandboneman
    Dec 6, 2012 at 17:03

You must log in to answer this question.