VDS Passwords

[tomp]

In the past few weeks we have seen an increase on the amount of brute force login attempts across our network. A few of these have resulted in our customers VDS's being compromised because of easily guessed passwords being used by our customers or our customers, customers.

Some really basic things you can do to protect your server include:

1. Limiting the amount of users with SSH access.

2. Utilizing tcpwrappers - http://www.clug.org/presentations/security/tcpwrappers.html

3. Monitor your log files on a regular basis - /var/log/secure ; /var/log/messages

4. Ensuring you use strong passwords - http://www.microsoft.com/athome/security/privacy/password.mspx
http://www.smat.us/sanity/pwdilemma.html

5. Asking us if you have any questions about anything suspicious you see.

Please take some time and read through our VDS security How To located at http://www.myriadnetwork.com/forum/showthread.php?t=8

If you have ideas or questions on how to implement some of the suggested security features please ask.

Tom

[nick]

Tomp,

Maybe a good idea would be to provide a secure online password generator somewhere on the myriad website such as: http://www.techzoom.net/security-password.asp

I swear by that resource to create 100% of the password i use.

Regards,
Nick

[tomp]

Hi Nick - that is an excellent resource. Thanks for your contribution!


-Tom

[sliqua]

http://www.rfxnetworks.com/ is an excellent resource for utilizing safe security guidelines in the every day usage for your VDS. They have tools such as APF, which allow easy maintence of iptables. And BFD, which automatically detects and blocks users attempting to bruteforce services on your server..

Word of warning, make sure you have properly configured these services before you put them into use! You could potentially lock yourself out of your server making an attempt at it.. there are a few good tutorials out there for how to setup these services and i'll be glad to assist anyone with questions through this thread! :)

[Jeff]

In conjunction with the other great ideas mentioned above, something else you can do is to change the port that sshd listens on. This will prevent your host from showing up in an attacker's logs as having sshd running when they scan for it. The benefit is twofold - first, the amount of brute force attempts will be greatly diminished, and second, it could save headaches from future sshd attacks.

To change the default port, you will need to edit /etc/ssh/sshd_config as root. If you do not have an sshd_config in /etc/ssh, you can locate it by running: find / -name sshd_config

Look for the line that starts with the word 'Port'. It should be very close to the top of the configuration file. Changing the port is simple - just replace '22' with something else. What's a good port to use? Generally speaking, a port that is not already in use by another service (typically these are the ports below 1024). To see if a port is already in use on your host, run 'netstat -ant | grep LISTEN'.

After changing the default port in the sshd_config and saving the config, you will need to restart sshd. This can be done via the command 'service sshd restart' if sshd is being run on your host via init.d/.

It is also worth noting that although ssh is an encrypted protocol, sshd protocol 1 is easily attacked and can give up logins and passwords to an attacker. For optimized security with sshd you should use Protocol 2 only. You will see the 'Protocol' line just below or around the 'Port' line.

In summary, 2 things you can do in for added layers of protection for sshd in conjunction with the examples already posted above are:

#1. Change the default port from 22. Use a port under 1024, and make sure the port is not already being used by a service on your system.

#2. Only use Protocol 2. Protocol 1 is very weak and is not to be considered secure.

Again, don't forget to restart sshd after making changes to the config file.

Jeff

[Jeff]

I have modified my post above, specifically to change this:


Change the default port from 22. Use a port over 1024, and make sure the port is not already being used by a service on your system. If in doubt, pick a random number between 20000 and 65535, such as 63671, or 47173, etc.

to this:


Change the default port from 22. Use a port under 1024, and make sure the port is not already being used by a service on your system.

An oversight on my part at the time of the posting. The issue is that in the event of a vulnerability in the openssh daemon that allows a malicious person to crash the service, anyone with local access could start their own sshd on the port it was previously running on (since unprivileged users can bind services to ports over 1024), and collect user login/password credentials. Yet another reason why you should never login as root, but as an unprivileged user, then su to root.