The solution and prospect of DDoS attack on website

Intermediary transaction SEO diagnosis Taobao guest Cloud host technology Hall

I. Occurrence

Spring Festival Holiday just over, the web failed, 1 o'clock in the afternoon eat back, immediately the desktop unlocked and habitually checked the Web server. The Web server performance monitoring software image shows a downward slide of the red curve to see the problem with the website.

Based on the above questions, I immediately started checking the Web server log to see if I could detect when the problem started, or find some clues about the interruption. In the course of a proper inquiry. The company's chief operating Officer (COO) told me that he had received a complaint from a customer and reported that he could not access their website. Then knock the network station address from the desktop, try to visit their website from desktops, but only see the message that cannot display this page.

Recall that a few days ago did not make any changes to the Web server and did not make any changes to the Web server, the server has experienced performance problems. Nothing suspicious was found in the Web server's log file, so I went through the firewall log and the router log carefully. Look at the firewall log carefully and print out the record of the server when it went wrong. and filter out normal traffic and keep suspicious records. The printed results are shown in the table.

Table One firewall log

The same work was done on the router log and the records that looked unusual were printed.

Router log during attack

Figure I

Explain：

IP Packet sizedistribution The two lines under this heading show the percentage of packets distributed by size range. The contents shown here indicate that 98.4% packets are between 33 bytes and 64 bytes (note the red flag).

Parameter explanation:

IP Packet sizedistribution The two lines under this heading show the percentage of packets distributed by size range. The content shown here shows that 98.4% packets are between 33 bytes and 64 bytes in size.

Kyoto Protocol Name

Total flows the number of information flows for this protocol since the last time the statistics were cleared.

Flows/sec the average number of streams of information that occurs within each second of this protocol, which equals the total flow of information/the number of seconds in a consolidated time.

Packets/flow adheres to the average number of packets in the information flow of this protocol. The number of packets that are equal to this protocol, or the number of streams of such protocols during this comprehensive period.

Bytes/pkt The average number of bytes of packets (equal to the total number of bytes of this protocol, or the packet count of such protocols within the overall time period). B/PKT, the average number of bytes per packet in this information flow

Packets/sec the average number of packets per second of this protocol (it equals the total packet of this Protocol), or the total seconds of this combined time.

Active (SEC)/flow the total time (in seconds, such as TCP FIN, end time, and so on) from the first packet to the last packet to terminate the flow of information, or the total number of streams of such protocols in the overall time period.

Idle (sec)/flow from the last packet of each non-terminated flow of information in such a protocol, until the sum of time (in seconds) that was entered into the command, or the total length of time of the information flow in this integrated period.

Normal routing Log

Figure II

IP Packet sizedistribution The two lines under this heading show the percentage of packets distributed by size range. The content shown here shows that 2% packets are between 33 bytes and 64 bytes in size.

Note that the site's traffic is plummeting. Obviously, no one has been able to access his Web server during this period. I started to look at what was going on and how to fix it as quickly as possible.

Ii. Incident Analysis

What happened to my Web server? It is very possible to attack, so what kind of attack? From this attack is to the Echo port look, that is, Port 7, and constantly send small UDP packets to implement. The attack appears to have originated from two, possibly two attackers using different tools at the same time. In any case, the overloaded data stream will drag down the Web server. However, the attack address source is uncertain, it is difficult to judge whether the source of the attack is distributed or the same address disguises many different IP addresses. If the source address is not disguised, is the real address, you can consult the ARIN I United States Internet number registry, from its "whois" database to find out where this intrusion 1P address belongs to which network. You can then get further information by simply contacting the administrator of that network.

Then if the source address is disguised, tracking the attacker is much more troublesome. 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 router to determine which interface the traffic is entering, and then trace back through the routers one at a time until you find the IP address source. This is difficult, however, because there may be many routers between the Web server and the attacker's originating pc, and they belong to different organizations. In addition, these analyses must be done while the attack is in progress.

After analysis, the firewall log and the information in the router log are associated, and some interesting similarities are found, such as the table black tag. The target of the attack is obviously the Web server 192.68.0.175, the port is UDP 7, that is, the echo port. This looks like a denial-of-service attack (but not sure, because the attack is distributed randomly). The address appears to be more or less random and scattered, only one source address is fixed, and its source port number has not changed. It's interesting. Then focus on the router log.

Immediately discovered that there were a large number of 64-byte packets on the router log when the attack occurred, and there were no problems with the Web server log. He also found that there were a lot of "udp-other" packets in the router log at the time of the incident, and that the Web server log was all right. This behavior is consistent with the assumption of Denial-of-service attacks based on UDP.

