You have not described what the "hack" was so all of this is educated guess.
If you don't have a specific knowledge, you should deploy a solution proposed by @0xDEADBEEF - a Teleport.
Ofc, never expose critical service or infrastructure to public. We don't know if you used that VPS for internal needs or were simply hosting a public facing website.
If you used Ubuntu as Linux O/S that means that you can filter traffic properly with default policy DROP - not REJECT (higher CPU usage and notification to adversary) - for all chains and allow only specific ports with both packet state and source and destination address filtering.
only ports for SFTP and HTTPS were opened.
firewall was activated and was restricting everything
it was a VPS(virtual machine on famous hosting provider's server)
it was managed through browser interfaces like many otherd VPS/droplets
SSH was done on a standard way, i made random keys with putty, uploaded private key through browser intreface...
bad thing i didn't have any logging except the standard one enabled, since i was very confident that issues can't occur
what i did not do, is changing default ssh port to some other, but still by not doing this, it could be a cause for server being down due to ddos, and not for someone to gain access to files
all scripts had input sanitized, and it was not able to deliver a hack that way
I am pretty much clueless when it comes to networks, but I think i covered most of the bases
If you don't have a specific knowledge, you should deploy a solution proposed by @0xDEADBEEF - a Teleport.
It sounds like your web application might have been vulnerable in multiple ways, not just to injection attacks [1]. Exposed HTTP(S) services often provide attackers with a foothold to infiltrate a server and escalate privileges to cause more damage. For the SSH part, I recommend setting up a jump server that is the only machine allowed to access your servers over port 22. You can then tunnel into this jump server and from there ‘jump’ to the rest of your infrastructure. Ensure that access to your jump server is tightly controlled with strict access policies. This approach significantly mitigates the risk of unauthorized access, brute forcing or password spraying.
A solution you can use is Teleport: Easiest, Most Secure Infrastructure Access (GitHub - gravitational/teleport: The easiest, and most secure way to access and protect all of your infrastructure.), which your IaaS provider can likely auto-deploy for you.
Also a WAF like Cloudflare is the easiest to setup and will block threats on the application side. I don't want to go off topic too much, so if you want to go more in-depth about this, feel free to send me a message.
[1] OWASP Top Ten | OWASP Foundation
Ofc, never expose critical service or infrastructure to public. We don't know if you used that VPS for internal needs or were simply hosting a public facing website.
If you used Ubuntu as Linux O/S that means that you can filter traffic properly with default policy DROP - not REJECT (higher CPU usage and notification to adversary) - for all chains and allow only specific ports with both packet state and source and destination address filtering.