5 ms·

Quick question; I don't know much about setting up a Linux server but I found it interesting the post had nothing related to security besides setting up a ssh k

Quick question; I don't know much about setting up a Linux server but I found it interesting the post had nothing related to security besides setting up a ssh key and separate user for deployment. What security-related tasks do you do when setting up a new server? Besides the above, the only things that come to mind for me are: 1. Change ssh port from default. 2. Block unwanted traffic via iptables. 3. Protect ssh with fail2ban.

latch 12y ago
#2 and #3 in your list are rather sweeping (fail2ban does more than protect ssh). I'm no expert either, the only thing I'd add is to disable password-based logins and root-login [1] [1] http://www.unixlore.net/articles/five-minutes-to-more-secure-ssh.html http://www.unixlore.net/articles/five-minutes-to-more-secure...
- yeukhon 12y ago
  I personally have a mixed feeling about disabling password-based login. What if you've lot your key and you need to access the server for reasons such as getting the data out, how do you do it without root and without login password? Is there a way to go around this issue? Let me know if there is because right now, I have login password that I don't re-use. Well, I guess for real deployment, serving real users, you'd have shading and a good central logging system so losing an instance is not a big deal, but for me I run a personal server and this is so far the way I protect myself (have login and ssh) in the case of lossing my key :( Anyhow, DO droplets allow people to "reset" root password and it is important to protect your DO account.
  - donw 12y ago
    Remote consoles still allow you to login with a password -- you just can't over SSH.
  - AYBABTME 12y ago
    You can enable two factor auth for your DO account.
