WHAT IS PCI COMPLIANCE

PCI (Payment Card Industry) data security standards provide a set of general rules and practices that ensure the security of credit card data, when a credit card is used for purchasing goods and services. PCI standards are to be followed by companies that store and process credit card data.

When a website accepts and stores credit card data, the credit card processing company requires the server and the site software to be PCI compliant. Such status is obtained through companies that provide PCI compliance certification. Usually, the certification company will run a PCI scan on the site/server to make sure that it is compliant.

DISCLAIMER ON OBTAINING PCI COMPLIANT STATUS FOR SITES ON OUR SERVERS

If you want to obtain a PCI DSS certification for a website that runs on our servers, you should have in mind the following before you purchase the certification service:

1. In general, shared hosting services are not meant to provide PCI compliance. Therefore, we cannot give a guarantee that your site will be able to pass a PCI scan. The types of scan differ through different companies, and while most of the scans can be passed, it is possible some certification companies to have requirements that cannot be fulfilled. This is due to the nature of the shared hosting service with more than one customer on the server.

2. Additional services on our side, such as specific port blocking, may be available only on some of our hosting plans.

COMMON STEPS YOU CAN TAKE BEFORE RUNNING A PCI SCAN

The list below include the most common items that could appear in a PCI scan report as failed. You can take these steps prior to running the PCI scan, or simply have the scan run, and then fix the “failed” points in it.

Obtain a personal certificate for your domain

The default certificate on our servers is issued to the server name. Therefore, if you want your site to be accessed over https:// without raising warnings, you need to obtain a personal certificate for your domain, and it should be installed on the server on a dedicated IP address. You can contact your hosting provider for assistance in obtaining and/or installing an SSL certificate on a dedicated IP. You will not be able to pass a PCI scan without having a personal certificate and a separate IP address for your domain.

