ratop
CS Lee
geek00l at gmail.com
Mon Oct 22 20:22:31 EDT 2007
Hi Carter,
Here's the result,
ra -L0 -nr ~/i-Pcaps/loadbalance.arg -s +1smac +2dmac
StartTime SrcMac DstMac Flgs
Proto SrcAddr Sport Dir DstAddr Dport SrcPkts
DstPkts SrcBytes DstBytes State
19:33:06.063023 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
tcp 10.0.0.46.36024 -> 216.67.244.22.80
3 3 629 198 RST
19:33:27.653232 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
tcp 10.0.0.46.45640 -> 216.67.244.22.80
2 2 140 138 RST
19:33:57.899913 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
tcp 10.0.0.46.2540 -> 216.67.244.22.80
2 1 108 60 RST
19:33:58.907789 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
tcp 10.0.0.46.2541 -> 216.67.244.22.80
2 1 108 60 RST
19:33:59.915817 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
tcp 10.0.0.46.2542 -> 216.67.244.22.80
2 1 108 60 RST
19:34:00.923744 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
tcp 10.0.0.46.2543 -> 216.67.244.22.80
2 1 108 60 RST
19:34:01.931729 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
tcp 10.0.0.46.2544 -> 216.67.244.22.80
2 1 108 60 RST
19:34:02.939714 0:1b:77:5b:f4:3f 0:50:e8:2:3d:ca e
tcp 10.0.0.46.2545 -> 216.67.244.22.80
2 1 108 60 RST
12:03:14.936864
man 0 0 16 1
28 9 2113 867416 STP
10.0.0.46 is the source in the data and only maps to one mac address which
is 0:1b:77:5b:f4:3f.
On 10/22/07, Carter Bullard <carter at qosient.com> wrote:
>
> Hey CS Lee,Well, this is right, but may not be exactly what you are
> expecting.
> We're going to build the radark() script up so that it does a lot
> more than just find some scanners in the big pile of flow records,
> so some of these early calls are really over designed for the simple
> first set of operations.
>
> With the calls to racluster(), we're keeping the Mac addresss <->
> IP address pairings, so we later can decide is this scan coming
> from the outside or the inside (just because its got an external
> IP address as a source address doesn't mean the packet
> originated from the outside).
>
> So based on what you've sent (and assuming no bugs) it looks
> like you've got some flows where 10.0.0.46 is coming
> from or to one ethernet address, and other flows where its
> mapped to another ethernet address. This can happen if
> there are two ways into a LAN.
>
> Run this against your original data:
>
> ra -nnr loadbalance.arg -s +1smac +2dmac | fgrep 10.0.0.46
>
> This should show us what ethernet addresses 10.0.0.46 is using.
> (you use the filter "- ip" to show your primitive data, but you don't
> use that filter in any of your racluster() commands, so you may
> be using arp flows in this run. maybe should add the "- ip" filter
> to the first racluster() call).
>
> The purpose of the third call to racluster(), is to generate a list of
> local IP addresses that are actively responding to external
> addresses, and 10.0.46 is indeed one of those addresses.
> If the address comes up twice, well that is not an issue for the program
> that will use it, rafilteraddr().
>
> Is this helping?
> Keep those questions coming!!!!
>
> Carter
>
>
> On Oct 22, 2007, at 2:24 AM, CS Lee wrote:
>
> Hi Carter,
>
> First of all, congratulations for the argus 3.0 release, and I'm looking
> forward for the client suite to reach that state.
>
> For ratop question, yes, it is over 1000 records per second.
>
> The explanation of radark is brilliant. And I have question regarding it,
> I tried the command in the radark -
>
> Here's my data -
>
> ra -nnr loadbalance.arg - ip
> 19:33:06.063023 e 6 10.0.0.46.36024 ->
> 216.67.244.22.80 3 3 629 198 RST
> 19:33: 27.653232 e 6 10.0.0.46.45640 ->
> 216.67.244.22.80 2 2 140 138 RST
> 19:33:57.899913 e 6 10.0.0.46.2540 ->
> 216.67.244.22.80 2 1 108 60 RST
> 19:33:58.907789 e 6 10.0.0.46.2541 ->
> 216.67.244.22.80 2 1 108 60 RST
> 19:33:59.915817 e 6 10.0.0.46.2542 ->
> 216.67.244.22.80 2 1 108 60 RST
> 19:34:00.923744 e 6 10.0.0.46.2543 ->
> 216.67.244.22.80 2 1 108 60 RST
> 19:34:01.931729 e 6 10.0.0.46.2544 ->
> 216.67.244.22.80 2 1 108 60 RST
> 19:34:02.939714 e 6 10.0.0.46.2545 ->
> 216.67.244.22.80 2 1 108 60 RST
>
> Then I tried -
>
> racluster -M norep -r loadbalance.arg -w loadbalance.racluster
>
> racluster -M norep rmon -m smac saddr daddr -r loadbalance.racluster -
> appbytes gt 0
> 19:33:06.063023 e ip 10.0.0.46 <->
> 216.67.244.22 3 3 629 198 CON
> 19:33: 06.063023 e ip 216.67.244.22 <->
> 10.0.0.46 3 3 198 629 CON
>
> I'm pretty clear until this part. 10.0.0.0/24 is the local net.
>
> The first call to racluster() generates the list of src and dst IP
> addresses for flows that had some form of user data exchanged, creating two
> entries for each set of src/dst IP pairs (using the -M rmon we remove the
> src and dst semanitcs by creating entries (A -> B and B -> A).
>
> But when I do -
>
> racluster -M norep rmon -m smac saddr daddr -r loadbalance.racluster -w -
> - appbytes gt 0 | racluster -L0 -m smac saddr -s +smac - src net
> 10.0.0.0/24 and not dst net 10.0.0.0/24 and src pkts gt 0
> StartTime Flgs Proto SrcAddr Sport
> Dir DstAddr Dport SrcPkts DstPkts SrcBytes DstBytes
> State SrcMac
> 19:33:06.063023 e ip 10.0.0.46
> <-> 0.0.0.0 3 3 629
> 198 CON 0:1b:77:5b:f4:3f
> 19:33:06.063023 e ip 10.0.0.46
> <-> 0.0.0.0 3 3 198
> 629 CON 0:50:e8:2:3d:ca
>
> For me it doesn't look right especially the second record. I'm not clear
> about the purpose of second parsing.
>
> Thanks.
>
>
>
> On 10/7/07, Carter Bullard <carter at qosient.com> wrote:
> >
> > Hey CS Lee,No, unless your processing 1000's of records per second.
> > Use ^G to display the processing stats at the bottom of the
> > screen. How records per second are you processing?
> >
> > Carter
> >
> > On Oct 6, 2007, at 1:08 AM, CS Lee wrote:
> >
> > Hi all,
> >
> > I'm running argus dev on Ubuntu 7.04, and using ratop to monitor the
> > traffic in realtime. Is it normal that ratop utilizes lots of resources as I
> > have this -
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 14256 root 25 0 25572 19m 1164 R 98 0.9 1273:40 ratop
> >
> >
> >
> > --
> > Best Regards,
> >
> > CS Lee<geekooL[at]gmail.com>
> >
> > http://geek00l.blogspot.com
> >
> >
> >
>
>
> --
> Best Regards,
>
> CS Lee<geekooL[at]gmail.com>
>
> http://geek00l.blogspot.com
>
>
>
--
Best Regards,
CS Lee<geekooL[at]gmail.com>
http://geek00l.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20071023/4dbf8f75/attachment.html>
More information about the argus
mailing list