DDOS does not need fear to effectively defend against DoS Attacks

The possibility of DDoS attacks to your enterprise depends on your enterprise's operating method, attacker's whimsy, or enterprise's competitors. The best way to mitigate attacks is to ensure that you have sufficient capabilities, redundant sites, commercial service separation, and plans to respond to attacks.

Although you cannot block all DDoS attacks, there are still ways to limit the effectiveness of these attacks so that your company can fix them faster. Most attacks target web applications. They simply send more requests than they can process to the target web application, making it difficult for visitors to use.

In DDoS attacks, most attacks do not care about system and application crash. Although they will be happy with the crash, their primary goal is to prevent the services provided by the target company from responding to requests from legitimate users and creating problems for the affected company.

If you have appropriate monitoring technology, it is easy to detect DDoS attacks. Your network operation center (NOC) displays the system status: bandwidth, requests per second, and system resources. If all these trends increase suddenly or in a short time, then the monitoring system will issue an alarm.

In a typical enterprise, these events will promote the upgrade of NOC, and the IT team will quickly recruit appropriate people to handle them. The management will also receive a notification saying that the website and applications are not normal, and everyone will think about why the sudden surge in requests.

The first step is to analyze the logs of these requests

You want to know what the request is and the source of the request. Compare new requests with normal traffic to determine whether these are legal loads. If your enterprise has centrally managed log records, it is easy to do. However, if the log server cannot keep up with the server and is overloaded, you may not be able to respond to your search for logs. If your application is attacked, logs from infected servers may not be sent to the log system. Which data will be transmitted from the beginning of the attack for analysis.

Step 2: parse these logs to understand DDoS attacks

After obtaining the log, open the classification tool and resolution tool. After obtaining the log, open the classification tool and resolution tool. First, you need to determine how DDoS attacks are carried out. Does a DDoS attack consume firewall resources by sending data to a port not opened by the remote system? Do I request a specific URL repeatedly? Or simply send Get/HTTP/1.1 requests to the web server?

Through enterprise monitoring, you can determine the location of the load application. If your firewall has a high load while the web server does not, it is the first type of attack. If the web server is slow in processing requests, and the firewall is processing load, the web application should be directly attacked if the resource utilization rate is higher than usual.

Step 3: determine the key factors

After you know the DDoS attack media, you need to work with the log information to determine several key factors. By viewing the log, you can determine what the DDoS attack tool has done. No matter whether the request is sent to a web application or processed by the firewall, the data you are looking for is the same. A request that violates the conventional rules. You can view the logs Clearly to see the DDoS attack section, because a large number of similar requests or request styles are combined. For example, 10 thousand requests may attempt to access a URL, or a port may fail.

In some cases, distributed tools may change their requirements. However, in general, you will see requests for the same resource, from the same source, combined, for example, repeatedly sending requests to nonexistent URLs. Determine the request used by the DDoS attack. If all attack nodes are the same, you will be able to find attackers and distinguish legitimate traffic.

As long as you figure out the request style, you can determine the attacker. Find the attack nodes that send the highest and fastest requests. These are large attackers. After you know the most common requests and their sources, you can start to act. I often hear suggestions for renaming infected resources (such as URLs or host names), but this will only cause attackers to reconstruct their DDoS attacks or attack new resources.

This policy works only when attackers call legitimate web application URLs (for example, large database queries. In this case, modify the application, execute screen confirmation, or execute redirection that cannot be understood by the attacker's tool (such as CAPTCHA or Flash application with user confirmation and redirection) this can reduce the impact of attacks. Unfortunately, in most cases, attackers only change their attacks.

Step 4: Source Filter, connection, and speed limit

After trying these initial steps, the next step should be source filtering, connection, and Rate limiting. If we can stop the largest attackers and slow down other attackers, We can greatly reduce the impact of DDoS attacks. In order to launch an attack successfully, the attacker's node must exceed the number of requests that our production cluster can process within a given time. If we can block some attack nodes, we can reduce the system load, so that we have time to block more attacks, notify network providers, and transfer services.

To protect most of the infrastructure, it is best to apply filters wherever possible near the edge of the network. If you can persuade the network service supply or data center to deploy filters on their devices, it will be easier to prevent DDoS attacks.

If you must deploy a filter on your device, or you need to wait for the response from the upstream supplier to start, you can start from the edge device and gradually spread backward. Use all appropriate tools to filter requests and reduce the impact on the system. Routers, load balancers, IPS, web application firewalls, and even the system itself can reject some requests.

The first filter should filter all connections from the attacker who sends the most requests. Apply this rule to your access control list (ACL. Of course, edge devices should not accept the traffic sent to their interfaces and should not respond to data packets. If they do this, they will become the attacker's additional attack targets.

Step 5: Limit the connection speed based on the source

This can block any new connection requests from hosts that exceed the connection limit. View logs and set the speed limit to below the average number of requests sent at each interval. If you are not sure which log entries are valid for attackers, you can use the Request Rate of the maximum request sender as the starting point. Because the Request Rate sent by the maximum sender must be greater than the average value.

In addition, you can adjust hosts and edge devices to clear idle sessions faster to get more resources. However, you cannot overhead it to avoid spending too much resources to establish and remove connections. By blocking the source and limiting the rate, the impact of DDoS attacks can be greatly mitigated. If attackers continue to attack and cannot see the end, the IT team should focus on protecting other enterprise resources.

Generally, attackers can target a specific host, application, or network. Transferring the traffic of these resources to another location or blocking the traffic will save the load of the backend system, but it will also affect your service, which is also the target of attackers. It is also a good idea to separate attacked services from other services. If the infected service can be isolated, at least the Enterprise will not crash completely.

DDoS attacks have a profound impact on the normal operation of enterprises. CEOs are concerned with loss of revenue and negative news. The IT department is worried about applications that crash and long-term overtime. If you provide services over the Internet, you are a potential DDoS attack target.