[Oisf-users] Discrepancies in Snort and Suricata alerts
Travis Green
travis at travisgreen.net
Fri Oct 5 16:20:24 UTC 2018
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/fa2ff2af/attachment-0001.html>
More information about the Oisf-users
mailing list