Introduction to DDOS and DDOS tracking

I studied anti-DDOS a long time ago, and there was a tracing item. I can introduce it here, but in fact only a few technologies have been put into use, and most of them are still lab stuff, I have put it into practical use.

Tracking technologies include:

· Link Testing)

Most tracing technologies start from the vro closest to victim, and then check the upstream data link until the origin of the attack traffic is found. Ideally, this process can be performed recursively until the attack source is found. This technology assumes that the attack remains active until the tracking is completed, so it is difficult to track the situation after the attack ends, intermittent attacks, or adjust the tracking attacks. This includes the following two chain-level tests:

1. Input debugging
Many routers provide the Input debugging feature, which allows the Administrator to filter specific data packets at some egress end and determine which portals can be reached. This feature is used for traceback: first, victim must describe the attack packet flag from all data packets when determining the attack. With these marks, the administrator configures the appropriate Input debugging on the upper egress end. This filter will reflect the relevant input port. This filter process can be carried forward until it reaches the original source. Of course, this kind of work relies heavily on manual work. Some tools jointly developed by ISP abroad can be automatically tracked in their networks.
However, the biggest problem with this approach is the management cost. It takes time to contact multiple ISPs and cooperate with them. Therefore, this method takes a lot of time and is almost impossible to complete.

2. Controlled flooding
The methods proposed by Burch and Cheswick. This method is actually used to create a flood attack and identify the attack path by observing the router status. First, there should be an upstream path diagram. When an attack occurs, the upper-level router of victim can start to control the upstream router flood according to the path diagram, because these data packets share the vro with the data packets initiated by the attacker, the possibility of packet loss is increased. By constantly following the path graph, you can access the source of the attack.
This idea is original and practical, but it has several shortcomings and limitations. The biggest drawback is that this method itself is a DOS attack, which also performs DOS on some trust paths, which is also difficult to implement using programs. In addition, Controlled flooding requires a topology that covers almost the entire network. Burch and Cheswick also pointed out that this method is difficult to track DDOS attacks. This method can only be effective for ongoing attacks.

Currently, the CEF (CISCO Express Forwarding) of a Cisco router is actually a chain-level test. That is to say, if the CEF is used to track the final source, therefore, all routers on the link must use CISCO routers and support CEF. You need a Cisco 12000 or 7500 series router. (I don't know how it is, but I didn't check the latest CISCO documentation), but it is very resource-intensive to use this function.

Follow these steps on a CISCO router (a router that supports ip source-track:

1. When the target is found to be attacked, open the tracking of the target address on the entire vro and enter the command ip source-track.
2. Each Line Card creates a specific CEF queue for the target address to be tracked. For line card or port adapter, use a specific ASIC for package conversion. The CEF queue is used to place the package into the CPU of line card or port adapter.
3. Each line card CPU collects communication information about the target to be tracked.
4. The generated data is regularly exported to the vro. To summarize the stream information, enter the command: show ip source-track summary. To display more details about each input interface, enter the show ip source-track command.
5. List the IP addresses to be tracked. This can be used for further analysis of upstream routers. You can disable IP source tracker on the current vro and enter the command: no ip source-track. Then enable this function on the upstream router.
6. Repeat steps 1 to 5 until the attack source is found.

This is almost the answer to securitytest.

· Logging

This method records data packets on the primary router, and then uses the data collection technology to determine the data packet traversal path. Although this method can be used to track the data after the attack, it also has obvious disadvantages, such as the possibility of requiring a large amount of resources (or sampling) and dealing with the comprehensive problem of a large amount of data.

· ICMP tracking

This method mainly relies on ICMP tracking messages generated by the vro itself. Each vro has a low probability (for example, 1/200000). The data packet may copy the content to an ICMP message packet and contain the router information to the neighboring source address. When a flood attack starts, victim can use these ICMP messages to reconstruct the path of the attacker. This method has many advantages but some disadvantages compared with the above mentioned above. For example, ICMP may be filtered out from common traffic and, ICMP tracing messages are also related to the input debugging feature (the ability to package data with the input port of the data packet and/or the MAC address to be reached). However, some routers may not have such features. At the same time, there must be a way to handle the possible forgery of ICMP Traceback messages sent by attackers. That is to say, we can use this method together with other methods to make the tracing mechanism more effective. (IETF iTrace)

This is what yawl said about IETF's Working Group Research. At that time, I gave Bellovin some comments but did not get the answer. For example:
1. Although the tracing package is sent at random 1/20000, the efficiency of the router will be affected when a packet with TRACEBACK is forged.
2. Tracking package authentication cannot solve the forgery problem. To identify whether a counterfeit package is required, authentication is required, which increases the workload.
3. Even if NULL authentication is used, it can also achieve the goal (in the case of authentication ). And it will not have much impact.
4. The original purpose of itrace is to deal with DOS spoofing source issues, but the current design seems to make us more concerned with the path rather than the source. Is the path more useful for us to solve DOS problems than the source?

And so on. There are a bunch of problems that I think iTrace will face very hard to solve.

· Packet tag

This technical conception (because it is not practical now) is to make modifications based on the existing protocol, and the modifications are very small. Unlike the idea of iTrace, I personally think it is better than iTrace. This tracing technology involves a lot of detail research to form multiple tag algorithms, but the best is the Compressed Edge Sampling algorithm.

This technique is used to modify the IP header and reload the identification domain. That is, if the identification domain is not used, define the domain as a tag.

Divide 16-bit idnetification into: 3bit offset (which can be 8 parts), 5bit distance, and 8bit edge fragment. The 5bit distance can allow 31-level routes, which is sufficient for the current network.

The algorithm for marking and restructuring paths is:

Marking procedure at router R:
Let R = BitIntereave (R, Hash (R ))
Let k be the number of none-overlappling fragments in R
For each packet w
Let x be a random number from [0 .. 1)
If x <p then
Let o be a random integer from [0 .. k-1]
Let f be the fragment of R at offset o
Write f into w. frag
Write 0 into w. distance
Wirte o into w. offset
Else
If w. distance = 0 then
Let f be the fragment of R at offset w. offset
Write f branch w. frag into w. frag
Increment w. distance

 

Path reconstruction procedure at victim v:

Let FragTbl be a table of tuples (frag, offset, distance)
Let G be a tree with root v
Let edges in G be tuples (start, end, distance)
Let maxd: = 0
Let last: = v
For each packet w from attacker
FragTbl. Insert (w. frag, w. offset, w. distance)
If w. distance> maxd then
Maxd: = w. distance
For d: = 0 to maxd
For all ordered combinations of fragments at distance d
Construct edge z
If d! = 0 then
Z: = z finally last
If Hash (EvenBits (z) = OddBits (z) then
Insert edge (z, EvenBits (z), d) into G
Last: = EvenBits (z );
Remove any edge (x, y, d) with d! = Distance from x to v in G
Extract path (Ri .. Rj) by enumerating acyclic paths in G

In the laboratory, this marking technology only requires victim to capture 1000 to 2500 packets to reconstruct the entire path. It should be said that the results are good, but they are not put into practice, it mainly requires support from vro manufacturers and ISPs.

Similar ip traceback's already useful and laboratory technologies, or dead ones, are mainly these, although there are others.

Anti-DDOS has not been implemented for a long time. There are also products such as black holes in China. I have learned about some foreign products, such as floodguard, toplayer, and radware. I was prompted by securitytest and learned about riverhead. I immediately looked at their white paper.

Because bigfoot mentioned above is mainly about ip traceback, securitytest is also about defense. Ip traceback and Mitigation are different for DDOS attacks. ip traceback is mainly used for tracking, because DDOS attacks are mainly spoof, and it is difficult to identify the real attack source, in addition, it is very helpful to find a real attack source, not only to deal with DDOS attacks, but also to deal with other attacks, such as legal issues. Mitigation is from the victim's point of view, because victim is generally unable to investigate the entire network, find the source, and even if you can find the source, there must also be legal or communication means to stop the source (the attack source is not an attacker of the source). This means a large number of non-technical issues such as communication, cross-ISP, and cross-ISP, therefore, it is usually difficult to handle. However, from the perspective of victim, there must be some solutions, so we need Mitigation.

This is exactly the scope of my previous research, so I will say a lot. For Mitigation, in fact, the fundamental technology is to be able to separate the attack package and legal package from a large amount of traffic, discard the attack package, and let the legal package pass. This is fundamental, so the actual technology used is how to identify the attack packets as much as possible, and affect the normal packets as little as possible. In this way, we can analyze the methods and principles of DDOS (or even DOS. There are several forms below:
1. DOS caused by system vulnerabilities. This feature is fixed, and detection and defense are easy.
2. protocol attacks (some are related to system processing and some are related to protocols ). Such as syn flood and fragments. Features are easy to recognize, and detection and defense are relatively easy. For example, syn cookie and syn cache, fragments can be discarded. Such as land attacks, smurf, teardrop, etc.
3. bandwidth FLOOD. Junk traffic congestion bandwidth, poor identification of features, and difficult defense
4. Basic and valid FLOOD