Here is the applicable article:
http://www.linux.com/feature/125548
There are links in the above article that explain tests for the system
and what is currently known about the rootkit.
Apparently initial access is NOT via any vulnerability but just guessed
root passwords.
There are currently 2 methods to see if you are infected:
1. In some cases, the root kit causes you to not be able to create
directories starting with a number ... so as root do:
mkdir 1
If it gives you an error similar to this, you are probably infected:
mkdir: cannot create directory `1': No such file or directory
2. Run this command for several minutes while you have windows users
connecting to your web server:
tcpdump -nAs 2048 src port 80 | grep "[a-zA-Z]\{5\}\.js'"
If you get output from this script, you may be infected.
=======================================================More info:
http://blog.cpanel.net/?p=31
http://www.cpanel.net/security/notes/random_js_toolkit.html
http://www.finjan.com/Pressrelease.aspx?id=1820&PressLan=1819&lan=3
http://www.pcworld.com/article/id,141358-c,techindustrytrends/article.html
http://www.webhostingtalk.com/showthread.php?t=651748
=========================================================
This does not seem to be caused by a specific vulnerability that CentOS
or RHEL or cPanel has, but rather it seems to be caused by compromised
root passwords.
There are several recommendations in the above links to prevent becoming
infected as well as what to do if you are infected.
While there does not seem to be anything that the CentOS Development
Team can "FIX" in relation to this issue ... I thought I would put
the
information out so that people can test their machines and take action
as necessary.
Thanks,
Johnny Hughes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20080128/b61858e8/attachment-0002.sig>
Johnny Hughes wrote:> Here is the applicable article: > > http://www.linux.com/feature/125548 > > There are links in the above article that explain tests for the system > and what is currently known about the rootkit. > > Apparently initial access is NOT via any vulnerability but just guessed > root passwords. > > There are currently 2 methods to see if you are infected: > > 1. In some cases, the root kit causes you to not be able to create > directories starting with a number ... so as root do: > > mkdir 1 > > If it gives you an error similar to this, you are probably infected: > > mkdir: cannot create directory `1': No such file or directory > > 2. Run this command for several minutes while you have windows users > connecting to your web server: > > tcpdump -nAs 2048 src port 80 | grep "[a-zA-Z]\{5\}\.js'" > > If you get output from this script, you may be infected. > > =======================================================> More info: > > http://blog.cpanel.net/?p=31 > > http://www.cpanel.net/security/notes/random_js_toolkit.html > > http://www.finjan.com/Pressrelease.aspx?id=1820&PressLan=1819&lan=3 > > http://www.pcworld.com/article/id,141358-c,techindustrytrends/article.html > > http://www.webhostingtalk.com/showthread.php?t=651748 > > =========================================================> > This does not seem to be caused by a specific vulnerability that CentOS > or RHEL or cPanel has, but rather it seems to be caused by compromised > root passwords. > > There are several recommendations in the above links to prevent becoming > infected as well as what to do if you are infected. > > While there does not seem to be anything that the CentOS Development > Team can "FIX" in relation to this issue ... I thought I would put the > information out so that people can test their machines and take action > as necessary.As a secondary note, the CentOS Security Team (and also the upstream security team) would like to have access to an infected machine for analysis, if anyone is infected and if they can spare the machine for several days for us to analyze (you should change your root passwd and take apache off line ... meaning you would need to stand up another web server to replace this one). So, if you have a machine for the cause that was infected in the wild that you can spare, you can contact the CentOS Security team at: security_AT_centos.org We will work also with the Red Hat Security team and see if we can isolate any issues that might be FIXABLE. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20080128/fb6765d9/attachment-0002.sig>
On Mon, 2008-01-28 at 19:55 -0600, Johnny Hughes wrote:> Johnny Hughes wrote: > > Here is the applicable article: > > > > http://www.linux.com/feature/125548 > > > > There are links in the above article that explain tests for the system > > and what is currently known about the rootkit. > > > > Apparently initial access is NOT via any vulnerability but just guessed > > root passwords. > > > > There are currently 2 methods to see if you are infected: > > > > 1. In some cases, the root kit causes you to not be able to create > > directories starting with a number ... so as root do: > > > > mkdir 1 > > > > If it gives you an error similar to this, you are probably infected: > > > > mkdir: cannot create directory `1': No such file or directory > > > > 2. Run this command for several minutes while you have windows users > > connecting to your web server: > > > > tcpdump -nAs 2048 src port 80 | grep "[a-zA-Z]\{5\}\.js'" > > > > If you get output from this script, you may be infected. > > > > =======================================================> > More info: > > > > http://blog.cpanel.net/?p=31 > > > > http://www.cpanel.net/security/notes/random_js_toolkit.html > > > > http://www.finjan.com/Pressrelease.aspx?id=1820&PressLan=1819&lan=3 > > > > http://www.pcworld.com/article/id,141358-c,techindustrytrends/article.html > > > > http://www.webhostingtalk.com/showthread.php?t=651748 > > > > =========================================================> > > > This does not seem to be caused by a specific vulnerability that CentOS > > or RHEL or cPanel has, but rather it seems to be caused by compromised > > root passwords. > > > > There are several recommendations in the above links to prevent becoming > > infected as well as what to do if you are infected. > > > > While there does not seem to be anything that the CentOS Development > > Team can "FIX" in relation to this issue ... I thought I would put the > > information out so that people can test their machines and take action > > as necessary. > > As a secondary note, the CentOS Security Team (and also the upstream > security team) would like to have access to an infected machine for > analysis, if anyone is infected and if they can spare the machine for > several days for us to analyze (you should change your root passwd and > take apache off line ... meaning you would need to stand up another web > server to replace this one). > > So, if you have a machine for the cause that was infected in the wild > that you can spare, you can contact the CentOS Security team at: > > security_AT_centos.org > > We will work also with the Red Hat Security team and see if we can > isolate any issues that might be FIXABLE.---- doesn't this almost beg for upstream to make denyhosts a base install and automatically on, just as sshd is automatically on? Craig
Along the lines of staying safe, now is probably a good time to check
your password policies.
1. Don't allow root access to ssh. (modify /etc/ssh/sshd_config)
2. restrict root logins to only the local machine. (modify /etc/securetty)
3. Limit users with access to 'su' to the wheel group (use visudo and
also modify /etc/pam.d/su)
4. Make sure root is the only one with a uid of 0. ( awk -F: '($3
="0") {print}' /etc/passwd )
5. Use pam to require strong passwords. (install/use pam_passwdqc
which is part of the base distro, modify /etc/pam.d/system-auth )
6. Use denyhosts or pam.tally2 to restrict login attempts.
7. use ssh keys.
And above all, because I know many admins slack on this, and I'm
guilty of it as well if it's not forced... ROTATE your passwords
periodically
The recommended password requirements for root: at least 10 characters
with a mix of upper/lower case, special characters, and numbers.
Discussion, and alternate suggestions welcome.
--
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell
Frank Cox <theatre at sasktel.net> wrote:>>I have never understood this. If I have a good, strong password that nobody knows, how is changing it to another one an improvement over what I already have? << Correct. Modern thinking is to teach people how to create a good, strong password and then stick with it for a longer period than has traditionally been the case. A rainbow tables attack against a captured hash can be done in just a few seconds, so unless you're prepared to change your password every few seconds, it's a futile gesture. Because most sets of rainbow tables cover all combinations of upper/lower case alpha, numeric and punctuation symbols, a strong password should contain at least one control character, a composed character (using the Alt+numpad technique) or some other non-printable character outside the rainbow tables set. Or use two-factor authentication (RSA SecurID or similar tokens, certificates, etc.). Best, --- Les Bell, RHCE, CISSP [http://www.lesbell.com.au] Tel: +61 2 9451 1144 FreeWorldDialup: 800909
On Jan 29, 2008 8:01 AM, Alfredo Perez <alfredoj69 at rogers.com> wrote:> Thinking about the above made me ask the following question: > > Is it possible to setup Centos to ask for a change of password > every month?Yep. Change the values in /etc/login.defs for PASS_* and use: chage -M <value> -m <value> -W <value> USER -- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell