Some initial thoughts based on a quick look at the data. Someone please correct me if I'm off base. - Someone could be performing a SYN Flood against the webserver at 209.11.84.ZZZ and spoofing the address of 213.51.XXX.YYY. - Someone could be performing a reflexive attack against 213.51.XXX.YYY by sending SYN packets to 209.11.84.ZZZ and then you would get the SYN-ACKs back. - However, the fact that the source MAC addresses vary and the traffic never left the VLAN make me think that the target of the attack is 213.51.XXX.YYY, and this is originating within your IP space. The source IP would be spoofed and the webserver at 209.11.84.ZZZ would never have actually been involved. I'm betting the source MAC addresses and varying TTLs are also spoofed in an attempt to avoid detection. - Multicast destination MAC addresses were likely used to amplify the attack. - These packets are clearly crafted. The question is what's generating them. I'm not sure at this point. A colleague mentioned bang.c, but I haven't tested that in the lab yet and am not overly familiar with its capabilities. Anyone else have ideas? Jason Falciola Information Security Analyst IBM Managed Security Services falciolaat_private "Arjan Hulsebos" <ahulsebosat_private> 03/11/2003 04:33 AM To: <incidentsat_private> cc: Subject: Unknown attack, possible trojan? Hello list, We're operating a broadband cable internet network. We received a complaint from a subscriber concerning odd traffic he'd captured. As it turned out, he'd captured a DoS attack on another subscriber. Analysis of the dump showed the following: - Large amounts of packets were sent from a single ip address (not belonging to our AS) to the victim's ip address. - Multiple source ethernet MAC addresses were used (17 in the dump the subscriber sent us). - Multiple destination MAC addresses were used, but most (7 out of 9) were multicast ethernet addresses. - Source and destination ports remained the same, while the SYN and ACK bits were set. - Both sequence numbers were equal to one another, and remained the same throughout the dump. - The TTL varied between 32 and 59. This is odd, as it's all in a switched environment. The router's ethernet address was never seen as a source MAC address, hence the traffic never left the VLAN. - The identity field in the IP header was the same (10803) for all packets. As this spew of packets also hit the router (and died there in an ACL), I checked other routers in our network, and did see the same sort of packets hit the ACLs in various other locations. Comparing them, it turned out that port 80 was always involved, either as a destination port or as a source port. I've included some lines from the tcpdump. Does anyone recognize this? I couldn't find any clue in Google... Thanks, Arjan H Not even a clue-by-four would work with this clown. ________________________________ dr. Arjan Hulsebos Security Engineer Essent Kabelcom West, a.k.a. @Home Benelux 1042 AX Amsterdam Email: arjanhat_private Tel: +31 20 88 55 407 Mob: +31 6 21 548 777 ==== < tcpdump > ===== 20:21:35.872464 0:50:fc:fe:74:a4 1:0:5e:33:e8:58 0800 60: 209.11.84.ZZZ.80 > 213.51.XXX.YYY.63089: S [tcp sum ok] 1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 56, id 10803, len 44) 20:21:35.872851 0:50:7f:4:15:70 0:6:52:50:94:8 0800 60: 209.11.84.ZZZ.80 > 213.51.XXX.YYY.63089: S [tcp sum ok] 1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 55, id 10803, len 44) 20:21:35.880167 0:10:a7:3:81:bd 1:0:5e:33:94:1 0800 60: 209.11.84.ZZZ.80 > 213.51.XXX.YYY.63089: S [tcp sum ok] 1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 53, id 10803, len 44) 20:21:35.880551 0:50:7f:4:15:70 0:6:52:50:94:8 0800 60: 209.11.84.ZZZ.80 > 213.51.XXX.YYY.63089: S [tcp sum ok] 1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 52, id 10803, len 44) 20:21:35.887731 0:10:a7:3:81:bd 1:0:5e:33:94:1 0800 60: 209.11.84.ZZZ.80 > 213.51.XXX.YYY.63089: S [tcp sum ok] 1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 54, id 10803, len 44) 20:21:35.888114 0:50:7f:4:15:70 0:6:52:50:94:8 0800 60: 209.11.84.ZZZ.80 > 213.51.XXX.YYY.63089: S [tcp sum ok] 1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 53, id 10803, len 44) 20:21:35.895208 0:4:61:43:fb:cf 1:0:5e:33:ea:1 0800 60: 209.11.84.ZZZ.80 > 213.51.XXX.YYY.63089: S [tcp sum ok] 1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 55, id 10803, len 44) 20:21:35.895598 0:50:7f:4:15:70 0:6:52:50:94:8 0800 60: 209.11.84.ZZZ.80 > 213.51.XXX.YYY.63089: S [tcp sum ok] 1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 54, id 10803, len 44) 20:21:35.902707 0:0:c5:5d:d:41 1:0:5e:33:e8:58 0800 60: 209.11.84.ZZZ.80 > 213.51.XXX.YYY.63089: S [tcp sum ok] 1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 53, id 10803, len 44) 20:21:35.903093 0:50:7f:4:15:70 0:6:52:50:94:8 0800 60: 209.11.84.ZZZ.80 > 213.51.XXX.YYY.63089: S [tcp sum ok] 1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 52, id 10803, len 44) ---------------------------------------------------------------------------- <Pre>Lose another weekend managing your IDS? Take back your personal time. 15-day free trial of StillSecure Border Guard.</Pre> <A href="http://www.securityfocus.com/stillsecure"> http://www.securityfocus.com/stillsecure </A>
This archive was generated by hypermail 2b30 : Fri Mar 14 2003 - 12:34:04 PST