Analysis on WEB Server Security Strategy

WEB Server Security Strategy 1: switch roles and treat yourself as a possible Attacker

Most of the time, if we only consider the problem from the perspective of the WEB administrator, we may not be able to find the WEB Server Vulnerability. On the contrary, if we can change our perspective and take ourselves as possible attackers, starting from their roles, think about the means they may use and which WEB server vulnerabilities they may launch attacks, we can detect possible security vulnerabilities on the WEB server, so as to fix the Security Vulnerabilities earlier to prevent trojan or virus attacks.

Access your WEB server from outside the company, perform positive detection, simulate attacks on your website, and see what results will be. This may be a good method for WEB security. For example, we can use a scanning tool to scan WEB servers and check whether there are any services that can be attacked. Some services or vulnerabilities that may be exploited by hackers may not be valued at ordinary times. For exampleServerDuring the installation, the operating system will install and start some unnecessary services by default; or some services need to be started when the server is configured, but they are not closed in time afterwards, thus, attackers are given an opportunity to attack. The most common is SNMP, also known as Simple Network Management Protocol. This service is enabled by default after the system is installed. However, this service can provide attackers with detailed information about the server system, such as the operating system used by the WEB server, the services enabled on the server, and the corresponding ports. Attackers can launch attacks only when they understand the most basic information.

Our security management personnel may not find this problem at ordinary times, but if they can use a hacker's scanning tool to scan, they can find the problem. Therefore, I believe that, when necessary, we need to consider the attack methods from the perspective of the attack role. In this case, we can avoid the "fans of the Board" error and ensure the security of WEB servers.

WEB Server Security Strategy 2: Rational permission management

Sometimes, on a server, not only does the WEB server run, but also other network services such as FTP servers. If multiple network services are applied on the same server, mutual infection between services may occur. That is to say, as long as attackers attack a service, they can use related technologies to break into another application. Attackers can use this service platform to attack other services from within the enterprise. In general, attacks from enterprise content are much more convenient than external attacks.

Some may say that different services can use different servers. In fact, this may be a waste for enterprises. In terms of performance, it is completely feasible to deploy both WEB services and FTP services on the current server without affecting the performance. To this end, enterprises take a server for cost consideration. But now we have a problem for our security administrators, that is, how to ensure their security when two or more services are deployed on one server at the same time, how can they prevent mutual infection?

I have encountered this problem now. I am running three services on my WEB server. One is traditional WEB services, the other is FTP services, and the third is OA Office Automation. Because the service is in the WEB mode, you can directly access the OA server on the Internet, so he is deployed on this server. Because the configuration of this server is still relatively high, it is not difficult to run the three services, and the performance will not be affected. The problem is that, for example, to ensure their security, the security between FTP server, OA server, and WEB server will not affect each other?

I am using a Windows server. To meet this security requirement, all the hard disks on the server are converted into NTFS partitions. Generally, NTFS partitions are much more secure than FAT partitions. Use the functions provided by the NTFS partition to reasonably assign relevant permissions to them. For example, if you configure different administrator accounts for the three servers, different accounts can only access specific partitions and directories. In this case, even if an Administrator account is disclosed, the administrator can only access the storage space of a service, but cannot access other services. For example, load the WEB service to partition D, and put the FTP service to partition E. If an FTP account is leaked, it is attacked and exploited. However, because the FTP account does not have the Read and Write rights to partition D, it will not perform any read/write operations on the content on the WEB server. This ensures that, after the FTP server is captured in real time, it will not adversely affect the WEB server.

Although Microsoft's operating systems are expensive and there are many security vulnerabilities, its achievements in NTFS partition are still not bad. On NTFS partitions, security management can be implemented to a large extent to ensure the security of services related to data. In the end, Microsoft's 2003 operating system was used as the server system instead of the Linux system.

WEB Server Security Strategy 3: Script Security Management

Based on past experience, many WEB servers are paralyzed by attacks and are caused by bad scripts. In particular, attackers like to use CGI programs or PHP scripts to exploit their scripts or program vulnerabilities to launch attacks.

For example, our website has encountered several attacks. They exploited the CGI program vulnerability to allow external attackers to transmit some unreliable parameters to the WEB server. Generally, a WEB application can be accessed normally only by passing necessary parameters. This parameter can be divided into two types: Trusted parameters and untrusted parameters. For example, an enterprise may manage its own WEB servers rather than hosting them. They place servers inside the enterprise's firewall to improve the security of WEB servers. Therefore, the internal parameters from the Enterprise Firewall are reliable and trustworthy. Parameters from outside the enterprise are not trustworthy. However, this does not mean that untrusted parameters, or parameter WEB servers from outside the firewall, are not used. However, when designing a WEB server, you need to check whether these untrusted parameters are valid; however, it cannot be treated like the internal parameters of an enterprise. This clearly threatens the security of WEB servers. Sometimes, attackers can use TELNET to connect to port 80 to pass insecure parameters to the CGL script.

Therefore, when writing CGI programs or editing PHP scripts, we must note that it cannot accept the parameters of strangers at will, and do not deal with strangers at will. Before accepting a parameter, check the validity of the person providing the parameter or the parameter itself. When writing a program or script, you can add some judgment conditions in advance. Inform the administrator of the invalid parameters during the service period. This can also help us detect possible attackers as early as possible and take appropriate measures.

Pay attention to the following issues for Script Security:

1. When writing scripts or programs, you should not directly save any untrusted parameters as session variables. According to the WEB application design principle, session variables only store trust variables. That is to say, the values in the session variables, WEB services, are considered trustworthy and will be used without thinking. The general design idea is to first set a temporary variable for storage, and then write a process or function to verify its legitimacy. This value can be passed to session variables only when verification is passed. Based on the author's experience, WEB administrators who have not personally experienced the painful lessons may not be concerned about this. However, those who have learned this lesson will pay great attention to the legitimacy test process. After all, it takes a long time to gain wisdom. Therefore, new users still need to listen to their suggestions and will not suffer.

2. When not necessary, do not use scripts to simplify the web page. In fact, enterprise websites are very different from personal websites. Enterprise websites only need to be simple and do not need to be rendered too much. On the one hand, over-rendering websites will speed up Website access, and on the other hand, this will also reduce network security performance. Therefore, if there is no sufficient need, do not share scripts or programs in rendering the flashy functions of the website.

3. Continuously track the execution of scripts or programs. When the website is forced to use programs or scripts, it is necessary to audit the running status of these scripts or programs from time to see if they are suspected of being exploited illegally.

WEB servers are the foundation of websites, and their security issues are definitely the top priority. Therefore, it is necessary to do a good job in defense. The three strategies in this article are more practical, for more information, see.