If you’ve taken a peek at your PCI scan results lately, you may have noticed that your scan provider is now requiring OpenSSH 4.5 or higher – a version that is not currently available in the CentOS 5 repositories.  A Yum update isn’t going to help you much there.

You can, however, easily compile your own RPM and manually upgrade OpenSSH.  The commands below are the ones I used to install version 5.8 (the latest stable at the time of this post), but can essentially be used for any compatible version.

First, download the OpenSSH source tarball from the vendor and unpack it. You can find the tarballs at http://www.openssh.com/portable.html

wget http://mirror.mcs.anl.gov/openssh/portable/openssh-5.8p1.tar.gz

tar -xvzf openssh-5.8p1.tar.gz

Copy the spec file and tarball:

cp ./openssh-5.8p1/contrib/redhat/openssh.spec /usr/src/redhat/SPECS/

cp openssh-5.8p1.tar.gz /usr/src/redhat/SOURCES/

Do a little magic:

cd /usr/src/redhat/SPECS

perl -i.bak -pe ‘s/^(%define no_(gnome|x11)_askpass)\s+0$/$1 1/’ openssh.spec

…and build your RPM:

rpmbuild -bb openssh.spec

Now if you go back into /usr/src/redhat/RPMS/<arch> , you should see three RPMs. Go ahead and install them:

rpm -Uvh *.rpm

To verify the installed version, just type ‘ssh -v localhost’ and you should see the banner come up, indicating the new version.

The cPanel security team found an issue in Exim that can potentially allow a user on the system to potentially run commands as the root user. Luckily, cPanel has already released a patch which is available for immediate download via their Exim upgrade script. If your system is set to update cPanel automatically, you may already have the patch. To verify, run:

rpm -qa |grep -i exim

The version should be 4.69-25 – if it’s not, you need to upgrade. You can simply run:

/scripts/eximup

Click the link below to read cPanel’s advisory:

http://mail.cpanel.net/pipermail/news_cpanel.net/2010-December/000060.html

I love waking up in on a nice Saturday morning to find out that one of my servers was rooted.

A two-year-old kernel issue in Redhat distributions has surfaced in the form of a nasty exploit byAc1db1tch3z.  Basically, a 32-bit binary is compiled and loaded to the server, and when run by any users (even non-root users), it uses a bug in the 32/64-bit compatibility layer to open a root shell.  Here’s a copy and paste of one that I ran on a test server:

user1@server [~]# ./badscript
Ac1dB1tCh3z VS Linux kernel 2.6 kernel 0d4y
$$$ Kallsyms +r
$$$ K3rn3l r3l3as3: 2.6.18-194.11.3.el5
??? Trying the F0PPPPPPPPPPPPPPPPpppppppppp_____ m3th34d
$$$ L00k1ng f0r kn0wn t4rg3tz..
$$$ c0mput3r 1z aqu1r1ng n3w t4rg3t...
$$$ selinux_ops->ffffffff80327ac0
$$$ dummy_security_ops->ffffffff804b9540
$$$ capability_ops->ffffffff80329380
$$$ selinux_enforcing->ffffffff804bc2a0
$$$ audit_enabled->ffffffff804a7124
$$$ Bu1ld1ng r1ngzer0c00l sh3llc0d3 - F0PZzzZzZZ/LSD(M) m3th34d
$$$ Prepare: m0rn1ng w0rk0ut b1tch3z
$$$ Us1ng st4nd4rd s3ash3llz
$$$ 0p3n1ng th3 m4giq p0rt4l
$$$ bl1ng bl1ng n1gg4 :PppPpPPpPPPpP
# whoami
root

Scary, eh?  And to think, Redhat has still not released a fix for this, and it’s been two days.  Therefore, if you’re running a 64-bit CentOS or RHEL 5 server, you may be a sitting duck. All it takes is one site on your server to be prone to remote file injection, and the hack is in.

No reason to fret, though, you have a couple options.