Force HTTPS on statistics folders (http://yourdomain.com/stats)

PCI compliance usually requires all parts of your website to be accessible through HTTPS. As the statistics folder is a system one, and it is not a part of your website, forcing HTTPS over it is done separately from the site. You can force HTTPS connection to your statistics page through the hosting Control Panel’s Site Statistics section.

Disable directory listing

Some PCI scans will require the directory listing for your website to be blocked, so that files are not visible if an index page is not present in some directory. Directory listing can be disabled for your site at the hosting Control Panel > Protection section -> Web access protection subsection. There, you need to click on the Disable button under Directory listing for the folder in which your website is (usually, /www/www)

Maintaining the website software

While we maintain the server software and are responsible for its security, it is a responsibility of the customer to run secure software on their website. PCI scans also test your website for SQL injections, cross scripting vulnerabilities, remote inclusion vulnerabilities, etc. If any such issues arise, they must be fixed by the developer of your website.

Additional port blocking / firewall protection

Most companies that provide PCI compliance certification require the server to have open ports only for the web service (ports 80 and 443), and not to have open ports for FTP, SMTP, SSH, MySQL, etc. This can be achieved on our servers by adding firewall rules so that only ports 80 and 443 are open.

To have this feature enabled:

• Your site must have a separate IP address. You will have such if you have a personal SSL certificate installed on your domain.
• You should perform certain DNS modifications before enabling the port blocking, so that your mail services continue to work.
• Your hosting plan must include this feature. You can contact our support team for more details on this.

Once the feature is enabled, your email, FTP, and remote MySQL services will be available only on the server default IP address, and not on your domain IP address.

DNS modifications

The DNS modifications you need to make are meant to point the MX record for your domain to the default server IP address. This will ensure that your email services will continue to work when the ports on your domain IP address are blocked. If your domain uses our DNS service, the modifications are to be made through the DNS Manager section of the hosting Control Panel. In general, if the MX record for your domain is mail.domain.com, the A record for mail.domain.com must be pointed to the default IP address of the server. Then, you need to allow at least several hours for DNS propagation, prior to enabling the port blocking.

If your domain uses a third-party DNS service, you need to make the required DNS changes there.

Enabling port blocking

The additional port blocking can be enabled only by our system administrators. You can contact our support team for assistance. We will check whether your DNS records are set properly, and will have the feature enabled.

Mail, FTP, MySQL, and SSH services with port blocking enabled

You must have in mind that with enabled port blocking, all services except the HTTP/HTTPS service will be available only at the server IP address/hostname. Therefore, you should modify your email programs to connect to mail.your_server.com instead of mail.domain.com. The same is valid for FTP/MySQL/SSH programs – use the server name to connect to the server instead of your domain name.

The meanings of these error codes from the web server are:

• 401 Authorization Required
  
  This error message indicates that a website visitor tried to access a password protected page without authenticating (with valid username and password).
  
  

• 403 Forbidden
  
  This error code means that access to the page the visitor is requesting is not allowed. This can be due to a special rule in the configuration of the web server, or to the specific file system permissions of the file. An example rule in an .htaccess file that would cause this message is this:
  
  

  deny from 1.2.3.4

  
  Where 1.2.3.4 is the IP address of the visitor.
  
  This error can also be caused by the file lacking read permissions. In that case, the web server will not be able to read the file, and this error message would be displayed.
  
  

• 404 Not Found
  
  This simply means that the requested file is not there.
  
  

• 412 Precondition Failed
  
  The error means that the request triggered a mod_security protection on our end. You can learn more on this matter in the Error “412 Precondition Failed” (mod_security2) article.
  
  

• 500 Internal Server Error
  
  This can be the most confusing error message, because it can be caused by many things ranging from server and permission problems to application errors and misconfigurations. Information about the actual error message is recorded in the server’s error log. Please contact our support team if you need information from the error log of the web server.

To deliver outstanding performance and uptime, our servers are built with the most reliable server components that can meet even the greatest expectations.

Each shared hosting server is equipped with two multi-core (up to 18 cores) Xeon processors, up to 256 GB DDR4 RAM, and multi-terabyte SSD RAID 6 storage arrays.

We use RAID 6 because it offers the best combination of performance and reliability. Performance is the same as RAID 5, and stored data is protected even if two drives in the array fail simultaneously.

All storage drives, power supply units, and cooling fans are hot-swappable, allowing replacements on the fly. This mitigates the impact of possible hardware failures to the absolute minimum.

Redundant power on the premises, multiple backup generators, and a redundant network of multiple fiber trunks from multiple sources ensure the highest levels of connectivity and reliability.

Our servers are running а highly customized 64-bit version of Debian GNU/Linux with the Apache web server, MySQL (MyISAM and InnoDB), PHP, Python, Perl, Ruby, and Tcl available. You can find the full list of software installed on the server in the hosting Control Panel -> System Information section.

If you see a WebApps section in your hosting Control Panel, you can install runtime environments like Django, Node.js, Flask, Ghost, Ruby on Rails, and run MongoDB or PostgreSQL instances. In the WebApps/Node.js category of our online documentation, you can find step-by-step instructions on how to install some of these web applications. You can contact your hosting provider for more information if you would like to take advantage of the web application support on our servers, but you do not see the WebApps section in your hosting Control Panel.

All our servers are running a highly customized 64-bit version of Debian GNU/Linux with the Apache web server.

The server-side scripting languages supported on our hosting platform are PHP, Python, Perl, Ruby, and Tcl.

Our database server solution is MySQL (both the MyISAM and InnoDB storage engines are supported). You can find more information on the versions of the installed server-side scripting languages and MySQL in the hosting Control Panel -> System Information section.

Hosting accounts with a WebApps section in the hosting Control Panel can deploy projects using custom runtime environments (e.g., Node.js, Python WSGI applications, etc.). Examples can be found in the WebApps/Node.js category of our online documentation. If you do not see a WebApps section in the hosting Control Panel, contact your hosting provider for more information.

You can view the Apache access and error logs in near real time using the Logs -> Live HTTP Logs section of the hosting control panel. The logs might be provided with a slight delay. When you open the interface for the first time after logging in to the Control panel, live logs for your account are enabled within one minute. Live logs will be disabled six hours after you close the interface, and will be enabled again when you open the interface again.

The raw Apache access logs, as well as the FTP access logs for the account, are available in the /home/$USER/logs folder on the server. This folder is accessible through the File Manager of the hosting Control panel, and through FTP.

To access the logs folder with the File Manager and download log files over HTTP, you need to:

1. Open your hosting Control Panel, and go to the File Manager.
2. Click on the .. link to go to the upper folder. You might have to click it a second time, to reach the /home/$USER/ folder.
3. Click on the logs folder. You will see a directory structure with the available log files for your account, a subfolder for each separate month. You can locate the file(s) you need, and download it by clicking on it.

To download log files over FTP, you need to log in to your account via FTP and change the working directory to /logs (make sure that you include the leading slash). You will find the logs in that directory. Note that you must use your main FTP user.

We also provide log analysis tools that are readily available with your hosting account. You can access them on the Site Statistics page of the Control Panel.

For information on viewing the error log, as well as the access log, of the web server in near real time, please refer to the Live HTTP Logs article. 

The mail logs are not available for download; however, you can search for incoming and outgoing messages for your hosting account’s mailboxes via the Online Manual -> Control Panel -> Logs section. More details on how to search for specific messages are available in our Searching for messages in the mail server logs article.

You can search the mail server logs on the Logs -> Mail logs section of the hosting Control Panel. The mail server logs contain information about all email messages delivered by our servers.

There is more information about the format of the logs in our Mail Logs Format article.

Mod_deflate is a module for the Apache Web Server. Its purpose is to make a better use of the available bandwidth by compressing content delivered from the web server to the client’s browser. The compression is automatic, and the only requirement is that the browser supports gzip compression. Nowadays, most of the browsers support gzip, and no additional software is required.

• How is the compression performed?

The browser will announce if the compression method is supported when sending a request to the server for a specific file, for instance, http://www.example_domain.com/index.html. In case Apache is configured with mod_deflate, the content of index.html will be compressed and sent to the browser. The browser, on the other hand will decompress the gzip file and will display it to the client as a simple html file. The web visitor would not be aware of the above operations.

• How can I use mod_deflate?

To set up mod_deflate, you have to create a .htaccess file (note the dot(“.”) at the beginning of the file) with the following code in it:

<IfModule deflate_module>
AddOutputFilterByType DEFLATE text/css text/csv text/html text/plain text/richtext text/sgml text/tab-separated-values application/javascript application/x-javascript httpd/unix-directory
AddOutputFilter DEFLATE html htm shtml php php4 pl rb py cgi css js txt
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>
Then save the .htaccess file to the directory where you want mod_deflate enabled. Have in mind that .htaccess files work recursively, so it will have effect on all the subdirectories as well.

The .htaccess file above will have mod_deflate enabled for all HTML, SSI,PHP, Perl, Ruby, Python, CGI, Cascading Style Sheets, JavaScript and text files.

Mod_gzip is a module for the Apache 1.3 web server. As we do not use Apache 1.3 on our servers, it is not available with our service. We are using Apache 2. In Apache 2, the functionality of mod_gzip is covered by the mod_deflate module. You can check this article for more information on using mod_deflate: Using mod_deflate.

Mod_speling is a module for the Apache Web Server. Its purpose is to attempt to correct mistaken URLs or various misspellings. It does that by ignoring capitalization. The Linux filesystem is case-sensitive by default, and mod_speling can help you overcome issues with the naming of your files. You may run into such issues when transferring your website over from a Windows-based server, or when publishing website content built on a Windows-based application. 

• How can I use mod_speling?

To enable mod_speling, you have to create a .htaccess file (note the dot(“.”) at the beginning of the file) with the following code in it:

<IfModule mod_speling.c>
CheckSpelling on
CheckCaseOnly on
</IfModule>

Then save the .htaccess file in the directory where you want mod_speling enabled. Have in mind that .htaccess files work recursively, so it will have effect on all the subdirectories as well.

Mod_brotli is a module for the Apache Web Server. It uses the brotli compression format to compress data sent from the server to the client over the network. The compression is automatic, and the only requirement is that the browser supports brotli compression. Modern browsers support brotli, and no additional software is required.

• How is the compression performed?

The browser will announce if the compression method is supported when sending a request to the server for a specific file, such as http://www.example_domain.com/index.html. If Apache is configured with mod_brotli, the content of index.html will be compressed and sent to the browser. The browser, on the other hand, will decompress the file and will display it to the client as a simple HTML file. The web visitor would not be aware of the above operations.

• How can I use mod_brotli?

To set up mod_brotli, you have to create a .htaccess file (note the dot (“.”) symbol at the beginning of the file) with the following code in it:

<IfModule brotli_module>
AddOutputFilterByType BROTLI_COMPRESS text/css text/csv text/html text/plain text/richtext text/sgml text/tab-separated-values application/javascript application/x-javascript httpd/unix-directory
</IfModule>

Then save the .htaccess file in the directory where you want mod_brotli enabled. Have in mind that .htaccess files work recursively, so it will have effect on all the subdirectories as well.

The .htaccess code above will enable mod_brotli for all HTML, SSI, PHP, Perl, Ruby, Python, CGI, Cascading Style Sheets, JavaScript, and text files.

What is an .ftpaccess file?

.ftpaccess files allow you to alter the default FTP server configuration settings. The name of the file begins with a dot (.) symbol. You can create .ftpaccess files via the File Manager section of the hosting Control Panel.

If you wish to edit an .ftpaccess file with a text editor of your choice, you can download the file via an FTP client. You can find step-by-step instructions on how to set up the most popular FTP clients in the Uploading files category from our online documentation. Some FTP clients do not show configuration/hidden files (starting with a dot (.) symbol) by default, so please refer to the official documentation of your FTP client of choice for instructions on how to show/display hidden files.

The .ftpaccess Limit directive

You can use the Limit directive in .ftpaccess files to limit access to a specific or a group of FTP commands in a particular directory. If you wish to limit access to specific FTP commands in multiple directories/subdirectories, you need to add an .ftpaccess file to each directory/subdirectory as .ftpaccess files do not work recursively.

A list of the command groups and the most widely used FTP commands with a brief overview is available below:

• ALL includes the READ, WRITE, and DIRS command groups (all FTP commands). This command group has the lowest precedence, so if there is a Limit directive configured for a command or command group, the ALL command group limit will not have any effect.
• READ includes the following FTP commands related to file reading (directory reading FTP commands are not included in this command group):
  • RETR (RETRieve) allows the FTP client to download files from the server.
  • SITE CHMOD (CHange MODe) allows the FTP client to change file/directory permissions.
  • SIZE allows the FTP client to view file size information.
  • STAT (STATus) allows the FTP client to view the FTP server/connection status.
• WRITE includes the following FTP commands used for writing, creating, and deleting files/directories:
  • APPE (APPEnd) allows the FTP client to append the content of one file to another.
  • DELE (DELEte) allows the FTP client to delete a file/directory.
  • MKD/XMKD (MaKe Directory) allows the FTP client to create a new directory.
  • RMD/XRMD (ReMove Directory) allows the FTP client to remove a directory.
  • RNTO (ReName TO) allows the FTP client to rename a file/directory. This FTP command is used in combination with the RNFR FTP command.
  • STOR (STORe) allows the FTP client to upload files to the server.
• DIRS includes the following FTP commands associated with directory listing:
  • CDUP/XCUP (Change Directory UP) allows the FTP client to navigate up one directory level.
  • CWD/XCWD (Change Working Directory) allows the FTP client to change the current working directory.
  • LIST/NLST (LIST/Name LiST) allows the FTP client to list the files in a directory.
  • MDTM (MoDification TiMe) allows the FTP client to view the date when a file was last modified.
  • PWD/XPWD (Print Working Directory) allows the FTP client to display the current working directory.
  • RNFR (ReName FRom) allows the FTP client to rename a file/directory. This FTP command is used in combination with the RNTO FTP command.

More details about the Limit directive are available in the official ProFTPD documentation.

Protecting .ftpaccess files

By default, configuration files (starting with a dot (.) symbol) are visible for all FTP users. This includes .ftpaccess files. We would recommend that you add the following code block at the beginning of your .ftpaccess files to allow only specific FTP users to view and manage your configuration files:

HideFiles (\.ftpaccess|\.htaccess|\.htpasswd)$ user !alloweduser
IgnoreHidden on

Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to each directory where you wish the custom FTP configuration to take effect.

For increased security, and to prevent public access (over HTTP) to your .ftpaccess files, we would recommend that you change their permissions to 0600 via the File Manager in your hosting Control Panel.

Examples

You can find examples for the most common uses of .ftpacess files listed below:

1. Blocking FTP access
   • from specific IP addresses/networks
   • from everywhere
   • from everywhere except for specific IP addresses/networks
2. Restricting file and directory deletion
3. Restricting file uploads and directory creation
   • for everyone except for specific FTP users
   • mixed setup
4. Allowing only file uploads
5. Restricting access to specific FTP users
6. Allowing access only to specific FTP users
7. Allowing file deletion only from specific IP addresses/networks
8. Restricting file/directory permission changes to specific FTP users

1. Blocking FTP access

• from specific IP addresses/networks

  To block FTP access to a directory from specific IP addresses (e.g. 1.2.3.4) and networks (e.g. all IP addresses starting with 5.6.7), add the following code block to an .ftpaccess file in that directory:

  Order allow,deny
  Deny from 1.2.3.4
  Deny from 5.6.7.
  

  Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect.

• from everywhere

  You can completely block FTP access to a directory by adding the following code block to an .ftpaccess file in that directory:

  Order allow,deny
  Deny from all
  

  Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect.

• from everywhere except for specific IP addresses/networks

  If you wish to block FTP access to a directory for everyone except for specific IP addresses (e.g. 1.2.3.4) and networks (e.g. all IP addresses starting with 5.6.7), add the following code block to an .ftpaccess file in that directory:

  Order allow,deny
  Allow from 1.2.3.4
  Allow from 5.6.7.
  Deny from all
  

  Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect.

2. Restricting file and directory deletion

You can prevent the deletion of files and directories in a directory for all FTP users except for one (e.g. allowed_user) by adding the following code block to an .ftpaccess file in that directory:

AllowUser allowed_user
DenyAll

Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect.

3. Restricting file uploads and directory creation

• for everyone except for specific FTP users

  If you wish to allow all FTP users to view the contents of the current directory, but prevent file uploads and directory creation for all except two FTP users (e.g. allowed_user_1 and allowed_user_2), you should add the following code block to an .ftpaccess file in that directory:

  AllowUser allowed_user_1,allowed_user_2
  DenyAll
  
  Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect.

• mixed setup

  You can assign FTP access to different commands for different FTP users allowing you to configure custom configurations like the following:
  – one user (e.g. allowed_user_1) with access to file reading and directory listing without writing access
  – another user (e.g. allowed_user_2) without access to file reading but with directory listing and file/directory uploading access
  – third user (e.g. allowed_user_3) with full access

  Add the following code block to an .ftpaccess in the directory where you wish to achieve the setup listed above:

  AllowUser allowed_user_1,allowed_user_3
  DenyAll
  

  AllowUser alloweduser_2,allowed_user_3
  DenyAll
  

  Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect.

4. Allowing only file uploads

To prevent file reading and directory listing access and allow file uploads to a directory for all FTP users (overwriting of existing files will be possible), add the following code block to an .ftpaccess file in that directory:

DenyAll

AllowAll
AllowAll

Important: The directory containing the .ftpaccess file will not be visible so, to access it, you will need to establish a connection directly to it by either of the following:

• Entering the path to the directory containing the .ftpaccess file manually in your FTP client.
• Configuring the directory containing the .ftpaccess file as the default remote directory in your FTP client.
• Setting the directory containing the .ftpaccess file as the (root) Directory for the FTP users via the FTP Manager section of the hosting Control Panel. You can find more details about this section in our FTP Manager article.

Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect.

5. Restricting access to specific FTP users

You can prevent access to a directory for specific FTP users (e.g. restricted_user_1 and restricted_user_2) by adding the following code block to an .ftpaccess file in that directory:

DenyUser restricted_user_1,restricted_user_2

Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect.

6. Allowing access only to specific FTP users

To grant access to a directory only for specific FTP users (e.g. allowed_user_1 and allowed_user_2), you should add the following code block to an .ftpaccess file in that directory:

AllowUser allowed_user_1,allowed_user_2
DenyAll

Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect.

7. Allowing file deletion only from specific IP addresses/networks

Should you wish to allow the deletion of files in a directory only from specific IP addresses (e.g. 1.2.3.4) and networks (e.g. all IP addresses starting with 5.6.7), add the following code block to an .ftpaccess file in that directory:

Allow from 1.2.3.4
Allow from 5.6.7.
DenyAll

Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect.

8. Restricting file/directory permission changes to specific FTP users

You can grant access for changing file and directory permissions in a specific folder only to specific FTP users (e.g. allowed_user_1 and allowed_user_2) by adding the following code block in an .ftpaccess file in that directory:

AllowUser allowed_user_1,allowed_user_2
DenyAll

The FTP users (allowed_user_1 and allowed_user_2) will be able to change the permissions of files and folders that they own, while all other FTP users will be unable to change the permissions of any files and folders (even if they own them).

Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect.

To properly enable FastCGI+OPcache, in the instructions below, you need to replace:

USERNAME with your actual hosting account username (you can find your username listed in the upper left corner of your Control Panel)

FastCGI is a way to accelerate frequently accessed pages on the site. FastCGI works in a way that a single process can handle many requests before being terminated. This reduces the overhead of starting a new PHP process every time there is a new page request. It also allows OPcache to work – it caches precompiled script bytecode, thus PHP does not need to compile bytecode again and again of the same PHP scripts. FastCGI with OPcache is the fastest solution for processing a lot of requests and boosting your website’s overall performance.

For accounts with FastCGI support, you can enable the technology for your main website (www.domain.com) in three simple steps:

Step 1)

