Score:0

Should server be hidden behind a VPN for the SSH access?

jp flag

We have three server instances, Nginx/PHP, PostgreSQL, and ELK stack. My idea is that the PHP server would allow public access for ports 22, 80, and 443, ELK server would have open port 5601 for public access, but all other intercommunication is only allowed through their private IP addresses.

Do I need to hide them all behind a VPN as well? What are the benefits of that? VPN would have no other purpose, it is not company-wide or something like that, it is only for securing those servers.

km flag
See https://security.stackexchange.com/questions/103055/does-a-vpn-provide-any-security-benefits-over-sshuttle-or-a-vanilla-ssh-tunnel
djboris avatar
jp flag
That question is about VPN vs SSH tunneling, I am asking about direct public SSH access. But it does make me more confident in the trustworthiness of the SSH.
Score:2
za flag

Depends on. Usually this is controversal.

BSD family has a blacklistd, which is perfect for filtering bruteforcers/scanners on an application layer. Linuxes are arrogant so they only have a peculiar python framework fail2ban, which, in my opinion, should've been rejected during alfatest, and not allowed to enter any production-level installation.

On the other hand, if you don't allow root to login via ssh (which is a usual security choice), then you have additional bruteforce barrier (once again, several Linux distribution insist that root should be able to log in via SSH).

Still controversal. Some engineers prefer to bind sshd to some other port than traditional tcp/22, some will allow ssh only via VPNs (see, this tells us something about fail2ban already). That's kind of a personal choice. I myself don't close the tcp/22 on my servers, but I use the password policies and don't allow root to log in via SSH. Some may say that I'm walking on the edge. I say - using ssh on a tcp/2202 is a self-torturing.

br flag
One method that I personally use is to create a bastion ssh server. I have SSH running on a non-standard port, use non-standard usernames with hostkeys and no passwords and I don't allow any command execution but only to forward traffic. This allows me to proxyjump to all other machines in my private subnets and also to the ones in public subnets with SSH ports firewalled off to the internet. And if I need to access my databases I can build an SSH tunnel to the db server and connect to it locally. Has worked well for me so far...
djboris avatar
jp flag
So, the conclusion would be, that if I harden the public SSH access I should be good even without the VPN.
Score:1
cn flag

Should server be hidden behind a VPN for the SSH access?

Maybe. Applications with modern security practices do not need to be behind a VPN for no reason. A trendy term for realizing that the network perimeter doesn't automatically make things secure is "zero trust".

Private IP addresses are not required for security. Consider the firewall rules necessary if all the hosts have public addresses (IPv6). Allow tcp/22 from anywhere for direct access with ssh. And allow 443/tcp from anywhere for the web server. But 5432/tcp only needs to be allowed from your hosts that need database access, not the internet in general. ssh and http has historically been more public facing, so expose the web apps and not the database server.

Of course maintain these hosts to keep them secure. Stay current on security updates. Use strong authentication, like ssh keys. Audit access, especially for privilaged users.

djboris avatar
jp flag
That is exactly what I thought. Using VPN as an excuse not take proper security care on the hosts behind it is a potential disaster. Hardened public SSH access should be secure enough.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.