Can some1 tell mewhat does this mean?
Hello folks, thanx for reading
i was about to reboot one of me webservers so i went to root and type: /sbin/shutdown -r now so the system told me that it was going to reboot but also this apered /dev/null RK_Init: idt=0xc0361000, sct[]=0xc02e92e4, kmalloc()=0xc012d8e0, gfp=0x1f0 Z_Init: Allocating kernel-code memory...Done, 12875 bytes, base=0xc6d38000 BD_Init: Starting backdoor daemon...Done, pid=29361 and the server didnt reboot so, i had to type again /sbin/shutdown -r now but what does that mean? a security problem? plese help =) this is my os: Red Hat Linux 7.2 (Custom) and Apache 1.3.2x web server Thanx Peace |
Box hacked: clean up please.
BD_Init: Starting backdoor daemon
It's definately the SuckIT rootkit. but what does that mean? a security problem? Yes. Someone gained access to your server, then installed a rootkit to be able to return later to abuse the system. From now on, regard this system as UNTRUSTED. DO NOT USE IT, AND DO NOT ALLOW OTHERS TO USE IT. ...and forget about getting that one last minute thing done. OK. What to 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. Notify any local and remote users about the compromise. Check the other boxen on your network. Inform your ISP if you want. 2. If you want to verify this really is the SuckIT rootkit, boot the Knoppix, FIRE or PSK cd and use "chkrootkit". Mount the harddisks readonly and scan. Alternatively, boot any other cd and do a "find" on all partitions for a binary called "sk": "find /yourmountpoint -type f -name sk" and/or versions of init: "find /yourmountpoint -type f -name "init*" ". 3. This step depends on what you want to do: 3a. 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. 3b. 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. 4. Precaution 2: read Starting from Scratch: Formatting and Reinstalling after a Security Incident first. Make sure you copy out any config files you forgot under 3b. DO NOT COPY BINARY DATA OUT. 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. 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 Mailinglists distro specific: RedHat http://www.redhat.com/support/errata/ http://www.redhat.com/mailing-lists/...ist/index.html Hardening, distro specific: Debian/Mandrake/Red Hat: Bastille Linux: http://www.bastille-linux.org/ |
God dammit
well in the mean time, i have changed teh root password.. does this will protect me some how? Thanx for your reply ! |
well in the mean time, i have changed teh root password.. does this will protect me some how?
Against what? |
i mean to avoid the hacker to gain acces to root...
u said some1 hacked in and installed that crap.. so i have changed the root password... soif he trys to enter agin he wont be able to control it right? sorry, but am kinda newbi!...--scared--- |
soif he trys to enter agin he wont be able to control it right?
Wrong. As long as you keep the box powered and plugged into the network there is no way you can make sure the box is under your control. You're stalling. Please follow the steps and start cleaning up... //For those into LRKs: yeah I know how to uninstall sk, but anyone doing so might be tempted to "restore" the system as well thinking all is safe, which is the WRONG conclusion. Please don't offer it as a solution. |
Hi upSpwan,
Please tell me how to get rid of Suckit Zubin |
You did read _all_ of the posts in this thread, right?
Hint - look 5 posts up......ah......there you go. |
Good info ; bookmarked this page just in case.... [:)]
|
All times are GMT -5. The time now is 04:08 PM. |