Differentiating between arp requests and arp replies inargus records
Carter Bullard
carter at qosient.com
Mon Feb 18 18:10:39 EST 2008
Hey Kevin,
The filter:
'arp host x.y.z.w'
works for me. And you can specify all the variations like:
arp src host x.y.z.w
Does that do what you wanted? Or is there another variation
that you would like?
Multiple packet counts for arp requests result when the source
sends out multiple requests before receiving a reply. Since there
really isn't a sequence number in arp packets, there is not
enough information to differentiate the request/response
volleys, and so we have to lump them together.
The response logic is basically if you have a flow such that
the request/response counts are 1:1, and its a protocol that is
a request/response type of protocol, then we'll output the record.
If there are multiple requests before a response, we'll output
the record after the status interval has expired.
Carter
On Feb 18, 2008, at 5:38 PM, Kevin & Leah Branch wrote:
>
> Sorry Carter, it looks like something started working for the first
> time when I upgraded from ra-clients-3.0.0.rc.67 to rc.69 along with
> going to th -se latest argus package. Replied-to arp requests are
> indeed now mostly resulting in argus records with 1 src packet and 1
> dst packet. Other times I get argus arp records where the src pkts
> and dst packets are > 1 and equal to each other. Maybe this is when
> a given arp request/reply pair is repeated soon enough that it falls
> under the same flow as the previous matching pair? If this is the
> case, is there somewhere I could tune this so that my arp request/
> reply pairs show up in distinct argus records? That would make my
> statistical analysis a little easier.
>
> Also, when I want to use an ra command to show arp requests by or
> for a given IP, I still can't do it, at least with the "host"
> primitive. It's a pity, because the host IP data really is in
> there, as I observe in the xml output of this example arp record.
>
> <ArgusRecord
> StartTime = "16:39:26.750669" Flags = " M " Proto = "arp"
> SrcAddr = "172.18.4.190" Dir = "who" DstAddr = "172.18.0.1" Pkts =
> "16" Bytes = "960" State = "CON" SrcPkts = "8" DstPkts = "8"
> SrcMacAddr = "0:1c:23:f:c9:d3"
> />
>
> Is there possibly some little tweak needed to allow ra filter
> expressions to use the "host" primitive for "arp" protocol records?
>
> Thanks for the improvements you've already make!
> Kevin
>
>
>
> From: klkbranch at hotmail.com
> To: carter at qosient.com
> Subject: RE: [ARGUS] Differentiating between arp requests and arp
> replies inargus records
> Date: Mon, 18 Feb 2008 21:24:08 +0000
>
> Hi Carter,
>
> I was just wondering if you had a chance to look at that sample
> capture of arp traffic you asked me to send you. My troubles with
> arp and argus don't appear to be confined to just one type of
> device. I have the same trouble whether it's my Juniper
> Netscreen-25 arping or my Cisco 2811 router arping -- argus accounts
> for absolutely no arp replies even though my sniff points are
> positioned where they really do see the replies (as seen with
> tcpdump). In cases where there really was an arp request and a
> related reply, argus produces a single "who" record that reports one
> src packets and zero dst packets. And when there is a cluster of
> repeated unanswered arp-requests, argus seems to make a single "who"
> records reporting numerous src packets and zero dst packets. Also,
> I never ever see any "is-at" records. If you'd like me to resend
> the capture file or send you more specific details, I'd be happy to.
>
> Separately, if I want to filter argus records of arps based on arp
> source IP or arp dest IP, any use of the "host" primitive always
> results in zero output. Perhaps ra doesn't like to use "host" with
> a packet that isn't really an IP protocol?
>
> I'd love to be able to work better with my argus record of arp
> traffic. I like to use simple arp traffic statistical analysis as a
> way to passively detect scanning within a local subnet on my LAN.
> The newest argus and racluster would enable me to do this much more
> cleanly than the cobbled-together Perl script I previously wrote for
> the job.
>
> Thanks!
> Kevin
>
>
>
> From: klkbranch at hotmail.com
> To: carter at qosient.com
> Subject: RE: [ARGUS] Differentiating between arp requests and arp
> replies inargus records
> Date: Fri, 11 Jan 2008 18:47:25 +0000
>
>
> Hi Carter,
>
> Sure, a sample is attached, arps.cap, and below is a transcript of
> me working with that file. Thanks for looking into it.
>
> tcpdump -r arps.cap -nn
> reading from file arps.cap, link-type EN10MB (Ethernet)
> 15:15:38.515522 arp who-has 172.18.4.90 tell 172.18.0.1
> 15:15:38.515841 arp reply 172.18.4.90 is-at 00:11:43:19:6d:13
> 15:15:38.895420 arp who-has 172.18.5.108 tell 172.18.0.1
> 15:15:38.895605 arp reply 172.18.5.108 is-at 00:0f:1f:85:0b:86
> 15:15:40.512483 arp who-has 172.18.4.103 tell 172.18.0.1
> 15:15:40.512864 arp reply 172.18.4.103 is-at 00:12:3f:13:1c:bb
> 15:15:42.506032 arp who-has 172.18.3.64 tell 172.18.0.1
> 15:15:42.506130 arp reply 172.18.3.64 is-at 00:30:6e:13:f6:fa
> 15:15:44.500834 arp who-has 172.18.5.33 tell 172.18.0.1
> 15:15:44.501151 arp reply 172.18.5.33 is-at 00:15:c5:40:3e:86
>
> argus -r arps.cap -w arps.arg
>
> ra -r arps.arg -nn
> 15:15:38.515522 e arp 172.18.0.1
> who 172.18.4.90 1 60 INT
> 15:15:38.515841 e arp 172.18.0.1
> who 172.18.4.90 1 60 INT
> 15:15:38.895420 e arp 172.18.0.1
> who 172.18.5.108 1 60 INT
> 15:15:38.895605 e arp 172.18.0.1
> who 172.18.5.108 1 60 INT
> 15:15:40.512483 e arp 172.18.0.1
> who 172.18.4.103 1 60 INT
> 15:15:40.512864 e arp 172.18.0.1
> who 172.18.4.103 1 60 INT
> 15:15:42.506032 e arp 172.18.0.1
> who 172.18.3.64 1 60 INT
> 15:15:42.506130 e arp 172.18.0.1
> who 172.18.3.64 1 60 INT
> 15:15:44.500834 e arp 172.18.0.1
> who 172.18.5.33 1 60 INT
> 15:15:44.501151 e arp 172.18.0.1
> who 172.18.5.33 1 60 INT
> 13:40:51.273611 man 0
> 0 21 1 10 876040 STP
>
> Say, are there any ra filter primitives that I can use against the
> who-has, is-at, and tell IP numbers in arp packets? I've tried the
> "host" primitive but that doesn't catch things. For example:
>
> ra -r arps.arg - host 172.18.0.1 -nn
>
> gets no results.
>
> Thanks,
> Kevin
>
>
>
>
> > To: klkbranch at hotmail.com; argus-info-
> bounces at lists.andrew.cmu.edu; argus-info at lists.andrew.cmu.edu
> > Subject: Re: [ARGUS] Differentiating between arp requests and arp
> replies inargus records
> > From: carter at qosient.com
> > Date: Thu, 10 Jan 2008 21:50:20 +0000
> >
> > Hey Kevin,
> > Argus does have a bi-directional flow model for arp, and it works
> great for me. If you have a packet file that has arps in it that
> don't seem to work, then send them on, and I'll take a look.
> >
> > Argus's flow model for arp has all the information that you are
> looking for, I believe. If you get an arp reply without a request,
> you should see 'is-at' instead of 'who'. Of course, this is assuming
> that it works.
> >
> > Capture a file of arp packets from your machine an we'll see if it
> is really broken!!!
> >
> > Carter
> >
> >
> > Carter Bullard
> > QoSient LLC
> > 150 E. 57th Street Suite 12D
> > New York, New York 10022
> > +1 212 588-9133 Phone
> > +1 212 588-9134 Fax
> >
> > -----Original Message-----
> > From: Kevin & Leah Branch <klkbranch at hotmail.com>
> >
> > Date: Thu, 10 Jan 2008 20:54:56
> > To:<argus-info at lists.andrew.cmu.edu>
> > Subject: [ARGUS] Differentiating between arp requests and arp
> replies in
> > argus records
> >
> >
> > I'm running the January 2008 argus-3.0.0 and ra-clients-3.0.0.rc.67
> >
> > I'm not sure how argus intends to handle arp packets, since they
> aren't exactly IP traffic. In my environments at least, argus does
> not pair up an arp request and its reply into a single argus record,
> but actually I think I like that since it preserves more details of
> the arp traffic. Given this fact, it does seem funny to me that at
> times when there are clusters of repeated identical arp-requests,
> that argus will create a single record for them. In that case argus
> sets the record as having many source packets, which makes sense.
> However, I have never seen an argus arp record with more than zero
> destination bytes. I guess arp conversations aren't being treated
> as stateful but blabbering of identical arp requests does get
> aggregated into single r
> >
> > My main question about argus and arps, though, is how am I to tell
> the requests from the replies?
> >
> > Here is an example ra output of an arp request and its reply
> >
> > ra -r arps.arg -s +dpkts -L0
> > StartTime Flgs Proto SrcAddr Sport
> Dir DstAddr Dport TotPkts TotBytes State DstPkts
> > 15:15:38.515522 e arp 172.18.0.1
> who 172.18.4.90 1 60 INT 0
> > 15:15:38.515841 e arp 172.18.0.1
> who 172.18.4.90 1 60 INT 0
> >
> > They look the same to me. In fact, the only way I can tell which
> is which is by looking at the mac addresses
> > StartTime Flgs Proto SrcAddr Sport
> Dir DstAddr Dport TotPkts TotBytes State
> DstPkts SrcMac DstMac
> > 15:15:38.515522 e arp 172.18.0.1
> who 172.18.4.90 1 60 INT 0
> 0:10:db:1b:1d:80 Broadcast
> > 15:15:38.515841 e arp 172.18.0.1
> who 172.18.4.90 1 60 INT 0
> 0:11:43:19:6d:13 0:10:db:1b:1d:80
> >
> > The record with the broadcast dest mac is the request and the one
> with the unicast dest mac is the reply. That's fairly predictable,
> unless you think someone is arp poisoning you. If you're
> researching arp shenanigans, this isn't so clear.
> >
> > I was just wondering if there might be some way to disambiguate
> arp requests from arp replies. Maybe instead of giving all arp
> packtets, be they requests or replies, the direction attribute of
> 'who', that attribute could be 'who' for request and 'is-at' for
> replies or something like that? Or perhaps there is some other
> record attribute I'm just missing that would clears this all up for
> me.
> >
> > Many thanks for any input you all can give,
> > Kevin
> >
> >
> > ----------------
> > Watch “Cause Effect,” a show about real people making a real
> difference. Learn more
>
> Make distant family not so distant with Windows Vista® + Windows
> Live™. Start now!
>
> Shed those extra pounds with MSN and The Biggest Loser! Learn more.
>
> Connect and share in new ways with Windows Live. Get it now!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20080218/70c3198b/attachment.html>
More information about the argus
mailing list