Is there a tech primer on securing a website?
July 19, 2008 9:28 AM Subscribe
Is there a handy primer on security for people who are new to website building but are experienced in Linux/Unix?
I'm in the first steps of running a website via shared hosting (Dreamhost). I've never done anything like this before and have One Click Installed Pligg, PHPBB and WordPress. I have full SSH/SFTP access, so pretty much full control (not root, though, obviously).
I've got the sites up and running but frankly have no idea about how to secure it all, both in terms of stopping prying eyes seeing data, and also against malicious interests. Is there a primer that explains (a) how websites work, from a Linux/Unix perspective, and (b) explains how to secure them? For example, I understand that apache works by creating a "web" user, and that security comes from controlling permissions for this user, but that's as far as I've got.
If I google for "web security", I just get stuff about adding SSL certificates, or about enacting firewalls, or about configuring Apache/IIS web servers. I don't have control over that, and I don't need a certificate. Just basic instructions on how web hosting works and how to secure it.
I'm in the first steps of running a website via shared hosting (Dreamhost). I've never done anything like this before and have One Click Installed Pligg, PHPBB and WordPress. I have full SSH/SFTP access, so pretty much full control (not root, though, obviously).
I've got the sites up and running but frankly have no idea about how to secure it all, both in terms of stopping prying eyes seeing data, and also against malicious interests. Is there a primer that explains (a) how websites work, from a Linux/Unix perspective, and (b) explains how to secure them? For example, I understand that apache works by creating a "web" user, and that security comes from controlling permissions for this user, but that's as far as I've got.
If I google for "web security", I just get stuff about adding SSL certificates, or about enacting firewalls, or about configuring Apache/IIS web servers. I don't have control over that, and I don't need a certificate. Just basic instructions on how web hosting works and how to secure it.
Wow, orthogonality, that doesn't answer the question at all.
deeper red, you don't give a lot of information on what kind of data you're wanting to secure. The server is Dreamhost's responsibility, so if we just assume it's the actual data, there are tons of ways to do this.
If you are putting it in a database, then the databases have security levels.
http://www.onlamp.com/pub/a/onlamp/2002/07/11/MySQLtips.html 10 MySql "best practice" tips.
And reading up on .htaccess would be helpful. This can be real useful if you're dealing mostly with static pages.
Also, a nice CMS will really help out with this. I use ExpressionEngine, and am able to create users with differing levels of access.
It might be helpful if you mention what kind of site you;re building.
And as far as a "a Linux/Unix perspective" if you have a mac, Apache comes preinstalled, and the documentation doesn't suck.
http://httpd.apache.org/docs/1.3/misc/security_tips.html Look, they even have a page on security.
You really don't have to be an expert on this stuff to make it secure. Just follow the conventions you probably already use, and you'll be a head of 90% of the people out there (non-dictionary passwords, etc.).
posted by cjorgensen at 9:49 AM on July 19, 2008
deeper red, you don't give a lot of information on what kind of data you're wanting to secure. The server is Dreamhost's responsibility, so if we just assume it's the actual data, there are tons of ways to do this.
If you are putting it in a database, then the databases have security levels.
http://www.onlamp.com/pub/a/onlamp/2002/07/11/MySQLtips.html 10 MySql "best practice" tips.
And reading up on .htaccess would be helpful. This can be real useful if you're dealing mostly with static pages.
Also, a nice CMS will really help out with this. I use ExpressionEngine, and am able to create users with differing levels of access.
It might be helpful if you mention what kind of site you;re building.
And as far as a "a Linux/Unix perspective" if you have a mac, Apache comes preinstalled, and the documentation doesn't suck.
http://httpd.apache.org/docs/1.3/misc/security_tips.html Look, they even have a page on security.
You really don't have to be an expert on this stuff to make it secure. Just follow the conventions you probably already use, and you'll be a head of 90% of the people out there (non-dictionary passwords, etc.).
posted by cjorgensen at 9:49 AM on July 19, 2008
Best answer: If you're not managing the server, a lot of the security is up to Dreamhost.
I'd say that the most important thing you can do is keep your stuff updated. It sounds trivial, almost a, "Who wouldn't do that?" type thing. But it's easy to lose track of there being a new update. If you run the most recent, you'll probably be pretty secure... But if you start lagging behind, the odds of your site getting hacked go way up, as you won't be covered against security vulnerabilities found.
I got hacked by running an obscure web app that was way out of date. I didn't even use it anymore, but I'd never removed it. Someone Google 'Powered by [old version here]' and found my site, and successfully used it to download and execute an IRC bot (used to attack other systems). It was a known vulnerability that had been fixed, literally, years ago, but I'd never updated.
A lot of this comes down to your host, though. If /tmp is mounted to disallow execution, a decent amount of web vulnerabilities just won't work. (/tmp is where 'script kiddies' tend to download their exploits and run them from, since they don't know much about the underlying directory structure, but /tmp is standard.)
For example, I understand that apache works by creating a "web" user, and that security comes from controlling permissions for this user, but that's as far as I've got.
In a shared hosting environment, it's not quite that simple: otherwise, you could write a script to view everyone else's stuff, since it's running as the same user. (And, in fact, this sometimes happens, but is generally protected against now.) I've been out of the shared hosting scene for a while, but the trick at the time was for hosts to use something called phpsuexec, which would run web scripts as your user, so they could only access your stuff.
I've found WebHostingTalk.com to be an excellent resource for learning stuff (it's a forum, but I picked up a lot by 'osmosis,' and some more by asking questions when needed). But when a company manages the server, you don't have as much to worry about. Just follow directions carefully (where they're given), and, above all, routinely check for updates. Better yet, subscribe to the 'announce' mailing lists for the software you run. (Google for their site, and join their list.)
Oh, and as far as backups... Don't ever trust your host to make them for you. Figure out how to perform backups through their control panel, both of your files and of your database, and save them to your home/work computer. The backups your host makes are typically only if the whole system crashes, not if just your stuff gets messed up. (And I had a friend who once used a shared host and wiped out a mission-critical database accidentally. He asked the host to restore to yesterday's daily backup... But they then admitted that they didn't actually make backups.) This isn't so much a security thing, but I saw SirStan mention it and wanted to emphasize his point.
Sorry I can't point you to a primer. It's just that everything I'm familiar with is targeted at people managing servers, not individual websites.
posted by fogster at 10:02 AM on July 19, 2008 [1 favorite]
I'd say that the most important thing you can do is keep your stuff updated. It sounds trivial, almost a, "Who wouldn't do that?" type thing. But it's easy to lose track of there being a new update. If you run the most recent, you'll probably be pretty secure... But if you start lagging behind, the odds of your site getting hacked go way up, as you won't be covered against security vulnerabilities found.
I got hacked by running an obscure web app that was way out of date. I didn't even use it anymore, but I'd never removed it. Someone Google 'Powered by [old version here]' and found my site, and successfully used it to download and execute an IRC bot (used to attack other systems). It was a known vulnerability that had been fixed, literally, years ago, but I'd never updated.
A lot of this comes down to your host, though. If /tmp is mounted to disallow execution, a decent amount of web vulnerabilities just won't work. (/tmp is where 'script kiddies' tend to download their exploits and run them from, since they don't know much about the underlying directory structure, but /tmp is standard.)
For example, I understand that apache works by creating a "web" user, and that security comes from controlling permissions for this user, but that's as far as I've got.
In a shared hosting environment, it's not quite that simple: otherwise, you could write a script to view everyone else's stuff, since it's running as the same user. (And, in fact, this sometimes happens, but is generally protected against now.) I've been out of the shared hosting scene for a while, but the trick at the time was for hosts to use something called phpsuexec, which would run web scripts as your user, so they could only access your stuff.
I've found WebHostingTalk.com to be an excellent resource for learning stuff (it's a forum, but I picked up a lot by 'osmosis,' and some more by asking questions when needed). But when a company manages the server, you don't have as much to worry about. Just follow directions carefully (where they're given), and, above all, routinely check for updates. Better yet, subscribe to the 'announce' mailing lists for the software you run. (Google for their site, and join their list.)
Oh, and as far as backups... Don't ever trust your host to make them for you. Figure out how to perform backups through their control panel, both of your files and of your database, and save them to your home/work computer. The backups your host makes are typically only if the whole system crashes, not if just your stuff gets messed up. (And I had a friend who once used a shared host and wiped out a mission-critical database accidentally. He asked the host to restore to yesterday's daily backup... But they then admitted that they didn't actually make backups.) This isn't so much a security thing, but I saw SirStan mention it and wanted to emphasize his point.
Sorry I can't point you to a primer. It's just that everything I'm familiar with is targeted at people managing servers, not individual websites.
posted by fogster at 10:02 AM on July 19, 2008 [1 favorite]
Response by poster: Thanks everybody for the replies so far.
The things I'm talking about are "system" directories for the web apps being viewable (for example, www.example.com/cache). I've figured out that I can drop-in empty index.htm files to make these not viewable, but there are lots of them (and they'll get wiped during an upgrade) -- isn't it possible to deny browser access via permissions? But I'm worried that removing the execute permission of a directory would mean that the web app can't use it.
On my Pligg site, somebody can view a particular page and get a SQL database error (settings.php). This very kindly points out the path to the file, including my /home directory, so therefore including my FTP login name because this is shared hosting. Somebody can then (theoretically) brute force my password, either SSH, SFTP, FTP, and so on, or do various things I'm not aware of.
It's things like this I'm (perhaps without reason) worried about.
posted by deeper red at 10:15 AM on July 19, 2008
The things I'm talking about are "system" directories for the web apps being viewable (for example, www.example.com/cache). I've figured out that I can drop-in empty index.htm files to make these not viewable, but there are lots of them (and they'll get wiped during an upgrade) -- isn't it possible to deny browser access via permissions? But I'm worried that removing the execute permission of a directory would mean that the web app can't use it.
On my Pligg site, somebody can view a particular page and get a SQL database error (settings.php). This very kindly points out the path to the file, including my /home directory, so therefore including my FTP login name because this is shared hosting. Somebody can then (theoretically) brute force my password, either SSH, SFTP, FTP, and so on, or do various things I'm not aware of.
It's things like this I'm (perhaps without reason) worried about.
posted by deeper red at 10:15 AM on July 19, 2008
Best answer: Dropping in empty index files is definitely not what you want to be doing. You'll definitely want to start with a tutorial on the .htaccess file.
posted by bcwinters at 10:53 AM on July 19, 2008
posted by bcwinters at 10:53 AM on July 19, 2008
To of the common (and most dangerous) threats to security that arise with web applications such as Wordpress are XSS (cross-site-scripting) and SQL Injection. It's worth reading up on those and satisfying yourself that your site is not at risk.
Obviously your host is dealing with basic server security, and should be regularly applying patches and whatnot. If they're not, then there's not much you can do apart from switching hosts. Your own main concern should be keeping Wordpress and your other apps up to date; provided you're using widely-adopted apps like Wordpress, vulnerabilities should be a minor worry, as they tend to get patched quite quickly.
Oh, and with PHP, you really should have error reporting turned off if it's a 'production' server.
posted by le morte de bea arthur at 10:55 AM on July 19, 2008
Obviously your host is dealing with basic server security, and should be regularly applying patches and whatnot. If they're not, then there's not much you can do apart from switching hosts. Your own main concern should be keeping Wordpress and your other apps up to date; provided you're using widely-adopted apps like Wordpress, vulnerabilities should be a minor worry, as they tend to get patched quite quickly.
Oh, and with PHP, you really should have error reporting turned off if it's a 'production' server.
posted by le morte de bea arthur at 10:55 AM on July 19, 2008
Two, not 'to'. Dammit.
posted by le morte de bea arthur at 10:56 AM on July 19, 2008
posted by le morte de bea arthur at 10:56 AM on July 19, 2008
Best answer: Dreamhost won't let you have files outside the document root (which is a pain), but you can use .htaccess files to block requests for certain folders (there's lots of info about things like htaccess and mod_rewrite online) to protect caches etc., and for settings files you should make them read-only to add a little more protection.
As others have said, because you're on shared hosting the security of the operating system is out of your hands, and the security of the apps is largely down to the authors, but things like permissions issues and simple passwords often result in security holes. There are various guides on locking down things like WordPress, and you should keep an eye out for security alerts and new versions.
posted by malevolent at 10:57 AM on July 19, 2008
As others have said, because you're on shared hosting the security of the operating system is out of your hands, and the security of the apps is largely down to the authors, but things like permissions issues and simple passwords often result in security holes. There are various guides on locking down things like WordPress, and you should keep an eye out for security alerts and new versions.
posted by malevolent at 10:57 AM on July 19, 2008
Dreamhost won't let you have files outside the document root
Unless something has changed really recently, that's not true. The document root for each domain on your account is the directory with the domain as its name (ex. ~/sub.yourdomain.com/). You can put anything you like in your home directory, which is not the document root for websites served off your domain(s). I have Trac and Django installs running in separate directories off my home directory that work just fine.
posted by chrominance at 11:09 AM on July 19, 2008
Unless something has changed really recently, that's not true. The document root for each domain on your account is the directory with the domain as its name (ex. ~/sub.yourdomain.com/). You can put anything you like in your home directory, which is not the document root for websites served off your domain(s). I have Trac and Django installs running in separate directories off my home directory that work just fine.
posted by chrominance at 11:09 AM on July 19, 2008
Sorry, I must've confused DH with other hosting I regularly have to use for clients that makes it very awkward to have files outside the site. Feel free to remove my best-answer tag :)
Note that if you move one-click-installed apps you probably won't be able to update them via the control panel, so bear that in mind if you do much rearranging.
posted by malevolent at 12:50 PM on July 19, 2008
Note that if you move one-click-installed apps you probably won't be able to update them via the control panel, so bear that in mind if you do much rearranging.
posted by malevolent at 12:50 PM on July 19, 2008
Response by poster: Note that if you move one-click-installed apps you probably won't be able to update them via the control panel, so bear that in mind if you do much rearranging.
My approach so far has been to use one-click install to get it up and running, as well as deal with setting up the SQL stuff, and then upgrade manually.
posted by deeper red at 2:14 PM on July 19, 2008
My approach so far has been to use one-click install to get it up and running, as well as deal with setting up the SQL stuff, and then upgrade manually.
posted by deeper red at 2:14 PM on July 19, 2008
Oh, and with PHP, you really should have error reporting turned off if it's a 'production' server.
This, too, is a job for .htaccess. (Strangely, I've never seen a good 'tool' for creating .htaccess... Now there's an idea!)
I think you want to tuck php_flag display_errors off into your .htaccess file, which should suppress the errors. You should test it to make sure, since I haven't done so.
posted by fogster at 6:12 PM on July 19, 2008
This, too, is a job for .htaccess. (Strangely, I've never seen a good 'tool' for creating .htaccess... Now there's an idea!)
I think you want to tuck php_flag display_errors off into your .htaccess file, which should suppress the errors. You should test it to make sure, since I haven't done so.
posted by fogster at 6:12 PM on July 19, 2008
The biggest security concern with shared hosting is the other people with accounts on the box. Sure, your webserver might not let someone view the wp-settings.php file, but if your wordpress directory is world-readable, then someone else with a shell account can see it. And then they have the mysql username and password, and then they can poke around in the db looking for interesting tidbits (unpublished articles, email addresses, etc.)
In the last few months I've moved away from shared hosting to virtual private servers (VPS). If you're a unix geek, you'll love it, because you have root access and can install everything just the way you want it. The whole idea of having your own server, where the security and stability isn't dependent on hundreds of other strangers is quite comforting.
posted by kamelhoecker at 6:35 AM on July 20, 2008
In the last few months I've moved away from shared hosting to virtual private servers (VPS). If you're a unix geek, you'll love it, because you have root access and can install everything just the way you want it. The whole idea of having your own server, where the security and stability isn't dependent on hundreds of other strangers is quite comforting.
posted by kamelhoecker at 6:35 AM on July 20, 2008
This thread is closed to new comments.
Your site becomes unsecure as you install software such as Wordpress, or other dynamic applications. You are somewhat at the mercy of Wordpress' developers that their application is secure, and not exploitable. You could manually audit the code.
Short story - pick good passwords, and update your software (just like how you keep a Linux server secure).
A larger part of security also revolves around planning - having a contingency plan for if something DOES happen. Even the most secure system in the world might have a security problem. Does your host have database backups? Do they have file backups? Do you need to do this yourself? What happens if 3am this morning someone guesses your Wordpress password and deletes all your posts?
What "data" do you have that you dont want prying eyes seeing? Perhaps it shouldn't be on Dreamhost at all? Say I work for a small doctors office, and want patients to be able to do certain things on my website -- I would not trust my patient information to Dreamhost.
posted by SirStan at 9:44 AM on July 19, 2008