suPHP and “Server Error”

At Hosting Marketers all our servers run on suPHP, this means that folders must be 755 and files 644 or even less, this blog post will explain why.

Hosting Marketers does not allow 777 on files which process server-side (i.e. PHP). However, many scripts require you to change your files to 777.

I can tell you that 755 will work in lieu of 777. You will not need to use 777 on PHP files or folders.

The concern is giving writable permissions to Group and World. This allows hackers from the world wide web to edit your files. Thus, the last two digits of file permissions should never be 2, 3, 6, or 7.

The problem is when you install a PHP script, the script needs permission to edit files. Traditionally, PHP is treated as ‘nobody’ on the server. Therefore, PHP is treated the same an any unknown visitor and must obey the permissions granted to World.

The solution to this conflict is to treat PHP as the Owner. Hosting Marketers has done so by implementing a special PHP security environment known as suPHP (or phpSuExec).

With suPHP, all PHP scripts are allowed the same permissions as the Owner, and outside visitors are still restricted by the World permissions. Therefore, 755 is the perfect number; it allows all actions for PHP and only reading/viewing for potential hackers.


If a server requires 777 permissions on folder in order for PHP to write to that folder, then your server is only as secure as the least secure account on that server.

If a server requires only 755 permissions for PHP uploads (i.e. with suPHP) then each account is on their own.

A couple of examples might illustrate this better.

Say a server has two accounts on it and that server is running PHP through Apache (i.e. no suPHP, 777 directories are required for PHP uploads). The two accounts are and is running a Gallery script, that requires the upload directory to have world-write enabled, permissions 777, but the owner of always keeps their Gallery script up-to-date and practices the best security policies. on the other hand, they don’t care about security. They are running an old WordPress install, and old Joomla script, and perhaps some other scripts that they never used and never updated or removed.

When gets hacked into because of the outdated scripts, those hackers may be able to place a PHP shell script onto the account, and they would then have access to write files into’s upload directory, the directory on that has 777 permissions.

This doesn’t seem quite fair, because was keeping their scripts up-to-date, yet their account was also being used in the exploit.

Now consider this same scenario where and are on a server running suPHP. still has the Gallery script, but because suPHP is in use, the upload directory for the Gallery script can survive with permissions of 755.

Now when gets hacked because of their old and outdated scripts, that hacker cannot upload anything onto the account because does not have any open directories. The hacker can go wild on the account, upload and delete anything they want. But the blame always goes back to the owner of, why wasn’t that person keeping their scripts up-to-date?

This is why, Hosting Marketers, on its servers always uses suPH!

Now an extra word of advice with suPHP. In the above example, I would recommend that keep their Gallery scripts config file set with a permissions setting of 600 or even 400. The reason being, if the config file (the file that contains that Gallery’s database login credentials) is using the default permission setting of 644, then the hacker from would still be able to read the config file (they would be able to READ any files that are set to 644 or above, just not write to them). This is why you should always create a MySQL username and password for accessing your MySQL databases, and NEVER use your main account username and password in your script’s configuration files for accessing MySQL databases. If you do use your main account username and password in the config file, and the config file has a permission setting of 644, then hackers from would still be able to read the config file, get your login information, and then FTP into your account.

what to do when your site is hacked or when you arrive at your site you see this warning: Reported Attack Page!

What to look for

The three most common forms of badware that StopBadware sees on compromised sites are:

1. Malicious scripts
2. .htaccess redirects
3. Hidden iframes

Malicious scripts

Malicious scripts are often used to redirect site visitors to a different website and/or load badware from another source. These scripts will often be injected by an attacker into the content of your web pages, or sometimes into other files on your server, such as images and PDFs. Sometimes, instead of injecting the entire script into your web pages, the attacker will only inject a pointer to a .js or other file that the attacker saves in a directory on your web server.

Many malicious scripts use obfuscation to make them more difficult for anti-virus scanners to detect:

Many malicious scripts use obfuscation to make them more difficult for anti-virus scanners to detect:

picture of obfuscated script

Some malicious scripts use names that look like theyre coming from legitimate sites (note the misspelling of analytics):

picture of deceptive script

.htaccess redirects

The Apache web server, which is used by many hosting providers, uses a hidden server file called .htaccess to configure certain access settings for directories on the website. Attackers will sometimes modify an existing .htaccess file on your web server or upload new .htaccess files to your web server containing instructions to redirect users to other websites, often ones that lead to badware downloads or fraudulent product sales.

