Quack remedies for the server

[Hallvor]

Do a search online, and you'll find plenty of advice on how to secure a GNU/Linux server. They also list pretty much the same advice:

Don't use ssh with passwords
Fiction:

A much safer method is to use Public Key Authentication.

https://medium.com/@rockprofile/so-how- ... eacd7def25

Fact:

9.4.4 Public Key Authentication The use of public key authentication assumes that the client host has not been compromised. It also assumes that the private key of the server host has not been compromised. This risk can be mitigated by the use of passphrases on private keys; however, this is not an enforceable policy. The use of smartcards, or other technology to make passphrases an enforceable policy is suggested. The server could require both password and public key authentication; however, this requires the client to expose its password to the server (see the section on Password Authentication below.)

So if the client has been compromised, the server is also compromised. If the user copies the keys around for convenience, and one of them get compromised, the server gets compromised as well.

9.4.5. Password Authentication The password mechanism, as specified in the authentication protocol, assumes that the server has not been compromised. If the server has been compromised, using password authentication will reveal a valid username/password combination to the attacker, which may lead to further compromises. This vulnerability can be mitigated by using an alternative form of authentication. For example, public key authentication makes no assumptions about security on the server.

On the other hand, passwords will get revealed if the server is already hacked.

The point is that public key authentication is a feature of convenience (with its own drawbacks) and not one of security per se.

Source: https://www.rfc-editor.org/rfc/pdfrfc/rfc4251.txt.pdf


Use a firewall
Fiction: You need a firewall to stop the hackers

Fact: Firewalls work if applied correctly, like limiting outgoing traffic or preventing access to certain services.

However, it does not increase security if you allow all outgoing traffic and expose all services to the internet. Then the hacker can reach all the services. That is like running without a firewall, because all the holes are open. You have achieved nothing.


Install sudo
Fiction: ... because it's dangerous to run as root.

Fact: Issuing commands as root is probably the most common task on a server, because you do maintenance, perform upgrades or set up services. All these tasks require root privileges.

Adding an unprivileged user and elevate him to issue commands with sudo makes little sense, because you have merely replaced root with a normal user who (with sudo) can do anything root can do.

Change the default ports
Fiction: ... or you'll get hacked.

Fact: This doesn't actually increase security, because whatever login attempts you get from SSH are probably automated attacks probing for weak passwords before they move on. As long as you have a strong password, you are safe. You can also, of course, disable WAN login attempts to SSH altogether and only allow logins from your own LAN. They are almost always probing the root user, so disabling direct root logins will help if this concerns you.

Changing ports, however, will decrease noise and unwanted traffic, but it does nothing to help security in itself. If someone is targeting you, of course they'll find where your services are located.

Are there any other quack remedies?

[CwF]

Install sudo
Fiction: ... because it's dangerous to run as root.

Fact: Issuing commands as root is probably the most common task on a server, because you do maintenance, perform upgrades or set up services. All these tasks require root privileges.

Adding an unprivileged user and elevate him to issue commands with sudo makes little sense, because you have merely replaced root with a normal user who (with sudo) can do anything root can do.

...worth repeating.
Give root a good password. Use it to set up polkit as needed. Done.

[reinob]

The point of using public key authentication vs password for ssh is that brute-force attacks become (nearly) impossible.

Obviously, if one takes control of the client, and the client's public key is in the server's authorized_keys, then they can get in the server.

So if you want to add security to the "convenience" of public key auth, then you need to protect your private key with a password. This way you have both the convenience and the security.
(It gets problematic if you need a key for automated/cron tasks)

[Hallvor]

I am not saying that public key authentication is a bad idea. It's not.

My point is that using PKA (without password protection of the private keyfile) often is presented as a solution to much improve security, when it also adds another vector of attack. Have you then really added much to the overall security of your server?

Adding a password to the keyfile is a good idea. I have disabled direct root logins and locked down the SSH server to only allow connections from certain computers from the LAN. Both of these methods do irrefutably add to the overall security.

[reinob]

