SSH scans - I caught one

Most likely the "hacker" broke into the FTP server because the admin of that server used the word "password" as his password. So natural selection took them both out. Two less idiots to deal with.

Try to get the cops to care about this. Try to get campus security to care about this. Try to get your campus IT department to care about this. (They probably don't want you running servers anyway.)

Law enforcement has bigger issues. In a world where HBO can send a letter to my roommate from an IP in 10 days, and the police investigating a robbery have to wait 9 months for the same thing. You did the right thing.

I would have played a longer con game instead of nuking some random ftp server, he probably just set up another one.

I should have mentioned that I definitely thought of this scenario before I deleted anything and confirmed, via the hostname of the server, directory names, and file names, that everything on that server was for h4x0ring (at least for that user account).

I also thought of more subtle and clever ways to exact revenge, but decided I was too busy to pursue any of them.

Also: Do you think these guys put their IP address and FTP password out there for anyone to collect as evidence?

Yes, I do. You're giving the script kiddies far too much credit.

plan ahead & run an IDS on it

Depends on the compromise, but generally speaking the observable difference in behavior (assuming you are unable to monitor upstream of the router) is very minor. Greater power drain, and evidence of compromised information being used that could only have been gained from that source.

Without having access to a box that was compromised it's hard to tell since the attacker could hide his tracks.

For this case specifically, if you're running openwrt you could try 'ps aux|grep syslgd' and see if you find anything. Then use 'lsof -p PID#' to see what files it's using. Or use 'lsof -i' to see what software has open connections. This can be very telling. Maybe 'netstat -anp| and looks for syslogd connecting out to the internet.

You should really follow basic security best practices and disable sshd on the outside interfaces, firewall unknown address, and switch sshd to a different port (security through obscurity will prevent the mass drive by port scanning).

Analyze the firmware. If it doesn't pass a checksum, it could be compromised. If the software doesn't pass a checksum, it's compromised. Strange traffic coming out of the router is a bad sign. If the router is running analysis on your packet, you will likely experience diminished throughput on the high end because of limited resources on the router.

I think if you can go without enabling remote access to a router, then you should. This will protect the router itself from direct login attacks from the outside, but if somebody compromises a machine on your LAN, you're boned. If you can't, and you have security concerns, you need to establish metrics of verifying whether or not the router is behaving the same way it was when it came out of the box and (presumably) was not compromised. Like I mentioned, software/firmware checksums are a possibility (these could be hard, though...getting a router to dump its internals out probably isn't a feasible solution for everything), but YMMV depending on what you do and what you need your router to do. My biggest guess at the tell-tale sign of a compromised router is that it just starts slowing down.

With the places you access the computer from do you use dynamic or static IP addresses?

If they're all static IP addresses, try to block everything on port 22 except for your static IPs.

If it's dynamic you should have a pool address block, you can add the block in but there's a risk that if your block is in an ISPs home user pool that the botnet could infect people in your block.

If you can't use upstream filtering then I'd suggest you configure a firewall to do the same thing, either in hardware (preferable) or software.

If you password protect the keys it's essentially the same at your end as if you were using a password. The only difference being that they need to copy the keys if after compromising the password they want to log on elsewhere.

I say, that's a joke son. </foghorn leghorn>

As someone who runs a hosting company -- yes I fully investigate with the information given. Just please try to give as much as possible and make it easy for me to easily pinpoint things.

Oh, and please don't come with a snooty attitude, it's not pleasant to work with.

But for simple devices or server setups with few changes over time, it might be worth it as it would at least cause a little more work to hack in. I remember that it used to be encouraged to use non-standard paths for security's sake, but then it seemed like too much work for the reason you stated. But these days, with more automated attacks relying on standard paths, I don't think it is out of the question.

I'm beginning to think I could cause hackers a lot of headache via long-running find commands caused by directory trees full of tmp-like dirs. But then they'd just use one of them.

Change the environment variable name, go through through your apps (and kernel probably) change the code to use a new one. Anything is doable, it just takes time. I'm not saying it is trivial by any means; I'm just saying it is an option. If you build everything from source, it is more doable. In fact, it would be nice to have a secure -nix distro that did it for you. (I know there isn't one that does this, but it could generate a random env var names and paths during install, and maybe change them on demand (by external boot).)

I'm perfectly aware that this could be "extremely difficult" or "not feasible" in many situations, but it wouldn't be so hard to control if you made the device and designed the OS for it (linux-based routers, etc.). I'm just tired of people giving up and laying things out like a holiday dinner because it's "too difficult". Good security requires sacrifice of work and time.

But a find on root takes a lot of time in some cases, during which the attacker could be compromised. And the scripts might not use it for that reason. The script could use it as a backup only if the standard one doesn't exist, but still, it is a bump in the road, and might be worth it to cause the script to use find and delay it.