Created: 07-Mar-2002 - Lawrence Baldwin
This document attempts to graphically illustrate the technique of tracing the actual source of a spoofed DoS attack which is documented here:
DoS Ingress tracking using ICMP backscatter
Step 1: Denial of service (DoS) attack is initiated by an unknown attacker. Attacker is randomly spoofing the source IP address of each packet, making it impossible to determine the actual source. Victim's Internet connection is saturated can no longer service requests. Victim contacts their ISP for assistance.
Step 2: ISP Pushes out a filter (null route) to ALL routers in their network blocking packets to victim's IP address.
Step 3: All routers will now block victim's traffic AND generate ICMP unreachable packets back to the source IPs (this is the "backscatter").
Some of the ICMPs will be sent
to valid users attempting to connect to victim's host. However, most of the ICMP traffic will be sent from the ingress router that is receiving the DoS flood.
The ISP also puts a special configuration in place so ICMP Unreachables regarding blocked packets from a range of IP addresses which are known to be
unused are sent to a central location.
As soon as they begin receiving these ICMP unreachables they know that the router sending them is the ingress of the DoS attack--Router 3 in this case.
Step 4: The filter blocking the victim's IP is removed from all routers EXCEPT the ingress. This stops the DoS flood and restores most service to the victim.
The ISP then escalates this issue to the provider downstream from Router 3. Hopefully they have as good a backtracing mechanisms in place. As this process is repeated,
the ultimate source of the attack can be identified.
I began researching this issue in order to better understand why firewalls often log ICMP Unreachable packets such as:
mNW Incident 2925313
One of the mNW agents that received these ICMP packets was able to capture the full packet using Ethereal:
(Note: Agents actual IP has been replaced with "xx.xx.xx.xx":
Frame 1 (70 on wire, 70 captured)
Arrival Time: Mar 6, 2002 08:53:19.592414000
Time delta from previous packet: 0.000000000 seconds
Time relative to first packet: 0.000000000 seconds
Frame Number: 1
Packet Length: 70 bytes
Capture Length: 70 bytes
Ethernet II
Destination: 00:b0:d0:XX:XX:XX
Source: 00:d0:05:XX:XX:XX
Type: IP (0x0800)
Internet Protocol, Src Addr: 500.POS1-2.GW5.SAC1.ALTER.NET (157.130.54.65), Dst Addr: (xx.xx.xx.xx)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 56
Identification: 0x0000
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 243
Protocol: ICMP (0x01)
Header checksum: 0x5621 (correct)
Source: 500.POS1-2.GW5.SAC1.ALTER.NET (157.130.54.65)
Destination: (xx.xx.xx.xx)
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 1 (Host unreachable)
Checksum: 0xa10d (correct)
Internet Protocol, Src Addr: (xx.xx.xx.xx), Dst Addr: 168.169.198.44 (168.169.198.44)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 48
Identification: 0xc93a
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 109
Protocol: TCP (0x06)
Header checksum: 0x77d7 (correct)
Source:(xx.xx.xx.xx)
Destination: 168.169.198.44 (168.169.198.44)
Transmission Control Protocol, Src Port: 65403 (65403), Dst Port: 65339 (65339)
Source port: 65403 (65403)
Destination port: 65339 (65339)
A nice feature of ICMP error packets is that it includes the header of the packet that actually triggered the error. This is how we're able to tell
that the DoS victim is (168.169.198.44) and they they are being flooded with TCP packets sourced from high numbered ports (e.g. 65403) and destined for
high numbered ports (e.g. 65339). The TCP SYN flag is NOT set, so this appears to be a brute traffic flood vs. a SYN flood.
Here is a tracert to the victim host:
H:\W3SVC1>tracert 168.169.198.44
Tracing route to 168.169.198.44 over a maximum of 30 hops
1 <10 ms <10 ms <10 ms host121.mynetwatchman.com [64.238.113.121]
2 <10 ms <10 ms <10 ms 172.16.41.165
3 <10 ms 10 ms <10 ms car00-s6-0-1.atlagabu.cbeyond.net [192.168.14.17]
4 <10 ms 10 ms 10 ms bgr00-g1-0.atlagabu.cbeyond.net [192.168.20.49]
5 10 ms 10 ms <10 ms 64.211.166.201
6 <10 ms 20 ms 10 ms pos2-0-155M.cr1.ATL1.gblx.net [206.132.115.113]
7 <10 ms 10 ms 10 ms pos0-0-0-155M.br1.ATL1.gblx.net [206.132.115.118]
8 <10 ms 10 ms 10 ms 57.ATM2-0.BR1.ATL5.ALTER.NET [204.255.168.137]
9 <10 ms 10 ms 10 ms 179.at-5-2-0.XR1.ATL5.ALTER.NET [152.63.82.198]
10 20 ms 20 ms 20 ms 0.so-1-0-0.TL1.ATL5.ALTER.NET [152.63.85.217]
11 20 ms 40 ms 30 ms 0.so-7-0-0.TL1.NYC8.ALTER.NET [152.63.146.53]
12 20 ms 30 ms 20 ms 0.so-2-0-0.XL1.NYC8.ALTER.NET [152.63.0.154]
13 20 ms 30 ms 20 ms 0.so-3-0-0.XR1.NYC8.ALTER.NET [152.63.19.30]
14 20 ms 30 ms 20 ms 183.at-1-0-0.XL1.NYC1.ALTER.NET [152.63.27.142]
15 40 ms 40 ms 40 ms 507.ATM6-0.GW3.BUF1.ALTER.NET [152.63.25.49]
16 40 ms 40 ms 40 ms wnyric-gw.customer.alter.net [157.130.21.26]
17 40 ms 40 ms 40 ms 168.169.1.65
18 40 ms 50 ms 41 ms 168.169.8.1
19 51 ms 60 ms 60 ms 168.169.108.42
20 * * * Request timed out.
21 250 ms 201 ms 200 ms 168.169.198.44
Trace complete.
Notice how Hop # 15 (152.63.25.49) corresponds to the source IP address of the initial ICMP backscatter logged
in the mNW incident I referenced above. I suspect that uuNet first put a null route on their edge router connecting
to the victim. This would have alleviated the congestion problem on the victims Internet link (between hop #15 and #16).
The actual packet we captured was from later in the day when uuNet had null routes in place on all their routers. Therefore, we can probably
conclude that the source IP (157.130.54.65) of that ICMP packet was the ingress source of the attack.
H:\W3SVC1>tracert 157.130.54.65
Tracing route to 500.POS1-2.GW5.SAC1.ALTER.NET [157.130.54.65]
over a maximum of 30 hops:
1 <10 ms <10 ms 10 ms host121.mynetwatchman.com [64.238.113.121]
2 <10 ms <10 ms 10 ms 172.16.41.165
3 <10 ms 10 ms <10 ms car00-s6-0-1.atlagabu.cbeyond.net [192.168.14.17]
4 <10 ms 10 ms <10 ms bgr00-g1-0.atlagabu.cbeyond.net [192.168.20.49]
5 <10 ms 11 ms 10 ms 64.211.166.201
6 100 ms 40 ms 20 ms pos2-0-155M.cr1.ATL1.gblx.net [206.132.115.113]
7 10 ms <10 ms 20 ms pos0-0-0-155M.br1.ATL1.gblx.net [206.132.115.118]
8 10 ms 10 ms <10 ms 57.ATM2-0.BR1.ATL5.ALTER.NET [204.255.168.137]
9 <10 ms <10 ms 10 ms 179.at-6-2-0.XR2.ATL5.ALTER.NET [152.63.82.194]
10 20 ms 20 ms 30 ms 0.so-1-2-0.TL2.ATL5.ALTER.NET [152.63.146.2]
11 61 ms 80 ms 70 ms 0.so-1-2-0.TL2.SAC1.ALTER.NET [152.63.10.114]
12 80 ms 80 ms 70 ms 0.so-7-0-0.XL2.SAC1.ALTER.NET [152.63.54.9]
13 60 ms 80 ms 70 ms 500.POS1-2.GW5.SAC1.ALTER.NET [157.130.54.65]
Trace complete.
SAC = Sacramento, CA, I believe.
secKB Index
|
