[Oisf-users] Discrepancies in Snort and Suricata alerts

Tue Sep 25 16:05:38 UTC 2018

I tried to capture some traffic, but those pcaps aren't triggering any
alerts in both snort and suricata, have to work on getting some pcap with
some traffic that would be malicious and could trigger alerts.
Meanwhile, was looking into the alerts that were triggered in Snort and not
in Suricata for last 15 minutes on live servers, and did the following
analysis:

Example of few alerts triggered in snort but not in suricata: sid:
2022813, 2008974, 2009714
when I looked at the above alert rules defined in ET ruleset for snort and
ET ruleset for suricata,
the only major difference found is in the protocol defined in both alerts,
i.e. :

suricata alert 2022813 definition:
alert *http* $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE
SearchProtect PUA User-Agent Observed"; flow:established,to_server;
content:"SearchProtect|3b|";
depth:14; http_user_agent; reference:md5,34e2350c2ed6a9a9e9d444102ae4dd87;
classtype:trojan-activity; sid:2022813; rev:2; metadata:created_at
2016_05_17, updated_at 2016_05_17;)

snort alert 2022813 definition:
alert *tcp* $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET MALWARE
SearchProtect PUA User-Agent Observed"; flow:established,to_server;
content:"User-Agent|3a 20|SearchProtect|3b|";
fast_pattern; http_header; reference:md5,34e2350c2ed6a9a9e9d444102ae4dd87;
classtype:trojan-activity; sid:2022813; rev:1; metadata:created_at
2016_05_17, updated_at 2016_05_17;)

And from snort alert logs, the packet content that triggered that 2022813
alert:

