[ec2-beta] document: EC2 Ubuntu sudo Guide

[Michael Greenly]

I'll be more specific....

When SSH is configured not to allow password logins what benefit is there in
being forced to use sudo?  The only difference is that if they compromise
the 'ubuntu' account they've have to type 'sudo su' after they get in?

Simply requiring a key to authenticate as root is much cleaner in my opinion
and apparently good enough for almost all other public AMIs.  I happen to
agree with them, at least until a reasonable attack vector is explained to
me?

So although it's only a minor inconvenience not being able to run rsync,
sftp or scp as root I'm pretty sure that functionality was traded away for
no actual gain in security.

Right now I'm using the fairly straight forward work around where I transfer
files as 'ubuntu' and then sudo to re-permission, change ownership and move
the files into the desired location.  So one command became four.  It works
but it's extra hoops to jump through.

Extra hoops always mean extra chances for something to go wrong.

I don't like it.


On Sat, Mar 7, 2009 at 4:39 PM, 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
>
> 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
>
> --
> Ec2-beta mailing list
> Ec2-beta at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ec2-beta
>



-- 
Michael Greenly
http://blog.michaelgreenly.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/mailman/private/ec2/attachments/20090307/e1e40e5b/attachment-0002.htm