Additional Security Suggestions

[AndrewMKP]

By denying all to the admin folder except certain IPs is that safe?

 

Anyone else have other security features to protect themselves?

 

Regards,

 

Andrew

[randy]

My 2 cents!

I would echo some of the other comments here. For security you should:

 

1. Install mod_security

 

i.e. see http://forums.cpanel.net/showthread.php?t=85813&highlight=gotroot

 

2. Rename your admin folder, then place the change in your configuration.php

 

i.e.

$customadminpath = "my_renamed_folder_name";

You can do this anytime, or change it if you need to, just rename the folder and then change the configuration.php.

 

3. Do not use admin for the login name use something else

 

4. Delete your install folder, do not just rename it

 

5. Delete any importing scripts if you imported from another software

 

6. Move your templates_c, attachments and download folder from you web accessible areas such as /home/username/public_html/whmcs_folder to /home/username since they have write permissions and /home/username generally does not, then add those to your configuration.php so they can be found. You can do this anytime, or change it if you need to, just rename the folder and then change the configuration.php.

 

i.e.

$templates_compiledir = "/home/username/templates_c/";

$attachments_dir = "/home/username/attachments/";

$downloads_dir = "/home/username/downloads/";

 

7. Place index.php files in all your folders where there is not an index.php (or use .htaccess to resrtict). We checked every folder in WHMCS that did not have an index file and added an index.php with the following contents.

 

<?php

header("Location: ../index.php");

?>

 

I think the stock/standard install of WHMCS should probably think about including these in the /whmcs_folder/templates /whmcs_folder/images etc....

 

8. Use a password you do not use in other places, it should also be a "strong password" you can use a password generator if needed. We use strong passwords for almost anything, if you were to read them in a dump of something they would just look like garbage. For help see http://strongpasswordgenerator.com/

 

9. You can use .htaccess to deny access to the TPL file or even the configuration files.

i.e.

http://forum.whmcs.com/showpost.php?p=81891&postcount=38

 

As for what is listed above in this link http://209.85.173.132/search?q=cache:YX_hrqs9xDIJ:www.h4cky0u.org/viewtopic.php%3Ff%3D12%26t%3D24283+whmcs+exploit&hl=en&ct=clnk&cd=17&gl=ca&client=firefox-a

I wonder if WHMCS should investigate this further.

 

Just all I can think of off the top of my head, feel free to add if you other ideals to make WHMCS more secure.

[simplybe]

Password protect the admin folder using htaccess. It means you require 2 logins but it adds an extra layer of protection. also means any new admin users would require the second set of logins from you to gain access.

[ivaserver]

Randy, Thanks for taking the time to post all the tips.

 

Best wishes

[randy]

Randy, changing the Admin folder, good idea, but when you update WHMCS (example, ver 4 to ver 5) how will this effect the update? That means I need to re-produce the steps each time there is an update.

 

You have version 4? Lol, yes I would assume so. I just switched from CE and from 3.71 to 3.72 there were no admin updates. But if there were I would rename the admin folder to what I have on the server before I uploaded, just assuming this would work. The long way would be to rename back to admin, edit the configuration.php update, then rename back to whatever I wanted, then reinsert the code into the configuration.php. I think either way should work.

 

Randy, Thanks for taking the time to post all the tips.

 

Best wishes

 

You are very welcome

[brianoz]

And while we're on the topic -

 

If anyone has any concerns about this, randy's post above (see #27) is about as good a summary as you can find on how to secure WHMCS effectively. We've followed every step and I'd say, whether or not there's an exploit in the wild, following his advice is good management and should keep you safe. Not following his advice is asking for trouble at some point down the track!

 

It's also worth saying - WHMCS's track record as far as security, up to and including this point, is pretty darn good, especially if decoded source is floating around. On the evidence so far, there's little reason for concern. However, if you haven't taken any of randy's steps, take them - better safe than sorry!

[randy]

And while we're on the topic -

 

If anyone has any concerns about this, randy's post above (see #27) is about as good a summary as you can find on how to secure WHMCS effectively. We've followed every step and I'd say, whether or not there's an exploit in the wild, following his advice is good management and should keep you safe. Not following his advice is asking for trouble at some point down the track!

 

It's also worth saying - WHMCS's track record as far as security, up to and including this point, is pretty darn good, especially if decoded source is floating around. On the evidence so far, there's little reason for concern. However, if you haven't taken any of randy's steps, take them - better safe than sorry!

 

Thanks, I do think phpsuexec is also an excellent suggestion (but I cannot edit my post to add it) and have used it with no side effects. We had a lot of issues with suphp, we would like to implement for a lot of reasons and will when we have time to fix all the scripts it breaks. Most of the errors are most likely because of directory permissions. SuHosin does a pretty good job but we had to relax the settings to the point we did not feel it was being effective and was block too many legitimate OsCommerce functions, we left it on simulation for a while and then decided to abondon it.

 

I should also mention if you change your admin area be sure you adjust your cron job to reflect the new name i.e. php -q /home/user/public_html/whmcs/newname/cron.php

[handsonwebhosting]

We use SuPHP on all our servers and don't have any issues at all. We regularly move customers from servers that were not setup on SuPHP before and here's the scripts you need to run from shell:

 

cd /directory/base

find . -type d -exec chmod 755 {} \;

