tips on how to batten down the hatches? have strange ip logins

[oneofusjustin]

so i found some disturbing IP logins to my VPS from Romania and china. is there anyway to tell what they did?

also can you give me tips on how to prevent this kind of stuff? im gonna change my SSH port and restrict Root login. but if im the only one who should ever login is there a way to prevent logins from anywhere but my home?

 

[xSauronx]

ACLs can restrict/allow connections/traffic from certain protocols via ip or ip ranges

depending on the OS you run and what auditing you have enabled/log files you may be able to find out what changes were made (if any)

 

[oneofusjustin]

im running Cent OS5 the basic set-up haven't messed with much

 

[Gooberlx2]

I assume there were some failed login attempts, right? Use something like fail2ban to block their ips after X number failed attempts.

 

[oneofusjustin]

no they were in for awhile im gonna reformat the server and add some security measures, i just wonder what they were up to, basically my VPS is stock cent OS with a squid proxy running on it nothing special

 

[mcveigh]

Others here are more knowledgeable than me but first I would try to identify the possible IP addresses or ranges of them I would be using to login and allow only those.

 

[Fallen Kell]

If they had successful logins, you are best re-formating as with the out of the box settings, you will never know what they did. First thing to do would be to turn on auditd and setup some basic rules to log different activity. For the really paranoid, you need to essentially log everything, but that will create huge log files which you still would need to read through. At a minimum, put some watches on /etc/passwd, /etc/shadow, /usr/bin/passwd, /usr/sbin/useradd, /usr/sbin/groupadd, /usr/sbin/userdel, /usr/sbin/groupdel, and you will at least be able to tell if/when someone changed their account password, or added a new account.

You really need to take a baseline of the system using something like fcheck. This way you will know if/when someone replaces a file/executable on you with a hacked version (like replacing the iptables executable with one that opens up a network port and doesn't display that rule to you when you look at active firewall rules).

Next step would be to basically shut everything off that you don't use/need. Turn off all the xinetd applications and anything else that you don't think you are using (use "chkconfig --list" to show you what is on, and "chkconfig <name of service here> off" to turn it off upon next reboot, you can use "service <name of service> stop" to shut it off right now).

Then I would say create the file "/etc/hosts.allow" and "/etc/hosts.deny", and put "ALL: ALL" in "/etc/hosts.deny" to start. That will prevent any remote host from pretty much accessing anything. If you want to trust a specific machine, like say your laptop, put "ALL: IP_ADDRESS" in the hosts.allow file. You can also use a subnet, so you could put in "ALL: 192.168.1.0/24" and that would allow anything from the 192.168.1 subnet to access your system (handy if you are using DHCP without static IP addresses for your home network).

 

[LCTSI]

Since you're running Cent 5 you can use the RHEL 5 guide from CIS
http://benchmarks.cisecurity.org/en-us/?route=downloads.show.single.rhel5.200

If you have dynamic dns set up home (and assuming your hostname is oneofusjustin.dyndns.org) , you can set up a template /etc/hosts.allow in /etc/hosts.allow.template:

cat /etc/hosts.allow.template
sshd: localhost 

cat /etc/hosts.deny
sshd: ALL

now set up a cron job to put your IP in the file, by looking up your dynamic IP.

sudo crontab -e
*/15 * * * * cat /etc/hosts.allow.template > /etc/hosts.allow; echo "sshd: `dig +short oneofusjustin.dyndns.org`">>/etc/hosts.allow

ta-da. You'll only be able to connect to SSH from the IP that oneofusjustin.dyndns.org resolves to.

You probably don't need squid... tell us more about what you're doing with it.

 

[jade_angel]

Something else you might try, for wiring down SSH, is to set up public key authentication.

Once you have this working, you can then disable password authentication altogether. This way, even if an attacker knows your password, they still can't get in. Just make sure to protect the private key, since anyone who has it can log in as you. There's an option to protect it with a passphrase: do so.

Also, it goes without saying, do not use the same password you used before. It's not clear if they guessed it, cracked a captured offline version of /etc/shadow, used an exploit to bust in without it, etc - but don't take the chance. I've found, for that, that using a password manager like KeePassX is quite helpful - this makes passwords consisting of 120-character streams of garbage actually usable.

 

[LCTSI]

I've found, for that, that using a password manager like KeePassX is quite helpful - this makes passwords consisting of 120-character streams of garbage actually usable.

I derive a strange sense of satisfaction from doing this.

 

[smirk]

Something else you might try, for wiring down SSH, is to set up public key authentication.

This. And also check out Denyhosts. I get hack attempts all the time; they get 2, maybe 3 hack attempts and then Denyhosts bans their IP.

 

[Red Squirrel]

Move ssh port to non default. If you really want to be safe(r) put it on a port higher than 1024. People/bots using port scanners will probably not scan all 65535 (though some may do it). This is more a security through obscurity tactic, but it still helps provided the rest is secure too. Also keeps your logs from growing GB's per day as most of the brute force bots just try the default.

Also, install fail2ban. It will block IPs that try to login and fail nn times (you can set it) and also works for other protocols, not just ssh. Without any kind of brute force protection any password based system is completely useless. It's not a matter of if they can get in, it's a matter of when. Does not matter if you change the password often, you will either change to one that was already tried, or what that was not.

So yeah brute force protection + non default port will help quite a bit. Definitely disable root logon too.

Fun experiment, setup a linux VM, open up ssh, use a strong enough root password, but otherwise don't do anything further. Make sure your console colors are green text over black. Do tail -f /var/log/secure. Free matrix screen saver!

 

[Fallen Kell]

I will have to look at fail2ban. I wrote something that essentially did that myself. It read through the various login logs and firewall logs, gleaning hostname/ip address information for the attempts to access ports and services. It would then keep track of the number of failed attempts from that ip address, the subnet as a whole, and the ISP used (it did a whois lookup to find the ISP and the blocks of ip addresses assigned to the ISP). And it would then update my firewall rules to silently deny the packets from those three categories after threshold values were hit.

 

[Red Squirrel]

I think that's what fail2ban does actually, it just polls the logs once in a while. You can also write custom rules for custom apps, never tried it myself though.