[Oisf-users] Discrepancies in Snort and Suricata alerts
fatema bannatwala
fatema.bannatwala at gmail.com
Fri Oct 5 15:54:49 UTC 2018
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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20181005/a8de5420/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: evidence.zip
Type: application/x-zip-compressed
Size: 2325 bytes
Desc: not available
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20181005/a8de5420/attachment-0001.bin>
More information about the Oisf-users
mailing list