Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So yesterday I found out that my server was rooted via the h00lyshit exploit. So far I deleted all the files that might be asociated with the exploit. I also deleted all the ssh keys in ~/.ssh/authorized_keys. I changed the root password to 25 random character password and changed mysql passwords as well.

Also i think the attacker was from italy, and since i need to have access only from my country i blocked every ip range except my own country, will this help?

Do you guys have any good advice what i should do? I plan to disable root via ssh (i should have done it much sooner, I know :( ). And is there a way to check if he can access my server again?

Also no damage was done luckyly, oh an i'm running Debian Lenny with 2.6.26 kernel if somebody is interested.

PS: yay my first question :D

share|improve this question
4  
Welcome to the community! You might want to take a look at the following questions to get you started: serverfault.com/questions/107334/… and serverfault.com/questions/87421 and serverfault.com/questions/38448 and serverfault.com/questions/35366 and serverfault.com/questions/86051 and serverfault.com/questions/154118 –  Mark Henderson Jul 10 '10 at 22:35
    
h00lyshit was released years ago, haven't you done a kernel update since then? –  Dentrasi Jul 11 '10 at 14:39

4 Answers 4

up vote 29 down vote accepted

You should restore the server from a known good backup. There's no real way to know that no other back doors were installed is there?

share|improve this answer
12  
That's the definitive answer: Wipe it and start over. +1 –  John Gardeniers Jul 11 '10 at 0:13
    
+1 only solution there is –  Oskar Duveborn Jul 11 '10 at 15:29

I would always advocate a complete rebuild in the event of a known compromise. It's the only safe way.

Assuming you have backups, and they're recent, and they cover more than just the data on the server, you have material for forensics.

If you're not already using a tool such as Chef or Puppet to make fast rebuilds to a known state, then get started.

Once the machine has been rebuilt, you need to think about attack vectors and how to mitigate against them. You mentioned your ssh config - there are many others - for a Redhat-centric, and paranoid approach, look here:

http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf

For a Debian and similar approach, look here:

Debian dot org /doc/manuals/securing-debian-howto/

Good luck.

share|improve this answer

Unfortunately since he had root access there is no way to really know what the hacker did to the system. They could have modified logs to hide their tracks and any other damage done. Format and reinstall or restore from known good backups is the only safe way to go. Good luck.

Next time disable root login, change ssh port, and get iptables going right away.

share|improve this answer
    
What is changing the default SSH port going to do? Anyone banner grabbing is going to find the port you changed it to anyway. Security by obscurity isn't really security. –  MDMarra Jul 11 '10 at 17:02
    
Good point but most scanners are scanning common ports. Getting away from port 22 will help a great deal. I also didn't mean to say only change ssh port just that its another layer that will help. –  Brandon Jul 11 '10 at 17:08
    
I'd add AllowUser in the SSH config to hardening it. Changing the port also definitely helps, although, as stated, it can't be the only layer. I'd suggest changing it to something above 10000. By default, most port scanners only scan the common ports, so this filters out a lot of potential attackers. Obviously, this won't do anything to stop a dedicated attacker because they can find the open port on a full scan, but the point is that it's an added layer of protection. –  Paul Kroon Jul 11 '10 at 17:37
    
When the good base configuration is established, how about installing Tripwire (or some flavor thereof) to generate and record checksums for files and directories (OS and config, ACLs, etc)? The checksum information will be useful down the road to determine if unauthorized changes have been made. You may wish mount file-systems as read-only prior to running Tripwire as it will change the timestamps which may be critical in a legal investigation. –  jl. Jul 14 '10 at 15:29

Personally if I get rooted, grab the data from a backup ideally. If not grab it from the server and boot and nuke it. (http://www.dban.org/)

share|improve this answer
3  
How would dban do a better job of formatting the hard drive in this case than say, the Linux installer? –  MDMarra Jul 11 '10 at 0:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.