Victor Julien [Sun, 24 Nov 2019 08:16:46 +0000 (09:16 +0100)]
files: move smtp prune logic to main
Now that we call the file prune loop very regularly, we can move the
SMTP specific inspection pruning logic into this loop. Helps with
cases there we don't (often) update a files inspection trackers.
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.
Jason Ish [Tue, 8 Oct 2019 16:23:08 +0000 (10:23 -0600)]
detect/test: update test for file prune changes
As the file prune is now moved to the flow worker, the file
prune is run later, meaning the first file has not yet
been pruned from the file container list.
Adjust test to look for a second file, and check the
flags on that file.
Eric Leblond [Sat, 30 Nov 2019 17:24:06 +0000 (18:24 +0100)]
qa/coccinelle: flag check for setter and getter
WHen adding something like
/* coccinelle: AppLayerParserStateIssetFlag():4,2:APP_LAYER_PARSER_ */
the coccinelle check will consider that AppLayerParserStateIssetFlag
is taking 4 parameters and that the second one is a flag that needs
to be checked against APP_LAYER_PARSER_.
Eric Leblond [Sat, 30 Nov 2019 16:20:44 +0000 (17:20 +0100)]
qa/coccinelle: fix false positive in setter getter
Coccinelle test was doing a false positive on the function
AppLayerParserStateSetFlag and AppLayerParserStateIssetFlag.
To address that, this patch adds a new coccinelle markup:
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.
Eric Leblond [Sat, 7 Dec 2019 09:43:28 +0000 (10:43 +0100)]
suricata: fix computing of default packet size
Update the default packet size computation to use LiveDeviceName
instead of LiveDevice as the LiveDevice list is not built when
the default packet size is built.
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.
Makefile: Make libhtp available at install-rules stage
So far when "make install-rules" stage was executed, libhtp path was not
recognized as ldconfig does not run by this stage.
Set "LD_LIBRARY_PATH" since we already know the path where libhtp would
be.
Victor Julien [Sat, 28 Sep 2019 08:55:34 +0000 (10:55 +0200)]
enip: fix compile warnings in gcc-8
In file included from suricata-common.h:471,
from app-layer-enip-common.c:27:
app-layer-enip-common.c: In function ‘DecodeCIPRequestPathPDU’:
util-debug.h:222:31: warning: ‘req_path_class8’ may be used uninitialized in this function [-Wmaybe-uninitialized]
int _sc_log_ret = snprintf(_sc_log_msg, SC_LOG_MAX_LOG_MSG_LEN, __VA_ARGS__); \
^~~~~~~~
app-layer-enip-common.c:589:13: note: ‘req_path_class8’ was declared here
uint8_t req_path_class8;
^~~~~~~~~~~~~~~
app-layer-enip-common.c:607:9: warning: ‘segment’ may be used uninitialized in this function [-Wmaybe-uninitialized]
switch (segment)
^~~~~~
app-layer-enip-common.c: In function ‘DecodeCIPResponsePDU’:
app-layer-enip-common.c:773:13: warning: ‘service’ may be used uninitialized in this function [-Wmaybe-uninitialized]
service &= 0x7f; //strip off top bit to get service code. Responses have first bit as 1
^~
app-layer-enip-common.c: In function ‘DecodeCIPRequestPDU’:
app-layer-enip-common.c:503:25: warning: ‘path_size’ may be used uninitialized in this function [-Wmaybe-uninitialized]
offset += path_size * sizeof(uint16_t); //move offset past pathsize
~~~~~~~~~~^~~~~~~~~~~~~~~~~~
app-layer-enip-common.c:506:5: warning: ‘service’ may be used uninitialized in this function [-Wmaybe-uninitialized]
switch (service)
^~~~~~
Jason Ish [Tue, 17 Sep 2019 10:08:15 +0000 (12:08 +0200)]
defrag: check minimum size of reassembled packet
Before re-assembling, check that the first fragment is large
enough to contain the IPv4 or IPv6 header to prevent
an out of bounds read (IPv4) or write (IPv6).
Reported-by: Sirko Höer -- Code Intelligence for DCSO.
Bug #3170.
Jason Ish [Fri, 6 Sep 2019 18:26:06 +0000 (12:26 -0600)]
geoip: add --disable-libgeoip
Add ./configure argument --disable-libgeoip to disable
libgeoip when --enable-geoip is requested. This will allow
libmaxminddb to be picked up instead of libgeoip when
both are installed on the system.
Eric Leblond [Wed, 31 Jul 2019 19:42:43 +0000 (21:42 +0200)]
detect-geoip: restore libgeoip code
Switching to libmaxminddb on a stable release will cause a
dependency to be changed and this may cause issue with some build
systems. Also yaml needs to be updated as geoip is erroring if
no geoip file is defined in the configuration:
Unable to locate a GeoIP2 database filename in YAML conf.
This patch update configure.ac to search for libgeoip then switch
to libmaxminddb if the first one is not found.
Victor Julien [Thu, 22 Aug 2019 09:28:36 +0000 (11:28 +0200)]
detect: fix FP on ICMP unreachable errors
ICMP unreachable errors are linked to the flow they send an error for.
This would lead to the detection engine calling the TX inspection
engines on them.
The stream inspect engine would default to a match for non-UDP
and non-TCP as for ICMP we're not expected to use a TX inspect engine
for stream data.
This all would lead to a false positive match.
This patch fixes this by making sure the TX engines are not called if
the packet protocol and flow protocol are not the same.
Victor Julien [Mon, 27 May 2019 13:46:18 +0000 (15:46 +0200)]
capture: check for flow packets on capture timeout
The capture threads can receive packets from the flow manager in their
Threadvars::stream_pq packet queue. This mechanism makes sure the packets
the flow manager injects into the engine are processed by the correct
worker thread.
If the capture thread(s) would not receive packets for a long time, the
Threadvars::stream_pq would not be checked and processed. This could
lead to packet pool depletion in the flow manager. It would also lead
to flows not being timed out/logged until either packets started flowing
again or until the engine was shut down.
The scenario is more likely to happen in a test (e.g. replay) but could
also delay logging on low traffic sensors.