Solutions and prospects for website DDOS attacks

　　I. event occurrence

After the Spring Festival holiday, the WEB experienced a fault. After one o'clock P.M., I immediately unlocked the desktop and habitually checked the Web server. The Web server performance monitoring software displays a red slide down curve and shows a problem on the WEB.

Based on the above problems, I immediately began to check the Web server logs and try to see when the problem began or find some clues about the interruption. While querying clues. The company's COO told me that he had received a complaint from the customer and reported that he could not access their website. So I typed in the website address from my desktop and tried to access their website from a desktop computer, but what I saw was that I could not display the message on this page.

In retrospect, we did not make any changes to the Web server or make any changes to the Web server a few days ago. The performance of the server has encountered performance problems. No suspicious information is found in the Web server log file. Therefore, I will carefully check the firewall logs and router logs. Carefully checked the firewall log and printed the records when the server encountered a problem. Filter out normal traffic and keep suspicious records. The printed results are displayed in the table.

　　

 

Table 1 firewall logs

Then, I did the same job on the router log and printed the abnormal log.

Router logs during attacks

　　

 

Figure 1

Explanation:

The two rows under the IP packet sizedistribution title show the percentage of data packets distributed by size range. The content shown here indicates that the size of the 98.4% data packet is between 33 bytes and 64 bytes (note the red mark ).

Parameter description:

The two rows under the IP packet sizedistribution title show the percentage of data packets distributed by size range. The content shown here indicates that 98.4% of data packets are between 33 bytes and 64 bytes.

Protocol name

Total Flows the number of information Flows of this Protocol since the last time statistics are cleared.

Flows/Sec displays the average number of information Flows of this Protocol per second, which is equal to the total number of information Flows/The number of seconds of the overall time.

Packets/Flow: the average number of Packets in the information stream that comply with this Protocol. It is equal to the number of packets of the Protocol, or the number of information flows of the Protocol during this comprehensive period.

Bytes/Pkt indicates the average number of Bytes of data packets that comply with this Protocol (equal to the total number of Bytes of this protocol, or the number of data packets of this Protocol during this comprehensive period ). B/Pkt, the average number of bytes of each data packet in this information flow

Packets/Sec average number of Packets of the Protocol per second (it is equal to the total number of Packets of the Protocol), or the total number of seconds of the overall time.

The total time (in seconds, such as tcp fin and termination time) of the last packet from the Active (Sec)/Flow to the terminated information stream ), or the total number of information flows of such protocols during the overall period.

Idle (Sec)/Flow starts from the last packet of each non-terminated information stream of this Protocol until the sum of time (in seconds) of the command is entered ), or the total time length of the information flow during the overall time.

Normal route log

　　

 

Figure 2

The two rows under the IP packet sizedistribution title show the percentage of data packets distributed by size range. The content shown here indicates that 2% of data packets are between 33 bytes and 64 bytes.

Pay attention to the sharp decrease in website traffic. Obviously, no one can access his Web server during this time. I started to study what happened and how to fix it as soon as possible.

　　Ii. Event Analysis

What happened to my Web server? It is very likely to attack, so what kind of attacks? This attack is based on the echo port, that is, port 7, which continuously sends small UDP packets. The attack seems to come from two sources, probably because two attackers use different tools at the same time. In any case, overloaded data streams will drag the Web server down. However, the attack Address Source is uncertain. I don't know whether the attack source is distributed or whether the same address disguise many different IP addresses. This problem is hard to judge. If the source address is not a disguised address, it is a real address, you can consult the arin I Internet Number registry to find out which network the 1 P address belongs to from its "whois" database. Next, you only need to contact the network administrator for further information.

If the source address is disguised, it would be much more difficult to trace the attacker. If you are using a Cisco router, you also need to query the NetFlow cache. NetFlow is one of the features of the Cisco fast forward (CEF) Switching framework. To track this disguised address, you must query the NetFlow cache on each vro to determine which interface the traffic enters. Then, you can trace the traffic one by one through these vrouters at a time, until the IP Address Source is found. However, it is very difficult to do this because the Web Server and the attacker's initiating pc may be connected through many routers and belong to different organizations. In addition, these analyses must be performed while the attack is ongoing.

