Securing VPS

hello lainchaners since im not really intonsecurity i wanted to ask about how can i secure my VPS. My actual setup: ports opened for external connections are http ssh(standard port i should chanve i know), and openvpn. rest of my services are opened only to vpn (openvpn). root password is long hash. i have ufw as firewall and other ports than ones i mentioned are closed. i also have fail2ban. is there anything else i could do at this point? (pic unrelated)

>>5155 Disable root login entirely and use sudo. Sudo gives you an audit trail in the logs. Good to hear you have fail2ban with ssh on a default port. I personally use port knocking to open my ssh port but that's more autistic than I would expect anyone else to implement. Read this: https://www.codelitt.com/blog/my-first-10-minutes-on-a-server-primer-for-securing-ubuntu/ and the attached pdf

>>5156 thanks! is it good thing that i have ssh over standard port or that i have fail2ban or are you sarcastic?

>>5156 after reading this its almost same as what i have. im just afraid of disablimg ssh outside of vpn because in case vpnnfails im fuarrrkd

>>5158 I was saying that because you are running ssh over the standard port, it is a good thing that you have fail2ban

>>5160 I didnt know how many logins i have untill i installed one. 50 (today) and its just half of the day xD logwatch is dope

I've seen a cryptographic way of doing port knocking. Basically, you send a bunch of encrypted data to port and then the listening daemon opens up ssh port. This way it would be impossible to eavesdropping or mitm attacker to replicate your port knocks and it also protects from possible vulnerabilities in ssh software based on denial of service. Here is a link: https://moxie.org/software/knockknock/

>>5163 Oh my thats also dope

>>5163 You could also use this masterpiece: https://github.com/benjojo/totp-ssh-fluxer/ or my crappy ripoff for multiple hosts: https://github.com/nilesr/ostp

>>5165 its only joke tho

>>5155 >is there anything else i could do at this point? yes, there always is. what you need to decide what level of protection you need, how much time you're willing to spend on it, and to what extent you're willing to consistently uphold these security measures in daily use. when I discuss this with people, they seem to think security is binary (the server is either insecure or secure) or somewhere on a one-dimensional "sliding security scale" from 1 to 10 (and they obviously want 10). when people ask "how to secure my server?" I find that they are often looking for answers like the ones found ITT, even though they need to establish other things first. what do you mean, OP? what do you want to protect yourself against? what is it what you would like to avoid? how much time and money are you willing to spend on establishing & upholding a certain security level? to what extent will you actually use cumbersome security measures in the long run?

>>5170 Well okay i get you. To put it simply i have vps and i just don't want to someone to hack into. I can only spend time not money :p

>>5175 right. well: virtual private servers are inherently insecure to a certain extent, in two main regards: - the server host has physical access to the machine, and this means that they can pretty much read and manipulate anything on your system. one of few exceptions would be encrypted data-in-transit being bridged through the server without any local decryption mechanisms. this is if course also true for actual physical server hosting - but it is more cumbersome for an attacker to do anything if you establish your own security measures on a physical & bios level (which you can't do on a vm). - utterly malicious users can easily register an account and exist on the same physical machine as you, but on a different virtual machine. this means they can readily exploit any inevitable low-level memory leak/privilege escalation 0days as soon as they're detected. no one wants to get hacked. you can make it hard for most attackers by simply blocking incoming by default, changing default ports, restrict running services and the way they listen to ports, disabling password-based login & using keyfile-based logins for ssh, port knocking, and enabling automatic updates. if you need fail2ban then you don't need fail2ban, because your system is configured incorrectly anyway. you should operate on whitelists and not even offer the possibility of brute-forcing.

>>5165 >totp-ssh-fluxer fuarrrk that was my idea. I guess someone's already done it.

>>5155 Ignore 90% of the security LARPers in this thread, OP. Firstly, SSH shouldn't be a worry. Just make sure all your users have strong passwords (and I mean STRONG: generate them with something like cat /dev/urandom| tr -dc 'a-zA-Z0-9' | fold -w 25| head -n 1). What you think of as a strong password probably isn't very strong, at all. Either that, or enable only key-based auth. Job done, nobody is getting in. Don't waste fuarrrking time with fail2ban, changing the default port, port-knocking, or anything else. It won't make the slightest difference: you'll be continuously bruteforced from every corner of the internet anyway and that's functionally irrelevant unless you're a retard, unless you use IP whitelisting, and then you'll have a problem if you're in a hotel or something and need to access it from somewhere unwhitelisted. Secondly, you've got a HTTPd running. What's on that? It's by far more likely to be what results in you getting owned: if you've got wordpress or whatever on it, get rid of it. Similarly, if you've put together some PHP on your own or something, shut it down. The attack surface of your average website is orders of magnitude higher than the attack surface of your servers' other services. You could take some steps to harden the box locally, but that's several books worth of learning to impart on you, so I'll just say for now, don't use sudo without a password, and keep your kernel, dbus-daemon, and glibc up-to-date.

>>5180 >have strong passwords >cat /dev/urandom| tr -dc 'a-zA-Z0-9' | fold -w 25| head -n 1 >no punctuation, alphanumeric password Please note OP, this poster's disclaimer "something like..." It is an important point.

>>5155 I would add to >>5156 for sshd I looked at drduh configs on github for ssh use keys for every user

>>5180 >>5184 I generate loong passwords using keepassxc and i keep them there so bruteforcing with fail2ban would take lets say… long

>>5185 after looking at >>5156 i just have one user that i log in using key (and to add key on different device i need to use password but its generated hash :P)

>>5180 >starts out by insulting posters >then suggests: >strong passwords (babby's first security advice) >key-based auth (already recommended multiple times ITT) >enable only key-based auth >Don't waste time on fail2ban (already been said) >shut down HTTPd, Wordpress, PHP: reduce attack vector (already been mentioned multiple times) >keep system up-to-date (already been mentioned multiple times) since you agree with us other posters I take it you're a LARPer too, lainon >you'll be continuously bruteforced >don't waste time changing the default port >don't waste time using port-knocking following a superficial port scan various bots will remember servers with open default ports as 'servers of interest' and carry out: a) more thorough port scans (possibly the entire range) b) rudimentary SSH brute-forcing attempts (regardless of server feedback) c) other relevant and possibly useful exploits on various services the scan/brute-forcing attempts in themselves are, as you say, "functionally irrelevant" in the sense that it shouldn't impact the security of your server. but there is no need to encourage any kind of malevolent behavior taxing the server to any extent, so it's better to simply seem extremely uninteresting and silently drop all requests. based of analyzed logs, having some level of 'port openness' usually leads to more requests and scans from related bots. also: assume there's a new 0day in your sshd. if it is listening on the default port, it is wide open to being exploited. you should obviously not allow for this.