0

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.

djboris
  • 101
  • 1
  • 1
    See https://security.stackexchange.com/questions/103055/does-a-vpn-provide-any-security-benefits-over-sshuttle-or-a-vanilla-ssh-tunnel – msanford Jan 10 '22 at 16:40
  • 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. – djboris Jan 12 '22 at 12:59

2 Answers2

2

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.

drookie
  • 8,051
  • 1
  • 17
  • 27
  • 1
    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... – MoWo Jan 12 '22 at 07:21
  • So, the conclusion would be, that if I harden the public SSH access I should be good even without the VPN. – djboris Jan 12 '22 at 12:52
1

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.

John Mahowald
  • 30,009
  • 1
  • 17
  • 32
  • 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. – djboris Jan 12 '22 at 12:56