[ec2-beta] document: EC2 Ubuntu sudo Guide

[Jim Cheetham]

Michael, I'll quote you out of order, hope you don't mind :-

On Sun, Mar 8, 2009 at 8:04 AM, Michael Greenly <mgreenly at gmail.com> wrote:
> Does anyone have really good justification for being forced into sudoing
> through the ubuntu user?  I can come up with a few fantasy scenearios

Let's step through this from the beginning :-
* All machines attached to the Internet are being attacked all the
time. Most of these attacks are Windows-specific, but many are
specific to Linux.

* Firewalls only protect you against attacks on services that "should
not" be running. They do not protect you from attacks on services that
are supposed to be available.

* 'ssh' is one of the most attacked services on a Linux machine. If an
attacker manages to get a shell login on your machine, it is game
over. Your machine can be compromised just as badly and undetectably
as a Windows machine can.

* Nearly all active ssh attacks are using a list of common usernames,
and are guessing passwords. The most common username on a Unix machine
is ... 'root'.

* The root password will be attacked over ssh, and will be attacked
from a compromised shell account.

One of the approaches to protect the root account from password
cracking is to disable the password completely, therefore no attempt
can succeed (i.e. 'su' cannot work). However we still need to use the
root account to do work, so another mechanism is provided -- sudo.
This provides other benefits too. Read the Ubuntu explanation of their
choice :- https://help.ubuntu.com/community/RootSudo

So, with the root account locked, you can't use 'su' ... and you can't
log in over ssh either (there's an ssh setting called PermitRootLogin,
which will stop root from being able to log in, even if there is an
unlocked password for it)

> files to instance.  I'm fairly certian that there's no way to make
> Capistrano 'put' work with 'sudo'?

What is your problem with using sudo in your scripts?
Sudo can be configured in many different ways, depending on your level
of recklessness vs. paranoia :-)
For example, you can allow your script user ('ubuntu'?) to execute a
specific command as root, without being asked for a password at all.
You can allow a specific user to execute *any* command as root without
being asked for a password.

> So I'm wondering if anyone has any
> suggestions?

Lots :-)

* Do not unlock the root account
* Do not use the ubuntu account (after initial setup)
* Create a new account specifically for your operation, with an
unusual name (i.e. not one likely to be on a common cracking list like
'admin' or 'webadmin')
* Set up public/private key logins over ssh, and disable password logins
* Configure the firewall to permit only your admin machines to connect
to the ssh port
* Restrict the ssh key to permit only your admin machines to
authenticate with ssh (in .ssh/authorized_keys)
* Consider running ssh on a port other than 22 (personally I don't
like this step, if you forget what you've done here things get
frustrating)

For automation, take these extra steps :-
* Create a new user just for automation tasks
* Provide this with restricted ssh keys, as above
* Limit the commands that can be run at login time (again, in
.ssh/authorized_keys) -- do not run a shell, run specific scripts
instead
* Configure sudo to let this account run specific commands as root,
without being prompted for an interactive password
* Consider configuring PAM further, so that sudo will only allow
passwordless root access if the account is logged in with the correct
key (this is very very hard, and will make testing difficult. You
probably have insufficient paranoia for this one ... I know I've never
really wanted do it!)


The goal in all of these steps is to reduce the attack surface for
logins, so that you can justify your decision to configure sudo to
allow passwordless root access, for your scripts.

-jim