To prep for the removal of the lib runmode, simplify this C++ example
to match our simple example. We don't yet have the C++ compatible
headers to allow for a C++ app to register its own custom runmode.
Debug validation revealed that library ThreadVars were being
created *after* the threads were sealed. And the only way to create
your ThreadVars that fits within the current application life-cycle is
to create them in your own custom run mode.
This is likely a better model for users who are bringing their own
packets and threads anyways, as they are essentially providing their
own capture method, and all capture methods provide their own run
mode. They're also using their own threads, which means adapting to
their own threading model.
This is suitable for a backport to 8.0. But for 9.0 we can go further
and remove the built-in library run mode, which will be done in a
follow-up commit.
Ticket: #8259
Ticket: 7666
The end goal is to remove all dependencies on suricata and just
use suricata_sys or suricata_ffi
For now, make usage of what is already available
Bindgen the Rust bindings to the C JsonBuilder API along with the rest
of the Rust bindings to C. Breaking it out was probably the wrong
idea.
This should make it easier, and more correct to bindgen C functions
that use SCJsonBuilder types.
Instead of enabling signal handlers by default, require the user of
the library to opt-in. This is done with the call to
SCEnableDefaultSignalHandlers, which sets a flag to add the default
signal handlers.
This seems like the least invasive way to do this at this time, but it
will require some re-thinking for 9.0, especially if migrate globals
to engine instances, signal handling will need to be re-thought.
Ticket: #6814
When a plugin is first initialized, it is too early to register
transaction loggers. Instead, a plugin can register a callback to be
called when Suricata is ready for outputs like transaction loggers to
be registered.
Likewise for library users, there is a window in SuricataInit where
transaction loggers can be registered that library users don't have
access to. So a lifecycle callback useful here as well.
Ticket #7236
Introduce DetectGetSingleData which does the generic wrapping,
including the transforms, using a new callback prototype
DetectTxGetBufferPtr
The goal is to replace most InspectionBufferGetDataPtr.
For this commit, we do not change every callback to keep the
change relatively small.
Focus here is to remove DetectHelperGetData as its functionality is
provided more directly by the new DetectTxGetBufferPtr.
This callback will be called when alert action has been changed due to a
rate filter. The user can then reset or customize the action in their
callback per their own logic.
As the callback is added to the current detection engine, make sure its
copied to the new detection engine on reload.
Ticket: #7673
util-device.h exposes some details that are particularly problematic
for C++, even when wrapped in 'extern "C"'. To address this, break the
header into public and private parts. The public part exposes
LiveDevice as an opaque data structure, while the private header has
the actual definition.
The idea is that only Suricata C source files should include the
private header, it should not be re-included in any other header
file. And this is the header library users should use, however we
don't enforce it with tecnical means, a library user could still
include the private header, but the clue there is in the name.
Ticket: 7667
And prefix SCDetectBufferSetActiveList to be exported
Allows less use of suricata crate in plugin as we get the functions
prototypes from suricata_sys and they are more correct.
Ticket: #2696
There are a lot of changes here, which are described below.
In general these changes are renaming constants to conform to the
libhtp-rs versions (which are generated by cbindgen); making all htp
types opaque and changing struct->member references to
htp_struct_member() function calls; and a handful of changes to offload
functionality onto libhtp-rs from suricata, such as URI normalization
and transaction cleanup.
Functions introduced to handle opaque htp_tx_t:
- tx->parsed_uri => htp_tx_parsed_uri(tx)
- tx->parsed_uri->path => htp_uri_path(htp_tx_parsed_uri(tx)
- tx->parsed_uri->hostname => htp_uri_hostname(htp_tx_parsed_uri(tx))
- htp_tx_get_user_data() => htp_tx_user_data(tx)
- htp_tx_is_http_2_upgrade(tx) convenience function introduced to detect response status 101
and “Upgrade: h2c" header.
Functions introduced to handle opaque htp_tx_data_t:
- d->len => htp_tx_data_len()
- d->data => htp_tx_data_data()
- htp_tx_data_tx(data) function to get the htp_tx_t from the htp_tx_data_t
- htp_tx_data_is_empty(data) convenience function introduced to test if the data is empty.
Other changes:
Build libhtp-rs as a crate inside rust. Update autoconf to no longer
use libhtp as an external dependency. Remove HAVE_HTP feature defines
since they are no longer needed.
Make function arguments and return values const where possible
htp_tx_destroy(tx) will now free an incomplete transaction
htp_time_t replaced with standard struct timeval
Callbacks from libhtp now provide the htp_connp_t and the htp_tx_data_t
as separate arguments. This means the connection parser is no longer
fetched from the transaction inside callbacks.
SCHTPGenerateNormalizedUri() functionality moved inside libhtp-rs, which
now provides normalized URI values.
The normalized URI is available with accessor function: htp_tx_normalized_uri()
Configuration settings added to control the behaviour of the URI normalization:
- htp_config_set_normalized_uri_include_all()
- htp_config_set_plusspace_decode()
- htp_config_set_convert_lowercase()
- htp_config_set_double_decode_normalized_query()
- htp_config_set_double_decode_normalized_path()
- htp_config_set_backslash_convert_slashes()
- htp_config_set_bestfit_replacement_byte()
- htp_config_set_convert_lowercase()
- htp_config_set_nul_encoded_terminates()
- htp_config_set_nul_raw_terminates()
- htp_config_set_path_separators_compress()
- htp_config_set_path_separators_decode()
- htp_config_set_u_encoding_decode()
- htp_config_set_url_encoding_invalid_handling()
- htp_config_set_utf8_convert_bestfit()
- htp_config_set_normalized_uri_include_all()
- htp_config_set_plusspace_decode()
Constants related to configuring uri normalization:
- HTP_URL_DECODE_PRESERVE_PERCENT => HTP_URL_ENCODING_HANDLING_PRESERVE_PERCENT
- HTP_URL_DECODE_REMOVE_PERCENT => HTP_URL_ENCODING_HANDLING_REMOVE_PERCENT
- HTP_URL_DECODE_PROCESS_INVALID => HTP_URL_ENCODING_HANDLING_PROCESS_INVALID
htp_config_set_field_limits(soft_limit, hard_limit) changed to
htp_config_set_field_limit(limit) because libhtp didn't implement soft
limits.
libhtp logging API updated to provide HTP_LOG_CODE constants along with
the message. This eliminates the need to perform string matching on
message text to map log messages to HTTP_DECODER_EVENT values, and the
HTP_LOG_CODE values can be used directly. In support of this,
HTP_DECODER_EVENT values are mapped to their corresponding HTP_LOG_CODE
values.
New log events to describe additional anomalies:
HTP_LOG_CODE_REQUEST_TOO_MANY_LZMA_LAYERS
HTP_LOG_CODE_RESPONSE_TOO_MANY_LZMA_LAYERS
HTP_LOG_CODE_PROTOCOL_CONTAINS_EXTRA_DATA
HTP_LOG_CODE_CONTENT_LENGTH_EXTRA_DATA_START
HTP_LOG_CODE_CONTENT_LENGTH_EXTRA_DATA_END
HTP_LOG_CODE_SWITCHING_PROTO_WITH_CONTENT_LENGTH
HTP_LOG_CODE_DEFORMED_EOL
HTP_LOG_CODE_PARSER_STATE_ERROR
HTP_LOG_CODE_MISSING_OUTBOUND_TRANSACTION_DATA
HTP_LOG_CODE_MISSING_INBOUND_TRANSACTION_DATA
HTP_LOG_CODE_ZERO_LENGTH_DATA_CHUNKS
HTP_LOG_CODE_REQUEST_LINE_UNKNOWN_METHOD
HTP_LOG_CODE_REQUEST_LINE_UNKNOWN_METHOD_NO_PROTOCOL
HTP_LOG_CODE_REQUEST_LINE_UNKNOWN_METHOD_INVALID_PROTOCOL
HTP_LOG_CODE_REQUEST_LINE_NO_PROTOCOL
HTP_LOG_CODE_RESPONSE_LINE_INVALID_PROTOCOL
HTP_LOG_CODE_RESPONSE_LINE_INVALID_RESPONSE_STATUS
HTP_LOG_CODE_RESPONSE_BODY_INTERNAL_ERROR
HTP_LOG_CODE_REQUEST_BODY_DATA_CALLBACK_ERROR
HTP_LOG_CODE_RESPONSE_INVALID_EMPTY_NAME
HTP_LOG_CODE_REQUEST_INVALID_EMPTY_NAME
HTP_LOG_CODE_RESPONSE_INVALID_LWS_AFTER_NAME
HTP_LOG_CODE_RESPONSE_HEADER_NAME_NOT_TOKEN
HTP_LOG_CODE_REQUEST_INVALID_LWS_AFTER_NAME
HTP_LOG_CODE_LZMA_DECOMPRESSION_DISABLED
HTP_LOG_CODE_CONNECTION_ALREADY_OPEN
HTP_LOG_CODE_COMPRESSION_BOMB_DOUBLE_LZMA
HTP_LOG_CODE_INVALID_CONTENT_ENCODING
HTP_LOG_CODE_INVALID_GAP
HTP_LOG_CODE_ERROR
The new htp_log API supports consuming log messages more easily than
walking a list and tracking the current offset. Internally, libhtp-rs
now provides log messages as a queue of htp_log_t, which means the
application can simply call htp_conn_next_log() to fetch the next log
message until the queue is empty. Once the application is done with a
log message, they can call htp_log_free() to dispose of it.
Functions supporting htp_log_t:
htp_conn_next_log(conn) - Get the next log message
htp_log_message(log) - To get the text of the message
htp_log_code(log) - To get the HTP_LOG_CODE value
htp_log_free(log) - To free the htp_log_t
Also remove function to set the library mode. This is easy enough to
do with SCRunmodeSet, and we don't want to add a specific setter for
each and every runmode.
Ticket: #7240
Use the more conventional "--" command line handling to separate the
arguments. The first set will be passed to Suricata, and the args
after "--" will be handled by the example. Currently this is a single
PCAP filename, but will be extended to a list of PCAP filenames.
Also hard code logging to the current directory.
Ticket: #7240
Philippe Antoine
Jason Ish
Victor Julien
Todd Mortimer