1. Make a good backup of the hacked system for data archival and forensic

analysis. 2) Take the affected system off-line. 3) Check all other systems in your company as they are definitely at high risk. 4) Completely re-format and re-install any and all hacked boxes. 5) Change all passwords everywhere and make sure they are not recycled.

I think you have steps 1 and 2 reversed. take it offline THEN make the backups etc etc. the infected systems disks should be mounted r/o on another secure system for doing said backups.

On Mon, Jun 29, 2009 at 9:00 AM, Sander Snelzander.snel@gmail.com wrote:

On 06/27/2009 09:21 PM, Mag Gam wrote:

sane and simple security management for linux systems:

1. only open ports in iptables which are being used, if possible with

source address or source network. 2. use hosts.allow/deny rules for services if applicable, this adds another layer of security. 3. check logs often, use a central loghost 4. SSH: no root login, only dedicated users, only dedicated source addresses, only key based access or kerberized access, no standard port

PortKnocking so the open port changes continuously.

and / or

tinc-vpn / hamachi so the port is only open to another member of your tinc network. Since there there are hundreds-of- thousands or millions of infected web servers out there serving up malicious drive-by javascript, use noscript on any machine connected to a server.

Reemphasize watching cms (joomla and the like) plugins.

5. enable SELinux
6. use some kind of intrusion detection, like aide (standard in centos)

or snort 8. use fail2ban to deny ipaddresses with several failed login attempts within a short period of time 9. clear your shell's history on logout 10. use sudo instead of su - 11. check bastille.org for hardening 12. check center for internet security for benchmarks, they provide very detailed information for hardening servers ( csisecurity.org ) 13. use chattr -i for several key configuration files, so they cannot be changed or deleted

this should get you started, good luck

Sander

...

WE have a centos 5.3 install, and our server is keep getting hacked. We see load averages of 500+ and see people from all over the world logging into our server (used last).

Is there a good place to start to avoid these kinds of things?

For example, here is what I already did.

Open up sshd port only setup iptables to only accept port 80 and 22 No FTP No other ports are allowed according to IP Tables.

I am not sure what else measures I can take. Can someone please assist?

TIA _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Sander Snel wrote:

10. use sudo instead of su -

How does that help?

Justin Bull wrote:

I don't know if you can disable su -

Sure: usermod -L root. Before you do that, you need to have a user in /etc/sudoers that has root equivalence. Ubuntu does this by default.

At Tue, 30 Jun 2009 17:43:14 -0700 CentOS mailing list centos@centos.org wrote:

On Tue, Jun 30, 2009 at 5:26 PM, Michael A. Peters mpeters@mac.com wrote:

...

How does that help?

Its considered proper convention to use "sudo" on individual commands instead of changing the user to root. With sudo you can water down the ability of a user, eg can't use the shutdown command.

I don't know if you can disable su -, but that would be the plus of this style.

Ubuntu does it by giving root a disabled password. The su command is not disabled exactly, but you cannot use su to become root (unless you already are (eg 'sudo su -' which is kind if redundant).

-- Best Regards,

Justin Bull So Hip it MHz Studios www.sohipitmhz.com

http://www.sohipitmhz.com/pubkey.txt (PGP Public Key) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Michael A. Peters wrote:

Sander Snel wrote:

...

10. use sudo instead of su -

How does that help?

I still don't understand how using sudo instead of su makes it more secure.

If the user does not have the root password that the only danger to su - is brute force from local account, but you can protect against that, and the same issue exists with sudo.

With sudo, very often the password is same as the admin's password - so if the admin account is brute forced the cracker then can use sudo to gain root.

What would be a security enhancement would be to borrow the bsd su which only allows you to su to root from a wheel group account.

I never understood why gnu su didn't implement that.

On Wed, 2009-07-01 at 01:20 -0700, Michael A. Peters wrote:

I still don't understand how using sudo instead of su makes it more secure.

As implemented by Ubuntu and others, sudo does nothing to make things more secure. In fact, as you pointed out, it can be less secure.

However, sudo has the capability to grant fine grained access. For example, one could configure sudo so that operators are able to launch backups as root but not start a shell or edit the web server config files. This capability is what earned sudo its reputation for being more secure. Sadly too many people chant "sudo is more secure" without understanding the conditions necessary to make that statement true.

John R. Dennison has already pointed out that it is trivial to configure su on CentOS to require wheel.

On 7/1/09 2:47 PM, "Warren Young" warren@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@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.

Frank Cox wrote:

On Wed, 01 Jul 2009 15:05:58 -0700 Gary Greene wrote:

...

. With sudo, you get a record of what command was executed with superuser rights by whom at whenever given hour.

sudo bash

If that's a problem for you, don't let people run bash via sudo. There's an entire body of articles and such on which processes to restrict because they can give you a sub-shell.

On 7/1/09 3:08 PM, "Frank Cox" theatre@sasktel.net wrote:

On Wed, 01 Jul 2009 15:05:58 -0700 Gary Greene wrote:

...

. With sudo, you get a record of what command was executed with superuser rights by whom at whenever given hour.

sudo bash

I didn't think I had to be THAT pedantic of what you add to the allows and disallows.... Its called common sense here. If the sub-process will give you an unrestricted shell, and you don't trust xyz user, block it from being allowed.

Robert Heller wrote:

At Wed, 01 Jul 2009 16:08:08 -0600 CentOS mailing list centos@centos.org wrote:

...

On Wed, 01 Jul 2009 15:05:58 -0700 Gary Greene wrote:

...

. With sudo, you get a record of what command was executed with superuser rights by whom at whenever given hour.

sudo bash

Which in turn is logged. Such a log entry might raise a red flag.

Speaking of logged - I don't do this but Dad set up his systems (solaris) to immediately boot the user and send an alert to the operator if the root user issued the id command and had not become root from a member of the wheel group.

He was a university admin, they had to have telnet open because of grad students doing research in countries that did not allow secure connections. Most of the time, that single action got the hacker off before any damage was done. Those were primarily Solaris systems he dealt with.

They also had a log server that everything was logged to (off the network, fed I think by serial cable if I recall but it may have been cat 5 - sun had funny looking serial ports that took a cat 5 jacks to me), as local logs are easily modified once you have a root shell.

But I don't personally deal with any systems that big and complex.

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.