script cracked my server
 

So I'm sitting there in the other room and my server just starts playing music out of the blue. Turns out whatever broke in was typing commands exceedingly fast into the currently active tty which consequently had left mocp running on. I quickly pulled the plug on the switch and the server.

Now I can track down where the attack came from myself with the snort logs I think. What I would love to figure out is what service the attack made it in through. My first thought would be Apache since I haven't bothered to update it in about 3 months and it was running whatever was in Debian Unstable at the time.

So what kind of vulnerability would give the attacker control of the currently active interface? I would rule out ssh since that would give the attacker their own shell not one I had locally logged in. Do I just start digging through apache logs? Where should I start?

Obviously I'll never boot off that drive again. For now I'll yank the HD and put the backup in and do any forensics on that disc off a bootable cd. This should be fun, I've never had the opportunity to track down a breach before :)

Bit lost, did you perhaps get root-kitted at some point? My first guess if it was a root kit would be it was FTP related (FTP is highly insecure, Thus why SFTP and SCP exist). My guess is that something like they placed in some kinda cron job and it was just passing out the information in any relavant open places, like your active shell or what not, could be wrong...

however if you were root-kitted, I'd probably think about reinstalling the machine from scratch, root-kits are horrific after all...

In short: start with the Intruder Detection Checklist (CERT): http://www.cert.org/tech_tips/intrud...checklist.html.

What you're looking for is building an understanding of the situation, which is different from "guessing" message the first reply carries. Even without talking about evidence acquired for judicial purposes and court situations, anyone with a structured approach to diagnosing things, any investigator will tell you that guessing is as bad as assuming, and you know what assuming makes... The checklist should guide you through most of the basic needs for gathering information like purpose of the box, date and duration of incident, distro+release+kernel data, audit data (system, daemon and firewall logs), auth data (login db, et cetera), IDS data, installed SW versions, integrity and updates, running services, finding "evidence" like setuid root files or LAMP piggybacking or user shell histories. There's lots of basic forensics docs on the 'net if you're interested in that and you could also search for and read some incident response threads in this particular forum. We've handled a few.

Also often the first thing to do would be doing nothing except for thinking over the sequence of ops and the consequences of performing those on a system. It's not for nothing Wise Hannibal says he loves it when a plan comes together: Think. Plan. Act.

For futures sake try and also have an integrity checker in place. Tripwire does a very good job on this though other people may have different utilities for this. Then, whether the results of your forensics point to apache or not, try and keep your box uptodate. Its always best practise to do so.