Re: [Bro-Dev] attributes & named types

[Vlad Grigorescu]

On Mon, Nov 5, 2018 at 4:40 PM Robin Sommer  wrote:

>
>
> On Sat, Nov 03, 2018 at 21:58 +0000, Vlad Grigorescu wrote:
>
> > In my mind, if the keyword is applied to a record, I would expect any new
> > fields added to that record to also be logged.
>
> I believe the reason for not doing that is that then one couldn't add
> a field that's *not* being logged (because currently we don't have
> remove-an-attribute support).
>

Yeah, I think the reasoning makes sense, and that seemed to be the
consensus from the discussion on bro-dev in 2011. My point is simply that
with the current behavior, it's not clear (or, AFAICT, documented) that
adding  to a record is just a shorthand for adding  to each
attribute, and that it really has no meaning for the record as a whole.

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] attributes & named types

[Vlad Grigorescu]

On Sat, Nov 3, 2018 at 9:14 PM Vern Paxson  wrote:

> Thanks for the pointers & thoughts!  A quick question, more in a bit:
>
> > To better understand the existing behavior, here's the commit that
> > introduced this (specifically with regards to conn_id):
> >
> https://github.com/bro/bro/commit/38a1aa5a346d10de32f9b40e0869cdb48a98974b
> > ...
> > > Note that for nested record types, the inner fields must likewise
> > > be declared with  Consequently, conn_id is now declared with
> > >  in bro.init.
>
> Does your understanding of this accord with the current behavior when
> running on testing/btest/scripts/base/frameworks/logging/attr.bro ?
> The test suite result has it not logging Log$id, even though it's of
> type conn_id, which has   (For my new version, it does log it.)
>

Hmm. I had to think about this for a bit, and I think it does agree with
the commit message. It's rather subtle, but because the message talks about
how the fields "must likewise be declared with ," I can see how the
expectation would be that *both* the conn_id declaration in init-bare and
the usage in your record need to have the  keyword to be logged.
However, before reading that commit message, that was not my expectation
for how Bro would behave.

I've been playing around with this a bit more, and I think that what's
described in the commit message is not the current behavior. Specifically,
the following seem to behave the same:

type conn_id: record {
> orig_h: addr;
> orig_p: port;
> resp_h: addr;
> resp_p: port;
> } 
>

type conn_id: record {
> orig_h: addr 
> orig_p: port 
> resp_h: addr 
> resp_p: port 
> };
>

This example demonstrates that all fields are still logged:
http://try.bro.org/#/trybro/saved/275829

In my mind, if the keyword is applied to a record, I would expect any new
fields added to that record to also be logged. However, if I use conn_id as
defined in init-bare (with  applied to the record), and I redef conn_id
as follows, it will not log the new field:

redef record conn_id += {
> nolog: bool 
> }
>

I believe that applying  to a record is just shorthand to applying it
individually to all fields on that record, whenever you define or redef
that record.

Simply put, I think the current behavior is not correct, and that we should
take this opportunity to determine what the behavior *should* be.

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] attributes & named types

[Vlad Grigorescu]

To better understand the existing behavior, here's the commit that
introduced this (specifically with regards to conn_id):
https://github.com/bro/bro/commit/38a1aa5a346d10de32f9b40e0869cdb48a98974b

> The  keyword now operates as discussed:
>
> - When associated with individual record fields, it defines them
>   as being logged.
>
> - When associated with a complete record type, it defines all fields
>   to be logged.
>
> - When associated with a record extension, it defines all added
>   fields to be logged.
>
> Note that for nested record types, the inner fields must likewise
> be declared with  Consequently, conn_id is now declared with
>  in bro.init.
>
> I think the discussion this is referring to is here:
http://mailman.icsi.berkeley.edu/pipermail/bro-dev/2011-March/001107.html

On Sat, Nov 3, 2018 at 7:34 PM Vern Paxson  wrote:

> (2) This makes me wonder about adding an operator to *remove* an
> attribute if present.  For example, you could imagine wanting
> to now do something like:
>
> type my_conn_info: record {
> id: conn_id -
> ...
> };
>
> as a way of specifying "if conn_id's have a  attribute,
> I don't want to inherit it".
>

I've found myself wishing to remove an attribute recently, so this train of
thought is relevant. I had imagined something slightly different, which was
to maintain  as it currently exists, but to also be able to explicitly
set it to T or F, e.g.:

> id: conn_id =F;

That would allow me to also be able to use redefs to configure whether or
not I want to log something:

> const log_conn = T 
> ...
> id: conn_id =log_conn;

I think that if we add something like this for , it might make sense to
add it for other keywords too.

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Any 2.6 release blockers?

[Vlad Grigorescu]

Ok, just submitted: https://github.com/bro/bro/pull/198

On Mon, Oct 29, 2018 at 7:24 PM Vlad Grigorescu  wrote:

> I'd really like to fix this: https://github.com/bro/bro/issues/195
>
> I've gotten reports from a few people that that fills up the disk in
> environments that encrypt MySQL. I'll take one more crack at it now.
>
>   --Vlad
>
> On Mon, Oct 29, 2018 at 7:22 PM Jon Siwek  wrote:
>
>> Anyone have any last minute issues that would block the 2.6 release?
>>
>> Or any remaining changes (bug fixes) they want to still try to get into
>> it?
>>
>> - Jon
>> ___
>> bro-dev mailing list
>> bro-dev@bro.org
>> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>>
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Any 2.6 release blockers?

[Vlad Grigorescu]

I'd really like to fix this: https://github.com/bro/bro/issues/195

I've gotten reports from a few people that that fills up the disk in
environments that encrypt MySQL. I'll take one more crack at it now.

  --Vlad

On Mon, Oct 29, 2018 at 7:22 PM Jon Siwek  wrote:

> Anyone have any last minute issues that would block the 2.6 release?
>
> Or any remaining changes (bug fixes) they want to still try to get into it?
>
> - Jon
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] bro-pkg Bro version requirements

[Vlad Grigorescu]

It strikes me that as Bro development marches on, package maintainers don't
have great choices in terms of maintaining compatibility with multiple Bro
versions. For JA3, to maintain compatibility, you have to do something like
this, due to the SSL event change:

@if ( Version::at_least("2.6") )
> event ssl_client_hello(c: connection, version: count, record_version:count,
> possible_ts: time, client_random: string, session_id: string, ciphers:
> index_vec, comp_methods: vector of count) =1
> @else
> event ssl_client_hello(c: connection, version: count, possible_ts: time,
> client_random: string, session_id: string, ciphers: index_vec) =1
> @endif
>

That works, but I worry that the overhead of trying to maintain that will
grow out of hand. I'm wondering if there's a better mechanism for this. A
naive approach might be to include an option in the package metadata, which
specifies minimum/maximum Bro versions that it requires. The installer,
then, would simply install the latest version that supports your Bro
version.

I don't want to overcomplicate things, but it does feel like there's a
mechanism that's currently missing.

Any other thoughts?

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] SSH Capabilities Bug: Fix for 2.6?

[Vlad Grigorescu]

Just for anyone who wanted some closure on this, I've submitted the PR:
https://github.com/bro/bro/pull/191

On Mon, Oct 15, 2018 at 10:21 PM Vlad Grigorescu  wrote:

> Sure, I'll do that.
> On Mon, Oct 15, 2018 at 16:19 Jon Siwek  wrote:
>
>> On Mon, Oct 15, 2018 at 3:33 PM Vlad Grigorescu  wrote:
>>
>> > The SSH Capabilities record has the following field, which is being set
>> incorrectly:
>> >
>> >> ## Are these the capabilities of the server?
>> >> is_server:  bool;
>> >
>> >> result->Assign(6, new Val(${msg.is_orig}, TYPE_BOOL));
>> >
>> > Obviously, I'd like to fix this. I'm curious to hear thoughts about
>> getting this into 2.6.
>>
>> Yes, that seems like a bug fix that can be included in 2.6.  Do you
>> want to make a PR for that and verify/update any unit test baselines
>> that change?
>>
>> - Jon
>>
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] SSH Capabilities Bug: Fix for 2.6?

[Vlad Grigorescu]

Sure, I'll do that.
On Mon, Oct 15, 2018 at 16:19 Jon Siwek  wrote:

> On Mon, Oct 15, 2018 at 3:33 PM Vlad Grigorescu  wrote:
>
> > The SSH Capabilities record has the following field, which is being set
> incorrectly:
> >
> >> ## Are these the capabilities of the server?
> >> is_server:  bool;
> >
> >> result->Assign(6, new Val(${msg.is_orig}, TYPE_BOOL));
> >
> > Obviously, I'd like to fix this. I'm curious to hear thoughts about
> getting this into 2.6.
>
> Yes, that seems like a bug fix that can be included in 2.6.  Do you
> want to make a PR for that and verify/update any unit test baselines
> that change?
>
> - Jon
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] SSH Capabilities Bug: Fix for 2.6?

[Vlad Grigorescu]

During BroCon, someone brought a bug in the SSH analyzer to my attention.

The SSH Capabilities record has the following field, which is being set
incorrectly:

## Are these the capabilities of the server?
> is_server:  bool;
>


> result->Assign(6, new Val(${msg.is_orig}, TYPE_BOOL));
>

Obviously, I'd like to fix this. I'm curious to hear thoughts about getting
this into 2.6. I know that the hassh package currently works around the
broken logic.

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] S7Comm/S7CommPlus Analyzer

[Vlad Grigorescu]

Hi Dane,

Thanks for sending this along. I'll have to check it out.

One thing I noticed -- do you mind filling out the license in
COPYING.edit-me? Without a valid copyright, it's hard to figure out what
all we can do this. Thanks,

  --Vlad

On Sun, Sep 23, 2018 at 3:04 PM DW  wrote:

> Hi there,
>
> as a part of my master's thesis I wrote a protocol analyzer for the
> Siemens protocols S7Comm and S7CommPlus.
>
> I posted the code on my GitHub repository, which can be seen here:
>
> https://github.com/dw2102/S7Comm-Analyzer
>
> The S7Comm nearly covers all protocol functions and was tested on .pcap
> files I generated with a Siemens S7-1204 and other files which I found
> on other GitHub repositores.
> The S7CommPlus analyzer isn't finished yet. It covers all base
> functions, but without handeling the data of the packets. There is a lot
> to do, like fragmentation, parsing of data, testing etc. which I
> couldn't do, because it would have exceeded my time limit.
>
> Feel free to use, modify or share it.
>
> Dane
>
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] JIRA to GitHub ticket migration plan

[Vlad Grigorescu]

On Sat, Sep 15, 2018 at 1:28 AM Robin Sommer  wrote:

> Are Jenkins and Coverity already pulling from GitHub?
>

No, I thought Jenkins was pushing to Coverity.

Is the plan to have GitHub issues within each repo? That is, bro, binpac,
etc. I think we'd lose the easy way to see all issues, but if I recall,
there was a way in GitHub to see issues across a few repos. Maybe by
organization?

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] DHCP event removal

[Vlad Grigorescu]

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. That way, people have at least one cycle to upgrade.
>

I have a branch that implements this, topic/vladg/dhcp_event_deprecation.
You would need to load policy/protocols/dhcp/deprecated_events.bro.

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] DHCP event removal

[Vlad Grigorescu]

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
> >
> > @ifdef (DHCP::Msg)
> > @endif
>
> 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.
>
> Anyone on this thread up for submitting a patch which makes Bro cope
> with the changes automatically?  You can then even mark the old events
> as deprecated. :)
>
>   .Seth
>
> --
> Seth Hall * Corelight, Inc * www.corelight.com
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] $history extensions - zero windows, logarithmic counts

[Vlad Grigorescu]

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 reach a total of 100-999),
> > and similarly more from resp.
>
> Correct in principle.  (1) These would be 1-9 followed by enough to
> get to 10-99, since a single retransmission is already a 't' / 'T', and
> (2) lower letters are responders rther than originators.
>

Ah, right. Thanks for clearing that up.


> > Maybe we add the
> > new letters, but don't repeat them and also add new fields for exact
> > bytecounts?
>
> I'm not following this.  If we add new letters that don't repeat *and* we
> add new fields, why do we need the letters given that the fields are there?
>

My thought for this was simply if it mattered *where* in the state history
the trouble occurred. For instance, if I'm seeing retransmissions at the
very end of a connection, that might indicate that one side abruptly
terminated the connection (I'd see this with things like fail2ban inserting
an iptables rule to block a brute-forcer). Similarly, if I see a zero
window at the start of a connection, that would tell me that the buffer was
full due to another connection or connections, as opposed to filling up due
the connection I'm looking at.

I'm having a tough time thinking up additional use-cases without having
some sample data, so perhaps the best course is to add what you proposed,
and then revisit it if we feel like anything's missing.

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] DHCP event removal

[Vlad Grigorescu]

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:
https://github.com/evernote/bro-scripts/blob/master/bolo/scripts/main.bro
- Anthony: https://github.com/anthonykasza/users/blob/master/users.bro

(There were a few others, like IVRE, but they've already updated).

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. That way, people have at least one cycle to upgrade.

Hopefully, as we see more published Bro packages, we have a better idea of
which events are/aren't being used.

  --Vlad

On Fri, Jun 15, 2018 at 9:22 PM, Azoff, Justin S 
wrote:

> > 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
>
> 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
>
> So for that script I ended up with
>
> @ifdef (DHCP::Msg)
> event dhcp_message(c: connection, is_orig: bool, msg: DHCP::Msg, options:
> DHCP::Options)
> {
> if ( options?$host_name && shellshock in options$host_name )
> NOTICE([$note=Bash::DHCP_hostname_Attack,
> $conn=c,
> $msg=fmt("%s may have attempted to exploit
> CVE-2014-6271, bash environment variable attack, via dhcp hostname against
> %s submitting \"hostname\"=\"%s\"",c$id$orig_h, c$id$resp_h,
> options$host_name),
> $identifier=c$uid]);
> }
> @else
> event dhcp_offer(c: connection, msg: dhcp_msg, mask: addr, router:
> dhcp_router_list, lease: interval, serv_addr: addr, host_name: string)
> {
> if ( shellshock in host_name )
> NOTICE([$note=Bash::DHCP_hostname_Attack,
> $conn=c,
> $msg=fmt("%s may have attempted to exploit
> CVE-2014-6271, bash environment variable attack, via dhcp hostname against
> %s submitting \"hostname\"=\"%s\"",c$id$orig_h, c$id$resp_h, host_name),
> $identifier=c$uid]);
> }
> @endif
>
>
>
> —
> Justin Azoff
>
>
>
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] $history extensions - zero windows, logarithmic counts

[Vlad Grigorescu]

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 similarly more from resp. However, I could also interpret it as 10-99
from orig, 10-99 from resp, 10-99 from orig, 10-99 from resp.

Another question I had was that most of these are TCP-specific. Would
checksum apply to UDP as well?

One downside of the logarithmic approach is that it makes it hard to search
for, since searching for 't.*t' means one thing for small conns, and
another for large conns. As you say, if what I care about is the overall
number compared to the number of packets, that feels more like a
percentage. To me, it'd seem more natural to use something like "0t" means
"of the total number of packets from the originator, 0-9% were
retransmissions," "1t" means 10-19%, etc.

What I'm left debating is whether adding numerical data to history is the
right approach, though. missed_bytes is a separate field, but it feels
similar. If we did something like the log approach for that, we'd lose
exact counts, but we'd have granularity on the direction. Maybe we add the
new letters, but don't repeat them and also add new fields for exact
bytecounts?

 --Vlad



On Fri, Jun 15, 2018 at 6:51 PM, Vern Paxson  wrote:

> > 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 recent $history thread, it
> entails
> differing sequence numbers), so I think once that's the case, then it's
> not all that much more confusing if the significance of a repetition has
> different semantics too.
>
> Vern
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] bro-devel package?

[Vlad Grigorescu]

