Latest News: (loading..)

Archived

This topic is now archived and is closed to further replies.

Taipo

A chat about File permissions

23 posts in this topic

I wrote this in another discussion but it probably needs its own thread.

 

There is some confusion surrounding the issue of file and folder permissions, and a lot of this is because there has been a change in methods in the last few years and many are not aware of.

 

There are in general two philosophies with virtual hosts now which have come into play probably because of the esculation in traversial type server intrusions.

 

Before, the common method which Ill refer to as method 1, the first of the two primary methods, was to use folder and file permissions as a means of controlling the writability of content where the server script, in this case php, needed a file to have a write permission of 666 to be able to write to that file.

 

The case was the same with folders, which like files of 644, were by default non-writable. In order for php to write to files in that folder, or to create files or delete files or even chnmod files, the folders have to have permissions of 777. 777 though meant that the writable folder was prone to an attack from another infected website on the webserver, using a directory traversal, an attacker could write into any folder within other websites that were writable.

 

And because it is possible in method 1 for malicious scripts to execute outside of the virtual host folder, it is possible for affected scripts to be used to read higher up into the server, like to nab the root user and passwords, scan all directories and files, read them, which usually could give an attacker enough information to be able to enter every site on that server (consider for a minute that a configure.php file chmod to 644 is still readable, even chmod to 444 is still 'readable' in this method 1 type configuration. In configure.php are the user and passwords for your mysql server, and in many situations, that user and password is not that different from the cpanel login, and the FTP user and password.

 

So while this restricted the overwriting attacks (often referred to as defacements) to just writable folders and to writable files on your website, it did allow attacks to span across multiple websites, often referred to as a mass defacement. It allowed attackers to run arbitrary code on non-root services like APACHE and spamassassin and others.

 

The second method, method 2 which has come into play with several php mods, usually in share hosting configurations, is to assign the owner privaleges to the user and the script, thus pretty much making the whole file and folder permissions almost redundant if your web code security is crap. On the plus side, if another site on the shared server is exploited, the attack is not able to spread their attack across virtual hosts, in other words, the attack is restricted to just the site that has the weak security coding.

 

On the downside of method 2, if your site is the one that has been attacked, every file and folder in that configuration is pretty much vulnerable to be overwritten irregardless of the file permissions (if malicious backdoor files have been installed, or code appended into files from the previous admin bypass exploit).

 

Sure you can chmod a file to 444 via a filemanager or FTP client (if allowed), but in this particular configuration which is becoming more and more popular amongst shared hosts, because PHP has user permissions therefore is the owner, it is able to chmod file permissions back to writable.

 

So all an attacker needs to do is call chmod() a file from 444 to 644 before calling fopen($filename, 'a') to append their code to any file they wish, and if they want to be nice, chmod the appended file back to 444.

 

Of course it is a waste of time doing this to some files, so they go for the main include files usually, like the language file, application_top and the javascripts.

 

I think the key indicator in all of this is that if PHP is saying that all files and folders by default (644 for files and 755 for folders) are writable, and in some situations, the webhost has given you your own php.ini to play with, then your site is on one of these configurations.

 

So therefore that means that the attack has come via a file still resident in your file repository or appended code in your site files somewhere that you must have missed.

 

So that little script above just gives you an indicator that if your index.php file is set to 644 and is writable by PHP, then there is a good chance all the files are the same. And by implication that your site is on a method 2 type configuration, that could mean there is still a rogue file or code somewhere on your site that has been missed somehow, rather than the usual assumption that the attack has been a traversal across from another affected website.

 

Long-winded I know, but just hope it gives a better insight into why there are differences in server setups where that same code above on one site would say that index.php is read only, and on another, its writable, yet the file permissions are the same.

Share this post


Link to post
Share on other sites

Here is a simple test:

 

Create a file called filewritetest.php and put the following code in.

 

<?php 

 // change the file name to whatever file you are testing 
 $testfile = "testchmod.php"; 

 error_reporting(0); 
 $i=0; 
 $content = NULL; 
 $writeperms = substr( decoct( fileperms( $testfile ) ),3 ); 

 if ($writeperms <= 665) { 
   if ( !chmod( $testfile, 0666 ) ) { 
     $i++; 
   } else { 
     $msg .= "able to chmod<br>"; 
   } 
 } else { 
   $msg .= $testfile . " is already chmod to " . $writeperms . "<br>"; 
 } 
  if (!$fp = fopen($testfile, 'r')) { 
   $i++; 
 } else { 
   $content = stream_get_contents($fp, -1, 0); 
   fclose($fp); 
   $msg .= "able to read content of " . $testfile . "<br>"; 
 } 
 if ( !$fp = @fopen( $testfile, "w" ) ) { 
   $i++; 
 } else { 
   $msg .= "able to open " . $testfile . "<br>"; 
 }  
 if ( fwrite( $fp, $content ) === FALSE ) { 
   $i++; 
 } else { 
   $msg .= "able to write to file " . $testfile . "<br>"; 
 }  
 if ( !fclose( $fp ) ) { 
   $i++; 
 } else { 
   $msg .= "able to close file " . $testfile . "<br>"; 
 }  
 if( $i > 0 ) {  
   echo $testfile . " is Write-Protected "; 
 } else { 
   echo $msg; 
 }  
?>

 

Create another file called testchmod.php and upload both of these to your websites main directory. Change the file permissions of testchmod.php to something like 644 or 600 or 444 then in your browser navigate to filewritetest.php and see what the printout says.

 

It will either read that the file is write protected or it will state that it is able to change the permissions to 666, open read, write and close the file.

 

If so then your website is probably on the 2nd method of shared host configurations.

Share this post


Link to post
Share on other sites

Here is a simple test:

 

 

If so then your website is probably on the 2nd method of shared host configurations.

 

Taipo, I continue to follow and learn. I CHMODed testchmod.php to 444 on one of my sites, ran the test and here's the readout:

 

able to chmod

able to read content of testchmod.php

able to open testchmod.php

able to write to file testchmod.php

able to close file testchmod.php

 

So that affirms my host is running the second configuration.

 

In general I am comfortable with this. Firstly because as you describe, the first method could leave my stuff vulnerable to something elsewhere on the host. I don't know if that means you're defenseless if such would occur but even if not, I don't like that idea of somebody else's site on my host getting compromised, thus putting my sites at risk.

 

Secondly, if I understand this correctly, with option 2, and presuming that sufficient "anti-hack" methodology and strategy is in on my sites, and that my sites not be previously compromised, then I should be in fairly good shape.

 

Thank you again for this info, very interesting and informative.

Share this post


Link to post
Share on other sites

That is actually the same with both methods. They both have the strengths and both have their weaknesses. From a server hosts perspective, they can lock a hack into the home directory of the virtual host that is affected, although as mentioned, the damage would be more severe since all files and folders are writable by PHP (or any script installed on that server). But from their perspective I suppose they would see that as a localized issue and at least only the insecure site was affected.

 

From the end users point of view, we make the assumption that there is still such a thing as file and folder protection, and in method 1 configurations that is true. But Oscommerce for example like many interactive scripts, is still coded with permissions in mind. The install still asks for configure.php to be write protected for example, which would mean a 444 setting on method 2....if your server host even allows 444.

 

An oscommerce hack on a method one configured server would localise the damage to writable files and directories, which is why you see some people talking about files being installed in their images directory, and others will have files in the images directory, and oscommerce files overwritten right throughout their website. Which they clean up, restore, and they get overwritten again because in the cleanup, just one file was missed. ALso as mentioned, and attacker could also launch the same attack across into other webfolders as well.

 

So yes to your second point, employing the security suggestions offered by others here, along with a completely new osc2.3.1 webscript that has been installed on an empty website is the most secure scenario.

 

Where people run into problems is when they either try to clean their files and miss one...or more boogie, or restore a backup which had already been infected, or upgrade over top of the existing site which will not remove files that have been added that are not a part of the Oscommerce file repository.

 

The point of this little discussion piece of mine is to address a belief that file and directory permissions can protect you, when they really shouldn't be relied upon at all.

 

Security has 4 levels to it.

 

1/ Good security at the server end which is your webhosts responsibility

2/ htaccess, which is the gateway into your site

3/ good coding practices by the designers which in a perfect world would mean there is no need for the likes of security pro or osc_sec.

4/ because this is not a perfect world, a security code or codes that cover blacklisting and whitelisting of user inputs.

 

A good example of why you shouldn't depend on permissions, is the belief by coders that forcing users to set their configure.php files to read only is somehow a more secure option, when the file is still readable, so via a hack, an attacker can read the file, grab the user and password for the database, and have a party at your expense, all with a write-protected file content.

 

If it comes down to file and directory persmissions to save you, then your site is toast bascially, because all 4 levels of security have failed you if they even existed in the first place.

Share this post


Link to post
Share on other sites

Here is a slightly more improved version of the proof of concept:

 

Purpose: to test if a file is ever really write protected on your server

How:

1/ create a file called testwritefile.php and add the following code.

<?php
 error_reporting(0);
 // change the file name to whatever file you are testing
 // caution: do not test on production files  
 $testfile = "testchmod.php";  
 $msg .= "File being tested: <a target=_blank href=" . $testfile . ">" . $testfile . "</a><br>";
 if (file_exists($testfile)) $msg .= "- " . $testfile . " exists<br>";

 if (!file_exists($testfile)) die($testfile . " does not exist");
 $i=0;  
 $content = NULL;  

 $writeperms = file_perms($testfile);  
 if ($writeperms <= 665) {  
   $msg .= "- original file permissions for " . $testfile . " are " . $writeperms . "<br>";
   if ( !chmod( $testfile, 0666 ) ) {  
     $i++;  
   } else {  
     $msg .= "- file permssions changed to 666<br>";  
   }  
 } else {  
   $msg .= $testfile . "- is already chmod to " . $writeperms . "<br>";  
 }  

 if (!$fp = fopen($testfile, 'r')) {  
   $i++;  
 } else {  
   $content = stream_get_contents($fp, -1, 0);  
   $content = "This is a test<br>" . $content;
   fclose($fp);  
   $msg .= "- able to read content of " . $testfile . "<br>";  
 }  
 if ( !$fp = @fopen( $testfile, "w" ) ) {  
   $i++;  
 } else {  
   $msg .= "- able to open " . $testfile . "<br>";  
 }   
 if ( fwrite( $fp, $content ) === FALSE ) {  
   $i++;  
 } else {  
   $msg .= "- able to write to file " . $testfile . ":  \"This is a test\" was appended<br>";  
 }   
 if ( !fclose( $fp ) ) {  
   $i++;  
 } else {  
   $msg .= "- able to close file " . $testfile . "<br>";  
 }   
 if( $i > 0 ) {   
   $msg .= "- " . $testfile . " is Write-Protected ";
   echo "<font face=verdana size=1>" . $msg;
 } else {  
   $writeperms2 = file_perms($testfile);
   $msg .= "- " . $testfile . " permissions are now " . $writeperms2 . "<br>";
   $msg .= "- changing permissions to 444<br>";
   chmod( $testfile, 0444 );
   $writeperms3 = file_perms($testfile);
   $msg .= "- " . $testfile . " permissions are now " . $writeperms3 . "<br>";
   if (is_writable($testfile)) $writable = " is still writable";
   if (!is_writable($testfile)) $writable = " is not writable but can still have its permissions changed<br>";
   $msg .= "- " . $testfile . $writable;
   $msg .= "- reload the page to see it overwrite this file now set to 444<br>";
   echo "<font face=verdana size=1>" . $msg;
 }  

function file_perms($file, $octal = false)
{
   if(!file_exists($file)) return false;
   clearstatcache();
   $perms = fileperms($file);
   $cut = $octal ? 2 : 3;
   return substr(decoct($perms), $cut);
}
?>

 

2/ The create another file called testchmod.php to test on,

3/ upload them both to your servers root directory and change the permissions of testchmod.php to lower than 644 (600 or 444 for example).

4/ browser to testwritefile.php and read the report

5/ browse to testchmod.php and see if the text was appended.

 

This version of the code you can run the test over and over again. If the file is writable, this code will change the permissions, add in some text, and close the file, changing the permissions back to 444 (it will attempt to...change it back).

rdva likes this

Share this post


Link to post
Share on other sites

Dear Taipo,

 

Thank you for your advise however I am new to osCommerce having recently taken over the working of the site that has been running for two years.

 

Because it was custom made I am working backwards so to speak as not had the confidence to upgrade to the newer version as like the shop I am currently working with.

 

Having said that recently I have been hacked regularly on a nightly basis each time I narrow down the infected files, upload clean file, change the permissions to 444 and .htaccess protect the directory. I always test the site to see it working, then bang the following night they seem to hack a different directory and different files so after many nights of this I am pulling my hair out!

 

Have written and tested the file as you discuss with the following results:

File being tested: testchmod.php

- testchmod.php exists

- original file permissions for testchmod.php are 444

- file permssions changed to 666

- able to read content of testchmod.php

- able to open testchmod.php

- able to write to file testchmod.php: "This is a test" was appended

- able to close file testchmod.php

- testchmod.php permissions are now 666

- changing permissions to 444

- testchmod.php permissions are now 444

- testchmod.php is not writable but can still have its permissions changed

- reload the page to see it overwrite this file now set to 444

 

So I assume method 2 however not sure what to do with the results as the hackers just seem to move onto the next directory and set of files? I tried locking down all directories with the .htaccess & file permissions but that affected the working shop. Have done the admin protection etc but they are just changing a few files at a time so can I assume that I am slowing narrowing down their activities night by night or will this suddenly explode into a full scale attack?

 

Thank you for any further advise and sorry if this is a basic question however I seem to be spending hours going through the forum and coming back to the .htaccess and file permissions question which being a newbie can't still get my head round it?

 

Best Regards

Sam

Share this post


Link to post
Share on other sites

What this test indicates is that your site script is running as the owner. Which indicates that most likely the server is configured under method 2, which eliminates the possibility that the attacks are being launched from anywhere else other than rogue files on your site.

 

File permissions will not save you neither will directory permissions in this type of configuration. If there are rogue files uploaded into your directories, or hidden with in site files then they will have complete permissions to do what ever they so please with your site.

 

Unfortunately in your situation there is no easy way around the only real way of dealing with your issue. In the name of security you best follow the advice given by many others on these forums. That is to take the sites offline, build a new set of sites using the latest patched version of oscommerce, and then import the database and images into the new site.

 

If you decide not to do that, then the next best thing, and there is a big void between this suggestion, and the last one, is to take the sites offline, and troll through every file matching it against the originals, and remove any code that resembles rogue javascript, upload code, or obsfuscated base64 code.

 

This actually, if you are a newbie to php and javascript, would take more time than creating new sites since it involves learning PHP to a sufficient level to recognise what that code would look like. I have given some examples of code I have found, but there are many variations, some of it blatant, other script is cleverly masked.

 

So in the end the first option is probably the one that will take the least time and effort, even though it might mean you learning how to install and configure the new site, and then work out how to import the database and relink the images. Add to that all the addons as well if there are any to bring it back to the working order it is at now.

 

What you need to understand is that the attackers are using rogue code in your site which is giving them the ability to do anything on your site. Anything you can achieve via the admin panel they can achieve with these rogue codes, so if you have sensitive customer data in your database, just consider it nicked already.

 

Thats how serious it is, and why sites need to be taken offline and fixed rather than picked at while still live.

 

Sorry I cannot be of more help to you on this issue. I will periodically post more rogue code in here as I find it, but there are so many different ways an attacker can achieve the same thing when they have that much access to your stuff.

Share this post


Link to post
Share on other sites

Dear Taipo,

 

Thank you for all your advise and touch wood since locking down thankfully I have not had a problem by putting on password protection and reducing file permissions.

 

Best Regards

Sam

Share this post


Link to post
Share on other sites

Dear Tapio, what do u think about idea to move out all writeable folder/files out of Webserver Root Folder (public_html)? Like sessions folder (descibed at OSC manual). I'm running OSC at Virtual Dedicated Server and able to do it.

Share this post


Link to post
Share on other sites

I think the main thing is to make sure the version of Oscommerce you are running is as secure as it can be. There is no hiding from gaping security holes no matter where you try and hide files. On a secure content management system you do not really need to hide anything, however it doesn't hurt to do so. However transversely on an insecure content management system there is no place you can hide files that cannot be attacked.

 

Part of the problem that has developed with Oscommerce in the recent attacks is that people have been instructed on what is essentially just hiding files and directories as one of the primary methods of 'securing' a website, when in fact patching and securing the code itself is always and should always be the primary method, cleaning up infected files would be second, and when properly secured, hiding directories like the admin directory is an optional extra.

 

Session directories should at least not be web accessible. So anywhere above the public_html directory is best. But again, an insecure set of files like Oscommerce 2.2.1 will not be saved by changing the location of writable files and directories.

rdva likes this

Share this post


Link to post
Share on other sites

Taipo, thanks for the response. I'm running heavily modified OSC MS2.2 and simply can't upgrade to 2.3 - too much changes. i'ts better to build completely new shop on OSC 3 later. So, for now my strategy is:

1. Renamed admin folder, deleted file_manager.php and define_language.php

2. Right access rights (no higer than 755 for directories, 644 for files). All files owner is ftp user, which upload files to server. All writable stuff belongs to php user.

3. Tested and eliminated all holes, described at description of osc_sec and at exploit-db.com. Also played around with hack shell, founded at http://tinyurl.com/osc-hack3 (that's why i'm thinking about move out all writable stuff higher than public_html)

3. osc_sec or php-ids or security pro and IP Trap

4. Site monitior

 

What do u think about this? Is it ok for OSC ms2.2?

Share this post


Link to post
Share on other sites

The main thing with osc 2.2 is to patch the $PHP_SELF code - the patch is in osc_sec.php, the rest you have listed is mostly being doubly safe....if you have patched that code.

 

Tested and eliminated all holes, described at description of osc_sec and at exploit-db.com.

 

Osc_Sec has all the patches for those holes plus the main patch that fixed the gaping hole where all this began. It also has a lot more in it as well, little holes that I found along the way, some yet to be exploited, and will no doubt be picked on once people migrate to 2.3.1

 

osc_sec or php-ids or security pro and IP Trap

 

In actual fact all 3 of those work fine together, without conflict.

Share this post


Link to post
Share on other sites

I think I should re-install 2.3.1 and have someone make the proper security changes.

This way, I don't make additional errors.

Where may I find someone to assist me

 

 

Thank you in advance

Brad

Share this post


Link to post
Share on other sites

There are no known bad security holes in 2.3.1. However it does not hurt to make changes like renaming the admin directory or putting htaccess user and password protection on that directory. It is also ok to install any of the security addons that were made for 2.2.1 as well.

 

The only (security) mistake that can be made is when upgrading from 2.2.1 to 2.3.1 by not completely cleaning out the web files and installing the new fileset, thus leaving rogue files for example still in the images directory which can be still accessed and exploited by the attackers on your site.

Share this post


Link to post
Share on other sites

Taipo, coming back to file/folders permissions: let's imagine, we have fully patched and secured osc shop, BUT some smart bad guy have found new security hole at OSC and try to upload exploit to our web-server. If all files/folders at webserver are write protected, the attacker can't upload or modify anything, right?

Share this post


Link to post
Share on other sites

If your web server allows it then file permissions can help make it more difficult for attackers to reek havoc with uploaded files via a security exploit hole.

 

However more and more webhosts are switching to this other method probably for liability reasons and also to localize the damage if a site is compromised. With method one as mentioned, the attacker would then have the ability with their uploaded file, to try and traverse to other virtualhost file repositories, would still be able to 'read' the contents of any file no matter how hard you screw down the file permissions, and so while the damage would be minimal, it could still allow an attack to come in from 'outside' so to speak.

 

With method two, it is up to the website admin to maintain their code, in that case then, an exploit code would reek havoc, as we have seen, however only within the web repository of the virtual host in question, and perhaps up into the tmp directory on some configurations where the tmp directory is still common.

 

On this configuration (method two) at least you would have no doubt in your mind where the attack has been launched from, within your own website files.

 

Actually I finally found another discussion on this issue where many of these points have already been discussed.

http://www.webhostingtalk.com/showthread.php?t=1023185

 

Even though its a discussion about suPHP apache module, suPHP is one of those modules that uses the method 2 method of executing the PHP interpreter (PHP running as CGI).

 

Worth a read if you have the time.

Share this post


Link to post
Share on other sites

Taipo, you are talking about shared servers, right? In my case i'm only one user of VPS and php and file owner are different users. So i think it's worth the time to move all writable stuff out of web server folder. Let's call it "Idea 1".

 

BUT, thank you for the link, i have found there other interesting idea (let's call it "Idea 2") - disable script execution at writable folder. Google point me to this code for .htaccess:

# Don't run arbitrary PHP code.
php_admin_flag engine off   

# Serve HTML as plaintext, don't execute SHTML
AddType text/plain .html .htm .shtml

Source - https://wiki.mozilla.org/Documentation:Security

 

What do u think about this?

Share this post


Link to post
Share on other sites

Certainly if you have control of the virtual host file and can construct your own <Directory> settings you can disable that sort of thing.

 

The Method two I am referring to is not just restricted to shared servers although it is most commonly found in the shared server configuration. There are still a limited amount of things attackers can do if they can upload files into a directory even if the directory is set to disable execution.

 

For example check the following "image" out. Your antivirus may prevent the page from loading but its just a text file mascarading as an image (named as an image).

http://www.vipekaem.ru/images/vero.jpg

Attackers use this type of file to load viruses into other websites via XSS injection. While its not exploiting the site it is on, other site owners will soon take a dislike to any site these types of files are being launched from.

 

But if you have your site on the Method one configuration then by all means set your upload directories to higher up the chain out of the reach of web viewable directories.

 

But for most users of the method one configuration, the directory in question would be the images directory which would best be left at 755 permissions until you are ready to upload images into it.

 

While there is always a chance there could be a yet to be discovered security hole in 2.3.1, there is a greater risk......by far......for users that have already been hacked and upgraded or 'fixed' their hacked sites, that they missed one of the rogue upload files or appended uploader code placed into their site files, in which case on method one the 755 directory setting is the safest, and on method two....well there isn't much that can save you, in each case though, the best is to do the cleanup properly - or upgrade correctly.

Share this post


Link to post
Share on other sites

I wrote this in another discussion but it probably needs its own thread.

 

There is some confusion surrounding the issue of file and folder permissions, and a lot of this is because there has been a change in methods in the last few years and many are not aware of.

 

There are in general two philosophies with virtual hosts now which have come into play probably because of the esculation in traversial type server intrusions.............

 

Taipo, I have switched my shops from individual shared hosting to one VPS account. How does the concept of securty apply to a VPS acct vs shared hosting?

 

Thanks

Share this post


Link to post
Share on other sites

At the end of the day the codeset does not discriminate between a shared environment or not. So you will be asked to set file permissions to read only for the includes/configure files irregardless. Generally speaking unless there is a server wide attack, there is little chance of your site suffering a traversal attack.

 

I doubt there have been many actual traversal attacks on osCommerce to date because the sheer amount of effort actually needed to pull off such an attack, when the security flaws that were in the older versions of osCommerce took almost no effort to exploit.

 

Plainly speaking, if the script (PHP) has owner privaleges then there are no file or directory permissions that will save you if an attacker is able to append rogue code into one of your sites files. The point as always is to make sure your site is patched so that the attack is stopped at the gate, rather than depend on locking doors and windows so to speak to keep the attack from being successful.

 

On the suPHP type configurations, even if a file is read only at 444, PHP can still chnmod the file permissions to something writeable, then write to it. So in the end when working on that type of configured webserver, file permissions as means of security is a bit like locking your car with the keys inside. It may make you feel slightly safe knowing that at least the keys are inside, but to a car thief that presents them with about 5 seconds more work to break in to your car and once they are in...best not to leave the keys in the car....i.e. correctly patch your sites against the security attack with the actual patch code for starters.

 

Any extra security after that is more designed to give you peace of mind than the actual security it may or may not provide.

Share this post


Link to post
Share on other sites

Thank you, I've always placed site security at the top of my list of things to do, and my sites have withstood most attacks. I say "most" because my host got hacked in Sept, which effected all sites on that host that had an "index" file anywhere in their sites. Got through that one though thanks to backup. Anyway...as always thank you for your help and advice.

 

 

 

At the end of the day the codeset does not discriminate between a shared environment or not. So you will be asked to set file permissions to read only for the includes/configure files irregardless. Generally speaking unless there is a server wide attack, there is little chance of your site suffering a traversal attack.

 

I doubt there have been many actual traversal attacks on osCommerce to date because the sheer amount of effort actually needed to pull off such an attack, when the security flaws that were in the older versions of osCommerce took almost no effort to exploit.

 

Plainly speaking, if the script (PHP) has owner privaleges then there are no file or directory permissions that will save you if an attacker is able to append rogue code into one of your sites files. The point as always is to make sure your site is patched so that the attack is stopped at the gate, rather than depend on locking doors and windows so to speak to keep the attack from being successful.

 

On the suPHP type configurations, even if a file is read only at 444, PHP can still chnmod the file permissions to something writeable, then write to it. So in the end when working on that type of configured webserver, file permissions as means of security is a bit like locking your car with the keys inside. It may make you feel slightly safe knowing that at least the keys are inside, but to a car thief that presents them with about 5 seconds more work to break in to your car and once they are in...best not to leave the keys in the car....i.e. correctly patch your sites against the security attack with the actual patch code for starters.

 

Any extra security after that is more designed to give you peace of mind than the actual security it may or may not provide.

Share this post


Link to post
Share on other sites

There are many things you can do to reduce the chance of a hack, but there is always the possibility that your host will suffer a massive breach. Therefore, your last line of defense is always a good, verified clean, backup (that you know is good and complete, and you know how to restore because you've tried it before). Whatever crap was dumped on your site, you can always get back to a state no more than a day or two old.

 

I suppose that the next-to-last line of defense is a warning system that your site has been altered. You can run a daily cron job to take a listing (ls -la) of all your site's files, and compare it to a protected version of the listing from the previous day (possibly on your PC) with "diff" or "fc". It can report file changes, and alert you to any changes that you weren't expecting (new or modified files). I seem to remember there being a mod/add-on to look for and report site file changes, to that end.

Share this post


Link to post
Share on other sites

Yes that is the issue with shared hosting that employs the traditional method of file permissions, a server wide attack is much more possible. In the suPHP type configurations it is less likely to occur and I suspect that is the primary reason many shared hosts are fast moving in that direction.

 

Out of all the site hacks I have been able to look at, only one so far has been the result of a server wide hack, the other gazillion sites I have had the opportunity to look at were hacked because of unpatched site code or additional code added in that introduced vulnerabilities.

 

Mostly your clients and customers will want a dependable site with dependable security that cannot be breached with ease. Many sites that have suffered attacks have never ever returned to their previous level of return because customers feel uneasy about using the site again knowing it was hacked.

 

Most site owners have slept less since the day their site was hacked because they lose the trust they once had that their site is secure.

 

Google quickly lists sites now too that have malware inserted, so even if you are fast in cleaning up, your customers are likely to discover that their favourite ecommerce site has been hacked and your site will suffer traffic loss and sales loss if they use Google to find your site.

 

The best that you can do is find a secure hosting service that runs the second method of shared hosting, and run secure site code and correct security configurations. Any other file examination code addons or cron initiated checks will only end up as a post mortem examination of a site that got hacked.

 

The rest is up to your webhost to have their shit together.

Share this post


Link to post
Share on other sites