[Oisf-users] Suricata 4.0.0 - bypass/performance issue

Victor Julien lists at inliniac.net
Tue Jul 25 12:42:38 UTC 2017


On 24-07-17 16:54, Martin Petracek wrote:
> I tried --disable-detection, -S /dev/null and I didn't notice any
> difference (either there is no difference or it's negligible).
> 
> Neither --set stream.reassembly.raw=false did any difference (I tried to
> play with this option before in config file).
> 
> The performance is still bad with these options (vanilla source).
> 
> 
> Maybe I wasn't precise, I don't want to disable rules/detection
> completely. I would like to use some rules in later stages of
> development (I don't want to cut that option completely), but these
> would be only for HTTP/TLS/DNS names, not for packet content.
> 
> 
> I'm not sure what were the cases that this patch tried to address still
> (what I might be missing, what's bypassed too early). I'm not sure if
> it's worth that dramatic performance penalty.

The performance decrease is against a seriously broken version that
bypasses lots of rules leading to false negatives. So the 'good'
performance you got there is the anomaly.

I've created a patch to optimize the --disable-detection case, it should
give you perf much closer to the broken stuff before:
https://github.com/inliniac/suricata/pull/2855 Can you give this a run
and let us know how it works?

I think we can do optimizations for the case with rules as well later,
but that will be more involved.

Cheers,
Victor


> 
> Best regards
> Martin Petracek
> 
> On 20.7.2017 10:32, Victor Julien wrote:
>> On 20-07-17 10:26, Victor Julien wrote:
>>> On 19-07-17 17:27, Martin Petracek wrote:
>>>> Oh, I should also mention that I'm using suricata without any rules,
>>>> just to perform deep-packet-inspection and get HTTP/TLS/DNS information.
>>>> I'm getting these information still, even with this patch. I think the
>>>> information drop could be important with some rules.
>>>
>>> Are you using --disable-detection?
>>>
>>> If so, could you test the vanilla source with -S /dev/null instead? I
>>> think there may be a dependency on the detection engine.
>>>
>>
>> Also separately could you add this commandline option and see if it has
>> any effect?
>>
>> --set stream.reassembly.raw=false
>>
>>
>>
>> _______________________________________________
>> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
>> Conference: https://suricon.net
>> Trainings: https://suricata-ids.org/training/
>>
> 
> 
> 
> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> 
> Conference: https://suricon.net
> Trainings: https://suricata-ids.org/training/
> 


-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170725/7c0aed32/attachment-0002.sig>


More information about the Oisf-users mailing list