There are a couple of cases where I think it'd be useful to have a
bro-devel package -- a package that I can install on a system, and then be
able to build plugins against Bro. (This is the same model as other *-devel
packages, such as openssl, libpcap, etc.)

Right now, if I compile Bro from source, run make install, I can't build a
package with what's in /usr/local -- Bro needs the entire source tree,
since the required headers are not present in /usr/local.

I'm curious how people are dealing with this issue, and if anyone has
thoughts on whether this would be useful, and if so, what it would take to
build such a package.

Thanks,

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] How to deal with stale branches?

[Vlad Grigorescu]

Yeah, that's certainly one option, but I think it'd be hard for people to
find.

On Thu, Apr 26, 2018 at 8:15 PM, Jon Siwek <jsi...@corelight.com> wrote:

>
>
> On 4/26/18 11:06 AM, Vlad Grigorescu wrote:
>
> I'm torn between deleting the branches, in an effort to not clog up git
>> with unneeded branches, and leaving them around or perhaps archiving them
>> somewhere, in order to not completely lose the work in case it's of value
>> to someone down the road.
>>
>> I'm curious if anyone has thoughts on the best way to proceed.
>>
>
> Maybe delete the branch from the official git repo and push it to your own
> github fork.
>
> - Jon
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] How to deal with stale branches?

[Vlad Grigorescu]

I have a couple of branches that, for whatever reason, aren't headed for a
merge request into master. The branches were left around for reference, in
case someone wanted to pick up and continue the work. However, this too now
looks very unlikely, as some of these are several years old, and of
questionable value at this point.

I'm torn between deleting the branches, in an effort to not clog up git
with unneeded branches, and leaving them around or perhaps archiving them
somewhere, in order to not completely lose the work in case it's of value
to someone down the road.

I'm curious if anyone has thoughts on the best way to proceed.

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Weirdness with event ssh_capabilities

[Vlad Grigorescu]

Hi John,

First, here's code that works: http://try.bro.org/#/trybro/saved/228261
(This is longer, because technically, clients and servers can specify
different algs for each direction).

Here's the relevant bit of Bro code:
https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro#L225

c$ssh$capabilities is only designed for internal use. The comment for it[1]
says "Store capabilities from the first host for comparison with the second
(internal use)." So, yeah. It's basically exactly as you said. The data's
only stored there in order to find common algorithms once we see the other
KEX packet. If you want to access the raw capabilities coming from the
client or the server, you need to use the capabilities parameter in that
event.

I feel like there's a better way to document that that parameter is for
internal use only, but I'm not sure what it is.

Does that help?

  --Vlad

[1] - <
https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro#L125
>




On Tue, Apr 24, 2018 at 9:57 PM, John Althouse  wrote:

> Take a look
>
> http://try.bro.org/#/trybro/saved/228251
>
> In this instance, the client sent the Key Exchange Init packet first and
> the server sent it's Key Exchange Init packet second. The client packet
> actually contained the list of encryption algorithms seen here, but it's
> being printed out when I specify is_server == T, it should be printed when
> is_server == F, right?
>
> It also looks like ssh_capabilities is only capturing details within the
> first Key Exchange Init packet, whether that be the one from the server or
> the client, and ignoring the second one.
>
> So sometimes the server will send the KEI first, Bro captures that, then
> the client sends it's KEI and it looks like Bro ignores it. Same thing
> happens when it's the other way around. I want to be able to look at the
> details in both KEI's.
>
> Does this make sense? Does anyone know how this can be fixed or maybe I'm
> doing something wrong here?
>
> Thanks!
>
> John
>
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] UDP connection_established event?

[Vlad Grigorescu]

True, I'm just basing it off of Bro's mechanism to turn some UDP traffic
into "connections" that fit into its model.

I guess what I'm looking for is a connection_state_add to go with the
existing connection_state_remove. It wouldn't be UDP-specific, but it might
fit the current event model a bit better.

On Mon, Mar 5, 2018 at 4:55 AM, Jan Grashöfer <jan.grashoe...@gmail.com>
wrote:

> On 02/03/18 03:52, Vlad Grigorescu wrote:
> > I would like to propose a new event in Bro, one that would fire when a
> UDP
> > connection is established (i.e. a response is observed within some time
> > frame after a request is seen). Basically, the UDP equivalent of
> > connection_established.
> >
> > [...]
> >
> > Does anyone have thoughts about this?
>
> I definitely see the need to correlate request-response-pairs for UDP
> protocols but as UDP is *connectionless*, the term UDP connection sounds
> very strange to me. Maybe a general notion of request-response protocols
> could be established. Corresponding protocols could trigger general
> events. For some protocols there might be even a session concept.
>
> Jan
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] UDP connection_established event?

[Vlad Grigorescu]

I would like to propose a new event in Bro, one that would fire when a UDP
connection is established (i.e. a response is observed within some time
frame after a request is seen). Basically, the UDP equivalent of
connection_established.

Currently, I think the only way to do this would be either with
new_connection or with udp_reply. Neither of these seem like great
solutions, as they'd require keeping state in script-land, and most of the
events wouldn't be useful.

Does anyone have thoughts about this? Thanks,

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Configuration framework syntax proposal

[Vlad Grigorescu]

First of all, thanks to Johanna for getting this discussion going, and
thanks to everyone who's weighed in so far. I'm really excited to see this
feature in Bro, and I'm also happy to see how much interest this has
already garnered.

To extend what Seth said about our two user groups -- I think that this
feature is where those two groups intersect. While a lot of thought has
gone into what this looks like from an end-user perspective, I want to make
sure that we also make this easy and elegant from a developer's
perspective. Bro scripting already has a high barrier of entry, and I think
that we need to be careful not to raise that barrier further. As was
discussed during BroCon, I think that the Bro community is increasingly
relying on developers outside of the core team to contribute scripts -- and
that's a great thing!

I think that it's important to have this behavior come with a reasonable
default. I think that whatever we choose should just work out of the box.
For example, I think the existing construct should continue to work:

> const user_name: string 

At the end of the day, what we're discussing is how a developer should
document and expose a feature to an end-user. If, as a developer, I choose
a bad variable name, then I'm not providing a good experience for the
end-user, but that's my decision. I don't think that forcing developers to
essentially add documentation via syntactic sugar is the right approach. If
their variable names are confusing, people are less likely to use their
script.

I think that a lot of what users might want to re-configure is too complex
to be explained through a variable name anyway. We already have a system in
place to document variables, and I think that we need to rely on that
instead of focusing so much on which name is exposed to the user.

As we look at moving Bro scripts to packages, I think we need to look at
how other package repositories have handled similar configuration options.
Puppet Forge, for instance, has a types tab which documents the names of
the parameters, and what they do:
https://forge.puppet.com/puppetlabs/mysql/types This would be pretty easy
to do with the Broxygen documentation, and a UI could also expose this.

tl;dr version: I want to find something that makes life easy for both
developers and end-users, and I think we already have the documentation
mechanism in place to be more expressive about variables.

  --Vlad

On Thu, Sep 21, 2017 at 10:22 AM, Robin Sommer  wrote:

>
>
> On Thu, Sep 21, 2017 at 14:51 +, you wrote:
>
> > comments. Like Jan, I had a hard time understanding the benefit having
> > two names for the same value: the identifier and config string.
>
> Yeah, that's been my original concern as well. What if we focused that
> new attribute just on displaying something to the user:
>
> const user_name: string  _name="User name"
>
> A UI would show it as "User name", but everything else (incl.
> internally the configuration framework) would use
> My_Program::user_name. This would even work more generically, anything
> could have a _name and we'd have Broxygen pick up on it too.
>
> Robin
>
> --
> Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] Source Package for caf?

[Vlad Grigorescu]

About a year ago, I was trying to get the Bro test suite running in Travis
CI. To make this easier, I was trying to get caf added as a whitelisted
package to Travis CI. Unfortunately, this failed because there was no
source package available for caf:

https://travis-ci.org/travis-ci/apt-whitelist-checker/builds/125294748

Does anyone know if a source package for caf now exists? Thanks,

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] 2.5.1 release?

[Vlad Grigorescu]

Correct, I agree. I just did another review of CHANGES, and didn't spot
anything concerning. We'll look at upgrading our test cluster (and UIUC's
test cluster) to master.

On Fri, May 12, 2017 at 8:48 PM, Slagell, Adam J 
wrote:

>
>
> > On May 12, 2017, at 4:09 PM, Seth Hall  wrote:
> >
> > I'd be fine with that.  I think master is quite stable right now anyway
>
>
> I'm pretty sure Vlad is in agreement, but traveling today. I think Justin
> as well, but I should let him speak for himself.
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] Splitting up init-bare?

[Vlad Grigorescu]

What do people think about splitting up portions of init-bare into separate
files, and having init-bare simply @load those files? Right now, it's a
4500+ line script that keeps growing, and it commonly results in conflicts.

For the protocols, I could see having a file such as
protocols/kerberos/bare.bro which defines the appropriate types which are
currently in init-bare.

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] CBAN naming

[Vlad Grigorescu]

Having reread through the discussion, I want to try to take a step back and
review some of it.

I believe there are two goals in play:

1) From a user's perspective, the principle of least astonishment. Names
matter, and choosing something intuitive or familiar means we're not
raising the barrier to entry for a new user.
2) From a developer's perspective, submitting to "CBAN," maintaining and
updating their code should be as painless as possible. Let's not forget
that at the end of the day, the only thing that matters in making this
project successful or not is developer contributions. If people aren't
contributing, none of this has any point.

The first goal is the reason we moved away from bags and carts. However, I
think we're in danger of straying too far away from the second goal. I
think having containers which manage both scripts and plugins would be a
mistake.

A scenario that I see as being quite likely is that a developer starts such
a container as being script-only, but wants to expand it at some future
date. Say there's some new botnet with a domain-generation algorithm that
they would like Bro to predict and alert on. The script is functional, it's
being deployed, but it has a noticeable performance impact. After some
refactoring, the developer adds a BIF to do some string-formatting heavy
lifting in C++ instead of in script-land. At this point, how does the
script package get converted to a plugin? Is this a new container? Is it a
refactoring of the existing container? Will bro-pkg be smart enough to
remove the old scripts from the script package and make sure the scripts
from the plugin are being loaded?

I fear that in trying to reduce confusion over nomenclature, we're
complicating the design and introducing much more confusion. I believe
there are advantages to having script-only plugins. Easier iterative
development is one, but also having a well defined structure with a clear
place for btest (in fact, init-plugin even creates a simple btest when
creating the plugin).

I believe that any issues with the name of "plugin" versus "package" can
and will be quickly cleared up when the project is released. I'll note that
the script plugin component is actually the only one currently documented
here: https://www.bro.org/sphinx-git/devel/plugins.html

I also think that since many of our developer audience is on this list, and
we've been spamming them about this for the past 10 days, our user outreach
has already happened. :-)

  --Vlad

On Sun, Jun 5, 2016 at 5:26 PM, Siwek, Jon  wrote:

>
> > On Jun 5, 2016, at 11:51 AM, Slagell, Adam J 
> wrote:
> >
> > Regardless, it seems that you and Jon have irreconcilable differences
> that eliminate plugin or package. And as the PI and implementer, I give
> high weight to both of your opinions. Would either of you object to
> extensions?
> >
> > So while I *really* hate to do this, I will throw out bro-bee and Bro
> Extensions for Everyone.
>
> We haven’t had a lot of time to reconcile, but my stance is that it’s not
> logical to choose a project name that introduces ambiguity in the naming of
> the top-level containers it deals with.
>
> Some paths to move forward that I see:
>
> 1) revisit the design of what the top-level container is
>
> 2) use plugins as top-level container and project name that refers to
> plugins
>
> 3) use plugins as top-level container and project name that is totally
> unrelated to the container name
>
> 4) use plugins as top-level container, a project name that refers to them
> by a different name, and then suggest how docs should be written or
> re-organized to avoid ambiguity.  I’m only being slightly facetious here, I
> really would need extra help/effort with guidelines for what term to use in
> what situations.  e.g. is it ok to call it a “plugin” when referring
> directly to existing plugin docs, but I should use the other term
> otherwise?  Seems better to avoid the extra effort and strain this path
> puts on maintaining consistent/clear docs.
>
> - Jon
>
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] which of these Lintian error messages need tickets?

[Vlad Grigorescu]

I'll take a shot:


> *1. binary file built without LFS support*
> binpac:
> binary-file-built-without-LFS-support
> 
> usr/bin/binpac
>
> bro (2.4.1+dfsg-2+b3; main):
> binary-file-built-without-LFS-support
> 
> usr/bin/bro
>
> bro-aux (0.35-1):
> binary-file-built-without-LFS-support
> 
> usr/bin/nfcollector
>

binpac - probably not.
We should check to see what files bro-aux and bro are accessing with
support for large files.


> *2. binary without manpage*
> binpac (0.44-1):
> binary-without-manpage
> 
> usr/bin/binpac
> usr/bin/binpac
>
> btest (0.54-1):
> binary-without-manpage
> 
> usr/bin/btest
> usr/bin/btest-ask-update
> usr/bin/btest-bg-run
> usr/bin/btest-bg-run-helper
> usr/bin/btest-bg-wait
> usr/bin/btest-diff
> usr/bin/btest-diff-rst
> usr/bin/btest-rst-cmd
> usr/bin/btest-rst-include
> usr/bin/btest-rst-pipe
> usr/bin/btest-setsid
>

I think that these should be fixed. We really shouldn't be installing stuff
in /usr/bin without manpages. I think we have most of this already
documented, it'd just be a matter for formatting it the right way.


> *3. hardening no bindnow*
>  binpac (0.44-1):
> hardening-no-bindnow
> 
> usr/bin/binpac
> usr/bin/binpac
>
> bro (2.4.1+dfsg-2+b3; main):
> hardening-no-bindnow
> 
> usr/bin/bro
> usr/bin/bro
>
> bro-aux (0.35-1):
> hardening-no-bindnow
> 
> usr/bin/adtrace
> usr/bin/adtrace
> usr/bin/bro-cut
> usr/bin/bro-cut
> usr/bin/ftwire2bro
> usr/bin/ftwire2bro
> usr/bin/nfcollector
> usr/bin/nfcollector
> usr/bin/rst
> usr/bin/rst
>
> capstats (0.22-1):
> hardening-no-bindnow
> 
> usr/bin/capstats
> usr/bin/capstats
>

This would probably be easy enough to add, though I'm not sure how useful
it is.


> *4. hardening no pie*
> binpac (0.44-1):
> hardening-no-pie 
> usr/bin/binpac
> usr/bin/binpac
>
> bro (2.4.1+dfsg-2+b3; main):
> hardening-no-pie 
> usr/bin/bro
> usr/bin/bro
>
> bro-aux (0.35-1):
> hardening-no-pie 
> usr/bin/adtrace
> usr/bin/adtrace
> usr/bin/bro-cut
> usr/bin/bro-cut
> usr/bin/ftwire2bro
> usr/bin/ftwire2bro
> usr/bin/nfcollector
> usr/bin/nfcollector
> usr/bin/rst
> usr/bin/rst
>
> capstats (0.22-1):
> hardening-no-pie 
> usr/bin/capstats
> usr/bin/capstats
>

We have had a ticket about this, so it'd be nice to support ASLR with a
configure option rather than forcing the user to override CFLAGS.


> *5. no ctrl scripts*
> binpac (0.44-1):
> no-ctrl-scripts 
>
> bro (2.4.1+dfsg-2+b3; main):
> no-ctrl-scripts 
>
> bro-common:
> no-ctrl-scripts 
>
> bro-aux (0.35-1):
> no-ctrl-scripts 
>
> capstats (0.22-1):
> no-ctrl-scripts 
>

I don't really understand this.


