Principle and precaution of distributed denial of service attack (DDoS) (2)

Here is the actual process of a SYN flood attack I simulated in my lab

This LAN environment, only one attack aircraft (Piii667/128/mandrake), is attacked by a Solaris 8.0 (Spark) host, network device is Cisco's hundred Gigabit Switch. This is a Snoop record on Solaris prior to the attack, and Snoop, like Tcpdump, is a good tool for network capture and analysis. You can see that before the attack, the target host received basically some ordinary network packets.

…
…
? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes
? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes
? -> (multicast) ETHER Type=0000 (LLC/802.3), size = 52 bytes
? -> (broadcast) ETHER Type=886F (Unknown), size = 1510 bytes
192.168.0.66-> 192.168.0.255 NBT Datagram Service type=17 source=gu[0]
192.168.0.210-> 192.168.0.255 NBT Datagram service type=17 source=rootdc[20]
192.168.0.247-> 192.168.0.255 NBT Datagram Service type=17 source=t Sc[0]
-> (broadcast) ether type=886f (Unknown), size = 1510 bytes
192.168.0.200-> (broadcast) ARP C who 192.168.0.102, 192.168.0.102?
?-> (broadcast) ether type=886f (Unknown), size = 1510 bytes
?-> (broadcast) ether type=886f (Unknown), siz E = 1510 bytes
192.168.0.66-> 192.168.0.255 NBT Datagram Service type=17 source=gu[0]
192.168.0.66-> 192.168 .0.255 NBT Datagram service type=17 source=gu[0]
192.168.0.210-> 192.168.0.255 NBT Datagram Service type=17 source= ROOTDC[20]
-> (multicast) ether type=0000 (llc/802.3), size = bytes
?-> (broadcast) ether type=886f (Unk Nown), size = 1510 bytes
?-> (broadcast) ether type=886f (Unknown), size = 1510 bytes ...

Then, the attack aircraft began to contract, DDoS began ..., suddenly the Snoop window on the Sun mainframe began to flip the screen quickly, showing a large number of SYN requests. The screen is like a window on a 300-kilometer train. This is the result of the Snoop output when the SYN flood attack:


...
127.0.0.178-> lab183.lab.net AUTH C port=1352
127.0.0.178-> lab183.lab.net TCP d=114 s=1352 Syn seq=674711609 len=0
127.0.0.178-> lab183.lab.net TCP d=115 s=1352 Syn seq=674711609 len=0
127.0.0.178-> lab183.lab.net Uucp-path C port=1352
127.0.0.178-> lab183.lab.net TCP d=118 s=1352 Syn seq=674711609 len=0
127.0.0.178-> lab183.lab.net NNTP C port=1352
127.0.0.178-> lab183.lab.net TCP d=121 s=1352 Syn seq=674711609 len=0
127.0.0.178-> lab183.lab.net TCP d=122 s=1352 Syn seq=674711609 len=0
127.0.0.178-> lab183.lab.net TCP d=124 s=1352 Syn seq=674711609 len=0
127.0.0.178-> lab183.lab.net TCP d=125 s=1352 Syn seq=674711609 len=0
127.0.0.178-> lab183.lab.net TCP d=126 s=1352 Syn seq=674711609 len=0
127.0.0.178-> lab183.lab.net TCP d=128 s=1352 Syn seq=674711609 len=0
127.0.0.178-> lab183.lab.net TCP d=130 s=1352 Syn seq=674711609 len=0
127.0.0.178-> lab183.lab.net TCP d=131 s=1352 Syn seq=674711609 len=0
127.0.0.178-> lab183.lab.net TCP d=133 s=1352 Syn seq=674711609 len=0
127.0.0.178-> lab183.lab.net TCP d=135 s=1352 Syn seq=674711609 len=0 win=65535 ...

This time the content is completely different, can not receive just those normal network packets, only DDoS packets. Note that all of the SYN flood attack packets are spoofed from the source address, which is very difficult to trace. How many SYN connections have been accumulated on the attacked host? Let's take a look at the netstat:

# netstat -an | grep SYN …
…
192.168.0.183.9 127.0.0.79.1801 0 0 24656 0 SYN_RCVD
192.168.0.183.13 127.0.0.79.1801 0 0 24656 0 SYN_RCVD
192.168.0.183.19 127.0.0.79.1801 0 0 24656 0 SYN_RCVD
192.168.0.183.21 127.0.0.79.1801 0 0 24656 0 SYN_RCVD
192.168.0.183.22 127.0.0.79.1801 0 0 24656 0 SYN_RCVD
192.168.0.183.23 127.0.0.79.1801 0 0 24656 0 SYN_RCVD
192.168.0.183.25 127.0.0.79.1801 0 0 24656 0 SYN_RCVD
192.168.0.183.37 127.0.0.79.1801 0 0 24656 0 SYN_RCVD
192.168.0.183.53 127.0.0.79.1801 0 0 24656 0 SYN_RCVD……

Where SYN_RCVD represents the currently unfinished TCP SYN queue, Statistics:

# netstat -an | grep SYN | wc -l
5273
# netstat -an | grep SYN | wc -l
5154
# netstat -an | grep SYN | wc -l
5267
…..

Half-connections with more than 5,000 syn are stored in memory. At this time, the attack was unable to respond to the new service request, the system runs very slowly, and can not ping.

This is the case only about 70 seconds after the attack was launched.

Prevention of DDoS
So far, the defense of DDoS attacks is more difficult. First of all, this attack is characterized by the use of TCP/IP protocol vulnerabilities, unless you do not use TCP/IP, it is possible to completely protect against DDoS attacks. A senior security expert gave an image metaphor: DDoS is like 1,000 people at the same time to call your home, when your friend still call in?

But even if it is difficult to prevent, it is not to say that we should be resigned to, in fact, to prevent DDoS is not absolutely not a thing to do. Internet users are various, fighting DDoS, different roles have different tasks. Let's take a few of the following roles for example:

• Enterprise network administrator
• ISP, ICP Administrator
• Backbone network operators

Enterprise network administrator
Network administrator as a corporate intranet manager, is often a security officer, guardian God. What should he do if there are some servers in the network that he maintains that need to provide WWW services to the outside, and thus inevitably become DDoS targets? It can be considered from two angles of host and network device.

Settings on the host
Almost all host platforms have a set of defenses against DOS, to sum up, there are several basic:

• To turn off unnecessary services
• Limit number of Simultaneous SYN semi-connections open
• Shorten time out of SYN semi-join
• Update system patches in time