Seriously, though: you almost certainly have one if you run a software business. Client side SSH certificates are your friend. If you're not able to do that, because it is really annoying, separate it from the main app and lock it down as much as possible. (Separate authentication from the main site/app's authentication scheme. Lock down access, ideally at the network level. Strongly consider two-factor auth.)
So you have folks administering the servers. A certain percentage of them need root access. One of them gets his certificate revoked and then laid off -- in that order -- but he already installed a back door account. Okay, so you're a good admin and you check the logs and make everyone use "sudo" for everything.
* But maybe it won't even show up in the logs. Maybe he was editing a file in sudo with vi and ran ":! bash". Okay, so you're a good admin and disabled that.
* Maybe he was editing crontab one day and added a one-shot script to create a nefarious account. Okay, you are a good admin and you have tripwires.
* Maybe he knows where your tripwires are. Do you honestly think you know every possible attack vector someone with legitimate sudo access could use?
It's really hard to stop an inside job. The principle of least privilege is a nice maxim, but there's a cost to figuring out exactly what the least privilege is, and there's a cost to giving someone too little privilege -- downtime when they can't fix something they're supposed to fix.
Ah, yes, works on a default Ubuntu desktop install provided you have vim installed (not the usual tiny-vim package that uses nano for visudo editing).
2) You can disable sudo -s, sudo su, and sudo bash. Maybe the people with root access only need to run a few commands and edit a few files as root, so you whitelist those. But as I mentioned, if they need to edit crontab you've probably given away the keys to the kingdom right there.
There are more attack vectors you can enable without knowing about it and you've got a business to run, so you make a cost/benefit analysis -- it's always a trade-off between efficiency and security.
:sp /bin/vi
...
:wq
Yes, I wasn't very clear when I said the following...
> Okay, so you're a good admin and disabled that.
What I mean is that you disable "sudo vi" access, and allow "sudoedit" access. Suddenly you only have write access to certain files. But which files? These people need to administer the server, but at the same time you want to prevent them from creating a backdoor, or at least you want to know about it if they do.
/etc/crontab is just an obvious example. Maybe you can get suborn a filter somewhere that runs as root, or poison the environment variables of a legitimate script.
This doesn't cure everything, of course. There are a lot of places in many server environments where a determined miscreant can hide time bombs. (Oracle DBMS_JOBs anyone?) But it can be a useful component of defense in depth...
The GM interface requires a special build of the WoW client, a specially flagged account, and a two factor auth token to login. It's pretty hard to emulate the client as opcodes are randomly shuffled based on the hash of the binary itself.
[1] http://massively.joystiq.com/2012/02/29/blizzard-announces-l...
[2] http://kotaku.com/5933454/blizzard-network-breached-change-y...
[1]: http://www.howtogeek.com/121650/how-to-secure-ssh-with-googl...
What are those? We're talking key-based ssh authentication? Or something else?
Of note, if you do use a client-side SSH cert, disable username and password auth.