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
Better handle case where pcap file receive thread fails to initialize. Allow
initialize to complete, but terminate the thread quickly. Delay exiting
unix socket runmode as late as possible.
Global NFQ contexts were not freed properly causing
'use-after-free' error. Moving contexts cleanup to a
separate NFQContextsCleanup() and calling it from
GlobalsDestroy(), like it's done for AFPacket, solves
the problem.
In case the pid file is given in the config file, the file name is
stored in volatile memory. Removal of the pid file happens after
cleanup of config memory. Create a copy of the name which will be
freed after the pid file has been removed.
* the lzma check during configure wasn't properly displaying the
additional information on how to install if --enable-lzma was passed
but lzma devel files were not present
* updated additional information blocks to include distribution
package names
* minor formatting updates to add quotes around variables
Signed-off-by: jason taylor <jtfas90@gmail.com>
Flow direction doesn't need explicit checking as the rule groups (sgh)
are already per direction. So if a rule sets only flow:to_server or
flow:to_client, we can avoid adding a sigmatch to the signature.
Fix match array reset depending on prefilter matches for the
current run. If there were none, the match array of the previous
packet was used. This could lead to inspection of rules from the
wrong rule group.
Loading rules with iprep keyword cause
memory leaks due to missing frees.
Direct leak of 8 byte(s) in 4 object(s) allocated from:
#0 0x7f81c862bd28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
#1 0x7f81c6afea69 in pcre_get_substring (/lib/x86_64-linux-gnu/libpcre.so.3+0x27a69)
#2 0x43206f7420676e68 (<unknown module>)
SUMMARY: AddressSanitizer: 8 byte(s) leaked in 4 allocation(s).