Summary of simple and practical WEB Security Settings

Server

1. First, the NTFS format is required, and the permissions of users and other users are reduced. If the disk in FAT32 format has no permission settings, there will be no security;

2. Second, the patch should be complete. Otherwise, if a trojan is installed on the server, nothing will happen;

3. Disable dangerous components and service items. This is difficult. If it is a simple application, it is better to say that if the server is running a tangled program, it is very likely that some components or services are not allowed to run, which is a headache for me. Therefore, it is necessary to know the permissions and other aspects involved in the application for security;

4. Port shielding. For example, it is enough for a common WEB server to open 21, 80, and 3389;

5. encrypted transmission, which prevents sniffing, but WIN does not seem to have its own;

6. other small settings, such as password security, desktop lock software, and command function renaming, are related to security awareness. They do not play much role, but are better than none.

IIS security

1. The execution permission is very important. Different Sites use different anonymous users for access, but these users cannot grant permissions and do not need to add group permissions, in addition, the permission for writing a single visitor is only valid in the corresponding WEB directory, other disks are invalid, and all the permissions such as Everyone are deleted... In addition, most directories do not have write permissions. User Permissions are the most important part of WEB security;

2. Cancel useless API extensions. Anyone who is confused knows that if asp fails to be passed, they will use a trojan in the asa or cer format. The same is true for security. All useless API extensions will be removed, for example, only one asp site is left. asp, other extensions are deleted, and it is useless to pass the backdoor;

3. Remove unnecessary WEB extensions. If more vulnerabilities are added to the extension, you can use less.

Permission

1. The site has independent user permissions to prevent cross-site access. As mentioned in IIS, this can be set in IIS or hard disk. In essence, this is the same as the NTFS-format permission settings, in addition, the permission can be read and written at most, and no more permissions are allowed;

2. permission settings for directories and files. For image directories, you can give them the read permission, and all scripts can be disabled. No picture can be executed... The same is true for files. The HTML directory and file and script permission can be disabled, and the normal page can be used to give a read permission. The write permission is dangerous and can be used to reduce the write permission, however, if you make a mistake, the website will crash;

3. Special directory permissions, such as drive D and drive E, delete Everyone and even delete sub-directories. However, directories such as system do not have inheritance rights, if you delete a user of drive C, there are still many sub-directories that need to be deleted one by one. Otherwise, the access to drive C becomes inaccessible, however, user folders and windows directories can be accessed.

Code Security

1. Code anti-injection: This is the most serious security problem. With the database, there are many injection methods, and there are also many defense methods. It is difficult to generalize them, in short, it depends on the programmer's security awareness and code skills;

2. To prevent the upload vulnerability, in addition to injecting a large number of uploads, many of them intrude into dependent uploads. The solution is to reduce the number of uploads, increase the verification strength, and fix the suffix and type during verification, instead of exclusion, the uploaded file is named immediately and the suffix is automatically modified. The upload directory does not have any permissions!

3. File naming rules. Some test files and sensitive files, names and directories cannot be guessed or verified;

4. Third-Party code should be used less, especially those written by small teams. The Code of DISCUZ is always prone to vulnerabilities, not to mention other code, because the code is open, attackers can find vulnerabilities from the source code, which is dangerous;

5. It is hard to find out other problems, such as preventing social engineering vulnerabilities and explosion-proof paths, or security awareness.