Create the /home/USERNAME/www/www/.ht-fcgi-php-wrapper file through the “File Manager” section in your hosting Control Panel. Please make sure the file has executable permissions (we recommend that you set its permissions to 775). The file should contain the following code:

#!/bin/bash

# memory limit in kbytes
ulimit -v 573440

# do not lower this limit or you may start getting sporadic 500 server errors
export PHP_FCGI_MAX_REQUESTS=10000

# disable PHP child process management
export PHP_FCGI_CHILDREN=0

exec /usr/local/bin/php74.cgi -c /home/USERNAME/www/www/php.ini

Note: If the /home/USERNAME/www/www/php.ini file does not exist, you should create it using the hosting Control Panel -> “File Manager” section and add the default content of php.ini files on our servers to it for compatibility reasons.

In this first step, it is important to note that you choose the PHP version on which the code will be running by specifying the path to the CGI script (i.e. php74.cgi). This is done in the last line of the above-mentioned piece of code.

You can choose from the following options, depending on the preferred PHP version:

PHP 7.4 (recommended):

exec /usr/local/bin/php74.cgi -c /home/USERNAME/www/www/php.ini

PHP 7.3:

exec /usr/local/bin/php73.cgi -c /home/USERNAME/www/www/php.ini

PHP 7.2:

