Hello,
I would like to bring your attention to one strange and unexpected problem
I faced
while trying to include user agent parser for bro I have developed (plugin:
https://github.com/vitalyrepin/uap-bro ) into the list of uap
implementations https://github.com/ua-parser
The req
--
WBR & WBW, Vitaly
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 || s2 Set union
s1 && s2 Set 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 += s2 Same as "s1 = s1 + s2"
s1 -= s2 Same 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
We merged the new Broker version into Bro master yesterday. As this a
major change to one of Bro's core components, I wanted to send a quick
heads-up here, along with a couple of notes.
With this merge we are completely replacing usage of Bro's classic
communication system with Broker. All the standard scripts have been
ported over, and BroControl has been adapted as well. The old
communication system remains available for the time being, but is now
deprecated and scheduled to be removed in Bro 2.7 (not 2.6). Broccoli
is now turned off by default.
With such a large change, I'm sure there'll be some more kinks to iron
out still; that's where we need everybody's help. If you have an
environment where you can test drive new Bro versions, please give
this a try. We're interested in any feedback you have, both specific
issues you encounter (best to file tickets) and general experiences
with the new version, including in particular any observations about
performance (best to send to this list).
>From a user's perspective, not much should even be changing, most of
the new stuff is under the hood. The exception are custom scripts
doing communication themselves, they need to be ported over to Broker.
Documentation for that is here:
https://www.bro.org/sphinx-git/frameworks/broker.html, including a
porting guide for existing scripts. Let us know if there's anything
missing there that would be helpful. The Broker library itself comes
with a new user manual as well, we'll get that online shortly.
One specific note on upgrading existing Bro clusters: the meaning of
"proxy" has changed. They still exist, but play a quite different role
now. If you're currently using more than one proxy, we recommend going
back to one; that'll most likely be fine with the standard scripts
(and if not, please let us know!)
Many thanks to Jon Siwek for the recent integration work tying up all
the loose ends and getting Broker mergeable. Also thanks to those who
have tested it already from the actor-system branch.
Robin
--
Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin
Hi,
the main bro server will go down for system upgrades a bit. This should
mostly affect the git server, the webpage should stay accessible.
I will write another email once I am done.
Johanna
There are a couple of cases where I think it'd be useful to have a
bro-devel package -- a package that I can install on a system, and then be
able to build plugins against Bro. (This is the same model as other *-devel
packages, such as openssl, libpcap, etc.)
Right now, if I compile Bro from source, run make install, I can't build a
package with what's in /usr/local -- Bro needs the entire source tree,
since the required headers are not present in /usr/local.
I'm curious how people are dealing with this issue, and if anyone has
thoughts on whether this would be useful, and if so, what it would take to
build such a package.
Thanks,
--Vlad
This has been coming up in various contexts & subgroups of people, and
I wanted to send it out as a proposal to gather some broader feedback:
Do we want to move Bro's git repositories and tickets to GitHub?
Currently we're hosting our Git repositories on our own server at
git.bro.org; from there, we mirror them to GitHub. For issue tracking,
we use JIRA at tracker.bro.org. Much of all this is a legacy setup in
some sense. I believe it would simplify life for both users &
developers if we moved to GitHub as the authoratative place for both
code and tickets.
More specifically, I propose that we:
1. Turn the current git repository mirrors on github.com/bro into
authoritative source for all Bro code. Then we discontinue
git.bro.org. We can set up up some notification system there
instead that points people still using the old URLs to GitHub.
2. Switch to using GitHub as our primary issue tracker. Giving
the large amount of old tickets in JIRA, I think we should
just start from scratch there, porting over just the most
recent pending tickets. We'd keep the JIRA running in
read-only mode so that we don't loose the history and can
always refer back to old tickets.
3. Switch to a mostly PR-based development model (i.e., no more
merge requests tracked separately through tickets), and also
use GitHub for code review & feedback.
4. Make sure it all integrates nicely with Travis CI (which has
already been set up recently).
About the only downside I see is that emailing out our standard commit
notifications won't be quite as smooth anymore: we'd still get them,
but with a bit of delay as some system would need to be polling for
changes, rather than being triggered immediately. Not much of a
problem I think (and with some additional work, we could make them
push-triggered, too; but probably not worth it).
What do people think? Any support, or concerns?
Robin
--
Robin Sommer * ICSI/LBNL * robin(a)icir.org * www.icir.org/robin
Hi there,
I want to write a function as a plugin to convert a 4 byte hex string
like "405f612f" to float/double (3.49031 in this case).
An easy way to do so in C++ is this:
#include<sstream>
union ulf
{
unsigned long ul;
float f;
};
int main()
{
ulf u;
string str ="405f612f";
stringstream ss(str);
ss >> hex >> u.ul;
float f = u.f;
cout << f << endl;
}
Unfortunatly, to use "stringstream" I will have to include the <sstream>
header file. Is this possible to do in plugin functions?
Thanks.
Dane
Maybe I'm jumping the gun a little bit, but I want to start wrapping my
head around the upcoming changes. Let's start by stating my use case... I
wanted to stop the repetitive reverse DNS queries caused by
ssh/interesting-hostnames.bro by rebuilding known-hosts.bro to include the
names, allowing a simple lookup*. I started re-writing the old one and
Justin pointed me towards the 'new' version of known-hosts in the
topic/actor-system branch.
Looking at the new known-hosts.bro..
1) My initial gut feeling was that all of the when() calls for insertion
could get really expensive on a brand new cluster before the store is
populated.
2) Correct me if I'm wrong, but it seems like the check for a host already
being in known_hosts (now host_store) no longer exists. As a result, we
try to re-insert the host, calling when(), every time we see an established
connection with a local host.
Which leads me to...
3) How do I retrieve values from the store to test for existence?
4) Assuming that requires another Broker call inside a when(), does it make
sense to pull the data store into memory at bro_init() and do
a Cluster::publish_hrw?
Thanks,
Dop
* - Yes, on the edges this breaks DNS TTLs, but saves thousands of when()
calls to lookup_addr() and our names don't change very frequently.
The latest version of the new Broker-ized cluster/communication system
for Bro in 'topic/actor-system' branch is wrapping up and, in my
opinion, ready to be merged into Bro's 'master' branch.
However, since it's such a big change, I'd like a last round of feedback
before merging. If you want to test, the build process should now be as
simple as:
$ git clone --recursive --branch=topic/actor-system git://git.bro.org/bro
$ cd bro && ./configure && make
Configuring BroControl is not any different from before.
If you had custom scripts, they may require porting. There's a guide
and examples for that at [1] and [2] (hyperlinks in those docs will
render more nicely when it's up on bro.org).
Though, for this round of testing, I'd be most interested just in any
general stability issues or major feature breakages from a vanilla Bro
installation. Mild performance issues, minor bugs, or other issues w/
porting custom scripts are things I think we can iron out even after
merging into 'master'.
- Jon
[1]
https://github.com/bro/bro/blob/topic/actor-system/doc/frameworks/broker.rst
[2] https://github.com/bro/bro/tree/topic/actor-system/doc/frameworks/broker
Hi there,
as a part of my master's thesis I'm going to write two analyzer which
will be able detect S7Comm and S7CommPlus traffic used by Siemens PLCs.
Both protocols are proprietary, so I have no official documentation. The
goal is to monitor this kind of traffic and/or detect threats against
those PLCs.
So far, I am able to read S7Comm traffic and generate various events,
covering all standard and most of the additional (UserData) functions.
This part is based on the code of Wireshark S7Comm dissector.
The S7CommPlus part is a little bit trickier. Unfortunately, the only
code base I can use is an 4 year old git-repo, probably forked from the
first S7CommPlus dissector written by Thomas Wiens
(https://github.com/moki-ics/s7commwireshark/blob/master/src/s7comm_plus/pac…).
After a quick glance I have discovered 2 "problems", where I hope you
could help me.
1) Reassembling packets: Some S7CommPlus packets which payload is over a
certain amount of bytes will be split and need to be reassembled. I
don't know how to do that in Bro nor how I can keep track of which
fragments belongs to the which packet. (LoC: 3917 to 4135)
2) Various payload: Some packets contain different payload, e.g.
different addressing types, attributes and/or structures, even though
the packet-type is the same (for example: a request packet can contain
one or more objects. In each object, there can be various items of type
A, B, C or D, each of them have a different structure). If I want to
generate a Bro events which contains the payload as a parameter, how do
I do that?
Any help will be appreciated!
Thanks.
Dane
