This allows to enable/disable file analyzers through the same interfaces
as packet and protocol analyzers, specifically Analyzer::disable_analyzer
could be interesting.
This adds machinery to the packet_analysis manager for disabling
and enabling packet analyzers and implements two low-level bifs
to use it.
Extend Analyzer::enable_analyzer() and Analyzer::disable_analyzer()
to transparently work with packet analyzers, too. This also allows
to add packet analyzers to Analyzer::disabled_analyzers.
Add a test parsing a malformed PE file showing that analyzer_violation_info
is raised with the fa_file object set.
It could be interesting to pass through an optional connection if one
exists, but access is provided through f$conns, too.
Introduce two new events for analyzer confirmation and analyzer violation
reporting. The current analyzer_confirmation and analyzer_violation
events assume connection objects and analyzer ids are available which
is not always the case. We're already passing aid=0 for packet analyzers
and there's not currently a way to report violations from file analyzers
using analyzer_violation, for example.
These new events use an extensible Info record approach so that additional
(optional) information can be added later without changing the signature.
It would allow for per analyzer extensions to the info records to pass
analyzer specific info to script land. It's not clear that this would be
a good idea, however.
The previous analyzer_confirmation and analyzer_violation events
continue to exist, but are deprecated and will be removed with Zeek 6.1.
There's a logic error in the packet analyzer's AnalyzerConfirmation()
method that causes analyzer_confirmation() events to be raised for every
packet rather than stopping after the first confirmation which appears to
have been the intention. This affects, for example, VXLAN and Geneve tunnels.
The optional arg_tag parameter was used for short-circuit'ing, but the return
value of GetAnalyzerTag() used for setting the session state causing the
disconnect.
In scenarios where Zeek receives purely tunneled monitoring traffic, this may
result in a non-negligible performance impact.
Somewhat related, ensure the session state is set to violated before
short-circuiting if no analyzer_violations are installed.
Suggesting this as a 5.0.3 candidate.
The current_entity tracking in HTTP assumes that client/server never
send HTTP entities at the same time. The attached pcap (generated
artificially) violates this and triggers:
1663698249.307259 expression error in <...>base/protocols/http/./entities.zeek, line 89: field value missing (HTTP::c$http$current_entity)
For the http-no-crlf test, include weird.log as baseline. Now that weird is
@load'ed from http, it is actually created and seems to make sense
to btest-diff it, too.
...the only known cases where the `-` for `connection$service` was
handled is to skip/ignore these analyzers.
Slight suspicion that join_string_set() should maybe become a bif
now determine_service() runs once for each connection.
Closes#2388
* 'topic/amazingpp/2384-record-deprecation' of github.com:/AmazingPP/zeek:
Replace all the Warning() calls after IsFieldDeprecated() over to Warn()
Fix deprecation not flagged and incorrect line number in record
* origin/topic/vern/cpp-maint-Sep22:
oof more manual fixups
undo inadvertently committed tweak to test
update for btest only run in some environments
btest tweaks for recent changes
updates to notes for compile-to-C++ maintenance
newly-created btest files
baseline updates for -a cpp alternative (compile-to-C++)
tweak btest so it's recognized as a candidate for C++ compilation testing
split basic "int" btests into main part versus now-separate overflow part
fix deprecated "local" scoping in test scripts
annotated scripts to skip when testing compilation-to-C++
C++ script generation fix for lambdas that have identical bodies
fix for C++ scripts that refer to "opaque" types
C++ compilation support for 2-valued vector "for" loops
C++ compilation support for RE /s operator
run-time checking of vector operations for overflows and division-by-zero
error propagation fix to avoid a crash
* origin/topic/awelzel/dpd-analyzer-merger:
analyzer/dpd: Address review comments
Remove @load base/frameworks/dpd from tests
frameworks/dpd: Move to frameworks/analyzer/dpd, load by default
scripts/dce-rpc,ntlm: Do not load base/frameworks/dpd
btest: Remove unnecessary loading of frameworks/dpd
In supervised nodes, the Supervisor's NodeConfig$scripts vector adds scripts to
the end of the user-provided scripts (options.scripts_to_load), so they load
_after_ any user-provided ones. This can cause confusing redef pitfalls when
users expect their customizations to run last, as they normally do.
This adds two members in Supervisor::NodeConfig, `addl_base_scripts` and
`addl_user_scripts`, to store scripts to load before and after the user scripts,
respectively. The latter serves the same purpose as the old `scripts` member,
which is still there but deprecated (in scriptland only). It functions as
before, after any scripts added via `addl_user_scripts`.
* topic/awelzel/cluster-telemetry-defaults:
telemetry: Use dynamic metrics port, remove broker topic mentioning from NEWS entry
telemetry: In a cluster, open port 9911 for Prometheus by default
Ran into this when using to_port(getenv(...)) for an undefined/empty
environment variable. ASAN doesn't like that the slash variable ends
up being access behind the string.
Now that it's loaded in bare mode, no need to load it explicitly.
The main thing that tests were relying on seems to be tracking of
c$service for conn.log baselines. Very few were actually checking
for dpd.log
* Because frameworks/analyzer is loaded via init-frameworks-and-bifs the
dpd functionality (really just dpd.log and disabling of analyzers) is
now enabled even in bare mode.
* Not sure we need to keep frameworks/base/dpd/__load__.zeek around
or can just remove it right away.
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?
Avoid the issue outlined in #2289 where the @if or @else is taken as the
statement of an `if`, `for` or `while` by rejecting such constructs.
Effectively this means the following scripts are now rejected:
# Print's "cond true" with Zeek 5.0 even though the `if ( F )`
# should be in effect.
if ( F )
@if ( T )
print "cond true";
@else
print "cond false";
@endif
or
# Print's "hello" once with Zeek 5.0
local v = vector( 1, 2, 3 );
for ( i in v )
@if ( T )
print("hello")
@endif
To make above work as intended, additional braces can be used.
if ( T )
{
@if ( cond )
print "cond true";
@else
print "cond false";
@endif
}
for ( i in v )
{
@if ( T )
print("hello")
@endif
}
* 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
