[Oisf-users] [Emerging-Sigs] More "Unknown type of Driveby Sigs"

[Joel Esler]

I've read this thread, as we are currently planning the release and production of features for the next major version of Snort (beyond what we've already built), and I'm still not sure what's being asked for.  

--
Joel Esler

On Nov 27, 2011, at 11:16 AM, Victor Julien <victor at inliniac.net> wrote:

> I wonder if this really belongs in the IDS engine itself. A SIEM like
> facility should be a better place I think. For example,  in a system
> like Sguil you could also remove the noalert from the first sig and have
> it generate the alert. Then in Sguil set it to "autocat" so it doesn't
> show up in the console. When the second sig matches you will be able to
> see what else fired for that flow and then it will show up giving the
> analyst all the info.
> 
> Thoughts?
> 
> On 11/26/2011 07:46 PM, Kevin Ross wrote:
>> No I don't think so. If I was tracking flows so I do this:
>> 
>> 1) I set flowbit for a client doing a GET for a PDF from an exploit kit (we
>> aren't sure at this point because of the format if it is genuine so we
>> noalert it
>> 2) Second Sig then checks flowbit and then sees PDF coming down so it
>> alerts.
>> 3) Third sig as you suggest checks both flowbits and generates an alert.
>> However it would alert on the same thing as the second one or possibly a
>> later packet (I think) as it can't back track and generate an alert for
>> stage 1 as it is at a different part of the flow. However we may want to
>> alert on stage 1 due to looking at websites, sources who may be
>> participating in other parts of the activity (I know you can get logs for
>> snort and suricata to see what sites and URI did stage 2 but stage 1 may
>> have been on a different site.
>> 
>> Regards, Kev
>> 
>> 
>> On 25 November 2011 23:50, Victor Julien <victor at inliniac.net> wrote:
>> 
>>> On 11/25/2011 08:47 PM, Kevin Ross wrote:
>>>> actually that just gave me an idea for something that could be put into
>>>> Suricata and that is the option to set a flowbit in a kind of noalert
>>> state
>>>> for the second stage and then only if the second stage fires then an
>>> alert
>>>> is generated for the noalert type sig. That means in this case we would
>>> be
>>>> able to suppress noisy FP sigs but we then consider the second part (the
>>>> download) to be indicative of an exploit kit and so we may want to
>>> generate
>>>> an alert for the first part only if confirmed. So it is a noalert unless
>>>> the next sig fires then alert on this too.
>>> 
>>> This would be achieved by having both rules set a flowbit and then have
>>> a third rule check for both bits, right?
>>> 
>>> --
>>> ---------------------------------------------
>>> Victor Julien
>>> http://www.inliniac.net/
>>> PGP: http://www.inliniac.net/victorjulien.asc
>>> ---------------------------------------------
>>> 
>>> _______________________________________________
>>> Oisf-users mailing list
>>> Oisf-users at openinfosecfoundation.org
>>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>> 
>> 
> 
> 
> -- 
> ---------------------------------------------
> Victor Julien
> http://www.inliniac.net/
> PGP: http://www.inliniac.net/victorjulien.asc
> ---------------------------------------------
> 
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
> 
> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!