<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Web Savers &#187; Security</title>
	<atom:link href="http://www.websavers.ca/blog/security/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.websavers.ca</link>
	<description>Hosting, made simple.</description>
	<lastBuildDate>Sat, 17 Jul 2010 14:12:35 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
		<item>
		<title>Why do I sometimes not have permission to delete files on my own account?</title>
		<link>http://www.websavers.ca/blog-post/why-do-i-sometimes-not-have-permission-to-delete-files-on-my-own-account/</link>
		<comments>http://www.websavers.ca/blog-post/why-do-i-sometimes-not-have-permission-to-delete-files-on-my-own-account/#comments</comments>
		<pubDate>Wed, 10 Feb 2010 16:45:01 +0000</pubDate>
		<dc:creator>Jordan</dc:creator>
				<category><![CDATA[All Posts]]></category>
		<category><![CDATA[Hosting]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://www.websavers.ca/?p=919</guid>
		<description><![CDATA[We are asked this question quite regularly and although we have a knowledgebase article outlining how to fix the problem within Plesk, I felt it would be beneficial for many of you to know why it occurs.Your website is served under the &#8216;apache&#8217; user account for all web content, including html and php. Whenever you [...]]]></description>
			<content:encoded><![CDATA[<p><img src="http://www.websavers.ca/wp/wp-content/uploads/2010/02/fastcgilogo.png" alt="" title="fastcgilogo" width="225" height="132" class="alignleft size-full wp-image-926" />We are asked this question quite regularly and although we have a <a href="https://secure.websavers.ca/helpdesk/kb/article/000028">knowledgebase article</a> outlining how to fix the problem within Plesk, I felt it would be beneficial for many of you to know why it occurs.<span id="more-919"></span>Your website is served under the &#8216;apache&#8217; user account for all web content, including html and php. Whenever you use a PHP application, whether custom built or an existing application like WordPress, that application also runs as the apache user. Because of this, files uploaded through your application will be owned by apache and no other users have the ability to edit them. On a shared server, this is good security practice since you don&#8217;t want other people hosted on the same server to be able to edit your files &#8211; including during potential attacks on your site.</p>
<p>When you upload content via FTP you use your personally selected username and password combination. The username you selected also becomes the owner of the files you upload. Similarly, when you attempt to delete files uploaded through an application like WordPress, since they are not owned by your account, you are unable to delete them. The apache user has control over the files.</p>
<p>Although you could get the root user to change the ownership or permissions of the files to allow your account access, this requires creating a support ticket every time you run into the problem. Rather than fixing the problem reactively, we suggest fixing it proactively; ensure that files uploaded through WordPress are already owned by your personal user account rather than apache.</p>
<p>How do you do this? FastCGI!</p>
<p>Within Plesk under Web Hosting Settings, there is an option to run PHP through FastCGI. By changing this setting from Apache Module to FastCGI, you are changing the user that PHP files are accessed with.<br />
<img src="http://www.websavers.ca/wp/wp-content/uploads/2010/02/PHPoverFastCGI.png" alt="This is how it looks in Plesk" title="PHPoverFastCGI" width="579" height="88" class="aligncenter size-full wp-image-921" /><br />
Since all of your PHP files will be executed by your own personal username, all files uploaded through your PHP application will also be owned by your user account. No more apache account in the mix and no more non-deletable files!</p>
<p>One additional benefit is that your files are not owned by the apache user any longer. You might remember that it was beneficial, for security reasons, to have your files not writable by users other than apache, but that only applies when you are forced to upload them under that user account. Since the apache user would be the same for all files uploaded across all websites hosted on the same server, if that account were hacked, then the hacker would have access to all files created by it (if they knew where to look). Now that your files are being uploaded under your personal user account, no other website can affect the security of your own files (assuming permissions are also set appropriately &#8211; ie: no &#8217;777&#8242;).</p>
<p>If you have any questions about this process or believe some of information provided here could be clearer, please <a href="http://www.websavers.ca/contact/">contact us</a> with your suggestions &#8211; we would love to hear from you!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.websavers.ca/blog-post/why-do-i-sometimes-not-have-permission-to-delete-files-on-my-own-account/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Beginners Guide to Website Security</title>
		<link>http://www.websavers.ca/blog-post/beginners-guide-to-website-security/</link>
		<comments>http://www.websavers.ca/blog-post/beginners-guide-to-website-security/#comments</comments>
		<pubDate>Tue, 26 Jan 2010 20:46:35 +0000</pubDate>
		<dc:creator>Adam</dc:creator>
				<category><![CDATA[All Posts]]></category>
		<category><![CDATA[Guides]]></category>
		<category><![CDATA[Security]]></category>

		<guid isPermaLink="false">http://www.websavers.ca/?p=894</guid>
		<description><![CDATA[So you have a website and are a bit concerned about its security. It doesn&#8217;t matter if it&#8217;s a business site or a personal blog, this article will tackle some of the basics you can implement today to avoid the big headaches down the road. How and why do websites get defaced, hacked, or corrupted? [...]]]></description>
			<content:encoded><![CDATA[<p>So you have a website and are a bit concerned about its security. It doesn&#8217;t matter if it&#8217;s a business site or a personal blog, this article will tackle some of the basics you can implement today to avoid the big headaches down the road.</p>
<h3>How and why do websites get defaced, hacked, or corrupted?</h3>
<p>Most sites are compromised by <strong>known vulnerabilities</strong> in <strong>outdated web-based scripts and applications</strong>. Simply put, this means if you run outdated versions of popular software such as message boards, blogging software, or content management systems, your website could be at risk. Other ways a website is commonly compromised is due to insecure or stolen passwords and incorrect file permissions.</p>
<p><strong>Why would anyone want to hack my website? I don&#8217;t store any personal or financial information on my site so I shouldn&#8217;t worry about this right?</strong> Many people feel that because they think no one wants to compromise their website they don&#8217;t need to worry about its security. <strong>Stop it</strong>.</p>
<p>Although they may not want any of the information on your site, most of the time your site will be used to spread viruses, spyware, or deceive your visitors into going to sites with them. Most compromised sites we see have malicious code injected into the files in order to do just this.</p>
<p>Here are a few things you can do today to make sure your website is better protected.</p>
<h3>Start locally</h3>
<p>Make sure your personal computer is secure. If you use an FTP program to upload content to your website, chances are that you have the username and password saved within it. Depending on how that program stores this data it is possible to have that info stolen if your computer has spyware or a virus.</p>
<p>We recommend installing a virus scanner and regularly scanning for spyware along with being more cautious of where you are surfing online.</p>
<h3>Update and patch your third-party applications</h3>
<p>Most website security issues can be avoided by being proactive with updates and security fixes issued by the authors of your applications. </p>
<p>Many popular applications now have a one-click update that takes less than 30 seconds to perform. It is recommend that you backup your data before upgrading which can usually be done through your Control Panel.</p>
<p>If you stop using an application make sure you remove it. If you&#8217;ve switched from WordPress to Joomla for your content management, make sure you remove the WordPress installation as it can be forgotten about and left outdated. Even though you may not be using it, it can still be accessed.</p>
<p>Remember that updates, patches, and new releases are released for a reason. Staying on top of these updates may seem like an inconvenience at the time, but it will save you from a lot of headaches and issues in the long run.</p>
<h3>Checking file permissions</h3>
<p>Allowing everyone to read, write, and execute files on your website is a huge security issue. In a web-based environment you typically will want a &#8220;755&#8243; permission setting, or full access to the file owner, and only read/execute access for everyone else.</p>
<p>Some applications will ask you to set a permission to &#8220;777&#8243; or full access to everyone. Make sure you are running the most up-to-date version of this application before installing. Also, you may want to try it with a 755 as some hosting environments will for this.</p>
<h3>Secure your login areas</h3>
<p>It is best to access the administration area of any application over SSL (https://). This can be done by making sure it is placed in a ssl-based directory.</p>
<p>In addition to this, it is possible to limit the admin directory to only specific IP addresses. This can be done by placing the following information into a <a href="http://en.wikipedia.org/wiki/Htaccess">.htaccess</a> file: </p>
<blockquote><p>
AuthUserFile /dev/null<br />
AuthGroupFile /dev/null<br />
AuthName AdminAreaAuth<br />
AuthType Basic<br />
order deny,allow<br />
deny from all<br />
# allow home IP address<br />
allow from 99.x.x.x<br />
# allow work IP address<br />
allow from 142.x.x.x<br />
# allow vacation home IP address<br />
allow from 24.x.x.x
</p></blockquote>
<p>For example, if you wanted to secure the admin area of your <a href="http://www.wordpress.org">WordPress</a> installation, you would place this .htaccess file in your /wp-admin/ directory. It will deny all connections that are not made from one of those predefined IP addresses.</p>
<p>&#8212;<br />
Hope this helps. Interested in hearing more on a specific topic? <a href="http://www.websavers.ca/contact/">Let us know!</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.websavers.ca/blog-post/beginners-guide-to-website-security/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
