Recently I noticed a posting at the SANS Internet Storm Center titled Deformed TCP Options - Got Packets? The story featured packets like the following:
07:11:45.781421 IP (tos 0x0, ttl 113, id 9433, offset 0, flags [DF],
proto: TCP (6), length: 48)
129.250.128.21.1256 > www.xxx.yyy.zzz.1229: S, cksum 0x5ed4 (correct),
2627126762:2627126762(0) ack 257795 6091 win 1460
0x0000: 4500 0030 24d9 4000 7106 4944 81fa 8015 E..0$.@.q.ID....
0x0010: wwxx XXYY 04e8 04cd 9c96 c5ea 99a8 7cfb ...{..........|.
0x0020: 7012 05b4 5ed4 0000 0204 05b4 0102 0403 p...^...........
07:11:51.517325 IP (tos 0x0, ttl 113, id 21659, offset 0, flags [DF],
proto: TCP (6), length: 48)
129.250.128.21.1252 > www.xxx.yyy.zzz.1070: S, cksum 0xa40c (correct),
1381904945:1381904945(0) ack 2301854615 win 1460
0x0000: 4500 0030 549b 4000 7106 764c 81fa 8015 E..0T.@.q.vL....
0x0010: wwxx XXYY 04e4 042e 525e 3231 8933 8397 ........R^21.3..
0x0020: 7012 05b4 a40c 0000 0204 05b4 0102 0403 p...............
In English, 129.250.128.21 is sending SYN ACK packets to the obfuscated IP addresses. 129.250.128.21 is sending SYN ACK packets because it is replying to SYN packets from the obfuscated IP. I knew right away what was happening. Some people called it "backscatter." When I wrote my first paper on the subject in 1999 I used the exceptionally exciting term "third party effects," thereby consigning my research to some vague corner of the Internet. In brief, 129.250.128.21 was being SYN flooded; it is a victim, not a perpetrator.
The ISC handlers wrote:
Generally the source ports are 80, 6667, 6666, and 443. However there are also a number of packets with random source ports between 1024 and about 1300. Ports 1024-1300 are also used as the target port. Looking at the Dshield data for ports 6666 and 6667 there was a small peak for these ports as source ports on the 27/28 Feb.
So we are seeing multiple hosts sending SYN,ACK with truncated option to targets (sometimes both scan the same IP) from known ports. The response is typically a RST, or RST,ACK. The window size is also often changed in the response.
What it looks like is a mapping/fingerprinting exercise using the target stacks' response to bad options. But at this stage the end goal is unclear.
I thought this was not right, and I told the handlers as much. They didn't believe me, so I asked them if they thought it might be a good idea to step out of the cave of packet conspiracies and ask the owner of 129.250.128.21 what was happening. (This was the strategy I followed in my original paper.) They decided not to pursue this non-technical investigative method, so I emailed hostmaster [at] ameri [dot] ca based on the resolution for the IP: compton.ameri.ca.
Since then I've been exchanging emails with Brad Dreisbach. He wrote:
i have been getting tcp syn attacked for about 3 weeks now. i have re-installed the OS on the host just to be safe, but im fairly sure my systems are secure. i have also taken measures with my upstream, whom i also work for, to migitate the attack. some stuff is still getting through but at this point im just waiting for the attackers to give up...
There you go -- Brad is being attacked. 129.250.128.21 is the victim. 129.250.128.21 is not doing some kind of reconnaissance.
When I asked Brad if he had captured any traffic related to his ongoing denial of service attack, he replied:
this pcap file doesnt appear to be a tcp syn attack, but some other form of tcp attack. whoever is doing this is changing their stategy though. the attack has changed a few times over its duration. they even attacked me via ipv6 for a few hours.
Here's part of the traffic he sent:
2007-02-22 17:40:20.844503 IP (tos 0x0, ttl 119, id 5698, offset 0,
flags [DF], proto: TCP (6), length: 40)
68.102.133.89.3072 > 129.250.128.21.80: .,
cksum 0xd7b5 (correct), 0:0(0) ack 0 win 0
0x0000: 4500 0028 1642 4000 7706 21bf 4466 8559
0x0010: 81fa 8015 0c00 0050 0000 0000 0000 0000
0x0020: 5010 0000 d7b5 0000
2007-02-22 17:40:20.855549 IP (tos 0x0, ttl 120, id 48455, offset 0,
flags [DF], proto: TCP (6), length: 40)
72.207.227.118.3072 > 129.250.128.21.80: .,
cksum 0x752f (correct), 0:0(0) ack 0 win 0
0x0000: 4500 0028 bd47 4000 7806 1733 48cf e376
0x0010: 81fa 8015 0c00 0050 0000 0000 0000 0000
0x0020: 5010 0000 752f 0000
2007-02-22 17:40:20.948933 IP (tos 0x0, ttl 118, id 3193, offset 0,
flags [DF], proto: TCP (6), length: 40)
71.237.133.30.3072 > 129.250.128.21.80: .,
cksum 0xd469 (correct), 0:0(0) ack 0 win 0
0x0000: 4500 0028 0c79 4000 7606 293c 47ed 851e
0x0010: 81fa 8015 0c00 0050 0000 0000 0000 0000
0x0020: 5010 0000 d469 0000
This looks like an ACK flood to port 80 TCP. The victim will reply with RST packets (not RST ACK) if it can.
I think ISC got thrown off the trail because SANS has a history of seeing global conspiracies in weird packet patterns. This dates back almost ten years and is documented in my first book. The unfortunate result of this attitude is hundreds, if not thousands, of other security analysts have "learned" to see these patterns as malicious too. ISC also spent too much time concentrating on "broken TCP options" on the backscatter traffic. They did not accept my observation that victims under DoS attack tend to respond slowly, weirdly, and eventually not at all when they are flooded.
If you decide to post a nasty reply here because you love ISC and SANS, please keep in mind you're only seeing the public side of the story. ISC and I exchanged very polite emails, but I am not going to disclose the additional justifications of the ISC evil packet theory here because those emails were private.
I think ISC does a great service to the security community, but I would like to see SANS officially abandon its adherence to this misguided view of the world. I am not trying to pick a fight with SANS. All I want is for security analysts to know this pattern is often seen as "malicious" by many when it is utterly benign -- at least as far as the backscatter recipient is concerned. Remember the site sending the SYN ACK, RST ACK, or RST traffic is responding to a SYN flood (to an open or closed port, respectively) or to an ACK flood.
The moral of the story is that it is not a good idea to assume the world is out to get you when a stray packet arrives at your doorstep. A second lesson is that it sometimes make sense to investigate issues by doing human analysis rather than peering at the world through the eyes of Tcpdump/Ethereal/Wireshark. A third lesson is that it makes little sense to interpret traffic as being malicious if the probablility of the "scanner" learning anything remotely useful is extremely low.
Update: One of my friends noted that the Virginia Tech DShield has 129.250.128.21 listed as one of their "Top 10 Most Wanted" "attackers". This demonstrates the trouble with automated reporting systems.
Update 2: Be sure to read the exciting conclusion here.
0 komentar:
Posting Komentar