2

I am hiring a freelance Server Admin (who is more experienced than me - that's why I am hiring them) to do some work on my CentOS-running VPS. They will require root-level access to the server, as they need to install server daemons and such.

What's the best practice in this scenario: how can I identify if the contractor goes and install root kits or does something otherwise nasty? What I have done is created a new account for the user, added the new account to group "wheel", and then used visudo to enable the group wheel to run all commands.

Are there any other steps I should be taking? I accept that by handing over sudo privileges the contractor could pretty much do whatever they want and the end of the day I need to trust them; I guess I at minimum want to make sure I have a record of whatever they do, just in case.

Thanks

Professor Frink
  • 509
  • 3
  • 7
  • 15

8 Answers8

5

Technical Solution: Image the server so you can compare after the fact what changes were made. Keep this copy away from them.

Political Solution: Have them sign a Statement of Work and hire contractors you can trust.

Matt
  • 933
  • 5
  • 12
  • Interesting - is there no easy/safe way to log the actions of a SUDO'd user? That would seem much easier to review than comparing server images – Professor Frink Sep 25 '09 at 20:13
  • By default it does, yes. But as root, they could just modify /etc/sudoers and /etc/syslog.conf (or whatever mechanism you're using to pull these down with) and then be free. – Matt Sep 25 '09 at 20:16
  • Even easier, you can just run a shell as sudo, then the only thing you see in the logs is that they ran a shell. – Kamil Kisiel Sep 26 '09 at 16:06
3

One option is to use system configuration tools like puppet, so they can explicitly outline what is to be done to the server. Of course, that requires someone to review their work before it be applied.

The other option is to set up a network syslog service. By forwarding logged messages to another server they don't control, you can at least guarantee the integrity of logs. Make sure the system records logins / logouts and ideally, restrict access to sudo so all root commands can be sourced to specific user. Again, this server needs to be root accessible only to as few people as possible.

jldugger
  • 14,122
  • 19
  • 73
  • 129
  • Thanks, this sounds like a good solution to my issue. Can't the SUDO'd user just shutdown the network syslog service though? Now to begin researching how to setup a network syslog service on CentOS :) – Professor Frink Sep 25 '09 at 20:23
  • I believe syslogd will announce to the log server when it's being shut down, so you'd have a record of that at least. As Nixon says, "the coverup is worse than the crime." – jldugger Sep 25 '09 at 21:14
  • Just remember that logrotate will (on most systems) naturally reload syslog nightly, and you may want to use something (OSSEC/Nagios/Monit/a simple script) to keep an eye on /etc/syslog.conf. – Matt Sep 25 '09 at 21:33
2

What you're asking for is difficult under normal conditions. You've already indicated that they know more than you do, so it's approaching practical impossibility to monitor them when they have equivalent privs to you. ( Do they actually need full privs? Maybe not. )

If these people aren't someone you trust, you really shouldn't be working with them. As matt.j.alexander rightly pointed out, this is not a technical problem.

Quality sysadmins are hyper-concerned about their reputations for this very reason. I keep my nose clean, because there's so much implicit trust required for me to do my job. If I loose that personal trust, it's a serious career issue.

pboin
  • 1,086
  • 8
  • 11
1

As you can stop him from doing whatever he want, you should monitor the system. Best way to do it is to export the logs to an external location and use an HIDS (host intrussion detection system).

You could use splunk and OSSEC together and monitor sudo use by the administrator.

OSSEC will also notify of filesystem changes and installation of packages.

chmeee
  • 7,270
  • 3
  • 29
  • 43
1

I will typically give the user an account that has screen as their shell and with a .screenrc that logs everything they do. This way I can monitor the user in real-time by using tail -f on the log in addition to keeping a log of all their actions.

chris
  • 11,784
  • 6
  • 41
  • 51
0

ask the vps provider for a snapshot before proceeding

quaie
  • 1,124
  • 6
  • 13
0

There are open source monitors out there, that use a client-server technique to monitor a clients status. One of them is Xymon (formerly known as Hobbit), a fork of the well-known Big Brother monitoring software, but then implemented in C. One nice feature is the ability to check an MD5 hash of a file or a directory. Offcourse it can monitor more than that, but you can for instance create a couple of MD5 hashes of /etc/passwd, /etc/shadow, /etc/syslog.conf or whatever you don't want them to silently change. On the server you can define these hashes to be checked periodically (default is 5 minutes). They should not have access to this monitoring server offcourse. You can also create a check for a running client on the server they're working on. You might not know what they did, but you can at least be notified if they changed something you didn't ask them to change.

0

One thing not mentioned so far: Create a staging copy of your server so that they don't have access to the live site. Have them work on the staging copy. Then either periodically or once they are done compare the two sites and synchronize the changes. This way you have a chance to review or revert anything they do.

Kamil Kisiel
  • 11,946
  • 7
  • 46
  • 68