DTLS now only outputs protocol violations once it saw something that
looked like a DTLS connection (at least a client hello). Before the
danger that it misinterprets something is too high.
It has a configurable number of invalid packets that it can skip over
(because other protocols might be interleaved with the connection) and a
maximum amount of Protocol violations that it outputs because of wrong
packet versions.
This changes many weird names to move non-static content from the
weird name into the "addl" field to help ensure the total number of
weird names is reasonably bounded. Note the net_weird and flow_weird
events do not have an "addl" parameter, so information may no longer
be available in those cases -- to make it available again we'd need
to either (1) define new events that contain such a parameter, or
(2) change net_weird/flow_weird event signature (which is a breaking
change for user-code at the moment).
Also, the generic handling of binpac exceptions for analyzers which
to not otherwise catch and handle them has been changed from a Weird
to a ProtocolViolation.
Finally, a new "file_weird" event has been added for reporting
weirdness found during file analysis.
* 'master' of https://github.com/hosom/zeek:
Normalize the intel seen filename for smb.
load smb-filenames in scripts/policy/frameworks/intel/seen/__load__.bro
Add SMB::IN_FILE_NAME to Intel::Where enum
Support filenamess for SMB files
I added a test case
* 'topic/jgras/intel-filter' of https://github.com/J-Gras/zeek:
Added new intel policy script to policy test.
Added test for intel removal policy script.
Added policy script for intel removal.
Added test for intel item filtering.
Added hook to filter intelligence items.
* 'smb3-negotiate-response' of https://github.com/mauropalumbo75/zeek:
added test and pcap files for smb 3.1.1 negotiate-response
smb3.1.1 additions to negotiate-response command
I made several modifications:
- Code format, style, naming changes
- For completeness/correctness, I added parsing support for the remaining
context type structures.
- Moved the optional padding before the NegotiateContextList field to
also require the 0x0311 dialect version (some failures in
pre-existing unit tests pointed this out as an issue)
* 'smb3-transform-header' of https://github.com/mauropalumbo75/zeek:
clean up, test and pcap for transform_header added
added smb2-com-transform-header for smb3.x
* 'master' of https://github.com/rdenniston/zeek:
Add linux netfilter NFLOG capture functionality initial commit
I made modifications:
- Formatting / code style
- More error handling and validity checks
- The Type and Length value of TLVs is technically host order
- Changed / fixed the Length value padding check: it's generally
32-bit alignment, not just aligning any TLV less than 8 bytes.
This introduces the following redefinable string constants, empty by
default:
- InputAscii::path_prefix
- InputBinary::path_prefix
- Intel::path_prefix
When using ASCII or binary reades in the Input/Intel Framework with an
input stream source that does not have an absolute path, these
constants cause Zeek to prefix the resulting paths accordingly. For
example, in the following the location on disk from which Zeek loads
the input becomes "/path/to/input/whitelist.data":
redef InputAscii::path_prefix = "/path/to/input";
event bro_init()
{
Input::add_table([$source="whitelist.data", ...]);
}
These path prefixes can be absolute or relative. When an input stream
source already uses an absolute path, this path is preserved and the
new variables have no effect (i.e., we do not affect configurations
already using absolute paths).
Since the Intel framework builds upon the Input framework, the first
two paths also affect Intel file locations. If this is undesirable,
the Intel::path_prefix variable allows specifying a separate path:
when its value is absolute, the resulting source seen by the Input
framework is absolute, therefore no further changes to the paths
happen.
Essentially, it will now process/parse priority values if they are
there, or else just accept whatever remaining data/text is there as the
syslog message. Reasoning is that there's syslog producers out there
that may have simply forgotten/neglected to send the priority value
and technically won't conform to what the standard says, though we can
infer the intent (some syslog consumers already may do similarly, but
I didn't verify).
* Better parsing/error-checking of VXLAN and encapsulated packet headers
* Add/implement the "vxlan_packet" event
* Add "Tunnel::vxlan_ports" option to tune the set of VXLAN ports to
analyze/decapsulate
* Add "Tunnel::validate_vxlan_checksums" option to allow for tuning of how
checksums associated with the outer UDP header of a possible VXLAN
tunnel are handled
Fixes GH-250
The result of the |x| operator for interval and time types historically
returned a value of type double. This was changed as part of
3256ac7c49 to return interval/time, but
this now reverts to returning a double again to avoid introducing a
change that may break user code.
Fixes GH-219
The "orig_fuids", "orig_filenames", "orig_mime_types" http.log fields as
well as their "resp" counterparts are now limited to having
"HTTP::max_files_orig" or "HTTP::max_files_resp" entries, which are 15
by default. The limit can also be ignored case-by-case via the
"HTTP::max_files_policy" hook.
Fixes GH-289
This change ignores leading/trailing whitespaces for a couple of
data-types (bool, port, subnet, addr) and just parses them as if the
whitespace was not present.
* 'master' of https://github.com/ZekeMedley/zeek:
lstrip test output cleanup
implemented rstrip
add rstrip tests
cleanup of lstrip function
added implementation of lstrip
added tests for lstrip function
* origin/topic/jsiwek/gh-211:
GH-208: change invalid subnet expressions to a runtime error
GH-211: improve consistency of how scripting errors are handled
Removed the 'allow_init_errors' option.
Scripting errors/mistakes now consistently generate a runtime error
which have the behavior of unwinding the call stack all the way out of
the current event handler.
Before, such errors were not treated consistently and either aborted
the process entirely or emitted a message while continuing to execute
subsequent statements without well-defined behavior (possibly causing
a cascade of errors).
The previous behavior also would only unwind out of the current
function (if within a function body), not out the current event
handler, which is especially problematic for functions that return
a value: the caller is essentially left a mess with no way to deal
with it.
This also changes the behavior of the startup/initialization process
to abort if there's errors during bro_init() rather than continue one
to the main run loop. The `allow_init_errors` option may change this
new, default behavior.
