Jason Ish [Mon, 25 Nov 2019 22:57:06 +0000 (16:57 -0600)]
detect-engine: check for tx detect flag support
When registing a detection engine, check that the app-layer
protocol supports tx detect flags. Exit with a fatal
error if it does not as this is a code implementation
error that should be resolved during development.
Victor Julien [Sat, 23 Nov 2019 21:25:02 +0000 (22:25 +0100)]
http: split request/response tx id handling
When HTTP pipelining was in use, the transaction id used for events
and files could be off. If the request side was several requests ahead
of the responses, it would use the HtpState::transaction_cnt for events
and files, even though that is only incremented on complete requests.
Split request and response tx id tracking. The response is still handled
by the HtpState::transaction_cnt, but the request side is now handled by
its own logic.
Victor Julien [Fri, 22 Nov 2019 14:33:27 +0000 (15:33 +0100)]
files: simplify pruning logic
Since ebcc4db84ac2c1957a6cc23b5154d7d6333f4cb8 the flow worker runs
file pruning after parsing, detection and loging. This means we can
simplify the pruning logic. If a file is in state >= CLOSED, we can
prune it. Detection and outputs will have had a final chance to
process it.
Remove the calls to the pruning code from Rust. They are no longer
needed.
Victor Julien [Fri, 22 Nov 2019 06:54:04 +0000 (07:54 +0100)]
app-layer: don't consider tx flags if not registered
If a protocol does not support TxDetectFlags, don't try to use them.
The consequence of trying to use them was that a TX would never be
considered done, and it would never be freed. This would lead to excessive
memory use and performance problems due to walking an ever increasing
list.
Victor Julien [Fri, 8 Nov 2019 11:09:24 +0000 (12:09 +0100)]
threading: fix shutdown race condition
A BUG_ON statement would seemingly randomly trigger during the threading
shutdown logic. After a packet thread reached the THV_RUNNING_DONE state,
it would sometimes still receive flow timeout packets which would then
remain unprocessed.
1 main: TmThreadDisableReceiveThreads(); <- stop capturing packets
2 worker: -> TmThreadTimeoutLoop (THV_FLOW_LOOP) phase starts
3 main: FlowForceReassembly(); <- inject packets from flow engine
4 main: TmThreadDisablePacketThreads(); <- then disable packet threads
5 main: -> checks if 'worker' is ready processing packets
6 main: -> sends THV_KILL to worker
7 worker: breaks out of TmThreadTimeoutLoop and changes to THV_RUNNING_DONE.
Part of the problem was with (5) above. When checking if the worker was
already done with its work, TmThreadDisablePacketThreads would not consider
the injected flow timeout packets. The second part of the problem was with (7),
where the worker checked if it was ready with the TmThreadTimeoutLoop in a
thread unsafe way.
As a result TmThreadDisablePacketThreads would not wait long enough for the
worker(s) to finish its work and move the threads to the THV_RUNNING_DONE
phase by issuing the THV_KILL command.
When waiting for packet processing threads to process all in-flight packets,
also consider the 'stream_pq'. This will have received the flow timeout
packets.
Jeff Lucovsky [Sun, 17 Nov 2019 20:09:11 +0000 (15:09 -0500)]
Add general purpose `ARRAY_SIZE` macro
This commit adds `ARRAY_SIZE` as an helper for determining the number of
elements in an initialized array. The calculation is the same but the
macro provides a convenient shortcut. The implementation was borrowed
from the kernel sources.
Victor Julien [Sat, 19 Oct 2019 08:10:28 +0000 (10:10 +0200)]
version: automate and cleanup ver handling
Create a single function to return the version string, to avoid lots
of ifdefs in multiple places.
Make the version determine the 'release' status. If the version from
autoconf has '-dev' in the name, it is not a release. If it hasn't
it is considered a release version.
Victor Julien [Fri, 18 Oct 2019 10:02:03 +0000 (12:02 +0200)]
nfq: clear memory of queue before using it
Avoids using uninitialized memory. Show showed itself
in nonsense values in counters, and in nfq_handle_packet
errors that were likely the result of passing uninitialized
memory to the nfq API.
Bug 3263.
Bug 3120.
Fixes: b2a6c60dee83 ("source-nfq: increase maximum queues number to 65535")
Victor Julien [Fri, 18 Oct 2019 08:49:56 +0000 (10:49 +0200)]
nfq: don't warn on 'handle_packet' error
NFQ can generate warnings/errors with a delay. After Suricata has
succesfully passed a verdict to the kernel, there are still things
that can go wrong for that verdict. This is then passed to the
queue through a netlink error message, which leads to nfq_handle_packet
returning an error code.
Suppress the warning. Also remove the errno/strerror use as
nfq_handle_packet does not set the errno.
Jason Ish [Fri, 11 Oct 2019 17:11:05 +0000 (11:11 -0600)]
suricata-update: don't install if requirements not met
Don't try to run suricata-update if its not installed.
The 'make install-rules' target would try to run suricata-update
when it was detected that it was bundled, but didn't consider
if suricata-update was actually installed.