It is the attacker who uses many small UDP packets to flood the Web server's Echo (echo 7) port, so their next task is to block this behavior. First, we intercept the attack on the router. Quickly set up a filtering rule for the router. Because source addresses are randomly sourced, they find it difficult to block an attack with an address or a range of addresses, and therefore decide to prohibit all UDP packets sent to 192.168.0.175. This practice can cause the server to lose some functionality, such as DNS, but at the very least make the Web server work properly.

Router Initial temporary DOS access control list (ACL)

Access-list 121 remark Temporary blocks DoS attack on Web server 192.168.0.175

Access-list deny UDP any host 192.168.0.175

Access-list Permit IP any

This reduces the burden on the Web server, but attacks can still reach the web, reducing network performance to some extent. The next step is to contact the upstream bandwidth provider and ask them to temporarily limit all UDP inbound traffic on his website Port 7. This can significantly reduce traffic to the server on the network.

Iii. DOS Precautions

There is no panacea for preventing and mitigating this bandwidth-related DOS attack. In essence, this is a "thick pipe to beat the thin pipe" attack. Attackers can "instruct" more bandwidth, and sometimes even huge bandwidth, to rout a network with insufficient bandwidth. In such cases, prevention and mitigation should be complementary.

There are many ways to make an attack more difficult, or to reduce its impact when an attack occurs, as follows:

Ø Network Entry Filter

The network service provider should set up ingress filtering on his downstream network to prevent fake packets from entering the network (and leaving them on the internet). This will prevent attackers from disguising IP addresses, which can be easily tracked.

Ø Network traffic filtering

Filtering out the network does not need traffic is always wrong. This also protects against Dos attacks, but in order to be effective, these filters should be set upstream of the network as much as possible.

Ø network traffic rate limits some routers have the highest traffic rate limit.

These restrictions will tighten bandwidth policy and allow a given type of network traffic to match limited bandwidth. This measure can also pre-empt ongoing attacks, while the filters should be set upstream (as close to the attacker as possible);

Ø intrusion detection system and host monitoring tools

IDS can warn network administrators of the timing of attacks and the attack tools used by attackers, which can help prevent attacks. The host listener can alert the administrator if a DOS tool appears in the system

Ø Single Point transfer RPF

This is another feature of the CEF that is used to check packets received at the interface. If the source IP address CEF The table does not have a consistent route to the interface to receive packets, the router discards the packet. The beauty of discarding RPF is that it blocks all attacks that disguise the source IP address.

Precautions against DDoS

Looking at the actual case above we also learned that many DDoS attacks are difficult to deal with, because the destruction of the host issued a request is completely legitimate, compliant, but the number is too large. With proper ACLs, 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 will cause the ISP or technical support team (if any) to lose some troubleshooting power. You may also encounter a SYN torrent with Cisco TCP interception:

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 permit any any

If you can use contextual access control (context Based access Control,cbac), you can use its timeout and threshold settings to handle the SYN torrent and the udp garbage torrent. For example:

Router (config) # IP inspect TCP synwait-time 20

Router (config) # IP inspect TCP idle-time 60

Router (config) # IP inspect UDP idle-time 20

Router (config) # IP inspect Max-incomplete high 400

Router (config) # IP inspect max-incomplete low 300

Router (config) # IP inspect one-minute high 600

Router (config) # IP inspect one-minute low 500

Router (config) # IP inspect TCP max-incomplete host-Block-time 0

Warning: It is not recommended to use both the TCP interception and CBAC defenses, as this may cause routers to overload.

Turning on the Cisco Quick Forward (Cisco Express FORWARDING,CEF) feature helps routers guard against the torrent of packets being random source addresses. The scheduler can be set up to avoid the full overload of the router at the impact of the torrent:

Router (config) #scheduler allocate 3000 1000

After this configuration, iOS will use 3s of time to process the network interface interrupt request, then use 1s to perform other tasks. For older systems, you may have to use the command scheduler interval "milliseconds".

Iv. Summary

Whether it's retaliation, extortion, a larger attack, DOS or DDoS attacks are a threat that cannot be underestimated. An unusual Dos attack is usually an incomplete exploit-the system service crashes rather than handing control over to the attacker. The way to prevent this attack is to hit a patch from the vendor in a timely manner or upgrade the operating system to a newer version of the Cisco system. Also, to close vulnerable services, or at least restrict access with access control lists. Regular Dos attacks, especially DDoS attacks, are often less methodical and more difficult to guard against. If the entire bandwidth is depleted by the crappy ping torrent, there's only so much we can do. Finally, you must work with your ISP and the Power department to prevent attacks from the source as much as possible. More than one connection to the Internet with different vendors, different as paths, and support for load balancing functions, but this is far from the requirement to respond to the conventional dos/ddos torrent that consumes high bandwidth. We can always use car or nbar to discard packets or limit the speed of the network flow to attack, reduce the burden on the router's CPU, and reduce the footprint of the buffer and the host after the router.

Article Source: http://www.cnblogs.com/chenguang/archive/2011/02/26/1965918.html