On Sun, Apr 05, 2009, Michael A. Peters wrote:
>Bill Campbell wrote:
>> On Sun, Apr 05, 2009, Ralph Angenendt wrote:
>>> Michael A. Peters wrote:
>>>> Ralph Angenendt wrote:
>>>>> Frédérique Da Luene wrote:
>>>>>> Useradd newuser : ok
>>>>>> passwd newuser : ok
>>>>>>
>>>>>> The password is not MD5, only 3DES.
>>>>> Again: Have you looked if passwd on your machine is the one from CentOS?
>>>>>
>>>> I would suggesting copying the binary to a known clean machine to check
>>>> the md5sum to verify. If you might have been hacked, you can't check
>>>> the md5 on that box.
>>> Yupp. The last times I had to handle/help in such situations, the binaries
>>> were clearly way off for the machines - often a comparing ls -l is enough, but
>>> not all the time.
>>
>> This will tell if the program is different and works on any RPM
>> based system regardless of their package contents.
>>
>> rpm -V `rpm -qf /bin/login`
>
>This assumes that rpm and the library it uses have not been compromised.
>I personally suspect the machine has been compromised.
So far I have not seen either rpm or its database changed on any
of the Linux cracks I have analyzed, and I have a fairly large
sample set. That isn't to say that it can't happen.
We also use a system I have developed, similar to tripwire and aide,
that maintains a database of all critical files on the system,
and will detect any changed files at least in /bin, /sbin,
/usr/bin, /usr/sbin, and /etc directories, and any setuid files
on any file systems not mounted suid. This runs at least daily,
and sends e-mail notification of any changes to our security
alias using direct SMTP, bypassing the system's e-mail system in
case that is either down or compromised.
I disable prelink as (a) I think it is a dubious optimization,
and (b) it can make changes that make tracking system integrity
more difficult.
Given a good database and quick detection of intrusion, I have
found it possible to clean systems quickly and with a reasonable
degree of confidence presuming that the system has been monitored
properly from installation. I certainly wouldn't try this on a
system that has been unmonitored from birth.
FWIW, the vast majority of cracks of Linux systems I have seen
were made first through weak user passwords. While it's possible
to have good passwords required in private or business systems, I
have found it practically impossible in and ISP environment where
the customers don't care about security and can't be forced to
use good passwords. Most often these cracks have been made via
webmin or its child, usermin.
We restrict access to webmin to the local LAN, and perhaps a few
external IPs, and usually disable usermin entirely. We also give
most users a /bin/false shell unless they have a real need for shell
access (although I did see a case where somebody had replaced
/bin/false with /bin/bash on a system we inherited so had not been
monitored consistently).
Bill
--
INTERNET: bill@xxxxxxxxxxxxx Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
Voice: (206) 236-1676 Mercer Island, WA 98040-0820
Fax: (206) 232-9186
No matter how much I may exaggerate it, it must have a certain amount of
truth...Now rumor travels fast but it don't stay put as long as truth
Will Rogers
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
