If they got in via SSH and all they did was deface his website they must be stand-up guys, huh? Most likely they just wrote an executable to his /tmp directory and then used apache's amazing recursion checking to execute it. This is the most common case I've seen on the dozens of cPanel 'hacks' I've encountered.

-Drew

-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Craig White Sent: Wednesday, August 09, 2006 12:19 PM To: CentOS mailing list Subject: Re: [CentOS] Server Hacked: Cpanel

On Wed, 2006-08-09 at 09:08 -0700, Karl Balsmeier wrote:

Hi,

I have servers of mixed OS, some Centos, some Fedora, and after the flame war that erupted last week (where I said basically nothing and just watched), my server was hacked by this team of hackers, actually their friend:

http://www.sibersavascilar.com/

This made Karanbir's statements about mixing Cpanel and Centos (any maybe any linux distro) come true very quickly. If one of the top package maintainers says this, it bears weight.

I'd like to know more about this subject, specifically on the package front, for security's sake.

Karanbir, can you restate the issues with Cpanel please? They are trying to recommend CentOS as the OS to install on, and even that Linux Journal article did -and before anyone else wastes their time, -let's get everything out in the open so that there's a pipermail archive trail for future folks 'googling' for info later on pros/cons of using, or avoiding use of, non-complimentary projects/technologies.

Is the issue that both parties maintain separate packaging/updating regimes and have little or no successful communication as far as keeping thing secure and up to date?

That seemed to be what you said, -and if I had the old email, i'd just run with it's advice.

Also, can you list the IRC channels you mentioned last time that contain the various hackers bragging about freshly broken Cpanel/Centos builds? Freenode right? Any others? I've been on IRC back when BITNET was still active and there wasn't even mosaic yet, but have always avoided it after 1992 because of hackers 'sniffing for future targets'.

William, Jim, Johnny, -any comments are truly welcome, -anyone really. Basically i'd like to help stop or curtail the 'open season' this set of circumstances is creating for hackers, -I have already decided to avoid Cpanel on Centos as it is, -my server that was hacked with Cpanel was not a Centos box, and those that have it, have been shut down.

The server next to it was *also* hacked, and that *was* a centos machine, with only a yum update from 3 days prior. Is it really recommeded that I run yum update evry night then? It was stunning to have a box up for 3 days and then get owned so fast.

Luckily this was for my personal business entity, and not my full-time job, which indeed does run 50-70 Centos servers behind layers of firewalls and other protections, and *no* commercial products, only centos packages by Dag or Karanbir.

To anyone in the mood for scolding, please hold off OK? I'm not in the mood for overbearing attitudes right now. I'm trying to run a business and seek solid answers. I see Centos as a reliable alternative to commercial offerings *if* you pay careful attention to what the senior staff and relevant discussion groups advise.

As for the team of hackers, if anyone knows who this is, or can point out who they might be or how to ban them, -that is also most welcome.

---- The only way to close the door is to figure out which door they used to get in.

The likely culprits are ssh - things like php (especially if using phpbb or other content management systems which allow users to write things on the web site). My money these days is always on SSH, allowing users to log in via password and users with weak passwords.

It's not really germane to discuss whether it was CentOS, CPanel or whatever until you actually know how they got in.

Craig

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

Drew Weaver wrote:

If they got in via SSH and all they did was deface his website they must be stand-up guys, huh?

Indeed. I try to be reasonably quick about updates and the occasional short-notice ssh exploit is rather scary.

Cheers,

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wed, Aug 09, 2006 at 12:40:17PM -0400, Chris Mauritz wrote:

Drew Weaver wrote:

...

If they got in via SSH and all they did was deface his website they must be stand-up guys, huh?

Indeed. I try to be reasonably quick about updates and the occasional short-notice ssh exploit is rather scary.

I have been using one One Time Password method or another to allow my users to have ssh access to their areas these days. Works great, as long as they are new users. Old users might complain if you make things "more difficult" for them.

- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wed, Aug 09, 2006 at 01:15:29PM -0400, William L. Maltby wrote:

My question is: is there a scenario where the public key based solution is just totally inappropriate? Am I overrating the value of going "passwordless"?

No to both questions. I use the same thing on all my servers (only keys, no plain-text).

However, there is a 3rd authentication option. The first 2 are:

- - Password - - Public Key

the 3rd being:

- - Challenge/Response

Challenge/Response authentication include things like S/KEY and OTPW (One Time PassWord).

If we give Password authentication a security rating of 0, and Public Key a security rating of 10, a good challenge/response method will offer you something like 9. They are a very good alternative when you can't, for one reason or another, use only key auth. And just like for passwords, you can have both key and challenge methods enabled.

There is one particular critical server here that I need to be able to access no matter what. Even if I need to go into a lanhouse to do it. In that case, using a public key is at least unadvisable, since others can try grabbing it at the time. So, Challenge/Response is a very good way to go, since it doesn't matter if someone else get my password (the password will work only once).

I'm also using an IPCop firewall w/no access from the 'net for now. But if/when I "open 'er up" a little, I would like to believe I'm doing the best job I can.

If you has the option of only using keys, then that is the way to go. Make sure all other authentication methods are disabled for extra points.

- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wed, Aug 09, 2006 at 03:19:23PM -0400, William L. Maltby wrote:

...

the 3rd being:

• • Challenge/Response

HA! I remember this from before I got cable access. While futilely hoping the telco would get DSL out here in the sticks, I did dial to my ISP. Auth was either PAP or CHAP. IIRC, ISP preferred CHAP and that's what we did (PtoP).

