The php.ini file, a critical configuration file containing your web server’s PHP settings, is integral to the functioning of your website.
Each time PHP initiates, your system hunts down this file to identify directives that will be applied to your site’s scripts. While your PHP initialization file comes pre-configured, there may be instances when you need to tweak the default settings to meet your specific requirements, such as modifying the memory limit or maximum execution time for scripts to run on your environment.
Website malware can impact the php.ini file, particularly on servers running older versions of PHP. In the first six months of 2023 alone, our team remediated 30,658 compromised php.ini files from infected websites.
In today’s post, we’ll walk you through what this file is, where it’s located, how to modify this file to change your PHP settings, how it’s used by attackers to execute malicious code, and how to harden your site to prevent attacks.
Contents:
- What is the php.ini file
- Where is php.ini located?
- How can I change php.ini directives?
- What settings can I find in php.ini?
- Can malware affect the php.ini file?
What is the php.ini file?
The php.ini file, also referred to as PHP’s initialization file, is a crucial configuration file that governs your web server’s PHP settings. It allows you to manage your site’s PHP-specific regulations, such as defining the maximum size for file uploads, error displays, file timeouts, visibility of error messages, memory limits, and other server-management functionalities.
By default, your server comes pre-configured with standard PHP settings. However, the php.ini file allows more customized control over these settings to optimize performance and enable certain functionalities.
Where is php.ini located?
The php.ini file is read by PHP during server start-up, however the location of your php.ini file may differ based on your server’s configuration, operating system, and PHP version.
We’ve provided a list below of some of the most common default locations for the php initialization file:
Default php.ini location for Linux
- /etc/php.ini
- /etc/php/X/apache2/php.ini (replace X with your PHP version)
Default php.ini location for Windows
- C:\php\php.ini
- C:\Windows\php.ini
How to locate the php.ini file via command line
If you’re comfortable with the command line interface, you can quickly locate your php.ini file using the ‘php –ini’ command.
Simply follow these instructions:
- SSH onto your web server.
- Type the following command:
php --ini | grep php.ini- Press enter.
- A list of all actively used php.ini files along with their locations will be displayed.
Check with your hosting provider
If you’re using a shared hosting plan, your access to php.ini may be restricted. You’ll need to contact your hosting provider for assistance identifying the location of the file and making any changes to it.
How can I change php.ini directives?
Even though default PHP settings are pre-installed on your server, you might need to create or edit a php.ini file to modify specific server settings. This can be accomplished by opening the file in your favorite text editor, modifying parameter values, saving them, and then restarting your web server to apply the changes.
What settings can I find in the php.ini file?
There are a number of important settings, also referred to as php.ini directives, found in your PHP initialization file.
Let’s take a look at some of the most commonly used settings and analyze how they modify PHP’s behavior.
| display_errors | Determines if errors will be displayed or hidden to the user. Usually, this directive should be turned off after development. |
| display_startup_errors | Displays errors encountered during PHP’s startup sequence. |
| error_reporting | Sets the error reporting level and is defined by either an integer or named constants. Default value is E_ALL for PHP 8. |
| log_errors | Defines which file script error messages should be logged to; the server’s log, or to the error_log file. |
| max_input_time | Defines how long a script can parse data from your website forms. |
| output_buffering | Defines whether output buffering for files is enabled or not, as well as size restrictions. |
| request_order | Defines the order that PHP registers GET, POST, COOKIE, and SERVER variables into the _REQUEST array. |
| memory_limit | Defines the maximum number of bytes that a script is allowed to allocate in the server’s memory. |
| short_open_tag | Tells PHP if the short form of PHP’s open tag should be permitted. This option must be disabled if you want to use XML functions. |
| variables_order | Defines the order of parsing for GET, POST, COOKIE, and SERVER variables. |
While this list is not exhaustive, you can get a jist for some common uses. For a more comprehensive list, check out the official documentation for php.ini directives.
Can malware affect the php.ini file?
Some website malware are known to affect PHP initialization files, especially on older web server configurations that allow site/directory level php.ini files. While it is not especially common these days, attackers are known to manipulate the behavior of PHP scripts by creating php.ini files with directives that facilitate malicious activity.
In the first six months of 2023 alone, our malware remediation team has already cleaned up 30,658 infected php.ini files. In most cases, we find multiple malicious files per site, as attackers often plant them in different directories on the environment.
For example, our teams frequently find the following php.ini file on compromised web servers.
safe_mode = Off disable_functions = NONE safe_mode_gid = OFF open_basedir = OFF exec = ON shell_exec = ON
These directives help the attacker disable important security features that protect the server from malicious behavior. It’s worth noting that these directives may only give attackers advantages on older server configurations, but if you find them on your website it may be a leading indicator of compromise and a sign that other malware may be present on your website.
How to protect your web server
The moral of the story? Protect your web server by monitoring for indicators of compromise and unexpected changes in your environment (including new, unexpected php.ini files)!
There are a number of different layers of defense you can implement to protect your web server:
1 – Regularly update your PHP and other software
Always keep your operating system and server software patched and up-to-date to mitigate risk. While updating your software with the latest security patches doesn’t guarantee complete server security, it’s a crucial step as hackers are known to exploit unpatched servers, leading to ongoing incidents.
2 – Monitor your web server
All of your web server logs, including network services, website access, database server, and operating system logs, should be stored in a separate area, monitored frequently and checked for unusual entries, which could indicate potential or successful attacks. Any suspicious activity identified in the logs should be immediately investigated.
3 – Implement a file integrity monitoring system
Consider implementing file integrity monitoring to check for signs of tampering in your website, server, or configuration files. These useful tools check any changes against a previous version of the file and updates against set security rules, alerting you if any indicators of compromise are detected.
4 – Remove unnecessary services
Default operating system installations and configurations are often insecure due to the installation of many unnecessary network services, leaving more ports open for potential abuse by malicious users. To enhance security and server performance, switch off and disable all unnecessary services and make sure they don’t start automatically upon reboot. This will also help to free up hardware resources.
5 – Access your server through secure remote connections
Server administrators should ideally login to web servers locally. If remote access is required, it should be secured through encryption protocols, security tokens, and single sign-on tools, and restricted to specific IPs and accounts. Public computers and networks should be avoided for remote access due to security risks.
6 – Disable unused users
Stale or inactive user accounts can pose a significant security risk to your web server if left unchecked, as they could be used by an attacker. Consider regularly grooming your database for unused users and removing them if access is no longer required.
7 – Assign lowest privileges possible
The principle of least privilege — granting minimal system access necessary for an action and only for the necessary time — is key for securing your environment and effectively managing user roles to mitigate risk. Consider the lowest set of privileges necessary for tasks, how long they’re required, and ensure every user uses complex, unique passwords, thereby reducing potential vulnerabilities and limiting unauthorized actions.
8 – Get a web application firewall
Consider using a web application firewall to further harden your website and server, virtually patch known vulnerabilities, and mitigate bad bots and DDoS.
9 – Encrypt data in transit
Always use the latest secure communication methods like TLS v1.2 and AES encryptions for your web servers. Make sure to enable HTTPS for data encryption and validate your certificate(s) regularly.
And as always — if you think your website has been hacked or you’re struggling to fix an infection, we’d be happy to help clean up malware and restore your site!
Luke Leal
Kyle Knight
Ben Martin
Néstor Angulo
Antony Garand
Douglas Santos
Northon Torga
Stephen Johnston
Victor Santoyo
Justin Channell