If you add public key authentication (let's assume, even without a password) *and* disable password authentication, then of course you've traded one thing for another.

The question is then: what is more likely to happen, that your client gets compromised (public key), or that the server is succesfully brute-forced (password).

In a local (LAN) environment, it maybe more likely that a client gets compromised, and therefrom the server, so you may be safer with password authentication on the server.

If the server is generally accessible from the Internet, then I think the risk of being brute-forced is higher, especially if you have non-root users whose passwords (and specifically, the password strength) you cannot control, so that indeed "adding" --- replacing password authentication with --- public key authentication can well "much improve security."

But yeah, blanket statements are never good.
.. Oops :)

[steve_v]

If the server is generally accessible from the Internet, then I think the risk of being brute-forced is higher, especially if you have non-root users whose passwords (and specifically, the password strength) you cannot control, so that indeed "adding" --- replacing password authentication with --- public key authentication can well "much improve security."

Perhaps, but IMO the obvious answer to users using stupid passwords is to enforce non-stupid passwords. You can control password length and complexity through PAM, among other things.

Add rate-limiting and a nice lengthy lockout on too many failed attempts (on my systems, if you can't type your password correctly in 3 goes, you gtfo for 2 hours), either with PAM again, or better yet with firewall automation like fail2ban, and brute-forcing SSH logins becomes pretty much a non-issue. Most bots give up and move on fairly quickly when the target stops responding.

If there's a way to enforce non-stupid passphrases on pubkeys, I'd be all for it... But AFAIK there isn't, so unless you can secure the client you're just trading a brute-force target you can control for one you can't.

[kopper]

If there's a way to enforce non-stupid passphrases on pubkeys, I'd be all for it... But AFAIK there isn't, so unless you can secure the client you're just trading a brute-force target you can control for one you can't.

Maybe someone would be kind enough to implement pam_cracklib support for ssh-keygen?

I know that policies or awareness training are not that popular topics at this forum but they can guide the users to pick better habits. If technical enforcement is absolutely required, then one solution would be to generate the keys for the users or force the users to use e.g. generator script that requires password to be compliant with the policy, instead of allowing the to create the keys themselves with ssh-keygen.

I'm not saying these are solutions without flaws. Someone will probably try to break the process anyway. Yet, security is more than technical implementation of controls.

I agree with the general point that moving authentication method from password (enforced or not) to password-less PKA just moves the attack vector from server to client. Depending on threat model, this may or may not be an improvement.

[seeker5528]

Install sudo
Fiction: ... because it's dangerous to run as root.

Fact: Issuing commands as root is probably the most common task on a server, because you do maintenance, perform upgrades or set up services. All these tasks require root privileges.

Adding an unprivileged user and elevate him to issue commands with sudo makes little sense, because you have merely replaced root with a normal user who (with sudo) can do anything root can do.

".. because it's dangerous to run as root." may not be sound logic for why you would use sudo, but saying that without saying why you would use sudo seems like it would give people the impression they shouldn't use sudo.

Seems like it would be good to at least mention the use cases of multiple administrators in general and the possibility of give different administrators different rights for administrating different things as a more specific use case.

I have only recently become aware of pkexec. How pkexec gets used seems like it adds some additional nuance to the conversation, but maybe that's too orthogonal to the root versus sudo debate.

[Hallvor]

The point of all this was to show some of the copy-pasted gospel online on how to secure a server. You'll find this advice many places, often without any explanation. The result is consequential errors and quack advice.

I am not saying do not use sudo. Sudo is great if there are many sysadmins: It gives transparency and privilege de-escalation for users to manage certain necessary administrative tasks without full root access, for instance managing printers.

However, it does not make a single user server automatically more secure. That is nonsense.

[trinidad]

https://en.wikipedia.org/wiki/List_of_T ... rt_numbers
https://www.ncftp.com/ncftpd/doc/misc/e ... irewalling

For firewalls, often administrators choose to restrict access to as many port numbers as possible. For cases where inbound connections to the ephemeral ports is required, an entire range of ports must be opened. It is imperative that when opening a range of ports on the firewall that no system services are listening on ports in the open range.

Really? Direct connect (no router) with SSH on a manually specified ephemeral port and allow it as an ethernet connection only from a specific IP. First failed attempt through the router bumps to another already firewalled no-system-services port (poof). Debian port range is about 32,000 to 61,000, and there are more.

TC