> *6. static library has unneeded section*
> binpac (0.44-1):
> static-library-has-unneeded-section
> 
> usr/lib/libbinpac.a(binpac_buffer.cc.o) .comment
> usr/lib/libbinpac.a(binpac_buffer.cc.o) .comment
> usr/lib/libbinpac.a(binpac_bytestring.cc.o) .comment
> usr/lib/libbinpac.a(binpac_bytestring.cc.o) .comment
> usr/lib/libbinpac.a(binpac_regex.cc.o) .comment
> usr/lib/libbinpac.a(binpac_regex.cc.o) .comment
>

Probably would be easy enough to remove.


> *7. unused override*
> bro (2.4.1+dfsg-2+b3; main):
> unused-override 
> description-starts-with-package-name
>

I think this is on the maintainer of the package.


> *8. extended description is probably too short*
> bro-common:
> extended-description-is-probably-too-short
> 
>
> *9. ctrl script* (is this really an error? it doesn't seem like one)
> broctl (1.4-1):
> ctrl-script 
> postinst
> prerm
>
> btest (0.54-1):
> ctrl-script 
> postinst
> prerm
>
> *10. vcs field uses insecure uri*
> trace-summary (0.84-1):
> vcs-field-uses-insecure-uri
> 

[Bro-Dev] [JIRA] (BIT-1578) dns_unmatched_msg weird has no connection associated with it

[Vlad Grigorescu (JIRA)]

Vlad Grigorescu created BIT-1578:


 Summary: dns_unmatched_msg weird has no connection associated with 
it
 Key: BIT-1578
 URL: https://bro-tracker.atlassian.net/browse/BIT-1578
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: Bro
Affects Versions: git/master, 2.4
Reporter: Vlad Grigorescu
Assignee: Vlad Grigorescu


NCSA has about 3 million weirds for "dns_unmatched_msg" per day. Debugging this 
issue is very difficult, however, since the weird.log entries don't have uid, 
id.orig_h, id.orig_p, id.resp_h, id.resp_p, or addl set for the weirds.



--
This message was sent by Atlassian JIRA
(v1000.5.0#72002)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Deleting old branches

[Vlad Grigorescu]

Hooray, thanks for taking this on! I just did a quick check for branches
named ticket* or bit* and all those tickets have been closed (I wanted to
check if they had been left open with the idea that someone would circle
back to that branch and add feature X).

>From my end, all the topic/vladg branches can be deleted.

  --Vlad

On Mon, Apr 25, 2016 at 5:56 PM, Johanna Amann  wrote:

> Just one more warning - if no one complains, I will go ahead and delete
> all of this on Friday.
>
> Johanna
>
> On Wed, Apr 20, 2016 at 10:28:01AM -0700, Johanna Amann wrote:
> > Hi,
> >
> > we currently have a ton of branches in Bro which have been merged into
> > master (some of them a long time ago). And - I would like to delete them,
> > unless people think they are worth keeping around for some reason.
> >
> > To be more specific, the branches I would like to delete are:
> >
> > robin/topic/writer-info
> > topic/dnthayer/configure
> > topic/dnthayer/doc-fixes
> > topic/dnthayer/doc-fixes-for-2.3
> > topic/dnthayer/doc-improvements-2.4
> > topic/dnthayer/doc-updates
> > topic/dnthayer/fix-rdp
> > topic/dnthayer/langref
> > topic/dnthayer/mktemp
> > topic/dnthayer/ticket1160
> > topic/dnthayer/ticket1186
> > topic/dnthayer/ticket1206
> > topic/dnthayer/ticket1215
> > topic/dnthayer/ticket1467
> > topic/dnthayer/ticket1481
> > topic/dnthayer/ticket1503
> > topic/dnthayer/ticket856
> > topic/gilbert/plugin-api-tweak
> > topic/hui/dnp3-udp
> > topic/hui/modbus-events
> > topic/jazoff/notice_file_info
> > topic/jazoff/ssl-validation-fix
> > topic/jazoff/suppression
> > topic/jdopheid/BIT-1242
> > topic/jdopheid/bro/edits_to_installation_and_getting_started
> > topic/jdopheid/bro_documentation
> > topic/johanna/filter_subnet_table
> > topic/johanna/function-recursion
> > topic/johanna/openflow
> > topic/johanna/stats_smb_leak
> > topic/johanna/str-functions
> > topic/jsiwek/asan-fixes
> > topic/jsiwek/ascii-log-memleak-fix
> > topic/jsiwek/bif-loader-scripts
> > topic/jsiwek/bit-1077
> > topic/jsiwek/bit-1153
> > topic/jsiwek/bit-1156
> > topic/jsiwek/bit-1166
> > topic/jsiwek/bit-1176
> > topic/jsiwek/bit-1235
> > topic/jsiwek/bit-1240
> > topic/jsiwek/bit-1246
> > topic/jsiwek/bit-1247
> > topic/jsiwek/bit-1248
> > topic/jsiwek/bit-1280
> > topic/jsiwek/bit-1288
> > topic/jsiwek/bit-1295
> > topic/jsiwek/bit-1296
> > topic/jsiwek/bit-1298
> > topic/jsiwek/bit-1305
> > topic/jsiwek/bit-1324
> > topic/jsiwek/bit-1343
> > topic/jsiwek/bit-1350
> > topic/jsiwek/bit-1367
> > topic/jsiwek/bit-1368
> > topic/jsiwek/bit-1373
> > topic/jsiwek/bit-1376
> > topic/jsiwek/bit-1384
> > topic/jsiwek/bit-1408
> > topic/jsiwek/bit-342
> > topic/jsiwek/bit-348
> > topic/jsiwek/bit-788
> > topic/jsiwek/bit-844
> > topic/jsiwek/broccoli-vectors
> > topic/jsiwek/broker
> > topic/jsiwek/broxygen
> > topic/jsiwek/coverity
> > topic/jsiwek/deprecation
> > topic/jsiwek/dnp3-udp
> > topic/jsiwek/dns-perf
> > topic/jsiwek/dns_fake
> > topic/jsiwek/faf-perf
> > topic/jsiwek/faster-val-clone
> > topic/jsiwek/file-reassembly-merge
> > topic/jsiwek/file-signatures
> > topic/jsiwek/flip-roles
> > topic/jsiwek/gre
> > topic/jsiwek/http-file-id-caching
> > topic/jsiwek/improve-type-checks
> > topic/jsiwek/improve_comm_loop
> > topic/jsiwek/jemalloc
> > topic/jsiwek/jj-bugs
> > topic/jsiwek/libmagic-integration
> > topic/jsiwek/mime-multipart-boundary-leniency
> > topic/jsiwek/misc-fixes
> > topic/jsiwek/missing-pac-deps
> > topic/jsiwek/missing-plugin
> > topic/jsiwek/new-libmagic
> > topic/jsiwek/odesc-escaping
> > topic/jsiwek/outer_param_binding
> > topic/jsiwek/parse-only
> > topic/jsiwek/pktsrc-idle
> > topic/jsiwek/remove-val-attribs
> > topic/jsiwek/review-rafael-bro-manual-changes
> > topic/jsiwek/snmp
> > topic/jsiwek/socks-authentication
> > topic/jsiwek/string-slicing-fix
> > topic/jsiwek/tcp-improvements
> > topic/jsiwek/while
> > topic/matthias/bloomfilter-fix
> > topic/rafaelb/new-Bro-Manual-Development-Edition-Update1
> > topic/robin/ascii-escape-normalization
> > topic/robin/bit-348-merge
> > topic/robin/bpf-vector
> > topic/robin/dnp3-merge-v4
> > topic/robin/dynamic-plugins-2.3
> > topic/robin/event-dumper
> > topic/robin/http-connect
> > topic/robin/modbus-events-merge
> > topic/robin/pacf
> > topic/robin/pktsrc
> > topic/robin/plugin-updates
> > topic/robin/reader-writer-plugins
> > topic/robin/rework-packets-merge
> > topic/robin/smtp-fix
> > topic/seth/ascii-escape-normalization
> > topic/seth/compiler-cleanup
> > topic/seth/deflate-missing-headers-fix
> > topic/seth/dnp3-wrong-sizeof-argument
> > topic/seth/dns-srv-fix
> > topic/seth/file-analysis-exe-analyzer
> > topic/seth/file-entropy
> > topic/seth/files-reassembly-and-mime-updates
> > topic/seth/files-tracking
> > topic/seth/http-connect
> > topic/seth/ie11-software-parsing
> > topic/seth/json-formatter
> > topic/seth/mime-updates
> > topic/seth/modbus_dpd_fix
> > topic/seth/more-file-type-ident-fixes
> > topic/seth/radiotap
> > topic/seth/rdp
> > 

Re: [Bro-Dev] [JIRA] (BIT-1571) Connection summaries w/ IPv6 have poor readabiity

[Vlad Grigorescu]

I'm not sure I agree without additional context. ICMP exfil is a known
technique. Wouldn't you want to know if all of a sudden, you started seeing
gigs of ICMP? Or is there some other limitation that would make detecting
this problematic?

What I would recommend instead is simply adding the protocols to the ports.
So, instead of "top ports: 53, 80, 443, 8" you would see: "top ports:
53/udp, 80/tcp, 443/tcp, 8/icmp"

Would this be sufficient to solve the ICMP/port number confusion?

On Tue, Apr 26, 2016 at 8:07 AM, Adam Slagell (JIRA) <
j...@bro-tracker.atlassian.net> wrote:

>
> [
> https://bro-tracker.atlassian.net/browse/BIT-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25900#comment-25900
> ]
>
> Adam Slagell commented on BIT-1571:
> ---
>
> Talking with Seth, he agrees that it probably just makes more sense to
> leave ICMP out of the connection summaries.
>
> > Connection summaries w/ IPv6 have poor readabiity
> > -
> >
> > Key: BIT-1571
> > URL: https://bro-tracker.atlassian.net/browse/BIT-1571
> > Project: Bro Issue Tracker
> >  Issue Type: Improvement
> >  Components: BroControl
> >Affects Versions: 2.4
> >Reporter: Adam Slagell
> >Assignee: Daniel Thayer
> >Priority: Low
> > Fix For: 2,5
> >
> > Attachments: [Bro] Connection summary from 15_53_27-16_00_00.txt
> >
> >
> > The variable length of IPv6 and being mixed with IPv4 causes alignment
> issues with the white space in the connection summary emails.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v1000.5.0#72002)
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1506) Bro fails to build on OS X 10.11 (El Capitan) due to OpenSSL header removal

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25803#comment-25803
 ] 

Vlad Grigorescu commented on BIT-1506:
--

[~johanna] - Sure, that's a good idea. Is it reasonable to add those to the end 
of the search paths, in that case, though? I'm worried about the case where, 
for example, I have an old OpenSSL floating around and that will get picked up 
first. (I haven't checked to see exactly in what order it would get added).

> Bro fails to build on OS X 10.11 (El Capitan) due to OpenSSL header removal
> ---
>
> Key: BIT-1506
> URL: https://bro-tracker.atlassian.net/browse/BIT-1506
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: Bro
>Affects Versions: 2.4
>    Reporter: Vlad Grigorescu
>Assignee: Johanna Amann
> Fix For: 2.5
>
>
> It looks like Apple removed the OpenSSL headers with El Capitan[1] (OS X
> 10.11), and now Bro fails to build on OS X. Apple's recommendation is
> that we either include a copy of OpenSSL ourselves or we use their
> Secure Transport API.
> [1] - <https://lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html>



--
This message was sent by Atlassian JIRA
(v7.2.0-OD-05-030#72002)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] [JIRA] (BIT-1506) Bro fails to build on OS X 10.11 (El Capitan) due to OpenSSL header removal

[Vlad Grigorescu]

I extended Jon's fix a bit in topic/vladg/homebrew-openssl. It uses brew
--prefix to get Homebrew's installation prefix, which seems to be the
recommended approach.

I also confirmed that Jon's fix works for me on El Capitan, with Homebrew
(works in the sense that I don't need to pass any command-line arguments to
configure).

  --Vlad

On Sun, Apr 10, 2016 at 4:36 PM, Adam Slagell (JIRA) <
j...@bro-tracker.atlassian.net> wrote:

>
> [
> https://bro-tracker.atlassian.net/browse/BIT-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25605#comment-25605
> ]
>
> Adam Slagell commented on BIT-1506:
> ---
>
> Hah. I tried a few.
>
>   417  ./configure --with-openssl=/usr/local
>   474  ./configure --with-openssl=/usr/local/include/
>   479  ./configure --with-openssl=/usr/local/etc
>   480  ./configure --with-openssl=/usr/local/
>   484  ./configure --with-openssl=/usr/local/lib/
>   488  ./configure --with-openssl=/usr/local/Cellar/
>   492  ./configure --with-openssl=/usr/local/Cellar/openssl/
>
> Of course the path you specified worked.
>
> Can someone put a note on the webpage with the fix for Homebrew users.
> Probably here.
>
> https://www.bro.org/sphinx/install/install.html
>
>
> > Bro fails to build on OS X 10.11 (El Capitan) due to OpenSSL header
> removal
> >
> ---
> >
> > Key: BIT-1506
> > URL: https://bro-tracker.atlassian.net/browse/BIT-1506
> > Project: Bro Issue Tracker
> >  Issue Type: Problem
> >  Components: Bro
> >Affects Versions: 2.4
> >Reporter: Vlad Grigorescu
> > Fix For: 2.5
> >
> >
> > It looks like Apple removed the OpenSSL headers with El Capitan[1] (OS X
> > 10.11), and now Bro fails to build on OS X. Apple's recommendation is
> > that we either include a copy of OpenSSL ourselves or we use their
> > Secure Transport API.
> > [1] - <
> https://lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html>
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.2.0-OD-05-030#72002)
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1506) Bro fails to build on OS X 10.11 (El Capitan) due to OpenSSL header removal

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25601#comment-25601
 ] 

Vlad Grigorescu commented on BIT-1506:
--

Seth said that he uses MacPorts, so it's possible that we optimized for that 
and not HomeBrew.

> Bro fails to build on OS X 10.11 (El Capitan) due to OpenSSL header removal
> ---
>
> Key: BIT-1506
> URL: https://bro-tracker.atlassian.net/browse/BIT-1506
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: Bro
>Affects Versions: 2.4
>    Reporter: Vlad Grigorescu
>Assignee: Robin Sommer
> Fix For: 2.5
>
>
> It looks like Apple removed the OpenSSL headers with El Capitan[1] (OS X
> 10.11), and now Bro fails to build on OS X. Apple's recommendation is
> that we either include a copy of OpenSSL ourselves or we use their
> Secure Transport API.
> [1] - <https://lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html>



