PHP-FPM Setup

PHP-FPM is a PHP implementation of the FastCGI, an enhancement of the earlier Common Gateway Interface (CGI). It works especially well with NGINX.

See here for configuration of PHP-FPM.

Installation

To install PHP-FPM on a system, use your local package to manager to grab all of the following: php, php-fpm, fcgiwrap, and nginx.

Often apache2-utils (a.k.a. apache-tools, httpd-utils, etc... consult your package manager!) is also necessary, for creating .htpasswd files.

Upstream manages a Docker file with frequent security patching, as bitnami/php-fpm:latest. This will expose PHP-FPM on port 9000 and generally work out of the box.

PHP

PHP-FPM unsurprisingly runs in PHP and will require a working installation. The primary configuration for PHP is found at /etc/php/php.ini. Some distributions provide two versions: a hardened php.ini-production and a verbose php.ini-development.

See here for help in configuring PHP.

The upstream Docker image bundles PHP internally, but it is possible to un-bundle it and force the use of an existing installation.

PHP-FPM

For the most part, distributed configuration for PHP-FPM work out of the box.

; Pid file
pid = /run/php-fpm/php-fpm.pid

; Error log
error_log = /var/log/php-fpm.log

FCGIWrap

FCGIWrap is, as the name implies, a wrapper script. It manages the configuration of FastCGI through PHP-FPM so that all you need to do is point NGINX at /run/fcgiwrap.sock.

At the same time, it is entirely optional. The upstream Docker image does not include it. Not using FCGIWrap will require more attention on the configuration of PHP-FPM, however.

NGINX

For more details on NGINX configuration, see this walkthrough. A basic configuration for FastCGI would be:

user www-data www-data;
http {
  include mime.types;
  default_type application/mime.types;

  sendfile on;
  keepalive_timeout 65;
  gzip on;

  server {
    listen 80;
    server_name example.com;
    access_log /var/log/nginx/example.com/access.log;
    error_log /var/log/nginx/example.com/error.log;

    root /var/www;
    try_files $uri @cgi;

    location @cgi {
      include fastcgi_params;
      fastcgi_param SCRIPT_FILENAME $realpath_root/my-cgi-script.cgi;
      fastcgi_param PATH_INFO $uri;
      fastcgi_param QUERY_STRING $args;
      fastcgi_param HTTP_HOST $server_name;
      fastcgi_pass unix:/run/fcgiwrap.sock;
    }
  }
}

Test Script

A minimal test script to validate the PHP installation.

<?php phpinfo(); ?>

Security

Work Directory

PHP applications can be placed anywhere on the web root and they will work as expected. This is because PHP-FPM defaults to working in the current work directory.

However, it is recommended to isolate PHP-FPM by running it in a different work directory. This is accomplished by configuring PHP-FPM on a pool level, which you can read more about here. What needs to be addressed up-front is how a web server will interact with an isolated FastCGI environment.

The NGINX try_files command, as shown below, checks for existence of files. This will cause issues if PHP applications are actually living in a different directory (or a different server). However, without checking for the existence of an executable, you can run into difficult-to-debug errors and security issues regarding embedded PHP in ordinary files.

The workaround is to set the key FastCGI parameters for the target server and check the URI against local null files.

location ~ \.php(/|$) {
    fastcgi_split_path_info ^(.+?\.php)(/.*)$;
    fastcgi_param SCRIPT_FILENAME /remote/path/to/work/directory/$fastcgi_script_name;
    fastcgi_param PATH_INFO       $fastcgi_path_info;

    try_files $uri =404;

    fastcgi_pass 192.168.86.1:9000;
    include fastcgi_params;
}

Note that try_files is called strictly after path info has been pulled out. Try files will, on success, overwrite $uri with the matched local URI.

HTTPoxy

location ~ \.php(/|$) {
    # Mitigate https://httpoxy.org/ vulnerabilities
    fastcgi_param HTTP_PROXY "";
}

CategoryRicottone