donw 12y ago
Something that a lot of Ruby deployment setups seem to be missing is setting up proper user permissions for apps and deployment. The first step is to have separate user accounts for everybody that's going to be deploying apps. You really don't want shared accounts (like a single 'deployer' user), because you get no audit trail on who-does-what, and you effectively lose access control to your machines. The second step is to run the app itself as a limited-privilege user -- no write permissions to anything except for logs and tempfiles. A lot of attacks depend on your app being able to overwrite parts of its own code; if that can't happen, the attack fails.
e12e 12y ago
Most important: disable password login to ssh. Optional: disable direct login for root. Optional: limit hosts that can login with whitelist for sshd in hosts.allow (and ALL:ALL in hosts.deny). On Linux I generally don't lock down ports w/iptables - better to not have anything listening on a public interface that's not supposed to be publically available (most distros have sane defaults when set up as a server config these days). As for DO upload your/a pubkey for root access to the control panel and have it installed for you in new images.
akbar501 12y ago
Some very basic security: 1. Change SSH port 2. Block all password logins 3. Disable root login (namely, a non-root user must login via a key, then su or sudo to root) 4. Lock down everything with IPTables 5. Allow only encrypted connections to the few ports open via IPTables (normal exception is port 80 for http). 6. Segment the network (with DO private networking your machines are open to anyone within the same facility, so you need to isolate your private network from other DO customers) 7. Lock down each running service/daemon per it's standard configuration. For example, if you're running Postgres, then lock it down per pg best practices. 8. Create individual, non-privileged users for each service that you're starting. ex. If you're running an app server, then it should have its own user. 9. Sandbox everything that can be. 10. Turn off everything that is not being used, then uninstall it. 11. If you don't need them, then uninstall build tools such as compilers. Have a separate build machine. 12. Only open edge of network machines to the outside world. On DO, turn off eth0 on all machines that customers do not directly interact with. 13. All services that are internal user only should have public networking totally disabled. Ex. Redis should only run on a private IP, should have the public interface disabled, and should only be accessible via a secure connection (ideally with some type of true authentication, replay protection, etc. Or, just run these services on a trusted network and pray that nobody penetrates your network deep enough to find out that you're totally unprotected once inside your network. 14. Don't keep private keys/certs in places that they are not needed. 15. Have a map of each service, the user that it runs under, what resources that user has access to, and a general map of what sequence someone has to follow to control your network. If you catch someone mid-attack, you can start to lock off parts of your network. 16. Logging! And monitor them for attacks. And ship logs off the machine in question so that you can review logs even if a machine is compromised. There's lots more, but this is a basic list that should be configured via Ansible/Chef/Puppet/Salt for each box. One other item I've heard is that some people like to run heterogeneous networks.
- xtrumanx 12y ago
  Thank you so much for all that. I took a great introductory Linux course by the Linux Foundation over at edx[0] which really filled me in on a lot of stuff about Linux one misses out on when they learn on their own. Sadly, the subsequent Linux Foundation training courses are way out of my price range. Even the intro course offered I took for free on edx is offered by the Linux Foundation for thousands of dollars. The good thing is I can mostly learn stuff on my own but have a hard time figuring out what I should be learning. Your comment helps a lot on that department. Even if I don't quite understand how to do some of the stuff your saying e.g. segment the network? Sandbox? Isn't eth0 my primary port to connect to my server? Which logs should I be monitoring (I've only heard of auth.log)? Thanks. [0] https://www.edx.org/course/linuxfoundationx/linuxfoundationx-lfs101x-introduction-1621 https://www.edx.org/course/linuxfoundationx/linuxfoundationx...

latch 12y ago

#2 and #3 in your list are rather sweeping (fail2ban does more than protect ssh). I'm no expert either, the only thing I'd add is to disable password-based logins and root-login [1] [1] http://www.unixlore.net/articles/five-minutes-to-more-secure-ssh.html http://www.unixlore.net/articles/five-minutes-to-more-secure...

yeukhon 12y ago
I personally have a mixed feeling about disabling password-based login. What if you've lot your key and you need to access the server for reasons such as getting the data out, how do you do it without root and without login password? Is there a way to go around this issue? Let me know if there is because right now, I have login password that I don't re-use. Well, I guess for real deployment, serving real users, you'd have shading and a good central logging system so losing an instance is not a big deal, but for me I run a personal server and this is so far the way I protect myself (have login and ssh) in the case of lossing my key :( Anyhow, DO droplets allow people to "reset" root password and it is important to protect your DO account.
- donw 12y ago
  Remote consoles still allow you to login with a password -- you just can't over SSH.
- AYBABTME 12y ago
  You can enable two factor auth for your DO account.

donw 12y ago

Something that a lot of Ruby deployment setups seem to be missing is setting up proper user permissions for apps and deployment. The first step is to have separate user accounts for everybody that's going to be deploying apps. You really don't want shared accounts (like a single 'deployer' user), because you get no audit trail on who-does-what, and you effectively lose access control to your machines. The second step is to run the app itself as a limited-privilege user -- no write permissions to anything except for logs and tempfiles. A lot of attacks depend on your app being able to overwrite parts of its own code; if that can't happen, the attack fails.

e12e 12y ago

Most important: disable password login to ssh. Optional: disable direct login for root. Optional: limit hosts that can login with whitelist for sshd in hosts.allow (and ALL:ALL in hosts.deny). On Linux I generally don't lock down ports w/iptables - better to not have anything listening on a public interface that's not supposed to be publically available (most distros have sane defaults when set up as a server config these days). As for DO upload your/a pubkey for root access to the control panel and have it installed for you in new images.

akbar501 12y ago

Some very basic security: 1. Change SSH port 2. Block all password logins 3. Disable root login (namely, a non-root user must login via a key, then su or sudo to root) 4. Lock down everything with IPTables 5. Allow only encrypted connections to the few ports open via IPTables (normal exception is port 80 for http). 6. Segment the network (with DO private networking your machines are open to anyone within the same facility, so you need to isolate your private network from other DO customers) 7. Lock down each running service/daemon per it's standard configuration. For example, if you're running Postgres, then lock it down per pg best practices. 8. Create individual, non-privileged users for each service that you're starting. ex. If you're running an app server, then it should have its own user. 9. Sandbox everything that can be. 10. Turn off everything that is not being used, then uninstall it. 11. If you don't need them, then uninstall build tools such as compilers. Have a separate build machine. 12. Only open edge of network machines to the outside world. On DO, turn off eth0 on all machines that customers do not directly interact with. 13. All services that are internal user only should have public networking totally disabled. Ex. Redis should only run on a private IP, should have the public interface disabled, and should only be accessible via a secure connection (ideally with some type of true authentication, replay protection, etc. Or, just run these services on a trusted network and pray that nobody penetrates your network deep enough to find out that you're totally unprotected once inside your network. 14. Don't keep private keys/certs in places that they are not needed. 15. Have a map of each service, the user that it runs under, what resources that user has access to, and a general map of what sequence someone has to follow to control your network. If you catch someone mid-attack, you can start to lock off parts of your network. 16. Logging! And monitor them for attacks. And ship logs off the machine in question so that you can review logs even if a machine is compromised. There's lots more, but this is a basic list that should be configured via Ansible/Chef/Puppet/Salt for each box. One other item I've heard is that some people like to run heterogeneous networks.

xtrumanx 12y ago
Thank you so much for all that. I took a great introductory Linux course by the Linux Foundation over at edx[0] which really filled me in on a lot of stuff about Linux one misses out on when they learn on their own. Sadly, the subsequent Linux Foundation training courses are way out of my price range. Even the intro course offered I took for free on edx is offered by the Linux Foundation for thousands of dollars. The good thing is I can mostly learn stuff on my own but have a hard time figuring out what I should be learning. Your comment helps a lot on that department. Even if I don't quite understand how to do some of the stuff your saying e.g. segment the network? Sandbox? Isn't eth0 my primary port to connect to my server? Which logs should I be monitoring (I've only heard of auth.log)? Thanks. [0] https://www.edx.org/course/linuxfoundationx/linuxfoundationx-lfs101x-introduction-1621 https://www.edx.org/course/linuxfoundationx/linuxfoundationx...