[Oisf-users] Discrepancies in Snort and Suricata alerts
David Wharton
oisf at davidwharton.us
Fri Oct 5 16:48:54 UTC 2018
What kernel are you running? I know there were some hash symmetry issues
with 4.4 and AF_PACKET (although I know you said PF_RING didn't work
either). What about the NIC and RSS queues?
Michal can speak more intelligently about these things than I can but I
thought I'd throw it out there; see also
https://suricata.readthedocs.io/en/latest/performance/packet-capture.html.
-David
On 10/05/2018 11:54 AM, fatema bannatwala wrote:
> I would also be out next week, so just have today for doing some more
> troubleshooting before I get back.
>
> I captured the traffic generated from a wifi host hitting cnn.com
> <http://cnn.com> with "SearchProtect" as UA: $ curl -A
> "SearchProtect" http://cnn.com
> on both Snort and suricata sensors.
> Amazingly they both captured exact same size of pcap for that traffic.
> Then I ran those pcaps through snort and suricata in offline mode on
> corresponding boxes.
> They both fired the alerts (with sid:2022813) and logged them in
> fast/eve.json, with http logging enabled in suricata produced http.log
> file as well.
>
> But when I run both in online packet sniffing mode, and was doing curl
> to produce traffic, only snort fired the alerts and not suricata.
>
> I use PF_ring with snort and AF_packet with suricata sensors. So I
> though maybe it's AF_Packet messing with the flow oriented packets on
> suricata, and hence tested it with PF_ring, but no positive results.
>
> I am attaching the captured pcaps from snort/suricata sensors if that
> is helpful.
>
> Thanks,
> Fatema.
>
> P.S: Suricata relevant config settings in suricata.yaml (followed
> SepTune):
>
> ### Local Bypass enabled ###
> stream:
> memcap: 64mb
> checksum-validation: no
> inline: no
> bypass: yes
> reassembly:
> memcap: 256mb
> depth: 1mb
> toserver-chunk-size: 2560
> toclient-chunk-size: 2560
> randomize-chunk-size: yes
>
> ### Threading ###
> threading:
> set-cpu-affinity: yes
> cpu-affinity:
> - management-cpu-set:
> cpu: [ 0 ] # include only these cpus in affinity settings
> mode: "balanced"
> prio:
> default: "low"
> - worker-cpu-set:
> cpu: [ 4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38 ] #
> cpu 2 is pinned to Interrupts hence not included in workers
> mode: "exclusive"
> prio:
> default: "high"
>
> #### AF Packet ####
> af-packet:
> - interface: em1
> threads: 18
> cluster-id: 99
> cluster-type: cluster_flow
> defrag: yes
> use-mmap: yes
> tpacket-v3: yes
> ring-size: 200000
> block-size: 65536
>
> On Fri, Oct 5, 2018 at 5:30 AM Michał Purzyński
> <michalpurzynski1 at gmail.com <mailto:michalpurzynski1 at gmail.com>> wrote:
>
> I’ve been living airport life recently but as soon as I’m
> somewhere more permanent I’ll run this sample and see what it
> tells me.
>
> It might be a capture bug indeed. I’d assume that you use the same
> capture method for both snort and Suri?
>
> On Oct 4, 2018, at 11:31 PM, fatema bannatwala
> <fatema.bannatwala at gmail.com <mailto:fatema.bannatwala at gmail.com>>
> wrote:
>
>> I was able to do some troubleshooting today, what's weird is, for
>> a user-agent alert (sid:2022813) I was able to generate traffic
>> using curl from my desktop, and snort triggered the alerts for
>> that traffic but no alerts in suricata.
>> But when I captured the traffic using tcpdump and ran snort and
>> suricata in offline mode reading from that pcap, both triggered
>> the alerts, which makes me think that might be there are issues
>> with the mutli-threading with suricata.
>>
>> I followed the SepTune doc to pin the IRQs to housekeeping core
>> as well as pinning interrupts to separate core, of the same Numa,
>> and using rest for workers in suricata, but no positive result so
>> far.
>>
>> The issue I think is with how the multi-threading is handled in
>> packet sniffing mode from the interface in suricata, and
>> reordering of packets before it's reaching suricata's engine.
>>
>> Thanks,
>> Fatema.
>>
>> On Thu, Oct 4, 2018 at 5:10 PM Travis Green
>> <travis at travisgreen.net <mailto:travis at travisgreen.net>> wrote:
>>
>> I was able to locate an exe making the request shown above
>> (f59cb3abb8ae0fb0fd626f86a75adff2), and I've also found a
>> pcap for it
>> which you can download here: https://reep.io/d/xo0rdnswuv
>> (password is
>> "oisf-users").
>>
>> I've run it against Suricata versions 4.0.0, 3.2, and 2.0.1
>> but sadly
>> was not able to reproduce the false negative. Results can be
>> viewed
>> here: http://autoids.net/output/58408e977582ade6ed1e1efee27c9628
>>
>> Hope that helps,
>> -Travis
>> On Thu, Oct 4, 2018 at 8:06 AM fatema bannatwala
>> <fatema.bannatwala at gmail.com
>> <mailto:fatema.bannatwala at gmail.com>> wrote:
>> >
>> > Hi Michal,
>> >
>> > Thanks for the pointers, will try to get some malware
>> samples, and see if we are still seeing any cnc traffic from
>> that host and if that can be captured.
>> > Meanwhile I will also enable eve http logging and will
>> compare it with bro http connections.
>> >
>> > I will keep you posted.
>> >
>> > Thanks,
>> > Fatema.
>> >
>> > On Thu, Oct 4, 2018 at 6:24 AM Michał Purzyński
>> <michalpurzynski1 at gmail.com
>> <mailto:michalpurzynski1 at gmail.com>> wrote:
>> >>
>> >> Looks like we might have a bug here. I agree that it seems
>> like Suricata does not recognize some HTTP traffic as HTTP.
>> >>
>> >> Can I get samples of this malware somewhere? I’d love to
>> run it here. I can run full packet capture for a week no problem.
>> >>
>> >> Can you enable eve log type http?
>> >>
>> >>
>> https://suricata.readthedocs.io/en/suricata-4.0.5/output/eve/eve-json-output.html
>> >>
>> >> This would let us know if suricata indeed fails to
>> recognize traffic as http. It’s kind of like bro http.log
>> >>
>> >> Do you have enough resources to capture traffic from
>> infected host to internet?
>> >>
>> >> On Oct 4, 2018, at 4:46 AM, Amar <amar at countersnipe.com
>> <mailto:amar at countersnipe.com>> wrote:
>> >>
>> >> Hello Fatema
>> >>
>> >> I see your comment about contuing to use Snort! If Snort
>> works for you anyway, may I ask what factors are driving you
>> to look at/use Suricata in the first place?
>> >>
>> >> Regards
>> >> Amar Rathore
>> >> CounterSnipe Systems LLC
>> >>
>> >>
>> >> On Oct 3, 2018 at 6:57 PM, <fatema bannatwala> wrote:
>> >>
>> >> Yet another example where no alerts fired in Suricata but
>> in Snort for legit bad traffic for "Andromeda" Trojan.
>> >>
>> >> Both the suri and snort signatures for sid:2809682 are
>> same, and yet only snort triggered the alert for an outbound
>> POST request to a domain related to Andromeda Trojan.
>> >> Bro detected those connections as http, hence the
>> application should be recognized by Suricata as http.
>> >>
>> >> Bro http log for the connection that triggered snort alert:
>> >> 10/2/18 7:06:46.734 PM CGOaPc2Kyn0xd3eGkd 128.x.x.x
>> 58299 184.105.192.2 80 1 POST atomictrivia.ru
>> <http://atomictrivia.ru> /atomic.php - 1.1 Mozilla/4.0 64 0
>> 200 OK - - (empty) - - - FUR4T54aQNbHsxbG84
>> >>
>> >> Snort alert for the same:
>> >> Oct 2 19:06:47 snort[3664]: [1:2809682:3] ETPRO TROJAN
>> Andromeda/Gamarue Checkin [Classification: A Network Trojan
>> was Detected] [Priority: 1]: {TCP} 128.x.x.x:58299 ->
>> 184.105.192.2:80 <http://184.105.192.2:80>
>> >>
>> >> No Suricata alerts fired for the same.
>> >>
>> >> The notification of this activity was sent by a third
>> party to us today, hence we are sure that the host is
>> compromised as it was trying to resolve Andromeda domains.
>> >>
>> >> I can't capture the pcap for the traffic that triggers
>> snort alerts but not Suri, as it is sporadic, and only couple
>> of minutes of traffic capture results in gigs of traffic,
>> hence I can't just keep running pcap capture for a long
>> period of time on the sensors.
>> >> If I can't figure out what is going on with Suri not
>> firing the alerts, then we just might have to drop Suricata
>> deployment in prod and keep working with Snort.
>> >>
>> >> Any pointers/suggestions?
>> >>
>> >> Thanks,
>> >> Fatema.
>> >> Event Actions
>> >>
>> >> On Tue, Sep 25, 2018 at 12:05 PM fatema bannatwala
>> <fatema.bannatwala at gmail.com
>> <mailto:fatema.bannatwala at gmail.com>> wrote:
>> >>>
>> >>> 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
>> <http://128.164.63.89:51872> -> 54.243.209.194:80
>> <http://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
>> <http://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
>> <mailto: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
>> <mailto: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 <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto:Albert.Whale at IT-Security-inc.com>
>> >>>>>> >> Cell: 412-889-6870
>> >>>>>> >>
>> >>>>>> > _______________________________________________
>> >>>>>> > Suricata IDS Users mailing list:
>> oisf-users at openinfosecfoundation.org
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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/
>>
>>
>>
>> --
>> PGP: ABE625E6
>> keybase.io/travisbgreen <http://keybase.io/travisbgreen>
>>
>
>
> _______________________________________________
> 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/20181005/b133c038/attachment-0001.html>
More information about the Oisf-users
mailing list