Dave, unfortunately there is no flow-extract installed and I don't manage this server, but I used flow-print which should give rather same results as far as I understand. So if I execute "flow-cat /<my path to flows>/ft-v05.2011-10-26.0[12]* | flow-print", I see results in following format:
srcIP dstIP prot srcPort dstPort octets packets Now if I try to check incoming flows based on your example: $ flow-cat /<my path to flows>/ft-v05.2011-10-26.0[12]* | flow-print | grep 192.168.2.196 | grep -v ^192.168.2.196 | grep -w 3389 | grep -w 6 > incoming_traffic ..I see 63865 lines if I do "wc -l incoming_traffic". For egress traffic I do: $ flow-cat /<my path to flows>/ft-v05.2011-10-26.0[12]* | flow-print | grep ^192.168.2.196 | grep -w 3389 | grep -w 6 > outgoing_traffic ..and I see 62515 lines if I do "wc -l outgoing_traffic". regards, martin 2011/10/28 Dave Ellingsberg <[email protected]>: > ./flow-cat /<your path to flows>/2011-10-23/ft-v05.2011-10-23.12* | /<your > path>/netflow/bin/flow-extract -ne "dstport=3389 &&proto=6 > &&(srchost=192.168.2.196 ) {print}" > > you need to supply correct paths for the above. This will show only outgoing > flows! change dates accordingly to whatever file structure you have in use. > > bigfoot > >>>> > From: Martin T <[email protected]> > To: <[email protected]>, <[email protected]>, > <[email protected]> > Date: 10/28/11 7:04 AM > Subject: Re: [Flow-tools] load of connections to ephemeral ports from > TCPsource port 3389(probably virus) > > CC: <[email protected]> > Zoltan, Joe, Paul: > yes, such traffic pattern looks exactly like 192.168.2.196 has > established or tried to establish huge amount of Remote Desktop > Connections out to public servers and now gets return traffic. > > I can confirm this if I look the statistics with "flow- stat - f6 - S2 > - P"(- f6 means "UDP/TCP source port", - S2 sorts by third column which > is "octets" and - P displays results in percentages): > > # port flows octets packets > # > 3389 98.855 98.744 96.942 > 1195 0.359 0.742 2.025 > 5101 0.059 0.085 0.061 > 4000 0.042 0.040 0.132 > 80 0.019 0.029 0.018 > 15486 0.037 0.028 0.091 > > However, if I check the statistics with "flow- stat - f5 - S2 - P"(- f5 > means "UDP/TCP destination port"), > > # port flows octets packets > # > 1195 0.407 0.782 2.071 > 25 0.080 0.136 0.078 > 1233 0.053 0.065 0.052 > 1058 0.053 0.062 0.052 > 3380 0.043 0.061 0.043 > 1520 0.046 0.059 0.046 > > ..then almost all the ports fall into 1025 - 5000 range. In other > words there has been lot of connections from port 3389 to ephemeral > ports of 192.168.2.196. Now what's strange to me is that why there are > so little egress connections from 192.168.2.196 to public Windows > Terminal Servers(to TCP port 3389)? I mean in order to get huge amount > of return traffic from port 3389, you need to initialize those > connections at first, don't you? Or does NetFlow capture traffic only > when it's in ingress direction? My flow- sensor is configured to > Juniper router. > > > PS: Paul, thank you for this link! > > > regards, > martin > > > 2011/10/28 Paul Halliday <[email protected]>: >> On Wed, Oct 26, 2011 at 8:56 PM, Martin T <[email protected]> wrote: >>> I have a router interface with IP address 192.168.9.94/27. In >>> addition, I have following static routes in this router: >>> >>> ip route 192.168.9.112 255.255.255.240 192.168.9.65 >>> ip route 192.168.20.16 255.255.255.248 192.168.9.65 >>> ip route 192.168.20.24 255.255.255.248 192.168.9.65 >>> ip route 192.168.20.112 255.255.255.248 192.168.9.65 >>> ip route 192.168.2.128 255.255.255.128 192.168.9.65 >>> ip route 192.168.21.128 255.255.255.128 192.168.9.65 >>> ip route 10.10.10.0 255.255.255.0 192.168.9.65 >>> >>> As you see, all those point to 192.168.9.65 which is a first usable >>> address in 192.168.9.64/27 network. >>> >>> Now if I execute: >>> >>> # flow- cat 2011- 10- 26/* | flow- filter - f access- list.acl - Dacl | >>> flow- print >>> >>> ..while "access- list.acl" looks following(in other words I want to >>> analyse all the networks associated with this connection): >>> >>> ip access- list standard acl permit 192.168.9.64 0.0.0.31 >>> ip access- list standard acl permit 192.168.9.112 0.0.0.15 >>> ip access- list standard acl permit 192.168.20.16 0.0.0.7 >>> ip access- list standard acl permit 192.168.20.24 0.0.0.7 >>> ip access- list standard acl permit 192.168.20.112 0.0.0.7 >>> ip access- list standard acl permit 192.168.2.128 0.0.0.127 >>> ip access- list standard acl permit 192.168.21.128 0.0.0.127 >>> ip access- list standard acl permit 10.10.10.0 0.0.0.255 >>> ip access- list standard acl deny any >>> >>> ..then 98% of lines looks like this: >>> >>> srcIP dstIP prot srcPort dstPort octets >>> packets >>> I.I.P.P 192.168.2.196 6 3389 3799 55 1 >>> I.I.P.P 192.168.2.196 6 3389 4465 40 1 >>> I.I.P.P 192.168.2.196 6 3389 1940 74 1 >>> I.I.P.P 192.168.2.196 6 3389 2611 51 1 >>> I.I.P.P 192.168.2.196 6 3389 2356 141 1 >>> I.I.P.P 192.168.2.196 6 3389 2111 92 1 >>> I.I.P.P 192.168.2.196 6 3389 1151 339 1 >>> I.I.P.P 192.168.2.196 6 3389 2609 55 1 >>> I.I.P.P 192.168.2.196 6 3389 1386 1500 1 >>> I.I.P.P 192.168.2.196 6 3389 3133 1480 1 >>> I.I.P.P 192.168.2.196 6 3389 2684 3000 2 >>> >>> >>> "I.I.P.P" is a random public IP address. 192.168.2.196 is a Windows >>> Server 2003. As you can see, almost every connection is to ephemeral >>> port on 192.168.2.196 using the source port 3389. In addition, >>> download traffic for customer is 5x higher than upload traffic. >>> >>> What might cause such traffic? A virus? If yes, then how does this >>> behave.. Or have I misunderstood something? If no, then what traffic >>> might this be? >> >> http://www.f- secure.com/weblog/archives/00002227.html >> >> -- >> Paul Halliday >> http://www.squertproject.org/ >> > _______________________________________________ > Flow- tools mailing list > flow- [email protected] > http://mailman.splintered.net/mailman/listinfo/flow- tools > > > _______________________________________________ Flow-tools mailing list [email protected] http://mailman.splintered.net/mailman/listinfo/flow-tools