find . -type f -exec chmod 644 {} \;

 

Basically you just move to the public_html folder for the client, then run the above. That will set the necessary permissions. SOME programs requrie 777 on LOG or UPLOAD folders to allow uploads through a browser, but beyond that you should be fine.

[randy]

Conor,

 

Appreciate that, I will give it a shot.

[brianoz]

SOME programs requrie 777 on LOG or UPLOAD folders to allow uploads through a browser, but beyond that you should be fine.

The whole point of suphp/phpsuexec is that the account already has write access. You definitely don't need 777 on any upload directories and having it partly defeats the purpose of suphp. Very occasionally an obstinate script will explicitly (and incorrectly) check for 777 and complain, but you don't see that often these days.

 

An alternative to the find commands is:

chmod -R go-w .

(removes write perms from group and other, leaving other permissions undisturbed)

[handsonwebhosting]

There's a number of scripts such as X-Cart, LiteCommerce, osCommerce, and some other shoppint cart software that require 777 permissions on the log folders in order for the user to be able to overwrite the files. When setting up a number of scripts you also need to have config.php files writeable for the configuration portion and then can set back to 644 once completed, but they will not fucntion without those permissions.

 

The command you gave is definitly faster Don't know why I've always used the find command

[brianoz]

There's a number of scripts such as X-Cart, LiteCommerce, osCommerce, and some other shoppint cart software that require 777 permissions on the log folders in order for the user to be able to overwrite the files. When setting up a number of scripts you also need to have config.php files writeable for the configuration portion and then can set back to 644 once completed, but they will not fucntion without those permissions.

Ah ... there's the common misconception! suphp actually runs as the user that owns the files and directories. That means that PHP always has write permission, and doesn't need mode 777 on config files or log directories - it already *has* write permission!

 

Unfortunately some less sophisticated script writers check for mode 777 explicitly, when they *should* rather be checking for actual write access, which may of course exist through them owning the file, which could be mode 644 or 755 or whatever. So, permission on the file or directory should never be changed when running under suphp. (in the very rare case the script writer checks for 777, you can comment out the check; usually they merely have the instructions wrong!)

[handsonwebhosting]

yep, it does run as the user, but I guarantee you that some programs will not work without 777 (but WHMCS does so no problems here) Possibly in the coding as you had mentioned. I know that every now and then I see files in the users folders set with "nobody" as the user (which is the apache username). So some are being written by the system.

 

I wish everyone used SuPHP as it makes it much easier for transferring files. It also makes tracking down spammers and people exploiting scripts (or system resources) so much easier.

[lostinspace]

Perhaps these files are pre-suPHP? One thing that will certainly break scripts after suPHP implementation is old files owned by "nobody". You should give the files within the html directory a mass chown according to their correct owner. This would definately explain the issues you're seeing with files still requiring 777.

[randy]

Perhaps these files are pre-suPHP? One thing that will certainly break scripts after suPHP implementation is old files owned by "nobody". You should give the files within the html directory a mass chown according to their correct owner. This would definately explain the issues you're seeing with files still requiring 777.

 

Stopping 777 filders obviously helps stop the hacking attacks, we had put it off for a long while and went ahead and switched over to SuPhp to increase security so we would not suffer the same fate as the thread starter, we followed some suggestions but when adding this there are three other things we had to do (Incase someone else wants to go this route) We are in a cPanel environment

 

After following the above suggestions like

find -perm 777 -exec chmod 755 {} \; -print

find -perm 666 -exec chmod 644 {} \; -print

 

We also found the below helps:

/scripts/postsuexecinstall

/scripts/chownpublichtmls

 

After all that we had some issues with several sites because they had some incompatible settings in thier .htaccess like:

php_value magic_quotes_gpc 0

Which will cause a server 500 error, so we had to delete those and create a php.ini file and put in:

magic_quotes_gpc = On

 

So anything in the .htaccess file that starts with php_value will not work. We wrote a script which basically was:

grep php_value /home/*/public_html/.htaccess >> /root/fixhtaccess.txt

grep php_value /home/*/public_html/*/.htaccess >> /root/fixhtaccess.txt

grep php_value /home/*/public_html/*/*/.htaccess >> /root/fixhtaccess.txt

 

I am not a big script writer so there might be another way to do that but it worked find for us. But after running we just looked at the /root/fixhtaccess.txt to be able to see the issues then manually update the .htaccess file and created a php.ini file for those customers. Out of 300+ accounts we only had to edit around 15 sites so it was fairly easy comparaed to the security we will now have. Then we created a KB for future accounts and anything we may have missed.

[brianoz]

Yes. once you switch to suphp, nobody-owned files are no longer created (unless you are talking about logfiles?). With suPHP all PHP processes run as the user, so there's no way a file owned by nobody could be created unless it's created by the apache httpd process (eg logfile etc).

[minadreapta]

yes, but how does this affects the server performance? it's working 2 times slower than without suphp...

 

there are other security measures you can take in order to keep the server performance up and have increased security.

 

suhosin maybe?

Edited December 5, 2008 by minadreapta

[boifromoz]

erm im having errors following these instructions in the first post using version 4.02 any ideas from anyone who has overcome these problems?

[ryleejames]

I know this is an older thread, but THANK YOU!! to all that have contributed to it.