[CentOS] server is always getting hacked

Warren Young 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?

The difference is that the root user (when sshd is properly configured) 
can not log in remotely even if the root password is guessed. While it 
is possible to set a different password for sudo, if a brute force gets 
your password the remote use can then sudo login or sudo sh.

I remember one of my passwords that I thought was good, I typed it in 
some web form that checks the security of password, and it turned out my 
password was one character off of a leet speak translation of a klingon 
word, and therefore while not super weak, was vulnerable to brute force 
by someone using a klingon dictionary (and they are readily available).

Requiring a pass phrase works to mitigate that, but on multiuser 
systems, unless everyone using it is a geek, requiring pass phrase just 
isn't possible. It is too difficult for the common user to set up.

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

That is a valid point, but only really matters if you make a habit of 
leaving your workstation without locking your screen, which if you have 
root access, is the kind of thing that should get you fired because all 
kinds of nasties can be done while you are at the bathroom. I use to 
screw with the .bashrc file of the web developers when they went to 
lunch w/o locking their screen. None of them had root on sensitive 
systems though.

It was funny to watch one of them reinstall because his cdrom kept 
ejecting every time he used the ls command - but he did not wipe /home 
after his reinstall.

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

That's what su --command is for.
I very rarely have a root shell open because most things can be done via

su -c 'foo'

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

Yes it does, but should be not be configured to allow spawning of a 
shell, as almost every single sudo install I have ever seen does, 
effectively creating numerous root passwords.

Saying that using sudo instead of su makes a box more secure is only 
true if your system administrator knows how to configure sudo. If they 
do, then they probably don't need to be told to use sudo. If they don't, 
then they should be pointed to documentation that explains the inherent 
dangers.

Otherwise, human nature is to allow sudo to do anything, because it 
work, but is not secure - just like almost every freaking php web app 
out there in the install file tells users to chmod 777 directories and 
files. It works for both mod_php and php-cgi, but is not secure (and is 
not the best way in either scenario, especially on shared hosts, which 
really should run php as a cgi negating the need for chmod all together)

Another option is to properly set up the system to begin with - a lot of 
what junior admins need to do can be done with wrappers, and some things 
don't need root access at all - IE set up a texlive user for texlive 
administration and your tex guy doesn't need root to update the system 
tex install (either via the tlmgr or rsync).

Using sudo instead of su does not make a system more secure. It can, but 
it can also make it less secure.

// gets of soap box

-=-=-=-=-

With respect to pam management of su - that's cool, wasn't aware there 
was a pam module that did that.

Still not as good as bsd su IMHO as it relies on pam, but it's something 
I'm definitely going to start using.