I've got a new dedicated server with Rehat 9, and whilst I have no specific reason to believe it has been compromised, because I'm a newbie it took me some time to re-do passwords and get a firwall. So for a while may server may have been vulnerable.

I would like to check it out with chkrootkit and I understand that this should be used with 'trusted' commands (binaries). As I have no direct access to my server (only via ssh), how can I get chkrootkit with trusted commands. Can chrootkit access them from elsewhere, or can I upload them usinf wget? If so how?

Step by step instructions would be most appreciated.

Thanks, Jack.

can you run lynx on your server?

That's how I do it on mine...I ssh into it, run lynx www.chkrootkit.org, download the latest, tar -xzvf and run...

What is lynx and how would I use it?
I already have chrootkit installed - as I understand it I should force it to use a 'trusted' version of Linux commands. If my machine has been cracked the existing required commands could be suspect, therefore I need a new trusted set (in a new directory?).
The commands listed as required are:
awk, cut, echo, egrep, find, head, id, ls, netstat, ps, strings, sed, uname.

Thanks, Jack.

IMO you should have started by taking some precautions, like setting up a system integrity checker (Aide, Samhain, tripwire) when you installed/first accessed the system. That would alert you on the state of the binaries. Also, if you're running Ext2/Ext3 you should add extended attributes to render the binaries immutable: "chattr =i </some/binary>" or "chattr =i -R </some/dir>".

As for chkrootkit using "-r", you could use OpenSSH's "scp" to copy static compiled binaries over if you need to. Using Busybox you can cut some diskspace, but some apps you will need to compile from the GNU packages. I would not compile Chkrootkit on that box, but on a box you trust, and then scp over the package. Please note on the Linux i386 platform using a 2.4 kernel in conjunction with deploying any libpcap apps, Chkrootkits' ifpromisc DOES NOT detect an interface in promiscuous mode. Unfortunately Nelson doesn't think it's a real problem... If you want to patch your chkrootkit, look here: http://www.rootshell.be/~unspawn/pac...hkrootkit.html
Nothing you couldnt do yourself tho, just use "/sbin/ip" from the "iproute2" package.


If you do not trust your server (you expect it to be compromised), then introducing "trusted" binaries may or may not help you detect a compromise, depending on who the intruder set up her stuff.

Could you describe in detail what services the server is running, who has access to it, and who has accessed it (no names, IP's, just account for it yourself) and if the system and/or logs show any anomalies?

Thanks unSpawn,
Well, my dilema is that I got the server just before going on holiday (bad timing). As a total newbie I just changed the admin and root passwords (to strong passwords), and thought that would be OK. Since I got back I have been on a steep learning curve and realised I should probably have done a bit more at the outset. I think I am now reasonably secure having followed much advice from the BB and other sources. However, I don't know how secure my server was for that first week or so. I have no reason to suspect anything is wrong but I just wanted to carry out whatever check would be sensible in this situation to reassure myself.
I would be gratefull for any step by step guidance in checking logs or whatever to give me a warmer feeling. I don't think the situation warrants a restore/re-install.
I have installed Tripwire but not set it up yet as I want to try and ensure my server is clean.
Any advice? Remember, I'm very new so you will have to spell it out for me.
Thanks, Jack

*Btw, you didn't answer all of my previous questions. If you don't know how to, just say so, else please provide the info cuz it could have been usefull for *this* post instead of being a waste of energy and time for me.

I think I am now reasonably secure
There is no "thinking" involved. It either is secure or it ain't.

having followed much advice from the BB and other sources.
Telling us *exactly what* you did would make it easier.

However, I don't know how secure my server was for that first week or so. I have no reason to suspect anything is wrong but I just wanted to carry out whatever check would be sensible in this situation to reassure myself.
Since you have no idea of the state the system was in in the first place, this will not produce results that can be fully trusted.
For instance, if a cracker did set up a kernel module (LKM) chances are processes are hidden and system calls rerouted. You will not find any evidence of those unless you unfortunately stumble on something like this or are able to have someone perform checks using a bootable cd.

Since this is a dedicated remote server, your only means of access is using SSH as you stated. If you log in directly as root, add an unprivileged user, set up the ssh keys and sudo and never login as root directly again. Login with your unprivileged user, sudo to root.
If you don't have the discipline to keep an admin logfile (you should), make your shell's .login file use "script <unique filename>" to record anything you do on the system.
I. Set up network access and local restrictions. See this post.
Be warned it doesn't handle specific server measures, just the essentials.
II. Check system authentication for anomalies: inspect your /etc/{passwd,group,gshadow,shadow} files. If any service on the box uses external (PAM) flatfiles or databases for authentication, inspect those too.
III. Check system access restriction files and network daemon configs for anomalies: basically anything with "allow" or "deny" or "conf" in the filename in applications configuration directories like /etc, /etc/xinet.d.
IV. Check your system logs in /var/log.
Info in the last and wtmp files can be accessed using "last": use "last -aix". Info in lastb can be accessed using "lastb" with the same flags as "last". Other anomalies in the login records can be accessed using "ac" like in "ac --complain --tw-leniency 60 --tw-suspicious 120 -y". Extract the info and inspect it for anything out of the ordinary, including root logins when you are sure you couldn't have logged in. If you see the remote address 193.132.4.8, think nothing of it, its an annoying bug in Red Hat.
Dont forget to check the plaintext logfiles as well.
V. Use the rpm database to check the status of any installed rpm. Note this doesn't give you a scope on the files NOT introduced by rpm. "rpm -Va 2>&1|tee /tmp/rpmverify.log" will show you the results and save it.
VI. Run some system checker like Tiger and run Chkrootkit.
Tiger will run a lot of checks, it really comes in handy checking suid and sgid bits, dotfiles etc etc.
*This list isn't final, but it should get you going. If you want to be thorough, report back any details. One explicit exception: if it's too large but you still want me to review it, roll a bzipped tarball and if its size is not in excess of 500K, then you're invited to mail it to me. Else mail me a link where I can download it.


I don't think the situation warrants a restore/re-install.
Think about the reasons *why* you're saying this. Reasons in the "that's nice, but it's WRONG" category would be "because I put a lot of work in it already" or "because I need it to work *now*" or "because I don't want to waste time reading and fiddling with arcane and obscure things". Now tell me how you came to your conclusion...


I have installed Tripwire but not set it up yet as I want to try and ensure my server is clean.
You should have asked for the server to be delivered with tripwire (or Aide or Samhain) installed and ready, or set it up once you took control of it.


Any advice? Remember, I'm very new so you will have to spell it out for me.
Read the sticky "FAQ: Security references" thread, at least post #1. Check, implement. Increase your mana and ask specific questions.


HTH