Here is an argus log of some traffic from a single source:
Start_Time Flgs Type SrcAddr Sport Dir DstAddr Dport SrcPkt Dstpkt SAppBytes DAppBytes Status
17 Oct 01 11:31:06 tcp 217.29.131.130.26735 ?> 130.216.236.45.80 2 0 160 0 FPA_
17 Oct 01 11:33:19 tcp 217.29.131.130.27112 ?> 130.216.236.45.80 4 0 234 0 FPA_
17 Oct 01 11:37:04 tcp 217.29.131.130.27708 ?> 130.216.236.45.80 4 0 194 0 FPA_
17 Oct 01 11:40:49 tcp 217.29.131.130.28329 ?> 130.216.236.45.80 4 0 194 0 FPA_
17 Oct 01 11:43:58 tcp 217.29.131.130.28582 ?> 130.216.236.45.80 2 0 196 0 FPA_
17 Oct 01 11:45:22 tcp 217.29.131.130.29066 ?> 130.216.236.45.80 4 0 200 0 FPA_
17 Oct 01 11:46:52 tcp 217.29.131.130.29305 ?> 130.216.236.45.80 4 0 192 0 FPA_
Some features to note:
1/ traffic is unidirectional.
2/ there are no SYN packets (would show up as a S in the status field).
3/ 130.216.236.45 is not in use.
5/ all packet have IP ID field of 0x0 (you can't tell this from the ouput
above).
It so happened that snort logged some of these packets:
[**] WEB-IIS File permission canonicalization [**]
10/17-11:37:07.512622 0:0:C:46:5C:D1 -> 0:E0:1E:8E:31:71 type:0x800 len:0x97
217.29.131.130:27708 -> 130.216.236.45:80 TCP TTL:101 TOS:0x0 ID:20959 IpLen:20 DgmLen:137 DF
***AP**F Seq: 0x586174AC Ack: 0xFFC41C7 Win: 0x4470 TcpLen: 20
47 45 54 20 2F 73 63 72 69 70 74 73 2F 2E 2E 25 GET /scripts/..%
63 31 25 31 63 2E 2E 2F 77 69 6E 6E 74 2F 73 79 c1%1c../winnt/sy
73 74 65 6D 33 32 2F 63 6D 64 2E 65 78 65 3F 2F stem32/cmd.exe?/
63 2B 64 69 72 20 48 54 54 50 2F 31 2E 30 0D 0A c+dir HTTP/1.0..
48 6F 73 74 3A 20 77 77 77 0D 0A 43 6F 6E 6E 6E Host: www..Connn
65 63 74 69 6F 6E 3A 20 63 6C 6F 73 65 0D 0A 0D ection: close...
0A .
Which clearly indicates malicious intent on someone's part ;-)
Here is one possible senario that might explain such traffic:
There is a worm (or other malware) which uses this particular IIS bug
to spread compromise systems. The source is located in a network
where there is some filtering proxy which is set up to block some
types of web traffic (eg. code red and nimda type exploits) but does
not quite get it right and some packets in the stream 'escape'. This
does not actually matter since the SYN packet *is* blocked.
I have seen similar traffic consisting of just the second data packet
of the code red attack and traced it back to a set up similar to that
described above that was being operated by a Norwegan ISP.
Anyone got any other ideas.
Russell Fulton, Computer and Network Security Officer
The University of Auckland, New Zealand
----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Wed Oct 17 2001 - 08:42:41 PDT