Then, go here:
(Damn, it takes too much time to write these replies :-[ )
From now on, regard this system as UNTRUSTED. DO NOT USE IT, AND DO NOT ALLOW OTHERS TO USE IT.
Here's what you do:
Precaution 0: read
Steps for Recovering from a UNIX or NT System Compromise before doing anything else.
Precaution 1: For any operations on the server boot your distro's rescue cd, any cd-based distro (Trinux, Knoppix, Finnix, FIRE, PSK) or a one-floppy distro like tomsrtbt, LOAF. DO NOT BOOT the kernel from the harddisk or let it automatically mount the disks. If you need to mount the disks, mount them readonly.
1. Power down the server. This will render the system useless to the cracker and protect you from doing stuff on the box. Running any system diagnostics wouldn't make sense because you can't trust your system to not lie to you. Forget about making backups, forget about saving files, just drop it.
Notify local and remote admins and users about the compromise. : if this box is used to access remote boxen, other boxen on the network, etc, etc alert network admins. Also alert users of the box their authentication is void and ask them to change any auth they share with other boxen. Alerting is best done from a box that doesn't reside on the same subnet as the compromised one. Initiate checking other boxen on your network. Inform your ISP if you want to.
2. This step depends on what you want to do:
2a. If you want to spend time trying to find out what exactly happened, prepare another box on the network, else skip to 3b. This means combing over that box and make sure it is SAFE to use. If unsure it's your choice to either not use the box, or use the 3 R's: repartition, reformat and re-install from scratch. Make sure the box has enough diskspace (minimally 2x the disks to duplicate). Make copies using "dd" over the network or physically mount the disk on the other box. For dd'ing out you don't need to mount the partitions, just "dd if=/dev/<partitionname> of=/somedir/somefile_<partitionname>" and don't forget the swapfile. What does this yield? Absolutely nothing. Now you've got a copy of the disks you can perform basic forensics on them and try to work out what happened. I'd be glad to help you, but remember this is tedious and time consuming work, and the result is not guaranteed.
2b. OK. You decided not to "play" with forensics. Copy the /etc and /var dir off the server. These include most system config files and logfiles. Comes in handy if you want to see if you can get to know something w/o doing full-fledged forensics.
Precaution 2: read
Starting from Scratch: Formatting and Reinstalling after a Security Incident first.
3. Make sure you copy out any config files you forgot under 3b. DO NOT COPY BINARY DATA. Copy only verifiable, human readable data out. Exceptions are /var files like utmp, wtmp, lastlog and any other accounting files. Grab all updates from a local ftp mirror. Now use the 3 R's: Repartition, reformat and reinstall from scratch. Install only what you need NOW. Finish by applying the updates. Make sure you render any backups inaccessable and change all users passwords.
Don't connect the box back to the network, but first head over to the Linux - Security forum and read the "FAQ: Security references" thread, especially post 1. At least read these:
UNIX Security Checklist v2.0:
http://www.cert.org/tech_tips/unix_s...cklist2.0.html
SANS, The Twenty Most Critical Internet Security Vulnerabilities:
http://www.sans.org/top20/
Linux Administrator's Security Guide (LASG):
http://www.seifried.org/lasg/
Securing Optimizing Linux RH Edition (older):
http://tldp.org/LDP/solrhe/Securing-...-Edition-v1.3/
Intruder Detection Checklist (CERT):
http://www.cert.org/tech_tips/intrud...checklist.html
Intrusion Detection Primer:
http://www.linuxsecurity.com/feature...e_story-8.html
Add checking any distro specific stuff like mailinglists and hardening.
...and finally to answer your questions:
This scricpt kiddie knows his job i use chrootkit almost everyday but it always show nothing infected.
First of all you shouldn't trust just one tool. Second, SuckIT file hiding and skdet checks where added recently to a tool similar to Chkrootkit: Rootkit Hunter. Third point I'd like to make is that tools in that category suffer from using default locations and default binary names for checks. Once you change your location or binary name you're safe from any "find" ops, unless someone runs "strings" for identification or uses specific (skdet, kern_check, ip) or more tools to find anomalies. That's why you should install a filesystem integrity checker (Aide, Samhain, tripwire) once the OS is installed.
Now what i want to know is how to remove this s*ckin' SUCKIT.
SuckIT installs default built binary called "sk" as /sbin/init. SuckIT (if unmodified) will uninstall itself when you call the "sk" binary with argument "u". So "/sbin/init u" should unload SuckIT.
This by no means means you're in the safe zone.
Is there any chance to secure my system since now ? Without OS-Reload.
In short, no. One would be insane to suggest it.
A slightly longer explanation: Yes, rebuild it. You have no idea what the cracker knows about your system, what it was used for, what backdoors are in place and what service she used to get in. Thinking you can get your box up to the point where it's more or less secure without rebuilding it from scratch is a fallacy.
And is there any chance to trace this script kiddie back?
In short, since the box has been found compromised for that long a period, chances are low.
A slightly longer explanation: when an intruder enters the system she will introduce methods to stay as much invisible as possible for as long as she can manage it. Removal or hiding of suspect files and logcleaning are the first things. Undelete could yield results (ls_hidden, an_check, mc VFS undelete, TCT), be partially undone, but only when it was discovered real soon after, and provided the server doesn't do much writes to the places where unlinked data lives.
// Out of sheer selfinterest, if you could secure me a copy of the contents of /dev/sdhu0/tehdrakg and whatever files changed on the system (no system auth stuff) and make it available for download I'd be happy. if you do, please *email* the download location.
This scricpt kiddie knows his job i use chrootkit almost everyday but it always show nothing infected. Also I found /sbin/inittehdrakg and /sbin/init were created on 3th January. 
I'm more serious about system security since my last box compromised. I'm using fedora core 1 and grsecurity patched kernel which is 2.4.26 and i followed steps you suggested. I also sent you an email that contains files link of that atacker left behind. Thank you very much.
