Update the no-jansson test to fail out if configure
passes.
The script needed to be converted into a single list item
for the early exit to work on Travis.
- There is now an option to automatically create streams on the
correct NUMA node when using cpu affinity.
- When not using cpu affinity the user can specify streams to be
created in the suricata.yaml file. It is no longer required to
use NTPL to create streams before running suricata.
- The legacy usage model of running NTPL to create streams is still
available. This can be used for legacy configurations and complex
configurations that cannot be satisfied by the auto-config option.
pledge(2) can be used on OpenBSD to restrict suricata possible
operation on the system once initialization is completed.
The process promises to only make use of:
- "stdio" to allow read(2) on IPS rules and write(2) on log file
- "rpath wpath cpath" to allow log rotation
- "unix" to operate the control unix socket and log unix sockets
- "dns" to retrieve DNS from recvfrom(2)/sento(2) in IPFW mode
- "bpf" as suricata uses libpcap, which uses the BIOCGSTATS operation
Signed-off-by: Emmanuel Roullit <emmanuel.roullit@cognitix.de>
The mode input in chmod is an octal integer. However when the warning is logged,
the file mode is printed in decimal which is confusing.
Signed-off-by: Emmanuel Roullit <emmanuel.roullit@cognitix.de>
The return value from the options decoder in TCP and IPv4 is ignored.
This commit changes the return type of the function to `void` and
modifies existing return points to return without a value.
When an error occurs, the packet state is being set to indicate whether
it's valid or not and the existing return value is never used.
This fixes two memleaks found with ASAN.
Direct leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x7f59cf4a4d28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
#1 0xd7f92f in ReceiveNFLOGThreadInit /home/glongo/suricata/src/source-nflog.c:221
#2 0xe9c8eb in TmThreadsSlotPktAcqLoop /home/glongo/suricata/src/tm-threads.c:293
#3 0x7f59cd7aa4a3 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x74a3)
Indirect leak of 70000 byte(s) in 1 object(s) allocated from:
#0 0x7f59cf4a4d28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
#1 0xd814ea in ReceiveNFLOGThreadInit /home/glongo/suricata/src/source-nflog.c:324
#2 0xe9c8eb in TmThreadsSlotPktAcqLoop /home/glongo/suricata/src/tm-threads.c:293
#3 0x7f59cd7aa4a3 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x74a3)
SUMMARY: AddressSanitizer: 70096 byte(s) leaked in 2 allocation(s).
When Suricata picks up a flow it assumes the first packet is
toserver. In a perfect world without packet loss and where all
sessions neatly start after Suricata itself started, this would be
true. However, in reality we have to account for packet loss and
Suricata starting to get packets for flows already active be for
Suricata is (re)started.
The protocol records on the wire would often be able to tell us more
though. For example in SMB1 and SMB2 records there is a flag that
indicates whether the record is a request or a response. This patch
is enabling the procotol detection engine to utilize this information
to 'reverse' the flow.
There are three ways in which this is supported in this patch:
1. patterns for detection are registered per direction. If the proto
was not recognized in the traffic direction, and midstream is
enabled, the pattern set for the opposing direction is also
evaluated. If that matches, the flow is considered to be in the
wrong direction and is reversed.
2. probing parsers now have a way to feed back their understanding
of the flow direction. They are now passed the direction as
Suricata sees the traffic when calling the probing parsers. The
parser can then see if its own observation matches that, and
pass back it's own view to the caller.
3. a new pattern + probing parser set up: probing parsers can now
be registered with a pattern, so that when the pattern matches
the probing parser is called as well. The probing parser can
then provide the protocol detection engine with the direction
of the traffic.
The process of reversing takes a multi step approach as well:
a. reverse the current packets direction
b. reverse most of the flows direction sensitive flags
c. tag the flow as 'reversed'. This is because the 5 tuple is
*not* reversed, since it is immutable after the flows creation.
Most of the currently registered parsers benefit already:
- HTTP/SMTP/FTP/TLS patterns are registered per direction already
so they will benefit from the pattern midstream logic in (1)
above.
- the Rust based SMB parser uses a mix of pattern + probing parser
as described in (3) above.
- the NFS detection is purely done by probing parser and is updated
to consider the direction in that parser.
Other protocols, such as DNS, are still to do.
Ticket: #2572