exec /usr/local/bin/php72.cgi -c /home/USERNAME/www/www/php.ini

PHP 7.1:

exec /usr/local/bin/php71.cgi -c /home/USERNAME/www/www/php.ini

PHP 5.6 (obsolete):

exec /usr/local/bin/php56.cgi -c /home/USERNAME/www/www/php.ini

PHP 5.3 (obsolete):

exec /usr/local/bin/php53.cgi -c /home/USERNAME/www/www/php.ini

Note: Make sure to replace USERNAME with your hosting account username, which is listed under the information panel in the upper left corner of your hosting Control Panel.

Step 2)

Create an /home/USERNAME/www/www/.htaccess file and add the following code to it, or add the code to your existing .htaccess file:

<FilesMatch "\.php$">
AddHandler fcgid-script .php
FcgidWrapper /home/USERNAME/www/www/.ht-fcgi-php-wrapper .php

Note: Make sure to replace USERNAME with your hosting account username, which is listed under the information panel in the upper left corner of your hosting Control Panel. Also, check your .htaccess file for other AddHandler directives and comment/delete them.

Step 3)

Enable OPcache by adding the following piece of code to the main php.ini file for your website via the “PHP Settings” section in your hosting Control Panel:

;Enabling OPcache
[opcache]
zend_extension = opcache.so
opcache.enable = 1
opcache.memory_consumption = 128
opcache.max_accelerated_files = 10000
opcache.revalidate_freq = 60

