I sortof agree? if you don't know and /don't want to know/ how to be a SysAdmin, don't get an unmanaged VPS. use shared hosting if you don't have much money and fully managed VPSs or dedicated servers if you have a lot. (Note, /good/ fully managed servers should cost many times over what unmanaged solutions cost. that sort of thing is expensive to do well.)
but, if you want to learn, and are willing to put in the time, I think a VPS is a good place to start. Dealing with compromised hosts (at the very least, shutting them down) is priced in to unmanaged VPS prices.
I wasn't really considering jumping directly to the VPS plan at first. I think as far as getting the site actually running, and proving itself as a concept, I can leave it on a relatively cheap shared host for a while.
My concern became that if I ever outgrew the shared host, which can happen for any number of reasons (bandwidth, needing to configure things in certain ways, etc.), I might not be able to afford to go full managed due to expense. I'm not expecting miracles for this thing financially, as it's just a minor itch I thought could do with some scratching, so full managed might never feel viable to me.
To be honest, becoming a sysadmin was never a big concern of mine, but I wouldn't go so far as to say I "don't want to know" how to do the job. I'm perfectly willing to learn, which is precisely why I created this post.
If I ever do get a VPS, it still won't be until at least a couple months from now, which gives me a reasonable amount of time to learn enough not to embarrass myself and to provide a decent foundation to learn more as I need to.
My top priority with this, and I hope I've made this clear in my comments here (I know I made it clear in my x-post to reddit) is that I want to be sure the system is secure. That is the reason I'm asking for help here, as I never had a doubt that I could get the system to a working state, but I don't have the expertise yet to know when I've left something in an insecure state, and that's exactly why I asked this question: to close that gap before it becomes a real problem.
I think off-site (and inaccessible) backups are the first thing you should think when you think about 'security' - after that, it's a relative thing.
the basics (after backups) are
1. disable anything you don't need (firewalls are part of this... at the very least, the default RHEL firewall closes off almost everything. that way, if you have some poorly configured service running that you don't need, it's less of a big deal 'cause it's not accessible from the Internet.
2. use reasonable passwords. My opinion is that if you can remember it, it's not a good password, but I'm pretty paranoid. at the very least avoid dictionary words (including 'leet' dictionary words) include mixed case and punctuation. If you can use keys instead of passwords, that's even better. Personally, I always disable remote root login with a password. use a key if you must remotely login with root, but most of the time logging in as you and using sudo or su is sufficient.
3. stay on the security or announce mailing list for every bit of software you have exposed to the internet, and upgrade when there are holes.
3. is where your distro comes in. if all the software you use is provided by your distro, and you check the security mailing list every day, you are ahead of most people.
With those three basics, well, you aren't 100% covered, but you have a good start.
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.
>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.)
but, if you want to learn, and are willing to put in the time, I think a VPS is a good place to start. Dealing with compromised hosts (at the very least, shutting them down) is priced in to unmanaged VPS prices.