Having to stop the passwords on plaintext (on the ISP side) always makes me raise an eyebrow toward any place that offers CHAP as authentication. Then again, I always use different passwords everywhere, so that is not usually a big issue.

- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wed, Aug 09, 2006 at 04:40:09PM -0400, William L. Maltby wrote:

...

Having to stop the passwords on plaintext (on the ISP side) always makes me raise an eyebrow toward any place that offers CHAP as authentication. Then again, I always use different passwords everywhere, so that is not usually a big issue.

Same here, even in my own net (I have grandchildren: they can be "snoopy"). The darn trouble is trying to remember them all, including those for different 'net sites; all have a different password.

The plain text password didn't bother me so much as my connection was a dial-up Point-to-Point connection. One would need some special acces to intercept.

CHAP autentication send the "password" encrypted over the wire. The problem is how it is stored on the ISP server.

[]s

- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Rodrigo Barbosa Sent: Wednesday, August 09, 2006 12:29 PM To: CentOS mailing list Subject: Re: [CentOS] Server Hacked: Cpanel

Not only it will use unsecure versions of many softwares and some patches of questionable safety, it will also stop you from using several method of improving security (/tmp hardening with ACLs is just one example). ---

Not to sound silly but cPanel automatically secures the /tmp directory since the end of last year.

Some people disable it forcefully.

-Drew

On Wed, 2006-08-09 at 13:42 -0300, Rodrigo Barbosa wrote:

As a side not, I have started playing with SELinux to try and improve the security of my servers. My main problem is that you simply can't find a working rule set for Exim, and I'm working hard on creating one while learning SELinux at the same time.

Slightly OT: I have been playing a bit with the Simplified Policy Description Language (SPDL), that is part of the SEEdit project[1]. The language looks like AppArmor policies. I still use the 'targeted' policy on servers, but on the other hand using SPDL seems better than turning SELinux off completely[2].

E.g., this is a simple quick sample policy, quite readable if you know UNIX DAC semantics.

--- { domain vsftpd_t; program /usr/sbin/vsftpd; include common-relaxed.sp; include daemon.sp; include nameservice.sp;

allow /etc/shadow r,s; allow /etc/pam.d/vsftpd r,s; allow /etc/security/pam_env.conf r,s; allow /etc/vsftpd.user_list r,s; allow /etc/vsftpd/vsftpd.conf r,s; allow /var/log/xferlog a,r,s; allow ~/** rw,s;

allowpriv netlink; allowpriv cap_sys_chroot; allowpriv audit_write; allow /etc/selinux/config r,s;

allownet -protocol tcp -port 20 server; allownet -protocol tcp -port 21 server; allownet -protocol tcp -port 1024- server; } ---

-- Daniel

[1] http://seedit.sourceforge.net/ [2] I think that the majority of the current system administrators will never bother to learn to understand the current policy or the new 'reference policy', and will simply turn it off when the default policy gets in the way.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Okey, lemme expand this a little bit, and even contradict you (while agreeing).

On Wed, Aug 09, 2006 at 01:32:42PM -0400, Jim Perrin wrote:

If you install something like Cpanel to a system, you're adding a level of complexity. You're stepping over what's provided in the base, and adding to it. This means you need to not only know the base inside and out, but you need to know Cpanel inside and out as well.

It is a bit more problematic than that. You are not only adding stuff, but you are also replacing (exim, apache) a part of the system.

1. Minimal packageset.

Always a good thing to do, with or without a CP.

2. Regular updates and backups.

Backups ! Backups !

3. Config changes

Which is sad but true, specially for cPanel (can't say for sure with the other CPs).

As a side note, even Webmin will screwup your iptables settings if you enable bandwidth monitoring.

4. Permissions:

Unix permissions by default are DAC style, where the user has the power to change permissions. Make sure that you stay on top of this and keep permissions in places like your webroot to a minimum to do the job. If you can, enable SELinux, which is MAC style based permission, which enforces restrictions no matter what the user does.

Also, take a look at POSIX ACLs. They are a bit more complex to use than unix permissions, but much more flexible.

Nice checklist, Jim.

Best Regards,

- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wed, Aug 09, 2006 at 02:24:36PM -0400, Jim Perrin wrote:

...

It is a bit more problematic than that. You are not only adding stuff, but you are also replacing (exim, apache) a part of the system.

True, and slightly more accurate. I would assume that one who has a mastery of both centos and CPanel would by default understand such things, but it may need to be set.

Aiming for mastery of both CentOS and cPanel is like mastering sendmail.cf rule writing: difficult, impressive but definitively not a worthy goal.

My point is simply, once you are using cPanel, you really have to trust them to provide you with everything. Even minor changes on the software installed by cPanel will make parts of it stop working. So you have to keep your customizations to what you can do using the web interface, unless you are completely crazy (and if you mastered sendmail.cf rule writing, you definitively are).

If you are using cPanel, forget ACLs and SELinux. You can try to do something using the stock kernel + grsecurity patches, and maybe even install mod_security, but you really can't aim higher than that.

...

Also, take a look at POSIX ACLs. They are a bit more complex to use than unix permissions, but much more flexible.

ACK! Dammit I did leave out extended ACLs... good catch. They're quite nice also, although they make backups interesting because tar eats them. Star is your friend in those circumstances.

I really hate using tar for backups, even tho sometimes we are forces to use it. I try to use "dump" as much as possible, since it will (should?) get all the fs metadata correctly. When migrating servers, I usually add a nice dd of the filesystem, having a image I can mount whenever I want, just for an extra kick.

It is really unfortunately that ACLs are not supported by many utilities, with special proeminence to tar. I don't think cpio can handle it either.

[]s

- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)