After analysis, the information in the firewall log and the router log is associated, and some interesting similarities are found, such as the black mark. The attack target is obviously the Web server 192.68.0.175, and the port is UDP 7, that is, the echo port. This looks like a Denial-of-Service attack (but it cannot be determined because the attack distribution is random ). The address seems to be more or less random and scattered. Only one source address remains fixed, and its source port number remains unchanged. This is interesting. Then focus on the router log.

Immediately, when an attack occurs, the router log contains a large number of 64-byte packets, but there is no problem in the Web server log. He also found that there were a large number of "UDP-other" packets in the router log at the time of the incident, and the Web server logs were all normal. This phenomenon is consistent with the assumption of UDP-based DoS attacks.

Attackers use many small UDP packets to launch a flood attack on the echo 7 port of the Web server. Therefore, their next task is to block this line. First, we intercept attacks on the vro. Quickly set a filter rule for the vro. Because the source address sources are random, they think it is difficult to restrict an address or a range of addresses to prevent attacks, so they decided to prohibit all UDP packets sent to 192.168.0.175. This will cause the server to lose some features, such as DNS, but at least make the Web server work normally.

The initial temporary DOS access control list (ACL) of the router)

Access-list 121 remark Temporary block DoS attack on web server 192.168.0.175

Access-list 105 deny udp any host 192.168.0.175

Access-list 105 permit ip any

This method reduces the burden on the Web server, but the attack can still reach the web, thus reducing the network performance to a certain extent. The next step is to contact the upstream bandwidth provider and ask them to temporarily limit all UDP inbound traffic on port 7 of their website. This will significantly reduce the network-to-server traffic.

　　Iii. DOS Prevention Measures

There is no panacea for preventing and mitigating bandwidth-related DoS attacks. In essence, this is an attack that "uses a thick pipe to defeat a thin pipe. Attackers can "direct" more bandwidth, sometimes even a huge bandwidth, to defeat networks with insufficient bandwidth. In this case, prevention and mitigation should complement each other.

There are many ways to make the attack more difficult, or reduce the impact when the attack occurs, as shown below:

Ø network entry Filtering

Network service providers should set entry filters on their downstream networks to prevent fake information packets from entering the network (and leave them on the Internet ). This will prevent attackers from disguising IP addresses for easy tracking.

Ø network traffic Filtering

Filtering out unnecessary network traffic will always be fine. This can also prevent DoS attacks, but in order to achieve the effect, these filters should be set as far as possible in the upstream network.

Some routers have the highest traffic rate limit.

These restrictions will enhance the bandwidth policy and allow a given type of network traffic to match a limited bandwidth. This measure can also mitigate ongoing attacks in advance. At the same time, these filters should be set as far as possible in the upstream Network (as close as possible to the attacker );

Ø Intrusion Detection System and host monitoring tools

IDS can warn the network administrator of the Attack Time and the attack tool used by the attacker, which can help prevent the attack. The host monitoring tool can warn the administrator of the existence of the DOS tool.

Ø single-point transmission RPF

This is another feature that CEF uses to check the packets received on the interface. If the source IP address CEF table does not have a route that is the same as the one that points to the interface when receiving the data packet, the router will lose the data packet. The magic of dropping RPF is that it blocks all attacks that disguise source IP addresses.

DDOS Prevention Measures

After reading the actual cases above, we also learned that many DDoS attacks are very difficult to cope with, because the number of requests sent by the host involved in the destruction is completely legal and compliant, but the number is too large. With the appropriate ACL, we can block ICMP echo requests. However, if you have your own autonomous system, you should be allowed to ping you from the Internet. Failure to ping may cause the ISP or technical support team (if any) to lose some troubleshooting capabilities. SYN flood with Cisco TCP interception may also occur:

Router (config) # ip tcp intercept list 101

Router (config) # ip tcp intercept max-incomplete high 3500

Router (config) # ip tcp intercept max-incomplete low 3000

Router (config) # ip tcp intercept one-minute high 2500

Router (config) # ip tcp intercept one-minute low 2000

Router (config) # access-list 101 permit any

If Context-Based Access Control (CBAC) can be used, you can use its timeout and threshold settings to cope with SYN flood and UDP spam flood. For example:

Router (config) # ip inspect tcp synwait-time 20

Router (config )#