I'm surprised more people aren't running tripwire or other IDS.
On Tue, Jun 2, 2009 at 1:37 PM, Guntram Trebs <email@example.com> wrote:
> there are few chances of replacing sshd without being root. In your place i
> would install every server new.
> I think, he spied out passwords and maybe got root-Passwords in this way.
> Possibly he has even accessed servers where you didn't find him and left
> backdoors there. (manipulation of ~/.ssh/authorized_keys, another user with
> userid 0, replaced software, replaced suid-accesses, added software, ...)
> When you reinstall your servers think of not using Login+Password but
> public-private key for user authentication.
> You can even forward such a combination. But be aware, that if key
> forwarding is enabled it can be used by attackers too.
> You should then protect the private key by password and use it only from
> trusted machines.
> Avoid keyforwarding unless you need it, for instance when copying files from
> one server to the other it could be useful.
> Lock your trusted working computer always when leaving it and think of
> encrypting the filesystem. (Be aware that a local attacker can install a
> password sniffer even if you encrypted your system partition)
> good luck and think of not accessing the new installed computers from old
> ones ...
> Johann Spies schrieb:
>> On Mon, Jun 01, 2009 at 07:23:27AM -0400, Michael Stone wrote:
>>> Yes, that's a typical location for intruders to drop files. Easiest
>>> thing to do is reinstall after thinking about how the compromise may have
>>> occurred. (Did you update regularly, including kernel updates? Did all
>>> accounts have strong passwords? Do you have web applications not managed by
>>> the system that weren't being updated? etc.)
>> We had a serious situation on this computer and several others. Ssh
>> and sshd were replaced by the cracker's own version and in once case
>> nearly all the pam-related stuff were replaced also. Through this
>> customised versions of ssh the cracker harvested every password that
>> was used during ssh logins and ssh sessions.
>> We are winning the battle and will in the next few weeks try do the
>> analysis of what went wrong.
> Guntram Trebs
> freier Programmierer und Administrator
> +49 (30) 42 80 61 55
> +49 (178) 686 77 55
> To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact