[Oisf-users] Discrepancies in Snort and Suricata alerts
fatema bannatwala
fatema.bannatwala at gmail.com
Fri Oct 5 16:28:26 UTC 2018
Ah my mistake, was having "http" as display filter on wireshark and wanted
to filter other noise.
Here's the pcaps with follow stream display filter from wireshark, showing
the TCP handshake and the complete streams.
On Fri, Oct 5, 2018 at 12:21 PM Travis Green <travis at travisgreen.net> wrote:
> FWIW, it seems there is no three way handshake in either of those pcaps,
> and any flow:established rules will not fire.
>
> On Fri, Oct 5, 2018 at 9:55 AM fatema bannatwala <
> fatema.bannatwala at gmail.com> 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 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> 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> 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>
>>> 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> 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> 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> 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 /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
>>>> >>
>>>> >> 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> 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 ->
>>>> 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/
>>>> >>
>>>> >> _______________________________________________
>>>> >> 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/
>>>>
>>>>
>>>>
>>>> --
>>>> PGP: ABE625E6
>>>> keybase.io/travisbgreen
>>>>
>>>
>
> --
> PGP: ABE625E6
> keybase.io/travisbgreen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20181005/bb02bfee/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-2022813-snort.pcap
Type: application/octet-stream
Size: 4477 bytes
Desc: not available
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20181005/bb02bfee/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-2022813-suri.pcap
Type: application/octet-stream
Size: 4477 bytes
Desc: not available
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20181005/bb02bfee/attachment-0003.obj>
More information about the Oisf-users
mailing list