Closed CptOfEvilMinions closed 4 years ago
hey @CptOfEvilMinions I think we've talked about this indirectly in other places but I haven't responded here. With EQL a .
indicates a nested field, but I think with the bro logs the native fields were named "ip.orig_h" and "id.resp_h", which caused the problems.
This is an interesting scenario, because we currently require all field names to match a-zA-Z][a-zA-Z0-9_]*
https://github.com/endgameinc/eql/blob/aa55970fd57996aed7519a8eda94c3fe472d15c2/eql/etc/eql.ebnf#L231
Since .
already means something in EQL, there are a few ways we could do this:
id\.orig_h
.["id.orig_h"]
.Then your EQL queries would look like one of these
network where id\.orig_h == "192.168.1.1"
network where ["id.orig_h"] == "192.168.1.1"
network where .["id.orig_h"] == "192.168.1.1"
Also since your blog, it should be a lot easier to make your own schema, and EQL will autodetect it from your JSON file if you use the new interactive shell
Any preferences for the syntax?
Resolved by https://github.com/endgameinc/eql/issues/19
I created a custom source file to parse BRO logs. By default BRO has key names containing dots like
id.orig_h
orid.resp_h
. When I do the followingdestination_address = 'id.orig_h'
and run eqllib it ignores this mapping. However, if I manually changeid.orig_h
todest_addr
in the JSON log file and change my source file statement todestination_address = 'dest_addr'
it works.bro-source.toml
bro-domain.toml