Note: If you want to enable FastCGI for a subdomain (example.domain.com), you need to create the /home/USERNAME/www/example/.ht-fcgi-php-wrapper file, update the last line in it to use the subdomain’s php.ini file (e.g. /home/USERNAME/www/example/php.ini), and create or edit the file /home/USERNAME/www/example/.htaccess. The path to .ht-fcgi-php-wrapper specified in your .htaccess file should also be correct.

In case you are experiencing any difficulties with FastCGI, you can contact our support team for assistance.

Mod_security2 is an Apache2 module which blocks requests to the web server based on a list of server-side rules, also known as a Web Application Firewall (WAF). Rules include blocks against common server attacks, and they filter requests to vulnerable software. This additional security feature is activated by default on our servers in order to provide maximum protection from hacker attacks for the websites of our customers. However, it is possible for certain legitimate requests/scripts to match a rule and be blocked. When this happens, the error message returned by the server is 412 Request Blocked (Precondition failed). You can disable certain blocking rules, or completely disable mod_security2, by using an .htaccess file.

Disabling mod_security2 for XML-RPC files

The XML-RPC protocol is used by some WordPress modules to communicate with external resources, most notably – the Jetpack plugin and the official WordPress mobile apps. All Jetpack IP addresses are whitelisted on our servers, so you do not need to disable mod_security2 to use the Jetpack plugin. To read more on how to allow access to this file through the WordPress section of the Control Panel, please check our Enabling access to XML-RPC article.