[1:2022813:1] ET MALWARE SearchProtect PUA User-Agent Observed
2018-09-25 11:09:39.337000-04:00 128.164.63.89:51872 -> 54.243.209.194:80
TCP: Data Triggering Snort Rule: POST / HTTP/1.1::~~Content-Type:
application/json::~~Accept: */*::~~User-Agent:
SearchProtect;3.0.50.0;Microsoft Windows 7
Enterprise;SPC0AFF85F-9E31-44AC-8E1C-61C39CDE89DC::~~Host:
sp-alive-msg.databssint.com::~~Content-Length: 2157::~~Connection:
Keep-Alive::~~Cache-Control: no-cache::~~::~~
[Xref => md5 34e2350c2ed6a9a9e9d444102ae4dd87]

Hence, looking at the contents of the above data triggering log, looks like
it matches the Suricata rule signature as well, except not sure if the
protocol detected was actually http or not, and hence Suricata alert might
not have trigged for the same content.
Other alerts that weren't triggered in Suricata were also having "http" in
place of "tcp" in the rule signatures, when compared with snort rule
signatures. Hence my guess is Suricata isn't able to detect http protocol
for the same traffic and hence not triggering the alerts.

Thanks,
Fatema.

On Tue, Sep 25, 2018 at 12:13 AM Michał Purzyński <
michalpurzynski1 at gmail.com> wrote:

> It would be really useful to have some data we could work on. You can
> always share pcaps with developers only, subject to your company's policy.
>
> One more thing you could do without sharing traffic is to verify if these
> cases when snort matches a signature A and Suricata does not, it is a false
> positive or a true positive.
>
> That would be a great start.
>
>
> On Mon, Sep 24, 2018 at 2:59 PM fatema bannatwala <
> fatema.bannatwala at gmail.com> wrote:
>
>> Hmm, makes sense, was just curious to know what happens when snort
>> ruleset was fed to Suricata,
>> and to produce a baseline for the initial test environment to see if the
>> important alerts are not missed by Suricata once deployed in prod.
>> Hence was trying to keep the rulesets same for both for an even
>> comparison..
>>
>> Thanks!
>> Fatema.
>>
>> On Mon, Sep 24, 2018 at 4:29 PM Michael Shirk <shirkdog.bsd at gmail.com>
>> wrote:
>>
>>> The issue is that the engines are different, so Snort signatures from
>>> VRT/Talos, even ET-Pro written for the Snort detection engine are only
>>> tested with Snort. There was a good presentation by Dave Wharton at
>>> SuriCon 2016 about the subtle differences that can cause signatures
>>> written for either engine to not work in the other. Digging into the
>>> specifics of a signature that works in Snort but does not work in
>>> Suricata may highlight a similar issue.
>>>
>>> At least from what I have seen, similar to the issue you had with
>>> pulledpork using a Snort signature set with a Suricata signature set,
>>> I believe the user base selects one detection engine over the other.
>>> The community will send emails with new detections that can end up in
>>> the emerging threats signatures, as well as the community based Snort
>>> rules, but specific to one of the engines.
>>> On Mon, Sep 24, 2018 at 4:18 PM fatema bannatwala
>>> <fatema.bannatwala at gmail.com> wrote:
>>> >
>>> > Hmm, don't want to start Suricata in IPS mode, as it's configured to
>>> sniff traffic through a tap and should really be running as an IDS.
>>> > Not sure if the triggering of alerts would depend on mode though, but
>>> I might be wrong..
>>> >
>>> > On Mon, Sep 24, 2018 at 3:41 PM Albert Whale <
>>> Albert.Whale at it-security-inc.com> wrote:
>>> >>
>>> >> So what happens if you start Suricata in IPS Mode?
>>> >>
>>> >>
>>> >> On 9/24/18 2:17 PM, fatema bannatwala wrote:
>>> >>
>>> >> Hi Albert,
>>> >>
>>> >> I am running Suricata in IDS mode.
>>> >>
>>> >> Thanks,
>>> >> Fatema.
>>> >>
>>> >> On Mon, Sep 24, 2018 at 2:11 PM Albert E Whale <
>>> Albert.Whale at it-security-inc.com> wrote:
>>> >>>
>>> >>> Hi Fatema,
>>> >>>
>>> >>> I’m curious, are running Suricata in IDS or IPS mode?
>>> >>>
>>> >>> I am experiencing significant issues with IPS on a small home office
>>> environment.
>>> >>>
>>> >>> Sent from my iPhone
>>> >>>
>>> >>> > On Sep 24, 2018, at 1:26 PM, fatema bannatwala <
>>> fatema.bannatwala at gmail.com> wrote:
>>> >>> >
>>> >>> > Hi All,
>>> >>> >
>>> >>> > I am working on getting Suricata up and running with same rulesets
>>> as we have for snort.
>>> >>> > Hence running Suricata with both VRT open source free ruleset from
>>> Cisco as well as with ET-PRO rule sets from Proofpoint for suricatav4.0.4.
>>> >>> >
>>> >>> > When I start Suricata it gives some errors for around 200 VRT
>>> rules concerning Invalid_Signature/Unknown_Keyword, which make sense as
>>> they are not designed to be run with Suricata. But Suricata starts up
>>> correctly and works fine inspite of those rule errors.
>>> >>> >
>>> >>> > My concern is, the number of unique alerts that get triggered in
>>> Snort are more than the unique alerts triggered in Suricata, even though
>>> both are getting same traffic flow. The difference is huge, i.e. 241 unique
>>> Snort alerts compared to only 94 unique alerts in Suricata.
>>> >>> >
>>> >>> > When did an analysis, the difference is between ETPRO alerts as
>>> well as VRT alerts that are triggered in both. And confirmed that the sids
>>> that are getting triggered in snort are also enabled in suricata, but still
>>> no suricata alerts for those sids.
>>> >>> >
>>> >>> > Hence, my question is why there is this discrepancy in the alerts
>>> that get triggered in snort and not in suricata even when they both are
>>> seeing the same traffic and have same sids enabled?
>>> >>> >
>>> >>> > P.S My initial thought was, either it's because of capture loss in
>>> suricata (which is <0.1%), or maybe because of some of those incompatible
>>> VRT alerts that are enabled in Suricata, and it is not able to work
>>> correctly because of those.
>>> >>> >
>>> >>> > Has anyone tried this kind on config before?
>>> >>> >
>>> >>> > Thanks,
>>> >>> > Fatema.
>>> >>> >
>>> >>> >
>>> >>> > _______________________________________________
>>> >>> > 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/
>>> >>>
>>> >>
>>> >> --
>>> >> --
>>> >>
>>> >> Albert E. Whale, CEH CHS CISA CISSP
>>> >> President - Chief Security Officer
>>> >> IT Security, Inc. - A Service Disabled Veteran Owned Company -
>>> (SDVOSB)
>>> >> HUBZone Certified
>>> >> LinkedIn Profile
>>> >>
>>> >>
>>> >> Phone: 412-515-3010 | Email: Albert.Whale at IT-Security-inc.com
>>> >> Cell: 412-889-6870
>>> >>
>>> > _______________________________________________
>>> > 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/
>>>
>>>
>>>
>>> --
>>> Michael Shirk
>>> Daemon Security, Inc.
>>> https://www.daemon-security.com
>>>
>> _______________________________________________
>> 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20180925/692595ac/attachment.html>