Hi all, first time poster here.

I'm attempting to teach myself some ins and outs of linux security. I'm running a debian box in my dmz at home, purely as a trial and error teaching tool. I'll keep reformatting as needed. I'm only running sshd (22) and httpd (80). I installed the denyhosts python script to block brute force ssh attacks. There have been a handful of blocks over the past week or so, but I just logged in a few minutes ago and putty told me the ssh2 key was different than the cache copy, and that unless the sysadmin (me) had upgraded ssh or changed the key in some other way, that there was probably a compromise. I did not make any changes. Is it safe to assume that my box has been sacked? If so, can anyone suggest where I might have gone wrong? If not, any ideas why the ssh2 key might have changed without my intervention? Apologies if this is a question that's too wide open to solicit a reasonably concise answer. I will become more on-point as I learn more.

Thanks!

David

A couple of things could have happened short of being hacked - have you reformatted/installed since you last connected in with putty? Or have you upgraded ssh, to fix the bug that debian had with predictable ssh keys? Did you connect to anything with the same ip address?

A rooted box wouldn't necessarily have a different ssh key. An unmatched key is usually more symbolic of a man in the middle attack, or a machine spoofing the real one.

I had not made any changes. I logged in a few hours earlier and it was fine. Then all of a sudden, Putty was telling me there is a new key.

For a man in the middle attack to occur, how would that work? The linux box is on the 10.* private IP range on my LAN, and is in the basement. Would someone have to physically connect to my LAN between me and the linux box? That seems a bit unlikely. How else might a man in the middle occur here?

I agree, man in the middle seems very unlikely. Could very well likely be compromised. What version of Debian is running on it?

I downloaded a few weeks ago - 5.0 32 bit intel architecture.

Best bet then is to just wipe and reinstall. When you put together your new system, check out Tripwire at:

http://www.linuxjournal.com/article/8758

Why do people feel the need to give this advice on the basis of absolutely no evidence whatsoever? Wipe and reinstall just sets up the potential to get cracked again.

The proper way to deal with this is to investigate. The CERT Intrusion Checklist is a good place to start. The point is that you need to develop some FACTS about what you're looking at and work off of those facts.

given my situation and goals, i.e. I'm not trying to run a secure box for the long term, but am trying to learn how people break in, I prefer not to wipe it and start over without understanding how it was compromised. I'm certainly open to reformatting over and over as long as I'm learning something each time about what went wrong. I've used tripwire and portsentry before - I'll play with those a bit more.

Hangdog - thanks for the link.

That's a good attitude. However, please make sure that your box is sufficiently locked down that it isn't a threat to the rest of the Internets. If you can't pull the network cable on the thing, then you should throw up a firewall that only allows SSH access from a trusted IP. You don't want to turn it off (that could destroy evidence) but you do want to control who has access.

As for Tripwire, that isn't going to help now. That only helps if you have it set up prior to an intrusion. You also should have a look at Aide or Samhain as alternatives to Tripwire.

I'm not keeping it up for any length of time and I'll reformat each time it gets compromised (after I figure out how / why), so it's not going to become a useful fixture for an attacker to utilize. In this case, it has been powered off for the last 2 days while I investigate root causes. I had already checked the various log files to see if anything looked empty or modified, and checked some other things to see if anything looked out of place. I'll do a bit more investigating with those links you provided, but will ultimately wipe it clean before putting it back up, and this time with some additional tools and knowledge on my part. I'll just keep repeating that process until I feel like I've learned a lot, or I get bored, whichever comes first

Thanks!

David

As an aside, I see in your signature that you run slackware - any particular reason? I used to use slackware but have been using debian recently because it's what my school uses, and I find the apt-get tool to be very handy.

I would respectfully disagree about it being useful to an attacker. While certainly a system compromised over a long time is most useful, the bad guys can get some decent mileage out of short term compromises as well. A lot of spam can be sent in a few minutes. Of course this does assume that you have been compromised, which as of yet we haven't seen any substantial evidence.

That's too bad. Powering down does destroy evidence of a compromise. This is doubly true if you powered down by normal means instead of just yanking the power. A lot of cracks have the ability to remove evidence of themselves when the normal power-down is used (think deleting log files). In general, it is usually better to leave the system up, but to make sure that network access is either eliminated or extremely restricted. If you must power down, pull the power plug and then when you boot, do so ONLY from a trusted source like a live CD.

Please feel free to post your findings. There are a number of people here seriously interested in intrusions and can give a ton of help in figuring out what happened. I've learned pretty much everything I know about security and intrusion detection/analysis from following those sorts of threads.


To be honest, Slackware just makes sense to me. I'm not afraid of using the command line (in fact I kind of prefer it) and Slackware's KISS philosophy has saved me a lot of headaches. I know apt-get is useful, but I've seen problems arise from automatic dependency resolution. I guess I prefer to resolve my own dependencies. Besides, a couple of tools for Slackware, namely sbopkg and src2pkg, make compiling from source into a Slackware package a complete breeze.