If your website is using an xmlrpc.php file, but it is not WordPress-based, you can still disable mod_security2 for it with an .htaccess file – it should contain the following piece of code:

SecRuleRemoveById 114

The .htaccess file can be easily created using the File Manager in the hosting Control Panel. The settings in this file apply to the directory in which it is located and recursively to its subdirectories.

Finding which mod_security2 rule triggers error 412

If you encounter an error 412 when browsing a specific page, you can easily find which mod_security2 rule triggers the error by inspecting the server error logs for your website. Here is how to do this:

1. Navigate to the hosting Control Panel > Logs section > Live HTTP logs subsection.
2. Allow about a minute for the Live HTTP logs subsection to start displaying the logs in near real time.
3. Open the page of your website where you get the 412 error.
4. Check the Error log screen from the Live HTTP logs subsection, where you should find an entry like this one:

   example.com [Fri Aug 13 14:46:30 2021] [error] [pid 9179] apache2_util.c(273): [client YOUR_IP_ADDRESS:59893] [client YOUR_IP_ADDRESS] ModSecurity: Access denied with code 412 (phase 2). Match of “ipMatchFromFile /apache/conf/includes/mod-security-jetpack-ip-whitelist.txt” against “REMOTE_ADDR” required. [file “/apache/conf/includes/mod_security2.conf”] [line “42”] [id “114”] [hostname “example.com”] [uri “/xmlrpc.php”] [unique_id “YRZblp0P33pV7fcztwccfAAAAQE”]

