The SMTP parser should not supply lines w/o EOL chars to the mime
parser unless its in the BODY parsing stage. Mimic this in the fuzz
target by testing the state for inputs that have no EOL.
Additionally, make sure the delim cnt reflects the missing EOL.
When in live-pcap mode, if the sniffed interface went down and up again,
Suri would enter an infinite and keep running, while not registering new
events. This fixes that behavior by allowing Suri to retry to open the
pcap in case of a retry on an already activated capture
('PCAP_ERROR_ACTIVATED').
This change is based on Zhiyuan Liao's work.
Bug #3846
That page existed only in our redmine. Updated and added a few things,
like a paragraph about our expectations for feature contributors.
Also updated links, contacts and some other processes that may have
changed since last edition.
Added some section labels in related documents, for ease of referencing.
Task #4929
This avoids long lasting inactive flows because in the most likely
case the RST did in fact end the connection. However Suricata may
still consider it to be "established".
The flow manager scans the hash table in chunks based on the flow timeout
settings. In the default config this will lead to a full hash pass every
240 seconds. Under pressure, this will lead to a large amount of memory
still in use by flows waiting to be evicted, or evicted flows waiting to
be freed.
This patch implements a new adaptive logic to the timing and amount of
work that is done by the flow manager. It takes the memcap budgets and
calculates the proportion of the memcap budgets in use. It takes the max
in-use percentage, and adapts the flow manager behavior based on that.
The memcaps considered are:
flow, stream, stream-reassembly and app-layer-http
The percentage in use, is inversely applies to the time the flow manager
takes for a full hash pass. In addition, it is also applied to the chunk
size and the sleep time.
Example: tcp.reassembly_memuse is at 90% of the memcap and normal flow
hash pass is 240s. Hash pass time will be:
240 * (100 - 90) / 100 = 24s
Chunk size and sleep time will automatically be updated for this.
Adds various counters.
Bug: #4650.
Bug: #4808.
For connections that use TCP timestamps for which the first SYN packet
does not reach the server, any replies to retransmitted SYNs will be
tropped.
This is happening in StateSynSentValidateTimestamp, where the timestamp
value in a SYN-ACK packet must match the one from the SYN packet.
However, since the server never received the first SYN packet, it will
respond with an updated timestamp from any of the following SYN packets.
The timestamp value inside suricata is not being updated at any time
which should happen. This patch fixes that problem.
Bug: #4376.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
When trying to propegate the depth/offset, within/distance chains
a logic error would set too a restrictive depth on a pattern that
followed more than one "unchained" patterns.
Bug: #5162.
Use a macro to validate the ranges for overflows. This removes
the clutter of all the checks and warnings, and also no longer
puts the state machine in an undefined state when hitting such
a condition.
So 'alert dcerpc' also matches if the DCERPC is over SMB.
Explicitly refuse smb keywords for the 'dcerpc' app proto setting:
`alert dceprc ... smb.share; ...` is rejected.
Remove a now useless special case in the stateless rule processing
matching for dcerpc/smb.
Bug: #5208.
Otherwise, if we log a first app_layer_event, then reset
with AppLayerDecoderEventsResetEvents for a new packet,
then get another event, it does not get logged
Ticket: #5391