/bin/false is not security (2005)
semicomplete.com
semicomplete.com
Clearly you'll only be accepting public key authentication too.
Edit: I see several other people posted this while I was typing :)
SSH to your account, add an alias to sudo in .bashrc (or equivalent for your shell) that records the password in a hidden file before passing it to the real sudo.
By the way, this is why Microsoft invented the UAC prompt: rather than a password, which can be intercepted, it generates a window which (presumably) cannot, thanks to User Interface Privilege Isolation.
For example, the attacker could inject a LD_PRELOAD library that redirects execve() calls from /usr/bin/sudo to a fake version of sudo.
Or, if the server is running Debian, you can set environment variables the .pam_environment file:
The .pam_environment one is interesting, thanks for the link.
It's a little bit of a mix of security through obscurity and security in event of sshd having the vulnerability. It won't save you from a targeted attack but will save from blanket "scan 22 port and try root" attacks.
The same way moving ssh from 22 port to something else helps. If you see someone brute-forcing your root you can dismiss it since it's just someone found open 22 port, but if your actual username is being used in attack then you can detect the targeted attack.
Now having password-less sudo is almost the same as using root.
sudo is useful for allowing generally non-root users to run specific commands or better yet specific scripts (that they can't write to) with elevated privileges - e.g., letting someone "sudo systemctl restart apache2" but nothing else. But it's not particularly useful for auditing people that you want to have mostly-full control over the machine. It can keep honest people honest, sure, but so can .bash_history.
I was not in the sysadmin team, I was in the web team, so I was not allowed root access, even though the box belonged to the web team.
I asked for root access (via sudo) so I could do stuff like restart Apache.
The manager of the sysadmin team said no way was I getting full access to root, but I could get sudo to run specific commands.
So one of the sysadmins wrote a helper script to do the things I needed, and I could use sudo to run that script (and that script alone) as root.
I told him, it wasn't secure, I could use his helper script to get full root access. He challenged me to prove it.
So I wrote a program which dropped a setuid root shell in my home directory. I used the CustomLog directive in Apache to pipe Apache's logs to that program. Then I used his helper script to restart Apache.
When Apache started, it ran my program as root. I then used the setuid binary it had dropped to become root, and created a file in the sysadmin's home directory to prove it.
When I showed this to the sysadmin, he decided to abandon the helper script. Instead, he just told me the root password.
More secure options would be to use CAP_NET_BIND_SERVICE instead of root, or to make Apache bind an unprivileged port and then use something like iptables (or an external load balancer) to redirect 80/443 to the privileged ports. But, for reasons I can't quite recall (it was 10+ years ago) we didn't take up any of those more secure options.
http://httpd.apache.org/docs/current/mod/mod_log_config.html...
I know Apache supports being started as an unprivileged user (I do this myself a lot when I need something a little more featureful than SimpleHTTPServer) but my impression was that that's not very common for production deployments.
SSH public keys have the exact same feature however. Look at "command=" under "Authorized Keys File Format" in the man page. This is a good idea for batch jobs that uses SSH to execute on remote machines.
With SSH keys you even have the option of limiting keys not just to certain commands but to certain IP addresses. By limiting the SSH keys you also don't have to give your keys access to an unprivileged shell where you don't need it.
- attach to an existing screen session that has an existing process under sudo inside it
- edit .bashrc to alias sudo to something that records the password, then come back later
- spawn a background process that waits for the user to run sudo, then opens the pty and uses TIOCSTI to type commands at it
Also, if the attacker actually has control over the sysadmin's local machine, they can do a lot more damage, like any of the above locally, or
- send an email from the admin's account to the team saying "Hi, I'm trying to run this command but I left my RSA token at home, can anyone help?"
- add a browser extension that rewrites all <pre> tags to include a https://thejh.net/misc/website-terminal-copy-paste -style attack
- commit to code or configuration-management repos adding a back door and trigger a deployment
None of these are technically difficult attacks. Requiring a separate sudo password might slow down a script kiddie, but that's about it.
First, sudo should not be cached for this very reason. Second, agent caching should never be enabled for this very reason. Third, agent forwarding should never be enabled for this very reason.
Indeed, using key authentication to log in and then using a password to upgrade to sudo is, I think, very reasonable.
which most often is not the default on vps/root/clouds, that's basically my point. if you use sudo, use it with a password.
Also far better to encourage running sudo for every command, gives a nice simple audit log of what happened, right there in your syslog, so you can identify and undo mistakes, and also eliminate lines of enquiry.
Clearly you can cover your tracks with the old sudo vi / !bash and similar tricks, but the goal isn't to protect against hostile privileges users, its to know what happened so that when John is on holiday you can see what he did to fix the problem you had last week.
sudoedit(8) has been around for a long time and it solves this problem.
The idea for sudoedit is that it allows you to allow non-root users to safely edit files, and if they shell out of their editor then they've not gained root rights - they edit a temporary file as a regular user and then sudo moves the file into place after it is edited.
Unless you have an system with its own auth and audit capability connecting as root, shared accountability is bad. People do dumb shit, including illegal shit.
So, account with sudo capabilities is better than then one which is sudo by default.
However, it's somewhat less secure than sudo-enabled account with password requirement. If your SSH key is somehow compromised (unpassworded keyfile or attacker had gained access to ssh-agent's socket, or you've ran a network-listening daemon from your account that had an exploitable RCE) you're a little bit more safe if attackers won't get root access. This only works well for noexec $HOME, of course, as attacker can't mess with your .*shrc and trick you into entering the password.
It would take a lot more processes to hit the maximum for the entire system
- Use public key authentication
- Encrypt your private keys
- Check the Host keys
- Use SSH Agent
- Use a different key for every computer
- Disable password authentication
- Do not SSH cross-server
- Use safe algorithms
- Use agent forwarding at appropriate times
- Use SSH certificates
- Use a smartcard
- Remove all system passwords
- Use Two-factor Authentication
You never knew about sys admins who put "." in the PATH for root? That was one of the warnings that I remember learning back in the early 1990s.
Remember the good old days when someone's .finger could be used for an escape sequence injection? Even if you read the manual for your terminal, that doesn't mean you change all your habits.
Or sys admins using "xhost +" for easy access to other machines in the local network?
And sys admins forgetting to do backups? That's certainly nothing new.