Table of contents of the article:
When discussing CMS security, the focus is almost always on updates, vulnerable plugins, passwords, application firewalls, and backups. These are fundamental aspects, but there's a lower, often overlooked level that can significantly contribute to mitigating attacks: the filesystem.
The discussion is generic and can be applied, with the necessary differences, to dynamic CMS such as Magento, PrestaShop, Drupal, Joomla and naturally WordpressIn this article, we'll focus on WordPress because of its widespread use and because, precisely because of this, it's one of the most frequent targets of automated exploits, bots, and massive compromise campaigns.
The starting point is simple: a dynamic site must be able to read many files, write to some, and traverse directories to function properly. But this doesn't mean the entire installation must always be modifiable. Not all files need to be writable, not all paths need to allow the same level of operation, and not all directories need to allow changes outside of maintenance periods.
When an exploit writes into WordPress
Many WordPress attacks don't just temporarily exploit a vulnerability. They often attempt to achieve persistence: they write new files, modify existing files, inject code into a theme, alter a plugin, or place a web shell in a web-accessible directory.
This happens because many installations are left, for convenience, in a too permissive state. WordPress needs to be able to update plugins and themes, upload images, generate cache, and sometimes modify files such as .htaccessFrom this legitimate need, however, a dangerous habit arises: treating the entire installation as if it were always writable.
If an exploit can execute code in the context of the website user or web process, it will try to exploit this very possibility.If it finds modifiable directories and overwritable files, it can install backdoors or alter legitimate components. However, if certain critical areas are protected and unmodifiable during normal operation, a significant part of the attack is made more difficult.
Not everything has to be writable
A clear example is the plugin directory. A WordPress site doesn't need that. wp-content/plugins be writable at all times. This must be the case when installing, updating, or removing a plugin. But between updates, especially on a professionally managed production site, those files can remain static.
The same reasoning can be applied to many core files, parts of the active theme, configuration files, and components that shouldn't change outside of scheduled maintenance. Conversely, directories like wp-content/uploads They have different needs: they must allow media to be loaded, but precisely because they are writable they should be treated with care and not become a convenient place to execute malicious code.
Security, therefore, should not be seen only as a distinction between “allowed” and “forbidden”, but as a more precise separation between what must be read, what must be written and what must remain intact.
This separation also concerns the concept of execution. On Linux, the execute bit on directories is also used to traverse them, so it shouldn't be interpreted superficially. However, from an application perspective, not every path containing files uploaded or generated by the CMS should be eligible for code execution. An upload area, for example, should be designed to store content, not to host PHP scripts ready to be called by the browser.
What does chattr +i do?
On Linux, in addition to the classic permissions managed with chmod e chown, there are filesystem attributes that can be managed via chattrAmong these, the most interesting attribute from a hardening perspective is +i, that is, the attribute of immutability.
When a file is marked as immutable, it cannot be modified, deleted, renamed, or opened for writing until the attribute is removed by an authorized party. This is therefore not equivalent to simply removing write permission with chmod: is a stronger constraint, applied at the filesystem level.
In essential form, the commands are these:
chattr +i file-o-directory chattr -i file-o-directory lsattr file-o-directory
chattr +i apply immutability, chattr -i removes it, while lsattr It allows you to check the existing attributes. Of course, these commands shouldn't be applied indiscriminately across the entire installation. A CMS must continue to write where it needs to: cache, upload, logs, and other dynamic paths can't be blocked without careful evaluation.
Why is it used so little?
Although it is a powerful tool, chattr +i It's rarely used in traditional web hosting (let's just say never), so do a few Google searches to see that we're the only ones talking about it. The first reason is cultural: many CMS security guides limit themselves to standard permissions, security plugins, or web server rules. Filesystem immutability is a topic closer to Linux system architecture than to standard WordPress management.
The second reason is operational. If you make a file that needs updating immutable, the update will fail. If you lock the wrong directory, the CMS may no longer be able to generate cache, upload files, or complete maintenance. This technique therefore requires a method, documentation, and clear procedures.
The third reason concerns control panels. Plesk, cPanel, and DirectAdmin simplify the management of domains, files, databases, mail, and certificates, but they haven't made filesystem immutability a standard application hardening model for CMSs. Some document the immutable attribute or explain how to remove it when it causes problems, but they don't typically offer it as a standard workflow for surgically securing a WordPress installation.
The reason is understandable: a generic control panel must work in a wide range of scenarios, often with non-systems users. Automating immutability without knowing the site could lead to disruptions. This is precisely where professionally managed hosting can offer added value.
The correct approach: surgical, not indiscriminate
Immutability shouldn't be used as a lock that can be applied everywhere. The site shouldn't be completely frozen. Instead, paths should be distinguished based on their function.
Critical configuration files may require additional protection. Core files can be treated as static between updates. Plugins can be made unmodifiable until the next maintenance. Upload directories should remain writable, but should not allow code execution. Cache directories should be regenerable, but without granting excessive freedom to sensitive areas.
A purely conceptual example, not a universal procedure, might be:
# Protezione di un percorso critico fuori manutenzione chattr +i percorso/critico # Sblocco controllato prima di un aggiornamento chattr -i percorso/critico # Verifica dello stato degli attributi lsattr percorso/critico
The important part is not the single command, but the process: analyzing the site's behavior, identifying what needs to change, and protecting what shouldn't be changed during normal operation.
An extra layer of security for managed hosting
In standard hosting, the provider offers web space, a database, a control panel, and generic tools. The user installs the CMS, updates plugins, and manages the site. In this model, it's difficult to apply truly targeted hardening because the provider doesn't necessarily know the specific behavior of the project.
Hosting managed by professional system administrators, however, can take a different approach. After initial tuning, it's possible to identify which paths should be writable, which should be readable only, and which can be protected with more restrictive attributes. This reduces the attack surface and makes it more difficult for malware to modify critical components.
The value is not just in performing chattr +i, but in knowing where to apply it, when to remove it, and how to reintegrate it into update processes. Immutability must coexist with maintenance: first unlock, then update, verify the site, and finally restore protection.
Limits not to be ignored
The immutable attribute isn't a silver bullet. It doesn't replace updates, backups, user isolation, malware scanning, monitoring, WAFs, or good access policies. Furthermore, if an attacker gains elevated privileges on the server, they may be able to remove the attribute, depending on the context and available capabilities.
However, it remains a very interesting measure against a common category of attacks: those that, after exploiting a vulnerability in the CMS or a plugin, attempt to write or modify files within the web installation. In these cases, reducing the writable nature of critical paths can make a tangible difference.
Conclusion
Increasing the security of a CMS also means stopping thinking of the filesystem as a single container. Each file and directory has a different function. Some paths should be dynamic, others should remain stable, and still others should only be modifiable during controlled maintenance.
In the case of WordPress, but also Magento, PrestaShop, Drupal, and Joomla, the filesystem immutability attribute can represent an additional layer of defense. It doesn't eliminate the need to update, monitor, and secure the application, but it does reduce the wiggle room for many attacks that aim to write backdoors or alter existing files.
chattr +i It's rarely used because it requires system expertise and because general-purpose control panels don't typically integrate it as an application security model. Precisely for this reason, it can become a distinctive feature in professionally managed hosting: initial tuning, path mapping, and a precise separation between reading, writing, and execution can transform a standard CMS installation into a more robust, more controlled environment that's less vulnerable to automated attacks.
