Table of Contents
Restoring your site, just like installing a new site, is a sensitive time for your site for two reasons.
The archive extraction script (Kickstart) could conceivably be used to extract any JPA, JPS, or ZIP archive on your site. This includes not just the backups present on your site's server, but also any arbitrary ZIP file you may have on your server as long as the operator knows the file path and file name.
The backup restoration script is, essentially, a site installer. Anyone who can access it can potentially see and change the database connection information. Moreover, towards the end of the restoration they can choose to change the password of a Super User (Joomla) or Administrator (WordPress) which could allow them to gain privileged access to your site.
Akeeba Backup and Akeeba Kickstart implement a number of technical measures and offer features which can be used to mitigate these situations. However, it's ultimately up to you to make use of these features and not do something which can be detrimental to your site's security.
Password-protect your backup archive. If you are using Akeeba Backup Professional / Akeeba Solo Professional you should use the JPS archive format. This is an encrypted format, protected by a password of your choice. Doing so means that an attacker who manages to download your backup archive cannot extract it as they do not have the password, thus only having encrypted, unusable data. For the same reason, even if you forget your backup archive and a non-password-protected copy of Akeeba Kickstart in your site's web root (which YOU MUST NEVER DO!) the attacker would be unable to extract the backup archive as they do not have the password. Please note that if you forget this password nobody can help you; you will be locked out of your password. Please use a password manager to generate and store this password. We recommend generating passwords which are at least 64 characters long and consist of truly randomly generated characters a-z, A-Z, digits 0-9, and special characters (`~!@#$%^&*()-_=+[{]};:'"\|,<.>/?); this gives you over 420 bits of randomness which practically ensures that the backup archive cannot be decrypted by brute force.
Password-protect your restoration script. Look for the option named "ANGIE Password" or "Restoration Script Password" (depending on your Akeeba Backup / Akeeba Solo version) in the Configuration page of your backup profile. Set a password here. When you access the restoration script, it will ask you for this password to proceed. This prevents access to the restoration script by unauthorised users. Should you forget this password you can delete the installation/password.php file and try to access the /installation/index.php URL of your site to restart the restoration script without entering a password.
Tell Akeeba Backup / Akeeba Solo to NOT include your database name, username, and password in the backup. Look for the option named "Blank out username/password" in the Configuration page of your backup profile and enable it. The restoration script will NOT pre-fill your database connection information (hostname, database name, username, and password) anymore. You will have to type these in yourself during restoration. This is an effective deterrent against attackers who gain access to your backup restoration script as they cannot proceed past the database restoration page, i.e. they can neither overwrite your database data, nor change the Administrator / Super User username and password. Should you forget this information, it is still easy for you with full access to the hosting account to recover this information by reading your site's configuration file using the information below.
Open the file configuration.php in your site's root. Look for the lines starting with the following:
The uncommon options may not exist in older versions of Joomla. For these versions just set Use SSL/TLS to No.
Joomla 1.5 used var instead of public.
public $dbtype. The database server type. A value of mysqli corresponds to MySQLi. A value of mysql or pdomysql corresponds to MySQL (PDO).
public $dbprefix. The database table name prefix.
public $host. The database server hostname.
public $db. The database name.
public $user. The database username.
public $password. The database password.
public $dbencryption. Corresponds to Use SSL/TLS. A value of 0 or false means No. A value of 1 or true means Yes. (Uncommon option; usually No)
public $dbsslca. The SSL CA file. (Uncommon option)
public $dbsslcert. The SSL Certificate file. (Uncommon option)
public $dbsslcipher. The value for the SSL Ciphers option. (Uncommon option)
public $dbsslkey. The SSL Key file. (Uncommon option)
public $dbsslverifyservercert. Corresponds to Verify Server Certificate. A value of 0 or false means No. A value of 1 or true means Yes. (Uncommon option)
It is possible that the database connection information has changed between the time of the backup and the time of the restoration. In this case, please contact your host for the best way to get or reset the database connection information; it is possible, but the exact process is specific to each host.
Open the file wp-config.php. Look for the define lines with the following keys:
DB_NAME. The database name.
DB_USER. The database username.
DB_PASSWORD. The database password.
DB_HOST. The database server hostname.
The line starting with $table_prefix is the database table name prefix. The database type for WordPress is always MySQLi.
Please note that some WordPress installations may use custom code in wp-config.php which loads this information from other files. It is also possible that the database connection information has changed between the time of the backup and the time of the restoration. In this case, please contact your host for the best way to get or reset the database connection information; it is possible, but the exact process is specific to each host.
Pay attention to the notifications about leftover files. Since Akeeba Backup for Joomla 10.2.0 and Akeeba Backup for WordPress 9.2.0 you will see a notification about restoration leftover files and folders if they are detected on your site. Please note that Akeeba Solo does not do that as it is a standalone application; it is not installed in a CMS installation, and could be used to back up and restore multiple sites at the same time.
Do not use the default kickstart.php filename. The default filename for Kickstart is kickstart.php. This is well-known, and targeted by attackers. Give Kickstart a completely random filename which does NOT contain the words "kickstart", "ks", "extract", or "akeeba". The best way to create a secure, random filename is using Random.org to generate a random 12-character string (this link always generates a new random string). Let's say you get the string 2BTWuadQccWb. Rename kickstart.php to 2BTWuadQccWb.php and upload that file to your site. You can now easily run the archive extraction using that filename in your URL. Let's say that your site is https://www.example.com. Instead of accessing https://www.example.com/kickstart.php do access https://www.example.com/2BTWuadQccWb.php. Please note that this is called "security through obscurity". It's a good way to slow down an attacker, but enough to thwart them. Always remember to remove Kickstart once you are done with the restoration.
Akeeba Kickstart Core and Professional version 9.0.1 and later will refuse to run unless the name of the file does not include any of the terms kickstart, ks, and akeeba, or you have set up a Kickstart password.
Older versions of Akeeba Kickstart Professional will refuse to run unless the name of the file does not include the term kickstart. However, older versions of Akeeba Kickstart Core will run regardless of what the file is named. These older versions do not support setting up a password.
For this reason, we VERY STRONGLY recommend NOT using these old versions unless you are trying to restore a very old backup on a very old server – which is a security issue in and of itself, as you're talking about a server environment and web application software which is several years out of date!
Set up a Kickstart password. Akeeba Kickstart 9.0.1 and later versions allow you to protect access to it with a password. Please refer to Kickstart's documentation for more information. We recommend that you both set up a password, and rename Kickstart to a random filename, as well as remove it immediately when you no longer need it for maximum security.
Use Kickstart's Stealth Mode. Kickstart has included a Stealth Mode since its early versions. This generates a .htaccess file which disables access to your site from any IP address that does not match yours. This method works for hosts using the Apache or Litespeed web server. It does not work with NginX or Microsoft IIS (Internet Information Services). It also assumes that your Internet connection's IP address will remain stable throughout the restoration; this may not be true for some ISPs, shared Internet connections (corporate, hotel, coffee shop, airplane Wi-Fi, …) and Internet connections based on a cellular connection including cellular Internet on your phone / tablet, when tethering to a phone / tablet, or when using an access point which connects to a cellular network as the main or backup Internet connection. This is an optional feature, but we recommend that you do use it whenever possible.
Use password protection for your site's web root. Alternatively to the above, you can use your host's tools to add password protection for your site's root. This requires you to enter a username and password to access any file on your site, including Kickstart itself. If you cannot use Kickstart's Stealth Mode, we strongly recommend that you use this method of protection whenever possible.
Remove Kickstart and the restoration if you have to pause the restoration. If something went wrong during the restoration and you expect it to take more than ten minutes to resolve it, always remove Kickstart and the installation directory where the restoration script lives. Your site will remain broken, but at least you do not run the risk of an attacker taking over your site while you seek help or otherwise work towards resolving the issue you are experiencing.
Always remove Kickstart, the restoration script, and your backup archive from your site when you're done. Once the restoration is done, the very last page tells you to close the tab and click on Kickstart's Clean Up button. This removes Kickstart itself, the installation directory where the restoration script lives, and the backup archive file(s). YOU MUST ALWAYS DO THAT! If the Clean Up stage fails, for example due to file permissions, Kickstart will notify you. In this case you MUST ALWAYS remove these files and directories yourself. As noted above, failure to do so may have security implications for your site.
As noted above, the following security features can be enabled at backup time and applied during the restoration:
Password protection.
Blanking out the database connection information.
Further to that, and as noted above, BRS will remind you to remove Kickstart, the restoration script, and the backup archive at the end of the restoration. You MUST ALWAYS DO THAT!
It is imperative that you remove restoration leftovers after you are done restoring your site. There are several technical measures in place to help you remember that.
As noted above, Kickstart and the restoration script do remind you of that fact and offer to do it automatically. If it's not possible, they will remind you to do this manually. It is your responsibility to act on those prompts. If you choose to leave behind Kickstart, the restoration script, your backup archive, or any combination thereof you will be putting your site at risk.
There are more technical measures in place to help you remember to do that.
If you leave the installation directory (restoration script) behind on a Joomla site, Joomla will automatically redirect you back to it. This feature is built into Joomla; there is no code in Akeeba Backup to implement this behaviour. If this happens, you have an immediate indication you did something wrong, and you must remove the installation directory manually.
If you leave the installation directory (restoration script) behind on a WordPress site, Akeeba Backup for WordPress has a must-use plugin which detects it and notifies you that you must remove the installation directory manually before proceeding.
Akeeba Backup for Joomla 10.1.0 and later versions, and Akeeba Backup for WordPress 9.1.0 and later versions detect if there are any backup archives, any ZIP files in general, any directories which look like a renamed copy of the installation directory (restoration script), or kickstart.php left in your site's root and warn you about it, giving you the option to delete these leftover files. In Joomla this is implemented as a separate system plugin which is automatically installed and activated every time you install or update Akeeba Backup. In WordPress this is part of the Akeeba Backup for WordPress plugin itself and cannot be turned off.
This is a security feature. As a result, we will not implement any feature requests to disable this feature (temporarily or permanently), or add exceptions to the files and directories it detects.
If you absolutely need those files on your server as a short-term, temporary solution (e.g. when you expect having to restore the same backup multiple times when trying to install an upgrade that keeps failing) you can always move those files in a folder placed next to your site's web root. Most hosts give you access to the folder above your site's root. Create a new subdirectory in there. Move these files in that new subdirectory. When you need to restore your site again, move these back to the web root. Kindly note that this is a short-term, temporary solution. If you plan on leaving those files on your server for more than a couple of days; don't! It's best to work on your site on a local server which is not directly accessible from the Internet.
Please note that this feature can be triggered by ZIP files in your site's web root even if they are not Akeeba Backup archives. There is no good way to discern between a general ZIP archive and a backup archive created by Akeeba Backup without spending too many server resources and time as to make such a feature problematic for your site. Besides, the same security principle applies. These files should not be left in your site's root. If you need them on your server, place them outside your web root. If you no longer need them, delete them. If you want to make a ZIP file available for download over the web, do not place it in your sites root; place it in the appropriate folder for publicly accessible files depending on the CMS you are using: images (or files) in Joomla, wp-content/uploads in WordPress.