A bit hard on yourself: core strategy for network stress testing

I. Necessity of stress testing

Today's IT infrastructure and applications are in an extreme environment. The network has been pushed to the limit, and the security industry and personnel are facing severe challenges. Service providers and enterprise networks face performance challenges and require support for massive high-speed communication loads. As the communication load becomes increasingly complex, more and more communication protocols and applications supporting integrated IP services are available, such as voice, video, data, and online transaction sensitive to performance.

Therefore, in order to test the network type of the organization, you can first make a little effort on yourself. You may wish to invest a lot of malicious attack communication into the network before the hacker attacks, see how networks, network devices, and network-based security products (from firewalls to intrusion defense systems) work under pressure.

On the other hand, how do enterprises know that their networks and data centers can support their business needs? How do enterprises know that their network and security manufacturers' devices can really meet their work needs? How do network and security device vendors know the performance that their products can deliver?

The answer is all in the stress test. Ideal stress testing tools need to respond quickly to new challenges, assess the running status of network and security devices under pressure, and be able to isolate and repair defects.

Ii. "Six Essentials" and "four essentials" of stress testing"

The Network stress testing tool is not prepared for underfunded units or unskillful spammers. Therefore, before you decide to buy a stress testing tool, think about it. Please follow the following ten requirements for network stress testing:

I. How can I use these tools? You know, these tools are generally expensive. Make sure that the efficiency is equal to the cost.

2. Before testing, you must obtain complete and accurate information about applications and Protocol sets so that you can build a truly representative environment.

3. Security personnel, network managers, and business managers must be involved in the incident. At the very least, they should listen to their opinions to determine which requirements should be planned, in this way, you can understand and know what needs to be tested.

4. Be sure to consult some service questions about using some or more testing tools to help vendors evaluate the performance of cloud services and test new applications. That is, you cannot prove that you have purchased and supported certain costs correctly. You can still use these services.

5. Be sure to understand the differences between products. A product may not meet the company's IT testing requirements. Are you concerned about performance testing (from testing to the fourth layer or to the application layer ?), Or security testing, or both. You may find that you need to purchase and support two or three products, which will greatly change your plan.

6. The report and correction functions must be evaluated. How does this tool report test results? Is this tool good at comparing test results and identifying problems? Or after the test, should the staff filter the test results and then manually compare them? This test tool should provide the "Capture and replay" function.

"Capture replay" is extremely useful for fault diagnosis. For example, I often hear such a comment: "Let me see the communication process ." In this case, "Capture and replay" is very useful.

7. Do not take precedence. Do not assume that you know which performance requirements apply to new applications, which are applicable to security devices, and which are applicable to networks.

8. Do not purchase products or tools that you cannot support. If an enterprise does not have dedicated laboratories and support personnel to test new devices and applications, it will not be able to reap significant benefits from these products and tools. Test Tools can make the existing test architecture more robust, but cannot build a practical lab on its own.

9. Do not underestimate the role of training. Note: These stress testing tools are complex and require well-trained and skilled personnel to maximize their benefits.

10. Do not ignore penetration testing. Stress Testing is powerful, but it is not a substitute for systematic penetration testing using attack tools such as Metasploit.

In addition, these tools are not a substitute for using traditional penetration testing tools. Generally, stress testing tools do not tell users a satisfactory answer about whether attackers can break the attack. If you cannot understand this, you will get some misunderstandings about vulnerabilities or security status.