Webmasters, you've probably all encountered web Trojans and website backdoors!
Among them, the most well-known is the "one-line Trojan." As its name suggests, it's extremely concise, truly consisting of just one line (as shown in the image below), and is generally embedded within a website's normal code, making it hard to detect.

(Figure 1: One-line Trojan)
Hackers often first infiltrate websites when targeting servers, implanting a Webshell, and then use this Webshell to further steal server permissions.
Hackers implant Webshells mainly through the following methods: online upload vulnerabilities, FTP information leaks, and cross-site intrusions. Among these, online upload vulnerabilities are the most commonly used, accounting for over 90%.
So, how can we prevent hackers from uploading Webshells?
Deleting the online upload module? That's certainly the most thorough method, as websites without online upload functionality have almost zero chance of being implanted with a Webshell. However, this approach affects daily website management and is not the best solution.
In fact, preventing Webshells is quite simple; just follow these two steps:
1. Restrict online upload functionality to administrators only at the physical level.
2. Prohibit the upload of dynamic script files such as PHP, ASP, and ASP.net at the physical level.
1. Restricting online upload functionality to administrators only at the physical level
The term "physical level" is used because some administrators mistakenly believe that restricting online upload functionality through the backend is sufficient, which is a grave error.
Hackers exploit online upload vulnerabilities to infiltrate, so even if the online upload functionality is disabled in the backend management, it has no impact on them.
Restricting at the physical level means adding an extra layer of protection outside the website. Uploaded files are generally stored in the backend directory, and we can use the "Website Admin-Panel Protection" module of "MagiAegis Defense System" to implement restrictions (as shown in the image below).

(Figure 2: Website Backend Protection module of MagiAegis Defense System)
We simply need to fill in the backend address and upload file address in the protection box and set an "authorization password." When accessing the online upload module, users will be intercepted and must enter the "authorization password" to proceed (as shown in the image below). Hackers, naturally unaware of the authorization password, are physically prevented from exploiting upload vulnerabilities.

(Figure 3: Access to the backend is intercepted; an authorization password is required to continue)
For convenience, you can grant overall authorization for your city (the chance of a hacker being in the same city as you is extremely low). As shown in the settings in Figure 2, users in China can access the backend without any verification, while users outside China must enter the authorization password to access.
2. Prohibiting the upload of dynamic script files such as PHP, ASP, and ASP.net at the physical level
Online upload modules generally have functionality to restrict the types of files that can be uploaded, but this is often ineffective against hackers.
Therefore, we need to use the "Tamper Protection" module of "MagiAegis Defense System" to restrict the types of files that can be saved at the driver level, leaving hackers with no opportunity. As shown in the settings below, writing PHP files is prohibited, so even if hackers can upload a Webshell, it will be intercepted when saved. Most importantly, this does not affect daily management.

(Figure 4: Advanced rules for tamper protection, prohibiting the upload and modification of PHP files)
To make it easier for users to use the tamper protection module, the system includes built-in tamper protection rule templates for most CMSs. You simply need to select the website path, security template, and backend address in "Add CMS Protection" and the system will automatically configure powerful tamper protection rules (as shown in the image below).

(Figure 5: Adding CMS tamper protection rules)
By implementing these two protective measures, the possibility of hackers implanting a Webshell becomes zero. Isn't it simple?
Additionally, you can further enhance website security by using the "Webshell Protection" module to automatically detect and kill Webshell files, and the "Static Directory Protection" module to prohibit the execution of dynamic scripts in directories where uploaded files are stored (this feature is enabled by default). This resolves the destructive capabilities of existing Webshells.
