On Fri, Jun 15, 2018 at 9:38 PM, Vlad Grigorescu wrote:
> Even if it's not widely used, I think it'd be a nicer user experience if
> we were to ship a script that handled dhcp_message, and raised the old
> events. We could mark the old events as deprecated, and remove them in the
> next version.
On 18 Jun 2018, at 15:09, Alan Commike wrote:
> With the default TSV, any change can break export into the various
> back-end log stores and SIEMs. When adding new fields, it would be
> nice to see them added to the end of the Info structure.
This was a complete rework on the logs and
On Fri, Jun 15, 2018 at 11:38 PM Seth Hall wrote:
>
> Ugh, I didn't consider that. Bro has re-reached the point where
> touching any number of things can set off an avalanche of problems like
> this.
>
The other aspect of Bro changes is in the logging format. This comment
isn't specifically
Thanks Vlad!
.Seth
On 16 Jun 2018, at 9:07, Vlad Grigorescu wrote:
> Yep, already working on it. :-)
>
> On Sat, Jun 16, 2018 at 6:26 AM, Seth Hall wrote:
>
>>
>> On 15 Jun 2018, at 17:22, Azoff, Justin S wrote:
>>
>>> The fix is a little trickier, you can't handle both events because the
>>>
No idea what’s in master. It should be trivial if you don’t remove the dhcp
analyzer completely.
> On Jun 16, 2018, at 6:07 AM, Vlad Grigorescu wrote:
>
> Yep, already working on it. :-)
>
>> On Sat, Jun 16, 2018 at 6:26 AM, Seth Hall wrote:
>>
>> On 15 Jun 2018, at 17:22, Azoff, Justin S
Yep, already working on it. :-)
On Sat, Jun 16, 2018 at 6:26 AM, Seth Hall wrote:
>
> On 15 Jun 2018, at 17:22, Azoff, Justin S wrote:
>
> > The fix is a little trickier, you can't handle both events because the
> > DHCP::Msg type no longer exists and you need to wrap the old event
> > with
> >
On 15 Jun 2018, at 17:22, Azoff, Justin S wrote:
> The fix is a little trickier, you can't handle both events because the
> DHCP::Msg type no longer exists and you need to wrap the old event
> with
>
> @ifdef (DHCP::Msg)
> @endif
Ugh, I didn't consider that. Bro has re-reached the point
On 15 Jun 2018, at 20:02, Michał Purzyński wrote:
> Hey, I use the dhcp analyzer because i cannot count on our dhcp logs.
> Not just that, I do some detection around it.
How much trouble is it to migrate your scripts to what's in Bro master?
.Seth
--
Seth Hall * Corelight, Inc *
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:
>
> -
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
While testing the new Broker code in master I came across this a bit
unexpectedly when trying to run our full production policy stack:
2.5-544 | 2018-05-01 17:57:15 -0500
* Rewrite the DHCP analyzer and accompanying script-layer API.
I'm all for analyzer updates and improvements, but what I'm
13 matches
Mail list logo
