↑↓ to navigate ↵ to open Esc to close Search by Algolia

Install

Securing the FileRun installation

If you use the official Docker image

The official image is built by us and arrives configured. Everything in the list below that belongs to the web server, to PHP and to the layout of the files is already set inside it:

  • The web server refuses every .php file under /apps, and answers with 404 for /system and for /cron.
  • PHP has display_errors off, session.cookie_httponly on, expose_php off and allow_url_include off.
  • The user files live on their own volume, /user-files, outside the folder the web server serves.
  • The container runs as an ordinary user account, not as root.
  • In the example of the Docker installation guide, the database container publishes no port, so the database is reachable only from the FileRun container and not from the network.

One item of the list below is different inside the image, on purpose: PHP can change the application files, because the container installs FileRun itself, and an update from the control panel replaces those files.

Two things stay yours to do, with Docker as without it:

  • Give the superuser a password that cannot be guessed. That account is the only one not protected against brute force sign-in attempts.
  • Serve the installation over HTTPS. The example in the guide publishes plain HTTP on port 80, meant to sit behind something that terminates TLS. See Docker with SSL and Reverse proxies.

Use only an official FileRun Docker image.

If you set the installation up yourself

Once you have FileRun running, it is strongly recommended following these steps in order to secure it:

  • Make sure all the user folders are outside the public area of your HTTP server!
  • Configure your HTTP server to block access to .php files inside the /apps folder. FileRun applies a .htaccess file for Apache and a web.config file for IIS. For NGINX, see the file /apps/security.nginx on suggested configuration that you will need to set in your NGINX configuration.
    • Test to make sure .php files are not accessible via the web server.
  • Configure your HTTP server to block access to the folder /system. FileRun applies a .htaccess file for Apache and a web.config file for IIS. For NGINX, see the file /apps/security.nginx on suggested configuration that you will need to set in your NGINX configuration.
    • Test to make sure the folder is not accessible via the web server.
  • The default user account, superuser, is the only account not protected against brute force login attacks, so it is very important that you set a password that cannot be guessed by a computer. Set a long password, containing also uppercase letters, digits and symbols.
  • Don't use FileRun (or any website) via unencrypted HTTP!
  • Make sure session.cookie_httponly is set to On, in your server's PHP configuration file, for increased security against cross-site-scripting attacks.
  • Remove the ALTER and DROP privileges from the MySQL user account that FileRun is configured with. An update changes the structure of the database and needs both, so do one of the following when you update:
    • Give the privileges back before the update, and remove them again afterwards.
    • Leave them removed, and let the update use the MySQL root account instead. The database step of the update offers Use root credentials, with a field for the root password. The update runs as root, the root password is not stored, and FileRun keeps using its own restricted account afterwards. This option needs the administrative MySQL account to be named root.
  • Make sure the permissions of the FileRun application files do not allow PHP (or any other system user) to make changes to them. Make an exception for the system/data folder and its contents, where FileRun needs to be able to make changes. An update from the control panel replaces the application files, so give PHP write access to them before you update, and take it away again afterwards.
  • Make sure display_errors is set to Off, in your server's PHP configuration file.
  • Do not expose the MySQL/MariaDB database server to the Internet. Do not leave the root account without a password.