The exact mod_security2 rule and file that trigger the error will be listed in the id and uri fields in the error message. The Match part of the mod_security2 message will contain more information about the triggered security rule. In the given example, access to the xmlrpc.php file was blocked by the mod_security2 rule with id 114 as access to the file is allowed only from JetPack IP addresses.

Disabling a specific rule

By default, a number of abusive bots are blocked from visiting customer websites with specific mod_security2 rules. These are the currently blocked bots, as well as their mod_security2 IDs:

“Havij” id:350
“^BOT/0.1” id:354
“^Mozilla\/4\.0 \(compatible; MSIE 6\.0; Windows NT 5\.1;?( SV1)?;?\)$” id:373
“^Mozilla\/3\.0 \(compatible; Indy Library\)$” id:392
“sqlmap” id:398
“DatabaseDriverMysql” “id:401”
“BUbiNG” id:406
“MauiBot” id:407
“MJ12bot” id:408
“BLEXBot” id:409
“DotBot” id:410
“MegaIndex” id:412

If you need to allow any of the above bots to access your website, you can disable the specific mod_security2 rule with an .htaccess file in the main folder of your website. Just use the SecRuleRemoveById directive followed by the ID of the specific rule. For example, to allow access to your website from the DotBot bot (which is blocked in mod_security2 with rule ID 410), you should add this code to your website’s .htaccess file:

SecRuleRemoveById 410

Disabling mod_security2 altogether

Completely disabling the mod_security2 module would decrease the security of your website considerably, so we strongly advise against doing that. Instead, follow the steps above to check the logs and find which mod_security2 rule blocks the execution of your script, then disable the specific rule.

If you are certain about disabling the mod_security2 module, you can create an .htaccess file (or edit the existing one) in the directory where you want to disable it. The file should contain the following piece of code:

SecRuleEngine Off
SecRequestBodyAccess Off

• Default IP address
• Third-party DNS services
• IP address changes on the server
  
  

Default IP address

The primary IP address of the hosting server is displayed on the left pane of the hosting Control Panel, section IP addresses:

The primary server IP address is used:

• for outgoing email. As such, if you are using our email server for outgoing email, then any SPF records for the domain should include the primary server IP address as well.
• for outgoing connections from the server. If you are using software on your account to connect to remote services, and these services are restricted by IP address, you might have to whitelist it.
• if your account does not have any additional IP addresses assigned, then your domain’s A records will be pointed to this IP address.

In some cases, your account may have additional IP addresses assigned to it – for example, if you have purchased a dedicated IP address for an SSL installation.

The account IP address is the (default) IP address to which your domain names should resolve to. That’s why, DNS records for the domains on the account should be pointed to this IP address. If the domain is using our DNS service, then its DNS records are controlled from the DNS Manager in the hosting Control Panel. If more than one IP address is assigned to your account (eg. for multiple SSL installations), one of the IP addresses will be marked as “default”. This is the IP address to which all DNS records will be pointed to, in case you use the option “Restore default configuration” on the DNS Manager page.

Third-party DNS services

If your domain is using a DNS service not maintained by us, you should remember:

• your domain should be pointed to the default account IP address, if such is assigned. If not, it should point to the primary server IP address.
• if your domain has an SPF record, and our server is used for outgoing email, then the SPF record should include the primary server IP address.
  
  

IP address changes on the server

Although the IP addresses on the server are static, it is possible IP addresses to change from time to time.

The usual procedure to change an IP address on the server would be:

