3 ms·
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 sud
by 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 agoThank 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...