Set Up Your Server Right, Part 1(blog.envylabs.com)
blog.envylabs.com
Set Up Your Server Right, Part 1
http://blog.envylabs.com/2009/08/set-up-your-server-right-part-1/
10 コメント
I've never been a fan of changing SSH's port.
If you're going to firewall SSH, changing the port is redundant.. The only reason to change the port is to prevent brute force attacks, and the firewall will do that for you.
If you're going to firewall SSH, changing the port is redundant.. The only reason to change the port is to prevent brute force attacks, and the firewall will do that for you.
Still.... it really cleans the logs up. It's not safer, but the logs do become easier to read in a pinch.
Huh? The firewall logs? Got grep -v?
The thing is that a lot of the simple scripts only bang on 22. Moving the port means that a lot of scripts will move on to another server.
Turn off password logins and move ssh to a different port.
And disable root login from ssh.
Use iptables to limit access to it from only certain static IPs.
Or just disable password logins entirely.
Or just disable password logins entirely.
Yeah, that's really much more secure ;-)
http://www.debian.org/security/2008/dsa-1571
http://www.debian.org/security/2008/dsa-1571
This would only protect you against password guessing, but not against any remotely exploitable security holes in the SSH (or any other) daemon.
Every sysadmin has their own fingerprints. I read some of the suggestions and kind of cringe since they don't match my preferences (not that they're absolutely bad). One of my current aspirations is to "use the tools the way they were intended". Rather than perverting the core components or skinning over them with other admin tools, I believe it's important to appreciate the system as designed and take advantage of the toolset provided.
1) sudo NOPASSWD is the moral equivalent of making that user root. I don't care for it. My preference would be to configure sshd_config with "PasswordAuthentication no" and continue to use passwords in the regular way, with password complexity enforcement if your distribution supports it. I'm not going to blanket condemn ssh public key auth, since it's generally smart. However, you can not enforce a requirement that the public key be encrypted on the remote host. If someone is undisciplined with the distribution of their public keys they can end up turning a single box exploit into free reign of the network, particularly if NOPASSWD is enabled.
2) I prefer manually editing iptables rules myself, using -I and -D. It's certainly not intuitive at first blush, more like using "ed" than "vi". I've gained an appreciation for using the "-m comment -comment 'this rule does blah'" construct. The benefit of this model is that an unfamiliar sysadmin won't immediately know that a host has another FW package installed, but if a change is needed everything is documented and commented in an "iptables -L" -- a standard diagnostic command. Furthermore, firewall rule generators often create unreadable rulesets, making diagnosing specific problems tough.
A specific nit I have against Shorewall is that it requires (last time I checked) you to edit a bunch of different files, using boilerplate recipes that aren't really much simpler than just writing the rules yourself. It could be a big win if you had multiple platforms to support, I suppose.
1) sudo NOPASSWD is the moral equivalent of making that user root. I don't care for it. My preference would be to configure sshd_config with "PasswordAuthentication no" and continue to use passwords in the regular way, with password complexity enforcement if your distribution supports it. I'm not going to blanket condemn ssh public key auth, since it's generally smart. However, you can not enforce a requirement that the public key be encrypted on the remote host. If someone is undisciplined with the distribution of their public keys they can end up turning a single box exploit into free reign of the network, particularly if NOPASSWD is enabled.
2) I prefer manually editing iptables rules myself, using -I and -D. It's certainly not intuitive at first blush, more like using "ed" than "vi". I've gained an appreciation for using the "-m comment -comment 'this rule does blah'" construct. The benefit of this model is that an unfamiliar sysadmin won't immediately know that a host has another FW package installed, but if a change is needed everything is documented and commented in an "iptables -L" -- a standard diagnostic command. Furthermore, firewall rule generators often create unreadable rulesets, making diagnosing specific problems tough.
A specific nit I have against Shorewall is that it requires (last time I checked) you to edit a bunch of different files, using boilerplate recipes that aren't really much simpler than just writing the rules yourself. It could be a big win if you had multiple platforms to support, I suppose.
re: 1) sudo NO PASSWD...
So the problem I have with this is that it collides with using Puppet to manage your users--Puppet will have to know about the users' Unix passwords.
It should be fairly straightforward to write a script that tests for SSH keypairs with an empty passphrase, simply try to authenticate an SSH agent by loading the user's key.
So the problem I have with this is that it collides with using Puppet to manage your users--Puppet will have to know about the users' Unix passwords.
It should be fairly straightforward to write a script that tests for SSH keypairs with an empty passphrase, simply try to authenticate an SSH agent by loading the user's key.
I can't speak to puppet, but I would expect the proper thing to do is to run puppet as root, or possibly create a puppet user with NOPASSWD if you must. There's really no reason to not run as root if you're going to run NOPASSWD ALL, since anyone with the slightest bit of deviancy in mind (or just annoyance with not being root) is going to "sudo su -", and sudo is done.
You can probably write a script that searches for empty-phrase keypairs, but this would be a client side thing. The private key is not disclosed to the server, and all operations involving the private key happen post-decoding, so this is unenforceable server-side. It would be an interesting policy/hygiene enforcement tool but would be of little or no use for security purposes.
You can probably write a script that searches for empty-phrase keypairs, but this would be a client side thing. The private key is not disclosed to the server, and all operations involving the private key happen post-decoding, so this is unenforceable server-side. It would be an interesting policy/hygiene enforcement tool but would be of little or no use for security purposes.
D'oh, upvoted instead of clicking reply =(
What I mean is that in order to manage user accounts, the management tool (Puppet) will have to know what the encrypted password is so it can insert it into /etc/shadow. Otherwise you have no password and must rely on NOPASSWD in sudoers if you want to log into that managed machine and use sudo.
If the system doesn't have a password for you in /etc/shadow, sudo can't authenticate you via getpwent or whatever.
So your only two options are to write a tool for users to update their password in Puppet directly/indirectly, or allow NOPASSWD and religiously check for empty passphrases on SSH keypairs.
What I mean is that in order to manage user accounts, the management tool (Puppet) will have to know what the encrypted password is so it can insert it into /etc/shadow. Otherwise you have no password and must rely on NOPASSWD in sudoers if you want to log into that managed machine and use sudo.
If the system doesn't have a password for you in /etc/shadow, sudo can't authenticate you via getpwent or whatever.
So your only two options are to write a tool for users to update their password in Puppet directly/indirectly, or allow NOPASSWD and religiously check for empty passphrases on SSH keypairs.
It's kinda fluffy. Most of the advice is good, but basic.
One peeve I have is that it's pushing a firewall solution on the local box. In general, that's best done off-host. Even better are MAC security solutions like AppArmor, which is really easy to set up (frankly much more so than a non-trivial set of firewall rules) and much more capable in general. Typical applications need access to only a handful of paths and capabilities that are well-defined in the documentation.
One peeve I have is that it's pushing a firewall solution on the local box. In general, that's best done off-host. Even better are MAC security solutions like AppArmor, which is really easy to set up (frankly much more so than a non-trivial set of firewall rules) and much more capable in general. Typical applications need access to only a handful of paths and capabilities that are well-defined in the documentation.
Considering how firewalls and AppArmor do completely different things, I'd say you need both.
We could automate all these steps using scripts. A very good example is the scripts by RightScale - http://github.com/rightscale/right_link/tree/master
Definitely agree, and the series will move in that direction. However, I think it is important to go over the setup sans automation first -- for the sake of people who have never used the utilities I'm going over.
After all, some will need to step out of an automated script's / puppet config / chef recipe box to do something custom to their setup.
After all, some will need to step out of an automated script's / puppet config / chef recipe box to do something custom to their setup.
* List all installed applications and libraries with versions
* Subscribe to all security advisories of those components
* Look for problems that hit your setup
* Take patch/corrective action when necessary
* OS update is good, but is not the final word in what you need to patch. You need to do your own homework
* Subscribe to all security advisories of those components
* Look for problems that hit your setup
* Take patch/corrective action when necessary
* OS update is good, but is not the final word in what you need to patch. You need to do your own homework
Enlighten me: How is a user with sudo rights different from a root user?
In addition to the advantage that notaddicted mentioned, you can also limit the user(s) to a specific command, set of commands, and so forth. Using sudo in that fashion doesn't give a user root access to the entire system, so it's quite different from "being" the root user.
On a system with multiple administrators sudo provides an audit trail.
[deleted]
How hard is it to provide attribution for the photos used? e.g.
http://www.flickr.com/photos/thomashawk/287666827/
It is attributed. Double-check the bottom of the blog post.
First thing I do is configure the backup software!
It defies belief that a lot of people don't consider this in these guides.
It defies belief that a lot of people don't consider this in these guides.
1. Run software update!
2. Don't allow everyone to access sensitive ports. Moving SSH to some nonstandard port is not enough. Use iptables to limit access to it from only certain static IPs.
3. Run SELinux! If you think its only purpose is to make your life more difficult, you have a lot more studying to do. (Also, make sure you don't use a distro that comes with a badly broken selinux config)
UPDATE: formatting