• we will assign new IP addresses, that will work along with the old IP addresses. Thus, no service will be disrupted.
• аn information box will appear at the DNS Manager and System Information sections of the Control Panel, listing the IP addresses that are going to be changed.
• we will notify our customers about the IP changes and will give them enough time to start using the new IP addresses, if they access some services by IP address. If a domain is using a foreign DNS service (not ours), the customer will have to update the IP addresses in the remote DNS service.
• we will announce the dates on which old IP addresses will stop working. Customers should have started using the new IP addresses prior to that date.

In case your domains are using our DNS servers, and you are not using an IP address in a program/connection setting, then such IP address changes will be completely transparent to you, and there are no actions you need to take.

The icons folder is predefined by the Apache web server. Any content you store in it will not be accessible in a web browser, as the web server will open up its default icons folder instead. You will be able to reach the files stored in your icons folder only via FTP.

• General information about FastCGI and PHP-FPM
• What are you missing if you use FastCGI instead of FPM?
• FastCGI deprecation
• How to transition from FastCGI to FPM
  
  

General information about FastCGI and PHP-FPM

FastCGI

FastCGI for PHP is a significant update of the traditional CGI PHP execution mechanism, and it was introduced on our VPS plans back in 2016. Unlike traditional CGI, the FastCGI execution mechanism allows a single process to handle many requests before being terminated. Reducing the overhead of starting a new PHP process with each new request to the web server brings significant speed improvement and lower resource usage. Due to its improved technology, FastCGI improves website loading times and allows more requests to be handled at once. It also supports OPcache – a caching system that further improves PHP performance by keeping pre-compiled script bytecode in the server memory, thus bringing additional speed and resource-usage optimization.

PHP-FPM

FPM (FastCGI Process Manager) is a newer version of the FastCGI implementation, bringing further improvements to FastCGI, specifically for heavily-loaded sites. PHP-FPM is one of the most efficient and stable technologies for running PHP, and it’s currently supported on all our servers – shared hosting servers and VPS. As PHP-FPM uses the FastCGI protocol, it has all the benefits of the FastCGI PHP execution mechanism, but it also maintains the FastCGI workers which handle PHP requests. This results in even faster execution of PHP scripts. If necessary, PHP-FPM will spawn additional workers to handle all incoming requests on time. PHP-FPM comes paired with OPcache by default and uses OPcache resources more efficiently than FastCGI, as the OPcache pool is shared among PHP-FPM child processes.

What are you missing if you use FastCGI instead of FPM?

Here are some of the benefits that FPM has over FastCGI:

• FPM processes requests faster (more than 30%) compared to FastCGI, which also allows it to process more than 30% more requests at a time than FastCGI.
• FPM helps improve visitor experience and search engine ranking due to its 5+ times shorter TTFB (Time To First Byte). This is possible mostly due to the workers being maintained by FPM, while FastCGI has to spawn a new worker if there are no currently active/available workers.
• FPM is supported on all our servers, while FastCGI can be enabled only on certain VPS plans.
• FastCGI can be enabled only manually, while FPM can be enabled with a single click via the Control Panel‘s PHP Settings section.
• OPcache is enabled by default for FPM; for FastCGI, it has to be enabled manually.
• FPM has better support and is tested more thoroughly by the PHP project.
  
  

FastCGI deprecation

Since there are no drawbacks of the FPM implementation on our servers compared to the FastCGI implementation, we will gradually stop supporting FastCGI. For this reason, we advise switching to FPM as soon as possible.

Transitioning from FastCGI to FPM

Switching from CGI/FastCGI to FPM on our servers is very simple. All you need to do is change the PHP handler for the specific domain/subdomain from CGI to FPM with OPcache via the Control Panel > PHP Settings section. More information on how you can change the PHP handler is available in the PHP version and handler article.

Although this is optional, we would encourage you to revert the steps taken to enable FastCGI in the first place (as outlined in our Using FastCGI + OPcache article) by removing:

• the <IfModule mod_fcgid.c> code block from your website’s .htaccess file;
  
• the .ht-fcgi-php-wrapper file from your website folder;
  
• the [opcache] code block from the main php.ini file for your website.
  

Important: The FPM execution mechanism has proven to work correctly with a plethora of web applications; however, we would recommend that your check your website thoroughly for issues after switching the PHP execution mechanism for your website from FastCGI to FPM, as a specific web application or script may be incompatible with FPM. In such a case, please change the PHP execution mechanism for the website to CGI.

If you encounter any problems or need any assistance with the transition from FastCGI to FPM, feel free to contact our support team.