Since our prevention is considered from the perspective of the intruder, we first need to know how the intruder invades. At present, the more popular web intrusion methods are to first obtain the website's webshell by looking for program vulnerabilities, and then find corresponding exploitable methods to escalate privileges based on the server's configuration, and then gain server permissions. Therefore, it is an effective method to cooperate with the server to set up to prevent webshell.
1. Prevent the database from being illegally downloaded
It should be said that administrators with a little bit of network security will change the default database path of website programs downloaded from the Internet. Of course, some administrators are very careless. They get the program and install it directly on their own server, without even deleting the description file, let alone changing the database path. In this way, hackers can directly download the website source program from the source code site, then test it locally to find the default database, and then download the database to read the user information and data inside (usually MD5 encrypted) to find the management entrance and log in to obtain the webshell. . Another situation is that the path to the website database is exposed due to a program error. So how to prevent this from happening? We can add the extended mapping of mdb. As shown below:
Open IIS and add an MDB mapping, so that mdb can be parsed into other files that cannot be downloaded: "IIS Properties" - "Home Directory" - "Configuration" - "Mapping" - "Application Extension" and add the .mdb file to apply parsing. You can choose the file used to parse it yourself, as long as the database file is inaccessible.
The advantages of this are: 1. Database files in the mdb suffix format will definitely not be downloaded; 2. It works for all mdb files on the server, which is very useful for virtual host administrators.
2. Prevent uploading
For the above configuration, if you are using an MSSQL database, as long as there is an injection point, you can still use the injection tool to guess the database. If there is no authentication at all when uploading files, we can directly upload an asp Trojan to get the server's webshell.
Regarding uploading, we can summarize it as follows: Directories that can be uploaded are not given execution permissions, and directories that can be executed are not given uploading permissions. The web program is run by the IIS user. We only need to give the IIS user write permission to a specific upload directory, and then remove the script execution permission from this directory to prevent intruders from obtaining the webshell through upload. Configuration method: First, in the IIS web directory, open the permissions tab and only give IIS users read and list directory permissions, then enter the directory where uploaded files are saved and the database is stored, add write permissions to IIS users, and finally Just change "Pure Script" to "None" in the "Properties"-"Execution Permission" option of these two directories. See picture below:
One last reminder, when you set the above permissions, you must pay attention to setting the inheritance of the parent directory. Avoid setting up in vain.
[Cut-Page]
3. MSSQL injection
For the defense of MSSQL database, we say that we must first start with the database connection account. Do not use the SA account for the database. Using the SA account to connect to the database is a disaster for the server. Generally speaking, you can use the DB_OWNER permission account to connect to the database. If it can run normally, it is safest to use the public user. After setting the dbo permission to connect to the database, the intruder can basically only obtain the webshell by guessing the user name and password or differential backup. For the former, we can defend it by encrypting and modifying the default login address of the management background. For differential backup, we know that its condition is to have backup permissions and know the directory of the web. Looking for web directories is usually achieved by traversing the directory to search or directly reading the registry. Either of these two methods uses the two extended stored procedures xp_regread and xp_dirtree. We only need to delete these two extended stores. Of course, we can also delete the corresponding dll files together.
But if the web directory is exposed due to a program error, there is nothing you can do. So we also need to make the account's permissions lower and unable to complete the backup operation. The specific operations are as follows: In the properties of this account - database access options, you only need to select the corresponding database and grant it DBO permissions. Do not operate other databases. Then go to the database-properties-permissions to remove the user's backup and backup log permissions, so that intruders cannot obtain the webshell through differential backup.
3. MSSQL injection
For the defense of MSSQL database, we say that we must first start with the database connection account. Do not use the SA account for the database. Using the SA account to connect to the database is a disaster for the server. Generally speaking, you can use the DB_OWNER permission account to connect to the database. If it can run normally, it is safest to use the public user. After setting the dbo permission to connect to the database, the intruder can basically only obtain the webshell by guessing the user name and password or differential backup. For the former, we can defend it by encrypting and modifying the default login address of the management background. For differential backup, we know that its condition is to have backup permissions and know the directory of the web. Looking for web directories is usually achieved by traversing the directory to search or directly reading the registry. Either of these two methods uses the two extended stored procedures xp_regread and xp_dirtree. We only need to delete these two extended stores. Of course, we can also delete the corresponding dll files together.
But if the web directory is exposed due to a program error, there is nothing you can do. So we also need to make the account's permissions lower and unable to complete the backup operation. The specific operations are as follows: In the properties of this account - database access options, you only need to select the corresponding database and grant it DBO permissions. Do not operate other databases. Then go to the database-properties-permissions to remove the user's backup and backup log permissions, so that intruders cannot obtain the webshell through differential backup.
