3 ms·

Don't do that, if you are unexperienced with linux. Most people don't realize that, when running a VPS, they become an administrator with all the responsibiliti

by js4all 16y ago

Don't do that, if you are unexperienced with linux. Most people don't realize that, when running a VPS, they become an administrator with all the responsibilities. If your VPS gets hacked, it is a danger for the whole net. My advice, go for a managed solution.

lsc 16y ago
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.
- AgentConundrum 16y ago
  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.
  - lsc 16y ago
    /nothing/ is completely secure. 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.
    - AgentConundrum 16y ago
      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.
Magneus 16y ago
I agree. Unless he's hungry to learn, it's a big leap and will distract him from the development process. If you're looking for a hosted solution that's a step up from a bargain-bin, Dreamhost-like arrangement, consider something like Heroku or Google App Engine.

by js4all 16y ago

lsc 16y ago

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.

AgentConundrum 16y ago
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.
- lsc 16y ago
  /nothing/ is completely secure. 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.
  - AgentConundrum 16y ago
    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.

Magneus 16y ago

I agree. Unless he's hungry to learn, it's a big leap and will distract him from the development process. If you're looking for a hosted solution that's a step up from a bargain-bin, Dreamhost-like arrangement, consider something like Heroku or Google App Engine.