--
This message was sent by Atlassian JIRA
(v7.2.0-OD-05-030#72002)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1528) SNMP and SIP scans show up in known services.

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-1528:
-
  Status: Merge Request  (was: Open)
Assignee: (was: Vlad Grigorescu)

> SNMP and SIP scans show up in known services.
> -
>
> Key: BIT-1528
> URL: https://bro-tracker.atlassian.net/browse/BIT-1528
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: Bro
>Affects Versions: 2.4
>Reporter: Justin Azoff
> Fix For: 2.5
>
>
> It appears that single packet SIP and SNMP scans cause the destination host 
> to end up in known_services as running a SIP or SNMP service, even though 
> they are not running that service and did not respond to the packet.



--
This message was sent by Atlassian JIRA
(v7.2.0-OD-04-029#72002)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1528) SNMP and SIP scans show up in known services.

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25201#comment-25201
 ] 

Vlad Grigorescu commented on BIT-1528:
--

Completed in topic/vladg/bit-1528.

> SNMP and SIP scans show up in known services.
> -
>
> Key: BIT-1528
> URL: https://bro-tracker.atlassian.net/browse/BIT-1528
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: Bro
>Affects Versions: 2.4
>Reporter: Justin Azoff
>Assignee: Vlad Grigorescu
> Fix For: 2.5
>
>
> It appears that single packet SIP and SNMP scans cause the destination host 
> to end up in known_services as running a SIP or SNMP service, even though 
> they are not running that service and did not respond to the packet.



--
This message was sent by Atlassian JIRA
(v7.2.0-OD-04-029#72002)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1533) mysql analyzer does not set service to mysql

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=25005#comment-25005
 ] 

Vlad Grigorescu commented on BIT-1533:
--

Fixed in topic/vladg/bit-1533

> mysql analyzer does not set service to mysql
> 
>
> Key: BIT-1533
> URL: https://bro-tracker.atlassian.net/browse/BIT-1533
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: Bro
>Affects Versions: 2.4
>Reporter: Justin Azoff
>Assignee: Vlad Grigorescu
>Priority: Low
>
> The mysql analyzer does not set the service to mysql.  The result of this is 
> that conn.log and known_services do not show 'mysql' anywhere.



--
This message was sent by Atlassian JIRA
(v7.2.0-OD-03-014#72000)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1551) Broctl plugins in Bro plugins

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=24807#comment-24807
 ] 

Vlad Grigorescu commented on BIT-1551:
--

Assigning to Daniel for the broctl piece.

> Broctl plugins in Bro plugins
> -
>
> Key: BIT-1551
> URL: https://bro-tracker.atlassian.net/browse/BIT-1551
> Project: Bro Issue Tracker
>  Issue Type: New Feature
>  Components: bro-aux, BroControl, Documentation
>    Reporter: Vlad Grigorescu
>
> Right now, the Bro plugin skeleton creates:
> /scripts
> /src
> /tests
> I propose that a new directory, /broctl-plugins be created and that broctl 
> adds the following directories to the search path:
> /lib/bro/plugins/*/broctl-plugins
> $BRO_PLUGIN_PATH/*/broctl-plugins
> The documentation here should also be updated: 
> https://www.bro.org/sphinx-git/devel/plugins.html



--
This message was sent by Atlassian JIRA
(v7.2.0-OD-03-014#72000)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1551) Broctl plugins in Bro plugins

[Vlad Grigorescu (JIRA)]

Vlad Grigorescu created BIT-1551:


 Summary: Broctl plugins in Bro plugins
 Key: BIT-1551
 URL: https://bro-tracker.atlassian.net/browse/BIT-1551
 Project: Bro Issue Tracker
  Issue Type: New Feature
  Components: bro-aux, BroControl, Documentation
Reporter: Vlad Grigorescu


Right now, the Bro plugin skeleton creates:

/scripts
/src
/tests

I propose that a new directory, /broctl-plugins be created and that broctl adds 
the following directories to the search path:

/lib/bro/plugins/*/broctl-plugins
$BRO_PLUGIN_PATH/*/broctl-plugins

The documentation here should also be updated: 
https://www.bro.org/sphinx-git/devel/plugins.html



--
This message was sent by Atlassian JIRA
(v7.2.0-OD-03-014#72000)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1551) Broctl plugins in Bro plugins

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu reassigned BIT-1551:


Assignee: Daniel Thayer

> Broctl plugins in Bro plugins
> -
>
> Key: BIT-1551
> URL: https://bro-tracker.atlassian.net/browse/BIT-1551
> Project: Bro Issue Tracker
>  Issue Type: New Feature
>  Components: bro-aux, BroControl, Documentation
>    Reporter: Vlad Grigorescu
>Assignee: Daniel Thayer
>
> Right now, the Bro plugin skeleton creates:
> /scripts
> /src
> /tests
> I propose that a new directory, /broctl-plugins be created and that broctl 
> adds the following directories to the search path:
> /lib/bro/plugins/*/broctl-plugins
> $BRO_PLUGIN_PATH/*/broctl-plugins
> The documentation here should also be updated: 
> https://www.bro.org/sphinx-git/devel/plugins.html



--
This message was sent by Atlassian JIRA
(v7.2.0-OD-03-014#72000)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] SMB2 - NTLM GSSAPI messages

[Vlad Grigorescu]

My intention for this was to do the parsing at the PAC level, but it wasn't
possible at the time. In the meantime, BinPAC now supports including files
from other directories, so just how ASN1 is now a BinPAC library shared by
SNMP and Kerberos, I would envision GSSAPI to become a library. This would
also allow parsing of NTLM auth over HTTP.

  --Vlad

On Mon, Jan 25, 2016 at 10:33 AM, Seth Hall  wrote:

>
> > On Jan 25, 2016, at 11:17 AM, Martin van Hensbergen <
> martin.vanhensber...@fox-it.com> wrote:
> >
> > 1) (pac level) Make a separate library of the parsing of the GSSAPI blob
> ( as I think this is independent of whether SMB1 or SMB2 is used ), which
> returns the parsed ASN1 structure when called. Then both the SMB1 and SMB2
> parser can use these functions.
>
> Yep, that's probably the right way.  We never had enough time to get that
> integrated more cleanly.
>
> > 2) (bro script level) Make an ASN1 parser at the bro script level that
> does the parsing there. I would not opt for this route as it probably would
> be to slow and then we would have two places where this parsing is done.
>
> This is almost certainly not a great idea as you learned. :)
>
>   .Seth
>
> --
> Seth Hall
> International Computer Science Institute
> (Bro) because everyone has a network
> http://www.bro.org/
>
>
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] Bro failing to build on OS X with XCode 7

[Vlad Grigorescu]

I can't get Bro master to build with XCode 7 on OS X. For anyone trying to
build Bro on a new OS X system, this is a problem, since I don't think old
versions of XCode are still available.

> $ cc -v
> Apple LLVM version 7.0.2 (clang-700.1.81)
> Target: x86_64-apple-darwin15.2.0
> Thread model: posix
> $ ./configure
> ...
> |  Bro Build Summary  |=
>
> Install prefix:/usr/local/bro
> Bro Script Path:   /usr/local/bro/share/bro
> Debug mode:false
>
> CC:/usr/bin/cc
> CFLAGS: -Wall -Wno-unused -O2 -g -DNDEBUG
> CXX:   /usr/bin/c++
> CXXFLAGS:   -Wall -Wno-unused -std=c++11 -O2 -g -DNDEBUG
> CPP:   /usr/bin/c++
>
> Broker:true
> Broker Python: false
> Broccoli:  true
> Broctl:true
> Aux. Tools:true
>
> GeoIP: true
> gperftools found:  true
> tcmalloc:  false
>debugging:  false
> jemalloc:  false
>
> 
> ...
> $ make
> ...
> /Users/vladg/src/bro/src/main.cc:865:10: error: no member named 'init' in
namespace 'binpac'
> binpac::init();
> ^
> 4 warnings and 1 error generated.
> make[3]: *** [src/CMakeFiles/bro.dir/main.cc.o] Error 1
> $ make clean; ./configure --disable-broker
> ...
> /Users/vladg/src/bro/src/main.cc:865:10: error: no member named 'init' in
namespace 'binpac'
> binpac::init();
> ^
> 1 error generated.
> make[3]: *** [src/CMakeFiles/bro.dir/main.cc.o] Error 1

Any ideas on how to fix this? This seems related:
https://github.com/bro/binpac/commit/e42a18d8cbb1fffa9cec54b7893e72f113fdba8f

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1413) README files misidentified by GitHub

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23807#comment-23807
 ] 

Vlad Grigorescu commented on BIT-1413:
--

Here's what I was doing:


{code}
git clone ssh://git.bro.org/capstats.git
cd capstats
git checkout -b topic/bit-1413
ln -s README README.rst
git add README.rst
git commit -m "Add README.rst -> README symlink. Addresses BIT-1413"
git push origin topic/bit-1413
cd ..
{code}

> README files misidentified by GitHub
> 
>
> Key: BIT-1413
> URL: https://bro-tracker.atlassian.net/browse/BIT-1413
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: Documentation
>Reporter: Vlad Grigorescu
>Assignee: Jeannette Dopheide
>Priority: Low
> Fix For: 2.5
>
>
> If a README file doesn't have an extension, GitHub will parse it as Markdown. 
> Because our README files are ReST, this results in some ugly (and not very 
> useful) READMEs when visiting the repository on GitHub.
> For example, see: https://github.com/bro/btest#readme
> There are two options we could take to fix this: rename README to README.rst, 
> or create a symlink. I tried out the symlink option here, and I think the 
> result is much more useful: https://github.com/grigorescu/btest#readme
> The affected repos are:
> binpac
> bro
> bro-aux
> bro-plugins
> bro-scripts
> broccoli
> broccoli-perl
> broccoli-python
> broccoli-ruby
> broctl (broctl's README just instructs users to see doc/broctl.rst. This 
> could just be a symlink)
> broker
> bromagic (this can probably be deleted?)
> btest
> capstats
> time-machine
> trace-summary



--
This message was sent by Atlassian JIRA
(v7.1.0-OD-04-012#71001)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1518) SSH analyzer doesn't handle non-conformant client version strings

[Vlad Grigorescu (JIRA)]

Vlad Grigorescu created BIT-1518:


 Summary: SSH analyzer doesn't handle non-conformant client version 
strings
 Key: BIT-1518
 URL: https://bro-tracker.atlassian.net/browse/BIT-1518
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: Bro
Affects Versions: 2.4
Reporter: Vlad Grigorescu
Assignee: Vlad Grigorescu


Received a report that some SSH clients send a version identification string 
similar to 'SSH-2.0-FooBar_Client\n' which causes a protocol violation in the 
SSH analyzer. RFC 4253 states that this must be terminated by '\r\n', but 
that's not what's being observed.



--
This message was sent by Atlassian JIRA
(v7.1.0-OD-04-012#71001)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Better Handling of User Agents in Software Framework

[Vlad Grigorescu]

The other question I was wondering about is: should this be a BIF?
Software::parse is a rather lengthy function, with a lot of string
manipulation, which gets called rather frequently. I suspect there'd be
some performance improvements for implementing this directly as a BIF.

On Mon, Dec 14, 2015 at 3:24 PM, Seth Hall <s...@icir.org> wrote:

>
> > On Dec 14, 2015, at 10:51 AM, Vlad Grigorescu <v...@grigorescu.org>
> wrote:
> >
> > I'm not thrilled with those user agents are being handled right now, and
> I'm curious to get some thoughts. Take, for example the Safari user-agent
> string of:
>
> I think your proposal sounds reasonable.  I’d go ahead and implement it
> and see what you think about overload situations since I can easily see the
> amount of software being tracked quickly get out of hand with that.  After
> it’s implemented, get it running on several networks that are willing to
> run it and see if it causes problems for them. :)
>
> This could be a good time to also implement some better handling around
> software tracking to avoid obvious DoS issues by doing traffic that causes
> lots of state being tracked.
>
>   .Seth
>
> --
> Seth Hall
> International Computer Science Institute
> (Bro) because everyone has a network
> http://www.bro.org/
>
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] Better Handling of User Agents in Software Framework

[Vlad Grigorescu]

I'm not thrilled with those user agents are being handled right now, and
I'm curious to get some thoughts. Take, for example the Safari user-agent
string of:

> Safari/11601.3.9 CFNetwork/760.2.6 Darwin/15.2.0 (x86_64)

Right now, this gets parsed as:

> name=Safari,
> version=[
>   major=11601,
>   minor=3,
>   minor2=9,
>   minor3=,
>   addl=CFNetwork/760
> ],
> unparsed_version=Safari/11601.3.9 CFNetwork/760.2.6 Darwin/15.2.0 (x86_64)

RFC 7231 says:

> "The User-Agent field-value consists of one or more product identifiers,
each followed by zero or more comments (Section 3.2 of [RFC7230]), which
together identify the user agent software and its significant subproducts."

What I would like to see is this user-agent generate three separate entries
in software.log:

> Safari 11601.3.9
> CFNetwork 760.2.6
> Darwin 15.2.0 (x86_64)

I think this is a better representation of the software that's actually
running on the machine (they're running this version of Safari, this
version of the CFNetwork library, and this version of the Darwin kernel).

Taking this to the server-side, given:

> Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8j-fips mod_auth_kerb/5.4
PHP/5.4.13

I'd like to see:

> Apache/2.2.25 (Unix)
> mod_ssl/2.2.25
> OpenSSL/0.9.8j-fips
> mod_auth_kerb/5.4
> PHP/5.4.13

All of those are pieces of software running on that system, and maintaining
it as a user-agent is a construct from HTTP, which I don't feel belongs in
the software.log. Another warning sign that this is an area that could use
some work is the comment above Software::parse:

> # Don't even try to understand this now, just make sure the tests are
working.

Curious to hear thoughts on this.

--Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Parse LDAP messages from a pcap

[Vlad Grigorescu]

Zakaria,

There's no LDAP analyzer in Bro. LDAP is not a simple protocol, but if
you'd like to try writing an analyzer, you might want to check out the
following resources:

https://www.bro.org/development/howtos/binpac-sample-analyzer.html
https://www.youtube.com/watch?v=1eDIl9y6ZnM

Best,

  --Vlad

On Wed, Nov 25, 2015 at 12:44 PM, Zakaria Hili  wrote:

> Hello,
>
>   I need to parse LDAP messages from a pcap. So what I did is I tried to
> search for some Bro's events of LDAP but I failed. So I was wondering if
> there's some and that I missed them. If no, how can I then code a dissector
> of ldap easily so I could use it in events that I have to implement?
>
> Thank you for your help and keep up the good work!
> ᐧ
>
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1500) BinPAC Call to FlowBuffer::NewFrame with frame_length -1

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23002#comment-23002
 ] 

Vlad Grigorescu commented on BIT-1500:
--

I'd like to revisit this and see if we can get the issue fixed, so you don't 
have to do the workaround.

> BinPAC Call to FlowBuffer::NewFrame with frame_length -1
> 
>
> Key: BIT-1500
> URL: https://bro-tracker.atlassian.net/browse/BIT-1500
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
>Reporter: Mark Fernandez
>  Labels: analyzer
> Attachments: test.pac
>
>
> I am creating a protocol analyzer using BinPAC. I created a type record for 
> chunked data, very similar to HTTP chunked data.  The auto-generated C++ code 
> does not parse the chunked data correctly.  I tracked it down to the 
> ParseBuffer code where there is a combination of calls to 
> FlowBuffer::NewFrame and soon thereafter a condition check against 
> FlowBuffer::ready().  The call to NewFrame passes '-1' as the frame_length 
> value. NewFrame calls FlowBuffer::MarkOrCopyFrame, and because the 
> frame_length is set to -1, MarkOrCopyFrame sets message_complete_ to false.  
> Therefore, when FlowBuffer::ready() is called, it returns message_complete_, 
> which is false, and then ParseBuffer exits via 'goto need_more_data' without 
> ever parsing the chunked data.  This is very frustrating.  Please review and 
> let me know what you think.



--
This message was sent by Atlassian JIRA
(v7.1.0-OD-01-053#71000)

___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1500) BinPAC Call to FlowBuffer::NewFrame with frame_length -1

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=23004#comment-23004
 ] 

Vlad Grigorescu commented on BIT-1500:
--

We can leave it closed. I'll keep it on my backburner.

> BinPAC Call to FlowBuffer::NewFrame with frame_length -1
> 
>
> Key: BIT-1500
> URL: https://bro-tracker.atlassian.net/browse/BIT-1500
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
>Reporter: Mark Fernandez
>  Labels: analyzer
> Attachments: test.pac
>
>
> I am creating a protocol analyzer using BinPAC. I created a type record for 
> chunked data, very similar to HTTP chunked data.  The auto-generated C++ code 
> does not parse the chunked data correctly.  I tracked it down to the 
> ParseBuffer code where there is a combination of calls to 
> FlowBuffer::NewFrame and soon thereafter a condition check against 
> FlowBuffer::ready().  The call to NewFrame passes '-1' as the frame_length 
> value. NewFrame calls FlowBuffer::MarkOrCopyFrame, and because the 
> frame_length is set to -1, MarkOrCopyFrame sets message_complete_ to false.  
> Therefore, when FlowBuffer::ready() is called, it returns message_complete_, 
> which is false, and then ParseBuffer exits via 'goto need_more_data' without 
> ever parsing the chunked data.  This is very frustrating.  Please review and 
> let me know what you think.



