> 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
> 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"
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
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
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.
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
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
> 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
>
> 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
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;
> 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
> 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 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,
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
> > 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)
> 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
> 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
> 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
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
> 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,
> 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;
};
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
> 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
> > (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
> 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
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
> 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
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
> 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.
> Here we will not have cases where some repetitions are logarithmic, and
> some (like for R) are not. I guess that makes sense, but I can see it
> potentially being confusing.
Yeah, I chewed on that too, but I don't see a better solution. The semantics
of repeated R are different, too (per the
> I 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
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
> 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.
> 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
> > 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/ |
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
> 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
> 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
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
> 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
> 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
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
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:
> 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
> 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'.
> 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
[
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
[
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 wr
[
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 "
> 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
> ... (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
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
[
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
[
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 *o
[
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"
[
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
[
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
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
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
___
[
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
[
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
[
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
[
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
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
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
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
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
[
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
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
[
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
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
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
[
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
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
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
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
[
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
[
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
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
[
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
[
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
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
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
[
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
[
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
[
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
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
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
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.
[
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
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
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
92 matches
Mail list logo
