Live data from Hacker News

My First 10 Minutes on a Server

codelitt.com

211–220 of 298 posts

Re: My First 10 Minutes on a Server

#211
post #65
post #62

> "You should never be logging on to a server as root." Can someone explain me, let's say I disabled password logins and only allow login via a key, what are potential downsides of logging in as a root?

Well for one, every command you run has root privileges (instead of requiring sudo). Every process you spawn has root privileges. You're safer keeping your privileges limited and sudoing when required. Also you lose your real-life audit log if multiple people log in as root.

But when I tried using a regular user to run anything on a server - it still requires me to do sudo, so the process will anyway have root privileges, no? So I end up typing sudo most of the times becauase most of processes do not work without root priveleges

Re: My First 10 Minutes on a Server

#212
post #208
post #203

Earlier quoted context omitted.

no, my point is exactly that the 2 in 2FA is inherently annoying, because you need to have physical access to 2 different devices at the same time. How does it prevent password reuse? You can use the same (weak) password to lock your phone and login to your banking account (which is again, a false security). However it could be easily circumvented by random generating secure passwords for users (which needs clever ad…

> How does it prevent password reuse? It does not prevent password reuse, it mitigates the risks of password reuse in that it adds the requirement of having physical access to a device, which is a show-stopper for most attackers. If you're using a password manager with sufficiently complex passphrases, the biggest remaining risk factor are targeted malware attacks (something like a keylogger), which is something that…

Meant in the general sense. More complexity, more opportunity for attacks and/or implementation bugs. For starters you have a phone number associated with an account already. I would wager losing your phone is nearly impossible to prevent, while picking your passphrase is up to you. Losing your phone could alone compromise your security, but the very least SMS leaks the info where you bank.

I'm aware I am a minority with this opinion, but I would be really grateful if I could at least opt out from phone based 2FA.

Re: My First 10 Minutes on a Server

#213

Why do people install fail2ban then disable password based authentication entirely? I legitimately don't understand the purpose. Also, they complain about log spam (from failed SSH attempts) this is one reason to move SSH to a different port. It does NOT increase security, but it DOES reduce log spam from bots trying for easy targets.

fail2ban installed = less logspam, and never having to adjust default port with whatever tool is ssh'ing

moving ssh port = less logspam, but now you have to specify your ssh port in every tool that uses it, and it's one more thing that other staff have to remember

Re: My First 10 Minutes on a Server

#214
post #133

Not sure if others feel this way but adding this line to sudo never felt right to me... deploy ALL=(ALL) ALL I usually instead limit the deploy user to a smaller subset of commands e.g. the init.d script to control a service. obviously if someone gained access to deploy user we're probably sol anyway... but it just makes it seem safer... we have a to login as an ops user to install or update things on the boxes.

Someone on /r/netsec rightly pointed out that you shouldn't ever add a user directly to sudoers anyways. You should add them to the sudo or wheel group. I've since updated the article. What I've described is a more of a base, but according the Principle of Least Privilege you could go even one step further and do what you're suggesting. You'd probably want to have a couple of users though. An admin user, a deploy use…

> you shouldn't ever add a user directly to sudoers anyways

What was the reason for that? I have the deploy user able to run a couple of individual commands without a sudo password (scripts that run canned updates, to be initiated from a buildserver), but I don't see how it would improve things to use a group instead that only holds that user.

Re: My First 10 Minutes on a Server

#215
post #197

Earlier quoted context omitted.

I can't see any benefit, what am I missing? Put SSH on a port that's not 22 and done, no more mass scanning. The only thing SSHGuard has ever done for me is to lock me out when I was accidentally using the wrong key.

If SSH is on a non-standard port, it is still possible to brute-force access to the server. You will see fewer automated attempts but you are still vulnerable to a motivated attacker who port scans you and finds the SSH port. Such an attacker is less common than automated scans but is more of a threat. With Sshguard, you are no longer vulnerable to this type of attack at all, no matter which port you run SSH on.

But brute forcing any reasonable password or key is so far-fetched as to not be something to even consider.

Re: My First 10 Minutes on a Server

#217

> We don't even have a password for our root user. We'll want to select something random and complex. So you're taking something secure by default -- no password means no login allowed, and making it less secure. And if you have hundreds of these servers, you'll need to rotate them whenever someone on the team leaves. This is painful. Simple solution: leave root password blank, don't forget your sudo password. If you…

what about protecting against the physical host of the machine?

Re: My First 10 Minutes on a Server

#219
It might nice if there were some cloud vendor specific addendums. For example on rackspace you almost always want to install the monitoring daemon (it's actually fairly decent and small foot print).

Re: My First 10 Minutes on a Server

#220
post #69

Earlier quoted context omitted.

I agree that fail2ban for ssh seems unnecessary. But, it also provides monitoring for other services like http and common exploits. I'd be interested in learning from the community if fail2ban adds much value. As I've looked into the service, it seems like simply running the latest security patches obviates the need for fail2ban.

I run a web server with some 50+ Wordpress installs on it. You better believe Fail2Ban is necessary. Without it all resources would be consumed by brute force attacks. If someone knows of a better way I would like to hear about it.

We use the WordFence module to block brute force attacks, seems to work fine.

I cannot believe that Wordpress still ships without basic rate limiting on its login form.

Post reply on HN