[Bro] Strange Issue with Live Capture

[Andrew Benson]

I just had an epiphany when thinking about your response: the site we're
dealing with configured the SPAN incorrectly. Looking back through, I'm
seeing *every* packet twice. I think they configured it to SPAN every port
on that switch, including the SPAN. I'm going to have them fix that, maybe
use the VLANs as the source as I had originally directed them.

--
AndrewB
Knowing is Half the Battle.

On 26 January 2015 at 12:38, Andrew Benson <abenson at gmail.com> wrote:

> I think if it were getting multiple copies of each packet, it'd be logging
> those as well. The dup3 on the card just duplicates the stream so each
> process receives the same traffic. If a process attaches to the stream
> (dag0:0, :2, and :4) that stream can't be attached from another process.
>
> Looking back we had some time over the weekend when the traffic was a
> little slower and it didn't have any errors. Likewise, we had a test at a
> previous site (mockup of this one) that didn't have the issue, and we've
> been using this setup for  a few years, this is just the first I've ever
> seen this issue. It's just really weird.
>
> I wonder how I could check to see if there's something causing bro to
> break when talking to the card? It's just weird that I can't recreate it
> anywhere else.
>
> --
> AndrewB
> Knowing is Half the Battle.
>
> On 26 January 2015 at 12:23, Aaron Gee-Clough <lists at g-clef.net> wrote:
>
>>
>> Right, so if it works with the pcaps, then there's clearly a problem with
>> bro's interaction with the card (hence my focusing on the load-balancing
>> aspect). If you're not load-balancing but are duplicating, are you sure
>> bro's not reading all three streams, and getting multiple copies of every
>> packet?
>>
>> I don't have experience with the 7.5G4, so I'm not sure how dup3 works.
>>
>> aaron
>>
>>
>> On 01/26/2015 02:14 PM, Andrew Benson wrote:
>>
>>> We are using the 7.5G4. We currently have it configured using dup3 to
>>> send
>>> all the traffic three streams (snort, bro, and tcpdump), so we're not
>>> load
>>> balancing between processes. I can verify against the pcaps that bro is
>>> reading the packet. It shows the S0 for the handshake, and then OTH for
>>> every packet after that. Every packet is accounted for.
>>>
>>>
>>> --
>>> AndrewB
>>> Knowing is Half the Battle.
>>>
>>> On 26 January 2015 at 10:21, Aaron Gee-Clough <lists at g-clef.net> wrote:
>>>
>>>
>>>> If I were to bet, I'd guess it has something to do with how the Endace
>>>> card is load-balancing packets across your bro workers. If the
>>>> retransmission packets are ending up on different workers than the
>>>> original session, then each worker will think it's got a new session,
>>>> and log it accordingly.
>>>>
>>>> How do you have the Endace card configured? (for the 9.2X2 I have,
>>>> n_tuple_select is the pertinent config option.)
>>>>
>>>> aaron
>>>>
>>>> On 01/26/2015 11:59 AM, Andrew Benson wrote:
>>>>
>>>>> We're currently using Endace DAG capture cards to feed directly to bro,
>>>>> snort, and a rolling packet capture.
>>>>>
>>>>> The network we're currently looking at has a high number of
>>>>>
>>>> retransmissions
>>>>
>>>>> (at one point we counted 45% of traffic being retransmissions).
>>>>>
>>>>> Bro is currently logging each packet as a separate connection in
>>>>>
>>>> conn.log,
>>>>
>>>>> and is failing to run the protocol analyzers correctly (i.e. it'll
>>>>> detect
>>>>> it as FTP, but will only log the action, not the login, response).
>>>>>
>>>>> What's weird is that if I run bro against the rolling pcap, it works
>>>>> correctly. This problem only occurs when bro is listening to the device
>>>>> directly.
>>>>>
>>>>> This problem is still occurring with 2.3.1, so I'm at a loss. I enabled
>>>>>
>>>> the
>>>>
>>>>> capture-loss module, and it's reporting 0%. The capture card doesn't
>>>>> seem
>>>>> to be dropping anything either.
>>>>>
>>>>> Seen anything similar or have any suggestions for
>>>>> troubleshooting/fixing?
>>>>>
>>>>> --
>>>>> AndrewB
>>>>> Knowing is Half the Battle.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Bro mailing list
>>>>> bro at bro-ids.org
>>>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>>>>
>>>>>  _______________________________________________
>>>> Bro mailing list
>>>> bro at bro-ids.org
>>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20150126/408028c7/attachment-0001.html