[CentOS] server is always getting hacked

Wed Jul 1 22:05:58 UTC 2009
Gary Greene <ggreene at minervanetworks.com>

On 7/1/09 2:47 PM, "Warren Young" <warren at etr-usa.com> wrote:
> Michael A. Peters wrote:
>> I still don't understand how using sudo instead of su makes it more secure.
> Let's start with the simple case where only one person needs superuser
> type privileges on a given machine.  What, then, is the difference
> between sudo and su -?  There has to be one all-powerful superuser on
> such a machine, right?
> That's true, but it ignores human nature.  Human nature, in a world
> without sudo, is to leave a root terminal up all the time so you don't
> have to keep su'ing up to root and then logging back out.  The default
> configuration for sudo ameliorates this problem by remembering your
> password for a short time, so you can do another sudo command shortly
> after without giving your password again.  Once the user stops invoking
> sudo long enough to let the timer expire, root privileges are
> automatically revoked.
> This has two main benefits to security:
> 1. On walking away from your computer, you're less likely to leave it in
> a state that gives anyone walking up to it root access.
> 2. The extra "sudo" prefix you need in front of every command you want
> run as root makes it less likely that you will accidentally run a
> command as root that you should only run as a regular user.
> Now take the more common case for an enterprise distro like CentOS,
> where more than one person needs some level of superuser access.  sudo
> provides more benefits in that case:
> 1. You don't have to give the all-powerful root password to as many
> people.  sudo controls access to superuser privileges by asking for that
> user's account password, not the root password.  When it comes time to
> take superuser privileges away from someone, that user can just be
> removed from /etc/sudoers; you don't have to change the root password
> and redistribute it.  If you don't know why frequent password
> redistribution is a problem, you haven't been an admin very long.
> 2. With su, it's all-or-nothing.  Once you have a root shell, there's
> nothing you can't do, barring some MAC type system, and that affects
> anyone with root access equally.  sudo lets you give access to just
> those commands that a given admin needs.  Maybe you have a dedicated web
> admin, so you let him run apachectl through sudo.  He has no legitimate
> need to run any other commands as root.
> 3. sudo logs all commands executed through it.  su doesn't.  You could
> maybe configure bash to log commands, but then you run into Big Brother
> issues if you don't somehow do it only for bash when run as root.  Even
> if you did that, now you have to do it for all shells on the machine,
> else the first command a bad actor did on the machine would be to open a
> different sub-shell to escape the prying auditor eyes.  (Clearly for
> this to be a security feature, you need to have syslogd configured to
> redirect logs to another machine that doesn't allow remote access.)
> This doesn't prevent security breaches, just helps figure out what
> happened after one does occur.  Coupled with an IDS, it can even give
> you early warning that security has been breached.
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos

There's also the obvious part about "why sudo vs. su -"; sudo logs the
action, su however, does not. The only thing you'll see in the log with su -
is that the user just elevated their privileges to root, however you won't
see what they may have executed with those elevated privileges. With sudo,
you get a record of what command was executed with superuser rights by whom
at whenever given hour.

This coupled with remote log hosting can greatly increase your security,
since you'll know who did what at when hour instead of floundering in the
dark tearing a box apart trying to figure out what a user inadvertently (or
not) via su, did to your machine. Mind, this isn't completely foolproof. You
still should get an IDS running, etc.

Gary L. Greene, Jr.
IT Operations
Minerva Networks, Inc.
Cell:  (650) 704-6633
Phone: (408) 240-1239