To mitigate the effort to maintain my personal server, I am considering to only expose ssh port to the outside and use its socks proxy to reach other services. is Portknocking enough to reduce surface of attack to the minimum?
Highly susceptible to replay and man in the middle attacks.
fwknop
isn’t susceptible to either.In your SSH config, you should disallow root login and password authentication.
It is more secure than these tommyknockers :-) but you can do that additionally, if you feel like it.
Why disallow root login? I always need root when I connect, and stealing the password by aliasing sudo/doas is trivial. It seems to me it would just make life harder for no benefit.
Because then:
- you also need to know the correct username
- audits and logging shows which user used sudo to gain root access
- you also need to know the correct username
Use a secure password or key. Security by obscurity is no security.
- audits and logging shows which user used sudo to gain root access
That is not the point that was made. Once access to sudo or root you already have lost.
Defense in depth.
Anyone who’s certified NET+ or higher knows this.
I would only expose a VPN and use that to access the other services.
Why? There’s no downside to ssh, if anything it’s easier to set up.
Other then the slowly increasing log file (if you use fail2ban for example), it will take thousands of years to actually hack you through this method as long as root auth is disabled and authentication is only via SSH keys, I wouldn’t worry about it.
It is possible to tighten the security of a machine to the point it is no longer usable. It is important to secure our devices but we cannot forget about convenience, so the trick is to tighten it but also make it so you don’t have to jump through a number of hoops till you get to your destination.
I for example, wouldn’t use your method because it would make it difficult to use some services I host from my phone.
Port knockers for the most part aren’t worrying. In an ideal situation, the only ports that should be open are 22, 80, 443 and using a reverse proxy to mask headers. (Poor configuration for example, go to Shodan and type bitwarden in the search bar and see how many people expose their instances to the world carelessly without an SSL cert) and the occasional UDP for game servers/media servers.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters SSH Secure Shell for remote terminal access SSL Secure Sockets Layer, for transparent encryption UDP User Datagram Protocol, for real-time communications VPN Virtual Private Network
[Thread #128 for this sub, first seen 10th Sep 2023, 16:25] [FAQ] [Full list] [Contact] [Source code]
Have you met my friend Tailscale?
I used to SSH into my server and proxy out from there. Then I learned how shit of a solution that is for daily use and set up a vpn like a normal person.
Sounds like security through obscurity to me.
Highly susceptible to replay and man in the middle attacks.
If you’re gonna combine that with another authentication method (and you should), then I see little advantage over just going with the other auth method.
Sure? It certainly detracts bots that now don’t discover the SSH port anymore. Against a targeted attack it’s less useful, but that is a very hard problem in any case. If someone is out to get you specifically, it will be a tough battle.
Instead of ssh I use wireguard directly. It’s a simple protocol based on public/private keys with great performance and security.
Wireguard is stateless and establishes connections really quickly on demand. This means the battery isn’t impacted even though it’s always on, since the VPN doesn’t have to maintain a constant connection. At least that’s the case if your routing only a specific subnet (e.g. 192.168.1.0/24 and not all traffic through it 0.0.0.0/0).
I use a vps running openvps. Then i only allow ssh access from my vpn ip address.