4

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

Gabriel
  • 193
  • 1
  • 8
  • 5
    Welcome to the community! You might want to take a look at the following questions to get you started: http://serverfault.com/questions/107334/how-to-do-a-post-mortem-of-a-server-hack and http://serverfault.com/questions/87421/ and http://serverfault.com/questions/38448/ and http://serverfault.com/questions/35366/ and http://serverfault.com/questions/86051/ and http://serverfault.com/questions/154118/ – Mark Henderson Jul 10 '10 at 22:35

4 Answers4

28

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?

MDMarra
  • 100,183
  • 32
  • 195
  • 326
3

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.

upasaka
  • 1,365
  • 9
  • 6
2

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.

MDMarra
  • 100,183
  • 32
  • 195
  • 326
Brandon
  • 161
  • 6
  • 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
1

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/)

Gray Race
  • 833
  • 2
  • 10
  • 20
  • 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 00:04