4 ms·

2 and 3 seem relatively obvious to me. The mailing list part of 3 was new to me, as I wasn't really aware they existed, but keeping things up to date and upgrad

2 and 3 seem relatively obvious to me. The mailing list part of 3 was new to me, as I wasn't really aware they existed, but keeping things up to date and upgrading when they're not seemed pretty common sensey. Regarding #1 though: How do I know what I can and can't turn off? Obviously turning off Apache or something like that is wrong, but there could be less obvious things I may miss. For the things that need to stay on (and I'm mainly focusing on the AMP in LAMP with this), are they generally good-to-go out of the box with minimal "extraordinary" configuration, or are there good resources to securing them that I should be reading? I guess what I'm asking is, beyond following the slicehost/linode tutorials, how much do I really need to know and where can I find it. Beyond all of this, I'll address your first point regarding the inherent incomplete security of things: While you can't make anything 100% secure, you should still try your best to prove that statement wrong. Plugging all "known" holes in your security is still a lot better than being ignorant of them.

lsc 16y ago
>Plugging all "known" holes in your security is still a lot better than being ignorant of them. Know that the moment an advisory is out, the bad guys are using automated tools to scan for vulnerable hosts. Plugging known holes is the minimum standard; otherwise you will be compromised in days if not hours. the vast majority of malicious activity is completely automated, each compromised system being used to compromise other systems. This means that there is a truly staggering number of attackers, and that you will be attacked even if you have nothing of value to take. this is why watching the security mailing lists for your software is important; even a weekly upgrade schedule may not be enough. The rest of the sysadmin jazz, eliminating unused programs and stuff like that are really shortcuts to reducing the number of programs who's security problems are your problems. There are holes we don't know about in everything, so the fewer programs you depend on not having holes, the better off you are. It's good practice to sit there with 'ps' and google and figure out what every process does and how the system responds when a process is killed (especially important if you are on a linux box with an aggressive overcommit and not enough swap, and thus oom-killer issues.)
- AgentConundrum 16y ago
  This is all really good information. Thanks.

lsc 16y ago

>Plugging all "known" holes in your security is still a lot better than being ignorant of them. Know that the moment an advisory is out, the bad guys are using automated tools to scan for vulnerable hosts. Plugging known holes is the minimum standard; otherwise you will be compromised in days if not hours. the vast majority of malicious activity is completely automated, each compromised system being used to compromise other systems. This means that there is a truly staggering number of attackers, and that you will be attacked even if you have nothing of value to take. this is why watching the security mailing lists for your software is important; even a weekly upgrade schedule may not be enough. The rest of the sysadmin jazz, eliminating unused programs and stuff like that are really shortcuts to reducing the number of programs who's security problems are your problems. There are holes we don't know about in everything, so the fewer programs you depend on not having holes, the better off you are. It's good practice to sit there with 'ps' and google and figure out what every process does and how the system responds when a process is killed (especially important if you are on a linux box with an aggressive overcommit and not enough swap, and thus oom-killer issues.)

AgentConundrum 16y ago
This is all really good information. Thanks.