--
This message was sent by Atlassian JIRA
(v7.1.0-OD-01-053#71000)

___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1506) Bro fails to build on OS X 10.11 (El Capitan) due to OpenSSL header removal

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=22817#comment-22817
 ] 

Vlad Grigorescu commented on BIT-1506:
--

Realistically, no one really runs Bro on OS X. But it is prominently labelled 
as a supported OS. From the downloads page: "Bro requires a Unix platform. We 
support Linux, FreeBSD, and Mac OS X, both 32-bit and 64-bit."

Really, I think this just requires an update to our requirements: 
https://www.bro.org/sphinx/install/install.html#required-dependencies

At the same time, it might be worth expanding on what exactly we support (e.g. 
Linux kernel versions > X, do we still need 32-bit support, etc?)


> Bro fails to build on OS X 10.11 (El Capitan) due to OpenSSL header removal
> ---
>
> Key: BIT-1506
> URL: https://bro-tracker.atlassian.net/browse/BIT-1506
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: Bro
>Affects Versions: 2.4
>Reporter: Vlad Grigorescu
> Fix For: 2.5
>
>
> It looks like Apple removed the OpenSSL headers with El Capitan[1] (OS X
> 10.11), and now Bro fails to build on OS X. Apple's recommendation is
> that we either include a copy of OpenSSL ourselves or we use their
> Secure Transport API.
> [1] - <https://lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html>



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-08-005#70107)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1506) Bro fails to build on OS X 10.11 (El Capitan) due to OpenSSL header removal

[Vlad Grigorescu (JIRA)]

Vlad Grigorescu created BIT-1506:


 Summary: Bro fails to build on OS X 10.11 (El Capitan) due to 
OpenSSL header removal
 Key: BIT-1506
 URL: https://bro-tracker.atlassian.net/browse/BIT-1506
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: Bro
Affects Versions: 2.4
Reporter: Vlad Grigorescu


It looks like Apple removed the OpenSSL headers with El Capitan[1] (OS X
10.11), and now Bro fails to build on OS X. Apple's recommendation is
that we either include a copy of OpenSSL ourselves or we use their
Secure Transport API.

[1] - <https://lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html>



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-08-005#70107)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1500) BinPAC Call to FlowBuffer::NewFrame with frame_length -1

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=22800#comment-22800
 ] 

Vlad Grigorescu commented on BIT-1500:
--

I've run into some similar weirdness, which is usually solved by creating a new 
record type for the element in question. Try:

type my_chunk = record {
  data = bytestring 
};

type TEST_chunk = record {
...
chunk_data  : my_chunk =chunk_length;
...
};

> BinPAC Call to FlowBuffer::NewFrame with frame_length -1
> 
>
> Key: BIT-1500
> URL: https://bro-tracker.atlassian.net/browse/BIT-1500
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
>Reporter: Mark Fernandez
>  Labels: analyzer
> Attachments: test.pac
>
>
> I am creating a protocol analyzer using BinPAC. I created a type record for 
> chunked data, very similar to HTTP chunked data.  The auto-generated C++ code 
> does not parse the chunked data correctly.  I tracked it down to the 
> ParseBuffer code where there is a combination of calls to 
> FlowBuffer::NewFrame and soon thereafter a condition check against 
> FlowBuffer::ready().  The call to NewFrame passes '-1' as the frame_length 
> value. NewFrame calls FlowBuffer::MarkOrCopyFrame, and because the 
> frame_length is set to -1, MarkOrCopyFrame sets message_complete_ to false.  
> Therefore, when FlowBuffer::ready() is called, it returns message_complete_, 
> which is false, and then ParseBuffer exits via 'goto need_more_data' without 
> ever parsing the chunked data.  This is very frustrating.  Please review and 
> let me know what you think.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-08-005#70107)

___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] [EXTERNAL] Re: [Bro] Logging VLAN IDs

[Vlad Grigorescu]

Oooh, yes, thank you. I'm not sure how I missed that, but that looks nice.

On Mon, Sep 21, 2015 at 5:50 PM, Robin Sommer  wrote:

> On Mon, Sep 21, 2015 at 11:20 -0500, you wrote:
>
> > I'm wondering if anyone has given any further thought to or done any work
> > on this.
>
> Yep, it's in place. :) See fb848f795de8ef22987ba01980ff65be1231b312.
>
> >  was reminded of what a mess Sessions.cc currently is. I think moving
> >  towards passing a Packet structure around would help to simplify
> >  things a lot
>
> And that too: fe3579f1b4c82db3cd9cd6f372c1a5387bac24ac and
> c72d191ab5c960be94c9f516aa94ec214f54b0c7
>
> Does that do what you're looking for?
>
> Robin
>
> --
> Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] Advice on the PE Analyzer

[Vlad Grigorescu]

For Bro 2.5, I'd like to add some more functionality to the Windows
Portable Executable analyzer. I think there's a lot of valuable data that
could be extracted, but the format is rather challenging to work with. Some
protocol pseudocode would be:

> : import_address_table is at 0010
> 0010: entry #1 is at 0030
> 0020: entry #2 is at 0050
> 0030: entry #1 address is at 0100
> 0040: entry #1 name is at 0110
> 0050: entry #2 address is at 0140
> 0060: entry #2 name is at 0120

Much of the data is simply pointers to offsets in the file where the actual
data resides. My thought for parsing this is to write two helper functions
in C++:

> jump_to_next_interesting_offset()
> // Skips to the offset of the next thing I would like to parse

> get_data_context_at_current_offset()
> // Get contextual information for how to parse the current data
> // (e.g. this is the the address of entry #1 in the import address table).

Does anyone have suggestions for what data structures I should use to store
the necessary data? Storing the offsets shouldn't be very difficult, but
each offset will need context associated with it in order to know how to
parse it once the analyzer gets there, and how to associate the data
residing there with data that's already been parsed.

Thanks,

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] [EXTERNAL] Re: [Bro] Logging VLAN IDs

[Vlad Grigorescu]

Apologies for resurrecting an old thread.

I'm wondering if anyone has given any further thought to or done any work
on this. While looking at BIT-1480 (adding ERSPAN decapsulation support), I
was reminded of what a mess Sessions.cc currently is. I think moving
towards passing a Packet structure around would help to simplify things a
lot - possibly by breaking up the code into per-protocol classes.

Curious to hear any thoughts. Thanks,

  --Vlad

On Thu, May 7, 2015 at 4:17 PM, Thomas, Eric D  wrote:

> That sounds good! Both ideas seem to add an interesting level of
> additional flexibility and analytic potential.
> --
> Eric Thomas
> edth...@sandia.gov
>
>
>
>
> On 4/29/15, 4:59 PM, "Robin Sommer"  wrote:
>
> >What if we did a combination of what I suggested and your thoughts
> >here? We carry link-level features through to script-land inside the
> >connection record, and in addition allowed to transfer a custom subset
> >over to the connection ID for hashing? The latter could be done later
> >as a second step.
> >
> >Robin
> >
> >On Tue, Apr 28, 2015 at 18:32 +, you wrote:
> >
> >> Hi Robin,
> >>
> >> I thought more about your generalized idea and would like to follow up.
> >>To
> >> start, adding link-level features to the connection ID hash, while
> >>perhaps
> >> useful in some contexts, does not provide us the functionality we
> >>desire.
> >> I have an incoming feed of VLAN-tagged traffic (both VLAN and 802.1ah)
> >> with perhaps dozens of different VLANs, and I would like to handle the
> >> connections differently in scripts but also mainly in offline log
> >>analysis
> >> depending upon which VLANs the traffic is associated with.
> >>
> >> Initially I had proposed simply adding the VLAN Ids to the conn.log
> >>file,
> >> but that is certainly too specific of a solution. What are your thoughts
> >> on exposing link-level features at the script layer for connections? For
> >> example, if all observed VLAN tags for a connection were in a set
> >>variable
> >> of the script-level Connection record, I could then label my data by
> >> matching VLAN Ids, then process them differently accordingly. Thoughts?
> >>
> >
> >
> >--
> >Robin Sommer * Broala, LLC * ro...@broala.com * www.broala.com
>
>
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1480) ERSPAN Supprt

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu reassigned BIT-1480:


Assignee: Vlad Grigorescu

> ERSPAN Supprt
> -
>
> Key: BIT-1480
> URL: https://bro-tracker.atlassian.net/browse/BIT-1480
> Project: Bro Issue Tracker
>  Issue Type: New Feature
>  Components: Bro
>Affects Versions: 2.3
> Environment: Using vCenter virtual switch, frames from monitored VMs 
> are encapsulated using GRE and forwarded to my sensor on a different 
> broadcast domain.
>Reporter: Matthew Domko
>Assignee: Vlad Grigorescu
>  Labels: ERSPAN
> Attachments: erspan
>
>
> PCAP attached... Basically, bro recieves the erspan packet and doesn't 
> recognize that it is just GRE with a slightly different format. All the 
> packets get logged in bro with the ERSPAN source/dest addresses instead of 
> the actual source/dest addresses. It seems like everything else is working. 
> There was a discussion about this on a mailing list in the past, but no one 
> provided PCAP.
> http://mailman.icsi.berkeley.edu/pipermail/bro/2015-April/008347.html
> And someone else released a tool to do the decapsulation on the side:
> http://staff.washington.edu/corey/gulp/



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-05-005#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu reassigned BIT-1460:


Assignee: Vlad Grigorescu  (was: Johanna Amann)

> DPD query too large on multicast DNS
> 
>
> Key: BIT-1460
> URL: https://bro-tracker.atlassian.net/browse/BIT-1460
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
>Reporter: Michal Purzynski
>Assignee: Vlad Grigorescu
>  Labels: analyzer
> Attachments: dnsm.pcap
>
>
> Lots of
> 1440024833.696698 CZdljELZjJSLLQpxj   10.251.27.165   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.76 CgVrZf4IQ0Tc04EfQe  10.251.29.250   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.764923 C4oQOB2GRRhDHW1i4g  fe80::6676:baff:feb5:772c   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.016577 CsCwiq3qk2Uxjhomjj  fe80::1c8a:768d:e113:e39f   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.015551 CA1nbO23vgbca2PBYi  10.251.28.176   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962007 C5kYaG3BckRrVOot89  10.251.26.995353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962049 CrkZft38lJ0YqGqxsl  fe80::2acf:e9ff:fe1a:9aed   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> for just UDP and port 5353 - multicast DNS
> Pcaps attached.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-04-018#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=22018#comment-22018
 ] 

Vlad Grigorescu commented on BIT-1460:
--

Will do. Sorry for not checking that earlier.

> DPD query too large on multicast DNS
> 
>
> Key: BIT-1460
> URL: https://bro-tracker.atlassian.net/browse/BIT-1460
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
>Reporter: Michal Purzynski
>Assignee: Vlad Grigorescu
>  Labels: analyzer
> Attachments: dnsm.pcap
>
>
> Lots of
> 1440024833.696698 CZdljELZjJSLLQpxj   10.251.27.165   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.76 CgVrZf4IQ0Tc04EfQe  10.251.29.250   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.764923 C4oQOB2GRRhDHW1i4g  fe80::6676:baff:feb5:772c   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.016577 CsCwiq3qk2Uxjhomjj  fe80::1c8a:768d:e113:e39f   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.015551 CA1nbO23vgbca2PBYi  10.251.28.176   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962007 C5kYaG3BckRrVOot89  10.251.26.995353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962049 CrkZft38lJ0YqGqxsl  fe80::2acf:e9ff:fe1a:9aed   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> for just UDP and port 5353 - multicast DNS
> Pcaps attached.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-04-018#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-1460:
-
Status: Open  (was: Merge Request)

> DPD query too large on multicast DNS
> 
>
> Key: BIT-1460
> URL: https://bro-tracker.atlassian.net/browse/BIT-1460
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
>Reporter: Michal Purzynski
>Assignee: Johanna Amann
>  Labels: analyzer
> Attachments: dnsm.pcap
>
>
> Lots of
> 1440024833.696698 CZdljELZjJSLLQpxj   10.251.27.165   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.76 CgVrZf4IQ0Tc04EfQe  10.251.29.250   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.764923 C4oQOB2GRRhDHW1i4g  fe80::6676:baff:feb5:772c   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.016577 CsCwiq3qk2Uxjhomjj  fe80::1c8a:768d:e113:e39f   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.015551 CA1nbO23vgbca2PBYi  10.251.28.176   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962007 C5kYaG3BckRrVOot89  10.251.26.995353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962049 CrkZft38lJ0YqGqxsl  fe80::2acf:e9ff:fe1a:9aed   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> for just UDP and port 5353 - multicast DNS
> Pcaps attached.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-04-018#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=22019#comment-22019
 ] 

Vlad Grigorescu commented on BIT-1460:
--

Yes, these all seem reasonable. Several symptoms of this particular bug were 
fixed.

> DPD query too large on multicast DNS
> 
>
> Key: BIT-1460
> URL: https://bro-tracker.atlassian.net/browse/BIT-1460
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
>Reporter: Michal Purzynski
>Assignee: Vlad Grigorescu
>  Labels: analyzer
> Attachments: dnsm.pcap
>
>
> Lots of
> 1440024833.696698 CZdljELZjJSLLQpxj   10.251.27.165   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.76 CgVrZf4IQ0Tc04EfQe  10.251.29.250   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.764923 C4oQOB2GRRhDHW1i4g  fe80::6676:baff:feb5:772c   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.016577 CsCwiq3qk2Uxjhomjj  fe80::1c8a:768d:e113:e39f   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.015551 CA1nbO23vgbca2PBYi  10.251.28.176   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962007 C5kYaG3BckRrVOot89  10.251.26.995353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962049 CrkZft38lJ0YqGqxsl  fe80::2acf:e9ff:fe1a:9aed   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> for just UDP and port 5353 - multicast DNS
> Pcaps attached.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-04-018#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=22019#comment-22019
 ] 

Vlad Grigorescu edited comment on BIT-1460 at 9/10/15 3:01 PM:
---

Yes, these all seem reasonable. Several symptoms of this particular bug were 
fixed.

I updated the appropriate baselines in topic/vladg/bit-1460 in the bro-testing 
repo.

Several tests unrelated to DNS seem to be broken, but I believe that's due to 
BIT-1467. Also, the private test suite seems to be out of date with master, but 
I didn't see any DNS-related changes.


was (Author: grigorescu):
Yes, these all seem reasonable. Several symptoms of this particular bug were 
fixed.

> DPD query too large on multicast DNS
> 
>
> Key: BIT-1460
> URL: https://bro-tracker.atlassian.net/browse/BIT-1460
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
>Reporter: Michal Purzynski
>Assignee: Vlad Grigorescu
>  Labels: analyzer
> Attachments: dnsm.pcap
>
>
> Lots of
> 1440024833.696698 CZdljELZjJSLLQpxj   10.251.27.165   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.76 CgVrZf4IQ0Tc04EfQe  10.251.29.250   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.764923 C4oQOB2GRRhDHW1i4g  fe80::6676:baff:feb5:772c   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.016577 CsCwiq3qk2Uxjhomjj  fe80::1c8a:768d:e113:e39f   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.015551 CA1nbO23vgbca2PBYi  10.251.28.176   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962007 C5kYaG3BckRrVOot89  10.251.26.995353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962049 CrkZft38lJ0YqGqxsl  fe80::2acf:e9ff:fe1a:9aed   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> for just UDP and port 5353 - multicast DNS
> Pcaps attached.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-04-018#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-1460:
-
  Status: Merge Request  (was: Open)
