- The sudo user shouldn't own anything that's accessible from the web.

• Setup ufw to "default deny" and only allow ports 80, 443, and your SSH port.

• If using the prefork MPM with Apache, set ServerLimit and MaxClients to a low value (~20) so that a few simultaneous connections don't result in a denial-of-service condition.

• Instead of blacklisting questionable HTTP methods, whitelist only three: HEAD, GET, and POST. Deny everything else. The same principle applies to any other place where you might be tempted to use some sort of blacklisting. It's always better to use whitelisting.

• Safe mode might be useful when you plan to host several websites that are administered by other folks. But if you're the only guy on this server, I'm not sure if it'll be helpful. Not saying you should get rid of it, though. You might still want to use open_basedir to restrict which files PHP can access, but this isn't bulletproof, either.

• Remember that most of those "secure" php.ini directives only serve to hide existing flaws in poorly written software. Do not use poorly written software such as Wordpress, which regularly seems to get hacked. If you absolutely must use something like that, make sure to update it as soon as a new version comes out. If you're writing your own PHP apps, include E_STRICT in your error reporting so as to minimize the chance of writing potentially insecure code. (But don't do that with other people's software, because your error log will be flooded with crap!) Oh, and of course, check your error log periodically.

just my $0.02.

Thanks for the input hybinet!

I'm not sure what prefork MPM is but I'll be looking into it.

A quick question about white-listing HEAD, GET, and POST. Where might I put these HTTP methods and what might they look like? I'm guessing in either /etc/apache2/httpd.conf or /etc/apache2/conf.d/security?

Anyone else want to throw out their two cents? :)

@eekeek:

for a site that might grow to maybe around 300 hits per day.
All that effort for a whole 300 hits a day???

For such a small site, you seem to be drifting well into the tinfoil hat zone.

Backup your site - do the NORMAL security measures - and don't worry so much.

Worse case, call all your visitors to let them know you'll be back online in a hour or so, respin your VPS, restore your backups, and you're back in business.

There's no such thing as 100% secure on a PUBLIC network - so why even try. Just keep good server setup doc's (better yet - script it out - except that's more work then it's worth for just one site), and backup backup backup.

Yeah vonskippy you‘re probably right, maybe I am drifting into tinfoil hat territory. I’m still learning and I don’t know how paranoid I need to be :) . I suppose my current setup is "good enough" for now but, I’m not entirely sure I even know what the “normal security measures” are yet. Locking down SSH, keeping things updated, fire walling ports, avoiding badly written scripts, keeping watch of the logs? Then within those what specific configurations and or programs to install or disable?

For example I've read many times that it's a good idea to stop unneeded programs from running. But I’m so green I don’t even know what programs are running by default or how to turn them off! lol - I know I have a long road ahead of me…one step at a time. :)

@vonskippy:

There's no such thing as 100% secure on a PUBLIC network - so why even try.

That sounds dangerous :D Sure, there's no such thing as 100% security, but that doesn't mean you shouldn't try to harden your box to a certain degree.

• If you just restore your backup after you're hacked, the vulnerability will probably still be there. Which means the bad guy can hack it again and again. Better try not to get hacked in the first place.

• The number of visitors to your site is not proportional to the damage that can be done. An idle VPS can still be exploited to send millions of spam to third parties, for example.

• Despite what I said, trying to limit HTTP methods is probably closer to the tinfoil-hat type than you really need to be. Most web servers should be able to handle those just fine. Just use a tried-and-true web server such as Apache, keep it updated, and you'll be okay. Web servers these days are pretty resilient; PHP is the usual culprit.

• Install htop if you want to see which processes are running. Unlike plain old top, you'll get a color-coded and easily scrollable list. If you see something you don't recognize, Google it to find out if it might be harmful.

• Install munin to collect a bunch of useful statistics above and beyond what is available on the Linode Manager.

Probably didn't say that well. No one can achieve 100% security - so don't try (for 100%).

Security is always a trade off between usability and security. So aim for "good enough" security and use backups and setup documentation to cover those rare cases when "good enough" wasn't good enough.