[ec2-beta] document: EC2 Ubuntu sudo Guide

[Mark V]

Hi group,
Thanks for all the excellent work that has gone into the EC2 AMI's.

I'm new to Ubuntu (from openSUSE). I have not yet used it in anger, so
I'm not fully familiar with Ubuntu's root/sudo peculiarities, I read
the RootSudo document and Eric's notes on ssh access to Ubuntu AMI's.
Please bear that in mind....

On Sun, Mar 8, 2009 at 9:39 AM, Jim Cheetham <jim at inode.co.nz> wrote:
> 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
>

My initial reaction to seeing the ubuntu user was the same - eew :)

Reading Eric's notes and the comments below it seems that extra
security is being added at the wrong level.
Specifically, I had been thinking to use single-packet-authentication
to 'harden' the ssh service.  Then leave the ssh service behaving it
does by default on all other AMI's.  I'd be inclined to dump the
ubuntu user and the randomly generated password.
See here for Michael's excellent proof-of-concept notes:
http://www.cipherdyne.org/blog/2008/11/single-packet-authorization-and-amazons-elastic-cloud-ec2-service.html

As he comments:
<quote>
The Amazon online documentation on how to access Linux instances over
SSH recommends adding new rules for each IP source address you want to
use to access SSHD, which can become tiresome if you are on a network
running DHCP. With fwknop, you don't need to do any such thing - you
can access SSHD via SPA from anywhere, and anyone else scanning for
SSHD on the instance can't even tell that it is listening.
</quote>

This seems, to me, to be some additional security. Albeit with the
cost of using the SPA-client before ssh'ing.
However once you have ssh'd in things needn't be more inconvenient,
and they will be more secure.
As Michael notes, people can also choose different integration points
for the SPA layer.
What the default integration point(s) should be for an Ubuntu at EC2 is
an interesting Q.  I'm in the middle of another project so haven't had
a chance to implement any of these ideas in the AMI's, but would be
interested in the communities thoughts.

I think SPA/fwknop addresses these concerns....

> 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.

Correct, but employing the ubuntu user does not address this issue.
The fwknop SPA layer does - it hides the presence of the ssh service.

>
> * '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.
>

Agreed.  So it seems more sensible to protect the ssh service directly.
Hopefully fwknop support can be built in by default - ideally it'd
become the AWS's recommended (Linux) practice :)
Of course people (Canonical?) may not want admin's to have to run some
SPA/fwknop client script before ssh'ing, in which case perhaps a
Ubuntu server config option could be 'fwknop protected ssh login'?

Cheers
Mark

> * 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
>
> --
> Ec2-beta mailing list
> Ec2-beta at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ec2-beta
>