Changed some configuration defaults to potentially more same values.
The callback function is now a hook to allow costomization of the events
that are raised.
Tests now exist. Test baselines are updated.
Logs that got sent sparsely or burstily would get buffered for long
periods of time since the logic to flush them only does so on the next
log write. In the worst case, a subsequent log write could never happen
and cause a log entry to be indefinitely buffered.
This fix introduces a recurring event/timer to simply flush all pending
logs at frequency of Broker::log_batch_interval.
And switch Zeek's base scripts over to using it in place of
"connection_state_remove". The difference between the two is
that "connection_state_remove" is raised for all events while
"successful_connection_remove" excludes TCP connections that were never
established (just SYN packets). There can be performance benefits
to this change for some use-cases.
There's also a new event called ``connection_successful`` and a new
``connection`` record field named "successful" to help indicate this new
property of connections.
These are no longer loaded by default due to the performance impact they
cause simply by being loaded (they have event handlers for commonly
generated events) and they aren't generally useful enough to justify it.
These were caused by earlier code updates.
This commit also removes the ocsp stapling logging script; it was
defunctional and the information provided by it wnever really has been
especially interesting.
This event is the replacement for ssl_application_data, which is removed
in the same commit. It is more generic, containing more information than
ssl_application_dataand is raised for all SSL/TLS messages that are
exchanged before encryption starts.
It is used by Bro internally to determine when a TLS1.3 session has been
completely established. Apart from that, it can be used to, e.g.,
determine the record layer TLS version.
The problem is that with certain compilers, the order of the file hash
events is reversed (for at this moment unknown reasons).
This fix simply removes all MD5 events from the dump-events test, only
leaving the SHA1 events. This removes this condition during the test.
Removed "file_mime_type" and "file_mime_types" event, replacing them
with a new event called "file_metadata_inferred". It has a record
argument of type "inferred_file_metadata", which contains the mime type
information that the earlier events used to supply. The idea here is
that future extensions to the record with new metadata will be less
likely to break user code than the alternatives (adding new events or
new event parameters).
Addresses BIT-1368.
- Re-arrange how some fa_file fields (e.g. source, connection info, mime
type) get updated/set for consistency.
- Add more robust mechanisms for flushing the reassembly buffer.
The goal being to report all gaps and deliveries to file analyzers
regardless of the state of the reassembly buffer at the time it has to
be flushed.
- Change to the default BOF buffer size to 3000 (was 1024).
- Reorganized MS signatures into a separate file
- Improved lots of the signatures and added new ones.
MIME entities buffered data and passed it along to protocol analyzers in
discrete amounts, but a gap is always passed along right away, so the
ordering of these "events" can cause incorrect file analysis. The
change here is to never leave any MIME data buffered -- it should now be
passed along line by line as it is seen, but may still temporarily make
use of a buffer allocated by the analyzer as it works on decoding
content.
Changes:
- Changing semantics of the new_event() meta event: it's raised
only for events that have a handler defined. There are too many
checks in Bro that prevent events wo/ handler from being even
prepared to raise to do that differently.
- Adding test case.
* topic/robin/event-dumper:
New script misc/dump-events.bro, along with core support, that dumps events Bro is raising in an easily readable form.
Prettyfing Describe() for record types.
