Securing PHP Environments: Disabling Dangerous Functions and Restricting Access

If you are hosting a WordPress site, a Laravel application, or any custom PHP-based software on your VPS, securing the PHP runtime environment is a critical line of defense. Even with a Web Application Firewall (WAF) and strict file permissions, a single vulnerability in a plugin or application code can lead to Remote Code Execution (RCE).

By default, PHP is designed to be highly flexible, which means it includes built-in functions capable of executing root-level system commands. If an attacker manages to exploit a vulnerability in your web application, they will immediately attempt to use these functions to download malware, read sensitive system files, or open a reverse shell. Hardening your php.ini configuration limits the damage an attacker can do, even if they manage to breach the application layer.

Disabling Dangerous PHP Functions

The most effective way to prevent PHP from being used as a weapon against your server is to explicitly disable functions that interact directly with the underlying Linux operating system.

• Locate your loaded php.ini file. The location varies depending on your web server and PHP version (e.g., /etc/php/8.1/fpm/php.ini for Nginx or /etc/php/8.1/apache2/php.ini for Apache).

• Open the file using your preferred text editor: sudo nano /etc/php/8.1/fpm/php.ini.

• Search for the disable_functions directive. By default, it is usually empty or only contains a few obscure functions.

• Update the directive to include functions that allow command execution and process control. A strong baseline looks like this: disable_functions = exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source

• Note: If your application explicitly requires one of these functions to operate (e.g., a backup plugin that requires exec to run mysqldump), you will need to carefully remove it from the list.

Restricting File Access with open_basedir

If a hacker finds a Directory Traversal vulnerability in your web app, they will try to trick PHP into reading files outside of your website's folder—such as /etc/passwd or your database configuration files located in other directories.

The open_basedir directive confines PHP scripts to a specific directory tree. If a script attempts to read or write a file outside of this defined boundary, PHP will block the action and throw a fatal error.

• In your php.ini file, search for the open_basedir directive.

• Uncomment it (remove the leading semicolon) and set it to the absolute path of your web root, plus the directory where PHP stores temporary upload files.

• For example: open_basedir = /var/www/mywebsite/:/tmp/

• This guarantees that even if a malicious script runs, it is physically trapped inside /var/www/mywebsite/ and cannot snoop around your VPS's core filesystem.

Hiding PHP Information

Information gathering is the first phase of any cyber attack. By default, PHP broadcasts its exact version number in the HTTP response headers of every single page load (e.g., X-Powered-By: PHP/8.1.2). Attackers use automated scanners to look for outdated PHP versions with known exploits.

• In your php.ini file, locate the expose_php directive.

• Change its value from On to Off: expose_php = Off

• Additionally, ensure that the display_errors directive is set to Off for production environments. When an application breaks, displaying raw error outputs on the screen can reveal your database structure, internal IP addresses, or file paths to an attacker. Errors should only ever be routed to your backend log files (log_errors = On).

Applying the Changes

Whenever you modify the php.ini file, the changes will not take effect until you restart the PHP processor or your web server.

• If you are using Apache with mod_php, restart the web server: sudo systemctl restart apache2

• If you are using Nginx with PHP-FPM, restart the PHP-FPM service (make sure to use your specific version number): sudo systemctl restart php8.1-fpm