Hey guys...
I've recently been hacked ( or atleast I think so) and need some help getting my company's server back up agian.
What I need is a complete directory listing of /lib from a fully up-to-date 3.4 distribution.
Also, if someone could email over the libc file to erik.douglas (at) gmail (dot) com that would be greatly appreicated.
Thanks in advance.
On Sat, 2005-04-09 at 12:34 -0400, Erik Douglas wrote:
Hey guys...
I've recently been hacked ( or atleast I think so) and need some help getting my company's server back up agian.
What I need is a complete directory listing of /lib from a fully up-to-date 3.4 distribution.
The contents of the /lib directory are unique for each install, and totally based on the items you have installed.
Also, if someone could email over the libc file to erik.douglas (at) gmail (dot) com that would be greatly appreicated.
libc isn't really a file, but there are several rpms that you might consider libc ... the rpms: glibc and libc-client ... and maybe libstdc+ + are all releated to libc.
If you have been hacked, you should probably not clean up the computer, but should backup data and re-install from scratch. If someone has hacked you, they can have installed binary files that look like the original but contain Trojan listeners for remote login that are hidden from the installed programs.
Johnny Hughes wrote:
[snip]
If you have been hacked, you should probably not clean up the computer, but should backup data and re-install from scratch. If someone has hacked you, they can have installed binary files that look like the original but contain Trojan listeners for remote login that are hidden from the installed programs.
That is absolutely the way to handle a hacked machine. Unless you've got MD5 fingerprints of each file on the system (a la tripwire), there is no way of knowing where the naughty people may have stashed future surpises for the original poster.
Cheers,
C
Chris Mauritz wrote:
That is absolutely the way to handle a hacked machine. Unless you've got MD5 fingerprints of each file on the system (a la tripwire), there is no way of knowing where the naughty people may have stashed future surpises for the original poster.
And even then you need to have those fingerprints on RO media and verify them off-line (relative to the machine's normal state) such as from a bootable rescue CD.
On Sat, April 9, 2005 11:04 pm, Phil Brutsche said:
Chris Mauritz wrote:
That is absolutely the way to handle a hacked machine. Unless you've got MD5 fingerprints of each file on the system (a la tripwire), there is no way of knowing where the naughty people may have stashed future surpises for the original poster.
And even then you need to have those fingerprints on RO media and verify them off-line (relative to the machine's normal state) such as from a bootable rescue CD.
If you can aford the time, if you have not already, you need to determine how the hacker gained access, otherwise, when you re-install your OS and applications again, you may well get hacked all over again.
Having Tripwire, etc., may be useful for determining what files were changed, but I'd never rely on a host integrity system to 'recover' a system. Always re-install to have a clean system. You'll be much better off.
Just my 2cents. :)
~Dan
On Apr 10, 2005 12:49 PM, T'Krin tkrin@tkrin.net wrote:
On Sat, April 9, 2005 11:04 pm, Phil Brutsche said:
Chris Mauritz wrote:
That is absolutely the way to handle a hacked machine. Unless you've got MD5 fingerprints of each file on the system (a la tripwire), there is no way of knowing where the naughty people may have stashed future surpises for the original poster.
And even then you need to have those fingerprints on RO media and verify them off-line (relative to the machine's normal state) such as from a bootable rescue CD.
If you can aford the time, if you have not already, you need to determine how the hacker gained access, otherwise, when you re-install your OS and applications again, you may well get hacked all over again.
Having Tripwire, etc., may be useful for determining what files were changed, but I'd never rely on a host integrity system to 'recover' a system. Always re-install to have a clean system. You'll be much better off.
Just my 2cents. :)
It is also much more cost-effective to re-install and restore *data* from backup. It will also give you a re-assurance that you didn't miss any backdoors etc.
Re-install + restore data shouldn't take more then 2 hours. Trying to salvage a system, where you can't be certain that you found all the malware, usually takes much longer. So it is better both from a technical point of view and from a business point of view to re-install the machine (tip: have a "rescue" kickstart image for each server - it can save you enormous amount of time in some cases, and it will always be faster then human interaction. And at the same time you can be sure you get all the packages you need every time you do it).
If you don't have a working backup of the data you can copy it from the compromised system, but be careful so you only get *data* and not applications and stuff. This is why backup of data is SO important, but I usually don't waste backup storage on something that can be easily re-installed (so I backup /home/*, /etc/* and so on - but I don't waste time and storage for /bin, /sbin/, /lib, /usr/sbin etc.).
You can ask RPM to tell you which files has been modified since install. This is good for finding out what to backup but don't trust it when it comes to figure out what has been modified in an intrusion. The RPM database is easy to manipulate for an attacker.
Best regards Michael Boman
-
Chris Mauritz -
Erik Douglas -
Johnny Hughes -
Michael Boman -
Phil Brutsche -
T'Krin