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.
Secure my VPS
Hi. I do have a VPS that i would like to secure it. All i need is a script that has the rules:
-to block all connections to any port apart from port 1194 udp
-block ICMP
-Block specific IP ranges, xxx/8
-block specific IP, yyy/32
-more than 3 attempts to ssh in a minute, then blacklist for 24 hours.
the system is a Debian 8.
Comments
I am not sure about any script that can do all tasks but you can do the following for a start:
Here are some articles on securing your server:
https://www.digitalocean.com/community/tutorials/an-introduction-to-securing-your-linux-vps
https://www.digitalocean.com/community/questions/best-practices-for-hardening-new-sever-in-2017
Change ssh port 22 to a random number like 26789
And enable firewall like iptables or firewalld
Most importantly, use ssh key and disable password authentication.
I am really amazed by how many people still mention changing ssh port as their an advise on how the harden the security. This is called security through obscurity and it means that hiding shit is not the same as actually securing it. A simple port scan will reveal the real ssh port. Changing the ssh port is not a best practice for actually securing your server.
That script called firewall. By default you have iptables in Debian, also ipset available via apt.
And I'm amazed how many people still believe in and repeat the "obscurity is not security" nonsense mantra.
a) there's a gazillion scripts out there stubbornly and stupidly working against port 22
b) security is obscurity. What else but professionally created obscurity is for instance encryption? Why do we use PKE to establish secret keys? Because we want professionally created obscurity.
What the "obscurity is not security" nonsense mantra drones are meaning but not understanding is that poor quality obscurity ~ poor security.
You don't believe me? Then think a moment about what e.g. 128-bit (NP, or even better NE) security means.
Changing SSH Port, does not really improve your security, it just keeps the bots away.
If someone really wants to find a weak point, there is a thing called portscanner.
If you want to fuck people off, get a /48, get one IPv6 random somewhere in the Subnet, and put SSH there, to fuck them off big time.
Anyway, just use a firewall, that solves all of these issues.
Which I'd wager is 99.999% of all attacks & the reason behind most server breaches.
Bullshit, if you use weak passwords sure.
Why do you use passwords anyway? SSH KEYS!
An SEO expert would tell you to install Wordfence
UFW or CSF can do that
And probably this, but not out of the box afaik
Wrong. Even with keys the real trouble (besides the nuisance of crapped logs) is that SSH - like anything using ssl/tls - contains a DOS vulnerability. The negotiation doesn't come for free; even powerful servers capable to handle tens of thousands of connections can only do a couple of hundred session negotiations per second. That is the real value of keeping gazillions of bot scripts away by simply changing the port.
Kindly note that the password vs keys question comes only up after a session is established. keys vs. passwords is in the authorization phase, once a tls connection is established.
Thats why you do use a firewall as I said, it makes no sense to move the Port, if someone wants your SSH to go down, they use a Portscanner?
Good luck when you have dynamic IPs or need to ssh-access your server from a friends IP.
As for portscanners: You may repeat that as often as you like but it doesn't change the fact that gazillions of bots and scriptkiddie-scripts stupidly go for port 22. "Intelligent" ones also check ports 2022 and 2222...
It's btw not just and always sheer idiocy that's the reason for that. There are diverse other reasons, too. Like e.g. effort vs cost ratio or not triggering (possibly even isp) firewalls, to name two examples.
If any human ever cared probably yes but in reality humans are really scarce when it comes to SSH attacks. Changing the port is likely to drop bruteforce attempts by 100% since it's all bots and i've never seen any doing anything even slightly more intelligent than hammer port 22.
Why don't you just admit that not having your logs filled with garbage makes you feel lonely?
Holy shit @Neoon all that strong points you have there.
Your knowledge about information technology seems to be very limited, not worth to continue discussion, just a waste of time for me.
I do waste a lot of time all day, but I do not need to waste it on this discussion.
Oh, please excuse me for disagreeing with your unfounded opinion and laughing at your weak tries of evasion. So enlighten me how moving SSH has a single drawback or how it doesn't cut down bruteforce by pretty much 100%? Fact: You can't. All you can come up with is a hypothetical scenarario that in the real world is nothing but a rare exception and still does not carry any drawback. Avoiding threats is simple pragmatism. Nothing more nothing less. Noone claims it to be a solution - there's other things for that. Guess that's above your head or you simply like mindlessly repeating your schoolbook guidelines, who knows?
So kindly take your superiour knowledge and stick it up an opening of your choice my cocky little web developer friend.
https://github.com/Xeoncross/lowendscript
Download the script, edit the rules which are inside the script in iptables section and run ./setup-debian.sh iptables [port]
Note the script is for Debian 6/7 but iptables are same and will work on Debian 8.
In before "Have a baby for me".
Ah yes, the annual flogging of the 'ssh security' horse @joepie91
Just use SSH key-auth and disable password auth as STEP1
If you have another minute, install fail2ban and setup the jail for ssh bruteforce attempts.
If you have another hour, learn iptables and ipsets.
It's worth learning how to do this rather than 'a script'
In security sky is the limit. And there is cost (time) of doing things. In some cases the cost of doing one thing is very less compared to the benefit it provides while in other cases the cost may be higher. Changing SSH port provides huge benefit as it keeps 99% noobs away which is not bad considering how much time does it take to change the port.
This has been discussed here endlessly.
@bsdguy summarized the mainstream view. It doesn't hurt anything, it helps filter noise and stupid scripts, but it's not a magic bullet because nothing is.
OTOH, some people prefer the convenience of port 22 and don't mind the frequent attacks, and that's a reasonable point, too.
The key (no pun intended...) is to understand both points of view before you make your choice...
If they hit your IP and find port 22, you're on their list. If they don't, they move on. Sure, a sophisticated attacker who wants to get into your specific box will scan the whole range of ports, but that's not 99.99% of attack scenarios. Most skiddies run a scan for port 22 and then start hammering if they find it. It's stupid logic but that's how most work.
Yep. I see attacks on port 22 daily...I can't remember the last time I was port scanned from an unknown IP.
And btw, in my experience, the port 22 knocking is immediately followed by a broad array of attacks on port 25/587, 80/443, etc. Without port 22 lit up, none of that happens.
Again, it's a choice and while I'm firmly in the "change the port" camp, I respect people who defend the "don't change port 22" point of view. But only when they know what they're talking about...
Yes! An excellent demonstrative case for your point: @Francisco at BuyVM changed BuyShared to use a non-standard port. Before he did that, I would see 3-5 failures trying to connect to ssh on his servers just because there was so much banging from skiddies that the daemon couldn't complete the connection. Sometimes it was impossible to connect via ssh.
All of that immediately went away when he changed ports.
OK your highness...enlighten us based on the commentary above.
If it helps, I asked this same question 6 years ago...
https://www.lowendtalk.com/discussion/2253/building-the-ultimately-secure-vps-add-to-this-list
I can't decide between the two camps so I do the next best thing
..and leave password authentication on?
Yeah so I can log in with both passwords and keys. Best of both worlds.
Security by convenience.
FYI,
2222
is seen as a 'common uncommon' so you can expect to see bots nailing it. It isn't as bad as when we had it on22
, but i'm likely still going to put CSF back in place because of it.Francisco