picture of an htaccess redirect

Hidden iframes

An iframe is a section of a web page that loads content from another page or site. Attackers will often inject malicious iframes into a web page or other file on your server. Often, these iframes will be configured so they dont show up on the web page when someone visits the page, but the malicious content they are loading will still load, hidden from the visitors view.

picture of a hidden iframe injected in a web page

How to look for it

If your site was reported as a badware site by Google, you can use Googles Webmaster Tools to get more information about what was detected. This includes a sampling of pages on which the badware was detected and, using a Labs feature, possibly even a sample of the bad code that was found on your site. Certain information can also be found on the Google Diagnostics page, which can be found by replacing in the following URL with your own sites URL:

There exist several free and paid website scanning services on the Internet that can help you zero in on specific badware on your site. There are also tools that you can use on your web server and/or on a downloaded copy of the files from your website to search for specific text. StopBadware does not list or recommend such services, but the volunteers in our online community will be glad to point you to their favorites.
Removing the badware behavior

Once you have located the code that is causing the badware behavior, removing it is often as simple as deleting the offending code from all files in which it appears. Sometimes, it is easier, if you have a clean backup of your sites contents, to re-upload all of the sites files, though be careful about overwriting files that may have changed since your last backup. In some cases, the bad content may be stored in one or more database records, in which case restoring a recent backup of the database or manually editing the relevant records may be necessary.
Preventing future infection

Preventing badware on your website requires protecting three things: your site itself, the password(s) used to upload content to the site, and the computer(s) used to upload content to the site. The site itself must be protected because attackers often look for vulnerable software to exploit so they can modify your sites contents. The passwords are critical because, if they are guessed or stolen, they can be used to modify the site. Finally, computers are important because badware on your computer can steal your password and/or modify the contents that you are uploading.
Protect your site

* Ensure that any software you use (e.g., blogging software like WordPress, third party scripts, etc.) is kept up to date with the latest security fixes, either by you (if you installed the software) or by your hosting provider.
* Remove any scripts, services, or other software that you are no longer using.
* Change any default passwords that come with the software you are using.
* Use appropriate file permissions on your web server.

Protect your password

Use a strong password and change it occasionally, especially if you have reason to think it has been compromised.

If we Hosting Marketers contacted you because your site has been hacked we request you to take the following security measures:
Update your script to the latest version!

1) Scan your computer with a good anti virus for virus, Trojans and key-loggers, don’t type passwords, copy and paste.
2) Change the password for you control panel and ftp accounts, if possible change the password for your database as well.
3) Check for the file/folder permission in your control panel. File permissions should be set to 644 and folder permissions should be set to 755.
4) You can scan you Mail, Entire Home Directory, Public Web Space, Public FTP Space using Virus Scanner present in your control panel under Advanced section.

You can also add the below lines to your .htaccess file to protect a site against some of the most common vulnerabilities:

# prevent access from santy webworm a-e
RewriteCond %{QUERY_STRING} ^(.*)highlight=\%2527 [OR]
RewriteCond %{QUERY_STRING} ^(.*)echr(.*) [OR]
RewriteCond %{QUERY_STRING}% s:(.*)252echr [OR]
RewriteCond %{QUERY_STRING} ^(.*)esystem(.*) [OR]
RewriteCond %{QUERY_STRING} ^(.*)rush=\%65\%63\%68 [OR]
RewriteCond %{QUERY_STRING} ^(.*)rush=echo [OR]
RewriteCond %{QUERY_STRING} ^(.*)wget\%20 [OR]
RewriteCond %{QUERY_STRING}% s:(.*)wget
RewriteRule ^.*$ [R,L] 

# prevent pre php 4.3.10 bug
RewriteCond %{HTTP_COOKIE}% s:(.*):\%22test1\%22\%3b
RewriteRule ^.*$ [R,L]  

# this ruleset is to "stop" stupid attempts to use MS IIS Web Server expolits on us
RewriteCond %{REQUEST_URI} /(admin|cmd|httpodbc|nsiislog|root|shell)\.(dll|exe) [NC]
RewriteRule .* - [F,L]

RewriteCond %{REQUEST_URI} /default\.(ida|idq)$ [NC,OR]
RewriteCond %{REQUEST_URI} /.*\.printer$ [NC]
RewriteRule .* - [F,L]

