* '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
Line 76: Replaced ' for ;
Line 120: Replaced ojbects to objects
I tested it on my cloned repo and everything seems to compile without errors (Ubuntu Bionic Beaver) regarding the DNP3 Protocol
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
It now produces numbers as large as is required to match the data it
needs to represent. It's up to the consumer to decide how to
appropriately handle values that may be outside their supported
range/precision.
Fixes GH-282
The contentline analyzer has two code paths that buffer data:
* right at the top of DeliverStream
* later in DoDeliverOnce
However, contentline can be in plain delivery mode, and if so, the
buffer resize in DeliverStream does not need to be done just because
DeliverStream was passed an 8K data chunk.
This was causing contentline to resize it's buffer to fit chunks of HTTP
response data. Additionally, the buffer was sized to be 3/2 of the
chunk, so an 8K chunk would result in a 12K allocation.