Assignee: (was: Vlad Grigorescu)

> DPD query too large on multicast DNS
> 
>
> Key: BIT-1460
> URL: https://bro-tracker.atlassian.net/browse/BIT-1460
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
>Reporter: Michal Purzynski
>  Labels: analyzer
> Attachments: dnsm.pcap
>
>
> Lots of
> 1440024833.696698 CZdljELZjJSLLQpxj   10.251.27.165   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.76 CgVrZf4IQ0Tc04EfQe  10.251.29.250   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.764923 C4oQOB2GRRhDHW1i4g  fe80::6676:baff:feb5:772c   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.016577 CsCwiq3qk2Uxjhomjj  fe80::1c8a:768d:e113:e39f   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.015551 CA1nbO23vgbca2PBYi  10.251.28.176   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962007 C5kYaG3BckRrVOot89  10.251.26.995353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962049 CrkZft38lJ0YqGqxsl  fe80::2acf:e9ff:fe1a:9aed   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> for just UDP and port 5353 - multicast DNS
> Pcaps attached.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-04-018#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1413) README files misidentified by GitHub

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=21944#comment-21944
 ] 

Vlad Grigorescu commented on BIT-1413:
--

Sure. I'll go with the symlink idea.

> README files misidentified by GitHub
> 
>
> Key: BIT-1413
> URL: https://bro-tracker.atlassian.net/browse/BIT-1413
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: Documentation
>    Reporter: Vlad Grigorescu
>    Assignee: Vlad Grigorescu
> Fix For: 2.5
>
>
> If a README file doesn't have an extension, GitHub will parse it as Markdown. 
> Because our README files are ReST, this results in some ugly (and not very 
> useful) READMEs when visiting the repository on GitHub.
> For example, see: https://github.com/bro/btest#readme
> There are two options we could take to fix this: rename README to README.rst, 
> or create a symlink. I tried out the symlink option here, and I think the 
> result is much more useful: https://github.com/grigorescu/btest#readme
> The affected repos are:
> binpac
> bro
> bro-aux
> bro-plugins
> bro-scripts
> broccoli
> broccoli-perl
> broccoli-python
> broccoli-ruby
> broctl (broctl's README just instructs users to see doc/broctl.rst. This 
> could just be a symlink)
> broker
> bromagic (this can probably be deleted?)
> btest
> capstats
> time-machine
> trace-summary



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-259#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1414) Make PIE option availalbe during compiling

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-1414:
-
Resolution: Cannot Reproduce
Status: Closed  (was: Open)

> Make PIE option availalbe during compiling
> --
>
> Key: BIT-1414
> URL: https://bro-tracker.atlassian.net/browse/BIT-1414
> Project: Bro Issue Tracker
>  Issue Type: New Feature
>  Components: Bro
>Affects Versions: 2.3
> Environment: We would like to request PIE support be built in and 
> available in the Bro binary.  
>Reporter: Jeff
>




--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-259#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=21941#comment-21941
 ] 

Vlad Grigorescu commented on BIT-1460:
--

The issue here is src/analyzer/protocol/dns/DNS.cc lines 58-68:

{quote}
// There is a great deal of non-DNS traffic that runs on port 53.
// This should weed out most of it.
if ( dns_max_queries > 0 && msg.qdcount > dns_max_queries )
{
analyzer->ProtocolViolation("DNS_Conn_count_too_large");
analyzer->Weird("DNS_Conn_count_too_large");
EndMessage();
return 0;
}
{quote}

topic/vladg/bit-1460 makes dns_max_queries redef-able, and bumps up the limit 
from 5 to 25.

Since multicast is so chatty, it might make sense to special case it and allow 
for a higher limit. That being said, I'm not sure there's much of a downside to 
setting the max a bit higher.

> DPD query too large on multicast DNS
> 
>
> Key: BIT-1460
> URL: https://bro-tracker.atlassian.net/browse/BIT-1460
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
>Reporter: Michal Purzynski
>  Labels: analyzer
> Attachments: dnsm.pcap
>
>
> Lots of
> 1440024833.696698 CZdljELZjJSLLQpxj   10.251.27.165   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.76 CgVrZf4IQ0Tc04EfQe  10.251.29.250   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.764923 C4oQOB2GRRhDHW1i4g  fe80::6676:baff:feb5:772c   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.016577 CsCwiq3qk2Uxjhomjj  fe80::1c8a:768d:e113:e39f   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.015551 CA1nbO23vgbca2PBYi  10.251.28.176   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962007 C5kYaG3BckRrVOot89  10.251.26.995353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962049 CrkZft38lJ0YqGqxsl  fe80::2acf:e9ff:fe1a:9aed   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> for just UDP and port 5353 - multicast DNS
> Pcaps attached.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-259#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1460) DPD query too large on multicast DNS

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-1460:
-
Status: Merge Request  (was: Open)

> DPD query too large on multicast DNS
> 
>
> Key: BIT-1460
> URL: https://bro-tracker.atlassian.net/browse/BIT-1460
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
>Reporter: Michal Purzynski
>  Labels: analyzer
> Attachments: dnsm.pcap
>
>
> Lots of
> 1440024833.696698 CZdljELZjJSLLQpxj   10.251.27.165   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.76 CgVrZf4IQ0Tc04EfQe  10.251.29.250   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440024920.764923 C4oQOB2GRRhDHW1i4g  fe80::6676:baff:feb5:772c   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.016577 CsCwiq3qk2Uxjhomjj  fe80::1c8a:768d:e113:e39f   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> 1440024981.015551 CA1nbO23vgbca2PBYi  10.251.28.176   5353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962007 C5kYaG3BckRrVOot89  10.251.26.995353
> 224.0.0.251 5353udp DNS DNS_Conn_count_too_large
> 1440025022.962049 CrkZft38lJ0YqGqxsl  fe80::2acf:e9ff:fe1a:9aed   
> 5353ff02::fb5353udp DNS DNS_Conn_count_too_large
> for just UDP and port 5353 - multicast DNS
> Pcaps attached.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-259#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-874) Handling Modbus exception FC

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-874:

Labels: Modbus analyzer exception fc  (was: , Modbus analyser, exception fc)

> Handling Modbus exception FC
> 
>
> Key: BIT-874
> URL: https://bro-tracker.atlassian.net/browse/BIT-874
> Project: Bro Issue Tracker
>  Issue Type: Task
>  Components: Bro
>Affects Versions: git/master
>Reporter: dina
>  Labels: Modbus, analyzer, exception, fc
> Fix For: 2.5
>
>
> event modbus_exception is a general exception and the 'fc' that is returned 
> here is 'original_request_fc'+128. This means if I send a request with Fc=3 
> and something goes bad,I will get this exception with fc=131. I thought it 
> would be useful to immediately subtract this value and show in the log exact 
> Fc where the exception was triggered.  A small function for this I put before 
> in modbus/utils.bro (on my branch), but its not in the 
> topic/robin/modbus-merge branch. 
> I suggest to implement this functionality.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-259#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1336) ElasticSearch indices in UTC

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=21956#comment-21956
 ] 

Vlad Grigorescu commented on BIT-1336:
--

The fix for this is in topic/vladg/es-fixes in the bro-plugins repo, although 
the defaults were kept the same.

> ElasticSearch indices in UTC
> 
>
> Key: BIT-1336
> URL: https://bro-tracker.atlassian.net/browse/BIT-1336
> Project: Bro Issue Tracker
>  Issue Type: Improvement
>  Components: Bro
>Affects Versions: 2.4
>    Reporter: Vlad Grigorescu
>Assignee: Seth Hall
>Priority: Trivial
> Fix For: 2.5
>
>
> For improved compatibility with Kibana and other ElasticSearch frontends, the 
> timestamps on the Bro indices should be changed to UTC.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-259#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1336) ElasticSearch indices in UTC

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-1336:
-
  Status: Merge Request  (was: Open)
Assignee: (was: Seth Hall)

> ElasticSearch indices in UTC
> 
>
> Key: BIT-1336
> URL: https://bro-tracker.atlassian.net/browse/BIT-1336
> Project: Bro Issue Tracker
>  Issue Type: Improvement
>  Components: Bro
>Affects Versions: 2.4
>    Reporter: Vlad Grigorescu
>Priority: Trivial
> Fix For: 2.5
>
>
> For improved compatibility with Kibana and other ElasticSearch frontends, the 
> timestamps on the Bro indices should be changed to UTC.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-259#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1458) Lots of binpac exceptions in SIP

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=21926#comment-21926
 ] 

Vlad Grigorescu commented on BIT-1458:
--

topic/vladg/bit-1458 reworks the analyzer a bit, and fixes any errors in the 
attached PCAPs.

> Lots of binpac exceptions in SIP
> 
>
> Key: BIT-1458
> URL: https://bro-tracker.atlassian.net/browse/BIT-1458
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
> Environment: Linux 3.19, Ubuntu 14.04 LTS, Asterisk for VOIP, plain 
> SIP plus RDP no encryption
>Reporter: Michal Purzynski
> Attachments: badsip-19AUG2015_anon.pcapng, sip2.pcap, sip3.pcap, 
> sip-scan-detailed.pcap
>
>
> There's quite a bit of binpac exception in dpd.log on office sensors, that 
> can see SIP traffic. The log message is always the same (I think).
> 1439957552.911869 ChGboH2ZriUae63ufg  23.92.80.45 5089
> 10.252.40.4 5060udp SIP Binpac exception: binpac exception: 
> string mismatch at 
> /home/mpurzynski/src/bro/bro-2.4-pfring/src/analyzer/protocol/sip/sip-protocol.pac:70:
>  \x0aexpected pattern: ":"\x0aactual data: " 496704993 2096249773 IN IP4 
> 23.92.80.45\x0d\x0as=sipcli\x0d\x0ac=IN IP4 23.92.80.45\x0d\x0at=0 
> 0\x0d\x0am=audio 5097 RTP/AVP 18 0 8 101\x0d\x0aa=fmtp:101 
> 0-15\x0d\x0aa=rtpmap:18 G729/8000\x0d\x0aa=rtpmap:0 
> PCMU/8000\x0d\x0aa=rtpmap:8 PCMA/8000\x0d\x0aa=rtpmap:101 
> telephone-event/8000\x0d\x0aa=ptime:20\x0d\x0aa=sendrecv\x0d\x0a"
> What kind of data do you want me to attach, to help debugging the issue?



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-259#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1458) Lots of binpac exceptions in SIP

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-1458:
-
  Status: Merge Request  (was: Open)
Assignee: (was: Vlad Grigorescu)

> Lots of binpac exceptions in SIP
> 
>
> Key: BIT-1458
> URL: https://bro-tracker.atlassian.net/browse/BIT-1458
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
> Environment: Linux 3.19, Ubuntu 14.04 LTS, Asterisk for VOIP, plain 
> SIP plus RDP no encryption
>Reporter: Michal Purzynski
> Attachments: badsip-19AUG2015_anon.pcapng, sip2.pcap, sip3.pcap, 
> sip-scan-detailed.pcap
>
>
> There's quite a bit of binpac exception in dpd.log on office sensors, that 
> can see SIP traffic. The log message is always the same (I think).
> 1439957552.911869 ChGboH2ZriUae63ufg  23.92.80.45 5089
> 10.252.40.4 5060udp SIP Binpac exception: binpac exception: 
> string mismatch at 
> /home/mpurzynski/src/bro/bro-2.4-pfring/src/analyzer/protocol/sip/sip-protocol.pac:70:
>  \x0aexpected pattern: ":"\x0aactual data: " 496704993 2096249773 IN IP4 
> 23.92.80.45\x0d\x0as=sipcli\x0d\x0ac=IN IP4 23.92.80.45\x0d\x0at=0 
> 0\x0d\x0am=audio 5097 RTP/AVP 18 0 8 101\x0d\x0aa=fmtp:101 
> 0-15\x0d\x0aa=rtpmap:18 G729/8000\x0d\x0aa=rtpmap:0 
> PCMU/8000\x0d\x0aa=rtpmap:8 PCMA/8000\x0d\x0aa=rtpmap:101 
> telephone-event/8000\x0d\x0aa=ptime:20\x0d\x0aa=sendrecv\x0d\x0a"
> What kind of data do you want me to attach, to help debugging the issue?



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-259#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1469) dpd.log contains lots of binpac exceptions for RDP

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=21927#comment-21927
 ] 

Vlad Grigorescu commented on BIT-1469:
--

I looked into this, and I don't think that it's trivial to solve correctly. We 
could easily ignore traffic that generates this warning, but we risk allowing 
some types of evasion.

The issue is exhibited in frame 38 of the attached PCAP, among others.

> TPKT, Version: 3, Length: 8
> ISO 8073/X.224 COTP Connection-Oriented Transport Protocol
> Length: 2
> PDU Type: DT Data (0x0f)
> Data (1 byte)
> 
>   28(
> Data: 28

DT_Data tries to parse the PDU Type, a uint8 (application_defined_type), and 
another uint8 (application_type). In this case, there are not 3 bytes available 
to process.

We could trust the lengths, but comments in the code indicate that they're 
often incorrect. I'm also unsure if these short packets are designed to be 
reassembled by the application.

Curious to hear other people's thoughts, but I think bumping this back to 2.5 
is a reasonable step for now.

> dpd.log contains lots of binpac exceptions for RDP
> --
>
> Key: BIT-1469
> URL: https://bro-tracker.atlassian.net/browse/BIT-1469
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC, Bro
>Affects Versions: git/master
> Environment: RHEL  6.6, 2.4-10 bro build from git
>Reporter: Gary Faulkner
>  Labels: analyzer
> Fix For: 2.5
>
> Attachments: rdp-31AUG15.pcap
>
>
> RDP scanners seem to generate a lot of binpac errors in dpd.log for RDP 
> connections.
> The following log line is an example of the error that repeats continuously 
> during the activity:
> 1441031469.413008 CPNcey4q2i8mGVUvEg  74.91.23.83 62082   
> 10.10.81.2073389tcp RDP Binpac exception: binpac exception: 
> out_of_bound: DT_Data:application_type: 3 > 2
> The 10.x.x.x IP is the redacted local IP. The other IP is the scanner.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-259#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1469) dpd.log contains lots of binpac exceptions for RDP

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-1469:
-
Fix Version/s: 2.5

> dpd.log contains lots of binpac exceptions for RDP
> --
>
> Key: BIT-1469
> URL: https://bro-tracker.atlassian.net/browse/BIT-1469
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC, Bro
>Affects Versions: git/master
> Environment: RHEL  6.6, 2.4-10 bro build from git
>Reporter: Gary Faulkner
>  Labels: analyzer
> Fix For: 2.5
>
> Attachments: rdp-31AUG15.pcap
>
>
> RDP scanners seem to generate a lot of binpac errors in dpd.log for RDP 
> connections.
> The following log line is an example of the error that repeats continuously 
> during the activity:
> 1441031469.413008 CPNcey4q2i8mGVUvEg  74.91.23.83 62082   
> 10.10.81.2073389tcp RDP Binpac exception: binpac exception: 
> out_of_bound: DT_Data:application_type: 3 > 2
> The 10.x.x.x IP is the redacted local IP. The other IP is the scanner.



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-259#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1458) Lots of binpac exceptions in SIP

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=21929#comment-21929
 ] 

Vlad Grigorescu commented on BIT-1458:
--

Yeah, I agree. The existing btest's Baseline did need to be updated with this 
fix (there was a SIP message that was previously missed), so we do have a test 
exhibiting this problem, but we should probably do more. We also have no tests 
for the SIP over TCP analyzer. I was going to make a ticket to add one for that 
(I had some issues finding a test trace).

