Hackers teach you to configure the server to be safe

Since our defense is from the perspective of the intruder, then we first need to know the way the intruder invades. At present, the more popular web intrusion methods are to obtain the webshell of the website by finding the loophole of the program, and then find the corresponding methods that can be used according to the configuration of the server to raise the right, and then take the server permission. So with the server to set up a way to prevent webshell is effective.

to prevent the database from being illegally downloaded


should be said, a little network security administrator will be changed from the default database path download sites online program. Of course, some administrators are very careless, get the program to install directly on their own servers, and even the documentation is not deleted, let alone change the database path. This way, the hacker can download the website source program directly from the source site, and then find the default database in the local test, and then download the user information and data (usually MD5 encrypted) to find the management portal to log in to obtain the webshell. . Another situation is that because the program error has broken the path of the website database, how can we prevent this from happening? We can add an extension map for mdb. As shown below:

Open IIS to add an MDB mapping, let mdb resolve to other files that cannot be downloaded: "IIS Properties" - "Home Directory" - "Configuration" - "Mapping" - "Applications Extension" added inside. The mdb file is applied for parsing. As for the files used to parse it, you can make your own choices. As long as you access the database file, you can't access it.

advantage of this is: If only 1 database file suffix mdb format would certainly not download; all mdb files on the server are two pairs of work, useful for virtual host administrators.

Upload


for preventing the above configuration If you are using MSSQL database, as long as there injection point, still can guess solution database by using the injection tool. If the uploaded file does not have authentication at all, we can directly upload an asp Trojan to get the server's webshell.

deal upload, we can be summarized as follows: upload directory does not give permission to execute, directory can not be executed to upload rights. The Web application is run by the IIS user. We only need to give the IIS user a specific upload directory with write permission, and then remove the script execution permission of this directory, which can prevent the intruder from obtaining the webshell through uploading. Configuration method: First in the IIS web directory, open the permissions tab, only to IIS users to read and list directory permissions, then enter the upload file to save and store the database directory, add IIS users write permissions, and finally The "Properties" - "Execute Permissions" option for these two directories changes "Pure Script" to "None". See below

final reminder that you set these permissions, be sure to note that a good set inherit the parent directory. Avoid making insults in vain.

MSSQL injection


for defense MSSQL database, we say, first of all start from the database connection account. Do not use the SA account for the database. Connecting to a database using an SA account is a disaster for the server. In general, you can use the DB_OWNER privilege account to connect to the database. If it works, it is safest to use public users. After setting the dbo permission to connect to the database, the intruder can only obtain the webshell by guessing the username and password or the differential backup. For the former, we can defend by encrypting and modifying the default login address of the management background. For differential backups, we know that its condition is to have backup permissions and to know the web directory. Looking for a web directory we say is usually done by traversing the directory to find or directly reading the registry. There is no way to use these two methods, xp_regread and xp_dirtree two extended stored procedures, we only need to delete these two extended storage, of course, you can also delete the corresponding dll files.

But if the program is due to their own mistakes storm out of the web directory, there is no way. So we have to make the account have lower permissions and can't complete the backup operation. The specific operation is as follows: In the attribute of the account - database access option, only need to select the corresponding database and give it DBO permission, do not operate for other databases. Then go to the database - Properties - permissions to remove the user's backup and backup log permissions, so that the intruder can not get the webshell through differential backup.