Victor Julien [Sat, 21 Feb 2015 13:19:48 +0000 (14:19 +0100)]
Remove spinning PacketPoolWait
PacketPoolWait in autofp can wait for considerable time. Until now
it was essentially spinning, keeping the CPU 100% busy.
This patch introduces a condition to wait in such cases.
Atomically flag pool that consumer is waiting, so that we can sync
the pending pool right away instead of waiting for the
MAX_PENDING_RETURN_PACKETS limit.
Victor Julien [Tue, 21 Oct 2014 08:04:57 +0000 (10:04 +0200)]
detect: set action from utility function
Set actions that are set directly from Signatures using the new
utility function DetectSignatureApplyActions. This will apply
the actions and also store info about the 'drop' that first made
the rule drop.
Eric Leblond [Mon, 19 Jan 2015 18:16:49 +0000 (19:16 +0100)]
flow-timeout: fix init of pseudo packet
The code was not checking if we had enough room in the direct
data. In case default_packet_size was set really small, this was
resulting in data being written over the data and causing a crash.
The patch fixes the issue by forcing an allocation if the direct
data size in the Packet is to small.
Eric Leblond [Thu, 12 Feb 2015 20:15:27 +0000 (21:15 +0100)]
decode: introduce PacketCallocExtPkt function
In flow timeout handling we need a function that allocate and blank
a place that will be used to put constructed packet data. This new
function has no other goal.
Jason Ish [Fri, 27 Feb 2015 17:30:47 +0000 (11:30 -0600)]
When re-opening a log file on HUP, always append.
This will prevent log files that have not been rotated by some
external tool from being deleted, but log files that were
rotated (moved out of the way) will be re-opened.
This is a better default behaviour, especially when not all
log files are rotated at the same time.
Jason Ish [Thu, 15 Jan 2015 20:43:45 +0000 (14:43 -0600)]
Don't attempt to load the rule files if the rule-files configuration
node is not a sequence. Instead log a warning as this is usually
a configuration error.
Eric Leblond [Fri, 6 Mar 2015 19:03:13 +0000 (20:03 +0100)]
json-alert: log tls info in alert
This patch adds the capabilities to log the TLS information the
same way it is currently possible to do with HTTP. As it is
quite hard to read ASN.1 directly in the stream, this will help
people to understand why suricata is firing on alert relative
to TLS.
Eric Leblond [Wed, 18 Feb 2015 10:45:12 +0000 (11:45 +0100)]
build: don't link with libnfnetlink
Don't link suricata with libnfnetlink when we don't have support
for NFQUEUE or NFLOG. Previously, suricata was linked with this
library without reason.
Victor Julien [Thu, 19 Feb 2015 09:39:50 +0000 (10:39 +0100)]
Fix compiler warning on CentOS 5.11
cc1: warnings being treated as errors
app-layer-smtp.c: In function ‘SMTPParseCommandBDAT’:
app-layer-smtp.c:908: warning: dereferencing type-punned pointer will break strict-aliasing rules
Eric Leblond [Thu, 19 Feb 2015 08:37:23 +0000 (09:37 +0100)]
util-ioctl: don't build code RX ring on old system
If ETHTOOL_GRXRINGS is undefined we will not be able to build the
RX rings code. So we can make the build conditional to the
definition of ETHTOOL_GRXRINGS.
Victor Julien [Fri, 23 Jan 2015 12:06:44 +0000 (13:06 +0100)]
http: remove unused and broken 'content-len' logic
The HTTP tracking code would parse the content lenght and store it
in the TX user data. It didn't take the possibility or errors into
account though, leading to a possible negative int being cases to
unsigned int. Luckily, the result was unused.
Victor Julien [Fri, 23 Jan 2015 11:09:29 +0000 (12:09 +0100)]
dcerpc: fix error handling for alloc errors
Fix error handling of stub parsers. In case of SCRealloc error the
function would return a non-error code. This could possibly lead to
memory corruption.
Victor Julien [Wed, 18 Feb 2015 07:50:01 +0000 (08:50 +0100)]
flow: make TCP reuse handling in flow engine optional
In case of autofp (or more general, when flow and stream engine
run in different threads) the flow engine should not trigger a flow
reuse as this can lead to race conditions between the flow and the
stream engine.
In such cases, the flow engine can be far ahead of the stream engine
as packets are in a queue between the threads.
Observed:
Flow engine tags packet 10 as start of new flow. Flow is tagged as
'reused'.
Stream engine evaluates packet 5 which belongs to the old flow. It
rejects the flow as it's tagged 'reused'. Attaches packet 5 to the
new flow which is wrong.
Solution:
This patch connects the flow engines handling of reuse cases to
the runmode. It hooks into the RunmodeSetFlowStreamAsync() call to
notify the flow engine that it shouldn't handle the reuse.
Victor Julien [Thu, 22 Jan 2015 16:30:10 +0000 (17:30 +0100)]
tcp reuse: handle reuse in stream engine
For the autofp case, handling TCP reuse in the flow engine didn't work.
The problem is the mismatch between the moment the flow engine looks at
packets and the stream, and the moment the stream engine runs. Flow engine
is invoked in the packet capture thread(s), while the stream engine runs
as part of the stream/detect thread(s). Because of the queues between
those threads the flow manager may already inspect a new SYN while the
stream engine still has to process the previous session.
Moving the flow engine to the stream/detect thread(s) wasn't an option
as the 'autofp' load balancing depends on the flow already being
available in the packet.
The solution here is to add a check for this condition to the stream
engine. At this point the TCP state is up to date. If a TCP reuse case
is encountered, this is the global logic:
- detach packet for old flow
- get a new flow and attach it to the packet
- flag the old flow that it is now obsolete
Additional logic makes sure that the packets already in the queue
between the flow thread(s) and the stream thread are reassigned the
new flow.
Some special handling:
Apply previous 'reuse' before checking for a new reuse. Otherwise we're
tagging the wrong flow in some cases (multiple reuses in the same tuple).
When in a flow/ssn reuse condition, properly remove the packet from
the flow.
Don't 'reuse' if packet is a SYN retransmission.
The old flow is timed out normally by the flow manager.
Victor Julien [Mon, 15 Dec 2014 14:06:53 +0000 (15:06 +0100)]
flow: handle TCP session reuse in flow engine
Until now, TCP session reuse was handled in the TCP stream engine.
If the state was TCP_CLOSED, a new SYN packet was received and a few
other conditions were met, the flow was 'reset' and reused for the
'new' TCP session.
There are a number of problems with this approach:
- it breaks the normal flow lifecycle wrt timeout, detection, logging
- new TCP sessions could come in on different threads due to mismatches
in timeouts between suricata and flow balancing hw/nic/drivers
- cleanup code was often causing problems
- it complicated locking because of the possible thread mismatch
This patch implements a different solution, where a new TCP session also
gets a new flow. To do this 2 main things needed to be done:
1. the flow engine needed to be aware of when the TCP reuse case was
happening
2. the flow engine needs to be able to 'skip' the old flow once it was
replaced by a new one
To handle (1), a new function TcpSessionPacketSsnReuse() is introduced
to check for the TCP reuse conditions. It's called from 'FlowCompare()'
for TCP packets / TCP flows that are candidates for reuse. FlowCompare
returns FALSE for the 'old' flow in the case of TCP reuse.
This in turn will lead to the flow engine not finding a flow for the TCP
SYN packet, resulting in the creation of a new flow.
To handle (2), FlowCompare flags the 'old' flow. This flag causes future
FlowCompare calls to always return FALSE on it. In other words, the flow
can't be found anymore. It can only be accessed by:
1. existing packets with a reference to it
2. flow timeout handling as this logic gets the flows from walking the
hash directly
3. flow timeout pseudo packets, as they are set up by (2)
The old flow will time out normally, as governed by the "tcp closed"
flow timeout setting. At timeout, the normal detection, logging and
cleanup code will process it.
The flagging of a flow making it 'unfindable' in the flow hash is a bit
of a hack. The reason for this approach over for example putting the
old flow into a forced timeout queue where it could be timed out, is
that such a queue could easily become a contention point. The TCP
session reuse case can easily be created by an attacker. In case of
multiple packet handlers, this could lead to contention on such a flow
timeout queue.
Victor Julien [Tue, 17 Feb 2015 11:08:20 +0000 (12:08 +0100)]
detect-flow: use dedicated flags
The flow keyword used flag names that were shared with the
Packet::flowflags field. Some of the flags were'nt used by the packet
though. This lead to waste of some 'flag space'.
This patch defines dedicated flags for the flow keyword and removes
the otherwise unused flags from the FLOW_PKT_* space.
Victor Julien [Thu, 22 Jan 2015 18:24:35 +0000 (19:24 +0100)]
file: optimize file pruning
FilePrune would clear the files, but not free them and remove them
from the list. This lead to ever growing lists in some cases.
Especially in HTTP sessions with many transactions, this could slow
us down.
Victor Julien [Sat, 24 Jan 2015 13:10:11 +0000 (14:10 +0100)]
flow: lockless flow manager checks
Until this point, the flow manager would check for timed out flows
by walking the flow hash, locking first the hash row and then each
individual flow to get it's state and timestamp. To not be too
intrusive trylocks were used so that a busy flow wouldn't cause the
flow manager to wait for a long time while holding the hash row lock.
Building on the changes in handling of the flow state and lastts
fields, this patch changes the flow managers behavior.
It can now get a flows state atomically and the lastts can be safely
read while holding just the flow hash row lock. This allows the flow
manager to do the basic time out check much more cheaply:
1. it doesn't have to wait for getting a lock
2. it doesn't interupt the packet path
As a consequence the trylock is now also gone. A flow that returns
'true' on timeout is pretty much certainly not going to be busy so
we can safely lock it unconditionally. This also means the flow
manager now walks the entire row unconditionally and is guaranteed
to inspect each flow in the row.
To make sure the functions called before the flow lock don't
accidentally change the flow (which would require a lock) the args
to these flows are changed to const pointers.
Victor Julien [Sat, 24 Jan 2015 12:46:25 +0000 (13:46 +0100)]
flow: modify lastts update logic
In the lastts timeval struct field in the flow the timestamp of the
last packet to update is recorded. This allows for tracking the timeout
of the flow. So far, this value was updated under the flow lock and also
read under the flow lock.
This patch moves the updating of this field to the FlowGetFlowFromHash
function, where it updated at the point where both the Flow and the
Flow Hash Row lock are held. This guarantees that the field is only
updated when both locks are held.
This makes reading the field safe when either lock is held, which is the
purpose of this patch.
The flow manager, while holding the flow hash row lock, can now safely
read the lastts value. This allows it to do the flow timeout check
without actually locking the flow.
Victor Julien [Sat, 24 Jan 2015 12:18:51 +0000 (13:18 +0100)]
flow: change flow state logic
A flow has 3 states: NEW, ESTABLISHED and CLOSED.
For all protocols except TCP, a flow is in state NEW as long as just one
side of the conversation has been seen. When both sides have been
observed the state is moved to ESTABLISHED.
TCP has a different logic, controlled by the stream engine. Here the TCP
state is leading.
Until now, when parts of the engine needed to know the flow state, it
would invoke a per protocol callback 'GetProtoState'. For TCP this would
return the state based on the TcpSession.
This patch changes this logic. It introduces an atomic variable in the
flow 'flow_state'. It defaults to NEW and is set to ESTABLISHED for non-
TCP protocols when we've seen both sides of the conversation.
For TCP, the state is updated from the TCP engine directly.
The goal is to allow for access to the state without holding the Flow's
main mutex lock. This will later allow the Flow Manager(s) to evaluate
the Flow w/o interupting it.
Victor Julien [Thu, 22 Jan 2015 12:43:31 +0000 (13:43 +0100)]
tcp: add stream.reassembly.zero-copy-size option
The option sets in bytes the value at which segment data is passed to
the app layer API directly. Data sizes equal to and higher than the
value set are passed on directly.
Victor Julien [Fri, 16 Jan 2015 10:53:29 +0000 (11:53 +0100)]
tcp: zero copy fast path in app-layer reassembly
Create 2 'fast paths' for app layer reassembly. Both are about reducing
copying. In the cases described below, we pass the segment's data
directly to the app layer API, instead of first copying it into a buffer
than we then pass. This safes a copy.
The first is for the case when we have just one single segment that was
just ack'd. As we know that we won't use any other segment this round,
we can just use the segment data.
The second case is more aggressive. When the segment meets a certain
size limit (currently hardcoded at 128 bytes), we pass it to the
app-layer API directly. Thus invoking the app-layer somewhat more often
to safe some copies.
Ken Steele [Mon, 3 Nov 2014 03:27:07 +0000 (22:27 -0500)]
Further optimize merging mpm and non-mpm rule ID lists.
When reaching the end of either list, merging is no longer required,
simply walk down the other list.
If the non-MPM list can't have duplicates, it would be worth removing
the duplicate check for the non-MPM list when it is the only non-empty list
remaining.