Hi,
I have a few things I am planning to add to the intel-framework. One of
them is expiration for intelligence items. To achieve per item
expiration in a table there is a little hack that is used in the
notice-framework and in the new netcontrol-framework: By setting
&create_expire=0 and returning the intended timeout for each item in the
corresponding expire_func, one can achieve per item expiration (see e.g.
scripts/base/frameworks/netcontrol/catch-and-release.bro).
This approach however does not work for &read_expire and &write_expire,
because accessing the item resets the expiration timeout based on the
&read/write_expire attribute of the table (in this case 0) instead of
the value that was previously returned by the expire_func. The following
script demonstrates this effect:
https://gist.github.com/J-Gras/061983dac59224a03d3bfad4476a1dd9
The straight-forward solution would be to allow each item to hold its
own expiration timeout. Talking to Seth about this, we came up with two
possible approaches to achieve this:
1) Use the return value of the expire_func to set this value.
2) Use a bif or language feature (e.g. expire 10sec { tbl[idx] }; ) to
set this value.
I would prefer the second approach, as the intention of the expire_func
return value is to provide a delay for a single expiration event. This
would e.g. allow to set an individual expire timeout of e.g. 1 hour for
a single item. Once the expire_func is called one could set a delay of
e.g. 10min. In case the item is accessed, the timeout would be reset to
the originally intended 1 hour instead of 10min.
What are your opinions on that? Which approach would you prefer or do
you think per item expiration is a bad idea in general?
Best regards,
Jan
Malware Utkonos created BIT-1580:
------------------------------------
Summary: Add ipv6 detection to conn.log
Key: BIT-1580
URL: https://bro-tracker.atlassian.net/browse/BIT-1580
Project: Bro Issue Tracker
Issue Type: Patch
Components: Bro
Affects Versions: 2.4
Reporter: Malware Utkonos
This is an additional column added to conn.log to determine if the connection is using ipv6. The address itself makes this clear, but it is much easier to grep for T/F than examining the address.
Pull request with patch:
https://github.com/bro/bro/pull/70
--
This message was sent by Atlassian JIRA
(v1000.5.0#72002)
Johanna Amann created BIT-1579:
----------------------------------
Summary: Please merge topic/johanna/xmpp-starttls
Key: BIT-1579
URL: https://bro-tracker.atlassian.net/browse/BIT-1579
Project: Bro Issue Tracker
Issue Type: New Feature
Components: Bro
Affects Versions: git/master
Reporter: Johanna Amann
Fix For: 2.5
Please merge topic/johanna/xmpp-starttls
This branch adds very basic support for XMPP, just up to the point when SSL encryption starts, when it switches to the SSL analyzer. Similar to the case of IMAP, this allows us to extract certificates from xmpp sessions that are upgraded.
--
This message was sent by Atlassian JIRA
(v1000.5.0#72002)
[ https://bro-tracker.atlassian.net/browse/BIT-1579?page=com.atlassian.jira.p… ]
Johanna Amann updated BIT-1579:
-------------------------------
Status: Merge Request (was: Open)
> Please merge topic/johanna/xmpp-starttls
> -----------------------------------------
>
> Key: BIT-1579
> URL: https://bro-tracker.atlassian.net/browse/BIT-1579
> Project: Bro Issue Tracker
> Issue Type: New Feature
> Components: Bro
> Affects Versions: git/master
> Reporter: Johanna Amann
> Fix For: 2.5
>
>
> Please merge topic/johanna/xmpp-starttls
> This branch adds very basic support for XMPP, just up to the point when SSL encryption starts, when it switches to the SSL analyzer. Similar to the case of IMAP, this allows us to extract certificates from xmpp sessions that are upgraded.
--
This message was sent by Atlassian JIRA
(v1000.5.0#72002)
I just ran the external testsuite for current master on my development
system, and I'm seeing some quite increased execution times:
[ 50%] tests.short ... failed (+3.4%)
[ 75%] tests.medium ... failed (+1.5%)
[ 28%] tests.m57-short ... failed (+4.6%)
[ 71%] tests.ipv6 ... failed (+39.8%)
[ 85%] tests.m57-long ... failed (+9.8%)
The short tests are prone to fluctuate in timing, but the increases
for ipv6 and m57-long are sticking out. Any ideas what could be
causing this?
Robin
--
Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin
[ https://bro-tracker.atlassian.net/browse/BIT-1449?page=com.atlassian.jira.p… ]
Robin Sommer updated BIT-1449:
------------------------------
Resolution: Merged (was: Fixed)
Status: Closed (was: Merge Request)
> Wrap Broker Bifs into script-level functions
> --------------------------------------------
>
> Key: BIT-1449
> URL: https://bro-tracker.atlassian.net/browse/BIT-1449
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: 2.4
> Reporter: Robin Sommer
> Assignee: Robin Sommer
> Fix For: 2.5
>
>
> When working with Broker in Bro, one currently calls its bifs directly. That works just fine, but is a problem for documentation: the bifs are defined outside of the Broker framework, splitting the information across two places.
> We should do here what other framework do: rename the Bifs to have internal-only names ({{__<name>}}) and then provide wrapper functions inside the framework that just forward to those internals ones.
--
This message was sent by Atlassian JIRA
(v1000.5.0#72002)