# IE's "make available offline" mode
RewriteCond %{HTTP_USER_AGENT} MSIECrawler [OR]

# unknown bot
RewriteCond %{HTTP_USER_AGENT} ^NG [OR]

# You may want to enable these lines below to disallow php and perl scripts to access your site
 RewriteCond %{HTTP_USER_AGENT} ^.*PHP.*$ [OR]
 RewriteCond %{HTTP_USER_AGENT} ^.*libwww-perl [NC,OR]

# Ignorant user trying to edit my site
RewriteCond %{HTTP_USER_AGENT} FrontPage [OR]
#this one will ban everything microsoft. Use with caution.
RewriteCond %{HTTP_USER_AGENT} ^(Microsoft|MFC).(Data|URL|WebDAV|Foundation).(Access|Control|MiniRedir|Class) [NC,OR]

# MSOffice
RewriteCond %{REQUEST_URI} ^/(MSOffice|_vti) [NC,OR]

# Various
RewriteCond %{REQUEST_URI} ^/(bin/|cgi/|cgi\-local/|cgi\-bin/|sumthin) [NC,OR]
RewriteCond %{THE_REQUEST} ^GET\ http [NC,OR]
RewriteCond %{REQUEST_URI} /sensepost\.exe [NC,OR]

# Cyveillance is a spybot that scours the web for copyright violations and ?damaging information? on
# behalf of clients such as the RIAA and MPAA. Their robot spoofs its User-Agent to look like Internet
# Explorer, and it completely ignores robots.txt. I have
# banned it by IP address.
RewriteCond %{REMOTE_ADDR} ^63\.148\.99\.2(2[4-9]|[34][0-9]|5[0-5])$ [OR]
RewriteCond %{REMOTE_ADDR} ^63\.226\.3[34]\. [OR]
RewriteCond %{REMOTE_ADDR} ^63\.212\.171\.161$ [OR]
RewriteCond %{REMOTE_ADDR} ^65\.118\.41\.(19[2-9]|2[01][0-9]|22[0-3])$ [OR]

# NameProtect peddles their ?online brand monitoring? to unsuspecting and gullible companies
# looking for people to sue. Despite the claims on their robot information page, they do not
# respect robots.txt; in fact, they spoof their User-Agent in multiple ways to avoid detection.
# I have banned them by User-Agent and IP address.
RewriteCond %{REMOTE_ADDR} ^12\.148\.196\.(12[8-9]|1[3-9][0-9]|2[0-4][0-9]|25[0-5])$ [OR]
RewriteCond %{REMOTE_ADDR} ^12\.148\.209\.(19[2-9]|2[0-4][0-9]|25[0-5])$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^NPBot	[NC,OR]

# Web Content International
RewriteCond %{REMOTE_ADDR} ^65\.102\.12\.2(2[4-9]|3[01])$ [OR]
RewriteCond %{REMOTE_ADDR} ^65\.102\.17\.(3[2-9]|[4-6][0-9]|7[01]|8[89]|9[0-5]|10[4-9]|11[01])$ [OR]
RewriteCond %{REMOTE_ADDR} ^65\.102\.23\.1(5[2-9]|6[0-7])$ [OR]

# dumb bot
RewriteCond %{HTTP_USER_AGENT} "^Mozilla/4.0$" [OR]

# Wordtracker
RewriteCond %{REMOTE_ADDR} ^128\.242\.197\.101$ [OR]

# Unknown
RewriteCond %{REMOTE_ADDR} ^64\.156\.198\.(6[89]|7[0-9]|80)$ [OR]

RewriteCond %{REMOTE_ADDR} ^65\.223\.250\.25[0-3]$ [OR]

# Turnitin spybot
RewriteCond %{REMOTE_ADDR} ^64\.140\.49\.6([6-9])$ [OR]
RewriteCond %{HTTP_USER_AGENT} TurnitinBot [OR]

# this ruleset is for formmail script abusers...
# we don't use Perl for Postnuke so this is not really needed.
RewriteCond %{REQUEST_URI} (mail.?form|form|form.?mail|mail|mailto)\.(cgi|exe|pl)$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*FileHound.*$
RewriteRule .* - [F,L]

# dumb bot
RewriteCond %{HTTP_USER_AGENT} "^Mozilla/3.0$"
RewriteRule .* - [F,L]

<FILES .htaccess>
order allow,deny
deny from all