While reviewing/understanding the analyzer setup, it didn't seem like
GTPv1 implements packet_analysis::Analyzer::DetectProtocol(), so
should not register it for protocol_detection either.
Alternatively, maybe DetectProtocol() should've been implemented in
which case maybe this should be an issue?
* simeonmiteff/master:
Pull changes from zeek/cmake fork
Skip test based on preprocessor flag set by cmake
Set flag for libpcap without DLT_LINUX_SLL2
Force event order in core/init-error btest
Update some coverage baselines
Update plugins/hooks baseline
Add support for DLT_LINUX_SLL2 PCAP link-type
I ran into wanting to iterate over just the values of a vector and wondering
whether that could just work.
This adds support for the following, where v will be value of vec[i].
local vec = vector("zero", "one", "two");
for ( i, v in vec )
print i, v;
The change to the capture-loss test is actually a fix for a bug exposed by the
code change. Previously it wasn't firing the scheduled event because of a failed
name lookup. Now that the lookup has been fixed, the event happens twice.
* ssh://github.com/fatemabw/zeek:
Update options.zeek
Create out-27
Add files via upload
Update src/packet_analysis/protocol/tcp/TCPSessionAdapter.cc
Updating the weird names to use all lower case
Fixing whitespaces..
Fixing clang pre-commit error
Add check for option 27
Add the parsed fields for TCP option 27
Add TCP options bad length check
I removed `deprecated-txhosts-rxhosts-connuids.zeek` from
`local.zeek`, seems preferable not to have a script-to-go-away in the
standard configuration for new users. Also tweaked `NEWS` just a tiny
bit.
* origin/topic/awelzel/files-log-unrolling:
files.log: Unroll and introduce uid and id fields
This is a script-only change that unrolls File::Info records into
multiple files.log entries if the same file was seen over different
connections by single worker. Consequently, the File::Info record
gets the commonly used uid and id fields added. These fields are
optional for File::Info - a file may be analyzed without relation
to a network connection (e.g by using Input::add_analysis()).
The existing tx_hosts, rx_hosts and conn_uids fields of Files::Info
are not meaningful after this change and removed by default. Therefore,
files.log will have them removed, too.
The tx_hosts, rx_hosts and conn_uids fields can be revived by using the
policy script frameworks/files/deprecated-txhosts-rxhosts-connuids.zeek
included in the distribution. However, with v6.1 this script will be
removed.
* micrictor/master:
Add a field to Modbus/TCP log to indicate the Modbus PDU type
Add modbus transaction and unit ids to logs
Enable modbus logging for requests
* origin/topic/awelzel/1678-disabling-analyzer-hook:
Add NEWS entry and zeekygen-smithing for disabling_analyzer()
Introduce global disabling_analyzer() hook to veto disable_analyzer()
ssl: Only delete c$ssl$analyzer_id when disabling the analyzer was successful
This hook can be used to coordinate disabling an analyzer for a given
connection. The contract is simple: Any script can veto a disable_analyzer()
call by breaking from this hook. The decision is local to the script taking
into account any state attached to the connection object or script specific
state stored elsewhere.
A script breaking from the hook takes over the responsibility to call
disable_analyzer() at a later point when it finds the condition due to which
it vetoed fulfilled (which may be never).
Signature:
disabling_analyzer: hook(c: connection, atype: AllAnalyzers::Tag, aid: count);
Example use-cases are keeping the SSL analyzer enabled for finger-printing
until a certain amount of bytes or packets have been transferred or
similarly the connection duration exceed a certain threshold.
Other example use-cases might be keeping analyzers for SSH, RDP or SSL
enabled for connections from specific subnets.
It's a bit quirky as it makes disable_analyzer() a maybe operation. While log
policy hooks and/or the notice hook have similar semantics, they are not as
stateful. It still seems like a quite powerful primitive.
The disable_analyzer() call in dpd/main.zeek may motivate the addition of a
force flag as a follow-up for situations where the caller "knows better" or
absolutely wants to override.
Closes#1678#1593.
Add new syntax for adding and removing attributes from record fields:
redef RecordType$field_name += { &log };
redef RecordType$field_name -= { &log };
For now this only allowed for the &log attribute as the semantics are clear.
For &default and &optional the semantics aren't obvious and no use-cases have
been identified where those would make sense to change.
This enables a mechanism to add potentially interesting fields to the typical
Info records in base scripts, but letting users opt-into actually including
them into their log. At the same time, users that find specific fields in a
standard log uninteresting can opt-out without using `Log::Filter$exclude`
which can be difficult to use correctly. Patching or forking external packages
to remove columns from a log can also be avoided with this mechanism.
Closes#2000.
* ynadji/topic/yacin/2319-add-change-handler-to-site:
update plugins.hooks baseline
lower priority for change handlers
split update_zones_regex into two functions
GH-2319: Add change handlers to Site