I'm having some stability issues with Slackware 10, so I was looking in /var/log/messages, when I noticed about a billion failed login attempts (as root) from ssh.

Whoever was attempting to log in managed to successfully log in as 'test', an account I created quickly (with a very obvious password) and had forgotten to delete.

Anyways, I am wondering what I can do to check that my machine has not been compromised.... root kits or other logs or any other suggestions?

I know that I should try and harden my machine a bit. First on my agenda was making the machine stable though, but I guess I have a new priority now...

I haven't done any research yet, but in terms of setting up iptables, what can I block? Essentially, all I need open to the public is SSH. I am running vncserver, but if I block the ports, I should still be able to tunnel in, right? I also use file sharing on my local network, so I will need to open ports for that, correct? And how to ephemeral ports work? Am I at risk if I keep that entire port range open?

PS: I logged in via putty to my test account and was greeted with this:

Well, that wasn't me logging in... It appears someone has attempted to break in with a VoIP phone

Just noticed the stickied SSH login attempts thread... woops...

I'm guessing that after noticing 'test' used a weak username-password combo, someone attempted to manually try and crack the root password...

And I thought I'd never find somebody who actually uses a test/test account.
It's your own fault though.
Run chkrootkit, check integrity db, double check /etc/passwd, check iptable rules, check linux module dir for any weird modules
that shouldn't be there, check bash history file (and hope that person was dumb enough to leave it) and so on.
But I'm afraid you never really can trust that box again.

Yeah, I feel pretty stupid. I had made the test account very quickly because I needed to test something (big surprise) and forgot to delete it.

If someone logged in as my test account, could they really do that much damage? How would it be possible to escalate their permissions?

I'm going to check everything that you recommended.

Any chance of answering my firewall questions?

Thanks again. And I promise to not be so stupid anymore

If someone got onto your machine as the test account there are all sorts of local exploits they could try to escalate their priviliges. There've been a number of such exploits described for the more recent 2.4 and 2.6 kernels. Your best bet is to follow iceman47's advice and carefully check everything on the system. If you want to be absolutely, 100% sure, though, you need to backup, reformat, and reinstall.

As for iptables, I'm not a guru, but they're pretty easy to figure out just from reading the man page an the howto on tldp.org. If you only SSH to the machine from one address, you might consider adding an iptables rule that only allows SSH connections from that address (or network). You can block anything but port 22 and then yes, you can use VNC over an SSH tunnel I believe.

I think that what I might do is set up SSH better such that a) I can only log-in from a single user account (not root, but I think that I should be able to su - no problem) and b) get a usb memory key and set up public and private keys. That should help

I'm already SSH tunneling for VNC, so I'm pretty sure that port 5901 doesn't need to be open.

I have a bunch of iptables resources that I will be reading once I have enough time. I also need some other ports open though, do I not? I will be sharing files over the local network via samba. Also, do you have any knowldege about ephemeral ports?

Thanks!

That is amazing: I just looked at /var/log/secure and noticed that several dudes tried the test user trick on me. I was amazed and thought that maybe this is some kind of ssh exploit, but as you say, it is just simple trying to see if the sysadmin was not realizing what accounts he has on his machne.

interesting! I guess I am too paranoid even think about falling for that. ;-)

maybe use grsec ?

also running a X server (and a few other apps, like wine i believe) prevents your computer from being even more secure (without those programs you can enable more of the options in the grsec patch that would normally break xfree/xorg and and perhaps others )

Yeah for that brute force ssh attack thing. I set up a script in cron.hourly that parses my /var/log/messages and automatically adds a line to my firewall that blocks the ip. I think that will work. I would like to have it run every like 10 seconds but that would be too system intensive.

hey that's pretty cool... could you share the script with us please??

There was one posted at the SANS ISC the other day, though I'd make sure to read the caveats at the bottom. In general I'd be very carefull in how you implement this, as you could easily DoS yourself by inadvertantly adding your own IP or loopback address to the blocklist if an attacker decided to spoofed an IP. So using something like a whitelist is probably wise.

Here's a link to the SANS script:
http://isc.sans.org/diary.php?date=2...168abebbe0746b

awesome. thanks caveman.

Here is mine for comparison. Their good script to my convoluted crappy one:

http://irighti.no-ip.com/badips

I run the rc.firewall.badips script in my rc.firewall script before the other rules. I used a seperate script so it was easier to append to.

i was testing my server box too and created fast test/test. i found out when i tried to log in and couldn't do it EVEN AS ROOT. Good thing it was a fresh install and nothing on the HD. i'm going to do REINSTALL and use the ssh deny/allow files.

now i know why in the ftp log on my main PC was full of connection retries with different login/pass combinations. three different IPs from *bell south" users. a lesson for future

Don't forget in the sshd_config to set
PermitRootLogin to No