New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
How to secure my vps
Hi, I'm noob in vps world (or even linux host although I'm a casual linux user).
One thing that made me worry is that when I examine the /var/log/auth.log, there are tens of thousands of "Failed password" entries in 3 days (the vps started 3 days ago).
Just run a grep "Failed password" | wc -l gives 23840. From the ip lookup, most of them are come from a single country.
This remind me to secure my system
Here're my first steps
- Use a very long root password (of course use digit, Upper/lower letters, symbols)
- Change the ssh port
- Disable root login in ssh
- Disable password login in ssh (I don't want to do because I need to access the system from many locations)
Any other recommendations? Can I block the connections base on country (my host is openvz based)?
Thomas.
Comments
Well, changing the SSH port will probably stop 99% of the bots.
I have never tried this myself, but maybe setup 2FA for SSH?
https://www.vultr.com/docs/how-to-setup-two-factor-authentication-for-ssh-on-ubuntu-14-04-using-google-authenticator
Use ssh keys.
If you don't like the noisy logs, change ssh ports (keep the alternative port number below 1024 so only root can bind to it). Changing ports is not really security but it will reduce log entries from automated attacks.Ugg, need sleep.. only read half your post. Anyway, yeah. You got it.
Keep up with security updates and if you have the option limit ssh to specific source IPs.
A good idea. I'll have a try (in a testing host first because any fault will make my vps host inaccessible).
As heretical as it may seem to some, there's really nothing wrong with keeping your (passphrase-protected) private key on Dropbox. Only you can unlock it, and that way it's always with you. If that makes you nervous, gpg encrypt it before you put it on Dropbox.
But I change to a port > 1024 coz' I think/guess those bots will not try/scan a high port say > 10000. Am I wrong?
Yes - look at the CSF firewall.
Other recs:
If you run a multiuser environment there's the potential that someone could get the ssh service to crash and run their own service on the port. The lower port numbers are privileged and can only be bound by a privileged user (root).
But to answer your question: the entire concept of changing port numbers does nothing in a targeted attack; moving a service to a port above 10000 does nothing to mitigate that. Moving it to a different port (still below 1024) keeps your logs cleaner and stops the majority of automated attacks, which typically do not port scan hundreds/thousands of ports (while at the same time preventing unprivileged users from using the same port).
Forcing SSH to use only keys (disabling passwords) is the single, best thing you can do for the SSH service.
Isn't that what host key verification is for?
@nulldev,
Security is done in layers. The OP said they were using passwords. Sometimes people ignore host key warnings. Etc. Etc.
this article helped me very much, hope it will also help you. https://www.digitalocean.com/community/tutorials/an-introduction-to-securing-your-linux-vps
You can use AllowUsers option in sshd_config.
Add some user with strong password, add it to allowed users, then combined with fail2ban you are good to go.
If you use a port < 1024, a local compromised/malicious user cannot replace the SSH daemon without another method of privilege escalation. With a port > 1024, it's a possibility and then you're relying on the user noticing.
@thomaz are you the only user?
I was never a fan of Fail2Ban because of the idea of keeping your VM running lean. Switch to random SSH port and be done.
@doughmanes : denyhosts provides the same functions, only they get banned forever (I think)
It's all about the number of bits, not the format. If it's a password you have to remember, you're a lot better off simply using a longer phrase rather than trying to get F4~cY.
The question is what you're trying to "secure". Changing a service port (or even using port knocking) will certainly clear up your logs, but it doesn't do anything about the security of the underlying service. Nor does it help you identify the attackers that are out there.
I say the better approach is to let the bad guys expose themselves by coming in on the expected port, use fail2ban to stop the fast movers, and manually firewall networks that are the source of persistent attacks. This is also an approach that works for services where you can't easily change the port, like http/https (have a look at those logs, too, if you want to see another large vector of abuse, often targeting WordPress/PHP).
Look at the logs to see what the actual attack vectors are. The overwhelming majority are going to be for standard accounts like "root", "admin", and "ubnt". Whether or not you disable passwords for normal user accounts isn't going to make a big difference to your actual exposure.
Your firewall is your friend. While you can cut off entire countries, I suggest simply cutting off the networks that attack you.
Brute force on a random port, to me, seems more like a focused/advanced attack versus typical SSH scanning noise on the Internet
My point is that no abuse should just be considered "noise". The way you mitigate the targeted attack on a random port is by cutting off the resources that are already in play doing the routine scans. I get that some people want to make their lives easier by not policing the small stuff, but the network that allows today's little scan helps power tomorrow's massive DDoS.
Enjoy shaking your fist and yelling at noise on the Internet.
Some providers in the past would do random SSH ports or force you to turn SSH on through their console (RamHost was like this, not to be confused with RamNode)
SSH scans are done because they work. The problem is the user with a poor password. Providers who have been proactive in the past are often met with hostility from users who practice poor security habits.
Well standards,
1) OpenSSH - Public Key auth only, Deny RootLogin, Change SSH Port
2) Separate privileges for each site/service if is possbile (or containers).
3) Disallow unused functions which can result in command execution (like system() of php)
4) Always keep system updated
5) Always keep 'CMS' and similar apps/addons/plugins updated.
6) Firewall
Can be always 0days vulns and that are hard to prevent, but in my opinion this basic configuration will save you from mass-attacks and basic-attacks..
Oh it's the ssh port debate again.
@raindog308, is better to have a stable IP (like a private secure vpn) and to allow all cirtical services just to this.. but if you have dynamic home/work ip and not like using VPN's or similar things can be a issue to have SSH/similar services on default port. (port knocking can be a good solution)
1) Because of noise generated by mass attacks 2) Mass mapping of ssh ip/banner in case of future 0day
using iptables: white list a few ips for ssh, then block all other ssh
and as everyone else said: disable root login
Personally, I have a pair of OpenBSD VMs which allow SSH from anywhere. They're not running much more than sshd, cron, syslog, and outbound mail. You can only get onto those boxes with a (passphrase-protected) ssh key. I've been thinking of making them only open after port knocking or using 2FA but haven't yet.
Everything else only allows SSH from those two VMs, though of course there's also the console which I can't control.
One of the scripts I've put in place is a HTTPS only SSH gateway.
Essentially you visit a HTTPS page (not public of course) that is password protected which then opens up the SSH for that remote IP just enough to connect. Password based port knocking. I still use a key based ssh login but this doesn't expose the SSH port except for a brief period to the specific IP (and this is very useful for the travelling salesman problem which of course is Non Permissively complete).
What? I'm doing exactly the opposite. It's because I don't have time for all that drama that I just drop abusers into my firewall and get on with my life.
Providers would do well to get those sorts of users off their network.
Thanks for your perfect world input, quite possibly reflective of your username, from the never-worked-for-a-provider perspective.
Thanks all of you to give me many invaluable inputs. I need to test every suggestions.
At present, after changing the ssh port, the bots connections dropped (demsg |grep "DPT=22" gives less than 50 within a day and the real ssh server port don't have any traffic besides me).
Hope there is a good port of monowall/opnsense/pfsense toLinux.
Currently, yes. Ultimately, less than 5 real users.
But there are many "networks" even from a single country. In fact more than 98% of my system attackers are come from one country. So cutting a single country will cut >98% attacks.