getrandom syscall availability is detected at runtime. So it is
possible that the build is done on a box that supports it but
the run is done on a system with no availability. So a workaround
solution is needed to fix this case.
Also we have seen some issue in docker environment where the build
is detecting getrandom but where it does not work at runtime.
For both reasons, the code is updated to have a call to a fallback
function if ever the getrandom call returns that the syscall is
not available.
Fix Coverity issue:
** CID 1435535: Null pointer dereferences (REVERSE_INULL)
/src/output-json-file.c: 212 in JsonBuildFileInfoRecord()
Where we check a variable for being NULL, when all paths to the
code show that it can't be NULL.
XFF configuration is already set in app-layer-htp-xff, and in
output-json-alert. Extending XFF configuration to files and HTTP allow
to get the same behavior as for alerts.
Extend the configuration of filestore json to let filestore metafile
dump be aware of xff. This is available only if write-fileinfo is set
to yes and file-store version is 2.
When a file is transferred over anything other than HTTP, the previously hard-coded HTTP protocol would trigger a non-existent index into htp_list_array_get(), causing a segfault. This patch mimics the logic in detect-lua-extensions.c.
Validate that the content that follows the 'tls_cert_serial' keyword
is on the correct form. If it's longer than two bytes it should be
separated by colons.
Introduces the option 'outputs.pcap-log.compression' which can be set
to 'none' or 'lz4', plus options to set the compression level and to
enable checksums. SCFmemopen is used to make pcap_dump() write to a
buffer which is then compressed using liblz4.
When traffic is becoming null (mainly seen in tests) we reach the
situation where there is timeouts in the poll on the socket and
only that. Existing code is then just looping on the poll and
the result is that the packet iface counters are not updated.
This patch calls the dump counter function to be sure to get
the counter right faster (and not only right at exit).
The stream depth computation was partly done with the stream_config
depth instead of using the value in the TCP session. As a result,
some configuration were resulting in abnormal behavior.
In particular, when stream depth was 0 and the file store depth was
not 0, Suricata was stopping the streaming on the flow as soon as
the filestore was started.
Reported-by: Pascal Delalande <pdl35@free.fr>
There is a difference in the size of the buffer length as passed from
the content buffers (cfr HttpReassembledBody.buffer_len) and the buflen
variable passed to mpm primitives. This can cause a misdetection
whenever the bufferlen is multiple of 65536 (as uint16(X*65536) == 0).
Increasing the buflen variable type to uint32 solves the issue (this
does not cause any issue with primitives, they all accept uint32).
If a file transfer stops on flow timeout, it won't be closed or
truncated. This patch makes sure that in such cases the files
are indeed truncated. This fixes the filestore-v2 output module,
as that requires a sha256 for storing the partial file correctly.
CID 1428797 (#1 of 1): Unchecked return value (CHECKED_RETURN)
check_return: Calling HashTableAdd without checking return value
(as is done elsewhere 5 out of 6 times).
Don't treat 'external' parsers as more experimental. All parsers
depend on crates to some extend, and all have C glue code. So the
distinction doesn't really make sense.
Add a new parser for Internet Key Exchange version (IKEv2), defined in
RFC 7296.
The IKEv2 parser itself is external. The embedded code includes the
parser state and associated variables, the state machine, and the
detection code.
The parser looks the first two messages of a connection, and analyzes
the client and server proposals to check the cryptographic parameters.
https://redmine.openinfosecfoundation.org/issues/2451
When a missing (or empty named) file is passed to source-pcap-file while
using unix socket, the pcap processing thread will incorrectly be stopped,
and no longer available for subsequent files.
As an optimization, reset bidirectional flag for rules with same src and dst.
If one created bidirectional rule like 'alert tcp any any <> any any ...',
the rule was checked twice (for each packet in every direction). This is
suboptimal and may give duplicated alerts. To avoid this, bidirectional
rules are now checked for the same src and dst (addresses and ports) and
if it's the case, the rule is treated as unidirectional and a corresponding
message is logged.
Add Ja3GetString() to return the content of the JA3 string buffer from the
TLS session.
Example:
function init (args)
local needs = {}
needs["protocol"] = "tls"
return needs
end
function setup (args)
filename = SCLogPath() .. "/ja3_string.log"
file = assert(io.open(filename, "a"))
end
function log (args)
ja3_string = Ja3GetString()
if ja3_string == nil then
return
end
file:write(ja3_string .. "\n")
file:flush()
end
function deinit (args)
file:close()
end
Add Ja3GetHash() to return the content of the JA3 hash buffer from the
TLS session.
Example:
function init (args)
local needs = {}
needs["protocol"] = "tls"
return needs
end
function setup (args)
filename = SCLogPath() .. "/ja3_hash.log"
file = assert(io.open(filename, "a"))
end
function log (args)
ja3_hash = Ja3GetHash()
if ja3_hash == nil then
return
end
file:write(ja3_hash .. "\n")
file:flush()
end
function deinit (args)
file:close()
end
In the (useless) example above, each JA3 hash is logged to a log file.
Match on JA3 hash using ja3_hash keyword, e.g:
alert tls any any -> any any (msg:"JA3 hash test";
ja3_hash;
content:"e7eca2baf4458d095b7f45da28c16c34";
sid:1;)
This changes LogQuery and LogAnswer functions
returning a json object instead of writing it in a log file.
In this way it's possible to reuse them to add dns info
into an alert.
The following is an alert record with dns:
{
"timestamp": "2017-07-31T15:01:17.885281+0200",
"event_type": "alert",
"src_ip": "8.8.8.8",
...
"dns": {
"query": [
{
"type": "query",
"id": 25394,
"rrname": "notifications.google.com",
"rrtype": "A",
"tx_id": 0
}
],
"answer": {
"type": "answer",
"id": 25394,
"rcode": "NOERROR",
"answers": [
{
"rrname": "notifications.google.com",
"rrtype": "CNAME",
"ttl": 3599,
"rdata": "plus.l.google.com"
},
{
"rrname": "plus.l.google.com",
"rrtype": "A",
"ttl": 299,
"rdata": "216.58.205.174"
}
]
}
}
}