> Lots of binpac exceptions in SIP
> 
>
> Key: BIT-1458
> URL: https://bro-tracker.atlassian.net/browse/BIT-1458
> Project: Bro Issue Tracker
>  Issue Type: Problem
>  Components: BinPAC
>Affects Versions: 2.4
> Environment: Linux 3.19, Ubuntu 14.04 LTS, Asterisk for VOIP, plain 
> SIP plus RDP no encryption
>Reporter: Michal Purzynski
>Assignee: Johanna Amann
> Attachments: badsip-19AUG2015_anon.pcapng, sip2.pcap, sip3.pcap, 
> sip-scan-detailed.pcap
>
>
> There's quite a bit of binpac exception in dpd.log on office sensors, that 
> can see SIP traffic. The log message is always the same (I think).
> 1439957552.911869 ChGboH2ZriUae63ufg  23.92.80.45 5089
> 10.252.40.4 5060udp SIP Binpac exception: binpac exception: 
> string mismatch at 
> /home/mpurzynski/src/bro/bro-2.4-pfring/src/analyzer/protocol/sip/sip-protocol.pac:70:
>  \x0aexpected pattern: ":"\x0aactual data: " 496704993 2096249773 IN IP4 
> 23.92.80.45\x0d\x0as=sipcli\x0d\x0ac=IN IP4 23.92.80.45\x0d\x0at=0 
> 0\x0d\x0am=audio 5097 RTP/AVP 18 0 8 101\x0d\x0aa=fmtp:101 
> 0-15\x0d\x0aa=rtpmap:18 G729/8000\x0d\x0aa=rtpmap:0 
> PCMU/8000\x0d\x0aa=rtpmap:8 PCMA/8000\x0d\x0aa=rtpmap:101 
> telephone-event/8000\x0d\x0aa=ptime:20\x0d\x0aa=sendrecv\x0d\x0a"
> What kind of data do you want me to attach, to help debugging the issue?



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-259#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1466) Need to document Q and I for conn.log

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu reassigned BIT-1466:


Assignee: Vlad Grigorescu

 Need to document Q and I for conn.log
 -

 Key: BIT-1466
 URL: https://bro-tracker.atlassian.net/browse/BIT-1466
 Project: Bro Issue Tracker
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 2.4
 Environment: Web site documentation
Reporter: james.lay
Assignee: Vlad Grigorescu
Priority: Trivial
  Labels: documentation

 Need to document Q and I in conn.log, per Seth's request



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-247#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1466) Need to document Q and I for conn.log

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=21801#comment-21801
 ] 

Vlad Grigorescu commented on BIT-1466:
--

Fixed in topic/vladg/bit-1466

 Need to document Q and I for conn.log
 -

 Key: BIT-1466
 URL: https://bro-tracker.atlassian.net/browse/BIT-1466
 Project: Bro Issue Tracker
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 2.4
 Environment: Web site documentation
Reporter: james.lay
Priority: Trivial
  Labels: documentation

 Need to document Q and I in conn.log, per Seth's request



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-02-247#70102)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1461) Bro Mgr Scripts Fail After Threat Intel Feed Add

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=21708#comment-21708
 ] 

Vlad Grigorescu commented on BIT-1461:
--

{quote}Value not found in enum mappimg{quote}

There's a typo in mapping. Could that be the issue? It's a bit hard to debug 
without seeing the script(s).

 Bro Mgr Scripts Fail After Threat Intel Feed Add
 

 Key: BIT-1461
 URL: https://bro-tracker.atlassian.net/browse/BIT-1461
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: Bro
Affects Versions: 2.5
Reporter: Tim Jackson

 Getting the following on check after inclusion of 3rd party threat intel 
 feeds. Unsure of how to continue
 manager scripts failed.
internal error: Value not found in enum mappimg. Module: Intel, var: 
 undefined, var size: 9
/opt/bro/share/broctl/scripts/check-config: line 28: 30661 Aborted 
 (core dumped) ${bro} $@
 proxy scripts are ok.
 calidcbrosrv001-eth1-1 scripts are ok.
 calidcbrosrv001-eth1-2 scripts are ok.
 Thanks
 Tim



--
This message was sent by Atlassian JIRA
(v7.0.0-OD-01-193#70101)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Trouble with getting Bro 2.2 private analyzer to write logs on current master

[Vlad Grigorescu]

On Wed, Jun 17, 2015 at 10:30 AM, James Swaro james.sw...@gmail.com wrote:

 If I understand the patch correctly, it would only cause problems for
 connections with over 2GB of data payload, but I think it should work fine
 for a small trace of say 200KB. I'm not seeing any events at all, nor am I
 seeing the log files that should be created when using the analyzer.


That was the point of that change, yes, but the breaking modification was
that the function signatures are now different. Specifically, those are
virtual functions that you're inheriting. If your parameters don't match
exactly, you're just defining a new virtual function as opposed to
redefining the existing function.


 I'll correct the functions and test it out though.


When you said that you're not seeing DeliverPacket be entered, was that
after making the uint64 change?

  --Vlad
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Trouble with getting Bro 2.2 private analyzer to write logs on current master

[Vlad Grigorescu]

Just a guess, but it could be related to this:
https://github.com/bro/bro/blob/master/CHANGES#L1578

ints changed to uint64s. As an example, you can see how the HTTP analyzer
was modified here:
https://github.com/bro/bro/commit/96bcc2d69d72c21f5f4eff0c88cd8d43613bee22#diff-978a30a2ac40a10fbf3c8b5500d3a9f3

The other big change was moving to plugins, but if you're seeing it added
as a child analyzer, that doesn't sound like it'd be the issue.

Was this analyzer written in BinPAC, or in C++?

  --Vlad

On Tue, Jun 16, 2015 at 9:22 PM, James Swaro james.sw...@gmail.com wrote:

 I have a TCP analyzer that I wrote for my master thesis which I'm trying
 to update to the latest version of Bro. After rebasing to the trunk, I
 observed only a few collisions. I resolved the collisions and but something
 seems to have changed with how the logs are written. Are there changes in
 the logging framework between Bro 2.2 and the current master which could
 influence how events are generated? Could this be a change in how packets
 are delivered to TCP child/support/application analyzers?

 I am only guessing at things as I haven't had much time to debug why the
 logs aren't being generated. From some quick debug, I can see that the
 analyzer is still being added to TCP as a child analyzer, so it seems
 related to either delivery or event generation.

 I know this is little information to go on. I can provide more information
 as needed.

 --
 James Swaro
 Internetworking Research Group
 Ohio University



 ___
 bro-dev mailing list
 bro-dev@bro.org
 http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev


___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1414) Make PIE option availalbe during compiling

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=21001#comment-21001
 ] 

Vlad Grigorescu commented on BIT-1414:
--

There are two compiler/linker flags you can use, fpic and pie. configure can 
take additional flags via env vars, so the only change you should need to make 
in your compilation process is:

{{ CFLAGS=-fpic -pie CXXFLAGS=-fpic -pie ./configure }}

 Make PIE option availalbe during compiling
 --

 Key: BIT-1414
 URL: https://bro-tracker.atlassian.net/browse/BIT-1414
 Project: Bro Issue Tracker
  Issue Type: New Feature
  Components: Bro
Affects Versions: 2.3
 Environment: We would like to request PIE support be built in and 
 available in the Bro binary.  
Reporter: Jeff





--
This message was sent by Atlassian JIRA
(v6.5-OD-05-041#65001)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1414) Make PIE option availalbe during compiling

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=21001#comment-21001
 ] 

Vlad Grigorescu edited comment on BIT-1414 at 6/15/15 5:08 PM:
---

There are two compiler/linker flags you can use, fpic and pie. configure can 
take additional flags via env vars, so the only change you should need to make 
in your compilation process is:

{{CFLAGS=-fpic -pie CXXFLAGS=-fpic -pie ./configure}}


was (Author: grigorescu):
There are two compiler/linker flags you can use, fpic and pie. configure can 
take additional flags via env vars, so the only change you should need to make 
in your compilation process is:

{{ CFLAGS=-fpic -pie CXXFLAGS=-fpic -pie ./configure }}

 Make PIE option availalbe during compiling
 --

 Key: BIT-1414
 URL: https://bro-tracker.atlassian.net/browse/BIT-1414
 Project: Bro Issue Tracker
  Issue Type: New Feature
  Components: Bro
Affects Versions: 2.3
 Environment: We would like to request PIE support be built in and 
 available in the Bro binary.  
Reporter: Jeff





--
This message was sent by Atlassian JIRA
(v6.5-OD-05-041#65001)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1414) Make PIE option availalbe during compiling

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20912#comment-20912
 ] 

Vlad Grigorescu commented on BIT-1414:
--

It worked just fine for me. What issues were you having, specifically?

 Make PIE option availalbe during compiling
 --

 Key: BIT-1414
 URL: https://bro-tracker.atlassian.net/browse/BIT-1414
 Project: Bro Issue Tracker
  Issue Type: New Feature
  Components: Bro
Affects Versions: 2.3
 Environment: We would like to request PIE support be built in and 
 available in the Bro binary.  
Reporter: Jeff





