Re: [Bro-Dev] "delete" of entire tables/sets
> I believe the clear_table() function still exists in zeek, as well... Hah^2! Yeah, it does. Well, glad I consulted the list before diving into some hacking :-P. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] "delete" of entire tables/sets
> I guess re-assigning a new, empty table to the variable could be > analogous to deleting all entries and also avoids the iterator > invalidation problem ? Hah!, yeah, that's certainly a simple way to do it. Maybe I'll change my hacking for now to just be adding this observation to the "delete" documentation :-). Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] "delete" of entire tables/sets
I'm working on some scripts where I want to remove every element from a table in a single shot. In awk, "delete tbl" would do the trick, but Zeek restricts delete operations to removing single elements. Worse, if I try iterating over an aggregate to remove elements piece-wise, it doesn't remove all of them, no doubt because the internal hash table is changing mid-stream of the "for" loop and thus doesn't visit all of the members. This means I have to first build up a *separate* vector of all the indexes, then iterate over that to remove them. Proposal: extend "delete" so that if applied to a table or a set, it clears out all of its elements. This seems straightforward to me, and something that I'll see if I can find some cycles soon to hack out. Comments? Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Consistent error handling for scripting mistakes
I like what you & Robin sketch. FWIW, it's hard for me to get excited over the issue of leaks-in-the-face-of-error-recovery. Presumably it would take in practice a lot of error recovery before this actually hoses the execution due to running out of memory. At that point, it's not unreasonable for things to keel over anyway. An alternative/additional approach would be to introduce a notion of "failure" as a first-class object. In another life I used a language that did that, and it worked remarkably well. But clearly that's a bigger undertaking than the valuable near-term notion of regularizing how Zeek deals with errors. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] attributes & named types
Thanks a bunch for the further context & discussion. The more I've delved into this, the more convinced I've become that we have a basic architectural problem with attributes: they're associated with identifiers and values, but not types ... *except* for hacky ways for records and record fields. My alternative implementation for type names fares a bit better with the example you gave at http://try.bro.org/#/trybro/saved/275829 ... but still gives counterintuitive behavior when I introduce a minor variant (I'll spare you the details), with the problem being that a subsequent use of (rather than the use when a record is declared) isn't propagated to the record's individual fields. I could I guess add code to do that propagation ... but testing further, none of this fixes the original problem that I cared about, which is to be able to declare types with values for tables, ala BIT-248: type str_tbl: table[string] of string =""; Here the problem is that the only opportunity to associate a attribute with a table is when instantiating a table value. It doesn't work if str_tbl is instead used to define a record field, similar to the lack of propagation for I think what we need to do is rethink the basic architecture/structure of attributes. In particular, types in general (not just named types) should be able to have attributes associated with them. The attributes associated with an identifier are those associated with its type plus those directly associated with the identifier (like ). While doing this, we can also think about mechanisms for removing attributes. I don't think the "=F" approach mentioned earlier on this thread will do the trick, since it's syntactically/semantically quite weird for attributes that already take expressions as values, such as or _expire. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] attributes & named types
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.) Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] attributes & named types
H I've looked into this and there are some subtle issues.
First, I tried to make this work using TypeType's like I had sketched, and
it turns out to be a mess. Too many points where a decision has to be
made whether to access the base type (what the named type points to) rather
than the TypeType itself.
I then had an Aha and realized it can instead be done in the grammar, by
associating different semantics with resolving type names depending on the
context in which they appear. I have this working. It's pretty simple, too.
HOWEVER: running on the test suite points up an issue I hadn't anticipated.
We have attributes associated with named types that currently aren't expected
to propagate. One example is from share/bro/base/init-bare.bro:
## A connection's identifying 4-tuple of endpoints and ports.
##
## .. note:: It's actually a 5-tuple: the transport-layer protocol is
stored as
##part of the port values, `orig_p` and `resp_p`, and can be
extracted from
##them with :bro:id:`get_port_transport_proto`.
type conn_id: record {
orig_h: addr; ##< The originator's IP address.
orig_p: port; ##< The originator's port number.
resp_h: addr; ##< The responder's IP address.
resp_p: port; ##< The responder's port number.
}
So conn_id's have associated with them. I'm not sure why this was
done (maybe a question for @Seth), since previously this was a no-op.
However, with my change/fix, this now means that any use of a conn_id
automatically inherits In principle, that's consistent with the
on-the-face-of-it semantics ... but it will likely lead to significant
unwanted effects if left unaddressed.
I have a couple of thoughts regarding this:
(1) I can go through the existing scripts and remove such attributes
where they currently appear. I believe that this shouldn't have
any effect because previously those weren't propagated anyway;
their presence seems to me more a bug than anything else, but
maybe I'm missing something.
(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".
Comments?
Vern
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] consistency checking for attributes
> To be honest I'm not even sure if the behavior > is defined right now, i.e. if the later value will overwrite the first one. I don't think it's defined. Looking at the code, the later one will indeed overwrite the first one. > Do you want to error out when two are found or overwrite the > first with the second one? My thinking is that listing them together should be an error. I don't see why it would be legitimate for this to occur, and it seems like a mistake that could be made if there's a lengthy list of attributes. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] consistency checking for attributes
> I'm thinking of implementing this as an internal table of meta-attributes, > i.e., each attribute type, like ATTR_OPTIONAL, will have its own attributes > ... Looking into this further, it appears that the basic issue is that while Attributes::CheckAttr already tries to make sure that a given attribute makes sense, its checking is deficient. Some of this might be because it lacks information about whether the attribute is appearing in the context of a type or a variable. Also, Attributes::AddAttr already checks for repeated attributes, but it just silently replaces them. This works okay for a situation where a type is being refined by introducing updated attributes, but doesn't make sense when all of the attributes are presented together (like in my example); again, it needs more context to figure that out. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] consistency checking for attributes
Attributes currently receive essentially no consistency checking.
For example, executing this script:
global a: count
= 10
= 9
_func = function(d: double, t: time): count { return 3; };
print a;
simply results in:
error in /Users/vern/tmp/attr-type-check.bro, line 7: value used but not set (a)
I'm planning to add basic consistency checking, which will look for
(1) attributes that are repeated (which doesn't appear to be meaningful for
any of them) and (2) attributes that don't make sense in a given context,
like the ones listed above.
I'm thinking of implementing this as an internal table of meta-attributes,
i.e., each attribute type, like ATTR_OPTIONAL, will have its own attributes
like whether it requires a record context, only makes sense for aggregates,
etc. Here are the ones that come to mind, based on looking at the attributes
at https://www.bro.org/sphinx/script-reference/attributes.html with examples
in parens:
applies to global variable ()
to global type ()
to event handler()
to record field ()
to indexed type ()
to global indexed type (_func)
to type with expirable entries (_func)
to a file (_interval)
Any feedback?
Vern
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] attributes & named types
> My understanding was just that TypeType's currently are *not* used > when creating type aliases. Correct. > # Passing the type name/alias as a value. > # The local variable/argument 'x' becomes of type > # "TypeType". It's not of type "count". > foo(mytype); (Note that here any attributes are lost, since there's currently no place for TypeType's to hold them.) > At least that's how I think it's currently working, so are you going > start using TypeType as a means of type aliasing in addition to adding > attributes to them? Not quite. Rather, the type of "mytype" would be a TypeType, which would have attributes. The TypeType instance however would not know that it belongs to "mytype" (just as is currently the case). We could continue to support a call like "foo(mytype)" above by hoisting the base type (what the TypeType points to) when evaluating the expression "mytype", just as currently the identifier gets turned into a TypeType at that point. That said, just what is the use for calls like "foo(mytype)" anyway? Seems a bit peculiar, but maybe I'm missing something. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] attributes & named types
> Other ideas I'm having for solving the overall problem are: > > (1) 'a' and 'b' need to actually be distinct BroType's. Instead of > 'b' being a reference/alias to 'a' with extended attributes, just > create it as it's own BroType by first cloning 'a', then adding any > additional attributes. I originally went down this route, but this involves adding attributes to all types, since currently types don't have attributes. Seems like a poor fit given there's only one class of type (named ones) that need this. > (2) BroType could somehow store a mapping of identifier -> attributes > so that on declaring a variable of either 'a' or 'b', we can choose > which attributes apply. That seems more hacky than (1), as it involves adding still more to types-in-general. Seems simplest to me to have TypeType's (and only those) include attributes. The rest of it is easy to do from there. We could also do this with a separate NameType, but I don't see what that gains, since TypeType's already come into existence because of binding names to types. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] attributes & named types
> I think the right solution for this is to introduce a new BroType called > a NamedType. A NamedType has an identifier, an underlying BroType, and a > set of attributes. When a NamedType is constructed ... Huh, turns out there's already a "TypeType", which is the equivalent. All I need to do, I believe, is allow these to have attributes. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] attributes & named types
For some scripting I'm doing, I'm running into the problem that attributes associated with named types don't get propagated. For example, type a: table[count] of count = 5; global c: a; print c[9]; complains that c[9] isn't set, instead of returning the value 5. Having dived[*] into this and examined some potential fixes, I've identified that the problem is that (1) the attribute " = 5" in the above example gets associated with the identifier 'a' rather than with a's type, and (2) when the parser processes the second line, early in the process 'a' gets converted to its underlying type, with the attributes lost at that point since, internally, BroType's do not have attributes. This is a pain to deal with. If we simply add attributes to BroType's and for statements like the first line associate the attributes with the type, then a sequence like: type a: table[count] of count = 5; type b: a _expire = 1 min; will wind up changing the attributes associated with 'a' even though it really shouldn't. I think the right solution for this is to introduce a new BroType called a NamedType. A NamedType has an identifier, an underlying BroType, and a set of attributes. When a NamedType is constructed, for its attributes it combines both the explicit attributes in its declaration (like the _expire for 'b' above) and the implicit (i.e., it inherits/copies the from 'a'). I plan to implement this soon, so please speak up if you have thoughts. Vern [*] The dive also exposed some other bugs in attribute processing, which I'll enter into the tracker shortly. ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] case-insensitive patterns
> > I am fine with implementing either (?[flags]) or (?[flags]:[pattern) or > > both. > > I'm going to just do the latter then, as it's a simple syntax change from > what I currently have, whereas the other is more involved. (this change is now pushed) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] case-insensitive patterns
> I am fine with implementing either (?[flags]) or (?[flags]:[pattern) or > both. I'm going to just do the latter then, as it's a simple syntax change from what I currently have, whereas the other is more involved. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] case-insensitive patterns
> Just so I have this right: it looks like the preferred would not be > /(?i foo)/ but rather /(?i)foo/, yes? Oh and to follow up on this, so in PCRE does /x((?i)bar)foo/ make the "foo" part case-insensitive too, or not? It's not obvious to me from the page you pointed me at, and I don't have an environment set up to definitively test this. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] case-insensitive patterns
> Hum. Is there a reason why we come up with our own syntax for this? No, just that I didn't have the other syntax on my radar. I was looking at Snort & Suricata and didn't find this; I'm not a PCRE user myself. It's simple to change, will do so now (though I think mine is slightly more cool ;-). > Python supports the exact same syntax. And - to make things easier for > users I think it would be way nicer if we just also would do this. Sure. Just so I have this right: it looks like the preferred would not be /(?i foo)/ but rather /(?i)foo/, yes? Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] case-insensitive patterns
Once I wound up monkeying around with the internals of the pattern-matching code (to fix leaks, because Johanna [correctly] pushed back on adding the &/| operators for general use if they leaked, which an old ticket indicated they would) ... I thought what-the-heck, it's time for supporting case-insensitive patterns. This turned out to be tricky to implement, as I gleaned from talking with Seth about an approach he had tried a while back but abandoned. But I now have it working. Here's the blurb from the NEWS entry in the topics/vern/case-insensitive-patterns branch: - You can now specify that a pattern matches in a case-insensitive fashion by adding 'i' to the end of its specification. So for example /fOO/i == "Foo" yields T, as does /fOO/i in "xFoObar". Characters enclosed in quotes however keep their casing, so /"fOO"/i in "xFoObar" yields F, though it yields T for "xfOObar". You can achieve the same functionality for a subpattern enclosed in parentheses by adding "+i" to the open parenthesis, optionally followed by whitespace. So for example "/foo|(+i bar)/" will match "BaR", but not "FoO". For both ways of specifying case-insensitivity, characters enclosed in double quotes maintain their case-sensitivity. So for example /"foo"/i will not match "Foo", but it will match "foo". The funky (+i ...) syntax isn't meant for general user consumption (though it's okay if a user wants to use it directly), but rather is how I implemented /pattern/i functionality. Basically, /pattern/i turns into /(+i pattern)/. That switch is necessary because the robust way to implement case-insensitive patterns, such that they can be composed with the & and | operators and behave as expected, is to modify the parsing of REs to turn any instance of a letter into a character class (so that /foo/ becomes /[Ff][Oo]Oo]/, just like people have been doing by hand for years), and also to modify the parsing of character classes. That requires alerting the RE scanner that it's doing a case-insensitive (sub)pattern, which in turn requires a prefix operator that specifies case-insensitivity. Let me know if you have any concerns. Otherwise, I'll tee this up for merging early next week. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] more set operators? (equality/subset)
> Oh, neat. If that actually works in all cases (so also with records of > records, etc) Well, it almost does. I tried it with records that contain records and that's fine. For records that contain sets, it often works in my testing, but not always, evidently due to the randomized hash keying, since I can make it go away by always loading the same seeds. The same problem occurs with set deletion: deleting from a set of records-containing-sets sometimes fails to delete an element that's indeed in the set. (Hmmm and we also don't support sets of sets, which seems like a natural.) I think the right answer for this is to have some sort of canonical ordering for hash keys. Seems like a pain given the need to also randomize hash keys. I'll file a ticket, but won't aim to fix it this go-around. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] more set operators? (equality/subset)
> I assume what will at the moment happen with sets is that the pointers of
> records are checked for equality
Specifically, in my branch they are checked for whether the composite hash
index matches. Happily, this works:
type A: record {
a: string;
};
event bro_init()
{
local i = A($a="a");
local j = A($a="a");
print set(i) | set(j);
}
when run prints
{
[a=a]
}
and if you change j to be $a="b" then you get:
{
[a=b],
[a=a]
}
This in fact suggests we could implement record equality by converting the
records to hash indices and then comparing those.
Vern
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] more set operators? (equality/subset)
I've implemented the set operators we discussed, and am now developing test cases. In the process, I'm finding that it would be handy to have set equality and subset/superset testing. These would be (for type equivalence sets): s1 == s2 iff both sets have exactly the same members s1 < s2 iff every element in s1 is in s2, but s2 has some elements not in s1 analogous <=, >, >=, != operators These can already be implemented in terms of existing operators (if I haven't screwed something up): s1 == s2 <=> |s1 & s2| == |s1 | s2| s1 < s2 <=> |s1 & s2| == |s1| && |s1| < |s2| Any concerns with adding these too? Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] patterns and &&/|| vs. &/| operators
> though maybe p1 + p2 would be even better at expressing that > concatenation is happening? I think this is somewhat problematic, since '+' already has a regular-expression meaning which is different. In addition, '&' is a more natural dual to '|' than '+' is. Indeed, in some contexts '|' and '+' are synonyms (e.g., I originally wanted them both for set union). > I also notice from [1]: > > `r/s': an `r' but only if it is followed by an `s' ... > > Maybe another option? Note that Bro's REs don't support that ... and in general that operator is a PITA to support correctly+efficiently. It would also step on the current syntax of '/'s being used to express /re/ 's. > Just making suggestions since I didn't quite get what p1 & p2 would do at > first. Interestingly, I discovered that we have a BIF merge_pattern(p1, p2) which does the same thing as "p1 & p2" (in the new syntax). As best as I can tell it's not used anywhere - plus it's funky (only allows itself to be called if Bro isn't processing traffic yet). Perhaps we can deprecate it, too? Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] v += e (Re: set and vector operators)
> > (3) Implement "v += e" to mean "append the element e to the vector v".
>
> Do we want to do this now, or should we potentially wait a release-cycle
> with it (to prevent the situation where v + e and v+= e means something
> different).
Turns out that "v += e" currently generates an error ("requires two
arithmetic or two string operands"), so it seems safe to me to introduce
it as append-to-vector concurrent with deprecating "v + e" (which from the
discussion on the list it seems likely current has little or no use).
BTW, "v1 += v2" likewise generates an error, even when "v1 + v2" works.
Vern
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] patterns and &&/|| vs. &/| operators
> The meaning of "p1 & p2" would be "yields a pattern that matches both > p1 and p2" versus the meaning of "p1 && p2" currently being "yields a > pattern that matches a p1 followed by a p2" ? No, p1 & p2 would be the new way to express p1 && p2. > I'd generally say that deprecating (emit a warning message pointing to > each usage) for a time period is a more cautious approach. Easy 'nuf, though I'd be amazed if anyone is using p1 && p2 given it's not documented and not intuitive! Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] patterns and &&/|| vs. &/| operators
In working on adding bitwise &/| operators for counts, I've come across apparently undocumented && and || operators for patterns: p1 && p2 yields a pattern that matches a p1 followed by a p2 p1 || p2 yields a pattern that matches either p1 or p2 Confusingly, Bro also supports "p1 | p2", which means the same as "p1 || p2" above, but *only* if p1 and p2 are literal patterns, not if they are variables of type "pattern". (This functionality is in common use.) It doesn't support "p1 & p2" in any form. I searched a large corpus of scripts and didn't find any instances of "p1 && p2" or "p1 || p2" for literal patterns, so I suspect the current feature is basically unused. Proposal: as part of adding bitwise &/| operators for counts, I'll also implement &/| operators for patterns, and remove the current &&/|| functionality. This seems pretty straightforward to me - but I've mistakenly thought that about other things before! :-P So if anyone has comments, plz speak up ... Vern % bro -e 'print (/foo/ && /bar/) in "xfoobary"' T ___ 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
> My thought for this was simply if it mattered *where* in the state history > the trouble occurred. I agree that it could ... but I think for at least some situations where it does, for the logs to help in diagnosing them will require something well beyond indicator flags. It's interesting to consider what these might look like, but for now I'd like to get this simpler additional functionality implemented, as I think it'll already be handy - not pointwise for diagnosing specific connections, but as manifest more in aggregate, such as "gee when we talk with a.b.0.0/16 we sure to rack up the checksum errors" or such. > 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. Sounds good. I'll aim to have a branch that people can try out ready in a bit. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
1.5 months ago we haggled over adding these and came close to converging, and then I dropped the ball on trying to ice the deal :-(. (Well, I also needed some time to lick my wounds, since I didn't get my way much on syntax preferences! :-P) Here's where I believe we wound up: (1) Add bitwise operators on "count" variables for &, | and ~. (2) Deprecate element-wise arithmetic operations on vectors, such as "v * 3" meaning "multiply each element of v by 3". Perhaps down the road we'll introduce syntax that flags things like "for this expression, vectorize it". (3) Implement "v += e" to mean "append the element e to the vector v". (4) Wait on whether "v + e" should mean "return a vector that is v with the element e appended". (And indeed we can't do this right now if we're #2.) (5) Keep "add" and "delete" for manipulating sets in terms of individual elements. (6) Add "s1 & s2", "s1 | s2", and "s1 - s2" as intersection, union, and set difference. I'm not clear whether we reached agreement on: (7?) Add "s1 &= s2" etc. to mean "s1 = s1 & s2". The advantage of having this as an operator is it might more easily enable efficient implementation of some set operations for big sets. I suppose if we have it then we'd be expected to also have: (7') "c1 &= c2" etc., i.e., bitwise assignments for "count" variables. Please chime in if you remember where we wound up differently, and also whether you disagree with #7. Again, my apologies for the lengthy lull in attending to this thread. Vern ___ 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
> 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. > However, I could also interpret it as 10-99 > from orig, 10-99 from resp, 10-99 from orig, 10-99 from resp. Nope. The counter doesn't reset at any point, it's cumulative. > Another question I had was that most of these are TCP-specific. Would > checksum apply to UDP as well? Right, it would apply to UDP too, just like is done presently for the boolean indicator. > As you say, if what I care about is the overall > number compared to the number of packets, that feels more like a > percentage. Well, I think this is yes-and-no. For one, the overall percentage might be quite small and still have a large impact on what's supposed to be a high-speed transfer - particularly if it means that a connection entered an extented timeout-and-back-off - so I don't know if there would be a natural point of inspection for it. (It could also quite large but no big deal because the connection is a runt.) > 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. I'm inclined to wait on refinements like this. Let's first see whether having log-counter-style histories leaves people wanting more before qualitatively changing the nature of the history field, or adding new fields. > 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? Vern ___ 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
> 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
Re: [Bro-Dev] $history extensions - zero windows, logarithmic counts
> I really like those ideas, especially the logarithmic count. Cool :-). > How much would it cost to have an event fired when those thresholds are > crossed? Nice thought. I think it would be too expensive if done for the first instance, but for each of the backed-off instances it ought to be rare enough that it's not a problem. So maybe something like: ## Generated each time a reporting threshold (10, 100, 1000, ...) ## is crossed, starting with 10. event multiple_tcp_zero_windows(c: connection, is_orig: bool, threshold: count); event multiple_tcp_checksum_errors(c: connection, is_orig: bool, threshold: count); event multiple_tcp_retransmissions(c: connection, is_orig: bool, threshold: count); ? Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] $history extensions - zero windows, logarithmic counts
I'm working on two enhancements to the $history tracking for connections
that thought I'd tee them up for comments.
(1) A new history element, 'W'/'w', which means that a TCP receiver
advertised a zero window, indicating that the corresponding process
was unable to keep up with the incoming data. (This element is omitted
in cases where zero windows aren't problematic: initial SYNs, and after
FINs or RSTs.)
(2) A notion of "logarithmic counts" for history events: for certain
events ('C' = checksum, 'T' = retransmission, and 'W' = zero window)
the count is repeated on the 10th/100th/1000th/etc. occurrence. So a
history value of 'ttt' means that the responder sent somewhere between
100 and 999 retransmissions. This is useful because for large
connections, a single checksum error, retransmission, or zero window
is much less significant for analyzing performance issues than a whole
bunch of these.
Comments?
Vern
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
> I think I actually would prefer just keeping add/delete, at least for > sets, and not introduce the plus-syntax. Okay, I can live with this as long as '|' and '-' support add-to-set and remove-from-set. But I think those have to work, given we'll enable them for operations on two sets. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
> It especially feels weird to me if v + e and > v += e are operations that perform something completely different. Yeah, I hear you. OTOH, I *really* would like a succinct way to say "add this to the end of this vector", it's such a common idiom. Robin and I discussed this a bit. Our ultimate thinking was along the lines of: (1) likely there's no significant use right now of "v op e" semantics, given how none of us initially remembered it (2) down the line such semantics could be quite handy if we start pushing on vector operations for doing statistical or ML computations (that's why I added "v op e" in the first place, inspired by how easy R makes these), (3) "v += e" really is a nice append-to-vector idiom (4) so how about we change "v op e" into something else to avoid the conceptual clash w/ v += e, while still having it available for the possible uses in (2) above? The question then was what would be the new "v op e" syntax. The best we could come up with (which we both found not-too-awful) is "vector(v op e)". Wrapped in "vector(...)", the operation becomes the current semantics (apply "op e" separately to each element of v). "v op e" by itself would now be an error (which could point the user at the "vector(...)" syntax as possibly providing what they're looking for). "v += e" would be "append e to v". Do you buy that? Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] pattern values and "||"/"&&" operators
> > p1 || p2returns a pattern that matches either p1 or p2 > > ... Though having the > functionality of the former available in some form would be kind of > nice-I have a few scripts where I would have used that. Oh I left out that that's in fact supported: print /foo/ | /bar/ in "hello Barbara"; prints "T" :-). As does print (/foo/ || /bar/) in "hello Barbara"; (parens now required), which is the one we'd be getting rid of. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] pattern values and "||"/"&&" operators
In implementing bitwise operations for counts (now pretty much done!), I found that Bro's internals actually support "||" and "&&" operators for patterns: p1 || p2returns a pattern that matches either p1 or p2 p1 && p2returns a pattern that matches p1 followed by p2 (Note that this second is not obvious. One might instead expect it to return a pattern that matches only if both p1 and p2 match, where the two could overlap.) This doesn't appear to be documented anywhere. I discussed it with Robin and we both agree that this seems weird and likely not used anywhere. Therefore we're thinking we should deprecate it and eventually remove it. Anyone think otherwise? Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
> A nice thing about "add" and "delete" for sets is that you can infer the > data type that you're operating on just looking at the local code/line. Only sort of. For delete, you don't know whether it's a table or a set, and for neither do you know what type of table/set if you can't immediately apprehend the type of the index (e.g., "delete foo[foo2]" doesn't tell me what type of index the set/table foo uses). > E.g. say you come back to some code after a few months and see "foo += > 1". Not obvious what 'foo' is anymore. I don't think it's reasonable to have the bar be "can you tell what's going on in isolation". It should include consideration of associated context, variable names, and comments. In fact, even now you don't know whether for "foo += 1" foo is an integer, a count, or a double. > I do also notice that you had "s + e" in the proposal and not "v + e". > Isn't that weird by the same logic or is it just an accidental omission? This is because "v + e" already has a meaning: apply "+ e" to each element of v. (Note though that "v += e" is not currently allowed.) > v += e Append element to vector > > And for that, a BiF or generic script-layer function call (if that were > possible) would even make me happy: > > push(v, e) > ... > add_to_set(s, v) > delete_from_set(s, v) Yuck. I would hate this. Might as well use Lisp! A basic tenet of Bro's language design has been to minimize verbosity. (For example, its use of type inference, and its support of C-style operators like "++".) Let's please not move in that direction. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
> Just one more thing still: I'm actually feeling pretty strongly > against having multiple different operators for the same operation > (set union, set addition/removal). I'm fine with removing "add" and "delete" for sets! (But seems we gotta keep them for a good while for backward compatibility. Plus, what would be the remove operator for tables? "t -= index" seems pretty weird to me.) But I don't think we should forego '+' and '-' for sets. It would be too weird that "v += e" works but "s += e" does not (and "add v[e]" blows, so let's not consider going down that path :-P). Once we have s += e, we certainly should have s -= e. And once we have "s + e", "s1 + s2" seems very natural to me too; I don't relish having to explain "oh *that* doesn't work, you have to use s1 | s2" :-P. > will have different preferences which version to prefer; they may not > even remember the other one. Seems to me they're both sufficiently mnemonic that this isn't a big worry. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
Hmmm thinking about it, we can get away with '&' with minimal keyword
conflict because there's such an easy (and natural-to-presume) fix -
namely, rather than "x" you use "x & attrkeyword". Now
there's no problem, since the lexer only recognizes ""
as a unit, with no whitespace allowed.
Given that, here's my updated proposal, with 'c' standing for values of
type count:
s1 + s2 Set union
s1 - s2 Set difference
s1 | s2 Set union
s1 & s2 Set intersection
s1 ^ s2 Set symmetric difference
s + e The set resulting from adding the element 'e' to
the set 's'
s - e The set resulting from removing the element 'e' from
the set 's', if present
s1 {+=, -=, |=, &=, ^=} s2
Perform the corresponding set operation between
s1 and s2 and put the result in s1.
s {+=, -=} e
Add or remove the element e from the set s
c1 | c2
c1 & c2 Bitwise or/and/xor of two count values
c1 ^ c2
c1 {|=, &=, ^=} c2
Perform the corresponding bitwise operation between
c1 and c2 and put the result in c1.
v += e Append the element 'e' to the vector 'v'
s += v Add the elements of 'v' to 's'
s -= v Remove the elements of 'v' from 's', if present
How does that sound?
Vern
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
> On Wed, Apr 25, 2018 at 10:40 -0700, you wrote:
>
> > s1 + s2 Set union (for sets of the same type, of course)
> > s1 || s2Set union
>
> (What's the difference between the two? Or do you mean either one or
> the other?)
No difference. It just seems to me that we need something for intersection,
and using existing operators, the natural for that is "&&". Once we have
that, might as well support "||" for union. But given symmetry with other
operators, "+" should work too.
> Like Justin, I was also thinking "|" and "&" might be more intuitive.
If we didn't have the keyword issue with , then I could see that.
But that strikes me as a significant drawback. (Also, if we do add these,
then a user might reasonably expect them to work bitwise for count's. We
could then consider implementing that too I guess.)
> other languages mgiht also coerce set operands into booleans in such a
> context, so that, e.g., "s1 || s2" evaluates to true if either is
> non-empty.
Hey I don't care about other seriously busted languages! ;-)
> I see the problem with the parser but maybe adding keywords is the way
> to go.
Yuck.
> > s += e Add the element 'e' to set 's'
> > (same as the current "add s[e]")
> > s -= e Remove the 'e' element from 's', if present
> > (same as the current "delete s[e]")
>
> I'd skip these. I don't think we should add an additional set of
> operators for things that Bro already supports
I actually feel the opposite, that "add" is clunky ("delete" a bit less so)
and thus these are more natural. But in particular it seems we ought to
support these due to needing to support "v += e" (which is the one that
I most want!).
> > s1 += s2Same as "s1 = s1 + s2"
>
> (Or s1 |= s2 if we pick "|" for union.)
Yeah, if we bite off the '&'-keyword ugliness. Ugh.
> > v += e Append the element 'e' to the vector 'v'
>
> That's probably the most requested Bro operator ever! :)
Yee-up, per my note above!
> > v += s Append the elements of 's' to the vector 'v',
> > with the order not being defined
>
> This one I'm unsure about. The point about the order being undefined
> seems odd. If I don't care about order, wouldn't I stay with a set?
I do have a use case, but I agree it's odd; let me revisit it to see if
I really do need it. I might instead settle for "vector of set[xxx]".
Vern
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] set and vector operators
> That's very similar to what python does, except they use & and | instead of > && and ||. > I think they do that because 'set or' is closer to 'bitwise or' than 'logical > or' Yeah, I thought of that, but Bro currently doesn't have any '&' or '|' operators, which makes me reluctant to add them just for this. '&' is particularly problematic, as it would introduce ambiguity as to whether "" means the redef attribute, or "use the 'and' operator on the value of the variable 'redef'". We'd have to add a bunch of reserved words to accommodate this. > They also use ^ for symmetric difference. (same here re being a new operator) Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] set and vector operators
I'm working on some scripts that use sets and vectors, sometimes together, and am finding it clunky that Bro doesn't offer much in the way of operators for this. To that end, I'm thinking of implementing some along the following lines, where values starting with 's' are sets, 'v' are vectors, and 'e' are type-compatible elements: s1 + s2 Set union (for sets of the same type, of course) s1 || s2Set union s1 && s2Set intersection s1 - s2 Set difference s += e Add the element 'e' to set 's' (same as the current "add s[e]") s -= e Remove the 'e' element from 's', if present (same as the current "delete s[e]") s1 += s2Same as "s1 = s1 + s2" s1 -= s2Same as "s1 = s1 - s2" v += e Append the element 'e' to the vector 'v' v += s Append the elements of 's' to the vector 'v', with the order not being defined s += v Add the elements of 'v' to 's' s -= v Remove the elements of 'v' from 's', if present These strike me as pretty straightforward, but please chime in if you have comments! Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] [Bro] Segmentation fault while using own signature.
Did anyone follow up on this?
Vern
--- Begin Message ---
Hi all,
So I have a case where if I use following regex in sig file, it works, but
when I edit it and make it more strict I get segmentation fault in like 5
minutes after bro gets normally started:
The working version:
signature rootkit-potential {
payload /.*[0-9\.]{7,15}\|[0-9]{1,5}.*/
event "Potential rootkit"
tcp-state originator
}
signature rootkit-malware {
payload /.*SSH-2\.5-OpenSSH_6\.1\.9.[0-9\.]{7,15}\|\d{1,5}.*/
event "rootkit malware"
tcp-state originator
}
When I change regex to be more restrictive, Seg fault occurs:
signature rootkit-potential {
payload /.*(?:\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\|\d{1,5}).*/
event "Potential rootkit"
tcp-state originator
}
signature rootkit-malware {
payload
/.*SSH-2\.5-OpenSSH_6\.1\.9.(?:\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\|\d{1,5}).*/
event "rootkit malware"
tcp-state originator
}
Any idea what might be going wrong?
Thanks,
Fatema.
___
Bro mailing list
b...@bro-ids.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro--- End Message ---
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Option -z
> If one > could express such analyses easily with a few lines of script code, > that would be quite powerful for doing script inspection that's also > easy to customize. Well sure, but it's not clear one can get to that point without some significant work under the hood anyway in terms of the features needed to make the script-level expression a few lines of code. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Option -z
> Just removing this specific use > of finding NOTICEs, which doesn't seem anybody has been using in a > long time. I wonder if they don't use it because it's not on their radar. It's actually pretty handy, a way of telling when you think the set of NOTICEs should be X, but it's actually X'. Can help with writing documentation or finding dead code (of a form), or telling just what happens due to the hierarchy of @load's that a script pulls in. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Option -z
> Does anybody remember what Bro's option -z is for? Well it's there in CHANGES, per the appended. But yeah looks like it never went anywhere beyond the original instigation, so I think removing it is okay. OTOH, it's a pretty handy general notion, so instead pushing it further strikes me as also reasonable. Vern 0.9a8 Wed Feb 16 17:09:34 PST 2005 - Bro now has a geneal mechanism internal for traversing policy scripts (Umesh Shankar). Various script analyses can be specified using the new -z flag. Currently, the one supported form of analysis is "-z notice", which prints all of the different types of notices that the script you've loaded can generate. For example, "bro -z notice ftp" will generate: Found NOTICE: BackscatterSeen Found NOTICE: FTP_PrivPort Found NOTICE: FTP_BadPort Found NOTICE: PortScan Found NOTICE: FTP_ExcessiveFilename Found NOTICE: ScanSummary Found NOTICE: AddressDropped Found NOTICE: DroppedPackets Found NOTICE: SensitiveConnection Found NOTICE: FTP_UnexpectedConn Found NOTICE: SSH_Overflow Found NOTICE: FTP_Sensitive Found NOTICE: TerminatingConnection Found NOTICE: PasswordGuessing Found NOTICE: AddressDropIgnored Found NOTICE: AddressScan ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1545) SSH connection not recording entire flow correctly
[ https://bro-tracker.atlassian.net/browse/BIT-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=24800#comment-24800 ] Vern Paxson commented on BIT-1545: -- I'm definitely a fan of at least adding transparency that the value has not been properly tracked! It would also be good to understand in what shunting situations one can still afford to track such values; and I would hope that even if there's full (blind) shunting, the FIN/RSTs that terminate the connection are still captured, so one can make a guess based on sequence numbers. (Likewise, we'd want this annotated as a guess and not a directly measured value.) > SSH connection not recording entire flow correctly > -- > > Key: BIT-1545 > URL: https://bro-tracker.atlassian.net/browse/BIT-1545 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro >Affects Versions: git/master, 2.4 > Environment: Ubuntu 14.04 LTS, myricom 10g capture card >Reporter: Jason Carr >Assignee: Johanna Amann > Labels: logging > Fix For: 2.5 > > Attachments: ssh-port22.pcap > > > Making a connection out to a server via ssh does not write to conn.log while > running with broctl but it does log to weird.log and ssh.log but nothing to > conn.log. > While running bro -C -r ssh-port22.pcap, a partial log entry is listed with > an incorrect and very low number of packets and bytes. > It was determined that disabling the SSH analyzer gets the correct conn.log > output. > Analyzer::disable_analyzer(Analyzer::ANALYZER_SSH); > Testing on try.bro.org, 2.4+ and master has this problem but 2.3 and below it > works as expected. > Attached is the SSH connection outbound pcap. -- 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-1535) conn.log conn_state field or documentation is wrong
[
https://bro-tracker.atlassian.net/browse/BIT-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vern Paxson reassigned BIT-1535:
Assignee: Vern Paxson
> conn.log conn_state field or documentation is wrong
> ---
>
> Key: BIT-1535
> URL: https://bro-tracker.atlassian.net/browse/BIT-1535
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
>Affects Versions: 2.4
>Reporter: Justin Azoff
>Assignee: Vern Paxson
>
> There is an issue where the conn.log conn_state field will contain RSTR,
> which according to the documentation means "Established, responder aborted."
> The problem that I notice is that I see log entries where conn_state is RSTR,
> but conn_history does not contain an 'h'. Additionally, the resp_h is
> absolutely not running a service on resp_p and the orig_h is usually in the
> process of a tcp scan.
> Here are the top frequencies of RSTR without an h over about a weeks worth of
> conn logs:
> {code}
> 38193 RSTR Fr
> 3662 RSTR DFr
> 1801 RSTR DFdrR
> 1248 RSTR DRr
> 432 RSTRDrF
> 232 RSTRFar
> 128 RSTRDdAFrR
> 79 RSTR DFadrR
> 64 RSTR DrR
> 58 RSTR DdAFarR
> {code}
> Compared to histories that did contain an h:
> {code}
> 425398 RSTR ShADadFr
> 204149 RSTR ShADadFrR
> 156303 RSTR ShADdFar
> 141795 RSTR ShADadFRRr
> 105704 RSTR ShADadfr
> 79697 RSTR ShADadr
> 63493 RSTR ShADaFr
> 51704 RSTR ShADadF
> 42075 RSTR ShADdar
> 37678 RSTR ShADadfRr
> {code}
> I don't have a pcap for this, but I believe many of the weird connections are
> related to scans or backscatter.
> I'm not sure if the code is wrong or the documentation is wrong, but I don't
> see how a fin+reset connection could be classified as established.
> Also, One thing that would be a nice documentation addition is the answer to
> this question:
> Given a conn.log entry, how do determine if there was a connection
> established? I thought it would be if the state was in 'SF S1 S2 S3 RSTO
> RSTR', but RSTR is problematic...
--
This message was sent by Atlassian JIRA
(v7.1.0-OD-06-005#71002)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1535) conn.log conn_state field or documentation is wrong
[
https://bro-tracker.atlassian.net/browse/BIT-1535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=24102#comment-24102
]
Vern Paxson edited comment on BIT-1535 at 2/10/16 3:03 PM:
---
Yeah, historically "RSTR" was defined as established-but-responder-aborted, but
that dates way back to a time when "surely" every connection began with a
handshake, and RSTR was the observation that that connection ended with a RST
sent by the responder. I think the right fix for this ticket is to correct the
documentation to state that it simply means that the entity that Bro
determined/inferred was the responder sent a RST.
was (Author: vern):
Yeah, historically "RSTR" was defined as established-but-responder-aborted, but
that dates way back to a time when "surely" ever connection began with a
handshake, and RSTR was the observation that that connection ended with a RST
sent by the responder. I think the right fix for this ticket is to correct the
documentation that it simply means that the entity that Bro determined/inferred
was the responder sent a RST.
> conn.log conn_state field or documentation is wrong
> ---
>
> Key: BIT-1535
> URL: https://bro-tracker.atlassian.net/browse/BIT-1535
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
>Affects Versions: 2.4
>Reporter: Justin Azoff
>Assignee: Vern Paxson
>
> There is an issue where the conn.log conn_state field will contain RSTR,
> which according to the documentation means "Established, responder aborted."
> The problem that I notice is that I see log entries where conn_state is RSTR,
> but conn_history does not contain an 'h'. Additionally, the resp_h is
> absolutely not running a service on resp_p and the orig_h is usually in the
> process of a tcp scan.
> Here are the top frequencies of RSTR without an h over about a weeks worth of
> conn logs:
> {code}
> 38193 RSTR Fr
> 3662 RSTR DFr
> 1801 RSTR DFdrR
> 1248 RSTR DRr
> 432 RSTRDrF
> 232 RSTRFar
> 128 RSTRDdAFrR
> 79 RSTR DFadrR
> 64 RSTR DrR
> 58 RSTR DdAFarR
> {code}
> Compared to histories that did contain an h:
> {code}
> 425398 RSTR ShADadFr
> 204149 RSTR ShADadFrR
> 156303 RSTR ShADdFar
> 141795 RSTR ShADadFRRr
> 105704 RSTR ShADadfr
> 79697 RSTR ShADadr
> 63493 RSTR ShADaFr
> 51704 RSTR ShADadF
> 42075 RSTR ShADdar
> 37678 RSTR ShADadfRr
> {code}
> I don't have a pcap for this, but I believe many of the weird connections are
> related to scans or backscatter.
> I'm not sure if the code is wrong or the documentation is wrong, but I don't
> see how a fin+reset connection could be classified as established.
> Also, One thing that would be a nice documentation addition is the answer to
> this question:
> Given a conn.log entry, how do determine if there was a connection
> established? I thought it would be if the state was in 'SF S1 S2 S3 RSTO
> RSTR', but RSTR is problematic...
--
This message was sent by Atlassian JIRA
(v7.1.0-OD-06-005#71002)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Error: Analyzer:: defined more than once.
> I tried recently to add an analyzer of RLogin protocol by using BinPac. Bro already has an Rlogin analyzer in src/analyzer/protocol/login/ , so presumably you're conflicting with that one ... ? Vern ___ 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
> ... (and if so, maybe there are some optimizations to > short-cut common cases or so) (... and/or: a few key BiFs to add that don't bite off the whole task but accelerate some particular processing) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] current_time() vs network_time()
For the script you sent me, the 1-second skips aren't that surprising. Bro's "schedule" sets a minimum time in the future for when the event will occur. The actual time will be a tad later, depending on how long it takes the event engine to process the buffer of packets that leads to the clock advancing past the scheduled time. So for example if at network time 1.95 you schedule an event for one second in the future, that won't be looked at until a set of packets arrives for which one of them has a network time of >= 2.95. Those packets will first be processed before doing the scheduled event. In addition, network-time will lag current-time by an amount proportional to the packet capture buffer. If the buffer is a few hundred msec's worth, then you will not infrequently get a mismatch regarding times of one-second granularity. OTOH, this: > Report time is 1447869607.383869, report hour is 10:0:7 > Report time is 1447869617.52706, report hour is 10:0:17 <- big jump is definitely not good. I'm not seeing how your script could lead to that behavior other than the event engine going away (= spending time processing packets) for around 10 seconds. Regarding this: > Report time is 1447869618.188414, report hour is 10:0:18 > Report time is 1447869619.04252, report hour is 10:0:19 <- stall ? > Report time is 1447869619.733979, report hour is 10:0:19 <--- stall ? I can at least construct a theory. Suppose the event was supposed to happen at 10:0:18.8. A packet comes in with that network time, so the event fires, but only 200 msec later, so current-time shows 10:0:19. The script schedules based on network-time rather than current-time, so it'll set the next event for 10:0:19.8. When that packet arrives, there's less to process, so the script runs before the current-time advances to 10:0:20. In any case, I agree that Craig's proposed fix is a good way to deal with this. In addtion, I think this points up the utility of Bro providing cron-style event scheduling in addition to relative-time scheduling. Vern ___ 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
[ https://bro-tracker.atlassian.net/browse/BIT-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=22900#comment-22900 ] Vern Paxson commented on BIT-1506: -- @Vlad: _au contraire_. Maybe no one runs Bro on OS X for live traffic, but certainly there are those of us who routinely use it offline under OS X both for development and to munch on traces. > 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-903) -b turns off -f
[
https://bro-tracker.atlassian.net/browse/BIT-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=22626#comment-22626
]
Vern Paxson commented on BIT-903:
-
FYI it's annoying to be told that my report is a "duplicate" of *one filed 3
years later*
> -b turns off -f
> ---
>
> Key: BIT-903
> URL: https://bro-tracker.atlassian.net/browse/BIT-903
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
>Affects Versions: git/master
>Reporter: Vern Paxson
> Fix For: 2.5
>
> Attachments: signature.asc, single-tcp-conn-est.trace
>
>
> Running with \-b (bare bones) disables processing by \-f. Boy did this take
> me a long time to figure out :-(.
> Reproduce using the appended trace. Invoking with *-e 'event
> connection_established(c:connection) \{ print "yep"; }*' will print "yep".
> Invoking with that plus *-f 'not tcp*' won't print anything. But invoking
> with *-f 'not tcp' \-b* _does_ print "yep".
--
This message was sent by Atlassian JIRA
(v7.0.0-OD-08-002#70107)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-903) -b turns off -f
[
https://bro-tracker.atlassian.net/browse/BIT-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=22628#comment-22628
]
Vern Paxson commented on BIT-903:
-
Got it. The phrase then to use would be "Superseded by BIT-1407"
> -b turns off -f
> ---
>
> Key: BIT-903
> URL: https://bro-tracker.atlassian.net/browse/BIT-903
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
>Affects Versions: git/master
>Reporter: Vern Paxson
> Fix For: 2.5
>
> Attachments: signature.asc, single-tcp-conn-est.trace
>
>
> Running with \-b (bare bones) disables processing by \-f. Boy did this take
> me a long time to figure out :-(.
> Reproduce using the appended trace. Invoking with *-e 'event
> connection_established(c:connection) \{ print "yep"; }*' will print "yep".
> Invoking with that plus *-f 'not tcp*' won't print anything. But invoking
> with *-f 'not tcp' \-b* _does_ print "yep".
--
This message was sent by Atlassian JIRA
(v7.0.0-OD-08-002#70107)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1411) SQL_Injection_Victim is a misleading name
[
https://bro-tracker.atlassian.net/browse/BIT-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=22013#comment-22013
]
Vern Paxson commented on BIT-1411:
--
I fully agree with the rationale behind splitting it - just want the name to
not imply that the attack has been successful. So changing Victim to Target
should do the trick.
(Also, FWIW, our paper on detecting distributed SSH bruteforcing
[http://www.icir.org/vern/papers/dist-ssh-det.ccs13.pdf] might be useful fodder
for thinking about the general problem of detecting attacks distributed across
a bunch of sources.)
> SQL_Injection_Victim is a misleading name
> -
>
> Key: BIT-1411
> URL: https://bro-tracker.atlassian.net/browse/BIT-1411
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Reporter: Vern Paxson
>
> I suggest changing the name of this notice to {{SQL_Injection_Target}}.
> Having "victim" in the name implies to me that the attack succeeded, which is
> not what the associated logic is about.
> Indeed, I even wonder if this notice is useful. The information should be
> directly available from {{SQL_Injection_Attacker}} notices (though it doesn't
> appear to be currently set up to provide this - why not?).
--
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-1411) SQL_Injection_Victim is a misleading name
[
https://bro-tracker.atlassian.net/browse/BIT-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=21972#comment-21972
]
Vern Paxson commented on BIT-1411:
--
@Matthias: perhaps. That works for values/types that can have attributes
associated with them, but not for things like language features. Maybe that's
the common enough case that we should go this route. I'm thinking then the
syntax might be something like =expr, where evaluates to a string
displayed at compile time (though perhaps only if a show-me-deprecation flag is
used). The string could include information (or a link to a discussion) on how
to migrate.
> SQL_Injection_Victim is a misleading name
> -
>
> Key: BIT-1411
> URL: https://bro-tracker.atlassian.net/browse/BIT-1411
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Reporter: Vern Paxson
>
> I suggest changing the name of this notice to {{SQL_Injection_Target}}.
> Having "victim" in the name implies to me that the attack succeeded, which is
> not what the associated logic is about.
> Indeed, I even wonder if this notice is useful. The information should be
> directly available from {{SQL_Injection_Attacker}} notices (though it doesn't
> appear to be currently set up to provide this - why not?).
--
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
Re: [Bro-Dev] Pattern matching for the Bro language
I want to propose introducing pattern matching for the Bro language.
Per our discussion yesterday, I like this notion in general. (Seems we
need a better term for it, though, as pattern matching is very generic -
plus will confuse some people who'll think it refers to NIDS rules rather
than generic type safety!)
Some languages (Ruby comes to mind) design switch as an expression,
which would allow constructs like:
local result = switch( x )
{
case T:
case U:
};
Personally, this strike me as a tad weird, since now result might not
have a statically determined type, so we're back to it being any.
So I'd want to wait on going this far until we have use cases where
it clearly would help with code clarity.
Vern
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] NTOP DPD
http://www.ntop.org/products/deep-packet-inspection/ndpi/ just came on my radar. Do folks already know about it? Has anyone assessed what they've put together and whether any of it is leverageable for Bro in a useful way? Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1431) Loss of information due to analyzer capitalization changes
[ https://bro-tracker.atlassian.net/browse/BIT-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=21200#comment-21200 ] Vern Paxson commented on BIT-1431: -- This can break in a nasty way. The original reason for making the casing uniform was (1) semantically, it shouldn't matter, but (2) without doing so, it's easy to have analysis holes like *if ( domain == badguy.com ) ... * then an attacker can just send badGuy.com and the test will fail. The same holds for grep'ing through log files and missing stuff just due to casing mismatches. What's the scenario where you're concerned about the lost casing information? If it's compelling, then I'd want to consider an interface that provides both the name (which in fact is downcased) and the raw_name (say) which has the original casing. Loss of information due to analyzer capitalization changes -- Key: BIT-1431 URL: https://bro-tracker.atlassian.net/browse/BIT-1431 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.5 Reporter: Seth Hall Currently some of Bro's analyzers are changing the case of data before passing it along to events which is fairly dramatic loss of information in some cases. The two known examples right now are the query in DNS (lowercased) and the header field name in HTTP (uppercased). The question is if we should brute force change these to stop modifying the original values and have people fix any scripts that it breaks (watching for header value names is the biggie here) or if we should use some alternate mechanism to allow the existing behavior to have a sundown time period. I say we should just break it since the quantity of existing scripts in the world is still fairly small and the number of scripts that it affects is even less (many scripts won't be affected at all). -- This message was sent by Atlassian JIRA (v6.5-OD-08-001#65007) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1427) rare SSH successful login heuristic FPs
[ https://bro-tracker.atlassian.net/browse/BIT-1427?focusedWorklogId=10100page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-10100 ] Vern Paxson logged work on BIT-1427: Author: Vern Paxson Created on: 21/Jun/15 11:19 AM Start Date: 21/Jun/15 11:19 AM Worklog Time Spent: 5 minutes Work Description: Already presumed fixed in 2.4. Issue Time Tracking --- Worklog Id: (was: 10100) Time Spent: 5 minutes Remaining Estimate: 0 minutes rare SSH successful login heuristic FPs --- Key: BIT-1427 URL: https://bro-tracker.atlassian.net/browse/BIT-1427 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.3 Reporter: Vern Paxson Fix For: 2.4 Time Spent: 5 minutes Remaining Estimate: 0 minutes During a bruteforce attack that made 27M attempted logins, 2 were flagged as successful by one instance of Bro monitoring the traffic, but not by another running an identical config on the same traffic stream. I wasn't able to reproduce the FPs from bulk traces of the event. Both instances were associated with two Weirds, SYN_after_close and excessive_data_without_further_acks that were otherwise quite rare in the traffic. This suggests that there's a flaw in the heuristic whereby it's analyzing traffic streams that have confused state. Perhaps an adequate fix is to track whether a given flow has experienced those Weirds, and if so, don't apply the heuristic to it. -- 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-1427) rare SSH successful login heuristic FPs
[ https://bro-tracker.atlassian.net/browse/BIT-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vern Paxson updated BIT-1427: - Resolution: Fixed Fix Version/s: 2.4 Status: Closed (was: Open) Already presumed fixed in 2.4. rare SSH successful login heuristic FPs --- Key: BIT-1427 URL: https://bro-tracker.atlassian.net/browse/BIT-1427 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.3 Reporter: Vern Paxson Fix For: 2.4 During a bruteforce attack that made 27M attempted logins, 2 were flagged as successful by one instance of Bro monitoring the traffic, but not by another running an identical config on the same traffic stream. I wasn't able to reproduce the FPs from bulk traces of the event. Both instances were associated with two Weirds, SYN_after_close and excessive_data_without_further_acks that were otherwise quite rare in the traffic. This suggests that there's a flaw in the heuristic whereby it's analyzing traffic streams that have confused state. Perhaps an adequate fix is to track whether a given flow has experienced those Weirds, and if so, don't apply the heuristic to it. -- 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-1427) rare SSH successful login heuristic FPs
[ https://bro-tracker.atlassian.net/browse/BIT-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=21006#comment-21006 ] Vern Paxson commented on BIT-1427: -- Thanks, Vlad. I'll close this. Once we upgrade to 2.4, surely the Internet will provide another opportunity to test this :-P. rare SSH successful login heuristic FPs --- Key: BIT-1427 URL: https://bro-tracker.atlassian.net/browse/BIT-1427 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.3 Reporter: Vern Paxson During a bruteforce attack that made 27M attempted logins, 2 were flagged as successful by one instance of Bro monitoring the traffic, but not by another running an identical config on the same traffic stream. I wasn't able to reproduce the FPs from bulk traces of the event. Both instances were associated with two Weirds, SYN_after_close and excessive_data_without_further_acks that were otherwise quite rare in the traffic. This suggests that there's a flaw in the heuristic whereby it's analyzing traffic streams that have confused state. Perhaps an adequate fix is to track whether a given flow has experienced those Weirds, and if so, don't apply the heuristic to it. -- 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-1428) Customizable email subject lines
Vern Paxson created BIT-1428: Summary: Customizable email subject lines Key: BIT-1428 URL: https://bro-tracker.atlassian.net/browse/BIT-1428 Project: Bro Issue Tracker Issue Type: New Feature Components: Bro Reporter: Vern Paxson There should be a hook of some sort to allow customizing email Subject lines. In particular, I want emails sent for alarm summaries to include the hostname of the Bro that's sending them (since at ICSI we run two concurrent Bros). Looking at *pp_send* in *base/frameworks/notice/actions/pp-alarms.bro* I don't see any way to do this currently. -- 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-1418) SSH::Login_By_Password_Guesser is not implemented
Vern Paxson created BIT-1418: Summary: SSH::Login_By_Password_Guesser is not implemented Key: BIT-1418 URL: https://bro-tracker.atlassian.net/browse/BIT-1418 Project: Bro Issue Tracker Issue Type: New Feature Components: Bro Reporter: Vern Paxson While that tag for this notice is defined, it's commented as not implemented. Seth indicated this is because it requires drawing upon distributed information, which doesn't have an apt framework yet. But this is precisely the sort of good-value, non-trivial-behavior notice that Bro should support. Presumably this can be done without requiring extensive inter-cluster-node communication. -- 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-1417) FTP_UnexpectedConn notice has gone away
Vern Paxson created BIT-1417: Summary: FTP_UnexpectedConn notice has gone away Key: BIT-1417 URL: https://bro-tracker.atlassian.net/browse/BIT-1417 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Vern Paxson This notice went away during The Great Policy Script Rewrite. It would be good to reintroduce, even though it's not so straightforward to do so given it requires cross-connection analysis. -- 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-1419) HTTPProxyFound notice has gone away
Vern Paxson created BIT-1419: Summary: HTTPProxyFound notice has gone away Key: BIT-1419 URL: https://bro-tracker.atlassian.net/browse/BIT-1419 Project: Bro Issue Tracker Issue Type: New Feature Components: Bro Reporter: Vern Paxson This one also went away during The Great Policy Script Rewrite, but unlike FTP_UnexpectedConn really ought to be pretty straightforward to support again. -- 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-1407) -f silently fails if base/frameworks/packet-filter isn't loaded
[ https://bro-tracker.atlassian.net/browse/BIT-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20903#comment-20903 ] Vern Paxson commented on BIT-1407: -- While there's an appeal to processing arguments in script-land, because some arguments control basic script processing (e.g., -p), I'm not sure this can be done in a coherent fashion without some significant under-the-hood kludges. Regarding replacing -f with PacketFilter::filter=, yuck - I wouldn't want to have to remember that, and there's no ready way for a user to discover this. I'd be happy settling for -f warning (or exiting) with a statement that without the packet filtering framework loaded, it's a no-op. Though I have a forboding that you're going to tell me that that's actually hard to implement :-P. -f silently fails if base/frameworks/packet-filter isn't loaded --- Key: BIT-1407 URL: https://bro-tracker.atlassian.net/browse/BIT-1407 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Vern Paxson Attachments: signature.asc I know we've been through this before (though searching the tickets in Jira, I couldn't find the thread). But to revisit: the -f filter option silently does nothing if base/frameworks/packet-filter isn't loaded (so the scenario here is using -b to suppress its automatic loading). This can lead to seriously confusing behavior. It would be preferable if there's either an error message indicating that the option won't be supported, or if it forced loading of packet-filter. -- 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-1409) DNS ZoneTransfer notice missing
Vern Paxson created BIT-1409: Summary: DNS ZoneTransfer notice missing Key: BIT-1409 URL: https://bro-tracker.atlassian.net/browse/BIT-1409 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Vern Paxson Assignee: Seth Hall The DNS analyzer used to generate a ZoneTransfer notice that can be handy for some operational settings. This fell by the wayside, apparently (per Seth) for no particular reason, so would be nice to restore it. -- 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-1407) -f silently fails if base/frameworks/packet-filter isn't loaded
[ https://bro-tracker.atlassian.net/browse/BIT-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20904#comment-20904 ] Vern Paxson commented on BIT-1407: -- Also, regarding the policy script adding the -f flag: how would the user discover that that's what they need to do (have the policy script loaded) to get the flag? I can see quite a bit of perplexment if Bro just tells the user that the flag doesn't exist without explaining why, if they don't have the script loaded. -f silently fails if base/frameworks/packet-filter isn't loaded --- Key: BIT-1407 URL: https://bro-tracker.atlassian.net/browse/BIT-1407 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Vern Paxson Attachments: signature.asc I know we've been through this before (though searching the tickets in Jira, I couldn't find the thread). But to revisit: the -f filter option silently does nothing if base/frameworks/packet-filter isn't loaded (so the scenario here is using -b to suppress its automatic loading). This can lead to seriously confusing behavior. It would be preferable if there's either an error message indicating that the option won't be supported, or if it forced loading of packet-filter. -- 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-1411) SQL_Injection_Victim is a misleading name
Vern Paxson created BIT-1411:
Summary: SQL_Injection_Victim is a misleading name
Key: BIT-1411
URL: https://bro-tracker.atlassian.net/browse/BIT-1411
Project: Bro Issue Tracker
Issue Type: Problem
Components: Bro
Reporter: Vern Paxson
I suggest changing the name of this notice to {{SQL_Injection_Target}}. Having
victim in the name implies to me that the attack succeeded, which is not what
the associated logic is about.
Indeed, I even wonder if this notice is useful. The information should be
directly available from {{SQL_Injection_Attacker}} notices (though it doesn't
appear to be currently set up to provide this - why not?).
--
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?
Vern Paxson created BIT-1412: Summary: 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?
[ https://bro-tracker.atlassian.net/browse/BIT-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20909#comment-20909 ] Vern Paxson commented on BIT-1412: -- Yes I see those but those aren't the shortcuts enabled for Description/Comment. For example, if right now I try to use ctrl-B to back up, instead I get *bold*, which isn't even mentioned on that menu. 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-1405) Notice framework documentation glitch
Vern Paxson created BIT-1405: Summary: Notice framework documentation glitch Key: BIT-1405 URL: https://bro-tracker.atlassian.net/browse/BIT-1405 Project: Bro Issue Tracker Issue Type: Problem Components: Documentation Reporter: Vern Paxson Priority: Low The [Notice documentation|https://www.bro.org/sphinx/frameworks/notice.html] includes the phrase _Users should directly make modifications to the Notice::Info record given as the argument to the hook_. Presumably this is instead should *not* directly make ... -- This message was sent by Atlassian JIRA (v6.5-OD-04-052#65000) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1406) Trouble locating -b documentation
Vern Paxson created BIT-1406: Summary: Trouble locating -b documentation Key: BIT-1406 URL: https://bro-tracker.atlassian.net/browse/BIT-1406 Project: Bro Issue Tracker Issue Type: Problem Components: Documentation Reporter: Vern Paxson I'm trying to locate the documentation for -b (run Bro in bare mode) but the paths I'd expect to work aren't. I don't see it or command line arguments (or flags) in the general index at [https://www.bro.org/sphinx/genindex.html], and at [https://www.bro.org/sphinx/search.html] a search on -b doesn't turn up anything. While the using Bro from the command-line section mentions the flag, it doesn't link to any documentation for it. -- This message was sent by Atlassian JIRA (v6.5-OD-04-052#65000) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1407) -f silently fails if base/frameworks/packet-filter isn't loaded
Vern Paxson created BIT-1407: Summary: -f silently fails if base/frameworks/packet-filter isn't loaded Key: BIT-1407 URL: https://bro-tracker.atlassian.net/browse/BIT-1407 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Vern Paxson I know we've been through this before (though searching the tickets in Jira, I couldn't find the thread). But to revisit: the -f filter option silently does nothing if base/frameworks/packet-filter isn't loaded (so the scenario here is using -b to suppress its automatic loading). This can lead to seriously confusing behavior. It would be preferable if there's either an error message indicating that the option won't be supported, or if it forced loading of packet-filter. -- This message was sent by Atlassian JIRA (v6.5-OD-04-052#65000) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1405) Notice framework documentation confusion
[ https://bro-tracker.atlassian.net/browse/BIT-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vern Paxson updated BIT-1405: - Description: The [Notice documentation|https://www.bro.org/sphinx/frameworks/notice.html] includes the phrase _Users should directly make modifications to the Notice::Info record given as the argument to the hook_. Initially I read this with a presumption that it was a typo and what was meant was instead should *not* directly make Then when I got to the example I see that it actually does mean go-ahead-and-modify, though presumably it only makes sense to modify some fields (such as $actions) and not others (context provided by the Info record). So this phrasing should be clarified, maybe along the lines of Users alter notice processing by directly modifying certain fields in the Notice::Info record given as the argument (was: The [Notice documentation|https://www.bro.org/sphinx/frameworks/notice.html] includes the phrase _Users should directly make modifications to the Notice::Info record given as the argument to the hook_. Presumably this is inste! ad should *not* directly make ...) Summary: Notice framework documentation confusion (was: Notice framework documentation glitch) Notice framework documentation confusion Key: BIT-1405 URL: https://bro-tracker.atlassian.net/browse/BIT-1405 Project: Bro Issue Tracker Issue Type: Problem Components: Documentation Reporter: Vern Paxson Priority: Low The [Notice documentation|https://www.bro.org/sphinx/frameworks/notice.html] includes the phrase _Users should directly make modifications to the Notice::Info record given as the argument to the hook_. Initially I read this with a presumption that it was a typo and what was meant was instead should *not* directly make Then when I got to the example I see that it actually does mean go-ahead-and-modify, though presumably it only makes sense to modify some fields (such as $actions) and not others (context provided by the Info record). So this phrasing should be clarified, maybe along the lines of Users alter notice processing by directly modifying certain fields in the Notice::Info record given as the argument -- This message was sent by Atlassian JIRA (v6.5-OD-04-052#65000) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1397) broctl --help is mysterious
[
https://bro-tracker.atlassian.net/browse/BIT-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20720#comment-20720
]
Vern Paxson commented on BIT-1397:
--
@robin: yeah, I think that's fine. I just want the error message to be clear!
broctl --help is mysterious
---
Key: BIT-1397
URL: https://bro-tracker.atlassian.net/browse/BIT-1397
Project: Bro Issue Tracker
Issue Type: Problem
Components: BroControl
Affects Versions: 2.4
Environment: MacOS Mavericks
Reporter: Vern Paxson
For a newly installed Bro 2.4 beta, issuing {{broctl --help}} yields the
cryptic output:
{{Error: unable to open database file: /usr/local/bro/spool/state.db}}
--
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-1397) broctl --help is mysterious
Vern Paxson created BIT-1397:
Summary: broctl --help is mysterious
Key: BIT-1397
URL: https://bro-tracker.atlassian.net/browse/BIT-1397
Project: Bro Issue Tracker
Issue Type: Problem
Components: BroControl
Affects Versions: 2.4
Environment: MacOS Mavericks
Reporter: Vern Paxson
For a newly installed Bro 2.4 beta, issuing {{broctl --help}} yields the
cryptic output:
{{Error: unable to open database file: /usr/local/bro/spool/state.db}}
--
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-1397) broctl --help is mysterious
[
https://bro-tracker.atlassian.net/browse/BIT-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=20710#comment-20710
]
Vern Paxson commented on BIT-1397:
--
No, I don't have write access. I had expected that ordinary users can run Bro
after it's installed - is that wrong? (In any case, the error message sure is
cryptic!)
I installed from source.
broctl --help is mysterious
---
Key: BIT-1397
URL: https://bro-tracker.atlassian.net/browse/BIT-1397
Project: Bro Issue Tracker
Issue Type: Problem
Components: BroControl
Affects Versions: 2.4
Environment: MacOS Mavericks
Reporter: Vern Paxson
For a newly installed Bro 2.4 beta, issuing {{broctl --help}} yields the
cryptic output:
{{Error: unable to open database file: /usr/local/bro/spool/state.db}}
--
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-1255) TCP reassembly issue
[ https://bro-tracker.atlassian.net/browse/BIT-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=19804#comment-19804 ] Vern Paxson commented on BIT-1255: -- That behavior is to not chew up tons of buffer when asymmetric routing leads to not seeing any acks. *However* I'm finding that modern traffic not infrequently is using much larger initial windows such that indeed there's routinely 4KB of data at the beginning of a flow without any acknowledgments. I think this value needs to be cranked to at least 16KB lest a lot of routine traffic goes unanalyzed. TCP reassembly issue Key: BIT-1255 URL: https://bro-tracker.atlassian.net/browse/BIT-1255 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: git/master, 2.3 Environment: CentOS 6 Reporter: Jimmy Jones Attachments: out.pcap Been testing bro with some messy (but valid) TCP streams, using docker and netem (happy to upload a gist if people are interested). The attached file reassembles correctly in wireshark, but bro only gives the first 4069 bytes when extracted with the file analysis framework, and obviously the wrong hash (md5 is the URI). -- This message was sent by Atlassian JIRA (v6.4-OD-15-055#64014) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Bro + real-time question
For performance concerns, it's not clear that individual packets are the right granularity to examine. For example, if you stop processing one packet you might be giving up on any subsequent analysis for the remainder of its flow, which can have a large amplifying effect (or not) depending on the size of the flow. For a different approach to the problem, see section 5.3 (Dynamically controlling packet load) in the Operational Experiences paper, http://www.icir.org/vern/papers/high-volume-ccs04.pdf . Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Bro + real-time question
I believe it the value of : watchdog_interval Unless things have changed, that instead is a global timer which kills Bro (rather than skipping to the next packet) if that much time has elapsed and it hasn't gotten past the current packet.. The notion is that Bro has become wedged and needs a hard recovery. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1167) Add subnet support to intel framework
[ https://bro-tracker.atlassian.net/browse/BIT-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=15905#comment-15905 ] Vern Paxson commented on BIT-1167: -- I don't know if this is the issue Robin had in mind, but one thing about subnets as table indexes is that they can overlap (two indices, one of which is a superset of the other), introducing ambiguity. Add subnet support to intel framework - Key: BIT-1167 URL: https://bro-tracker.atlassian.net/browse/BIT-1167 Project: Bro Issue Tracker Issue Type: Patch Components: Bro Affects Versions: 2.2 Reporter: Brian Little Priority: Low Labels: intel, subnet Attachments: bro-intel-subnet.patch Here is a patch to add Intel::NET data as a type to search on. This allows adding whole subnets to the intel data rather than just individual addresses. I have also updated the btest. I'm not sure if the lookup is the best way of doing it - currently if loops through each subnet and then checks if the host is part of each. Is it possible to do it in a more efficient way? -- This message was sent by Atlassian JIRA (v6.2-OD-10-004-WN#6253) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1159) type checking inconsistencies
[
https://bro-tracker.atlassian.net/browse/BIT-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=15818#comment-15818
]
Vern Paxson commented on BIT-1159:
--
Runtime as a general style for this sounds fine, but I'd still like to know
whether it works at compile-time like it used to. It's also not clear to me
that at run-time one will always know when it's necessary to look up a name
(for which there may be zillions) on the off chance that it has changed.
type checking inconsistencies
-
Key: BIT-1159
URL: https://bro-tracker.atlassian.net/browse/BIT-1159
Project: Bro Issue Tracker
Issue Type: Problem
Components: Bro
Affects Versions: git/master, 2.2
Reporter: Justin Azoff
Assignee: Jon Siwek
Priority: Low
Labels: language
Attachments: signature.asc, signature.asc
If you try to compare a count to a port directly, you get the following:
{code}
operands must be of the same type (1500/tcp 2000)
{code}
but if you have a record, and mixup the types like so, it silently fails:
{code}
type PortRange: record {
min: port default=1/tcp;
max: port default=65535/tcp;
};
global pr = PortRange($min=1000,$max=2000);
#CORRECT: global pr = PortRange($min=1000/tcp,$max=2000/tcp);
event bro_init()
{
print (pr$min = 1500/tcp 1500/tcp pr$max) ? OK : NOTOK;
}
{code}
{code}
$ bro a.bro
NOTOK
{code}
--
This message was sent by Atlassian JIRA
(v6.2-OD-10-004-WN#6253)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1156) DNS analyzer parses TXT records imcompletely
[ https://bro-tracker.atlassian.net/browse/BIT-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=15726#comment-15726 ] Vern Paxson commented on BIT-1156: -- Does payload of DNS TXT records mean that an individual TXT record can consist of multiple character strings? If so, and if the order is significant/preserved, then set[string] wouldn't be the right type. If instead this is referring to multiple TXT RRs, then likely set[string] is okay (but worth double-checking the RFC regarding the semantics for that case). DNS analyzer parses TXT records imcompletely Key: BIT-1156 URL: https://bro-tracker.atlassian.net/browse/BIT-1156 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Robin Sommer Fix For: 2.3 The payload of DNS TXT records can consist of multiple character strings but the DNS analyzer parses out only the first. We should parse them out all and then probably concatenate into a single string to pass to the event, separated with semicolons or something. I have a trace with an example but it would need anonymization before inclusion into the test suite. -- This message was sent by Atlassian JIRA (v6.2-OD-10-004-WN#6253) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Bare Mode
Yeah, I sometimes find when running on ginormous traces with limited disk space available for (what will be massive) logs that -b really helps. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] doc/install/CHANGES-bro.txt
Is it a bug or a feature in the 2.2 beta that this file stops off in the middle (well, actually near the top) of the 0.9a2 CHANGES items? Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] doc/install/CHANGES-bro.txt
Is it a bug or a feature in the 2.2 beta that this file stops off in the middle (well, actually near the top) of the 0.9a2 CHANGES items? Hmmm, part of the problem is that the top-level CHANGES file has two copies of many changes in it. At line 10466 the changes starting at 2.1-826 repeat. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1045) Review usage of InternalError when parsing network traffic
[ https://bro-tracker.atlassian.net/browse/BIT-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13401#comment-13401 ] Vern Paxson commented on BIT-1045: -- In line with what you frame, the history behind these is that they're meant to reflect should-never-happen situations; not weird activity, but apparent internal inconsistencies in Bro's processing/execution. So they don't really fit with the notion of weird. (Of course it's definitely possible there's some mission-creep and InternalError is misused when Weird really is the right notion.) That said, for sure I agree that we don't want to give adversaries a way to tickle a Bro crash. So ideally the solution here would be to come up with something similar to the weird/notice framework, but that expicitly captures the notion that Bro-is-confused rather than something-happened-on-the-network. Vern Review usage of InternalError when parsing network traffic -- Key: BIT-1045 URL: https://bro-tracker.atlassian.net/browse/BIT-1045 Project: Bro Issue Tracker Issue Type: Task Components: Bro Affects Versions: git/master, 2.1 Reporter: Vlad Grigorescu Creating issue for tracking purposes. Reporter-InternalError denotes a fatal error, and will cause Bro to stop. Calling this function when parsing network traffic creates the possibility for an attacker using a packet of death, which could stop Bro. I suspect that in most cases, a weird should be generated instead, and Bro should just move on to the next packet. A quick grep shows some likely candidates for incorrect use of InternalError: src/Sessions.cc: reporter-InternalError(Bad IP protocol version in DoNextInnerPacket); src/Sessions.cc: reporter-InternalError(fragment block not in dictionary); src/Sessions.cc: reporter-InternalError(fragment block missing); src/Sessions.cc: reporter-InternalError(unknown transport protocol); src/Frag.cc: reporter-InternalError(bad IP version in fragment reassembly); src/IP.cc:reporter-InternalError(IPv6_HdrChain::Init with truncated IP header); src/IP.cc:reporter-InternalError(IPv6_Hdr_Chain bad header %d, type); src/IP.h: reporter-InternalError(bad IP version in IP_Hdr ctor); src/RSH.cc: reporter-InternalError(multiple rsh client names); src/RSH.cc: reporter-InternalError(multiple rsh initial client names); src/POP3.cc: reporter-InternalError(command not known); src/Rlogin.cc:reporter-InternalError(multiple rlogin client names); src/ICMP.cc: reporter-InternalError(unexpected IP proto in ICMP analyzer: %d, src/ICMP.cc: reporter-InternalError(unexpected next protocol in ICMP::DeliverPacket()); src/SMB.cc: reporter-InternalError(command mismatch for ParseTransaction); src/HTTP.cc: reporter-InternalError(unrecognized HTTP message event); src/HTTP.cc: reporter-InternalError(HTTP ParseRequest failed); src/DPM.cc: reporter-InternalError(unknown protocol); src/RPC.cc: reporter-InternalError(RPC underflow); src/RPC.cc: reporter-InternalError(RPC resync: skipping over data failed); src/RPC.cc: reporter-InternalError(inconsistent RPC record marker extraction); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://bro-tracker.atlassian.net/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] viability of stand-alone (not installed) Bro
Try source build/bro-path-dev.sh. Cool, that does it. The only problem is surely I'm going to fail to remember that bit of voodoo, and bug you with similar questions in the future at least three more times :-P. Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Re: [Bro-Dev] Meta-programming
Would this functionality working like I wish it did be difficult? First, as best as I can figure, the current functionality is seriously broken. It's reaching into a interpreter stack frame at the offset associated with x. That just happens to be the offset associated with 'a' during your my_addr()/your_addr() invocations, which is why the output is a doubling of 'a'. Indeed, I've confirmed that if your outer function had an additional argument that comes before 'x', then the my_addr()/your_addr() invocations crash. To fix this, it makes sense that for functions defined inside other functions, there's a clear binding model. The only trick is what that model should be. If it's bind-on-function-creation, then you'd get the semantics you desire. But I suspect there are other uses for such interior funtions where bind-on-application is handy - *providing* of course that the interior function doesn't escape to the exterior like it does in your example. My proposal would be to introduce bind-on-function-creation semantics, and if later we find we sometimes want bind-on-application semantics, introduce that using an attribute. But there's still the would this be difficult question. I suspect it's going to be messy. I'm having a hard time seeing how it doesn't involve a full parse-tree traversal of the interior function's body during creation. (And I leave the problem of the interior function itself having an interior function as an exercise for the reader. :-) Vern ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
