Enterprise-level Web server security active defense measures

Web servers have now become the hardest hit by viruses and Trojans. Not only has the enterprise's portal website been tampered with and data stolen, but it has also become a disseminator of viruses and Trojans. Some Web administrators have taken some measures to prevent the portal website from being tampered with, but it is difficult to prevent the website from being used as a zombie to spread viruses, malicious plug-ins, and Trojans. The author believes that this is mainly because the Administrator is too passive in Web security protection. They are only passive defense. In order to thoroughly improve the security of Web servers, the author believes that Web security should take the initiative. Specifically, you need to do the following.

I. conduct vulnerability testing during code writing

Enterprise websites are becoming more and more complex and more powerful. But none of these come out of thin air and are accumulated through code. If this code is only used within the enterprise, it will not bring much security risks. However, if it is used on the Internet, the code to implement specific functions may become the target of attackers. Let me give a simple example. You can embed SQL code in the webpage. Attackers can use these SQL code to launch attacks to obtain administrator passwords and other destructive actions. Some specific controls are required to access some websites. When you install these controls, you may be installing a Trojan (which may be invisible to both the visitor and the visitor ).

To this end, you must take the initiative to write code for a specific function of the website. From coding design, writing, and testing, you must identify whether there are security vulnerabilities. In my daily work, I put forward high requirements for employees. Each employee must be responsible for the functions they develop. At least known viruses and Trojans cannot be used in your plug-ins. This layer-by-layer check can improve the security of code writing.

2. Continuous monitoring of Web servers

Frozen for three feet, not a day cold. This is like a person is ill, and there is a process. Viruses, Trojans, and other such attacks on Web servers also require a process. Or, before the attack succeeds, they will have some tentative actions. For example, for a Web server that has taken certain security measures, it takes at least half a day from the beginning of the attack to the result. If the Web administrator monitors the server around the clock. When abnormal behavior is detected, take early measures to block viruses and Trojans out of the portal. This method can greatly improve the security of Web servers.

I have maintained dozens of Web servers. Now we have a dedicated team to monitor server access around the clock. On average, some tentative attack behaviors can be detected every minute. More than 99% of attacks have failed because the server has taken corresponding security measures. However, some attacks still occur every day. These attacks may target new vulnerabilities or adopt new attack methods. No corresponding security measures were taken on the server. If such behavior is not promptly discovered, it is likely that they will eventually achieve their illegal purpose. On the contrary, we have discovered their attack methods early, so we can close this door on the server and fix this vulnerability before they take further action.

I suggest that enterprise users not only consider performance and other factors when selecting Internet Web server providers, but also assess whether service providers can provide around-the-clock monitoring mechanisms. Take the initiative to attack Web security, and promptly discover attack behaviors of attackers. Before they take further attack measures, they are eliminated in the bud.

3. Set a honeypot to direct attackers to the wrong direction

In the army, military personnel are sometimes "disguised", so that the enemy cannot tell the truth. In fact, when dealing with viruses and Trojans, it is itself a war without smoke. To this end, the Web server adopts some disguise and can lead attackers to the wrong direction. When the provider finds a target error, the Administrator has locked the attacker and can take appropriate measures as soon as possible. I sometimes call this kind of active attack as a honeypot effect. Simply put, it is to set up two servers. One is a real server, and the other is a honeypot. What needs to be done now is how to disguise the real server and push the honeypot to the public. Attackers can think that the honeypot server is the real server. To achieve this, you may need to start from the following aspects.

First, it is difficult to distinguish between true and false. If attackers need to hide their eyes, the honeypot server cannot be too fake. When I was working on a honeypot server, more than 80% of the content was the same as the actual server. Only some confidential information is not prevented on the honeypot server. In addition, the security measures taken by the honeypot server are exactly the same as those of the Real Server. This not only improves the authenticity of the honeypot server, but also evaluates the security of the Real Server. Two birds in one fell swoop.

Second, attackers need to be intentionally or unintentionally directed to the honeypot server. Attackers will evaluate whether a Web server is worth attacking. For example, to assess whether the traffic of this website is relatively high. If the website traffic is not high, even if it is cracked, there is little practical value. If attackers are not profitable, they will not spend so much energy on the website server. To direct attackers to the honeypot server, you need to increase the access volume of the honeypot server. In fact, it is very easy to do this. There are now many teams that use interactive traffic. You only need to make a small investment.

Third, attackers can intentionally open some backdoors to drill them. As a Web Server Manager, you not only care about whether your server is secure, but also whether your server has been targeted. Or is there any value of being attacked. The administrator needs to know how many times the server has been attacked in a day. If the attack frequency is high, managers will be happy and worried. I'm glad that the value of my server is still quite large, so many people are thinking about it. We are worried that our servers have become targets of attacks. We should extract more power to focus on server security.

4. Dedicated personnel test the Web server security

As the saying goes, relying on people is better than relying on yourself. This principle also applies to the attack and defense of Web servers. I suggest you set up a professional team if your company has a high security level for Web services, such as an e-commerce transaction platform on your website server. They act as attackers to test server security. This professional team mainly performs the following tasks.

First, test the response speed of the Web management team to attack behaviors. For example, you can use some popular attack methods to launch attacks on your Web servers. Of course, this time is random. The pre-Web management team does not know. Now we need to evaluate how much time the Web management team can discover such attacks. This is also a test of the ability of the management team to track around the clock. Generally, the shorter the time, the better. This time should be controlled within a controllable range. Even if the attack fails, the Web management team should discover the attack behavior as soon as possible. After all, there are two different concepts: whether there is discovery, and whether there is success in the end.

The second is to test whether the server vulnerabilities are supplemented. After all, most attacks are caused by existing server vulnerabilities. Now, what this professional team has to do is whether these discovered vulnerabilities have been installed with security patches or have taken corresponding security measures. Sometimes none of the vulnerabilities we have found are powerless, but these existing vulnerabilities cannot be spared. Otherwise, it would be too cheap for attackers.