--
This message was sent by Atlassian JIRA
(v6.5-OD-05-041#65001)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1413) README files misidentified by GitHub

[Vlad Grigorescu (JIRA)]

Vlad Grigorescu created BIT-1413:


 Summary: README files misidentified by GitHub
 Key: BIT-1413
 URL: https://bro-tracker.atlassian.net/browse/BIT-1413
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: Documentation
Reporter: Vlad Grigorescu


If a README file doesn't have an extension, GitHub will parse it as Markdown. 
Because our README files are ReST, this results in some ugly (and not very 
useful) READMEs when visiting the repository on GitHub.

For example, see: https://github.com/bro/btest#readme

There are two options we could take to fix this: rename README to README.rst, 
or create a symlink. I tried out the symlink option here, and I think the 
result is much more useful: https://github.com/grigorescu/btest#readme

The affected repos are:

binpac
bro
bro-aux
bro-plugins
bro-scripts
broccoli
broccoli-perl
broccoli-python
broccoli-ruby
broctl (broctl's README just instructs users to see doc/broctl.rst. This could 
just be a symlink)
broker
bromagic (this can probably be deleted?)
btest
capstats
time-machine
trace-summary




--
This message was sent by Atlassian JIRA
(v6.5-OD-05-041#65001)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1412) Documentation/control of Jira markup shortcuts?

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20908#comment-20908
 ] 

Vlad Grigorescu commented on BIT-1412:
--

I don't think they're modifiable, but you can disable them if you'd prefer. You 
can view the shortcuts by using the ? shortcut, or by clicking on the 
question mark at the upper right, and then selecting Keyboard Shortcuts.

Once the shortcut modal is displayed, there's an option to disable them at the 
bottom.

 Documentation/control of Jira markup shortcuts?
 ---

 Key: BIT-1412
 URL: https://bro-tracker.atlassian.net/browse/BIT-1412
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: TicketTracker
Reporter: Vern Paxson

 I find that some of the keystroke bindings for markup when typing in a 
 Description (like this one!) are counterintuitive for me and would like to 
 change them.  However, searching the Jira documentation I haven't been able 
 to find where these shortcuts are documented (as opposed to more general ones 
 that aren't about markup).  Where do I look for info like this?



--
This message was sent by Atlassian JIRA
(v6.5-OD-05-041#65001)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1412) Documentation/control of Jira markup shortcuts?

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20910#comment-20910
 ] 

Vlad Grigorescu commented on BIT-1412:
--

Ah, my mistake. I believe the editor shortcuts are a subset of those listed 
here: 
https://confluence.atlassian.com/display/ConfCloud/Keyboard+Shortcuts#KeyboardShortcuts-Intheeditor

If I disable the keyboard shortcuts, the editor shortcuts get disabled as well, 
if that helps...

 Documentation/control of Jira markup shortcuts?
 ---

 Key: BIT-1412
 URL: https://bro-tracker.atlassian.net/browse/BIT-1412
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: TicketTracker
Reporter: Vern Paxson

 I find that some of the keystroke bindings for markup when typing in a 
 Description (like this one!) are counterintuitive for me and would like to 
 change them.  However, searching the Jira documentation I haven't been able 
 to find where these shortcuts are documented (as opposed to more general ones 
 that aren't about markup).  Where do I look for info like this?



--
This message was sent by Atlassian JIRA
(v6.5-OD-05-041#65001)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1410) tx_hosts and rx_hosts switched in files.log

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20911#comment-20911
 ] 

Vlad Grigorescu commented on BIT-1410:
--

Fix is in branch topic/vladg/bit-1410 in bro, bro-testing and 
bro-testing-private. I just propagated is_orig down to MIME_Mail.

The POP3 analyzer was also touched, but since it's missing btests, I didn't 
write any tests for that change.

 tx_hosts and rx_hosts switched in files.log
 ---

 Key: BIT-1410
 URL: https://bro-tracker.atlassian.net/browse/BIT-1410
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: Bro
 Environment: Linux Ubuntu 
Reporter: Ali Hadi
Priority: High
  Labels: analyzer
 Fix For: 2.4


 Hi,
 _Based on Robin's request I opened this ticket.
 _
 If you use the PCAP below and analyze it using Bro:
 https://www.bro.org/static/traces/email.pcap
 Then when checking the files.log, the tx_hosts is supposed to show the host 
 who transmitted the file, and rx_hosts is for the host who received the file 
 based on Bro's documentation: 
 https://www.bro.org/sphinx-git/scripts/base/frameworks/files/main.bro.html
 If you do the following:
 cat files.log | bro-cut fuid tx_hosts rx_hosts | grep ID OF THE LEAKED PDF 
 FILE
 You'll get that the TX Host IP (SrcIP) is 192.168.121.176 and not 
 192.168.121.179 !!!
 It seems that Bro switched their positions in the output. I found this in an 
 assignment given to my students, and one of them gave me a result completely 
 different. So when I double checked with Wireshark, I found that the IPs have 
 been switched by Bro.
 Hope this helps.
 Ali



--
This message was sent by Atlassian JIRA
(v6.5-OD-05-041#65001)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1394) Github commit seems to have possible configure issues?

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20602#comment-20602
 ] 

Vlad Grigorescu commented on BIT-1394:
--

When working with Bro behind an HTTP proxy, I use a config based on this: 
https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy

 vladg@dev-01 ~ % git config -l | grep proxy
 http.proxy=http://proxy.example.net:3128
 core.gitproxy=/home/vladg/bin/gitproxy
 vladg@dev-01 ~ % cat bin/gitproxy
 #!/bin/sh
 
 _proxy=proxy.example.net
 _proxyport=3128
 
 exec socat STDIO PROXY:$_proxy:$1:$2,proxyport=$_proxyport

 Github commit seems to have possible configure issues?
 --

 Key: BIT-1394
 URL: https://bro-tracker.atlassian.net/browse/BIT-1394
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: Bro
Affects Versions: git/master
 Environment: * Dell C6220 (PER blade: 128GB of ram | 2 socket | 16 
 cores per socket | 2-10G cards)
 * Ubuntu 14.04.2 LTS system
 * Feeding in 20Gb/s links
 * PF_RING-6.0.3 compiled into /opt/pfring
 Packages installed from base (other than SSH during select-install):
 build-essential libnuma-dev pkg-config cmake make gcc g++ swig flex bison 
 libpcap-dev libgeoip-dev libssl-dev python-dev zlib1g-dev libmagic-dev 
 swig2.0 libgoogle-perftools-dev google-perftools libxml2-dev 
 libcurl4-gnutls-dev mailutils
 Have also added GeoIP databases manually.
 pfring loaded with modprobe:
 modprobe pf_ring enable_tx_capture=0 min_num_slots=32768
Reporter: Ventz Petkov
Priority: Low
 Attachments: CMakeOutput.log


 When checking out latest master branch 
 (https://github.com/bro/bro/commit/1e66c6718a98675fb838205a5e55220e9794eeb7), 
 and given the above environment, error at configure:
 
 bro# ./configure --with-pcap=/opt/pfring
 Build Directory : build
 Source Directory: /root/install/bro
 CMake Error at CMakeLists.txt:7 (include):
   include could not find load file:
 cmake/CommonCMakeConfig.cmake
 CMake Error at CMakeLists.txt:52 (include):
   include could not find load file:
 FindRequiredPackage
 -- Found sed: /bin/sed
 CMake Error at CMakeLists.txt:64 (FindRequiredPackage):
   Unknown CMake command FindRequiredPackage.
 -- Configuring incomplete, errors occurred!
 See also /root/install/bro/build/CMakeFiles/CMakeOutput.log.
 
 Attaching log file CMakeOutput.log



--
This message was sent by Atlassian JIRA
(v6.5-OD-03-002#65000)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1384) Optimize option leads to internal error

[Vlad Grigorescu (JIRA)]

Vlad Grigorescu created BIT-1384:


 Summary: Optimize option leads to internal error
 Key: BIT-1384
 URL: https://bro-tracker.atlassian.net/browse/BIT-1384
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: Bro
Reporter: Vlad Grigorescu


On a whim, I tried using the optimize option:

  % bro -O -Cr ~/pcaps/sansholidayhack2013.pcap
 internal error in 
 /home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad 
 tag in same_expr()
 zsh: abort  bro -O -Cr ~/pcaps/sansholidayhack2013.pcap

I'm not sure if I'm not using this right, or what. If it's not used much any 
more, should we consider removing it? Backtrace follows.

internal error in 
/home/vladg/src/bro/scripts/base/frameworks/logging/./main.bro, line 507: bad 
tag in same_expr()

bq. Program received signal SIGABRT, Aborted.
bq. 0x75eda5e7 in raise () from /lib64/libc.so.6
bq. (gdb) bt
bq. #0  0x75eda5e7 in raise () from /lib64/libc.so.6
bq. #1  0x75edb9c8 in abort () from /lib64/libc.so.6
bq. #2  0x00835dc4 in Reporter::InternalError (this=0x111d6c0, 
fmt=0xbe3b69 bad tag in same_expr()) at 
/home/vladg/src/bro/src/Reporter.cc:150
bq. #3  0x007f813b in same_expr (e1=0x14662a0, e2=0x1466240) at 
/home/vladg/src/bro/src/Expr.cc:5984
bq. #4  0x007f7e35 in same_expr (e1=0x146a4b0, e2=0x146a410) at 
/home/vladg/src/bro/src/Expr.cc:5911
bq. #5  0x007e7fbe in BoolExpr::DoSimplify (this=0x14661e0) at 
/home/vladg/src/bro/src/Expr.cc:2036
bq. #6  0x007e1719 in BinaryExpr::Simplify (this=0x14661e0) at 
/home/vladg/src/bro/src/Expr.cc:586
bq. #7  0x007f7a96 in simplify_expr (e=0x14661e0, 
simp_type=SIMPLIFY_GENERAL) at /home/vladg/src/bro/src/Expr.cc:5828
bq. #8  0x0089194d in ExprStmt::Simplify (this=0x1466180) at 
/home/vladg/src/bro/src/Stmt.cc:388
bq. #9  0x00899831 in simplify_stmt (s=0x1466180) at 
/home/vladg/src/bro/src/Stmt.cc:2282
bq. #10 0x008975dc in StmtList::Simplify (this=0x1466540) at 
/home/vladg/src/bro/src/Stmt.cc:1786
bq. #11 0x00774d60 in yyparse () at parse.y:1177
bq. #12 0x0078b854 in main (argc=4, argv=0x7fffe2d8) at 
/home/vladg/src/bro/src/main.cc:893



--
This message was sent by Atlassian JIRA
(v6.5-OD-01-120#65000)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20413#comment-20413
 ] 

Vlad Grigorescu commented on BIT-1369:
--

I tweaked the kinit btest to print output for one of the other events, and I 
added another btest that tests the TGS events.

I couldn't find a good way to generate the other events in my test environment 
- I've often seen them in Microsoft AD environments, and not in the MIT or 
Heimdal implementations.

Of the untested events, ```krb_ap_response``` and ```krb_priv``` only have the 
connection information, ```krb_cred`` and ```krb_safe``` are rarely seen. I'll 
keep thinking of a way to test those, but I don't think that should be a 
blocker.

 Kerberos Analyzer
 -

 Key: BIT-1369
 URL: https://bro-tracker.atlassian.net/browse/BIT-1369
 Project: Bro Issue Tracker
  Issue Type: New Feature
  Components: Bro
Affects Versions: 2.4
Reporter: Vlad Grigorescu
Assignee: Robin Sommer
 Fix For: 2.4


 topic/vladg/kerberos has a Kerberos analyzer.



--
This message was sent by Atlassian JIRA
(v6.5-OD-01-120#65000)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20401#comment-20401
 ] 

Vlad Grigorescu commented on BIT-1365:
--

 Any reason why local-local couldn't be set to INTERNAL? and I suppose 
 remote-remote set to EXTERNAL?

Hmm. I don't think those are quite right. The biggest issue is that they're 
technically not directions, just endpoint attributes. It does simplify some 
searches, but it still leaves something to be desired there (e.g. if I want to 
see all SSH connections to systems on my network, I need to search for INBOUND 
|| INTERNAL).

I agree that there's a better solution out there, but I think this exposes a 
larger issue. There are some open questions about local_nets - should RFC-1918 
space be in there, or just public space? Should connections from neighbor nets 
be denoted in the logs as well? What if IP space alone isn't enough to denote 
my local networks, what if I need, say, VLAN IDs?

What might make sense is just to split this into two fields that denote where 
orig_h and resp_h are, in the order PRIVATE, LOCAL, NEIGHBOR, EXTERNAL (i.e. if 
is_private_addr return PRIVATE; else if is_local_addr return LOCAL...).

We can leave this ticket open to discuss better options down the line - this is 
marked as a TODO in the script.

 direction field of SSH::Info no longer populated
 

 Key: BIT-1365
 URL: https://bro-tracker.atlassian.net/browse/BIT-1365
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: Bro
Affects Versions: git/master
Reporter: Jon Siwek
 Fix For: 2.4


 Here's the bug report:
 {quote}
 Reporter::ERROR   field value missing
 [SSH::c$ssh$direction]
 /usr/local/bro/share/bro/policy/protocols/ssh/geo-da
 ta.bro, line 29
 Reporter::WARNING non-void function returns without a value:
 SSH::get_location (empty)
 Tracing this back, it looks like the SSH::c$ssh$direction is not being
 populated. I checked the /base/protocols/ssh/main.bro file and it looks
 like the function is missing.
 Looking at https://www.bro.org/sphinx/_downloads/main32.bro and
 https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro
 it looks like the function that determined the direction was removed at
 one point, which looks like it causes the
 /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail
 {quote}



--
This message was sent by Atlassian JIRA
(v6.5-OD-01-120#65000)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1380) Files::add_analyzer documentation has too many fields

[Vlad Grigorescu (JIRA)]

Vlad Grigorescu created BIT-1380:


 Summary: Files::add_analyzer documentation has too many fields
 Key: BIT-1380
 URL: https://bro-tracker.atlassian.net/browse/BIT-1380
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: Documentation
Reporter: Vlad Grigorescu
Priority: Low


I was looking at: 
[Files::add_analyzer|https://www.bro.org/sphinx-git/scripts/base/frameworks/files/main.bro.html#id-Files::add_analyzer],
 and noticed that too many fields seem to be listed for the default of 
AnalyzerArgs. The same thing happens for remove_analyzer.

Is this something we could get cleaned up?



--
This message was sent by Atlassian JIRA
(v6.5-OD-01-120#65000)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1379) PE File Analyzer

[Vlad Grigorescu (JIRA)]

Vlad Grigorescu created BIT-1379:


 Summary: PE File Analyzer
 Key: BIT-1379
 URL: https://bro-tracker.atlassian.net/browse/BIT-1379
 Project: Bro Issue Tracker
  Issue Type: New Feature
  Components: Bro
Reporter: Vlad Grigorescu


topic/vladg/file-analysis-exe-analyzer has some fixes and cleanup of 
topic/seth/file-analysis-exe-analyzer in order to add a Portable Executable 
file analyzer. The branch has been pushed to bro, bro-testing and 
bro-testing-private.

As one might expect, there's a ton of information in the PE file format. The 
code will only interpret the headers, but that information will still provide a 
lot of actionable data.

I believe that this is ready and would be a good addition to 2.4, but as it 
wasn't previously discussed, we can punt on it if we have to.



--
This message was sent by Atlassian JIRA
(v6.4-OD-16-006#64014)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1379) PE File Analyzer

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-1379:
-
Status: Merge Request  (was: Open)

 PE File Analyzer
 

 Key: BIT-1379
 URL: https://bro-tracker.atlassian.net/browse/BIT-1379
 Project: Bro Issue Tracker
  Issue Type: New Feature
  Components: Bro
Reporter: Vlad Grigorescu

 topic/vladg/file-analysis-exe-analyzer has some fixes and cleanup of 
 topic/seth/file-analysis-exe-analyzer in order to add a Portable Executable 
 file analyzer. The branch has been pushed to bro, bro-testing and 
 bro-testing-private.
 As one might expect, there's a ton of information in the PE file format. The 
 code will only interpret the headers, but that information will still provide 
 a lot of actionable data.
 I believe that this is ready and would be a good addition to 2.4, but as it 
 wasn't previously discussed, we can punt on it if we have to.



--
This message was sent by Atlassian JIRA
(v6.4-OD-16-006#64014)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1370) SIP Analyzer

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20323#comment-20323
 ] 

Vlad Grigorescu commented on BIT-1370:
--

I merged master, updated the tests (no changes to bro-testing and 
bro-testing-private), and updated NEWS.

 SIP Analyzer
 

 Key: BIT-1370
 URL: https://bro-tracker.atlassian.net/browse/BIT-1370
 Project: Bro Issue Tracker
  Issue Type: New Feature
  Components: Bro
Affects Versions: 2.4
Reporter: Vlad Grigorescu
Assignee: Vlad Grigorescu
 Fix For: 2.4


 topic/vladg/sip has a SIP analyzer.



--
This message was sent by Atlassian JIRA
(v6.4-OD-16-006#64014)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1370) SIP Analyzer

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-1370:
-
Status: Merge Request  (was: Open)

 SIP Analyzer
 

 Key: BIT-1370
 URL: https://bro-tracker.atlassian.net/browse/BIT-1370
 Project: Bro Issue Tracker
  Issue Type: New Feature
  Components: Bro
Affects Versions: 2.4
Reporter: Vlad Grigorescu
Assignee: Vlad Grigorescu
 Fix For: 2.4


 topic/vladg/sip has a SIP analyzer.



--
This message was sent by Atlassian JIRA
(v6.4-OD-16-006#64014)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20320#comment-20320
 ] 

Vlad Grigorescu commented on BIT-1369:
--

I merged master, updated the tests (no changes to bro-testing and 
bro-testing-private), and updated NEWS.

 Kerberos Analyzer
 -

 Key: BIT-1369
 URL: https://bro-tracker.atlassian.net/browse/BIT-1369
 Project: Bro Issue Tracker
  Issue Type: New Feature
  Components: Bro
Affects Versions: 2.4
Reporter: Vlad Grigorescu
Assignee: Vlad Grigorescu
 Fix For: 2.4


 topic/vladg/kerberos has a Kerberos analyzer.



--
This message was sent by Atlassian JIRA
(v6.4-OD-16-006#64014)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-1369:
-
Status: Merge Request  (was: Open)

 Kerberos Analyzer
 -

 Key: BIT-1369
 URL: https://bro-tracker.atlassian.net/browse/BIT-1369
 Project: Bro Issue Tracker
  Issue Type: New Feature
  Components: Bro
Affects Versions: 2.4
Reporter: Vlad Grigorescu
Assignee: Vlad Grigorescu
 Fix For: 2.4


 topic/vladg/kerberos has a Kerberos analyzer.



--
This message was sent by Atlassian JIRA
(v6.4-OD-16-006#64014)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated

[Vlad Grigorescu (JIRA)]

[ 
https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20319#comment-20319
 ] 

Vlad Grigorescu commented on BIT-1365:
--

This is fixed in topic/vladg/ssh.

When fixing this, I found a bug with the old implementation. The documentation 
states that: If a client was a local host logging into an external host, this 
would be OUTBOUND. INBOUND would be set for the opposite situation. However, 
only Site::is_local_addr(c$id$orig_h) was being checked, so local-local would 
always be OUTBOUND and remote-remote (which could happen if, for example, you 
haven't set local_nets) would always be INBOUND.

I was torn between restoring the old implementation, or doing what the 
documentation states. I decided to implement what's documented. The field will 
be unset for local-local or remote-remote conns.

 direction field of SSH::Info no longer populated
 

 Key: BIT-1365
 URL: https://bro-tracker.atlassian.net/browse/BIT-1365
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: Bro
Affects Versions: git/master
Reporter: Jon Siwek
Assignee: Vlad Grigorescu
 Fix For: 2.4


 Here's the bug report:
 {quote}
 Reporter::ERROR   field value missing
 [SSH::c$ssh$direction]
 /usr/local/bro/share/bro/policy/protocols/ssh/geo-da
 ta.bro, line 29
 Reporter::WARNING non-void function returns without a value:
 SSH::get_location (empty)
 Tracing this back, it looks like the SSH::c$ssh$direction is not being
 populated. I checked the /base/protocols/ssh/main.bro file and it looks
 like the function is missing.
 Looking at https://www.bro.org/sphinx/_downloads/main32.bro and
 https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro
 it looks like the function that determined the direction was removed at
 one point, which looks like it causes the
 /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail
 {quote}



--
This message was sent by Atlassian JIRA
(v6.4-OD-16-006#64014)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1365) direction field of SSH::Info no longer populated

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-1365:
-
Status: Merge Request  (was: Open)

 direction field of SSH::Info no longer populated
 

 Key: BIT-1365
 URL: https://bro-tracker.atlassian.net/browse/BIT-1365
 Project: Bro Issue Tracker
  Issue Type: Problem
  Components: Bro
Affects Versions: git/master
Reporter: Jon Siwek
Assignee: Vlad Grigorescu
 Fix For: 2.4


 Here's the bug report:
 {quote}
 Reporter::ERROR   field value missing
 [SSH::c$ssh$direction]
 /usr/local/bro/share/bro/policy/protocols/ssh/geo-da
 ta.bro, line 29
 Reporter::WARNING non-void function returns without a value:
 SSH::get_location (empty)
 Tracing this back, it looks like the SSH::c$ssh$direction is not being
 populated. I checked the /base/protocols/ssh/main.bro file and it looks
 like the function is missing.
 Looking at https://www.bro.org/sphinx/_downloads/main32.bro and
 https://github.com/bro/bro/blob/master/scripts/base/protocols/ssh/main.bro
 it looks like the function that determined the direction was removed at
 one point, which looks like it causes the
 /usr/local/bro/share/bro/policy/protocols/ssh/geo-data.bro script to fail
 {quote}



--
This message was sent by Atlassian JIRA
(v6.4-OD-16-006#64014)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] [JIRA] (BIT-1369) Kerberos Analyzer

[Vlad Grigorescu (JIRA)]

 [ 
https://bro-tracker.atlassian.net/browse/BIT-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vlad Grigorescu updated BIT-1369:
-
Fix Version/s: 2.4

 Kerberos Analyzer
 -

 Key: BIT-1369
 URL: https://bro-tracker.atlassian.net/browse/BIT-1369
 Project: Bro Issue Tracker
  Issue Type: New Feature
  Components: Bro
Affects Versions: 2.4
Reporter: Vlad Grigorescu
Assignee: Vlad Grigorescu
 Fix For: 2.4


 topic/vladg/kerberos has a Kerberos analyzer.



--
This message was sent by Atlassian JIRA
(v6.4-OD-16-006#64014)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev