1.5 months ago we haggled over adding these and came close to converging,
and then I dropped the ball on trying to ice the deal :-(. (Well, I also
needed some time to lick my wounds, since I didn't get my way much on
syntax preferences! :-P)
Here's where I believe we wound up:
(1) Add bitwise
Hey, I use the dhcp analyzer because i cannot count on our dhcp logs. Not just
that, I do some detection around it.
> On Jun 15, 2018, at 2:38 PM, Vlad Grigorescu wrote:
>
> Yeah, I've mainly seen it used for shellshock. On top of that, I saw some
> scripts in GitHub that used it from:
>
> -
> On Jun 15, 2018, at 6:13 PM, Johanna Amann wrote:
>
> I actually am more concerned about the scripts that we ship with Bro itself
> :). Though it is nice to have for packages too...
>
> Johanna
Oh :-) I hadn't ran it on the scripts that come with bro.. it finds one
non-ascii char:
On 15 Jun 2018, at 14:40, Azoff, Justin S wrote:
>> On Jun 2, 2018, at 12:49 PM, Johanna Amann wrote:
>>
>> Hum. Would it make sense to introduce a test that checks all
>> script-files for non-ascii-characters?
>>
>> I can so see that happening again...
>>
>> Johanna
>>
>
>
> I added this as
On Fri, Jun 15, 2018 at 9:54 PM, Vern Paxson wrote:
> > it unclear on the logarithmic
> > counts. Take, for instance SaDtTtT. If I'm reading this correctly, I
> think
> > that means 10-99 retransmissions from orig, followed by 10-99 from resp,
> > then more retransmissions from orig (enough to
> it unclear on the logarithmic
> counts. Take, for instance SaDtTtT. If I'm reading this correctly, I think
> that means 10-99 retransmissions from orig, followed by 10-99 from resp,
> then more retransmissions from orig (enough to reach a total of 100-999),
> and similarly more from resp.
> On Jun 2, 2018, at 12:49 PM, Johanna Amann wrote:
>
> Hum. Would it make sense to introduce a test that checks all
> script-files for non-ascii-characters?
>
> I can so see that happening again...
>
> Johanna
>
I added this as one of the checks that packages.bro.org does,
Yeah, I've mainly seen it used for shellshock. On top of that, I saw some
scripts in GitHub that used it from:
- Michal:
https://github.com/michalpurzynski/bro-gramming/blob/master/dhcpr.bro
- Matthias: https://github.com/bro/bro-scripts/blob/master/roam.bro
- Grant Stavely:
> On Jun 15, 2018, at 5:18 PM, Seth Hall wrote:
>
> On the
> upside, you can handle both the old events and the new and they
> shouldn't impact each other (if you want to make a script work on
> multiple releases).
I ran into this on a script I got from somewhere, bash-cve-2014-6271.bro
On 15 Jun 2018, at 0:30, Michael Dopheide wrote:
> How was the determination made that it's not widely used? I don't
> recall a survey on the bro/bro-dev lists and there's clearly instances
> of it's use when searching github.
I didn't dig around much which I made that change. Generally the
I think this is a useful feature. I'm a bit unclear on the logarithmic
counts. Take, for instance SaDtTtT. If I'm reading this correctly, I think
that means 10-99 retransmissions from orig, followed by 10-99 from resp,
then more retransmissions from orig (enough to reach a total of 100-999),
and
> Here we will not have cases where some repetitions are logarithmic, and
> some (like for R) are not. I guess that makes sense, but I can see it
> potentially being confusing.
Yeah, I chewed on that too, but I don't see a better solution. The semantics
of repeated R are different, too (per the
I think I like these, the only small concern I have is...
> (2) A notion of "logarithmic counts" for history events: for certain
> events ('C' = checksum, 'T' = retransmission, and 'W' = zero window)
> the count is repeated on the 10th/100th/1000th/etc. occurrence. So a
> history
> I really like those ideas, especially the logarithmic count.
Cool :-).
> How much would it cost to have an event fired when those thresholds are
> crossed?
Nice thought. I think it would be too expensive if done for the first
instance, but for each of the backed-off instances it ought to be
> On Jun 1, 2018, at 11:37 AM, Azoff, Justin S wrote:
>
> I could never figure out what was causing the problem, and it's possible that
> not doing anything anymore is why it's better now. I'm mostly
> using for syncing input files across all the workers and one of
> them does have 300k
I really like those ideas, especially the logarithmic count.
How much would it cost to have an event fired when those thresholds are crossed?
> On Jun 15, 2018, at 10:41 AM, Vern Paxson wrote:
>
> I'm working on two enhancements to the $history tracking for connections
> that thought I'd tee
I'm working on two enhancements to the $history tracking for connections
that thought I'd tee them up for comments.
(1) A new history element, 'W'/'w', which means that a TCP receiver
advertised a zero window, indicating that the corresponding process
was unable to keep up with the
17 matches
Mail list logo