1. Download a working patch from here, and install the kernel, kernel-devel, and kernel-headers RPMs, then reboot
2. Ksplice really came through on this one, and by nature, provided an update that does not require a reboot. Take a look at their post here, and download their diagnostic tool to any of your 64-bit servers running CentOS or RHEL 5, to make sure they haven’t been compromised. They are also offering a 30-day trial so you can secure your servers.  $4/mo is a worthy investment, and I’m 100% sure that you’ll be happy with your results.

Update: on 9/12, Redhat released a patch for 64-bit RHEL systems: https://rhn.redhat.com/errata/RHSA-2010-0704.html, and a similar one exists now for CentOS: http://bugs.centos.org/view.php?id=4518

ClamAV is an popular open source anti-virus toolkit for *nix, and while many people don’t find much value in using antivirus software on Unix, it is very useful for email scanning.  cPanel’s implementation allows end users to run scans on their home folders, public FTP folders, mail, and public_html.

It’s really hard to install ClamAV on cPanel – if you’re too lazy to click a couple buttons.  Simply go to WHM > Manage Plugins and enable the ClamAV Connector, and you’re good to go.

After this is done, you can go to WHM > Configure ClamAV Scanner and set scanning options for the entire server or specific users:

You should now see a Virus Scanner option in cPanel. If you don’t, you may need to enable it in Feature Manager.

From here, cPanel users can run scans on any permitted items.

For administrators, here are a few quick commands that may be useful:

Update antivirus database:

freshclam

Scan a directory and print out infected files:

clamav -ri /home

Scan a directly and remove infected files and emails:

clamav -ri –remove /home

This article will not go into detailed technicalities on identifying, troubleshooting, tracing, and fixing hacks. These topics are far too broad to cover in a single article, and is outside the scope of this article’s intent. This guide is to help you, the system admin, come up with a plan to handle situations involving breached security.

FTP hacks seem to be on the rise nowadays, with viruses like Gumblar stealing FTP passwords and farming them out to hackers so they can upload malicious code into user files. What you end up with is a flood of complaints from users about errors on their site and being flagged by Google for malicious content.  And as you know, when  things like this happen the first person the customer tends to blame is the hosting provider.

While it’s really not something you as the hosting provider can control, there are measures you can take to secure your server against FTP hacks.

Lately FTP has been a problem for a lot of hosting providers. Especially since the recent influx of Gumblar-related attacks and FTP exploits, some hosting providers are now considering changing their FTP ports as an added measure of security. If you’re on a cPanel server you have a couple extra steps to go through, but it’s a rather easy change.

Pure-FTP

1) Edit /etc/pure-ftpd.conf and look for the following line:

Bind <addr> <port>

Where <addr> is a publically routable IP.  The default example, 127.0.0.1, will cause the socket to bind locally but then this connection won’t serve externally. <port> is the new port you wish to put the service on.

2) If necessary, add the new FTP port to your server’s firewall

3) Edit /etc/chkserv.d/ftpd and change the port, which is the first comma-separated entry to the right of ‘=’ on the line in the file, to match the port you put the service on.

Finally:

/etc/init.d/pure-ftpd restart
/etc/init.d/cpanel restart (restarts tailwatchd/chkservd)

ProFTP

Edit /etc/proftpd.conf and change:

Port 21

Then make sure to test to make sure FTP is working before notifying your users!

DomainKeys (DKIM) and SPF records are becoming a common, and annoying, demand among email providers, mainly Yahoo and Hotmail. In short, both are methods of email authentication designed to verify email integrity, by linking a sender to a specific server or hostname. In other words, DomainKeys and SPF records specify what servers can send email on behalf of a domain name.

You’ll want DomainKeys and SPF records if your users have trouble sending email to certain providers, or they are having issues with spoofed (forged) email. CPanel currently allows two easy ways for you or your users to set up email verification. This is supported at least from cPanel 11.18 onward.